Thats....not what google play services is, like at all. https://developers.google.com/android/guides/overview

because we are going to make editors using JAVASCRIPT, which was never meant to be used this way

Also - resources that are essentially free to use (customer/users CPU cycles, storage and bandwidth) will be consumed.

We as consumers are paying the bills for it all in different ways(electricity, new gadgets, cloud costs etc).

It depresses me to no end too, but i am surprised in the least.

There were tiny groups trying to go frugal and solid. Remember suckless ? I forgot other names, there's also alan kay vpri project with ometa.

Maybe we should make a frugalconf. Everything 25fps on a rpi zero

Of course they’re going to accept that delay, even if adding a few million numbers together should really take less than a millisecond.

Not everything needs to be super efficient. Most things are tuned for production cost and time. Efficient code isn't going anywhere. Relax guys.

> Modern text editors have higher latency than 42-year-old Emacs. Text editors! What can be simpler? On each keystroke, all you have to do is update a tiny rectangular region and modern text editors can’t do that in 16ms. It’s a lot of time. A LOT. A 3D game can fill the whole screen with hundreds of thousands (!!!) of polygons in the same 16ms and also process input, recalculate the world and dynamically load/unload resources. How come?

Text is very complicated. Does your 42-year-old Emacs support Unicode? And not just accents, but whole different scripts?

See https://news.ycombinator.com/item?id=21105625 for some discussion and a good link about the complexities of rendering text.

No one's forcing you to use a library. But if you do they come with tradeoffs.

OK, things are slow and buggy. But we've got lots more things thanks to all the productivity we've gained from using libraries, etc. That means we collectively solve more problems for more people.

Purism is a nice idea, but ultimately probably not worth the effort until things become so bad that they are, and at that point become a differentiator. I mean, I don't care if a web page is twice the size of Windows 95 because my computer is way faster than a 486.

a) Lack of fundamental understanding of how computers work

b) Abstraction away from the bits, flops, shifts and pops

c) Quick sort

d) Electron.js

e) Ruby hipsters

f) Magical cloud computing

g) Software companies that know the cost of everything and the value of nothing

h) All of the above

All module folders should be at root level.

Need version 15 and version 16? Yep different folders under the root. Modulename_version, eg somelib_0.1.15 alongside somelib_0.1.16

It would allow clear identification of old versions and much less duplication. Less bloat. No way to have duplicate copies of the same library.

I feel like this is a feature, not a bug of software dev. The fact that you can push updates out so instantaneously allows you to work incredibly incrementally. You can make barely functional, inefficient things (shortcut hacks) just to make sure that your product is something that people actually use before focusing on optimization. If users are willing to put in the extra work to "refresh" the page, then certainly there's some real problem you are solving.

Gas car technology matured, gas got more expensive, and cars got more efficient. Moore's Law isn't going to go on forever. We are hitting limits in battery life. Software will tend to get more efficient over time.

I think we need a guild. We need licensed software engineers.

Not every programmer needs to be one, just like not every engineer needs to be licensed, but there needs to be a licensed engineer on every team. And, of course, sometimes there doesn't need to be. But I sure wish there was the option.

And hell, bring back apprenticeships and mentoring with the guild. There is so much we could learn from the physical science engineering disciplines

As self driving cars enable us to fit far more cars on the road before causing the same level of congestion, people will start taking increasingly longer car rides for decreasingly valuable reasons, up until the roads are equally intolerable as they were before the innovation had occured.

Replace "self driving cars" with "faster hardware / more memory".

http://www.muppetlabs.com/~breadbox/software/tiny/teensy.htm...

Honestly things were way more sucky years ago. Your Windows computer crashing was just normal in the 90's. Rebooting and reinstalling par for the course. Getting Linux to install with drivers working seemed impossible unless you carefully chose hardware.

Or fewer features. Talk to an actual professional who uses spreadsheets all day long about switching from Excel to Google sheets. It's infuriating the infantilization of UIs and the "oh they'll never miss it" attitude.

but:

- economic incentives do not align with common sense

- landscape is fragmented, continually evolving and unstable

- we are all posers. we all have opinions and morals, look at others and criticise, but when it comes to our own work we are just like anyone else. we need money to live, so we just go with the flow

The whole point of Babel was to allow us to use the latest JavaScript syntax so that we wouldn't have to update our own source code when the new syntax finally became broadly supported by browsers and other engines.

IMO, the Babel project is a failure because:

- Babel itself is always being upgraded to support newer ECMAScript syntax, so people still need to upgrade their own code whether they use Babel or not. The only benefit is that using Babel allows you to use these features before other people.

