Tue, 06 Nov 2007
Programming languages suck?
Bruno
De Wolf blogs about programming languages. His statement: "all
programming languages suck". Not sure whether I agree. But's let look at
his arguments. In his words, a good programming language, among others,
is readable by a guy who didn't write the original program and who
doesn't know all the language details or libraries
.
Personally, I don't agree. Code readability, above all, depends on the programmer. Programming languages that impose structure can probably help, but it's possible to create unreadable code in any language—that doesn't need goto.
Since I went to the 'karel de grote' institute of higher education, I learned quite a number of programming languages. Hairy code is possible with all of them. Unreadable code is easy with some of them, and some of those I do consider good programming languages. I guess my criteria are different:
- Flexibility. In theory any programming language
that is turing-complete will allow one to write any imaginable program.
In practice, some programming languages will require you 100 lines of
code to do stuff which can be done in three lines in another language. A
programming language that doesn't require you to turn your brain upside
down three times to figure out how to get something done is a better
language in my book than one that does. A language that provides
multiple ways to do any given thing is very strong for this particular
requirement; it allows you to pick the best way to do anything in order
to prove readability. The alternative is for you to have to write some
extra hairy code because the language requires you to jump through silly
hoops.
The Turing Machine utterly fails this criterion. Any language that lacks pointers or references or something similar fails it, too, though not in such a dramatic way. Perl is very good in this particular requirement. - Compactness. I blame COBOL for this particular requirement, but it's still rather important, in my opinion: a programming language should not require me to write an entire novella for a simple 'hello world' program. Obviously COBOL utterly fails this requirement. Large parts of Java's libraries do, too. Perl and C are rather good at this particular requirement.
- Resembling english. COBOL fails this requirement, too—COBOL is english, not a programming language. Brainfuck fails, as well. Obviously. Mostly everything else passes. Except for windev, that is, which resembles French. Hah.
That's it, I guess. In my book, a programming language is a tool to get a job done. A good tool is flexible, not too unwieldly, and somewhat intuitive. Like a hammer. If you want to build a table, you probably need a hammer, among other things. The better the hammer, the more likely it is that you'll get a nice table. But even the best hammer won't get you a wonderfully crafted table if your carpenter sucks at his craft.
And so it is with programming languages: it might help if you use a proper language, but any good programmer can write readable code in any programming language.
I did look at Ruby. It's a nice language, but not so much better than perl, IMO, and that one has way more libraries.
Your "compactness" requirement is weird: does it only apply to hello-world? C is hardly compact for anything else.
I'm also not sure how perl passes "looks like English", unless you're a profane comic-book character. (@Do #!you[] &talk !!like *this?)
"And so it is with programming languages: it might help if you use a proper language, but any good programmer can write readable code in any programming language."
Even a Turing machine? Brainfuck? Whitespace?
P.S., Python is not the language which is notably absent from your list. Lisp is -- http://www.catb.org/~esr/faqs/hacker-howto.html#skills1
- Agreed that you can write both readable and messy code in each language. But in some languages, it's easier to write readable code than in others.
- "a programming language is a tool to get a job done"
I must say I learned the hard way that this statement is way too simplistic. A lot of students and beginning programmers don't realize that the 'fun' only starts when a program is finished. What happens then? Well, the program is actually used (hurray). If it was a non-trivial program with some body, it is likely to be used by a non-techie guy (three times hurray). And if you're lucky, the guy really likes your program and it becomes part of a real 'business process' (the crowd is applauding). And after a year or two or three, a part of this business process changes, the data model is extended or they want to use the same program in a slightly different context. In the meantime, the original developer is doing something else, eventually he left the company or the company that wrote the program is bankrupt. The key user's technical skills include recording an Excel macro, but end there, so he calls a new developer. End result: somebody else needs to take over the development that doesn't know the program, doesn't know what it was supposed to do and doesn't have the original developer or decent documentation to fall back to. And if the original developer wrote his 5000 lines of Perl with fancy regular expressions that the new developer doesn't grasp, the new developer will likely say: 'perl sucks, and the original developer even sucked more, he didn't even foresee [insert new functionality here] but let's redo this pile of crap in ruby, it's the newest and hottest thing' and the whole cycle starts over again.
I have customers where people have a full time job ditching perfectly working programs and replacing them with other programs that do for 90% the same thing and all this just because nobody understands the original program and some things need to be changed.