Slashdot Mirror


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

2 of 232 comments (clear)

  1. Re:"...strengths of certain languages" by Anonymous Coward · · Score: 5, Interesting

    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.

  2. A good lesson by jgotts · · Score: 5, Interesting

    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.