Ask Hackers: Are you planning to do your startup in Arc? | Hacker News Reader

Ask Hackers: Are you planning to do your startup in Arc?

13 pointskirubakaran59 comments

What are your Arc related plans?

Please share your thoughts.

to be honest i'm tired of all this language talk. The fanboism surrounding lisp, haskell, arc, scheme, erlang, and other less popular languages is getting to be a little too much

Languages don't matter!

When I first started programming, I was so impressed by superhackers who knew like 10 languages or were experts in obscure ones like Forth and whatnot. Then as I learned more languages, I realized that languages are just interfaces into the computer system. Thats it.

Arc won't be able to do anything that binary code can't do.

This is nothing against pg. If you want to create a language because that interests you. Great! I'm just tired of all the elitist fanboys mentally masturbating over how great their language is. maybe i just read programming.reddit too much tho ;)

Well said, spoken like a true Blub programmer!

Right, and ad hominem attacks are OK if someone really doesn't get it?

As a programmer who has a preferred Blub language myself, I saw it more as a flip comment than any sort of name calling. Until someone actually sits down and invents the "100 year language", it won't matter much if you're using a powerful language or one of the lesser blubs.

If you frequent programming.reddit, you must have read http://www.paulgraham.com/avg.html ? Is your opinion still the same?

I must admit I am curious about his statement that 25% of viaweb code would have been very difficult to do in other languages.

I would like to hear examples of that.

My feeling is that the success of viaweb development had much less to do with lisp than it had to with PG and friends being really good hackers.

What a weird situation. I keep trying to tell people Lisp is great, and they say, no, no, you guys were just really good programmers. But if I'm such a good programmer, why don't they believe me?

To nitpick this remark,

Suppose: 1, cperciva is a really good programmer, 2, writing a Viaweb is within his ability.

Given: cperciva intends to write a Viaweb.

Result: Viaweb in C.

http://news.ycombinator.com/item?id=96431 (I know, the logic is flawed. I'm being half-facetious)

Viaweb manipulated s-expressions at runtime and called compile on them. One literally could not write it in C, short of writing a Lisp interpreter in C, which is what Yahoo had to do when they ported it to C++ after I left.

I believe it could be very ugly in C, but not that it could not be written in C.

Ever heard of the concept of Turing Completeness, Google it...

Viaweb was a cash strapped startup in a competitive market, who succeeded against odds because of their speed and agility. They were running on fumes when they were acquired. A longer development period would have certainly meant the death of the company.

So, no, they could not have written it in C.

Wow, that was a cool comment. I don't think I've ever agreed with and wanted to argue with a comment so much as that one. I sat there for about 30 seconds deciding whether to vote it up or down. Kudos! (note - that was totally sincere)

At first I thought you were leaving out their smarts and technology, but speed and agility were because of the smarts and tech. Then I thought I remembered pg saying they were going to close another round of funding when they got bought instead.

But I totally agree with your main point.

Makes sense from that perspective.

The theory says that for any two programming languages there is a constant c such that any given program can be translated from one to the other with only a c difference in size.

That's just an elaborate way of saying that you can write an interpreter (of size c) for one language in another.

Nevertheless, I have a hard time believing that viaweb could not be written in C short of writing a Lisp interpreter. For that to be true, the runtime compilation of s-expressions would have to be essential to the application; there would have to be no other way to write it.

Do you think I would have done something as heavy-handed as compile s-expressions at runtime if it weren't necessary?

We had a page description language called RTML that was Lisp underneath. Users created templates in it, which we then executed to generate their pages. It is these page templates that are still stored on disk as s-expressions in the C++ version.

> Do you think I would have done something as heavy-handed as compile s-expressions at runtime if it weren't necessary?

Why not, if the language makes it simple? I am not claiming that Lisp does not have more powerful abstractions than C, just that they are not usually essential to any given feature in the application.

If Lisp is actually part of the user interface, then clearly there is no way to avoid having a Lisp interpreter. This is begging the question though.

That's why I said "could not write it in C, short of writing a Lisp interpreter," instead of just "could not write it in C."

http://news.ycombinator.com/item?id=99171 Why not, Paul?

That's a {def (on n) (on (+ n 1))} wonderful {(on 1)} idea.

Evaluates to:

  That's a wonderful stack overflow idea.

It works, haha!

Did they preserve the s-expr structures in the C++ version?

PostgreSQL was once a collection of C modules called from Common Lisp. Debugging the cross-language implementation proved too difficult so it was ported entirely to C using tools which mostly moved the parens around. Some lisp structures live on inside it to this day.

