[kingludite]

> Would new applications become available?

In the 80ś-90ś I thought of software as prototyping. If we keep a healthy separation of [shall we say] mission critical application and entertainment, today, as far as normal users are concerned, a good 99% is pretty well defined. We are now developing stuff users don't want, rent seeking schemes and prisons therefore.

Not sure if it was my failure to predict or the industries but I thought the most obvious requirements in the obvious applications would find their way into the high level language abstractions (in increasingly large chunks) and gradually migrate to lower language features and so on closer to the metal until the email client is just an array of similar email processors that can be powered on with some basic query. Have a mailto with params, a new mail notification with some custom sounds entirely separate from other audio, some way to export the attachments and the database i/o preferably with a mechanical switch that completely rules out any other process accessing the mailbox unless the user specifically enables it. Yeah, it should probably beep loudly for as long as remote reading or writing is enabled with a red led blinking above the tumbler switch.

That way no one has to ponder how to ruin the protocol, add emoji's, data mine the user, insert ads or otherwise turn email into a first person shooter MMO next level email experience. Regardless what fantastic thing email could grow into it would just not be possible. After all, we've already turned the fantastic document distribution network (www) into a fantastic application platform. Ideally such things should not be possible but it was and we did and the result is ofc wonderful... except that documents are now multi GB advertisement machines that make 500+ requests. (I cant even view the images in this topic because this laptop cant do such websites) Email has the potential to be a superior application platform much superior to the www but I really hope(ed) we could glue its components into place. (toasters that cant run doom)

The next chunk of hardware can do news groups, one for IRC, one for torrents, one for word processing, one for tabular data, one with maps, one with a web browser, a real terminal(!) and eventually we can have a hardware implementation of HN.

Each such application can have its own signal from the keyboard and mouse and its own video output. Some other chip to combine the pictures into windows with some title validation so that one cant mimic hardware implementations without the user knowing it.

I was completely wrong or was I?

That wonderful pdf in the topic makes an analogy replacing a single supper fast bar tender with multiple bar tenders but this seems a poor fit.

The general purpose stuff is like a college degree. It is some college! Its product is state of the art and it is improving all the time.

But if you want to develop, manufacture and finance the development of the next level drink dispenser you cant keep throwing [however excellent] college graduates at it and expect it to scale.

Our college is to produce the finest surgeons who are also the finest pilots, the best mathematicians, greatest artists and stand up comedians.

Good luck with that?

[contingencies]

That hardware outlook would have been rational in those days. The popularization of computing was a double-edged sword and commerce corrupted efficiency. It's no good selling people reliable PCs with easily replaceable parts if you want to make money on hardware and software. Today in a triumph of marketing and needless consumption people buy laptops for no apparent reason plus phones more powerful than their old laptops and PCs are becoming edge-cases. Each OS release refuses to work on older hardware. Even Linux drops support. On PCs you can plug in extra processors but only your modern-day prototypers/prototypists (software developers), oddballs like film post processing houses, scientists and gamers tend to bother. It's reaching the point even screens can barely be purchased without corrupting advertisements, internet connections and spyware.

Can't say I follow your whole line of reasoning but I agree the faddishness of, say, frontend environments does favor a, say, LISP implementation with code generation to exploit the next app-market with rejigs of yesteryears' algorithms. Classic games, utilities, etc. Just a new target layer and profit. Let the deployment environment evolve and invest in something abstract enough for inherent stability.

Some of the better facets of today's environment are popular enthusiasm for technology, easy and fast connectivity, and nominal availability of funding. I agree that systems thinking tends to be learned through implementation and maintenance, not taught.

Speaking of drinks, I need a drink: for tomorrow I am scaling a drink dispenser.