4 ms·

What that kind of people need to understand is that "code is a liability, not an asset". Every piece of adhoc code is added maintenance cost, hence the less cod

by Apaec 8y ago

What that kind of people need to understand is that "code is a liability, not an asset". Every piece of adhoc code is added maintenance cost, hence the less code the better, no matter the programming language or paradigm.

samontar 8y ago
That’s what I feel too. It’s like in The Goal by Eli Goldratt. The machinery of building product is all cost. Inventory is cost. Machinery is cost. Only finished sold product is revenue. Analogously, code is cost, infra is cost, only our sold product is revenue. A thing I did not understand for a long time is the effect this has on value. Something that produces a low value over a long time may well have been value-negative over the period because of the hidden carrying cost.
plopilop 8y ago
I overall agree but I'd like to add some nuance: one-liners are hella compact but no way near maintainable in many cases. For instance 100% of code golf competition results should never be allowed in production. Also there may be a balance between "some hierarchy in the code so it can evolve" and adhoc code that just works for the current problem. Only having to write a new class for a new feature because everything else is handed smoothly is a bliss.
- bal00ns 8y ago
  I have to agree with this comment. More often than not one-liner rewrites of even trivial functions are unreadable and can't easily be modified, all for the sake of having the appearance of elegance. It's more important to have code that is easily understandable and extendable, which isn't always the case with fewer lines of code. For example I could write a massive list comprehension in Python in one line that could solve my problem, but it would be much more difficult to read and would be a pain to modify. I'd much rather work with the 10 lines of code it would take to actually spell it out.
- Apaec 8y ago
  Wanted to state the main idea first. I definitely agree about one-liners, Perl and APL come to mind. There are some other aspects to this idea of code economy: correctness and reusability. This definitely depends on the programming language. In Java(or oop for that matter) you can get correctness but to get reusability you need a whole hierarchy of classes, lots of added code/cost. In Python you get more reusability out of the box but to get correctness you need to add swaths of unit tests, lots of cost. In contrast with a functional language such as Haskell you get both with less effort, fp plus a rich type system reduce code enourmosly.
  - aldanor 8y ago
    Same with Rust, to some extent -- in some cases it's extremely hard to get a program to compile, fighting with borrow checker along the way, but when it's done and done you can be fairly sure it won't segfault due to a dangling pointer or something stupid of the sort. It also makes it easier for you to trust the code written by others, e.g. when working on a large codebase collaboratively.
    - Apaec 8y ago
      Rust is another favorite of mine, and with Rust you also get efficiency besides correctness and reusability. I wish Rust would have gone with an ML syntax though, in particular the Hindley-Milner type signatures allow me to reason better about code reusability, the "fn" and braces just adds noise to me, too much Haskell I guess.

by Apaec 8y ago

samontar 8y ago

That’s what I feel too. It’s like in The Goal by Eli Goldratt. The machinery of building product is all cost. Inventory is cost. Machinery is cost. Only finished sold product is revenue. Analogously, code is cost, infra is cost, only our sold product is revenue. A thing I did not understand for a long time is the effect this has on value. Something that produces a low value over a long time may well have been value-negative over the period because of the hidden carrying cost.

plopilop 8y ago

I overall agree but I'd like to add some nuance: one-liners are hella compact but no way near maintainable in many cases. For instance 100% of code golf competition results should never be allowed in production. Also there may be a balance between "some hierarchy in the code so it can evolve" and adhoc code that just works for the current problem. Only having to write a new class for a new feature because everything else is handed smoothly is a bliss.

bal00ns 8y ago
I have to agree with this comment. More often than not one-liner rewrites of even trivial functions are unreadable and can't easily be modified, all for the sake of having the appearance of elegance. It's more important to have code that is easily understandable and extendable, which isn't always the case with fewer lines of code. For example I could write a massive list comprehension in Python in one line that could solve my problem, but it would be much more difficult to read and would be a pain to modify. I'd much rather work with the 10 lines of code it would take to actually spell it out.
Apaec 8y ago
Wanted to state the main idea first. I definitely agree about one-liners, Perl and APL come to mind. There are some other aspects to this idea of code economy: correctness and reusability. This definitely depends on the programming language. In Java(or oop for that matter) you can get correctness but to get reusability you need a whole hierarchy of classes, lots of added code/cost. In Python you get more reusability out of the box but to get correctness you need to add swaths of unit tests, lots of cost. In contrast with a functional language such as Haskell you get both with less effort, fp plus a rich type system reduce code enourmosly.
- aldanor 8y ago
  Same with Rust, to some extent -- in some cases it's extremely hard to get a program to compile, fighting with borrow checker along the way, but when it's done and done you can be fairly sure it won't segfault due to a dangling pointer or something stupid of the sort. It also makes it easier for you to trust the code written by others, e.g. when working on a large codebase collaboratively.
  - Apaec 8y ago
    Rust is another favorite of mine, and with Rust you also get efficiency besides correctness and reusability. I wish Rust would have gone with an ML syntax though, in particular the Hindley-Milner type signatures allow me to reason better about code reusability, the "fn" and braces just adds noise to me, too much Haskell I guess.