- Instead of just worrying about how JavaScript syntax changes affect your code, with Babel, you also need to worry about how Babel upgrades will affect your code. The babel plugin dependencies often change and break over time (even if you don't change your own code) and you always have to support both ecosystems.

So when you consider the big picture, Babel doesn't save you from having to upgrade your own code (as per its original promise). When you evaluate the pros and cons, the cons greatly outnumber the pros:

Pros:

- You get to use the newest language features before other people.

Cons:

- You need to maintain your code for compatibility with two ecosystems instead of just one. Keeping up with both ECMAScript + Babel is a lot of work. I would even argue that staying up to date with Babel is more work because dependencies keep changing underneath your project.

- It forces you to use a build step so you lose the benefits/iteration speed that an interpreted language brings to your development flow.

- Adds a lot of bloat and unnecessary, hard-to-describe dependencies to your project which can open up security vulnerabilities and make your code more opaque and brittle.

An explanation of "why" does not explain "why this is acceptable".

I support the idealism of the article, but this quote is very accurate. Nobody wants to pay for quality software. Not your users, not your stakeholders, not even you!

And that's because the price of quality isn't just a little more expensive. It's not 1$ a year. It's exponentially more expensive. And some of those paid efforts will still end up slow and crappy in outcome, because of something else the article doesn't acknowledge:

Writing fast, efficient, simple, correct, full featured software is really really hard.

So not only is it expensive, it's also just plain difficult. Meaning it's not just about money and resources, but also time, time to experiment and fail.

If I think back to my engineering school days, the definition of "engineering" for my classmates in civil and electrical engineering was to look up well defined procedures and calculations from a book and apply them. No deep understanding required to design a bridge that didn't fall down or a circuit that didn't overheat.

What's the equivalent for software? Design patterns were a bust. SICP is for cultists. It's a huge void. There is hardly any such discipline as "software engineering" yet.

Well, where's your word processor buddy? Try to write one to achieve those goals -- and offer what people want today, including syntax highlighting, linting, auto-completions, etc, and come back to us...

There's no reference for this in the article, and it caught my attention - anyone have any idea what the author is talking about here? Never heard of this before

But the best explanation for why this problem persists even in teams of proficient engineers that I have seen comes from the 2005 GDC Keynote from John Carmack [1].

> I can remember clearly in previous projects thinking [...] I've done a good job on all of this but wouldn't it be nice if I could sit back and really clean up the code, perfect the interfaces, and you know, just do a wonderful nice craftsman job [...] interestingly this project I've had the time to basically do that and I've come to the conclusion that it sort of sucks [...] there's a level of craftsman satisfaction that you get from trying to do what you do at an extreme level of quality and one thing that I found is that's not really my primary motivation [...] that's not what's really providing the value to your end-users [...] you can sit back and I am do a really nice polishing job it's kind of nice but it's not the point of maximum leverage and I found.

So, as others have mentioned here, there is a threshold where extra performance provides less value to the project than, say, an extra feature.

It seems that in some cases we have crossed that threshold and some software has become comically bloated. I attribute the reason why these are not solved to the same reasoning. Refactoring an existing project to reduce the bloat would take too much time and effort from one single developer, that could be used somewhere else, although in the end everyone would benefit from it. So you are better off adding stuff to the dumpster fire and moving on.

It's sort of a tragedy of the commons [2] of software performance.

[1] https://youtu.be/N0auhzHZe5k?t=1015

[2] https://en.wikipedia.org/wiki/Tragedy_of_the_commons

Modern text editors have to deal with proportional font, right to left writing, anti-aliasing, and a big bag of Unicode related issues (Arabic is going to break all assumptions you have on language and text editing)

Fantastic read on this subject from few months ago:

https://news.ycombinator.com/item?id=21384158

You and me both buddy! 11 years here, you are not alone in this!

What I found helped me take my mind of this nagging feeling is to bring in a tool that is like a razer sharp brand new scalpel. That was Nim. It's readable, small, fast, and spits out tiny statically compiled binaries.

Find your scalpel and slice and dice. Back to basics. Purity.

https://docs.gitlab.com/ee/administration/operations/unicorn...

because I've had to deal with that a bit. N.B. the last sentence here:

One other thing that stands out in the log snippet above, taken from GitLab.com, is that ‘worker 4’ was serving requests for only 23 seconds. This is a normal value for our current GitLab.com setup and traffic.

For example, how many authors on medium proclaim themselves "Senior Software Engineers" but when you dig find they've got maybe 5 years experience doing web development, with no CS or engineering education. Maybe stuff like a 36hr "Web Development Bootcamp". Do people really not understand the definition of an engineer anymore?

From there they progress into the deeper parts of software. And create the atrocities to be found in the npm registry, which become dependencies of dependencies of dependencies that results in nightmares everytime one needs to navigate to a website.

If it would've been possible to see the background and education of the numerous critics here, what may we find? If I (the developer as described by the OP) am surrounded by people like me, and the world filled with people who think like me, and create things at a similar cognitive level as my peers, would I not misjudge the collective level of quality that I perceive to be acceptable? Smells like confirmation bias to me? Maybe a few others. Dunning-Kruger anyone?

In their defense, the marketing campaigns created by large corporations to turn the supply-demand (cost of employment) of employees in their favor, has I think been a big part of the problem. First the programmers, then the "Data Scientists", etc - the amount of disappointment and student debt being created as these people eventually realise they've been sold something that they're not suited for!

If we cannot critically look at our industry and admit our flaws, we cannot move forward as a collective.

I jumped straight from Android 2 to Android 8 development and was surprised myself, so did some investigation and have half an answer. The author is actually wrong here, on both looking different and additional functionality. However, the bloat is still far larger than it needs to be.

All the bloat comes from the AppCompat modules, which all the docs recommend to the point of it apparently being required if you don't know better.

AppCompat is for both supporting differing APIs and creating a consistent look and feel across different Android versions. Each Android version has its own visual design, which Google decided was a bad thing, opting to use AppCompat so the most recent designs (and in some regards design functionality like coloring the selection handles) were used in older versions of Android.

To do this however, it includes a crap-ton of images. The build scripts are supposed to remove the unused ones, but even with maximum trimming enabled it can only remove somewhere around 10%. There are hardcoded inclusion rules for some of the AppCompat java code, that no one's found a way to override, which in turn reference the images - so they get kept a well, even if your app never uses them.

As for differing APIs, notifications have changed massively over the years. The interface is so different you do actually need the AppCompat subset for notifications to target different Android versions (and that can be used separately from the rest of AppCompat), but there also have been a huge number of new features added to notifications - such as delay settings, shortcuts, icons, even full-on fancy designs, that didn't exist early on.

I'm calling this only half an answer because there's no apparent reason for some of the notification API changes, and the build scripts/AppCompat can certainly be significantly improved to remove more cruft. I have a sneaking suspicion that it's not done because this is low-hanging fruit for handing over signing keys to Google for their "optimized" builds...

I am a dependency skeptic. I think that you need them to do big stuff, but should probably avoid them for small stuff.

High-quality dependencies can have a drastic impact on the quality of your software, but so can low-quality dependencies.

I think we are at the tail-end of a "wild west" of dependencies.

When the dust settles, there will be a few really good, usable and stable dependencies, and a charnel pit, filled with the corpses of all the crap dependencies, and, unfortunately, the software that depended on them.

The only way out of this is to rethink the web. Which is a hard one to tackle.

> The demand upon a resource tends to expand to match the supply of the resource (If the price is zero).

Have cheap hardware, software will expand to use more of it.

Conway's Law

> I hope I’m not alone at this. I hope there are people out there who want to do the same. I’d appreciate if we at least start talking about how absurdly bad our current situation in the software industry is. And then we maybe figure out how to get out.

Okay, I'll respond, especially on the last part "how to get out".

For the problems and struggles in the OP, I've seen not all of them but too many and sympathize. Mostly though, I don't have those problems, and the main reason is in the simple, old advice in the KISS Principle where KISS abbreviates Keep it Simple Silly although the last S does not always abbreviate silly.

In particular my startup is a Web site and seems to avoid all of the problems in the OP. Some details:

(1) Bloated Unreliable Infrastructure?

My Web site is based on Microsoft's .NET with ASP.NET for Web pages and ADO.NET for access to SQL Server (relational database). The version of .NET I'm using is some 4.x. So far I've seen essentially no significant revisions or bugs.

For the software for my Web pages I just used one of the languages that comes with .NET. I wanted to select between two, the .NET version of C# and the .NET version of Visual Basic. As far as I can tell, both languages are plenty good ways to get to the .NET classes and make use of Microsoft's managed code, e.g., garbage collection, and their CLR (common language run time) code. And IIRC there is a source code translator that will convert either language to the other one, a point which suggests that really the two language are deeply equivalent.

I've written some C code off and on for 20+ years; mostly I remember the remark in the Kernighan and Ritchie book on C that the language has an "idiosyncratic syntax" or some such -- I agree. I never could understand the full generality of a declaration of a function -- IIRC there is some code in the book that helps parsing such a statement. I do remember that

i = ++j+++++k++

is legal; I don't want any such code in my startup; also my old tests showed that two compilers gave different results.

I find Visual Basic to have a less "idiosyncratic syntax" and a more traditional syntax closer to the original Basic and then Fortran, Algol, PL/I, Pascal, etc. So, my 100,000 lines of typing are in the .NET version of Visual Basic (VB).

For my Web site, part of the code is for a server process for some of the applied math computing. The file of the VB source code is 478,396 bytes long (the source code is awash in comments), and the EXE version is 94,720 bytes long. As far as I can tell, the code loads and runs right away. Looks nicely small and fast and not bloated or slow to me.

(2) A bloated IDE (integrated development environment).

I have no problems at all with IDEs. The reason is simple: I don't use one.

Instead of an IDE, I typed all my code, all 100,000 lines, into my favorite text editor, KEdit. It has a macro language, KEXX, a version of REXX, and in that language I've typed about 200 little macros. Some of those macros let KEdit be plenty good enough for typing in software.

E.g., I have about 4000 Web pages of .NET documentation from Microsoft's MSDN site. Many of the comments in my VB source code refer to some one of those pages by having the tree name on my computer of the HTML file; then a simple command displays the Web page. When reading code and checking the relevant documentation, that little tool works fine.

After all, VB source code and HTML code are just simple text; so are my Web site log files, the KEXX code, Rexx language scripting code, all the documentation I write either in the code or in external files (just simple text or TeX language input), etc. So, a good general purpose text editor can do well. And, "Look, Ma: I get to use the same spell checker for all such text!" The spell checker? ASPELL with the TeX distribution I use. It's terrific, really smart, blindingly fast, runs in just a console window.

For KEdit, it seems to load and run right away. I just looked and saw that what appears to be the main EXE file KEDITW32.exe is

1,074,456

bytes long -- not so bloated.

(3) Windows 10 Home Edition Reliability.

For a move, I got an HP laptop; it came with Windows 10 Home Edition. I leave it running 24 x 7. It hasn't quit in months. It appears that now the Microsoft updates get applied without stopping the programs I usually have running, e.g., KEdit, the video player VLC, Firefox, etc.

Using carefully selected options for ROBOCOPY, I do full and incremental backups of my files. I keep the ROBOCOPY log output; that output shows the data rate of the backup, and I have not seen that to grow slower over time. The disk in that laptop is rotating, and I've never done a de-fragmentation. So, I can't complain about performance growing slower from bloat, disk fragmentation, etc.

(4) Windows 7 64 bit Professional Server.

For a first Web server, I plugged together a mid-tower case with an AMD FX-8350 processor, 64 bit addressing, 8 cores, 4.0 GHz standard clock speed and installed from a legal CD and authentication code Windows 7 64 bit Professional SP1. As I left that pair running 24 x 7, occasionally it would stop with a memory error of some kind. I installed an update and never again saw any reliability problem in months of 24 x 7 operation.

Since then I looked into Windows 7 64 bit updates and concluded that (i) there was a big roll-up of about 2016 or some such; (ii) since then there have been updates and fixes monthly and cumulative since the big roll-up, and (iii) the updates for Windows 7 64 bits and Windows Server 2008 are the same.

I can believe that Windows Server 2008 long ran and still runs some of the most important computing in the world. So if my Windows 7 64 bit Professional has the same updates as Windows Server 2008, maybe for use as a server my Windows 7 installation will be about the most reliable major operating system in computing so far. Fine with me.

So, I am not screaming bloody murder about operating system or software reliability.

(5) Smart Phone Bloat and Reliability.

I have no problems with smartphones if only because I have no smartphone and don't want one: When smartphones first came out, I saw the display as way too small and the keyboard as just absurd. Heck, in my desktop computing I have a quite good keyboard but would like a better one and, of course, would like a larger screen -- no way do I want to retreat to an absurd keyboard and a tiny screen.

Next I guessed that there would be problems in security, bloat, reliability, system management, documentation, and cost. Maybe history has confirmed some of these guesses!

For a recent move, I got a $15 cell phone and did use it a few times. Then I junked it.

My phone is just what I want -- a land line touch tone desk set with a phone message function from my provider. Works fine. So, I have a phone with lower cost and no problems with keyboard, screen, security, bloat, or documentation. Ah, old Bell Tel built some solid hardware!

(6) Web Site Speed, Reliability, and Bloat.

My Web site apparently has few or no problems with speed, ....

Why? The site is simple, just some very standard HTML code sent from now old and apparently rock solid ASP.NET.

Fast? The largest Web page sends for just 400,000 bits.

The HTML used is so old that it should look fine on any device anywhere in the world with a Web browser up to date as of, say, 10 years ago.

The key to all of this? The KISS Principle.

YMMV!

Hmmm. Let's think about this.

I piled standout quotes below.

I think a big takeaway from the intersection of Bret Victor, Alan Kay, Jim Hollan and the ink&switch folks and your work is that the right dynamic interface can be the "place we live in" on the computer.

Victor shows a history of interactive direct manipulation interfaces, live environments where explorations of models or the creation of art go hand in hand with everything else related to that task: data input, explicit (programmatic) requirements and the visual output.

Hollan and ink&switch show the environment (ZUIs, canvas) can contain everything for doing work, the code alongside any manipulation of the viewport that can be conceived. Tools infinitely more advanced than Microsoft OneNote and designed 40 years ago.

From what I know about your work, I see another take on the environment I want to live in on the computer. I dont understand why I would want to lose power by stepping away from my language/interpreter/compiler/repl into a GUI or some portal when I can bring whatever it is which is nice about GUIs or portals into my dynamic computing environment. I very much want a personal DSL or set of DSLs for what I do on the computer, and I want to be able to hook into anything ala middle mouse button in plan9.

The superior alternative to walled gardens and this absurd world of bloat and 'feature loss' (for lack of a better term for software engineering's enthusiastic rejection of history) seems to be known, and facets of it advocated by you and these others. It seems clear that "using the computer" needs to return to "programming the computer" and that to achieve that we need to fundamentally change "programming the computer" to be a more communicative activity, to foster a better relationship between the computer and the user.

Where is this work being done now? VPRI shut down 2 years ago, Dynamicland seems to be on hiatus? I am inspired most these days by indie developers who write their own tools and build wild looking knowledge engines or what they sometimes call "trackers."[1] And of course the histories and papers put forward by the above and their predecessors. And I play with my own, building an environment where I can write, draw, code, execute and interact with it all. I see no existing product which approaches what I want.

> Everyone is busy building stuff for right now, today, rarely for tomorrow.

> Even when efficient solutions have been known for ages, we still struggle with the same problems: package management, build systems, compilers, language design, IDEs.

> You need to occasionally throw stuff away and replace it with better stuff.

> Business won’t care Neither will users. They are only learned to expect what we can provide.

> There’s no competition either. Everybody is building the same slow, bloated, unreliable products.

> The only thing required is not building on top of a huge pile of crap that modern toolchain is.

> I want something to believe in, a worthy end goal, a future better than what we have today, and I want a community of engineers who share that vision.

[1]: https://webring.xxiivv.com

All of this bloated 'shitware' today is the result of it having been written by people who a) have no deeper understanding of what the computer is actually doing; also known as typical Python/Java/etc/etc/etc programmers, and/or b) simply not giving a damn about conservation of resources--as further evidenced by all of the other extremely wasteful and destructive habits they hold in their personal lives, and in their societies in general.