Yes, in the C++ version the s-expressions are stored on disk exactly as they were before. The C++ version literally reads a file of Lisp code and executes it. As an instance of Greenspun's tenth rule, it's hard to beat.

The original Lisp version was actually running till last fall. When they introduced the C++ version you had to explicitly choose to "upgrade." There were some users, including me, who hadn't. Finally last fall they called me and told me they were going to move us to the C++ version. It's barely different.

That doesn't sound like something a "normal" programmer would come up with.

It would be nice to have some "cookbooks" for typical applications in LISP or Scheme. Searching for "scheme web development" turns up just one or two hits, all very basic (like this one http://www.scheme.dk/blog/2007/08/introduction-to-web-develo...)

They lack a lot of features one has come to expect from modern web frameworks. Could be that some turn out to be unnecessary, but still. I think I have found good online references for learning the basics of Scheme, but for now, I still don't know if writing full blown web applications is really feasible.

Scheme web development:

http://brl.codesimply.net/

Full-blown web application:

http://ourdoings.com/

Thanks - so brl is following the ASP style approach to html generation (mix code and HTML)? Similar to PHP and JSP?

I like that better than creating the whole HTML in S-Expressions, but at the moment I wonder if the best approach would not be the one I know from XMLC: just operate on the dom-tree of the web page, and then serialize the dom?

Where are good places on the web to discuss such things?

The subtle difference between JSP and BRL is that in JSP %>string<% becomes a statement that outputs the string to a web page, while in BRL ]string[ is simply a string expression. This makes the same handy syntax available for putting any static/dynamic elements together, whether in web pages, emails, or SQL. This would be hard to replicate in a non-sexpr language. Hacking is quick and easy, and centralizing similar code from individual pages is straightforward and natural. BRL doesn't stay messy as PHP tends to.

Other features of BRL could be implemented in a non-sexpr language. It just seems nobody cares to make languages truly suitable for database-driven web apps. PHP could have done something like define-input to solve their register_globals problem while retaining a lot of the convenience it had become famous for. A ResultSet object in any language could be extended to have a very useful subset of the functionality in BRL's sql-repeat.

Anyway, I'm not sure the best place for discussion. Most lispers and schemers don't seem interested in web development. Maybe you could discuss it here on news.yc.

pg: do you think that using a fairly obscure language lowered your valuation in yahoo's eyes because they knew they'd have to rewrite it, or raised it because they knew the hackers they were buying were top-notch?

I don't think it made that much difference either way. They liked us simply because we were the leader in our market.

That's a really perplexing question, isn't it? I gave up trying to answer it after your "Beating the Averages" essay didn't make the world-changing impact it rightly should have.

I suppose the good news is that Lisp hackers today don't have to feel the fear you felt during Viaweb, that the competition would figure out you were using Lisp, start using Lisp themselves, and beat you. Now we know that kind of thing just doesn't happen. Now you can shout it from the rooftops and know they'll only fear you, since you must be some amazing braniac to be productive in so difficult a language.

Aw, man, you fed the troll with an even larger troll.

This is going to be messy.

Maybe I can defuse the situation with the Premature Godwin Maneuver. Look! Over there! It's Hitler!

We just went from 19 to 20. (Or worse.)

"Languages don't matter!"

That's why I write raw machine code exclusively!

I use dice to decide in which language I write today.

Wuss. I use dice AS the input device. Yep. Has a random number generator built right in, it does.

So what language do you use when you roll a 20?

  DO COME FROM (20)
  USE Intercal
  PLEASE GIVE UP

P.S. Could somebody write a real piece of Intercal-code for language selection?

> I realized that languages are just interfaces into the computer system. Thats it.

What do you mean... that's it? From where I stand, that's quite a lot...

That is a really brash statement. Usually this kind of comment comes from someone who hasn't really explored the advantages of the different languages they've tried, they've just taken every language that's come to them and manhandled it until it felt like the language they like. I've seen that happen before a lot, somebody likes C very much, so when they're introduced to Lisp, they basically write C in lisp. what does that give you? well for one thing, you have basically a program that is no better than the C version, but with a strange syntax. However, it means that the coder also hasn't taken advantage of the things you can do in lisp that are different from the things you can do in C. You can't write closures in C, so if you've only ever written in C you probably won't use them when writing in Lisp, and thus it seems like a pretty useless transition.

Languages ARE interfaces to the computer system, but that doesn't mean that some aren't more powerful than others. I could write a paper with a typewriter or a word processor, which are both viable ways to produce a document, but I can do things with a word processor that just aren't feasible on a typewriter. If you've never used a word processor, you won't miss things like "copy and paste" or being able to tweak your margins at any time, but if you HAVE used one before you will feel stifled without those abilities. Now, if you use a word processor, but you don't figure out how to use any of those handy features, than it's just an electronic typewriter to you and you'll say things like "tools don't matter! Typewriters and Word Processors are just two different ways to write a paper. That's it!"

of course, you'll probably get a few odd looks for saying that.

Languages don't matter, eh?

A month ago I heard a couple of hackers talk about how they were able to complete a personnel scheduler in Scheme in 20'000 LOC and a few weeks time, when the previous C++ codebase was 200'000 LOC and was never going to be finished.

Not always, but for certain endeavours, certain languages are just much better tools for the job than others, and by better, understand order of magnitude better. That's a very real fact, even if it doesn't make the languages zealots any less obnoxious.

There are times when I just want to say, "Anything you can build, I can build in BASIC," but I chicken out.

OK, here goes...

Anything you can build, I can build in BASIC. Sure, I may have drop down a level and roll out some tools every once in a while, but my BASIC app will so whatever your <language du jour> app does.

There. I feel better already.

If you want to write a ton of your own support libraries, feel free to join the fray. While you're writing a library to upload files to S3 (or whatever), others are going to be implementing actual website features in Rails. Do you see where I'm going with this?

If you can re-use the MzScheme libraries there is some hope.

I think you make a good point but also consider,

MZ Scheme links trivially to C libraries. I would think that anyone who uses Arc would use this facility heavily. Now whether there exists a C library to do exactly what you want is a different question. And I know this might be heretical here, but ROR is hardly the great time saver the fanboys make it out to be when you count in issues like deployment and doing non standard things with it. (Don't get me wrong, it is a good framework, but it is hardly a magic wand and neither is it very unique - Wicket + scala comes very close to ROR in productivity for example)

PS: How long do you think it would take before people hack up a virtual machine or C code emitter? I, for one would do exactly this if I planned to use it in my startup. It isn't that hard (Ruby's recursive descent sloooww interpreter still powers all those RoR sites, minus the vanishingly few ones in JRuby.)

I've dealt with a couple systems that link Lisp 'trivially' to C. When they say they link trivially, what they mean is that they let you call the function in the C library just like you'd call it from C. This is frequently extremely not how you want to do it in Lisp, and so you're forced to either a) write a Lispification layer, in which you take all the C functions and turn them into a library that acts like you want a Lisp library to act (the usual approach), or b) just write it like it's in C, which makes you very angry all day long, and also loses some of the benefit of writing in Lisp. Both approaches slow you down quite a lot. Especially if you decide not to be an asshole and release your lispification layer as open-source (which you should)-- because then people will all be pounding down your door for fixes and extensions and maintenance for new versions of the C library, which is not what you want to do. You didn't even want to write the layer to begin with, presumably.

So no, 'trivial' C linking not actually a silver bullet making everything hunky-dorey with respect to lack of libraries. Python has a significant advantage in that it's popular enough for many people to have already gone through the Pythonification process for most important libraries, and have also open-sourced their Pythonification layers.

Not only do I plan to do my startup in Arc, I've already decided to use holographic storage to do my backups (it's big, you know).

