4 ms·

I like what Clojure is trying to do, but comparing languages based purely on LOC is crazy. Its almost like choosing one car over another because the first one

by vineet 14y ago

I like what Clojure is trying to do, but comparing languages based purely on LOC is crazy. Its almost like choosing one car over another because the first one looks better even if it does not have an engine. At the end of the day, languages help you write code. Comparisons on how much time it would take to write the code would be much closer to usefulness and would be interesting (even though they would have also have their own challenges). This would be a really hard test to do in the real world, but I would like to see the code generated by 2 teams over a year - each having 4-5 people and each having similar experiences (ideally 10 years of coding background).

pnathan 14y ago
This is both true and false. LoC is a volume metric. More volume = more things to comprehend. A great example of imperative vs. less-imperative is looping vs mapping. Mapping in Python: foo = map(function, list) vs looping in C++: for(int i = 0; i < list.size(); i++) { foo[i] = function(list[i]; } Note that the C++ version has about 6 choice points where errors can be made (or customized too - it's more flexible than a map)- initialization, comparison, upper bound, increment, lval index, and the rval index. So to grasp the entirety of the loop, you have to examine all 6 things, whereas the map is far simpler. After a while, this simplicity starts to add up. However, LoC is a truly bad metric (other measures are, imo, just as bad), and doesn't really capture what I just said at all. What LoC does capture (as I said above) is volume - the extrinsic complexity of the solution. If you can hone your code so that it simply expresses the intrinsic complexity of the solution, your LoC will decrease to that point. And language helps a great deal. Your point is really well made though: for industrial use you have to have a head to head of expert teams over a reasonable time frame for a reasonably sized system, in reasonably comparable conditions. And yeah, that's the big joke in SW engineering research. It's never really been done and published in any meaningful way. Some companies did do work in that area in the '80s, as I recall - but they didn't publish meaningful datasets as far as my reading shows. Most SW engineering research in this area is very much "small problems" and "students in a class".
- vineet 14y ago
  > More volume = more things to comprehend I disagree. It is not that simple. If volume is similar code, then sure. But if you are talking about different styles of coding then you have a lot of other things to consider. On top of this, if you have a language that has very few underlying primitive (such as parentheses in lisp as opposed to [,;.] in other languages) then you actually have a higher comprehension barrier as the reader will need have to examine the role of the primitive as well. Basically, the terser the language the harder it is comprehend a LOC in that language. On the research note, I do agree that most SW engineering research has focused on 'small problems'.
  - pnathan 14y ago
    I disagree. :-) It is that simple, at base! More stuff = more things to wrap your head around. I posit that a well-written terse solution should say exactly the intrinsic needs of the problem at hand, and no more. The ideal language abstraction would explain exactly what needs to happen and no more. The key forms of the language (macros, functions, etc) should be built up to that point so that it is clear what is going on. There is - in my mind - little difference between (with-open-file (file-stream filename) (do-stuff (read file-stream))) and stuffDoer(fileObject(filename).read()); Both say (to me) exactly the same thing at approximately the same level of abstraction; one does it with Lisp syntax and one in traditional C++ syntax. The question starts to arise after a while - what abstraction tools does the language make available. At what point do you need functions, classes, closures, m4 macros, lisp macros? Well, at the point when you need them. :-) These are all just tools to say exactly what you mean in as much code as you need. If you have a social problem of a bunch of cowboys all whooping it up in your codebase, I don't think any technical solution is going to help you. :-)
    - masklinn 14y ago
      > Both say (to me) exactly the same thing at approximately the same level of abstraction They don't, though: depending on the exact C-style language, you may have leaked a filehandle.
DennisP 14y ago
Code Complete referenced studies saying that programmers write about the same number of lines per day, no matter what the language is. It follows that more concise languages really do translate into faster development.
- vineet 14y ago
  Thanks for the pointer. I appreciate it. I am going to try digging up the reference. I find it hard to believe though. Beyond the code reading challenges that developers have had, I have seen highly varying productivity in code bases that have different amounts of 'brittleness' (and code cycles). On some codebases developers even after understanding what is going on and understanding the change that needs to happen, developers can very easily spend hours making sure a line of code will actually work in different situations.
  - DennisP 14y ago
    Idiomatic clojure does several things to improve matters, like minimizing mutable state, wrapping the remaining mutable state in good concurrency structures, and emphasizing constructs like map and reduce instead of manually looping.

