3 ms·

> 4. The best code is no code, or code you don’t have to maintain > 17. Keep your processes as lean as possible > 20. Always strive to build a smaller system

> 4. The best code is no code, or code you don’t have to maintain > 17. Keep your processes as lean as possible > 20. Always strive to build a smaller system He stops just short of saying it, but IMO a program with fewer lines of code is almost always better. You can write your Java in Python and have it be 1/5th the lines. You can drop the classes and use functions and save some lines. Exceptions to this rule only happen because lines of code isn't an infallible measure of "size" or complexity. > Project size is easily the most significant determinant of effort, cost and schedule https://blog.codinghorror.com/diseconomies-of-scale-and-lines-of-code/ https://blog.codinghorror.com/diseconomies-of-scale-and-line... This comes to mind after having written some short pieces of code which get "improved" by others. But all they did was move things into different files and turn some functions into classes. As though what makes good code is trivially wrapping everything in a class. I can't understand it.

w-j-w 5y ago
More lines is generally less good, but I hesitate to really give out this advice. Classes are useful because they make great nucleation sites for future complexity, and often, more simpler lines of code is easier to read (and change). Not all additional lines of code are equally bad.
Zababa 5y ago
I think that's because non-generated lines of code are a form of "incompressible human work". Sure, one person can write twice as much lines as another. Even 10! But when you have a codebase of 10 millions lines of code, this is going to take a certain amount of man-years, and there is no way to reduce that. This is in stark contrast to the programs we write, that can replace large quantities of human work easily. Some other ways of looking at this: compilers are an impressive force multiplier. When you compare the size of the source and the size of the executable, it's easy to see how much work you avoid. Compilers allow one single person to create way bigger programs. That would also explain why some people are so insistent on Lisp: macros are compilers. If you can write your own compiler, you can increase even more your own productivity. This raises the question of why not everyone uses Lisp. The answer is collaboration. Collaboration happens when people share a mental model of things. The bigger the language, the harder it is to find lots of people that share that entire mental model. This may be why you often hear programmers with a lot of experience that prefer "small and simple" things, like C or Go. It makes collaboration easier. Dynamic vs static typing might be the same. It's about "how much context you need in your head at all time". If you have a lot of context in your head, it's easy to think about things succinctly. But when people don't have the same context as you or you lose yours, understanding their short and full of context code might be very hard. Spaghetti programs are that, a mix of context. You can't take one spaghetti out. You have the same exact problem in parsing, context-free vs context-sensitive grammar. I don't know if and how the context-free vs context-sensitive ideas translate in terms of people. If anyone really likes using Lisp or Go or Haskell, I would be interested in your opinion about my "theory", and if you think that preference for context-free or context-sensitive applies to other parts of your life or personality.

w-j-w 5y ago

More lines is generally less good, but I hesitate to really give out this advice. Classes are useful because they make great nucleation sites for future complexity, and often, more simpler lines of code is easier to read (and change). Not all additional lines of code are equally bad.

Zababa 5y ago

I think that's because non-generated lines of code are a form of "incompressible human work". Sure, one person can write twice as much lines as another. Even 10! But when you have a codebase of 10 millions lines of code, this is going to take a certain amount of man-years, and there is no way to reduce that. This is in stark contrast to the programs we write, that can replace large quantities of human work easily. Some other ways of looking at this: compilers are an impressive force multiplier. When you compare the size of the source and the size of the executable, it's easy to see how much work you avoid. Compilers allow one single person to create way bigger programs. That would also explain why some people are so insistent on Lisp: macros are compilers. If you can write your own compiler, you can increase even more your own productivity. This raises the question of why not everyone uses Lisp. The answer is collaboration. Collaboration happens when people share a mental model of things. The bigger the language, the harder it is to find lots of people that share that entire mental model. This may be why you often hear programmers with a lot of experience that prefer "small and simple" things, like C or Go. It makes collaboration easier. Dynamic vs static typing might be the same. It's about "how much context you need in your head at all time". If you have a lot of context in your head, it's easy to think about things succinctly. But when people don't have the same context as you or you lose yours, understanding their short and full of context code might be very hard. Spaghetti programs are that, a mix of context. You can't take one spaghetti out. You have the same exact problem in parsing, context-free vs context-sensitive grammar. I don't know if and how the context-free vs context-sensitive ideas translate in terms of people. If anyone really likes using Lisp or Go or Haskell, I would be interested in your opinion about my "theory", and if you think that preference for context-free or context-sensitive applies to other parts of your life or personality.