"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?"

All hail Nebulous!

[Anonymous Coward]

This will make everything clear. [youtube.com]

99 bottles of beer

[jbolden]

There is already a pretty good collection http://www.99-bottles-of-beer.net/ [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/ [sourceforge.net]

it's been tried, but not extensively

[Anonymous Coward]

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 [norvig.com] 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".

Re:Simple Answer...

[plover]

Srsly? Do you know how stupid executives are? "Hey, that web page that my nephew wrote, it does what we need, put it into production." A week later you get this email: "We need you to maintain it - add a loyalty registration page to this thing here, and we're getting complaints about response time..."

What I'm trying to do

[cdawson]

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

Re:"...strengths of certain languages"

[lgw]

I only programmed in Python for about 6 months professionally, but I want to echo the experience. Python blows goats for large projects, for all the reasons mentioned above. Python is awesome for writing small projects (say, a programmer-year or smaller) in a way that's real, maintainable code and not a throw-away script.

Ultimately, I don't think you can have a language that good for both small and large projects. Large projects need structure that just gets in the way for smaller efforts.

Also, I have to agree with the :list comprehension" thing - all modern languages eliminate boilerplate for-loops for list processing (except Java - man I hate Java - but maybe it's better in Java 8?). Even C++11 now has good enough lambda support to get rid of the for loops for containers. Heck, I think even VB got the LINQ extensions that C# did to allow proper list processing.