Each language feature introduced that tries to enforce safety of some kind invariably introduces some reduction in the power of the language. Some of these tradeoffs’ seem acceptable. The Java security model is an example of a limiting factor in the deployment and execution of a Java application which makes perfect sense to me. Java also hides memory management and pointers from you, which for the majority of applications also makes sense, however sometimes you really want to get hold of the underlying memory model and do nasty things with pointers and that is why C and C++ are still used for writing OS API’s.
Other limitations just become more frustrating over time. Java’s strongly typed language provides a great deal of compile-time checking, at the cost of program flexibility – Python, Ruby et al provide a richer, dynamically typed language which gives the programmer much more power (And anyone saying “You get dynamic typing with Groovy” is going to get smote with the cluestick of death, +1.). At this point I’d like to borrow a phrase from Spiderman (uh oh – nerd alert!) “With power comes responsibility”. Such dynamic languages with their more flexible typing can also get you into a bit of a mess. These dynamic languages can be seen primarily as enabling languages – they make the assumption that developer actually know what they are doing. As a result, they will on occasion let them shoot yourself in the foot. C and C++ likewise let you shoot yourself in the foot – they also however let you shoot the guy next to you, blow your car up, drink your beer and steal your girlfriend, but that perhaps is a discussion for another day.
With Java, Sun used the typing model to provide the developer with some safety by enabling complie-time checking. They attempted to enforce good OO practises by not allowing multiple inheritance of base classes. I can only assume they tried to keep things simpler by not introducing generics sooner. However each of these things can become a frustrating limitation in the hands of a developer how knows perfectly well that you shouldn’t point the gun at your foot, play golf in a lightning storm or eat yellow snow. Perhaps it is time the Sun started to accept that some of us actually want that power?
When I was thinking about this, I started to think about the relative merits of several languages, and mentally started to plot them on a graph (well, actually I started out to make a league table, but in the end that didn’t make a whole lot of sense). Along the X-axis we have power. Along the Y axis we have danger – or, the number of ways in which said language can really ruin your day. The realisation I can to quite quickly was that the relationship between the power and danger associated with a language is not linear – I consider C and C++ (I have amused you are using ‘safe’ C# code) to be more dangerous than the dynamic languages of Ruby and Python and yet not as powerful.
It’s important to note that the relative strengths and weaknesses of these languages can be contextual – for example Haskell makes it extremely easy to do some very complex jobs, but some other simple tasks can be a real pain to perform compared to other languages (IO comes to mind). Please also note that I’m talking about the relative powers of _language_ features – excluded are factors such as the ease of installation, performance, rich API’s etc. Such comparison can wait for another day.
The relative plottings on the graph are purely subjective and are based on my own (in some cases limited) experiences with the languages in question – a more quantitive study would no doubt yield more interesting results, but such a study would in all likelihood get in the way of me making sweeping generalisations. Flame away!
_Update_: Some problems with the graph display, should be sorted now.
5 Responses to “The league of dangerous languages”
In the Python world, we tend to refer to the principle that the programmer should generally be trusted to know what he or she is doing as “programming for consenting adults”.
See also “The principle of least privilege”:http://www.brunningonline.net/simon/blog/archives/000528.html .
BTW, I’m not sure that textile is working properly on your site – that should have been a link, I think. It worked OK in the textile page.
Bah – looks like its not woking. I’ll have a tinker…
Right – textile is working, but I have Auto-link URL’s turned on, so MT made a HREF which resulted in Textile ignoring it. I’ve turned auto-link off for now (will have to fix up the old comments) so it should work.
I suspect the smart quotes. Something converted my ordinary quote characters to curly quotes – perhaps this happened before Textile had its go, and Textile doesn’t recognise the curly quotes.
Coming along this evening, Sam?
Actually, IO is very easy to do in Haskell. Unfortunately the functional programming literature makes it sound really complicated by talking about monads and category theory. However, all that mathematical guff can be safely ignored unless you want to do wizardly stuff like optimising passes in the Haskell compiler itself.