The truth about programming languages
rzwitserloot posted in programming on June 19th, 2006
This is a somewhat in depth response to a post made by Mike Bowler here.
I’ll conclude that no one programming language is ‘better’, which is generally common knowledge except for Mr. Bowler, apparently, but also that such evangelism isn’t all that bad for you.
Life just isn’t that simple. Python cannot (and never will) tell you what kind of methods a given variable can have. That’s the penalty you pay for a very dynamic programming environment. For example, when trying to work with Django, I had to continually refer back to documentation and examples to figure out what I had to do. Trying to write a java servlet though, the one thing you will NOT suffer from, is figuring out what text to type to do what you want. (Servlets are horrible, but then again, they’ve been around for a decade. The point stands).
In python, you have to document return types in the docstring. Changing return type and forgetting to update the docs is a common bug, and it will NOT be caught by unit tests. Sorry agile programmers out there, but, unit tests aren’t the end all of solving your bugs. The bother of having to explicitly declare return types is actually a boon when writing libraries. Completely different thing compared to continuations, but that’s the point really. Different programming language, different strengths, different weaknesses. I can give you a bunch more examples if you’d like, where python (A language I’m familiar with) just loses to java (also quite familiar with that). The reverse is also true. Take any two languages and that tends to happen.
The point is: Things like painless as-you-write identifier lookup and functions as first class objects are mutually exclusive. You cannot have both, one needs to pick. Languages that have tried to do both like PL/I just failed. Far too complicated to learn, and worse, any given bit of code in a do-it-all language is probably unreadable to fully half of the population versed in it.
This is where that old adage comes from - a programming language is a tool. Find the right tool for the job and use that. Old programming fogies take that adage and beat the new hotness language evangelists over the head with it, with glee.
But, their glee is misplaced. Mike’s on to something.
Before I continue, I have to quickly undermine another adage: A sufficiently skilled programmer can pick up a new language in a span of weeks. Crock of horse manure. Patently false. Absurd notion. Knowing how to use a language well, playing to its strengths and avoiding its weaknesses, takes years of experience. In fact, I dare to say that most programmers haven’t mastered any language, let alone have a big toolbox to choose from.
But that’s where my little story about the history of programming changes:
Actually, most programming problems are (relatively) trivial. By wich I mean: They are easily bent into whatever shape makes them easy to solve with your favourite programming language. For most problems, you are far better off mastering one language and forcing yourself to see every problem as a nail for your one hammer. Sometimes that will bite you in the arse, but only rarely. It’s generally easier to just soldier through those very rare occasions instead of taking the considerable mental trouble of mastering more than one language.
Don’t forget that modern languages are very mobile. LISP may be pretty much frozen (though even there, lots of libraries are still being built), but java1.5 introduces major changes. PHP5 is a completely different beast compared to PHP4. You may be a Ruby expert, but these days you can’t call yourself a Ruby expert without being at least fairly fluent with Rails as well. Keeping yourself in that vaunted ‘expert’ position is hard work!
So, to conclude, Mike’s football supporter approach to programming languages is the right way to go. If you really like one language and feel very comfortable with it, stick with it!
June 19th, 2006 at 8:52
You can have these in Haskell which has completely statically typed functions which are (of course) first class objects.
June 19th, 2006 at 17:44
Go Go Immutability programming. Didn’t know that.
Still, the point stands - a lot of convenient things are basically mutually exclusive. I’m sure that Haskell having both of those means it doesn’t have something else that various people find convenient.
June 20th, 2006 at 13:17
You mean like conventional setting of variables or easy (meaning non-Monadic) I/O.
Yeah, it definitely is not for the faint of heart.
June 21st, 2006 at 11:33
LISP hasn’t changed in the last 20 (or so) years because it hasn’t needed to. Programming languages haven’t changed much since the early eighties, when Smalltalk populazied object-oriented programming. The only real difference between modern programming languages is syntax, and the amount of high-level languages feature (ie dynamic typing, object-orientatoin, first-order funcitons, macros, closures, continuations, garbage-collection, etc.) the designers implemented. Since learning syntax is fairly, the difficulty of moving between two programming languages is determined by the amount of high-level features were implemented. Moving from to a feature-rich form a feature-poor language seems almost pointless (the blub paradox), until you encounter a problem were you need one of the “new” features, while moving form a feature-rich language to a feature-poor language is all always difficult because you realize just how useful the features you are losing really are (try moving from Java back to plain C).
June 22nd, 2006 at 18:13
I disagree. Take the IDE for example. Lots of stuff happening there. The notion of refactoring scripts is a relatively new invention, and it has forced me to program differently. “Keep it simple” is now more important than it was - after all, nowadays, if I know I’m going to have to make a more complicated version later, I can easily delay. I’ll just refactor the simplistic original.
Used to be it was an actual tradeoff.
Can you write a device driver in LISP? I doubt it. There: Lots of pointedness in moving from a so-called ‘feature-full’ to a ‘feature-poor’ language. I dislike those terms in a big way because it depends on what you consider features.
You think first order objects are a feature. So do I, but I also think link chasing is a feature (the thing where I can control-click on any identifier to automatically end up where the code for that identifier was written). Java IDEs can do it. LISP and Python IDEs, by the very virtue of their dynamic nature, cannot, except for the most trivial of code.
I’ll just restate one of my main points then: You CANNOT have everything. Take all possible programming features you’d like to have. Now design a language that can do em all. Either impossible, or it becomes the biggest piece of pointless bloat ever.
New things have been invented since LISP. Yet LISP hasn’t changed. That’s okay though - those who like LISP can still solve problems with it with the best of em, because LISP is ‘good enough’ - they’ve trained themselves to work with LISPs strengths, and avoid its weaknesses.
THere is no blub paradox.
August 18th, 2006 at 16:50
Have you used Lisp? (probably not, considering your rant about Ruby).
> Things like painless as-you-write identifier lookup and functions as first class objects are mutually exclusive.
Not true. You can have as-you-write identifier lookup. The only thing you can’t do is lookup the value of a higher-order-function-variable. But that’s the same as saying that you shouldn’t have first class integers because you cannot predict the value of an integer variable (that’s why it’s called a variable, right?).
Emacs (with a lisp-mode) even has “link chasing”. Instead of clicking on an identifier you press a key on your keyboard instead of a mouse button.
Please use Lisp and write another rant.
August 18th, 2006 at 16:53
> Can you write a device driver in LISP? I doubt it.
Of course you can. You just need direct access to hardware, but that’s the same in any language.
August 18th, 2006 at 17:39
Re Jules first’ comment: That point was mentioned for Haskell earlier in the thread, and has been answered.
As far as the second one goes: Name a device driver written in LISP. Doesn’t exist. Missing the native libraries. Not to mention something like consecutive ordered dumps to a port don’t mesh well with functional programming at all. You need some sort of middle layer somewhere.
October 2nd, 2006 at 14:56
Most Lisp machines had the entire OS written in Lisp, including device drivers. One example is the Xerox 1186:
http://blogs.sun.com/was/entry/who_the_hell_is_will
A more recent example is writing a VGA screen driver in Dylan (Lisp-derived/inspired):
http://www.opendylan.org/pipermail/gd-hackers/2003-August/004531.html
There are two functions which are just wrappers around outb and inb ASM, but other than that you’re using a dynamic language.
Even Microsoft is experimenting (with some success) in using managed code with their Singularity project:
http://research.microsoft.com/os/singularity/
http://en.wikipedia.org/wiki/Microsoft_Singularity
October 2nd, 2006 at 23:58
LISP can’t just compile to machine code. Neither can basic C, even, there’s the IN and OUT instructions at the very least that need to be ‘ported’. If you hack that in or use some sort of library device, you can.
I thought this would be logical, but I’ll have to explain it in more detail: An OS usually supports device drivers only in the language native to the OS. In Os X, that would be Objective C. In windows, it’s C++, and in Linux, it’s C. All modern OSes in use do NOT use LISP here.