"Clinical Trials" For Programming Languages?
theodp writes "High school junior Charles Dawson's New Year resolution is to write a new program in different language each week. It's an ambitious project for someone of any age, and while it won't give him an in-depth appreciation of programming language differences, it'll certainly give him greater insight into the strengths of certain languages than would perusing the Hello World Wikipedia article. Lots of claims are made about the comparative productivity of programming languages, but have there been any landmark studies that measure the efficacy of a programming language's productivity claims in a 'clinical trial' of sorts? Would head-to-head tests against other languages be a better way of sorting out Popularity vs Productivity vs Performance claims, or is relying on more nebulous claims of superiority the best we can do?"
long flamewar
There is already a pretty good collection http://www.99-bottles-of-beer.net/
There is also a website with the implementations of the Perl cookbook in a bunch of languages: http://pleac.sourceforge.net/
The answer is research is sparse in this area, but the few times it's been tried (using competent programmers in each language rather than conflating learning the language and productivity in it), is LISP and LISP-like languages win when measuring programmer productivity and ability to express complex algorithms in small amounts of code, and C and C++ like languages win for ultimate ability to make the program run fast. But the variability from programmer to programmer in how fast the program runs can exceed the variability between languages so it pays to get high quality programmers who have an intimate understanding of both efficient algorithms and the underlying machine architecture, rather than think "the language will make the program run fast".
With everything, there are professional users and amateur users. For amateur users, it's important to get reasonably good results with relatively low effort without much learning. For professionals, what counts is the effort for projects the size a professional does, after learning a lot.
Trying a new programming language every week cannot give any useful information to a professional user, because the language can only be judged on how well it works for inexperienced developers on tiny projects. That's not what professionals do.
PHP is unparalleled for people who want to make a webpage without having to understand HTTP.
Or PHP for that matter...
(...kidding...)
I, for one, am looking forward to the inevitable
Master Po: The Tao gave birth to machine language. Machine language gave birth to the assembler. The assembler gave birth to the compiler. Now there are ten thousand languages. Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao. But do not program in COBOL, Grasshopper, if you can avoid it.
Grace Hopper: My name isn't Grasshopper, and I will program in whatever I want!
Ezekiel 23:20
As someone who programs professionally in many languages, with about 85% of the last few years at the day job in Python (+ many years with 2 and now 3), I can attest Python has its merits, but elegance is hardly one of them. The language, standard libs, and popular third party tools are among the lower-tier of anything I've ever used.
If we forget all the other faults of python, consistency and predictability are hardly core advantages of python (no, dicts/kwargs/args aren't elegant at all). If we think about other things:
-the package management is atrocious (even with virtualenv), but more a tooling than a language issue you could say
-there still isn't what I would call great IDE support given the limitations of parsing a language like Python
-the language has changed from major versions in some pretty drastic ways, which hardly points to good design overall vs. other languages
-unicode in python 2 wasn't even the default...wtf
-the "flexibility" leads to wildly different ways of handling things
-the back and forth on things like handling lambdas and anonymous functions elegantly over the years is hardly, well, a sign of elegance
-rampant abuse of modules vs. classes
-__init__ is basically a huge wtf
-problems with circular imports
If you want something that is actually elegant, I'd suggest starting with a number of research languages. If you want something that has at least been used in major projects and proven in the field, even if not the most popular, go ahead and give Smalltalk, Lisp, and consequently Clojure a try if you seek elegance. Sorry, but I have to say Python in comparison is a toy compared to any of these languages. I'd gladly shoot the language in its face if it were legal and never wish it on my worse enemy, but hey it's a god send compared to php, perl, and many others so there's at least that.
What I tend to find is that programmers who have never used languages that can handle data structures using the core libraries and syntax of the language are easily impressed. Python list comprehensions are a good example of something that aren't that great, but "wow" if you've never seen anything that can operate on sequence or blocks before. Typically these people were C, C++, PHP, VB, or other programmers. People who worked in Lisp and/or Smalltalk are wondering how other functional, object oriented, and hybrid languages could seriously screw things up so bad when they had the benefit of hindsight.
It's a good lesson, but for different reasons. Here's why.
In the real world, you pick the right tool for the job. You never pick a language because it's the best language. There is no such thing. Factors going into language selection where technical merit plays no role include what the other developers at the company and/or the project are using, what environment you're using (if Apple, then Objective C; if Android, then Java), what language the code you are maintaining was written in 5, 10, 20, or 30 years ago, and (hopefully if you are a great programmer this will be a minor issue) what languages you're comfortable with using.
After 30 years I've learned that basic computer science concepts are helpful, but only to a point. Google may want you to know specifics about certain types of trees for their interview process, but if you need to know that level of detail for a job, you spend a few hours on Google and learn it. The same goes for languages. Figure out what you need with a bit of research before you start the job. You should have a great idea of what environments a language is nearly always used, so you don't try to do something weird nobody can maintain. If you're going to write an iPhone app, you're going to adhere to whatever specific Objective C thing Apple is doing. Maybe I'm slightly out of date and Apple is doing something else, who knows? I don't work in that space.
Python everywhere, be damned with you, is a quick way to make enemies of people 10-20 years down the road who have to maintain your code. I was doing web development in the 1990s, and everybody used Perl. For everything. Now I work with a legacy Perl code base, and mod_perl seems to be completely abandoned, and it certainly hasn't been released for apache httpd 2.4 yet. We're using Perl because we have to, but not for new stuff. But for the Perl part of our system in bug fix maintenance mode, it is the appropriate language. We didn't have the attitude that we'd continue to use Perl for everything just because that's the way things were done. We were flexible enough to slowly switch over to PHP for certain things that we had been using Perl for.
Avoid fads like the plague. After 30 years of programming, I just ignore marketing. I have no gee whiz attitude about anything. I focus on perfecting my craft, learning how to program better, to debug better, to test better. Learning how to deliver code that works now and five years from now. All that is way more important than figuring how how some language is subjectively the best.
Hi everyone. Thanks for all of your comments. I just want to quickly elaborate on why I'm doing this and what I'm trying to do with this project: I am not trying to start a flamewar, annoy programmers, or hog attention. I am not aiming to master any of these languages after only a week. I'm not even trying to get "okay" at any of them. All I'm trying to get out of this project is a more broad understanding of the languages that are out there, and what, in a very general sense, each language is good for. My thought is that if I can get even one cool new idea or concept out of each week's programming language (like functional programming concepts from this week's foray into Haskell), I'll consider this project a success. Also, it will allow me in future to be able to quickly reference a new language if I need it for something I'm working on (not necessarily remember any syntax or anything, but at least to save myself some googling time). Thanks for your interest. Sincerely, Charles Dawson