9 ms·

> who was writing the most code There's yer problem right there. Code quantity is not correlated with value. In fact, it can be negatively correlated with va

by lisper 2y ago

> who was writing the most code There's yer problem right there. Code quantity is not correlated with value. In fact, it can be negatively correlated with value if it's buggy and laden with technical debt. Measuring productivity by lines of code produced actively discourages writing clean, maintainable, bug-free code.

thesuperbigfrog 2y ago
> Code quantity is not correlated with value. In fact, it can be negatively correlated with value if it's buggy and laden with technical debt. ** "No Code" or Nihilist Software Engineering ** No code runs faster than no code. No code has fewer bugs than no code. No code uses less memory than no code. No code is easier to understand than no code. No code is the best way to have secure and reliable applications. Write nothing; deploy nowhere. One of my most productive days was throwing away 1,000 lines of code. -- Ken Thompson The cheapest, fastest, and most reliable components are those that aren’t there. -- Gordon Bell Deleted code is debugged code. -- Jeff Sickel Measuring programming progress by lines of code is like measuring aircraft building progress by weight. -- Bill Gates * Master Foo and the Ten Thousand Lines * Master Foo once said to a visiting programmer: “There is more Unix-nature in one line of shell script than there is in ten thousand lines of C.” The programmer, who was very proud of his mastery of C, said: “How can this be? C is the language in which the very kernel of Unix is implemented!” Master Foo replied: “That is so. Nevertheless, there is more Unix-nature in one line of shell script than there is in ten thousand lines of C.” The programmer grew distressed. “But through the C language we experience the enlightenment of the Patriarch Ritchie! We become as one with the operating system and the machine, reaping matchless performance!” Master Foo replied: “All that you say is true. But there is still more Unix-nature in one line of shell script than there is in ten thousand lines of C.” The programmer scoffed at Master Foo and rose to depart. But Master Foo nodded to his student Nubi, who wrote a line of shell script on a nearby whiteboard, and said: “Master programmer, consider this pipeline. Implemented in pure C, would it not span ten thousand lines?” The programmer muttered through his beard, contemplating what Nubi had written. Finally he agreed that it was so. “And how many hours would you require to implement and debug that C program?” asked Nubi. “Many,” admitted the visiting programmer. “But only a fool would spend the time to do that when so many more worthy tasks await him.” “And who better understands the Unix-nature?” Master Foo asked. “Is it he who writes the ten thousand lines, or he who, perceiving the emptiness of the task, gains merit by not coding?” Upon hearing this, the programmer was enlightened. Source: http://www.catb.org/~esr/writings/unix-koans/ten-thousand.html http://www.catb.org/~esr/writings/unix-koans/ten-thousand.ht...
- musicale 2y ago
  Unix-nature loves malicious argument and code injection vulnerabilities, while C brings its own set of issues such as buffer overflows.
  - gowld 2y ago
    Are you referring to bash when you say Unix-nature? Bash and C are both old and flawed early implementations that brought great ideas. Bash can be replaced by a much safer language that retains its shell nature (easily able to weave together many Unix programs).
    - musicale 2y ago
      I was replying to GP. You could certainly replace bash and traditional Unix shells with something else. My favorite attempt is scsh (though mainly for the "acknowledgements" section of its reference manual.) But I'm in favor of a Unix/Linux command shell and scripting language that has type and taint checking for command arguments, and which differentiates between code and data. Typed data pipes could be nice as well. However, Unix/Linux isn't (yet) designed for those features. For example exec() doesn't type check command arguments.
- trelane 2y ago
  This is an amazing collection. Thanks for it. It's is exactly what I was needing for this slide deck on I'm writing how to improve our code.
  - slowtrek 2y ago
    a) Would make a great coffee table book. b) Would make a great poster.
- btilly 2y ago
  The author of the shell script was probably Doug McIlroy. See www.leancrew.com/all-this/2011/12/more-shell-less-egg/ for more.
psychoslave 2y ago
Turning a 100+ lines function of 5+ intertwined control flow mess into a single expression using a combination of method chaining of just a few lines is always a delighting experience to my mind.
- lodovic 2y ago
  Until a coworker needs to debug a specific edge case that was too specific for the single expression, and it all has to be rewritten back to long form. Dense code is not always better and sometimes makes a code base incomprehensable.
  - rightbyte 2y ago
    Single use long functions are great for debuggability and following the code path. Injection or whatever fancy term used for passing function pointers around is ofent write only.
    - psychoslave 2y ago
      If the function is long, accumulate variable along the way, and open intertwined control flow every three lines, no a single function is not at all a scalable way to expose a construction involving many transformations and sources and debugging will be as hard as the control follow depth times number of stacked variable so far as it's stepped through. With method chaining at each step you have only the complexity of the current method inputs to deal with: that's a far better noise/signal ratio.
  - LandR 2y ago
    I've experienced this watching a coworker debugging that sort of code, he had initially written it all as a long chained statements, then had to undo it all to allow him to debug. Once it was extracted it could be debugged and step through it, great! Once he was done debugging it he put it all back to how it was originally... The mind boggles.
    - 2y ago
vezcha 2y ago
code is liability for both the business and the thinker at the end of the day. It's worth it to spend as much time as possible figuring out how to avoid writing it and keep it minimalized.
jimbokun 2y ago
I’m getting a similar sense from many of the AI “success” stories we’ve been hearing. There’s amazement about how many lines of code the AI produces in a short amount of time. But not so much about maintaining and debugging all those lines of code once they’re created.
- giantrobot 2y ago
  But the code runs great, over a hundred transactions per minute! All on just a $750 a day AWS instance! Saved so much money on those expensive developers! /s Math left as an exercise for the reader.
  - fakedang 2y ago
    Well 750 a day times 365 comes out to 275k, which is still lower than a couple of Bay Area devs' salaries. That being said, I've found AI to be quite powerful given that I already know what infra I'm planning to use and restricting it to use only those tools and services.

