At any given time, you're probably happiest on the main branches of an evolutionary tree. Even when there were still plenty of Neanderthals, it must have sucked to be one. The Cro-Magnons would have been constantly coming over and beating you up and stealing your food.
I think you might want a little more justification. This principle implies you would be happier as a rodent like thing then a dinosaur. It might be true, but it is not self evident.
If you name your language 'The hundred-year language' then you are asking for people to do two things:
- misinterpret you
- be underwhelmed with your performance
Something like that requires full time dedication of at least one person during the initial phase (say two decades or so), and after that an opening up.
By putting arc out there before it's 'ready' there is an upside, you get feedback from the community. But you also get an installed base and pressure to perform, and that's a drawback.
The haskell community has this motto: "avoid success at all costs". It took a long time to get haskel to be where it is today, and that has a lot to do with their motto. But it was the way to keep it clean and consistent. And arc was/is meant to go for the same if I understood it all right.
You can move fast in the programming language field, but then you'll have to be 'practical' and 'compromising'.
Or you can move slow, but then you risk 'irrelevant' and 'theoretical'.
A 'true' one hundred year language would try to strike a median between the two, it would be developed with a resasonable speed by a really small, core team that was very dedicated to the work.
Arc answers some interesting questions (it's essentially a better lisp), but it has one more drawback compared to lisp, which is that there is only a very small community behind it. This stops it from gaining widespread acceptance, but that is actually a benefit if you want to stay flexible.
But the window of time that you have to remain in that mode is not infinite and I think that the speed at which arc is coming along is mostly driven by improving HN (scale, features) than the other way around.
If HN were to move to say clojure (I know, that's cursing in the church, but I think it is one of the more realistic options when it comes to dealing with growth) then all the drive to keep arc going would be more or less lost.
A programming language for a community of '1' is a hobby project, but if HN came out of 'arc' then in a way the project has already succeeded, just not in the way that it was originally planned.
My longer term prediction is that clojure will occupy the niche that Paul described with the '100 year language', it's also based on lisp, it's headed by one very smart guy that is willing to work with a team of people providing input, it's gaining adoption fast and it solves some very pertinent problems (multi-programming, how to bring the functional paradigm to the web, STM) in elegant ways. And putting it on top of the JVM was sheer genius.
I think you're mistaken that marketing (in the sense of community building) is an important component of designing a language people would still care about in 100 years. The history of the Lisp family is a counterexample. For 50 years (except arguably for a brief interlude in the 1980s) Lisp was popular only with a tiny community of eggheads. Now thanks to Clojure Lisp is fashionable.
The history of such fashions also contradicts your claim that you can lock in a position of leadership by building a big community around your language. There has been new hot language every 5 years. First Perl, then Python, then Ruby, now maybe Clojure.
The way to make a language popular in the short term is build buzz and libraries, because that's what the average programmer cares about. But to build a language that turns out to be the ancestor of whatever people are using in 100 years, you have to appeal not to programmers but language designers. You have to create the ideas language designers want to copy (have to copy, because you found the optimal solution). That's what McCarthy did.
I think creating a 100 year language would be cool, if it weren't for the fact that some geeks are the most fickle people in the world, who jump on the latest fad. They don't want a "100 year language", they want "The new awesome thing". Then 3 years later they want the next fashionable thing to be using.
At the end of the day, it doesn't really matter that much. It's just fashion.
You are confusing actual programmers with web 2.0 fanbois with blogs. Some people value stability and incremental improvement, but those people don't seem to write as much as the "throw everything away and use this language I read about on /b/ last night".
There is probably not a market for the 100 year language, as we don't know enough about programming to predict that far into the future. But all the languages we use today are probably "25 year langauges", which is getting there.
Yeah you're probably right about the fickle people being far more vocal than the ones just using the same language.
I'm not convinced languages are really something that need constant improvement and evolution though. There's a lot to be said for all generally using the same language over a long period of time. I'd say that's more important than which particular language it is.
A language exists to communicate ideas. Obviously you don't want a language that is ambiguous, or overly verbose. You also want a language that can express most ideas you want to express in a simple way.
But IMHO, that's been achieved already - several times over. If we never improved any computer language, and just continued using the ones we have, we'd still be able to express the ideas we have in them.
I agree @ 25 years. Further than that, maybe we won't use any programming languages at all. Who knows.
Personally, I'd love for stuff to stabilize, and for someone to put an end to this madness of having to ditch all the stuff you've learned three years ago because that skill is no longer what businesses expect.
I'm frankly sick and tired of it.
Progress is good. Too much progress can be very tiring, and gives the industry as a whole too little time to consolidate the old with the new.
Which is one reason why everybody is re-inventing the wheel all the time, both in terms of business processes as well as development methodologies.
For certain domain of problems SQL is the 100 year language. You have to define tables and indexes but you don't get to chose how joins are performed - query optimizer knows about your high-level request to chose optimal execution strategy most of the time. It's a small leap from there (in historical terms) to make the indexes built automatically via profile-guided-optimization.
Similarly, Flex is the 100 year language for UI. It's almost entirely devoid of implementation details and you get to spend most of your time describing what you want to see. What Flex is for Flash, open OpenLaszlo is for HTML.
I find the notion that Java could be considered an evolutionary dead end bizarre, considering that it achieved the commercial and mindshare breakthrough for garbage collection and VMs.
In fact, looking at current developments, it seems not unrealistic at all to predict that whatever languages we'll have in 100 years, many of them will be running on a direct descendant of the JVM.
Still, without the widespread success of Java, the JVM as we know it would not exist or would at least not have seen widespread adoption. Thus all languages running on it are, if not sons and daughters, at least nieces and nephews of Java.
I don't know how to break this to you, but despite what the mother may say about who the daddy is, everybody in town is exchanging knowing glances about it having the milkman's eyes.
They already do, at least whenever I hear business types say that X or Y should be really easy I always wonder if they're ever to be in hospital to get surgery if they're going to tell the surgeon as well what should be easy or hard.
I think you might want a little more justification. This principle implies you would be happier as a rodent like thing then a dinosaur. It might be true, but it is not self evident.