|Why We Don't Need Even More Programming Languages|
|Written by Mike James|
|Monday, 12 December 2011|
Do we need more programming languages?
There are arguments on both sides of the divide.
Do we need more programming languages?
Judging by the number of major announcements of new languages that seek to do better and generally take over the programming world, you would conclude that the answer is a very loud YES.
However if you also listen to the groans that are emitted by programmers already committed to an existing language and simply bored, intimidated or otherwise not impressed by yet another language the answer is an equally emphatic NO.
Recently an article by Fatal Exception's Neil McAllister writing in favor of more programming languages has created something of a stir and given us something to argue about.
To quote from "Why we need even more programming 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. 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.
Essentially the argument McAllister makes is that programming languages are hard to evolve into something better and the only way to do it is to create new languages. PHP 6 is quoted as an example of an evolutionary failure, but this isn't quite the whole story. Sometimes the step that a programming language takes is too big to be evolutionary.
Most PHP programmers would say that PHP 6 is different enough to give it all the problems of a new language with none of the advantages of PHP. The fact that PHP programmers haven't flocked to PHP 6 is actually evidence that we need fewer breaks with the past - fewer new languages not more.
I am firmly of the opinion that most of the time we do not need more programming languages.
There are many reasons I think that this is true and they are worth discussing because they highlight our current linguistic position.
When it comes to mainstream languages we have a problem in that the overwhelming mindset of today's programmers has been created by a C/C++ like language.
Most of the major languages in use take the approach that we can conveniently call C/C++. This includes Java, C#, and just about anything else you care to mention. If you don't believe me consider the simple test of the for loop. Most languages used the three parameter for loop as in:
you never see the alternative Basic style
For index=start To finish
even though it is arguably easier to read. Objects are always defined by the use of the idea of a class rather than an instance and the languages are usually hierarchically typed because of this.
The problem is that most of the new languages are just slight tweaks of Java, C++ or C#. They are all block structured and class based and use a hierarchical type system. They are not all strongly typed, but you can tell that they wish they were as they find ways of relaxing the strong typing to make it easier to use the language dynamically. Put simply, the new languages are all variations on a very limited theme and as such don't really represent new languages.
So what is so bad about this idea?
It is very simple. We put a lot of effort into learning and using a language. Anything that makes a non-backward compatible change is a really bad idea. We still program in Fortran, Pascal , Cobol, Prolog and so on. You can add your own favourite ancient language to this list. Each time someone adds a new language, even if it is a clone of Java, the result is another long term legacy language to maintain.
This is worse than the Tower of Babel because programming languages never die out and are born at far too fast a rate. The population of languages never reduces, it just goes on getting bigger and bigger.
Of course all of this would be just fine if there were some brilliant new programming paradigm to be introduced by the new languages - but simply doing objects slightly better doesn't qualify.
In the past there have been some really big shifts in the way we program that could only easily be implemented by a new language - structured programming, objects, logic programming, functional programming and so on. These are all great, very new and different ideas and it made perfect sense to wipe the slate clean, dump Fortran and implement Simula - not that Simula ever caught on.
Even when the change is as great as adding object orientation there is a really big argument for evolution as opposed to revolution. Take the case of C+ with C as a subset as proof that you don't have to throw the old language out to add something even as radically new as objects.
Unless you have a really, really innovative idea that demands a radical change to the syntax and semantics of the existing languages then the best thing to do is to evolve the existing languages.
Even evolving existing languages may not be a good idea. Many a programming language's shortcomings can be made up for simply by improving the tools used to construct, test and validate the language. For example, you don't need to add strong typing to an untyped language if the IDE checks what the user is doing and flags attempts to use non-existent properties and methods or automatically generates code that checks for their existence. When you look at the sort of tools that most languages have you quickly realize that this is the big unexploited area of potential improvement. The point being that a text editor, no matter how clever, isn't the high point in language tooling.
What if you do have a really groundbreaking idea?
Then, yes, why not launch it as a new language but you need to not have any hopes that the programming world will take to it in huge numbers. Even when they do, be ready for users to treat it like C++ or Java. Inevitably they will ask you to add all of the features that you left on on purpose because they weren't necessary, such as classes.
|Last Updated ( Thursday, 15 December 2011 )|