by vineet 14y ago

pnathan 14y ago

This is both true and false. LoC is a volume metric. More volume = more things to comprehend. A great example of imperative vs. less-imperative is looping vs mapping. Mapping in Python: foo = map(function, list) vs looping in C++: for(int i = 0; i < list.size(); i++) { foo[i] = function(list[i]; } Note that the C++ version has about 6 choice points where errors can be made (or customized too - it's more flexible than a map)- initialization, comparison, upper bound, increment, lval index, and the rval index. So to grasp the entirety of the loop, you have to examine all 6 things, whereas the map is far simpler. After a while, this simplicity starts to add up. However, LoC is a truly bad metric (other measures are, imo, just as bad), and doesn't really capture what I just said at all. What LoC does capture (as I said above) is volume - the extrinsic complexity of the solution. If you can hone your code so that it simply expresses the intrinsic complexity of the solution, your LoC will decrease to that point. And language helps a great deal. Your point is really well made though: for industrial use you have to have a head to head of expert teams over a reasonable time frame for a reasonably sized system, in reasonably comparable conditions. And yeah, that's the big joke in SW engineering research. It's never really been done and published in any meaningful way. Some companies did do work in that area in the '80s, as I recall - but they didn't publish meaningful datasets as far as my reading shows. Most SW engineering research in this area is very much "small problems" and "students in a class".

vineet 14y ago
> More volume = more things to comprehend I disagree. It is not that simple. If volume is similar code, then sure. But if you are talking about different styles of coding then you have a lot of other things to consider. On top of this, if you have a language that has very few underlying primitive (such as parentheses in lisp as opposed to [,;.] in other languages) then you actually have a higher comprehension barrier as the reader will need have to examine the role of the primitive as well. Basically, the terser the language the harder it is comprehend a LOC in that language. On the research note, I do agree that most SW engineering research has focused on 'small problems'.
- pnathan 14y ago
  I disagree. :-) It is that simple, at base! More stuff = more things to wrap your head around. I posit that a well-written terse solution should say exactly the intrinsic needs of the problem at hand, and no more. The ideal language abstraction would explain exactly what needs to happen and no more. The key forms of the language (macros, functions, etc) should be built up to that point so that it is clear what is going on. There is - in my mind - little difference between (with-open-file (file-stream filename) (do-stuff (read file-stream))) and stuffDoer(fileObject(filename).read()); Both say (to me) exactly the same thing at approximately the same level of abstraction; one does it with Lisp syntax and one in traditional C++ syntax. The question starts to arise after a while - what abstraction tools does the language make available. At what point do you need functions, classes, closures, m4 macros, lisp macros? Well, at the point when you need them. :-) These are all just tools to say exactly what you mean in as much code as you need. If you have a social problem of a bunch of cowboys all whooping it up in your codebase, I don't think any technical solution is going to help you. :-)
  - masklinn 14y ago
    > Both say (to me) exactly the same thing at approximately the same level of abstraction They don't, though: depending on the exact C-style language, you may have leaked a filehandle.

DennisP 14y ago

Code Complete referenced studies saying that programmers write about the same number of lines per day, no matter what the language is. It follows that more concise languages really do translate into faster development.

vineet 14y ago
Thanks for the pointer. I appreciate it. I am going to try digging up the reference. I find it hard to believe though. Beyond the code reading challenges that developers have had, I have seen highly varying productivity in code bases that have different amounts of 'brittleness' (and code cycles). On some codebases developers even after understanding what is going on and understanding the change that needs to happen, developers can very easily spend hours making sure a line of code will actually work in different situations.
- DennisP 14y ago
  Idiomatic clojure does several things to improve matters, like minimizing mutable state, wrapping the remaining mutable state in good concurrency structures, and emphasizing constructs like map and reduce instead of manually looping.