Sadly we have strayed to the other extreme. From "every instruction is precious" right over to, "who cares how many instructions I use?"
Nowadays, desktop apps which started in an instant 20 years ago, seem to take several seconds even before they are even doing anything useful like loading a project or whatever. Even things like Visual Studio looking through the MRU project list can take 10 seconds (probably a threading issue) and VSCode, Teams and others are equally unimpressive - in fact the browser, the one thing that should be slow due to the network, is usually fastest when using a well-written site.
I'm not sure whether the multi-platform desktop app was ever a great idea. How much time have we saved "not writing multiple apps" but have instead ended up with slow, bloated software that doesn't usually run multi-platform, at least not all the time in the same way.
My #1 annoyance these days, because it is so egregious, is Electron apps.
I guess because the only language some programmers know is Javascript, of which I know little but what little I know places it marginally above PHP in intrinsic horror.
So people write standalone apps in a language intended for tweaking web pages, meaning that to deploy those apps requires embedding an entire web browser into every app.
And entire popular businesses, for example Slack, do not as far as I can tell have an actual native client. The only way to access the service is via a glorified web page, running inside an embedded browser. Despite which, it can't actually authenticate on its own and needs ANOTHER web browser to be available to do that.
Electron apps make Java ones look lean and mean and efficient.
Apparently, expecting a language that can compile to native machine code that executes directly on a CPU, and which makes API calls to the host OS in order to display a UI, is quaint and retro now.
And it's perfectly acceptable to have a multi-billion-dollar business that requires a local client, but which does not in fact offer native clients of any form for any OS on the market.
It's enough to make me want to go back to DOS, it really is. Never mind "nobody will ever need more than 640kB"... if you can't do it in 640kB and still have enough room for the user's data, maybe you should reconsider what you are doing and how you are doing it.
> meaning that to deploy those apps requires embedding an entire web browser into every app
It doesn't require it, that's just what they choose, and it has little to do with the language. (Besides, if you actually observe them—and ignore what they tell you about liking JS—then it's clear that most of them hate their preferred language.) Languages and the bindings that a particular runtime exposes are orthogonal. You can have GTK apps written in JS, for example, or you can write a program in JS that compiles into a binary that runs on a microcontroller[2].
This is much more of a problem with the culture of Electron and the adjacent NPM ecosystem than it is anything else. Conflating the source of these problems is a great way to tank any would-be activism meant to solve them.
But TBH I wish Eich had just embedded Lisp in Mozilla instead.
> wide use and hence accessible.
"Everyone uses it" is not a good argument for anything at all, really.
> it takes decade to fix all issues it presented in other area.
Well, yes, it has had a lot of R&D done upon it to make it quicker, but again, that is not an endorsement.
> Still I would not dismiss it. Yes it is slow.
It seems to me that in the 2nd sentence there you contradict your own previous sentence.
> But it is not Java type.
What is so wrong with Java?
More OSes support JVMs than support Javascript. JVMs have few requirements and can even run on DOS. JVMs too have a ton of R&D into making them faster and better. There is rich tooling and support to make Java apps scale, such as Enterprise Service Buses, e.g. JBoss FUSE, which allows apps with clashing namespaces to run on the same host at the same time, and even communicate.
There are tools for writing native UIs for Java apps.
I would rather have Java apps than a Javascript one, frankly. At least with Java apps, one JVM in your OS supports all your apps, whereas JS needs one per app, or even one per window or tab in some apps.
> It can be better is the motto.
That is not a good motto. That is in fact a really bad one.
The way I heard it, Eich was hired to put Scheme in the browser, but then Sun planned a big applet event and he had a week and a half to throw together a scripting language that looked like Java, because plan B would have been something more like VBScript.
That's muddled: there was no Sun big applet event, I needed to do a demo inside Netscape to get everyone on the "it's possible to do Mocha" page.
And the VBScript threat was later, from Microsoft doing it in IE3. If I'd missed the Netscape 2 boat, it's likely VBScript would prevail (Netscape 3 was originally 2.1, and 4 was originally 3 but delayed a year; find "Collabra-driven" in https://www.jwz.org/doc/groupware.html).
The developer time is saved by not writing multiple apps, fuck the end user, who cares about their time?
Seriously, I have to really think about when was the last time there wasn't some degree of unnecessary friction in an application. It really feels like being an end user of modern tech is like being in an abusive relationship.
> It really feels like being an end user of modern tech is like being in an abusive relationship.
I've come to realize that a lot of modern developers consider users of their tech to be little more than cattle. The tech is cattle feed, meant to fatten and ensnare the user, so they can be sold off and slaughtered.
There's really only one party in that kind of relationship that benefits.
+1000. But in my experience the trend started not with developers, but with the other people around them: Product Managers, Designers, Engineering Managers, Steve Jobs wannabes. There was an obvious disdain for users, and they were seen as complete dunces that should be shepherded to whatever new functionality happened to pop up their heads. There was also a complete disdain for the medium: designers used to print design choosing too rigid designs that didn't really work that well on a screen, and only adapting when the market started punishing them.
At first programmers were able to resist all that and have a voice, but lately it seems that the only prestige we retained was the salary, so we must play the same tune as the rest of the band. Agile was an attempt at being "self managed" and have a bit more independence, but that was also corrupted and lots of devs hate it with a passion too, so we're mostly back to practicing non-iterative, Steve-Jobsian-gut-feeling-centric development. Programmers have bought into that toxic mentality too.
And even in better situations, such as my current job, the tasks that cause the most issues, take more developer time and annoy the user the most are always the same: non-idiomatic features (for the web or for desktop apps), often concocted by designers totally disconnected with the audience, who at most did two or three "interviews" where the user said "yeah I could see myself using that".
non-iterative, Steve-Jobsian-gut-feeling-centric development
This is a misunderstanding of Jobs. It’s true that he had a disdain for what users would _say_ they wanted, but he was very focused on providing the, with something intuitive and easy to use. He wanted to make their lives better, and to ‘surprise and delight’.
He was also very iterative. He regularly saw demos of in-production software (and hardware), and would ask for anything from small tweaks to complete rewrites. He was completely unafraid of throwing away work, and would change his opinions on a dime if they didn’t work out.
Sorry, let me rephrase: I don't think Steve Jobs was like that at all.
But the copycats that don't believe in iterative development or in user research love to pretend they got all figured out before it's out for development.
But it became industrialized by business-types. The BOFH thing was personal. They considered (still do, sometimes), users of their systems to be "the great unwashed."
Basically, pests.
Business types look at users as a resource to be exploited to make money.
Basically, livestock.
Different outlook. We try to discourage pests, but we breed and incubate livestock. In neither case, are we particularly interested in the long-term benefit to our users. If anything, the BOFH types are actually working towards the benefit of their "lusers," because that's their job.
I write software that is targeted at a demographic that I actually respect, and sincerely want to benefit with my work (so, naturally, I don't get paid for it).
I'm constantly fighting with "modern software types" that want to treat users of the software that I write as livestock. They -quite literally- can't understand my PoV.
It's fairly discouraging, really. I'm treated like an idiot, because I actually want to help the users of my software.
The only way I see that happening is if it becomes easier to crowdsource donations. When your users are the ones putting bread on your table, they're the boss. Whatever they want they get. But sadly it's hard to crowdsource from programmers because there's so few of us. I love building and sharing software that delights my peers. Not because it's a smart thing to do. If money was the thing I cared about, then it'd be more rational to play video games on Twitch and blog about culture conflict on Substack. Rather coding is something I feel compelled to do and I won't stop even if it destroys me.
It predates the BOFH a bit as well. I am restoring a PDP-10 to operation and the operating system refers to users as "lusers", non-sanctioned users of the system are "turists" who were just there to gawk at things. It's not so much out of disdain for the people themselves as what they were doing with the computer - when computer resources were limited, it was grating to have to wait while unskilled and uncaring people occupied those resources for frivolous or unnecessary reasons.
Edit: Consider being told something along the lines of "Your DNA sequence has to wait, the CEO has important Facebook posts to read..."
> The disdain for "lusers" came from BOFH sysadmin types, well before it was adopted by the non-"tech", business-focused folks.
Based on the definitions in the thread, I'd say the BOFH attitude is more the inverse: it is contemptuous towards users, whereas the modern practice is more condescending towards users.
The latter still has a notional ethos of catering to the user, but the Monkey's Paw corruption caters towards the user's most superficial desires, particularly at a first impression, while de-optimizing for the acclimated or "power" user.
Exactly, the modern practice is condescending. The prevalent thinking is that "users don't really know what they want", so there is zero research, zero iteration, zero respect and a lot of corralling in the application to force users into a (lucrative) workflow.
But the treatment itself is first class, unlike with sysadmins of yore.
I think those are totally different kinds of disdain.
The former is generalized misanthropy plus specific hostility to the individuals who bother them.
The latter is more akin to the feudal lord or the cattle farmer: a lack of empathy plus an eagerness to stuff one's own pockets such that they build exploitative systems.
Sysadmins ultimately just wanted to be left alone to pursue their techie interests. But the MBA types are the opposite. You can't have an upper class without a set of lower classes to provide you with income and feelings of power.
I don't remember the norm being "desktop apps which started in an instant 20 years ago". Or 30, for that matter. Do you have any data for that? E.g., when I think back over launching Photoshop over the decades, I remember loading screens all the way through.
My take is that launch times are on average better but still not great. And I think that's because something else that's constant is that programs first get written for the convenience of the programmer, and then optimized until people stop complaining about the speed.
The waste of resources bothers me too, of course. But on the other hand, computing resources have become radically cheaper while programmer time has gotten much more expensive. While at the same time, writing software had gotten radically more complex. So I suspect me getting bothered here is sort of like when my grandmother, who grew up in the Great Depression, got bothered when I didn't wash and reuse aluminum foil.
> I don't remember the norm being "desktop apps which started in an instant 20 years ago".
What keeps happening is-- we get an upgrade, and then have some old applications, and they become "instant" in comparison to our experience with both newer stuff and the application in the past. Then we watch that win clawed away from us.
Of course, it was never instant, even with the old or newer hardware.
My brother spoke a few weeks ago of being awestruck and programs starting "instantly" when he got a hard disk on DOS on the XT. But now I have a better-than-XT-equivalent (9.54MHz V20) with a very fast IO subsystem and I can tell you that it is very much not actually instant.
Who cares about instruction counts? Computers are there to get stuff done, they're a means to an end.
Good algorithms are far more important than instruction level optimization, which is to a large degree pointless anyway, since new CPUs come out all the time, and change the tradeoffs involved.
Nowadays, desktop apps which started in an instant 20 years ago, seem to take several seconds even before they are even doing anything useful like loading a project or whatever. Even things like Visual Studio looking through the MRU project list can take 10 seconds (probably a threading issue) and VSCode, Teams and others are equally unimpressive - in fact the browser, the one thing that should be slow due to the network, is usually fastest when using a well-written site.
I'm not sure whether the multi-platform desktop app was ever a great idea. How much time have we saved "not writing multiple apps" but have instead ended up with slow, bloated software that doesn't usually run multi-platform, at least not all the time in the same way.