Slashdot Mirror

← Back to Stories (view on slashdot.org)

Rosetta Code Study Weighs In On the Programming Language Debate

Posted by Soulskill on from the fresh-ammunition dept.

An anonymous reader writes: Rosetta Code is a popular resource for programming language enthusiasts to learn from each other, thanks to its vast collection of idiomatic solutions to clearly defined tasks in many different programming languages. The Rosetta Code wiki is now linking to a new study that compares programming language features based on the programs available in Rosetta Code. The study targets the languages C, C#, F#, Go, Haskell, Java, Python, and Ruby on features such as succinctness and performance. It reveals, among other things, that: "functional and scripting languages are more concise than procedural and object-oriented languages; C is hard to beat when it comes to raw speed on large inputs, but performance differences over inputs of moderate size are less pronounced; compiled strongly-typed languages, where more defects can be caught at compile time, are less prone to runtime failures than interpreted or weakly-typed languages."

26 of 165 comments (clear)

  1. And? by blueshift_1 · · Score: 2

    So it's telling us just what we already knew? Interesting.

    1. Re:And? by jd · · Score: 5, Funny

      That's the job of consultants.

      --
      It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
    2. Re:And? by Tablizer · · Score: 2

      Sometimes advice carries more weight to the listener if they paid and arm and a leg for it.

      --
      Table-ized A.I.
  2. Who cares about succinctness .... by Squidlips · · Score: 5, Informative

    especially if it makes the code unreadable. Give me the verbose, easy to read code any time. If you really, really want succinctness, use Perl or even better, APL and don't worry about the next poor slob who has to maintain your code.

    1. Re:Who cares about succinctness .... by beelsebob · · Score: 2, Informative

      The problem is that OOP languages rarely have more readable code. Instead, they typically have simply code with more boiler plate.

    2. Re:Who cares about succinctness .... by Theovon · · Score: 2

      Verilog vs. VHDL. I find that the verboseness of VHDL (which requires like 3 times as much typing) actually impedes readability. Sure, there are situations where VHDL can catch a bug at synthesis time that Verilog can't, but the rest of the time, it just makes VHDL unwieldy.

    3. Re:Who cares about succinctness .... by CRCulver · · Score: 2

      Succinctness can supposedly have performance implications in some contexts. I had been away from Python for over a decade before I recently picked up the newest edition of O'Reilly's Learning Python . I was surprised at how many instructions that developers previously spread out over multiple lines are now packed into highly idiomatic one-liners. The author, Mark Lutz, claims in several cases that the Python interpreter is likely to run the one-liner faster (even after it's all been compiled to bytecode) than the traditional multi-line expression.

      Of course, Python's succintness is not Perl's succintness, but it can take people a long time to get up to speed with what now seems the expected idiom, and there's plenty of room for producing something that other eyes will find baffling.

    4. Re:Who cares about succinctness .... by Chris+Mattern · · Score: 2

      Poorly done, cryptic succinctness can indeed make code impenetrable. Yet overdone verbosity can destroy readability just as thoroughly. When the language is naturally succinct, it's easy to ensure that it contains enough context to be readable. When the language is overly verbose, you generally can't slim it back down to readable conciseness.

    5. Re:Who cares about succinctness .... by sycodon · · Score: 3, Interesting

      You jest, but the majority of large, mission critical systems...payroll, point of sale, etc. are in COBOL...

      When it's got to work, work all the time, handle million and millions of records, and can be maintained by college graduates, COBOL is the way to go.

      --
      When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
    6. Re:Who cares about succinctness .... by Tablizer · · Score: 3, Insightful

      Depends on the reader. Anyhow, coding is the art of balancing trade-offs among many factors, but readability by an average programmer (future maintainer) should be among the top priorities. It's best to learn what code style is the easiest for a random programmer to digest.

      Too much abstraction and factoring can sometimes throw readers off, I hate to say. Those who personally enjoy making "symbolically optimized" code don't like to hear that, but one is not coding on an island, but rather in the City of Fungible Cubicles.

      --
      Table-ized A.I.
    7. Re:Who cares about succinctness .... by sycodon · · Score: 2

      So that's a great big Nuh Uh! from you then?

      Perhaps in small business applications you may be right. But the Big Guys...National Banks, large aerospace, etc. COBOL runs the core systems.

      And I'd choose COBOL for reliability and maintainability anytime.

      --
      When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
    8. Re: Who cares about succinctness .... by Warbothong · · Score: 2

      You're saying you only write raw pedestrian code with NO layering? I have only ever seen that in CS 101.

      No, the point is that (pure) functional programming forces a separation between "actions", which may affect something in the program (eg. a global), in the computer (eg. a file) or in the outside world (eg. play a sound), from "computations", which can *only* return a value based on the given arguments.

      This separation makes it easy to understand computations: arguments go in, return value comes out and *that's it*. In turn, this makes it safe to work at very high levels of abstraction (Monoids, Monads, Categories, etc.), since we don't care whether some function will be called or not, or what order stuff happens in, or how many times something gets called: the *only* possible thing that can happen is we get a return value.

      Most languages, OOP included, don't make such a separation. An innocent-looking call like "getUserId" may in fact call out to a database, cache files to disk, obtain a lock and send some emails, which are all things we have to keep in mind whenever we try to call that function.

      Actions in functional programming are just as dangerous as things like "getUserId", but they tend to be much smaller. For example, we might write all of a program's logic in a bunch of complicated computations, which ultimately takes a string as an argument and returns another string. We might then have a single, tiny action which reads a string from a file, passes it to our pure computation, then writes the result to stdout.

    9. Re:Who cares about succinctness .... by morgauxo · · Score: 2

      I think it depends more on the coder. Spaghetti code can be written in any language. Good, readable code can be written in almost any language (not sure about Brainfuck). Some languages go farther to force the user to write good code than others but it's still a choice.

    10. Re:Who cares about succinctness .... by jbolden · · Score: 2

      Functional code can't be maintained immediately by the random programmer. They need to learn concepts first. That's also true of languages which are tightly coupled to hardware, languages which are tied tightly to databases or BI tools or languages which uses other conceptual frameworks like logic programming. Everyone learns: do X then do Y when they are a toddler.

    11. Re:Who cares about succinctness .... by steveha · · Score: 2

      I was surprised at how many instructions that developers previously spread out over multiple lines are now packed into highly idiomatic one-liners.

      As with many things, Python one-liners can be good or bad. When done correctly they are awesome.

      Consider this code:

      bad = any(is_bad_word(word) for word in words_in(message))

      If words_in() is a generator that yields up one word at a time from the message, and is_bad_word() is a function that detects profanity or other banned words, then this one-liner checks to see if any word in a message is a bad word.

      I love the any() and all() built-in functions in Python.

      You can take this too far. Instead of defining a function is_bad_word() you could put the code inline as part of the on-liner. And instead of defining a generator that yields up one word at a time, you could add the splitting code to the one-liner. Then you would get:

      bad = any(word in bad_words_list for line in message for word in line.split())

      Or let's say the definition of a bad word is that any substring in the word is from the bad list (thus "frakking" is a bad word if "frak" is in the bad list), with it inline you get:

      bad = any(any(bad_word in word for bad word in bad_words_list) for line in message for word in line.split())

      I think we can all agree that the above is horrible, but I hope you will agree that the first one was pretty nice.

      --
      lf(1): it's like ls(1) but sorts filenames by extension, tersely
  3. Compiled Strongly-typed Languages -vs- Scripts by Anonymous Coward · · Score: 5, Insightful

    The difference, as the summary noted, is that when using a scripted-language, you are trading all your compile-time (build breaks) for runtime errors that your users will see.

    If you write 'C' code, would you declare all your input and output return types as 'void*'?
    If you write 'Java' code, would you declare all your input and output return types as 'Object'?

    Why someone would willingly give up the function of a compiler is beyond me. Sure, use scripts for little tasks / prototyping etc. Any long-term project should be using a proper language, that provides type-checking (at compile time), and provides proper encapsulation so that 'private' means 'private' (looking at your Groovy). I don't want to be forced to read every line of your crappy code, just to try to figure out what object-type your method supports because you are too damn lazy to define it in the method's interface.

    When you change the behavior of the method and assume different input/output object-types, I want that to be a BUILD-BREAK instead of me once again having to reverse engineer your code.

  4. Re:Machine specific by i+kan+reed · · Score: 3, Interesting

    Pragmatically, almost no one actually codes software with that aspect of the target platform in mind. Unless you're writing drivers, OSes or something else that might need to know EXACTLY how many cycles an op is going to take, your cache behavior, e.g. is never going to be part of what you're building your code around.

    And RAM sizes are large enough that a "large" input is easily contained entirely within even smallish RAM.

    As long as they used a consistent testbed between languages, it's an excellent heuristic for language effects on performance in the real world.

  5. "Scripting" langs are functional, OO, procedural by mr_mischief · · Score: 4, Informative

    Simply because a language is billed as a "scripting" language (by which people tend to mean distributed as source code and partially compiled for each execution rather than compiled once and distributed as object code rather than actually used primarily to script other programs) doesn't mean there's no programming paradigm associated with them. They can support procedural, functional, actor-based, object-oriented, logical, dataflow, reactive, late binding, iteration, recursion, concurrency, and whatever other paradigms and methods people want. Some of them support mixing and matching even in the same program.

    Languages that are typically fully compiled can even be run in an interpreter. C-- comes to mind. Often languages known for interpretation (actually most of which are partially compiled rather than interpreted line-by-line) have support for compiling at least portions of a program up front, too. Examples include the .pyc files of Python, luajit, Facebook's HHVM, Steelbank Common Lisp, and Reini Urban's work on perlcc.

    People making claims about one type of language vs. another should really keep straight what types they are talking about.

  6. Re:Confirming the obvious. by iggymanz · · Score: 2

    Not obvious at all that C is hard to beat on raw speed on large inputs. Fortran and COBOL and Forth do that.

  7. Re:Machine specific by Penguinisto · · Score: 2

    And RAM sizes are large enough that a "large" input is easily contained entirely within even smallish RAM.

    /old-man mode: ...and this is EXACTLY what's wrong with programmers today! No eye for efficiency! :old-man mode/

    Cue endless round of arguments about how so-and-so wrote an app that only used one bit of RAM to execute four jobs, yeah - but in all seriousness, the attitude of 'RAM is cheap' has done more to create bloat than any other.

    --
    Quo usque tandem abutere, Nimbus, patientia nostra?
  8. Re:C++ = Clear Language Choice. by Warbothong · · Score: 3, Interesting

    Sincere question - I've heard that Fortran blows away (or at least beats) C++ for scientific/calculation programming... can you lend any insight into what accounts for that, specifically?

    http://stackoverflow.com/quest...

  9. Re:Machine specific by chuckugly · · Score: 2

    And a cache miss costs ~200 clock cycles.

    Size isn't the only thing, locality of reference is just as big or bigger and languages like C/C++ allow a programmer to think about and control such things. With everything being powered by batteries now being efficient isn't something we want to always just throw more hardware at, although such a phone might be more resistant to bending.

  10. Mickey mouse tests by Alomex · · Score: 2

    If I understand the statistics correctly the average program has 71 lines of code. Those are mickey mouse tests for which scripting languages shine. All the verbosity of imperative languages becomes handy when you have tasks that are a few 100KLC long.

    This is a lesson Perl learned the hard way: once your program is long enough you beg in your knees for strong static type checking system.

  11. Re:Machine specific by K.+S.+Kyosuke · · Score: 2

    Norvig says you should know these things even today. ;-)

    --
    Ezekiel 23:20
  12. Re:Machine specific by K.+S.+Kyosuke · · Score: 2

    That's not about pitfalls of OOP, that's about pitfalls of OOP in C++ :-p

    --
    Ezekiel 23:20
  13. Grand Tradeoff [Re:Compiled Strongly-typed Languag by Tablizer · · Score: 2

    In my opinion the basic trade-off is that "scriptish" languages can be written to be closer to pseudo-code and thus easier to read and grok. Strong/heavy typing tends to be verbose and redundant, slowing down reading.

    Better grokkability often means less "conceptual" errors, but at the expense of more "technical" errors, such as type mismatches. There's no free lunch, only trade-offs.

    In some projects the conceptual side overpowers the technical-error side, and vice verse. It also depends on the personality of the coder or team.

    --
    Table-ized A.I.