After all, this is the same civilization that's burning through increasingly vast quantities of oil at an astounding rate, despite the fact that previously existing abundant and cheap oil is nearly depleted, with no possibility of replenishment or replacement. So is it any surprise that foolish developers also burn through CPU and memory with reckless abandon?

Really, the problems we face aren't just in software; they're more about the foundations of our entire Western 'civilization.' Such problems generally tend to be rather intractable, in the historical view.

I'm working to construct, in my own computing life, something of a 'personal oasis', which is increasingly removed and estranged from all of the horrible things I see Other People out there having to suffer in their personal computing lives, thanks to talentless 'developers' who Just Don't Fucking Care. Some of these pricks actually have the audacity to call themselves 'engineers', even.

Effiency is a selling point that most users don't care much about in most markets. There are efficient browsers out there but everyone uses Chrome because those browsers are inferior to Chrome in many other ways. Ways that are more important to the average browser user.

If there's a market for a more efficient software solution, go make it and get rich. Otherwise, I'm getting sick of the complaining.

The least competent programmers are the once writing slow code. The least competent programmers are the ones working at the top of the stack.

If you "simply blocked all ads" the people making the pages wouldn't have the income which they maintain the pages with.

How smart do you have to be to understand that?

>We haven’t seen new OS kernels in what, 25 years? It’s just too complex to simply rewrite by now. Browsers are so full of edge cases and historical precedents by now that nobody dares to write layout engine from scratch.

