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