I agree with your point about nagging, popups, and analytics, but I don't think the existence of those annoyances are an argument against the OP.
https://news.ycombinator.com/item?id=16261510
"Software is really about codifying process -- pun completely intended. What happens is some slick new software comes along that implements that happy 80% path on the process, and does it quickly and efficiently. Then business complains about the 20% falling into the gap, and starts adding features to reduce that, thereby slowing down the processing. This keeps going, until someone has an idea and implements slick new software that implements that happy 80% path on the process, and does it quickly and efficiently..."
To a limited extent, yes, but if we're being honest here, the main "additional demands" that most users have for most new pieces of software are "simpler" and "prettier", neither of which automatically requires additional complexity under the hood.
It means that the "simpler" software has to be aware of all kinds of edge cases and solve them automagically, because the user expects a larger degree of automation. Software seems "simpler" to the user because it's working on a higher level of abstraction (and levels of abstraction tend to be "leaky") and by reducing the domain of details that the user needs to be aware of. In order to do that properly, the "simpler" software now needs code to take care of all those details as they are effectively removed from the user's awareness, while the earlier software could leave some of those edge cases up to the user.
No, it doesn't, or at least it doesn't if you write the application in a language that is expressive enough to cater for the edge cases without bloating the code base.
Consider a language like Red, which allows you to write GUI applications in a few lines of code. Must be a large runtime behind the scenes enabling this, right? It's clear that this is not the case as the runtime, compiler and libraries fit within 2MB. How is it possible for Red to achieve so much with so little? I'll leave that for you to discover for yourself.
EDIT: As an aside, the Java 1.1 JVM was only about 15MB.
Two reasons:
1. Computing is a relatively young field, and not all of the best practices have made it to the mainstream.
2. The quickest way to develop is to bolt additional code onto the side of a project rather than considering how the overall requirements for the software application may be better served by designing reusable helper functions and refactoring.
Also, I think you've dismissed Red a little too quickly. The GUI DSL is not the only factor that keeps the codebase compact. I'm using the word "compact" rather than "small" as I recognise that Red is still in its infancy, but with the word "compact" I'm trying to emphasise that Red does a lot with not a lot of code.
> "EDIT: As an aside, the Java 1.1 JVM was only about 15MB."
How big was the JCL (Java Class Library) at the same time? Also, 15MB for a VM on its own is not that impressive. Even Oracle have managed to make small (feature complete) VMs, for example:
https://blog.plan99.net/graal-truffle-134d8f28fb69
"The resulting runtimes have peak performance competitive with the best hand-tuned language-specific compilers on the market. For example, the TruffleJS engine which implements JavaScript is competitive with V8 in benchmarks."
"To give a feel for how easy it is to write these engines, TruffleJS is only about 80,000 lines of code compared to about 1.7 million for V8."
http://nirvdrum.com/2017/02/15/truffleruby-on-the-substrate-...
"The Substrate VM addresses those deficiencies by producing a static binary of a Truffle language runtime. It performs an extensive static analysis of the runtime, noting which classes and methods are used and stripping away the ones that are not. The AOT compiler then performs some up-front optimizations such as trivial method inlining and constructs the metadata necessary for Graal to perform its runtime optimizations. The final output is a version of the Truffle language interpreter fully compiled to native machine code; i.e., there is no Java bytecode anywhere. As an added benefit, the binary size is considerably smaller than the JVM’s because all the unused classes and methods are excluded."
The quoted number was for the entire JRE installer:
http://www.oracle.com/technetwork/java/javasebusiness/downlo...
Users also, for the most part, demand more correct. Not always, and not in all applications, but the tolerance for jank is going down over time. And this is a big reason why I use React and Redux: because React maps better to my understanding of how code works (namely, that extracting state to the imperative outer shell of the functional core leads to generally more correct and maintainable code) and Redux maps better to my understanding of how data works (namely, that specific and replayable transforms create manageable state). It's also a reason why I use containers: to turn the runtime environment into an "API" that is evaluated and tested in isolation from the "API consumer" that lives in the container.
We are progressively moving towards software with these demands, too, and tools are evolving to respond to them. The panic around complexity is, IME, hyperbolic; a failure to choose tools with wisdom is endemic, it's not new.
I run Linux as my desktop, and I've been using Linux on a daily basis since the mid 90s. The amount of work that it does for its user now compared to then isn't even comparable.
How fast did this page download? Pretty fast probably. That speed happens, in no small part, because of enormously complex software running many devices between your computer and the source. Yes, hardware has gotten a lot faster, but software has gotten enormously more complex to not only keep up with the hardware, but also add and facilitate huge optimizations on top of that.
I agree that there the amount of 'useless' or low quality software is also staggering. That doesn't really surprise me, it is what it is.
And I also agree that there is a huge amount of synthetic, un-needed and artificial complexity around these days, with more being made all the time.
But I think those categories come pretty naturally, by default, from the total mass of software being created.
I guess there's a good chance that the percentage of 'good' vs. 'bad' software has always been roughly the same.
And here i sit, yelling at the screen any time any of those automagical daemons and signal buses break.
Because they make fixing the problem once and for all a royal pain!
And i moved away from Windows to get away from that crap.
It used to be we had software A read or write a file (optionally one in /dev), and output some results. Maybe those results were piped to another program that drew something within X11.
But now there is daemon A talking to daemon B over signal bus C, that again talk to program D over either bus C or E, or maybe even Z, that then many go on to draw something (likely just an eternally spinning widget because something got lost in the game of telephone).
This is the dilemma of The Linux Desktop (pick Ubuntu, GNOME, systemd, or all of them). Things like internationalization, plug and play, network configuration, are all important to provide. Trying to provide them to the demographic of people that use Microsoft Windows ends up with solutions that resemble those of Microsoft Windows. Meanwhile power users and developers get alienated and end up implementing those things in a far more efficient and efficient to use way. Running Emacs as my X11 window manager gives me far better internationalization capabilities than GNOME. xmodmap is a better way to configure the keyboard than the GUI tools in GNOME and LXDE (no more worries about losing configuration on updates, for one). Linux web browser video playback and font antialiasing has been such a great feature that I now do half of my browsing with w3m (through emacs-w3m) with the X11 misc-fixed fonts. It is faster to connect to wireless networks using OpenBSD's ifconfig than it is to use nm-applet. The list just goes on - who even needs desktop notifications? Do all projects that try to be "user friendly," like GNOME and Ubuntu and systemd, end up being power user unfriendly?
Interesting question. Can you think of any examples of projects that started (roughly speaking) simple, power-user friendly but not end-user friendly that grew to become complex, power AND end-user friendly?
A post ago you were saying users didn't care about mobile apps.
> Plus it can use a company's SSO
So can IRC, so can HipChat, that wasn't the issue.
> When it first came out, it was also not very complicated. I remember when it didn't have reactions or threads, but it was a breath of fresh air after having come from using things like HipChat and Gchat, both of which were pretty dreadful.
They were dreadful in the UX department. Slack and HipChat in particular are indistinguishable at the feature level.
To shorten my last post, it's poor development practices and a lack of foresight from upper management that makes software too complicated. You could make an interface that looks like it's from the mid 2000's(garbage by today's standards) and people would still use it if it works well and is reliable.
Look at HN. Do we need more from it than it already provides? If it was up to the average upper management, the backend would need constant retooling for every feature request from different departments, 12 forms of analytics, newsletter signup forms in between posts, job alerts, a mobile app with a nag message on mobile pages, single sign on from Facebook and Google, share buttons, a waffle iron, etc. None of which the actual users and even the developers ever wanted.
EDIT: Some people might point to Slack as an exception to my argument. Indeed, Slack looked very nice compared to the competition when it first came out. But what made it a killer app was that it took the best of the IRC experience and made it a universal experience between devices and browsers. Plus it can use a company's SSO. When it first came out, it was also not very complicated. I remember when it didn't have reactions or threads, but it was a breath of fresh air after having come from using things like HipChat and Gchat, both of which were pretty dreadful.