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

 



Forgot your password?
typodupeerror
Programming

"Clinical Trials" For Programming Languages? 232

Posted by samzenpus
from the apples-and-oranges dept.
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 Anonymous Coward on Monday January 06, 2014 @11:50AM (#45878931)

    long flamewar

  • Simple Answer... (Score:2, Insightful)

    by Anonymous Coward on Monday January 06, 2014 @11:57AM (#45879031)

    ...Some languages are good for some things, and other languages are good for other things. Think LISP.

  • by jdeisenberg (37914) on Monday January 06, 2014 @12:02PM (#45879091) Homepage
    And therein lies the problem of comparisons. An extreme case: a person writing a program that involves concurrency among hundreds of processes will probably be more productive in Erlang than in Perl, but a person writing a program that does massive amounts of text manipulation will be more productive in Perl than in Erlang, because of what the languages were designed for. It's somewhat like asking which is a better tool, a hammer or a screwdriver. A lot of it depends on what you're trying to build.
  • Maintainability? (Score:5, Insightful)

    by cjonslashdot (904508) on Monday January 06, 2014 @12:06PM (#45879139)
    In any such trial, it is important that aspects such as maintainability, reliability and securability be considered. The ability to hack out a-lot of functionality is not the only criteria that is important, unless you are building a home hobby project.
  • by gnasher719 (869701) on Monday January 06, 2014 @12:11PM (#45879191)
    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.
  • by DuckDodgers (541817) <keeper_of_the_wolf@NOSPam.yahoo.com> on Monday January 06, 2014 @12:23PM (#45879351)
    It shouldn't be a flame war. In order to make a meaningful comparison between two programming languages I think you need to have a high level of skill in each, and write two feature-equivalent non-trivial programs in each.

    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.
  • by Savage-Rabbit (308260) on Monday January 06, 2014 @12:36PM (#45879525)

    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.

  • by Connie_Lingus (317691) on Monday January 06, 2014 @12:37PM (#45879535) Homepage

    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.

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

    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.

  • by plover (150551) on Monday January 06, 2014 @12:56PM (#45879721) Homepage Journal

    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.

  • by brausch (51013) on Monday January 06, 2014 @01:36PM (#45880149)

    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.

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

    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.

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

    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.

  • by K. S. Kyosuke (729550) on Monday January 06, 2014 @02:12PM (#45880531)

    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. ;-)

  • by TsuruchiBrian (2731979) on Monday January 06, 2014 @02:35PM (#45880733)
    As someone who pretty much only codes in python lately, I would agree except that I hate the fact that whitespace actually matters in python. I feel that this limits the utility of python while gaining only a modest increase to readability (according to some people).

I don't have any use for bodyguards, but I do have a specific use for two highly trained certified public accountants. -- Elvis Presley

Working...