Linked by snydeq on Sun 11th Dec 2011 01:35 UTC
General Development Fatal Exception's Neil McAllister writes in favor of new programming languages given the difficulty of upgrading existing, popular languages. 'Whenever a new programming language is announced, a certain segment of the developer population always rolls its eyes and groans that we have quite enough to choose from already,' McAllister writes. 'But once a language reaches a certain tipping point of popularity, overhauling it to include support for new features, paradigms, and patterns is easier said than done.' PHP 6, Perl 6, Python 3, ECMAScript 4 -- 'the lesson from all of these examples is clear: Programming languages move slowly, and the more popular a language is, the slower it moves. It is far, far easier to create a new language from whole cloth than it is to convince the existing user base of a popular language to accept radical changes.'
Thread beginning with comment 499910
To read all comments associated with this story, please click here.
Baggage
by torbenm on Mon 12th Dec 2011 09:58 UTC
torbenm
Member since:
2007-04-23

Old languages carry around a lot of baggage, and it is very difficult to get rid of this with language updates -- you can usually add features, but it is extremely hard to get users to accept that you remove any. Even minor syntactic changes can be hard to do. This gets worse as a language have more users.

A new language can be designed cleanly without having to worry about backwards compatibility, so you often get a cleaner design with fewer surprising corner cases. Also, you can avoid the cases where the new features interact badly with the old features.

I agree with the previous poster that libraries are important -- it is often a lot more work to write extensive libraries than it is to design and implement the language itself. But I also think libraries are in as much need of revision as languages. Languages tend to accumulate libraries and it is very difficult to get rid of the badly designed libraries once they are in widespread use. And it often isn't enough to rewrite the implementation of these, as it may be the APIs themselves that are badly designed.

Also, when libraries become too big, they hurt performance. The result is that a simple web application equivalent to a HTML form compiles to 2MB of code and requires 80MB to run.

Extensive libraries also makes programmers lazy: They would rather use a library that is a poor fit to their problem than coding a solution that is better suited, even if this would only need 20 lines of code. In fact, many so-called programmers aren't: They can't program, they can only string library calls together.

This is also why I think Java and its ilk are badly suited for teaching programming: In most cases your program is 90% library calls and 10% real programming, so students come to believe that programming is stringing library calls together. This is why CMU have dropped OO languages from the first year of their CS programme -- instead the students use Standard ML and a (fairly clean) C subset, both with fairly limited libraries.

Reply Score: 2