Doing a startup in something that's not even public yet?

lol... is it yc application season yet?

That's not really something I could answer at this point. I would never put my faith in a language that I haven't hacked around in.

Seems like you're a good candidate for a catch-22...

Not really - hacking around with Arc doesn't require faith in it (since the commitment level is well below the level where you would use it to implement your Next Great Idea). And of course hacking around in it is how he would become confident/impressed enough to use it for bigger things.

@kirubakaran - "What are your Arc related plans?"

I plan to build the arc, set sail and bring 2 of every animal with me.

;)

Is any startup ever "done" in just one language? Everwhere I've been there are a half a dozen.

Why not just wait to see what Arc ends up doing really well out of the box and then considering it for that and leave the things it doesn't handle to something else?

I've been anxiously awaiting to give Arc a try for five or six years now. I don't necessarily have a particular project in mind for it yet, but from what I've seen, I expect to like it, and will start using it for SOMETHING as soon as possible.

Ah, I've got this one figured out. I'm going to use it to implement another dialect of CL... in which I will implement a dialect of Scheme... in which I will reimplement Arc. I'd like to see how many iterations of this one could go through before it becomes completely unusable even for simple arithmetic.

Assuming each one interprets the next.

No, but I may try Clojure. Because it runs on the JVM, there are lots of libraries, and I can always fall back to Java/JRuby if something doesn't work.

Arc and Clojure together may make for a great Lisp year.

Writing code is only half of "doing a startup".

Depends on the startup.

Writing code is between 1% and 99% of a startup.

I'm doing mine in Arc#.NET.

Reply on news.ycombinator.com