Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

"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?"
This discussion has been archived. No new comments can be posted.

"Clinical Trials" For Programming Languages?

Comments Filter:
  • by CompSci101 ( 706779 ) on Monday January 06, 2014 @12:06PM (#45879145)

    I have this same problem -- there are a lot of interesting languages out there that I'm interested in trying, but I always keep going back to languages I already know because:

    1. I have work to do; and
    2. it's hard to objectively compare language merits in the short term or for trivial projects.

    I was thinking that the solution to this is to have one program that I understand very well implemented as well and completely as possible in a language that I feel proficient in, and have that be my reference. Then, over the course of a couple of weeks (a month?), re-implement the same program in the new language and strive for the implementation to be as idiomatic of the new language as possible. After all, if you're still thinking in the old language but just using the new one's syntax, what's the point?

    I feel like this would give you a lot of data to make a reasoned decision -- you can compare language features and how the implementation works in one versus the other; time to implementation (LOC, maybe?); how much of a mental shift the new language requires; the toolchain around the new language; etc.

    The problem is figuring out what the reference app is, and having the stomach for implementing it over and over again. Tetris, maybe? ;)

    But, back to the resolution (and partially touched on) -- I don't think a week is enough time. A month is even cutting it close, IMO.


  • by Anonymous Coward on Monday January 06, 2014 @12:52PM (#45879685)

    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.

  • by jbolden ( 176878 ) on Monday January 06, 2014 @01:08PM (#45879843) Homepage

    Terrific suggestion regarding Debian benchmark!

    There are some pretty good stats on productivity from Cocomo II group: http://csse.usc.edu/csse/research/COCOMOII/cocomo_main.html [usc.edu]. First off you measure in terms of normalized lines of code which ends up being close to the same across languages. From there you can examine how large programs are in varieties of languages in terms of normalized lines of code and you get productivity measures:

    Assembly .4
    C 1
    COBOL 1.5
    C# 2.5
    Java 2.5
    Visual Basic 4.5
    Perl 6
    SQL 10


    Perl vs. Python for relatively similar levels of experience I'd assume the differences in productivity is going to be close to 0. You seem to need rather dramatic differences on high/low level scale to get much of a productivity boost. So for example C# and Java are both 2.5; Perl and Smalltak are both 6.

  • Re:Simple Answer... (Score:5, Interesting)

    by RabidReindeer ( 2625839 ) on Monday January 06, 2014 @01:25PM (#45880057)

    PHP is unparalleled for people who want to make a webpage without having to understand HTTP.

    How does knowing HTTP help you at all when making a webpage? I've written my own HTTP server, but that doesn't seem to help my web programming at all.

    You would not believe how many people think that HTTP is just like old-time conversational remote applications programming. They think that once you connect to the server you stay connected and 2-way asynchronous communications are the norm. They don't understand that HTTP is a touch-and-go protocol with a strict 1-1 request/response cycle.

  • by fahrbot-bot ( 874524 ) on Monday January 06, 2014 @01:30PM (#45880115)

    There are good practical reasons for writing the same program in different languages. (1) People often make the same mistakes in the same language, because they are often taught/trained in similar fashions. (2) Different programming languages have different issues and failure modes.

    I'm not an expert, but I worked as an undergraduate research assistant on a project way (way) back in college (1985-87) for a professor on a NASA contract to study issues related to N-version fault tolerance - like used on the Shuttle, where several computers solve the same problems and vote on the answers. One problem (if I remember correctly) was that the different programs, written by different people, in the same, or same type of, language often failed on the same or similar edge cases.

    The experiment was to implement the same solution to a problem using much different languages. In this case, Pascal and Prolog. The "gold" Pascal routine was already written and my task was to write the corresponding "gold" routine in Prolog. [ I also did work for a related study in the automatic analysis (and execution) of abstract data types in LISP.] I graduated before the experiment was run, but found the idea as least plausible.

    Note that I might be remembering some of this incorrectly as it was a while ago and I was only an undergrad. (They wanted a graduate student, but I was the only one with LISP and Prolog experience... And $9.50/hour wasn't bad for 1985.)

  • A good lesson (Score:5, Interesting)

    by jgotts ( 2785 ) <jgotts AT gmail DOT com> on Monday January 06, 2014 @01:59PM (#45880389)

    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.

The meat is rotten, but the booze is holding out. Computer translation of "The spirit is willing, but the flesh is weak."