"Clinical Trials" For Programming Languages? 232
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?"
That is a beautiful start of a ... (Score:5, Insightful)
long flamewar
Simple Answer... (Score:2, Insightful)
...Some languages are good for some things, and other languages are good for other things. Think LISP.
"...strengths of certain languages" (Score:5, Insightful)
Maintainability? (Score:5, Insightful)
Languages for professionals (Score:5, Insightful)
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.
Re:That is a beautiful start of a ... (Score:5, Insightful)
Most of the flame wars are between people who don't have good expertise in at least one of the languages under discussion, arguing about merits and drawbacks in simple programs.
I think what Charles Dawnson plans will be interesting, educational, and fun, but you can't become good enough in a language in a week to have a useful opinion on its effectiveness at creating the next social network, operating system kernel, C compiler, web browser, search engine or office suite.
Re:99 bottles of beer (Score:5, Insightful)
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]
Where performance is concerned I'd go for something like the Debian Benchmarks game. The time taken for this benchmark task, by this toy program, with this programming language implementation, with these options, on this computer, with these workloads. With enough people participating in the pissing contest you eventually get things optimized to hell and the wheat is separated from the chaff.
http://benchmarksgame.alioth.debian.org/ [debian.org]
http://benchmarksgame.alioth.debian.org/play.php [debian.org]
As for productivity, that's harder since this is highly subjective. While you can generally postulate that coding in non typed scripting languages where you don't have to worry about memory management is going to be faster than coding in a typed, manually memory managed language like C. But what happens when you compare more similar languages like Python vs. Perl? Your productivity in a language is highly dependent on your experience with it, how fast you are at typing, how intuitive the syntax is to you.... etc... But different programmers can have different issues with languages. In Perl for example the syntactic freedom can actually lead some programmers to write bugs bugs into their code because they are used to languages with a more nailed down syntax.
aren't i so damn trendy? (Score:5, Insightful)
it's my observation that programming languages have become the equivalent of fashion and bands.
it's as if choosing and using one is like saying "oh, im listening to arctic monkeys and calvis harris these days, and that makes me feel liberated from those plebs still listening to kings of leon and david guetta..and MAYBE if im lucky someone will be impressed by my trendiness"...now that so many 20-somethings code, they all seem to feel the need to break from the "boring old bonds" of existing languages and define themselves among their peers by how esoteric their language-de-jour is.
what this guy is doing is illustrating the point, he isn't going to learn anything about the benefits of each "language" or how to maximize productivity...it's just a "notice me notice me" stunt.
it's just a silly exercise in syntax-swapping anyway for 90% of it...
please don't get me wrong...it's totally fine by me whatever language you want to use, as long as it's maintainable and there is a large enough pool of existing programmers who know the language so when you leave my company because your bored with maintaining the code you wrote, i can find someone quickly and affordably to replace you.
Re:Simple Answer... (Score:3, Insightful)
Why kidding? That is one of the strongest points for PHP and VB. Those are languages that you should recommend to someone who wants to write something without learning how to program.
Sure, the result isn't something you should take to production but any programmer who deals with people who doesn't program knows that there aren't a shortage of ideas that it would be wasteful for a programmer to implement.
I think that the support to throw quickly throw together unmanageable crap is a bit under-appreciated among programmers. Sometimes a program is only meant to be ran once.
Re:99 bottles of beer (Score:5, Insightful)
Productivity is a tough one, but it's by far the most important. That's what we get paid for.
A good competition might be to start with a functional test, and just let developers "swing away" at it. Or you might add real world constraints that development organizations want to see, such as requiring 95%+ code coverage with unit tests, keeping complexity below 12, and it must pass lint / pmd / fxcop / other static code analysis tool with no warnings or errors. Maybe it has to pass a code review, too. The functional test would have to pass ensuring it does what it's supposed to do, and maybe it would need to pass a fuzz test to ensure it doesn't break under strain.
And you would need to run different contests for different categories: web apps, services, operating systems, embedded systems, phone apps, etc. Not all problems are created equal.
Re:That is a beautiful start of a ... (Score:5, Insightful)
The real problem is that different languages are often created to solve different problems. You can't really compare them very easily with any single program, no matter what non-trivial program that you use. For example, C is a better programming language than Javascript for some problems; Javascript might be better than C for some other problems.
I'm advanced to expert in about six languages and have decent experience in a dozen others. I've settled on about four that I use a lot, and that fit the kinds of problems that I work on. Other equally skilled and experienced programmers (programming for over 40 years) would choose a different set of languages better suited to solving the problems they routinely work on.
It's kind of like trying to compare the toolbox of a plumber with the toolbox of a mechanic. There is overlap of course but there are also specialized tools.
Re:it's been tried, but not extensively (Score:4, Insightful)
As contrasted with Java? Unless you want something that is really in Java's forte (i.e. working the a Java library) I'd be hard pressed to see where LISP is likely to lose.
Now the issue of course is as the number of programmers increases LISP's idiosyncratic behaviors and allowing each developer to express their individuality go from huge advantages to huge disadvantages. At a million+ lines of code Java's maintainability and standardization become key features. But at say 20-10,000 I'm hard pressed to see much that LISP wouldn't win at.
Re:Live and don't learn (Score:4, Insightful)
Because the productivity doesn't scale well as projects get larger. Dynamic languages are amazing at 20 line programs. They are pretty hot at 200 lines programs. At 2000 lines you are starting to feel the minus but they still work well. At 20,000 things start going badly wrong. By 2m, well there are 2m line programs mostly because all those things that are good about a dynamic language for 20 lines turn into disadvantages when you need hundreds of programmers to work together.
Re:Simple Answer... (Score:4, Insightful)
They think that once you connect to the server you stay connected and 2-way asynchronous communications are the norm.
That's what WebSockets are for, after all. ;-)
Re:All hail Python! (Score:5, Insightful)