IDEs don’t create complexity. But they do remove some of the natural downwards pressure on complexity that you get without an ide.
I’ve been programming for 30 years and I still feel very mixed about that. For some projects, I figure who cares if it took us 30k lines to solve the problem. It’s just that complex, and more code = more optimised data structures and faster runtimes. On other days I’m reminded of how productive I can be with tiny programs or libraries that just solve their own niche exceptionally well. The best small libraries basically never need to be modified or updated. They just work and keep working forever.
I don’t think this conflict can ever be solved once and for all. I’m sad that Chrome and Linux are around 20-30M lines of code. Would they be better or worse programs if they were smaller? It’s so hard to know.
My worry with large code bases is not so much about performance, or bloat. It's: bugs.
One of the first lessons I learned same 30 years ago in CS class was that invariably you'll find at least 3 bugs/kloc, regardless of where those 1000 lines of code came from. Highly critical battle tested code tended to have less, but even code where those 3 bugs had been fixed, ultimately given enough time would turn out to have yet another 3 bugs (on average). That's scary!
My professor suggested 2 ways to mitigate:
1. create robust systems that can handle malfunctions
2. never write a single line of code that doesn't need to be written
Ps. Don't think it's fair to attribute Linux's vast code base to IDEs.
> more code = more optimised data structures and faster runtimes.
Not sure if I agree, can you elaborate? Seems a more modest claim "more code allows for more optimized ds and faster runtimes" would be more accurate(?)
At least, in the Pentium era it used to be that instructing compiler to optimize for size often resulted in faster code than optimizing for speed. That was of course the result of relatively small (text segment) caches and the often underestimated effects of temporal and spacial locality.
> Seems a more modest claim "more code allows for more optimized ds and faster runtimes" would be more accurate(?)
Yeah; I’m assuming the code in question is produced at a similar skill level. Hence mentioning Linux and Chrome.
But you’re right; large projects are often large because they’re written poorly. Personally I think there’s a special place in hell for people who bloat programs unnecessarily. Making if statements into class hierarchies. Adding generic interfaces to things that don’t need them. Factories and factory factories. This stuff reduces your team’s productivity with no corresponding benefit. I hate working with people who argue for this stuff.
I’ve been programming for 30 years and I still feel very mixed about that. For some projects, I figure who cares if it took us 30k lines to solve the problem. It’s just that complex, and more code = more optimised data structures and faster runtimes. On other days I’m reminded of how productive I can be with tiny programs or libraries that just solve their own niche exceptionally well. The best small libraries basically never need to be modified or updated. They just work and keep working forever.
I don’t think this conflict can ever be solved once and for all. I’m sad that Chrome and Linux are around 20-30M lines of code. Would they be better or worse programs if they were smaller? It’s so hard to know.