Slashdot Mirror
Rosetta Code Study Weighs In On the Programming Language Debate
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."
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.
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.
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)
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.
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.
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...