Ron said on Sun, 18 Jan 2026 12:49:44 -0800

>Steve Litt wrote on 2026-01-18 02:18:
>
>>> (complexity is always bad)  
>> 
>> That's not a very fashionable idea in 2026.  
>
>Probably because without qualifiers it is neither insightful nor
>useful.
>
>What's too complex? 

1 Use of other peoples' code when it could have reasonably been
  included in the software itself.

2 Excess cutesy-pretty features that few people need.

3 Static content stored in databases.

4 Excessive dependencies.

5 An init system reinventing and subsuming functionalities that already
  exist in existing software.

6 Thick interfaces.

>Why is the specific complexity "too much"?

Referring to my numbered list above:

1. Supply chain exploits, difficulty in keeping all the versions
   compatible. Difficulty in compilation and building, vulnerability to
   others changing their interface or functionality without warning.
   Need for other packages, some of which might not be supplied by your
   package manager, on your distro.

2. Every feature adds code, adds attack surface, and unless inserted
   very thoughtfully, adds dark corners where bugs can hide.

3. Static HTML is easy, simple, can pass all W3C validations, looks
   identical on all competent browsers. Static HTML is trivial to move
   from one web host to another: Don't try that with static content
   stored in databases. Databases are for your active content.

4. Same as #1.

5. Decreased customization possibilities. Thick interfaces. Transfer of
   code from userland to system, and time spent that could be better
   spent on making real improvements somewhere else.

6. Inability or extreme difficulty to test components individually.
   Inability or extreme difficulty to replace a component with a
   diagnostic equivalent. Much more difficult to understand.
>
>
>It's 2026, not 1926. Complexity is inevitable.

You're making an unproved assertion, so I'll make my own. The only time
complexity is inevitable is when the problem domain is complex. The
majority of human functionality addressed by software is simple.

>Which year should we go back to where complexity was just right?

In what realm? If you're talking physics, pre 1905 (when Relativity was
discovered). If you're talking cars, 1960, except we do need computers
to make engines perform better, with better gas mileage and less
pollution. Computer controlled windshield wipers, not so much.

In software, 1980's for sure. For things where GUI is necessary, 1999.
For small to medium web apps, the 1990's with LAMP. With huge web apps
hit by millions, complexity is currently necessary for load balancing,
database reliability etc.

>
>Particularly weird to complain about it on a *computer* enthusiast 
>mailing list. 

Ah, the "No true Scotsman" logical fallacy: The contention without
evidence and in fact with plenty of evidence to the contrary that you
must like complexity in order to be a computer enthusiast. 

We have Newtonian physics, Relativity (Special and Relative), Ohm's
Law, and many other laws of the universe. "Computers must be complex"
is not a law of the universe.

>Perhaps this is partially why LUGs are withering away.

Yeah, it's all my fault.

>Slide rules, pencils, and notepads if complexity is "always bad".

Here we have both the False Choice logical fallacy and the Strawman
logical fallacy. 

False choice because it implies that you can use either complex
programs or slide rules et al. Strawman fallacy because you're refuting
an argument that I never made. I never said to go back to slide rules.

SteveT

Steve Litt 

http://444domains.com

_______________________________________________
Discuss mailing list
[email protected]
https://lists.blu.org/mailman/listinfo/discuss

Reply via email to