Well, there's Fucsia, speaking of new kernels. And Mozilla is doing exactly that, written a new layout engine from scratch (plus a language to write it in).

(I agree with the general sentiment of the post, but the examples are often shoddy)

All systems - biological, physical, meta-physical are built on layers that once deep enough are pretty well cemented in. Hindsight is 20/20 and though we know if the foundations were different things would be better - they won't actually change until the energy gain exceeds the energy cost of uprooting everything to make the change.

Just saying this problem isn't exclusive to software, but also laryngeal nerves in giraffes, x86, and Esperanto.

An increasing number of providers (for example databases) charge per server, per core, or another hardware-usage metric. The more hardware, the more revenue for them as they make about 90% margin for every new machine. There is a high incentive to get users to need more machines on their "managed cloud".

Vendors could try to improve their software so it requires twice as little CPU. But why bother since this would result in 2x cost in revenue? It makes more sense to focus on horizontal scalability than on core efficiency so users can keep on adding machines to their cluster over time.

If software is running at 1% of the maximum performance as suggested in the article, a 1% improvement could reduce costs by 50%. But I think none of the existing vendors will ever make the move as it conflicts against their own interest.

> I can comfortably play games, watch 4K videos, but not scroll web pages? How is that ok?

IMO the comparison should be buildings <-> fine-tuned libraries (i.e. video decoding algorithms), modern applications <-> cities.

