3 ms·

> I eventually decided that short code is better than readable code because the shortness of code is objectively measurable I can debug sophisticated algorith

> I eventually decided that short code is better than readable code because the shortness of code is objectively measurable I can debug sophisticated algorithms code that is readable and explicit far more easily than short and concise. Anyone that tells you otherwise has never had to debug the legacy optimization algorithms of yesteryear (nor have they seen the ample amount of nested parens that comes from a bullshit philosophy of keeping the code as short as possible).

heavenlyblue 8y ago
All arguments about computer languages will always end up in disagreement, since every person in that argument does programming in an entirely different context. Short is good when the average half-life of your code is less than a month. When you're writing something for 10 years and beyond - it makes sense to have something incredibly sophisticated and explicit. Otherwise it doesn't since the amount of time it takes me to comprehend all of the assumptions you made in all of those nested for loops is probably longer that the lifetime of the code in production. List comprehension has a nice, locally-defined property in python: it will always terminate.
- ethbro 8y ago
  Obligatory Dijkstra: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
  - catnaroek 8y ago
    That's actually Brian Kernighan. Dijkstra would have never advocated debugging to begin with.
- joshuamorton 8y ago
  Only if you iterate over a fixed-length iterable. [x for x in itertools.count()] will never terminate.
  - heavenlyblue 8y ago
    It will terminate as soon as it runs out of memory.
    - joshuamorton 8y ago
      By this definition, python has a nice locally defined property that it will always terminate ;)
      - heavenlyblue 8y ago
        No; this will never-ever terminate: (x for x in itertools.count())

heavenlyblue 8y ago

All arguments about computer languages will always end up in disagreement, since every person in that argument does programming in an entirely different context. Short is good when the average half-life of your code is less than a month. When you're writing something for 10 years and beyond - it makes sense to have something incredibly sophisticated and explicit. Otherwise it doesn't since the amount of time it takes me to comprehend all of the assumptions you made in all of those nested for loops is probably longer that the lifetime of the code in production. List comprehension has a nice, locally-defined property in python: it will always terminate.

ethbro 8y ago
Obligatory Dijkstra: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
- catnaroek 8y ago
  That's actually Brian Kernighan. Dijkstra would have never advocated debugging to begin with.
joshuamorton 8y ago
Only if you iterate over a fixed-length iterable. [x for x in itertools.count()] will never terminate.
- heavenlyblue 8y ago
  It will terminate as soon as it runs out of memory.
  - joshuamorton 8y ago
    By this definition, python has a nice locally defined property that it will always terminate ;)
    - heavenlyblue 8y ago
      No; this will never-ever terminate: (x for x in itertools.count())