3 ms·

Hold on there. Gzipped source is a terrible metric. It would undercount duplicate code, the worst kind of program bloat. Not that I'm defending LOC. If one has

by gruseom 17y ago

Hold on there. Gzipped source is a terrible metric. It would undercount duplicate code, the worst kind of program bloat. Not that I'm defending LOC. If one has to count something, counting tokens seems less susceptible to noise.

jacquesm 17y ago
That's the whole point. Even if you program in a 'sloppy' way the gzip algorithm will see that and reduce accordingly so you are comparing the languages, not the programmers stylistic elements. Besides, the article talks about implementing the same algorithm twice in different languages, if you went about that in a completely different way then that would of course be problematic. But when comparing the expressiveness between two languages you'd assume the same major structures would be present.
- nostrademons 17y ago
  Except that some languages encourage sloppy programming. Haven't you ever looked at some Java code where two (or more!) functions do exactly the same thing except that the types are different? GZip would compress that down to almost nothing, but you still have to deal with the complexity, maintenance burden, and API bloat of having multiple versions. It also doesn't account for language misfeatures that introduce significant additional cognitive burden for the programmer but don't appear much in source code. For example, manual memory management in C++ results in a bunch of "delete x" calls in code, which would get GZipped down to very little, but impose a very high cognitive cost on the programmer. PHP's inconsistency in argument order doesn't show up at all in code length, but also presents a big cognitive tax that sends you back to the reference manual all the time. Personally, I think that the best metric of language productivity is "The amount of information you have to keep in your head in order to write code as fast as you can type." Unfortunately, that's nearly impossible to measure.
  - jacquesm 17y ago
    Doesn't that suggest that such code 'bloat' is actually less important than people make it seem ? After all, there is not much to remembering that two functions exist for the same type, it's not like you have to remember that there is something 'completely' new, just a routing that is almost the same as another.
    - gruseom 17y ago
      If you're right, then there isn't much value in abstracting over repetitive patterns. I'd say that is pretty decisively contradicted by the history of software. Why have functions at all then?
      - jacquesm 17y ago
        Because it saves space and because it makes maintenance easier, and it allows you to label a block of code with a meaningful name. Caching also means that if you execute less code you will have better performance. The actual instructions can be interpreted serially, in fact when you're 'desk checking' that is exactly what you do, to unwind the way the code is written to the serial stream that the processor is executing.

by gruseom 17y ago

jacquesm 17y ago

That's the whole point. Even if you program in a 'sloppy' way the gzip algorithm will see that and reduce accordingly so you are comparing the languages, not the programmers stylistic elements. Besides, the article talks about implementing the same algorithm twice in different languages, if you went about that in a completely different way then that would of course be problematic. But when comparing the expressiveness between two languages you'd assume the same major structures would be present.

nostrademons 17y ago
Except that some languages encourage sloppy programming. Haven't you ever looked at some Java code where two (or more!) functions do exactly the same thing except that the types are different? GZip would compress that down to almost nothing, but you still have to deal with the complexity, maintenance burden, and API bloat of having multiple versions. It also doesn't account for language misfeatures that introduce significant additional cognitive burden for the programmer but don't appear much in source code. For example, manual memory management in C++ results in a bunch of "delete x" calls in code, which would get GZipped down to very little, but impose a very high cognitive cost on the programmer. PHP's inconsistency in argument order doesn't show up at all in code length, but also presents a big cognitive tax that sends you back to the reference manual all the time. Personally, I think that the best metric of language productivity is "The amount of information you have to keep in your head in order to write code as fast as you can type." Unfortunately, that's nearly impossible to measure.
- jacquesm 17y ago
  Doesn't that suggest that such code 'bloat' is actually less important than people make it seem ? After all, there is not much to remembering that two functions exist for the same type, it's not like you have to remember that there is something 'completely' new, just a routing that is almost the same as another.
  - gruseom 17y ago
    If you're right, then there isn't much value in abstracting over repetitive patterns. I'd say that is pretty decisively contradicted by the history of software. Why have functions at all then?
    - jacquesm 17y ago
      Because it saves space and because it makes maintenance easier, and it allows you to label a block of code with a meaningful name. Caching also means that if you execute less code you will have better performance. The actual instructions can be interpreted serially, in fact when you're 'desk checking' that is exactly what you do, to unwind the way the code is written to the serial stream that the processor is executing.