> Web browsers are a really good example that some software needs to be complex to do its job. Web pages can do pretty much anything so web browsers have to support that which requires a bunch of code off the bat.
The point is that web pages don't inherently need to do "pretty much anything." The web could have been simple and browsers could be simple. Stakeholders decided that no, we want more and more and more and even more features.
And when you say simple is not correct, it is often because someone wants something complicated instead of acknowledging that simple, in fact, does all they really need.
I think op is referring to something you’re ignoring. Simple algorithms can often become quite gnarly if you can’t ignore some base assumption. I’ve seen some really elegant mathematics represented in a single equation turn into thousands of lines of code simply because reality means we can run out of stack space.
Similarly, I can tell you that dealing with ill formatted feed data, parsing any given value can be trivial, until you find some random example of data that abuses some seperator. Then suddenly you need to do thing like try seperating on X and see if you get data that looks right, else seperate on Y. Oh, and include some data (if it exists) from a prior seperation based on Z. I feel bad for anyone who has to modify my code. Hopefully they won’t ignore the unit tests that include all the gnarly cases...
> Similarly, I can tell you that dealing with ill formatted feed data, parsing any given value can be trivial, until you find some random example of data that abuses some seperator. Then suddenly you need to do thing like try seperating on X and see if you get data that looks right, else seperate on Y.
Yes, if you accept complexity, this is where you end up. The other alternative is to reject complexity. Stop accepting and trying to make sense of broken data.
At this point, we get back to my point because you'll say that someone (a stakeholder) demands that the program works with existing legacy/broken/misguided systems/users. Sometimes that is genuinely the only reasonable option, but all too often I see people introducing more and more features and complexity instead of figuring out whether it's really necessary or whether the intended end result can be achieved with less.
> And when you say simple is not correct, it is often because someone wants something complicated instead of acknowledging that simple, in fact, does all they really need.
I think you can see evidence against your point and for the GP's point if you look for "Falsehoods programmers believe about X" articles. Whenever software interacts with the real world, corner cases abound.
Just as often, the problem is that the programmer had introduced assumptions (and complexity and problems) where none were required. Did they do it just for the heck of it? Or did a stakeholder ask them to add feature X because it "would be nice to have" (maybe they just think it would be nice to have, without realizing that it is unnecessary or that they could achieve what they want in a different manner using a different, less complex feature Y)?
I'm well aware of those corner cases. And, at work, I'm dealing with.. well, not corner cases, but "real world" stuff right now, related to dates and timezones. None of what I'm doing right now would be necessary if people had the guts to decide that internally and in logs, everything is always going to be in a single format such as Unix time. Unfortunately, people made bad decisions and there are stakeholders so I'm adding complexity to the software.
If it were my software, I would outright reject this complexity. It is not needed for the software to do what its core purpose is.
People like to argue that the real world is absolute and software is strictly inferior if it cannot deal with all the complex cases people in the real world attempt to shove into the software world.
My argument is that a good engineer can look at a (seemingly) gnarly real world issue and finds a way to make it simple. Not all complexity is inherent.
Using OpenBSD after Linux is quite illuminating in this regard. At points it might seem like it's lacking features, but on the other hand you find lots of cases where it achieves exactly what you could achieve on Linux in a simpler manner and with fewer features & less complexity because they took a simpler approach to it, and in doing so, made a bunch of features a Linux user would look for simply unnecessary.
> The point is that web pages don't inherently need to do "pretty much anything." The web could have been simple and browsers could be simple. Stakeholders decided that no, we want more and more and more and even more features.
I did kindof address that in my final sentence. But there is a fair amount of inherent complexity in what I would want from a replacement for the web.
The web interface for Github should still be possible. Doing that would require a graphical layout engine (eg something like css), some way to manage authentication, and some way of submitting user data from a form. None of those require a turing-complete language, so I would perhaps be in favor of not having a JS equivalent, which would dramatically simplify the task of a browser, but there is still a lot of complexity there.
> And when you say simple is not correct, it is often because someone wants something complicated instead of acknowledging that simple, in fact, does all they really need.
The easiest case to say the simple is not enough is with encryption. I am not aware of any simple encryption algorithm. If you want to achieve, communication that others cannot eavesdrop in, simple is not enough.
Numerical stability in all sorts of applications is important and it is hard to achieve. Projecting the real number line into finite bits is hard to do in a consistent way.
You didn't contest my simple vs fast claim, but a good example of that is pathfinding algorithms. Dijkstra's algorithm is simple (relatively), but for many video games, a more advanced algorithm like hierarchical A* search or jump point search is needed.
> The easiest case to say the simple is not enough is with encryption. I am not aware of any simple encryption algorithm.
I disagree very much. Most crypto is very simple to use as well as implement. From DES to Chacha20, you can fit an implementation on a business card or two.
> Numerical stability in all sorts of applications is important and it is hard to achieve.
Counterpoint: I hardly ever need to worry about numerical stability, and most of the time I can just throw more bits at it.
> You didn't contest my simple vs fast claim, but a good example of that is pathfinding algorithms. Dijkstra's algorithm is simple (relatively), but for many video games, a more advanced algorithm like hierarchical A* search or jump point search is needed.
I wish the problem of complex software were just algorithms. Because most algorithms are easy to abstract in a box with loose coupling, and even the more complex algorithms usually boil down to some dozens of lines of code.
No, the millions of lines of code in big bloated applications are not made up of that.
The point is that web pages don't inherently need to do "pretty much anything." The web could have been simple and browsers could be simple. Stakeholders decided that no, we want more and more and more and even more features.
And when you say simple is not correct, it is often because someone wants something complicated instead of acknowledging that simple, in fact, does all they really need.