Go to any city center in Europe. Urban planning a century ago was much more elegant and elaborate taking into consideration the city as a whole. Nowadays developers and investors often ignore important aspects, such as surrounding buildings, infrastructure, making cities inefficient for the people who actually live there.

Any system which has plenty of resources has to become inefficient. It's just that the Moore's law allows for pretty damn inefficiency.

Since the current practices are so inefficient, users are having to pay for this from pocket as hardware expenses. Buy a $1000 smartphone, to get the same experience as last-year's.

A different stack (don't need to reinvent the universe), can be branded as brutally efficient, uses slim hardware, and strict engineering practices to provide a much better experience at a fraction of the price (1/5 possible.)

I believe nobody is doing that yet since there are two main barriers:

1- Risk of no-market (I think this might be proven unfounded, given the current trend in price hikes)

2- Capital investment necessary to get started (But this also can be solved given the obvious appetite for the next-big-thing money being poured left and right, without anything catching on yet)

The argument is incomplete.

The correct question (to maintain the analogy) is:

"Would you buy a car if it eats 1000 liters per 100 kilometers, but that doesn't affect you at all (you still get to where you want to be fast enough), and the time to manufacture and cost to buy it is much lower than would be possible with more efficient car that used 10 liters per 100 km?"

The answer to which would be yes. A software that does a task we do once a day or so at 1 second vs 0.2 seconds doesn't cost us money (and even the environmental impact is small).

>That is not engineering. That’s just lazy programming

I don't believe that developers/programmers are all lazy. There are a lot that want to do a good job optimizing their code and making sure it performs well and is future proof as much as possible. I believe that budget limits and pressure from deadlines set by non-technical people forces even the good programmers to cut corners in order to deliver.

Somebody needs to write this software. Efficient, maintainable, and debugged are not the low-energy state.

That means it either needs to come from business, or from open-source hobbyists. Business doesn't see a competitive advantage in it -- even Apple, which has traditionally cared more about UX than anybody, just has to be better than their #2 competitor (and price of entry to "desktop OS" or "smartphone OS" is high so that list is short, and not changing on any relevant timescale). And the open-source world has never delivered well on the end-user experience side of things.

The sad truth is that users would rather have new software for $0 (paid by ads, or media subscriptions, or whatever) than pay what it truly costs to develop software.

My main hopes today are that the end of Moore's Law will force companies' hands, or that government will step in to regulate minimal quality, or that workers will organize so they can stand for quality behind a CBA. These all seem rather unlikely at this junction. The number of programmers in it for the paycheck far outweighs the number of people who care about simplicity.

Software is going to get much worse before it gets better.

It seems he does not realise that this is a satire piece, and seem to completely buy in to his view of the world instead of seeing things in a more nuanced way.

The software in nutshell is programmable transistors. Each CPU instruction is in effect just a convenient way to design a specific electronic circuitry. Even a trivial act of printing Hello World takes an astonishing amount of complexity when you take into account all kind of protoicals, APIs, driver codes, kernal code, fonts, rendering, graphics that gets executed in between. If you showed a computer printing Hello World on screen to someone from 1920s who knows how to build electronic circuits and primitive "display", they can estimate the amount of work that would be required to do that. Nothing has changed from 1920s to 2020s in terms of complexity to enable simple Hello World. A relatively simple program will easily exceed 30,000 low level components working together to achieve a goal in an intricate dance. Now think of large code bases with million lines of code... This is why software is hard, software is complex, software is messy and software is magic.

The exception would be games and embedded software, but even there, there's certain degrees of lazyness. For instance, games are very cpu/memory/gpu efficient, but they're almost always ridiculous when it comes to disk space usage. There's no reason that your average AAA game needs to take up 50GB other than that things which could address that aren't worth the fuss. (I'm thinking common demo-scene tricks like procedural textures/data/everything, aggressive compression schemes, reusing assets, etc.)

But something crucial is missing from this manifesto. As the author says, the problems don't exist because we can't solve them, but because no one ever takes an interest in solving them. We're all engineers, so why don't we just do some engineering and fix this bullshit? Well, because it wouldn't make any money.

Perplexingly and contradictorily, the profit motive drives both innovation and stasis, both growth and sprawl, and both efficiency and inefficiency. The problem is both technical and social, and probably so will be the solution.

Whenever I read posts like Software Disenchantment, I find myself agreeing with that philosophy. In other words, it’s probably by design. Of course this doesn’t account for the enormous waste of time and money that occurs during software development, but that doesn’t really affect my feelings on the matter.

Software today is in the snake oil era. "Secure", "privacy-friendly", "robust"...

We need the government to create the FDA of software, to protect the consumers against potentially harmful software, marketed using false advertisement.

We also need job applicants to be protected against predatory companies that hire people that want to do right by the customer, but are forced to produce rushed, poor quality stuff.

What frustrates me above all else is the trend of compile-to-javascript languages. IMO interpreted languages are great, of course some performance was sacrificed to get there - I think that was a fair trade-off because saving the developer from having to build the project is a HUGE advantage when developing (at least for my particular development flow)... So when I see people throwing away that massive advantage by adding an unnecessary compile step in order to get slightly better syntax or static typing (e.g. CoffeeScript or TypeScript), I find it deeply disturbing. Static typing can be a useful feature, but is it worth adding a compile step? Not by a long shot.

And the idea of transpiling a language into an interpreted language is just ridiculous in principle. We had an army of very smart people who invested a huge amount of time and effort into making efficient interpreters for certain languages but all that work is thrown away as soon as you add a build step.

And the stunning thing is that it's actually possible (easy even) to create excellent software with clean code without a build step (I've done it many times) but these simple, clean approaches are never popular. People want to use the complex approach that introduces a ton of new problems, delays and compatibility issues.

The problem is that when your software is built on top of a framework and/or uses X different web APIs etc then you often run into issues where a part of the system that you don't have control over causes performance issues and you don't have the expertise/time to profile it in order to fix it. So I think what's causing problems is that software has become a lot more about putting together frameworks, libraries and reusable components and when faced with such a complex system a programmer will often give up and say "there! it's as fast as I can make it without rewriting everything from scratch".

Therefore, the issue seems to be that programmers are building on top of other systems that they don't know enough about to use efficiently. The author does mention this issue in his article as well, but in a slightly derogatory fashion blaming programmers for bringing in dependencies they don't need.

I think if everybody had the time and ability to write everything from scratch like Jonathan Blow is doing with Jai then yes, things would be more efficient. It is far easier to profile and debug code you've written yourself. However, seeing how this isn't feasible for most projects, I think more focus should be put on better documentation of frameworks and libraries.

But as many languages support implicit static typing, the folklore that dynamic languages are "more expressive" is not actually correct.

such as:

let x = "string literal" //compiled as string

let y = 42 //compiled as int

let z : i32 = 100 //compiled with type declared as 32 bit int.

This works great for my personal machines, but not for my company, which wants to do fancy networking things without going over the open internet.

I do fully agree that it’s an order of magnitude cheaper if you know what you are doing though. I’m sure our $3000/month AWS stack would run a lot more efficiently on my $20/month Robot server.

Note also the potential deadlock here. Optimizing core calculations at μs level is bad because UI is slow, but optimizing UI to have μs responsiveness is bad, because core calculations are slow. Or the database is slow. This way, every part of the program can use every other part of the program as a justification to not do the necessary work. Reverse tragedy of the commons perhaps?

If you had pure gasoline, you could store it for years (and in past, countries and armies did exactly that for their reserves).

That would be the meaningful software improvements I can think of. Curiously, the key enabler here seems to be performance - we had the capability to write web apps for a while, but JS was too slow to be useful.

--

[0] - They may or may not have been developed earlier, but I haven't seen them used in practice before the modern web.

In this thought experiment we are talking about a 2 orders magnitude improvement - hardly a small nudge!

0ms is great, 4ms is very good, 16ms is minimally acceptable, 20ms needs improvement (you're skipping frames), 200ms is bad (it's visible!), 500ms is ridiculous and should have been showing a progress bar or something.

Responding to input doesn't necessarily mean being done with processing, it just means showing a response.

>You’ve probably heard this mantra: “Programmer time is more expensive than computer time.” What it means basically is that we’re wasting computers at an unprecedented scale. Would you buy a car if it eats 100 liters per 100 kilometers? How about 1000 liters? With computers, we do that all the time.

The point is that we are wasting all the resources at every scale. We are supposedly burning computer cycles because developer time is more important. Yet we are also burning developer time with compiling, or testing for interpreted languages, at a rate that is starting to approach the batch processing days.

One thing I found was that surprisingly the C# code I write outperforms the C++ code I used to write at equal development times.

I was good at C++, but the language has so many footguns and in general is so slow to develop in that I would stick to "simple" and straightforward solutions. I avoided multi-threading like the plague because it was just so hard to get right.

Meanwhile in C# it's just so easy to sprinkle a little bit of multithreading into almost any application (even command-line tools) that I do it "just because". Even if the single-threaded performance is not-so-great, the end result is often much better.

Similarly, it's easy to apply complex algorithms or switch between a few variants until something works well. In C++ or even Rust, the strict ownership semantics makes some algorithm changes require wholesale changes to the rest of the program, making this kind of experimentation a no-go.

The thing that blows my mind is the "modern" approach to programming that seems to be mostly young people pretending that Java or C# just don't exist.

Have you seen what JavaScript and Python people call "easy?" I saw a page describing a REST API based on JSON where they basically had thousands of functions with no documentation, no schema, and no typed return values. It was all "Just look at what the website JS does and reverse engineer it! It's so easy!"

I was flabbergasted. In Visual Studio I can literally just paste a WSDL URL into a form and it'll auto-generate a 100K-line client with async methods and strongly-typed parameters and return values in like... a second. Ditto for Linq-2-SQL or similar frameworks.

I understand that you're asking a theoretical question, not a practical one, but in practical terms the answer is fairly simple. Our economy is not built to (indeed, is built not to) reward individuals in line with what they contribute to society. An entirely different set of incentives are what structure our economy, and therefore the jobs and lives of most people.

In some sense, David Graeber's Bullshit Jobs is all about the widespread awareness (and denial) of this phenomenon, and what caused it. I wouldn't say it's a perfect book but it's the best one I've read on the subject.

Edit: in other simpler words, it's useful and scales fine.

(Do individuals really bother mining bitcoin these days anyway?)

React is huge, it’s unlikely you’ll implement the synthetic events, lifecycle hooks, bottom up updates, context, hooks with their magical stacks, rendering “optimizations” and all of react-specific warts.

There are simple reimplementations like hyperapp and preact and I completely recommend using those instead. I really meant React the library and ecosystem are at fault, not the general model.

(which is not specific to React but more like an issue for any framework that tries to do everything)

I seem to remember boot times being a frequent topic of discussion the early 2000s, because people turned off their computers.

In a way, this is a great little microcosm of the problem. Just fix habits instead of fixing the software.

That being said, there's a lot of crap software out there that's slow even on 2020 hardware.

That's already the case, your orders of magnitude are just off. Long-running AJAX or page loads are timed out at a pretty consistent point across browsers. Half-open/closed TCP connections are timed out at a pretty consistent point across operating systems. Busy-looping JS gets you a "page is not responding" block in a similar amount of time; same for nonresponsive native applications on many operating systems.

Their definition of "slow" or "stuck" just tends to be "tens of seconds or minutes", not the threshold of perceived responsiveness you want in a website.

Also, your parenthetical is a pretty tall-née-impossible order:

> a slow website (relative to the task)

How could the "task" be classified? Do you mean "task" as in "clicking a button and having a DOM update"? Or as in "this is a TODO application so it should have responsiveness threshold X"?

When I talk about sending 8 KB in a "networked action game", I'm referring to the update packets sent to and from clients in something like Fortnite or Counter-Strike, not a game patch. I'm not trying to make a competition for who uses the least bandwidth (which a 60 GB game would lose just on the initial download). I'm trying to illustrate that games don't run faster than some website because it's inherently easier to make games run fast, but rather that developers, by necessity, optimize games until they run fast (or in this example, until they reduce network lag enough).

I'm not sure why a chat app would tack on something like 7.5 KB of overhead on a chat message, but I wouldn't be surprised if there's a chat app out there that does so. Users won't notice the extra couple milliseconds (especially so because they don't know exactly when the other person hit send). A 3 character Discord message is close to 1 KB including the headers. The same message over UDP in a game might be under 20 bytes, including the UDP header (games could also use TCP for chat - text chat isn't going to strain anything). So I'd say the overhead of a Discord message is still an order of magnitude or two bigger than it could be. Which is perfectly fine; we can afford 1 KB of overhead on a modern connection. It's optimized as much as it needs to be.

I wouldn't be at all surprised if it's the majority. For every big-ticket software offering there's going to at least be things the user never interacts with, like a build system and a test suite and a bug tracking system and whatever else. And there's just so much software everywhere, most of which we never see. Every small business has its little web site. Who knows how much software there is powering this or that device or process at random factories, laboratories, and offices.

The Debian popularity contest looks like it has a big long tail of relatively unpopular packages [1]. It looks like the app store has 2 million apps, only 2857 (.14%) have more than a million dollars of annual revenue. These are of course incomplete and flawed and do not really directly address the question. I don't really know how to research this in a thorough way.

[1] https://popcon.debian.org/by_inst [2] https://expandedramblings.com/index.php/itunes-app-store-sta...

But perhaps the answer is VMware Fusion instead then.

But this means that anything that's not represented in telemetry gets completely ignored. The numbers won't show you how many of your users are pissed off. They won't alert you to the majority of bugs. They won't tell you if you have a bloated web application that's stuffed full of advertising. They won't tell you if your UI is incoherent.

I really do think that large companies are looking at the numbers instead of actually using their software, and the numbers say that everything's fine.

In my experience, a lot of performance problems boil down to really stupid problems, like simple code using the wrong data structure out of convenience (e.g. linked lists instead of arrays for lots of randomly-accessed data), or structured in a bad way (e.g. allocating a lot of small pieces of memory all the time). Often times, there are cheap performance wins to be had if you occasionally run the product through a profiler and spend couple of hours fixing the most pressing issue that shows up. Couple of hours isn't much; there's enough slack in the development process to find those hours every month or two, without slowing down your regular work.

Bonus points if it also lists the before and after streets at direction changes so people know if they missed a turn.

This could be implemented as a proxy to either of the maps apps (Google, Apple, OpenStreetMap)

On my phone it takes about 4-5 seconds to load even on Gbit WiFi. It's so bad I have a conspiracy theory that the pulsing Reddit orb is just on a timer and it's not actually loading anything. More likely it's just horrifically unoptimized I suppose.

In the end the backend was pure and beautiful, but the the frontend devs had to perform joins in the the client and make 21 API calls in a 20-item list and then everything goes to hell.

Consider a loading spinner with a line of copy that explains what's happening. Say it's for an action that can take anywhere from 20 milliseconds to several seconds, based on a combination of factors that are hard to predict beforehand. At the low end, showing the spinner will result in it flashing on the screen jarringly for just a frame. To the user it will appear as some kind of visual glitch since they won't have time to even make out what it is, much less read the copy.

In situations like this, it's often a good idea to introduce an artificial delay up to a floor that gives the user time to register what's happening and read the copy.

I like them, but I've found that they make a bit too conscious about the sound, so I have to be extra careful. The isolation emphasizes noise and frequencies that the monitors don't, and that will be masked in the full mix. It used to lead me to a rabbit hole of noise-gating and EQs.

It's a real case, actually. I don't remember a name, but I've encountered this situation in the past, and that brief flash of a "in progress" marker was what I used to determine whether me clicking a "retry" button actually did something, or whether the input was just ignored. It's one of those unexpected benefits of predictability of UI coding; the less special cases there are, the better.

If you consider yourself a world-leading expert on neural networks and have some secret sauce in mind, by all means, good luck... otherwise it sounds like a fools errand.

Also I'll bet you that your neural net is > 100x slower than straight line code.

I imagine it would be fast, then you realise you've made a static content caching layer out of a neural network and replace it with Varnish cache and it would be hyper fast.

I'm not sure I'd like a http webserver to silently fail, or be undebuggable when it comes to security vulnerabilities when given strange inputs.

The object returned by the function expresses a tiny subset of the properties of a DOM node. Often just {className, childNodes: [...]}. Only those explicit attributes are checked for update or otherwise dealt with by my code. My code has no idea that a DOM node has a thousand properties. By contrast, a ReactComponent is more complex from a JS POV than a native DOM node.

In other words, if my code returns: {className: 'foo'} at time t0, and then returns {} at time t1, the className in the DOM will be 'foo' at t0 and at t1. That is not at all how exhaustive tree diffs work, and not at all how react works.

With 5,000 nodes, you might have 8K-15K property comparisons. Per-render CPU load thus grows linearly and slowly with each new node. I can re-render a thousand nodes in 2-5 milliseconds with no framework churn or build steps or any of that. But more importantly, we have the ability to step into "straight-to-canvas" mode (or whatever else) without rupturing any abstractions and without awkward hacks.

This is unidirectional data flow plus component-based design/organization while letting the DOM handle the DOM: no fake elements, no fake events -- nothing but utterly fast strict primitive value comparisons on shallow object properties.

EDIT: Earlier I said that a node changes if and only if its state description changed; that is not strictly true. "if and only if" should just be "only if".

Literally anything built with NPM: megabytes? tens of megabytes? in size, totally inscrutable, code being pulled in from hundreds of megabytes of code in tens of thousands of packages from hundreds or thousands of people of unknown (and unknowable) competence and trustworthiness, if it breaks not only do you not know who to blame but you probably have literally no idea what wrong.

Yeah, jQuery was probably better.

Reading Computer Lib/Dream Machine over the holidays and I wonder where it all went so wrong.

So there are reasons to prefer more imperative languages and their systems, but stack-smashing isn't one of them.