Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
A different kind of Arc challenge: a quest for a true 100 year language (offbytwo.com)
19 points by cstejerean on Feb 5, 2008 | hide | past | favorite | 24 comments


I am not certain what this new challenge is trying to achieve. The Arc challenge serves an immediate purpose: getting people to investigate Arc (and perhaps to ease the sniping put-up-or-shut-up style).

Thinking about a 100 year language seems very ivory tower like. I feel like that is something I should do after I create something useful and generate significant wealth.


> Thinking about a 100 year language seems very ivory tower like.

Agreed. I'd rather have something 'pretty good' right now, and worry about the future later. This industry changes too quickly to do something like worry about 100 years in the future.

> I feel like that is something I should do after I create something useful and generate significant wealth.

Disagree, and I think a truly great version of Arc is the opportunity cost of Viaweb and YCombinator. I think to create a truly great language, you have to really focus on your language, and probably start, if not in your 20ies, by around 30. I think that perhaps that ship has sailed for PG and Arc, although I'd be happy to be proven wrong. I think though, that YC is in some ways a bigger and better hack than Arc, and am glad he's done it - there are plenty of people to work on new languages (there are so many that the cost is essentially 0, for something that is not an easy project), but far fewer people in a position to do something like YC as successfully as PG has.


> This industry changes too quickly to do something like worry about 100 years in the future.

Disagree. It may seem ivory-tower-y, but it's a great aspiration, and I don't see anyone else doing it. PG is financially secure, and probably one of the smarter hackers out there - I think it would be hard for him to justify a less ambition goal - surely it's better than toiling away publishing academic papers for whatever academic fads are popular, the vast majority of which will lie discarded 100 years from now.


When I think about what technology was like 100 years ago, I'm dubious that aiming at 100 years from now is sensible. Creating and popularizing a good, hacker-friendly language that works well now is already a tough challenge and a worthy goal.


When I think about what technology was like 100 years ago

Touche... on the other hand, although I don't have artistic training, I'm sure there are techniques which have stayed around, even though photography has mostly "replaced" painting in most uses (or at least in some way...). By analogy, if some technology replaces explicit programming, people will still program.


I wish I were more eloquent so I could state my opinions clearly. 'Writing a language' might be a component of creating a product. Language theology (sorry... hopefully you get what I mean, is there a word for this?) appears to me to be the worst kind of procrastination - the one where you think you are working but you really aren't.


I'm trying to hopefully convince someone to write a new language I can use so that I don't have to write it myself.


I don't like submitting links to my own site. I was going to write this as a new post here but it soon became unwieldy so with a bit more editing I posted it on my blog. I'm curious to see what you think.


If you went to the trouble of writing it, why not post it, if it's on topic? The worst that can happen is that it's ignored.


Implement Arc, eh. Maybe you'll go first?


I don't know about implementing Arc but I might take a stab at writing a language that would make writing Arc easy.


I don't know about implementing Arc but I might take a stab at writing a language that would make writing Arc easy.

Be careful. This sounds like it could be the first step down the Dark Path. You do realize that this is how Lisp ended up where it is today: approximately 73 forked versions, differing in arcane and subtle ways, none of which has definitive mindshare, all of which snipe at each other in terms that most programmers can't even understand. The result: market confusion, stagnation, and possible eventual extinction.

So, by all means have fun writing an Arc interpreter, but don't float off into space like an untethered astronaut. Please consider trying to make Arc better rather than handcrafting your own, individual, poorly documented meta-Arc clone thing. Please. Think of the children.


Oh, I have no intent on writing a new version of Arc and floating it around. I simply used Arc as an example of something that should be easy to write in a new powerful language.

I would love to contribute to Arc if it was available for example via distributed source control (like Git).


Okay, please don't take this the wrong way, but I'm going to put my Vince Lombardi coaching hat on and pick on this statement:

I would love to contribute to Arc if it was available for example via distributed source control (like Git).

What on Earth are you talking about? Arc is 4600 lines of code! Steve Wozniak used to type in more than that by hand every time the power went out on his Apple I! You could do the source control using papyrus and it still wouldn't be a showstopper!

Okay, I'm taking the hat off now. Admittedly, the only reason I'm exhorting you to get started is that it's easier than finding the time to learn Arc myself. ;)


The distributed nature of Git makes it easy to maintain my local patches that Git will attempt to use even against newer versions of Arc as they get released and other folks would be able for example to pull in changes from my repo (and I could from theirs) if it solved an urgent problem before PG could incorporate them into the codebase. It simply makes it easier and encourages collaboration. Certainly not necessary however.

Maybe I should create a repository and mirror PG's releases for a while.


Is that the mentality that gave us Arc?


> What should a language do to be a true hundred-year language? > It should make it easier for programmers to write DSLs.

Agreed. And there are already a couple of us working on such languages. Have a look at Converge http://convergepl.org/ as an example. To be honest, I think we're barely even scratching the surface of what might be possible. But in the meantime one can have fun with odd examples like an abstract-ish assembler DSL that can implement things like a Fibonacci generator http://convergepl.org/cgi-bin/gitweb.cgi?p=src;a=blob;f=exam...


I need to take a closer look at this.


"Steele and Sussman tried to start over when they first began working on Scheme, but they seem to have been practically the only ones. And they made, at least from the point of view of brevity/power, some serious mistakes early on."

So what mistakes did they make?


The first thing that comes to my under-caffeinated mind is the fact that set! and the like don't return useful values. PG also considers hygenic macros to be a mistake. I haven't used them enough to form a meaningful opinion, but they feel like a mistake.


I believe not including a hashtable in the standard was one of the problems (but I don't know much Scheme)


The name "call-with-current-continuation"?

(well, actually it didn't appear until RRRS ...)


But then for call-with-current-continuation there is also call/cc ... I've rarely seen the full name spelled out in code.


call/cc wasn't in the Scheme standard formally until R6RS.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: