4 ms·

> I could barely comprehend how little I wrote to get something to work. There's a subset of developers that really fall in love with this idea. I try and unde

> I could barely comprehend how little I wrote to get something to work. There's a subset of developers that really fall in love with this idea. I try and understand where they're coming from but really have a hard time. The more involved with code reviews I've become through my career the more I recoil with fear when I hear this, recalling all the time I spent unbundling nested with nested within nested operations. In the end I believe less LOC as an end goal is largely for the satisfaction of the single engineer writing the code. It feels good at he time. Over time the super compact lines of code decay into hieroglyphics that cast a curse to the unlucky explorer that disturbs their tomb.

deleted 10y ago
[deleted]
Someone 10y ago
One man's hieroglyphics are another man's bread and butter. It is all about shared culture. You don't write empty x repeat a times repeat b times add an item to x count the items in x but the hieroglyphical x = a × b Because "everybody knows what multiplication is". And even the explicit loop has lots of shared culture, for example in the idea what variables are, what a loop is, where it ends, that we do not use × but asterisks for multiplication, etc. Modern languages may require more cultural background, but if that is useful for program comprehension that in itself isn't reason to say that disqualifies them. If it did, we would never have moved towards languages with malloc/free, garbage collection, or classes, the weirdness of IEEE floats, to mention a few things. So, any discussion about new terminology/language constructs should mention costs and benefits. Also, which of them is greater will often depend on the target audience.
pbreit 10y ago
How can you not understand that all things equal, less code is better? Clear and concise code is good. We're not talking about fancy, unintelligible minimizations. Have you coded in Python? Give it a try.
- matt_wulfeck 10y ago
  I'd say that programming languages behave like normal languages and fall under the waterbed affect: if you push the complexity down on one corner then it simply pops up in another corner. The question is which corner do you code for: the corner that develops the code or the corner that maintains it.
SkyMarshal 10y ago
>In the end I believe less LOC as an end goal is largely for the satisfaction of the single engineer writing the code. Fwiw, this is Ada's philosophy - code will be written once but read many times, thus the language should err on the side of clarity and verbosity to facilitate being read, even if at the expense of being written.
tluyben2 10y ago
In theory I agree with this, but in practice it is a bit harder in my experience. To make readable code, it might help if the language itself is readable. But more importantly, the programmer has to write readable code. And that is a skill which takes a lot of time to learn (a lot of people never do) and when they don't, I'm not sure if a readable language matters much at all. Anecdotal, I know, but I see/saw plenty of code written by juniors and/or sweatshops (seniors from sweatshops have a tendency to not progress much in their code writing skills over the years) written in Java, PHP, Python or Ruby which is completely unreadable. And, on the other hand, code written in C, assembly or Forth that is very easy to read even though the languages themselves don't really support traditional 'readable' code. Reading in a natural language is only very little about syntax or strict semantic rules; plenty of novels which are syntactically correct and which follow the semantics of the language but which are 'readable' as per the definition of 'able to read and understand' however which not many people would ever read or finish if they did start. Very terse code which is well written can be beautiful and easy to read; it takes very long to craft code like that in any language but once done, to me at least, it is easy to read and often preferred over reading 'the tech spec' (for which 'shorter is better' is a rule of mine anyway).

deleted 10y ago

[deleted]

Someone 10y ago

One man's hieroglyphics are another man's bread and butter. It is all about shared culture. You don't write empty x repeat a times repeat b times add an item to x count the items in x but the hieroglyphical x = a × b Because "everybody knows what multiplication is". And even the explicit loop has lots of shared culture, for example in the idea what variables are, what a loop is, where it ends, that we do not use × but asterisks for multiplication, etc. Modern languages may require more cultural background, but if that is useful for program comprehension that in itself isn't reason to say that disqualifies them. If it did, we would never have moved towards languages with malloc/free, garbage collection, or classes, the weirdness of IEEE floats, to mention a few things. So, any discussion about new terminology/language constructs should mention costs and benefits. Also, which of them is greater will often depend on the target audience.

pbreit 10y ago

How can you not understand that all things equal, less code is better? Clear and concise code is good. We're not talking about fancy, unintelligible minimizations. Have you coded in Python? Give it a try.

matt_wulfeck 10y ago
I'd say that programming languages behave like normal languages and fall under the waterbed affect: if you push the complexity down on one corner then it simply pops up in another corner. The question is which corner do you code for: the corner that develops the code or the corner that maintains it.

SkyMarshal 10y ago

>In the end I believe less LOC as an end goal is largely for the satisfaction of the single engineer writing the code. Fwiw, this is Ada's philosophy - code will be written once but read many times, thus the language should err on the side of clarity and verbosity to facilitate being read, even if at the expense of being written.

tluyben2 10y ago

In theory I agree with this, but in practice it is a bit harder in my experience. To make readable code, it might help if the language itself is readable. But more importantly, the programmer has to write readable code. And that is a skill which takes a lot of time to learn (a lot of people never do) and when they don't, I'm not sure if a readable language matters much at all. Anecdotal, I know, but I see/saw plenty of code written by juniors and/or sweatshops (seniors from sweatshops have a tendency to not progress much in their code writing skills over the years) written in Java, PHP, Python or Ruby which is completely unreadable. And, on the other hand, code written in C, assembly or Forth that is very easy to read even though the languages themselves don't really support traditional 'readable' code. Reading in a natural language is only very little about syntax or strict semantic rules; plenty of novels which are syntactically correct and which follow the semantics of the language but which are 'readable' as per the definition of 'able to read and understand' however which not many people would ever read or finish if they did start. Very terse code which is well written can be beautiful and easy to read; it takes very long to craft code like that in any language but once done, to me at least, it is easy to read and often preferred over reading 'the tech spec' (for which 'shorter is better' is a rule of mine anyway).