Languages Should Die
One of those interesting facts about evolution is that most of the species that ever existed are now extinct. There are good reasons for this. The average life time for a mammalian species is a few million years. There are currently about 5400 species of mammals alive right now, and the mammalian class has existed for about 300 million years. If the current number is representative, there has been about 810 000 different species of mammals during the history of that class. So less than 1% are alive today. And this is only talking about mammals.
Many programming languages have died out, but there are still several old programming languages making a living. Cobol is still the backbone of much infrastructure in the world - it is even evolving still (Cobol 2002 include support for object orientation). Making another analogy with evolution, Cobol would be the sharks of programming languages. They have been around for a long, long time - at least 400 million years in the case of sharks, and 50 for Cobol - and are still recognizable. Fortran is another language that has been used for a long time, and has evolved substantially.
But we also have newer languages. From the view of business and technology, Java and other C-based languages are way ahead. In the dynamic realm, we have Perl, Python and Ruby. All of them over 14 years old. And then we have the really new languages, like Scala and Clojure, who are rapidly gaining use.
Maybe it is a bad thing that these languages that we use day to day have been so long lived. I’m not saying they should die out totally - I know that will never happen. But it might have been better if we had spent energy on fixing the Java language, instead of creating more and more tools to fix deficiencies in the language. The good part about Java is the JVM, and that could have been at least as good now even if we had evolved the language more.
It’s obvious that humanity isn’t evolving like other animals. Natural selection is still happening, but the results are getting skewed by better medicine, social infrastructure and many other inventions. These are tools that make it better for us - with the side effect that natural evolution is changing course. Something similar seems to have happened with Java - we have created so many tools to fix Javas problems, that there isn’t enough pressure to fix the language. I tend to believe that this is a good strategy for humanity, but a bad strategy for language development.
I’m happy that more and more new languages are gaining play on the JVM, on LLVM, the CLR and Parrot. That’s great. But on the other hand I’m seeing threads on Ruby-talk asking whether Ruby can stay ahead. Why would we want that? Wouldn’t it be better to take the best pieces of Ruby, and build on that? In the keynote at the last RubyConf, Dave Thomas proposed that people fork the language. I think that would be a great thing if it started to happen more.
I guess I’m sounding a bit like “yeah, all the current effort is good, but it could be better!”. And it could be. I think the way most people look at languages are all wrong.
Michael Feathers wrote a post on Artima called Stunting a Framework. Maybe we should look at language development in that way? Is this another way to approach DSLs, or can we get more useful, smaller languages, by using such an approach? I think it would be very interesting, no matter what.
Languages should die and be replaced. There should be less cost involved in developing a language. Languages should work on common infrastructure that makes this easy - and we’re finally hitting that mark with machines such as the JVM, LLVM, CLR and Parrot.
So - you should go out and fork your favorite language. Or your least favorite language. Fix the things that you don’t like with it. Modify it for a specific domain. Remove some of the cruft. Create a new small language. It doesn’t have to be big. It doesn’t have to do everything - one of the really cool things about functional languages is that they are often have a very small core. Use a similar approach. Hack around. See what happens.
No existing language will die in a long time. But we need new ideas. New fresh ways of looking at things. And new languages that incorporate what other languages do right. That’s how we will finally get rid of the things we don’t like in our current languages.
You should be ready to abandon your favorite language for something better.
Ola Bini is a Swedish developer working for ThoughtWorks. His daily job includes working on JRuby, starting up a Swedish ThoughtWorks office and mucking around with Java and Ruby. In his spare time he spends most time on his language Ioke, working on one of several other open source projects or reading science fiction. Ola has presented at numerous conferences, such as JavaOne, Javapolis, JAOO, RailsConf, TheServerSide Java Symposium and more. He is the author of APress book Practical JRuby on Rails Ola is a DZone MVB and is not an employee of DZone and has posted 29 posts at DZone. You can read more from them at their website.
- Login or register to post comments
- 4445 reads
- Printer-friendly version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)















Comments
Jeroen Wenting replied on Wed, 2009/04/15 - 4:44am
Many of those are closely related (and often hardly changed at all) from relatives that lived among the dinosaurs. When the flashy young kids on the block evolved and died out, these guys stuck to what they were good at and survived.
The same is true to a large extent for programming languages. We may write BPEL processes deployed on multicore blades to call Cobol programs running on 20 year old mainframes, but those Cobol programs will still be around a decade from now when those BPEL processes will be long forgotten.
Change isn't always for the better, and change for the sake of change (which most change in this industry seems to be) hardly ever is (meaning that sometimes, by accident, it might have a positive effect, but usually it doesn't).
Javier Neira replied on Wed, 2009/04/15 - 5:21am
Jeroen Wenting replied on Wed, 2009/04/15 - 6:25am
That 1.0 Java is dying, living on only as part of the genetic code of its more evolved siblings. Because the time since its demise as a living language has been short, there's still code around that might even be maintained, just like Neanderthal man lived for a while next to Homo Erectus who ultimately replaced him (and might even have interbred with him).
Girish Bellalcheru replied on Wed, 2009/04/15 - 10:15am
in response to: jwenting
Jeroen Wenting replied on Thu, 2009/04/16 - 12:17am
Ray Walker replied on Thu, 2009/04/16 - 1:05am
John Ferguson Smart replied on Thu, 2009/04/16 - 5:33am
in response to: jwenting
Jeroen Wenting replied on Thu, 2009/04/16 - 6:17am
Russel Winder replied on Thu, 2009/04/16 - 8:29am
Clojure is not a new language, it is a dialect of Lisp running on a JVM -- with access to the installed Java etc. libraries. Lisp is as old as Fortran and Cobol. Yet Lisp (and hence Clojure) remains unique amongst programming languages in that there is no syntactic distinction between code and data. This makes for some seriously interesting programming techniques -- notwithstanding the old prejudice against self-modifying code.
It would be sad if Lisp died simply because it was old.
Re Java: The sooner the JVM is fixed to support parameterized types, and type erasure is removed, the sooner Java will be a language it is possible to use. CLR got this issue right. Arguments about backward compatibility do not wash since the JVM changed anyway to support annotations.
Jeroen Wenting replied on Sat, 2009/04/18 - 1:02pm
If you want C++ style templates, use C++.
Ray Walker replied on Sun, 2009/04/19 - 8:26pm
in response to: jwenting