by lisper 2y ago

thesuperbigfrog 2y ago

> Code quantity is not correlated with value. In fact, it can be negatively correlated with value if it's buggy and laden with technical debt. ** "No Code" or Nihilist Software Engineering ** No code runs faster than no code. No code has fewer bugs than no code. No code uses less memory than no code. No code is easier to understand than no code. No code is the best way to have secure and reliable applications. Write nothing; deploy nowhere. One of my most productive days was throwing away 1,000 lines of code. -- Ken Thompson The cheapest, fastest, and most reliable components are those that aren’t there. -- Gordon Bell Deleted code is debugged code. -- Jeff Sickel Measuring programming progress by lines of code is like measuring aircraft building progress by weight. -- Bill Gates * Master Foo and the Ten Thousand Lines * Master Foo once said to a visiting programmer: “There is more Unix-nature in one line of shell script than there is in ten thousand lines of C.” The programmer, who was very proud of his mastery of C, said: “How can this be? C is the language in which the very kernel of Unix is implemented!” Master Foo replied: “That is so. Nevertheless, there is more Unix-nature in one line of shell script than there is in ten thousand lines of C.” The programmer grew distressed. “But through the C language we experience the enlightenment of the Patriarch Ritchie! We become as one with the operating system and the machine, reaping matchless performance!” Master Foo replied: “All that you say is true. But there is still more Unix-nature in one line of shell script than there is in ten thousand lines of C.” The programmer scoffed at Master Foo and rose to depart. But Master Foo nodded to his student Nubi, who wrote a line of shell script on a nearby whiteboard, and said: “Master programmer, consider this pipeline. Implemented in pure C, would it not span ten thousand lines?” The programmer muttered through his beard, contemplating what Nubi had written. Finally he agreed that it was so. “And how many hours would you require to implement and debug that C program?” asked Nubi. “Many,” admitted the visiting programmer. “But only a fool would spend the time to do that when so many more worthy tasks await him.” “And who better understands the Unix-nature?” Master Foo asked. “Is it he who writes the ten thousand lines, or he who, perceiving the emptiness of the task, gains merit by not coding?” Upon hearing this, the programmer was enlightened. Source: http://www.catb.org/~esr/writings/unix-koans/ten-thousand.html http://www.catb.org/~esr/writings/unix-koans/ten-thousand.ht...

musicale 2y ago
Unix-nature loves malicious argument and code injection vulnerabilities, while C brings its own set of issues such as buffer overflows.
- gowld 2y ago
  Are you referring to bash when you say Unix-nature? Bash and C are both old and flawed early implementations that brought great ideas. Bash can be replaced by a much safer language that retains its shell nature (easily able to weave together many Unix programs).
  - musicale 2y ago
    I was replying to GP. You could certainly replace bash and traditional Unix shells with something else. My favorite attempt is scsh (though mainly for the "acknowledgements" section of its reference manual.) But I'm in favor of a Unix/Linux command shell and scripting language that has type and taint checking for command arguments, and which differentiates between code and data. Typed data pipes could be nice as well. However, Unix/Linux isn't (yet) designed for those features. For example exec() doesn't type check command arguments.
trelane 2y ago
This is an amazing collection. Thanks for it. It's is exactly what I was needing for this slide deck on I'm writing how to improve our code.
- slowtrek 2y ago
  a) Would make a great coffee table book. b) Would make a great poster.
btilly 2y ago
The author of the shell script was probably Doug McIlroy. See www.leancrew.com/all-this/2011/12/more-shell-less-egg/ for more.

psychoslave 2y ago

Turning a 100+ lines function of 5+ intertwined control flow mess into a single expression using a combination of method chaining of just a few lines is always a delighting experience to my mind.

lodovic 2y ago
Until a coworker needs to debug a specific edge case that was too specific for the single expression, and it all has to be rewritten back to long form. Dense code is not always better and sometimes makes a code base incomprehensable.
- rightbyte 2y ago
  Single use long functions are great for debuggability and following the code path. Injection or whatever fancy term used for passing function pointers around is ofent write only.
  - psychoslave 2y ago
    If the function is long, accumulate variable along the way, and open intertwined control flow every three lines, no a single function is not at all a scalable way to expose a construction involving many transformations and sources and debugging will be as hard as the control follow depth times number of stacked variable so far as it's stepped through. With method chaining at each step you have only the complexity of the current method inputs to deal with: that's a far better noise/signal ratio.
- LandR 2y ago
  I've experienced this watching a coworker debugging that sort of code, he had initially written it all as a long chained statements, then had to undo it all to allow him to debug. Once it was extracted it could be debugged and step through it, great! Once he was done debugging it he put it all back to how it was originally... The mind boggles.
  - 2y ago

vezcha 2y ago

code is liability for both the business and the thinker at the end of the day. It's worth it to spend as much time as possible figuring out how to avoid writing it and keep it minimalized.

jimbokun 2y ago

I’m getting a similar sense from many of the AI “success” stories we’ve been hearing. There’s amazement about how many lines of code the AI produces in a short amount of time. But not so much about maintaining and debugging all those lines of code once they’re created.

giantrobot 2y ago
But the code runs great, over a hundred transactions per minute! All on just a $750 a day AWS instance! Saved so much money on those expensive developers! /s Math left as an exercise for the reader.
- fakedang 2y ago
  Well 750 a day times 365 comes out to 275k, which is still lower than a couple of Bay Area devs' salaries. That being said, I've found AI to be quite powerful given that I already know what infra I'm planning to use and restricting it to use only those tools and services.