1. 49
  1.  

  2. 31

    Modern cars work … at 98% of what’s physically possible with the current engine design.

    Ignoring the fact that ICEs are thermodynamically constrained to something closer to 20% efficiency, “current engine design” is quite an escape-hatch. Computer software and hardware designs, similarly, are subject to “current designs”, and there’s no reason to think that SWEs are somehow less inclined to improve designs than mechanical engineers.

    Only in software, it’s fine if a program runs at 1% or even 0.01% of the possible performance

    There is no objective “possible performance” metric. There’s only “current implementation” vs “potential improvements gained by human attention”.

    Everything is unbearably slow

    No. kitty is fast. ripgrep (and old grep…) is fast. Mature projects like Vim and Emacs are getting faster. JITs and optimizing compilers produce faster code than ever. Codecs, DSP are faster than ever.

    Yes, tons of new software is also being created and power law effects guarantee that most of it will be low-effort and unoptimized. The fact that you can scoop your hand into an infinite stream and find particulates, means nothing.

    Text editors! What can be simpler? On each keystroke, all you have to do is update a tiny rectangular region

    If that’s all you expect from a text editor then your computer can do it very quickly. But you chose to use a text editor that does much more than that per keystroke.

    Build systems are inherently unreliable and periodically require full clean, even though all info for invalidation is there

    “All info” is not there. Most builds have implicit state created by shell scripts, filesystem assumptions, etc. That’s why conforming to bazel or NixOS is painful (but those projects are examples of people working to improve the situation).

    Machine learning and “AI” moved software to guessing in the times when most computers are not even reliable enough in the first place.

    :)

    Spin another AWS instance. … Write a watchdog that will restart your broken app … That is not engineering. That’s just lazy programming

    That’s how RAM ECC works, that’s how MOSFET works. Failure is an inherent property of any physical system.

    I want state-of-the-art in software engineering to improve, … I don’t want to reinvent the same stuff over and over

    I agree with that. Clojure and urbit are efforts in that direction. Taking code-reuse and backwards-compatibility seriously, allows us to build instead of repeat.

    But dispense with the nostalgia for DOS and the good old days. CompSci artists ignore cost/benefit. Engineers consider economics (cost/benefit, not just “money”, all costs).

    The bulk of new activity in any vigorous market will be mostly trash, but the margins yield fruit. High-quality software is being built at the margins. The disposable trash is harmless, and serves a purpose, and will be flushed out as users adjust their relative priorities.

    1. 4

      Mature projects like Vim and Emacs are getting faster.

      Ignoring the fact that older software had to be optimized in order to run on older computers, a bit of this is survivorship bias. People don’t use the old bad programs anymore or they got fixed.

      Older software crashed a lot and it corrupted your documents. Today, even if it crashes you probably won’t lose anything. To an extent, this is the result of consciously trading performance for correctness.

      1. 1

        Ignoring the fact that older software had to be optimized in order to run on older computers,

        You’re making assumptions. Emacs and especially Vim have many unoptimized components. Vimscript, the core language of Vim, doesn’t even produce an AST, it re-parses every source line over and over (including while-loops/for-loops). Only recently has this got attention. Fixing it takes human time, and now the human time is being spent on it because relative priorities arrived there.

        survivorship bias. People don’t use the old bad programs anymore or they got fixed.

        The converse is that every program that touches a computer should be optimized before it reaches a user. That makes no sense.

        1. 1

          You’re making assumptions.

          No! You! :)

          I didn’t mean to imply that they are perfectly optimized. I meant that they had to perform more optimization to run on older computers than modern software might have to make to run on newer computers.

          The converse is that every program that touches a computer should be optimized before it reaches a user. That makes no sense.

          I don’t think every program should be optimized. I don’t follow what you are saying here.

          1. 1

            I don’t think every program should be optimized.

            Then it does not make sense to discount good software as mere “survivors”. It is a contradiction. Good software takes time, bad software gets filtered out over time. In the interval, there will be bad software, but that is because more time is needed for good software to take its place.

            1. 1

              Good software takes time, bad software gets filtered out over time. In the interval, there will be bad software, but that is because more time is needed for good software to take its place.

              I agree. The comment about survivors is about how not every piece of software from an era is as good as the software from that era that we use today. I.e., the survivorship bias fallacy:

              https://en.m.wikipedia.org/wiki/Survivorship_bias

      2. 2

        Actually, measured by latency (which is almost certainly the benchmark you care about in a terminal emulator), kitty is moderately fast and extremely jittery, just like alacritty. Both Konsole and Qterminal perform substantially better every time I benchmark them, especially if you have a discrete GPU instead of integrated graphics.

        1. 1

          Fast software exists, that’s my point. You’ve provided more examples of fast software.

        2. 1

          So, I think you maybe be misinformed about the cars thing. ICEs and turbines can get between 37 and 50ish percent efficiency by theoretical maximum, and real-world engines get very close to that.

          This is important when you look at the claimed efficiency of computers: a modern multi GHz CPU should be capable of billions of operations a second, and for any given task it is pretty easy to to make a back-of-the-envelope calculation about how close to that theoretical ideal we are–that’s one of the ways efficiency in traditional engineering fields is calculated.

          We are seeing efficiencies of tens of orders of magnitude smaller than seems reasonable. There are reasons for this, but the fact is inescapable that anybody saying “we really use computers inefficiently” is not wrong.

          Also, on the restarting the app bit–it is one thing to use ECC to compensate for cosmic ray bit flips, or to mirror data across multiple hard drives in case one or two die, as a way of doing reliability engineering. It is something else entirely to, say, restart your Rails application every night (or hour…) because it leaks memory and you can’t be bothered to track down why.

          1. 3

            It is something else entirely…

            Is that ‘a difference in scale becomes a difference in kind’?

            They seem like the same kind of thing to me, just at very different points on the effort/value continuum.

            1. 2

              Statistical process control is a tool we can use to answer that.

              If the problem is predictable enough to count as routine variation inherent to the system, we should try to fix the system so it happens more rarely. (And I’d argue the memory leaks that force you to restart every hour belong to that category.)

              If the problem is unpredictable and comes from special causes, we cannot generally adjust the system to get rid of them. Any adjustments to the system due to special causes only serves to calibrate the system to an incorrect reference and increases the problem. (This is where I’d argue cosmic radiation belongs.)

              Another way of looking at it is through the expression that “you cannot inspect quality into a product”, meaning that continually observing the system state and rejecting the system when it goes out of bounds is a way to ensure only systems within limits are running, but it is very expensive compared to ensuring the system stays within bounds to begin with. It is only acceptable for cosmic rays because we can’t work the cosmic rays out of the system, so we are regrettably forced to rely on inspection in that case.

              1. 2

                Memory errors are not unpredictable; for a given stick of ram, the rate of bit flips is not that hard to figure out (takes quite awhile to get good numbers for ECC sticks).

                We adjust this by adding error correction codes.

                RE memory leaks: a memory leak isn’t worth chasing if it’s not causing trouble. I have inherited an app that uses the “restart every hundred requests” strategy and I cannot fathom that ever being on my top ten problems. My users don’t care, and it isn’t expensive. I dislike the untidiness, and would probably fix it if it was a side project.

                1. 1

                  Indeed. Volatile RAM is a horrible hack (continually refresh capacitors, waste power) compared to NVM. The cost calculation is clear there, so few complain about it. But the cost calculation of “human attention” is less clear to puritans who think that lack of Discipline and Virtue is what prevents a utopia of uniformly better software.

              2. 1

                ICEs and turbines can get between 37 and 50ish percent efficiency by theoretical maximum, and real-world engines get very close to that.

                I said “closer to 20% [than 98%]”. I didn’t bother to look up the actual number. 50 is closer to 20 than 98.

                a modern multi GHz CPU should be capable of billions of operations a second, and for any given task it is pretty easy to to make a back-of-the-envelope calculation about how close to that theoretical ideal

                • Why do you assume that the current hardware design is the theoretical ideal?
                • CPU saturation as a performance metric assumes that the instructions are meaningful, not to mention TFA is concerned about an over-abundance of instructions in the first place.
                1. 1

                  I said “closer to 20% [than 98%]”. I didn’t bother to look up the actual number. 50 is closer to 20 than 98.

                  I am not sure that you are interpreting those numbers correctly. There are two numbers: the ~37-50% efficiency allowed by physics, and the 98% efficiency in achieving that theoretical efficiency. The former is a measure of how good an ICE can ever be at accomplishing the goal of turning combustion into usable mechanical energy, the latter is a measure of how well-engineered our engines are in attaining that ideal–only the latter we have any control over.

                  Why do you assume that the current hardware design is the theoretical ideal?

                  There may well be a more efficient means of computation out there! In the mean time, it seems reasonable to look at the theoretical max performance of real silicon we have on hand today.

                  1. 0

                    There are two numbers: the ~37-50% efficiency allowed by physics, and the 98% efficiency in achieving that theoretical efficiency.

                    That’s why I said “Ignoring…”. Also mentioning “thermodynamic limit” is a pretty clear signal that I’m aware of the difference between physical limits and engineering tradeoffs. OTOH combustion itself is a design choice, and that is a hint that the distinction isn’t so obvious.

                    You chose to comic-book-guy that part of the comment instead of focusing on the part that didn’t start with “Ignoring”.

            2. 8

              Love the article. Gotta call this one out, though:

              “But who has time for that? We haven’t seen new OS kernels in what, 25 years? It’s just too complex to simply rewrite by now. “

              That’s been BS. OpenBSD is the longest-running proof. DragonflyBSD a more recent one. Minix 3 kind of halted but got massive deployment by Intel. The Solaris 10 rewrite cost almost $300 million but had huge benefits. Microsoft made their own implementation of Linux that will be important for their long-term competitiveness. Lots of smaller projects such as Genode and Redox OS ongoing.

              They all prove you definitely can rewrite or clean-slate some of this software. Whether you should is another matter. For legacy rewrites, modern tooling for code analysis/transformation and equivalence testing makes it easier than it used to be, too.

              1. 12

                TempleOS should probably be on that list too.

                1. 6

                  Definitely. It’s both an example of clean-slate and in its own category altogether.

                  The bigger slip was not mentioning the Oberon System(s). Heck, that even started when Wirth was shown a personal computer at Xerox PARC, not allowed to buy it, and then (Lilith project) they made their own hardware/OS/language/everything.

                2. 3

                  seL4 too, as an OS kernel.

                  the way I see it is that there was an evolutionary explosion and then collapse for the personal computer market.

                  1. 2

                    That’s a good point on PC market. That brings us to MorphOS and Haiku of Amiga and BeOS legacies. Maybe throw ReactOS in there for Windows.

                    1. 2

                      Yeah. Looking backwards in time from today produces sort of a narrowed vision of what actually occurred, since a lot of options failed.

                      I went to White Sands Missile range’s public aircraft museum once - its this small place far away from anywhere, in New Mexico. There are a ton of designs that are wiiild from the 40s-60s. For whatever reason, they didn’t pan out. You’d have to be an educated person in the field to actually know they existed, because they are not directly inferrable from the designs you see on an airfield today.

                      The IoT/embedded field has a lot wider varieties right now than the PC market. Phones, oddly, don’t. Not perfectly sure why that is, myself. Best guess is locked bootloaders and focus on consumers, rather than developers.

                      1. 2

                        Phones, oddly, don’t

                        It could be because stuff around EM emissions is so fraught with regulation, it’s simpler to build on existing, approved systems. Even if these are technically outside the phone’s operating system itself, it’s non-trivial to write a driver for, say, a UMTS chip in an OS that’s not “popular”.

                3. 8

                  The problem with this article is that he misses the point most of the time. Software development is an economic activity.

                  For instance:

                  You would expect programmers to make mostly rational decisions, yet sometimes they do the exact opposite of that. E.g. choosing Hadoop even when it’s slower than running the same task on a single desktop.

                  Most programmers are doing rational decisions: They are optimizing their personal revenue prospects by acquiring skills more desirable to the market than by optimizing the speed for their employer product.

                  There is no economic incentive to optimize software only on speed, customers will usually flock to apps/systems that solve their business problem rather than well developed, and that is the reason we are where we are. That quote the article did on Python vs. Rust is a great example, even if you optimize something technically, it might bring no benefits on the real use case scenario.

                  I don’t believe there is such a thing as progress, only evolution, and evolution don’t mean better. And that is real for anything, it’s a historical framework. The notion of progress is a positivist notion of history, that sees humanity as constantly progressing technologically, it’s a nice start trek dream, but very outdated as a view of history. And the author realized there is no such thing as progress, only economical forces shaping history and technology in certain ways, but it’s baffled by it.

                  That’s the way it always been. The great technological revolutions never happened isolated from their economical and historical setting, so it’s naive to believe that for some reason it would be that way with software and IT.

                  Microservices -> Microservices on Containers -> Microservices on Orchestrated containers is evolution, you might argue it’s not progress, but it’s definitely evolution and it makes sense if you think on the economic incentives that engineers have in their work environment.

                  1. 4

                    There is no economic incentive to optimize software only on speed, customers will usually flock to apps/systems that solve their business problem rather than well developed, and that is the reason we are where we are. That quote the article did on Python vs. Rust is a great example, even if you optimize something technically, it might bring no benefits on the real use case scenario.

                    Is this true, though? A lot of people believe it, but I haven’t seen any real-world comparisons that customers aren’t bothered by slow speeds. I’ve seen people stop using software that solved business problems because it was too slow.

                    Another example: Firefox. For a long time people weren’t using firefox because chrome was faster.

                    1. 3

                      That’s fair I generalized too much. I would change to “It’s rare to have the economic incentive to optimize software on speed alone”.

                      Most users are usually bothered by slow speeds, but they are not impressed by super fast speeds. But also that wouldn’t apply to something like a browser, where speed is a huge selling point, but on 99% of products, is not as major.

                      1. 1

                        I think users care about speed and stability much more than we think. I think the problem is that other than in extreme circumstances, it is much easier to for customers and management to express requirements in terms of features (either they exist or they don’t) rather than more fluid concepts such as speed and stability (what does “fast” and “stable” mean, and how do we know when we have achieved it?)

                        A big part of this, I think, is teaching management and customers about performance and reliability engineering on a high level; giving them the mental tools to start expressing requirements in terms of uptime, time-to-fix, 99.9th centile response time, worst case response time, throughput, and so on.

                        (Of course, this is a hard task: who wants to teach their customers to be more demanding? If you withhold your customers the tools they need to express their demands, you can sort of live in an imaginary world where you pretend those demands don’t exist. As long as everyone does this, we sit at a great inadequacy equillibrium.)

                        1. 2

                          In addition, the price signals really aren’t there anymore.

                          When a BigCorp orders some software, the end users are almost never consulted early in the process. So there’s little signal from them indicating that speed is an issue.

                          For the rest of the world, you have “free” (ad supported) content, “free to play” games, and really really cheap apps. A ton of functionality is provided by open source software. The little that’s left (games, software like audio/video processing) does tend to take performance seriously, in my experience.

                      2. 2

                        I don’t believe there is such a thing as progress, only evolution, and evolution don’t mean better.

                        People throw around “worse is better” when I think what they mean is “worse is fitter” where fitter here means survival of the fittest.

                        1. 1

                          “Worse is better” originally references a software design philosophy where one focuses on getting quickly to a simple implementation that is reliable and performant, and only then think about extending it to provide additional functionality. The emphasis is on simple implementation. As long as it means the implementation can stay simple, “worse is better” advocates creating complicated interfaces and stripping out desired functionality. The goal is to get to a core that is rock solid, and when that core is at a state where it barely needs any maintenance, you can build more complicated things out of it.

                          This can be put in contrast with e.g. “good enough software” where you decide on a minimum set of features you think your customers want, and then implement them all poorly, but just good enough for your customers to want to use your product anyway. After that, you try to improve your initial implementation while adding new features.

                          The other extreme end of that scale is usually referred to as “the right thing” were implementation complexity is not considered as important as interface complexity, and you focus on building all the right abstractions to support all use cases at once. Naturally, “the right thing” tends to devolve into “good enough software” given market pressures to complete things on time.

                          1. 2

                            Yeah, I understand where the original phrase came from; I just think the word choice implies a value judgement that wasn’t necessarily intended in the first place. Worse is “better” in that it’s better adapted to its environment and more likely to dominate its competitors, and I think “fitter” describes that more accurately than “better”.

                      3. 20

                        You know, I could get on this train, but I suddenly realized that the advent of the JVM-killer, the web-browser, brought me the first Year of the Linux Desktop. Previously: no apps. Now: slow apps. This is an improvement.

                        1. 6

                          As far i remember, you could install applications on most operating systems. I don’t really see the “no apps” state in history that would the current state make seem like an improvement.

                          1. 1

                            I think you are referring to the openness and compatibility created by HTML, CSS and js - hardly examples of excellent engineering. It took decades of format changes; their compatibility is still questionable; and now they are being even replaced by phone “apps”.

                            Not to mention the amount of bandwidth and RAM used.

                            Yes, it’s an improvement over “no apps”, but the article is about “our industry’s lack of care for efficiency, simplicity, and excellence”

                            1. 7

                              The perfect is the enemy of the good. JS/HTML/CSS is here now and solves real problems.

                              1. 2

                                Real problems like “most people don’t have a package manager” which don’t actually apply to me, you mean?

                                1. 5

                                  Nope, I don’t mean that :D

                                  I mean stuff like VS Code being available on Linux, as is Slack. That kind of thing.

                                  And it’s really easy to slap together a simple mobile app.

                          2. 6

                            I fully agree with the sentiment, however..

                            If we care, people will learn. And there’s nobody but us to show them that it’s very much possible. If only we care.

                            ..but someone will have to pay us for caring. And that someone is probably not an engineer.

                            1. 7

                              Modern buildings use just enough material to fulfill their function and stay safe under the given conditions.

                              The hell they do. “Safety factor” is a thing, and it’s not thrown around lightly.

                              Also, given conditions are a start. They have to weather the elements, which are never a given.

                              1. 21

                                enough material to fulfill their function and stay safe

                                The hell they do. “Safety factor” is a thing, and it’s not thrown around lightly.

                                Civil engineer here.

                                What I think was meant: after safety factor and all other considerations were taken into an account, say you get that your minimal cross section should be 191 cm2. You would round it up to 200 cm2 to be (a bit more) on the safe side, and use that.
                                You cannot eye-ball it without a calculation and then say “I’ll use 5000 cm2 cross-section, that should do it”.

                                1. 5

                                  Factors of safety are what let us use the minimum of material. If we didn’t bound the upper limit of FoS, for example, every parking garage would be a tremendous pile of concrete instead of decked slabs and trusses.

                                  Elementary are also a given, roughly. That’s why Galveston beach houses are on stilts (and are cheaply enough built to be replaced when the occasional hurricane overpowers them) and why skyscrapers in places with strong winds may have active compensation to offset oscillations due to gales.

                                2. 4

                                  metacomment: Fascinating to see lobsters taken over by people who are fully homo economicus, and equate good software with business value.

                                  The answer is really to be looking to create legal liabilities for defective software. If the software doesn’t perform to spec, lawsuits civil and up to criminal should be applied. Otherwise you’re in a barely controlled race to the bottom for commodity goods.

                                  1. 2

                                    As a first-order analysis tool when examining human behavior,the homo economicus view is generally very helpful. Care must be taken to see it as descriptive, not prescriptive.

                                    create legal liabilities for defective software.

                                    Another approach to creating better quality software would be to enforce a professional standard on software developers (akin to lawyers, MDs, and engineers in some jurisdictions). It’s quite possible that enforcing legal sanctions would quickly lead to such a situation.

                                    In both cases, it would be more expensive and time consuming to develop software.

                                    1. 1

                                      In both cases, it would be more expensive and time consuming to develop software.

                                      Given that software is so intertwined with our lives, I think not being able to deliver ultra-cheap junk to users is perfectly fine.

                                    2. 1

                                      create legal liabilities for defective software

                                      How authoritarian.

                                      1. 1

                                        much like legal liabilities for engineering, yes, definitely. /sarcasm

                                    3. 2

                                      It’s funny that the OP uses a car analogy, when even clear-cut drop-in replacements like hybrid cars that would enable massive efficiency gains see sluggish adoption (according to JP Morgan, hybrid + pure electric vehicles are expected to reach 30% of sales by 2025: no, not usage share, sales). After all, it doesn’t really matter much how close to the theoretical max efficiency under load you get when your car spends a significant fraction of the time idle at a stop sign or in traffic.

                                      1. 1

                                        So far I have not seen any compelling arguments, other than aesthetic ones, that software “bloat” is a bad thing.

                                        Looking at the big picture, reducing ICE car emissions by a few percent will dwarf any energy savings from “lean code”. This is just an example.

                                        If bloated software starts to impact users in a meaningful way - i.e. more and more users have to opt out of buying a new phone every 2 years - then development practices will adjust to reflect this. Trust the market.

                                        1. 8

                                          Certainly “bloat” by itself is a rather imprecise term, and it’s good to think about exactly what aspects of software we mean by it and in what circumstances they are and are not a problem, rather than just being upset in the abstract that a modern web page is bigger than windows 95.

                                          I do think it’s accurate to claim that UI latency is more of a problem in commonly-available software than it should be. I personally encounter this most often using Javascript-heavy webapps in mobile Firefox on Android phones, and I think it’s fair to say that my experience of using web page UIs is actually kind of bad in a way that I’ve more or less gotten used to. It’s also fair to attribute this UI latency to software bloat in a few different senses - the initial download of a webapp as well as requests it makes while it is running take longer if there’s more bytes to transfer (particularly on spotty internet connections), those bytes also increase cache evictions (I don’t know how much of a problem the instruction cache is on a smartphone like the one I have), and increase the probability that the phone OS will wipe out some state I cared about saving in the name of reducing memory or power use.

                                          In a more abstract sense, there’s bloat in the sense that modern webapp designers are building UIs on top of many layers of node packages, most of which they don’t understand, and all of which offer an opportunity to accidentally introduce pathological performance behavior - it’s pretty easy for a naive javascript programmer to write code that mutates the DOM in a dumb way or too many times in a loop, and this manifests itself as typing text into a form on a webpage on a smartphone suddenly becoming incredibly slow. I’ve been on both the implementer and user side of situations like this. And of course abstraction bloat isn’t unique to the javascript webapp ecosystem, although I think node does encourage it - there’s a lot of abstraction stacks between the phone hardware and the laggy web form that aren’t the browser, and any one of them could also be introducing some pathological behavior.

                                          There’s an additional sense of what I might call interface bloat in the specific case of the web browser. Browsers are so complicated and do so many things in evolutionarily-complex ways that it’s difficult for private individuals or teams to produce new browsers from scratch. This manifests itself as there being exactly two browser engines that actually render modern webpages, and the absence of serious competitors to Mozilla and Google.

                                          Anyway, I don’t think that software that’s bloated in this sense - in being written in ways that make it hard to reason about reducing noticeable latency - actually impacts users in an incentive-changing way. Input lag is an annoyance, but a tolerable one in exchange for having a pocket-sized device that can access the web and otherwise do useful network-connected work. I think that software written in completely novel minimalist stacks has a chance of supplanting traditional bloated software in some cases, but the fact is that such novel minimalist software is never very feature complete, and bloated+featureful winning in the marketplace compared to minimalist+few features, is exactly what the status quo looks like.

                                          1. 4

                                            Thanks for taking the time to respond.

                                            I agree (in part) about input lag.

                                            A lot of the “corporate portals” I come in contact with are also like this - buggy unstable masses of web cruft piled on top of each other.

                                            What kind of bothers me about this latest week’s discussions about “bloat” (for example here, and this post (which I know is a year old) is that it’s implicit that the problem is JS/Node/Electron, but it’s expressed as a sort of original sin that started to appear as soon as someone started coding in anything other than pure K&R C. This confuses me (who can’t code myself out of a wet paper bag using JS), and it muddies the water a great deal.

                                            I’m fully confident that the Electron ecosystem will gradually become faster, more efficient, and easier to work with. Efforts should be made to address the real causes, not bemoan some sort of lost Golden Age when everyone uses PDP-11s and a megabyte was an unimaginably vast number.

                                        2. 1

                                          Yes, Wirth’s law exists..

                                          Most groups I’ve worked with don’t care about performance until it gets very bad, even if only 20% of features they’re cramming in are used. You’ll see unit and integration tests, but few (if any) looking for performance regression or measuring program memory footprint and amount of network traffic.

                                          It’s not just memory or CPU performance though. Many programs wake up periodically or send obscene amounts of telemetry. I had an issue once with a Windows box slugging along with nearly 0% CPU reported, but there were 10k context switches/second wrecking performance going on due to seemingly innocuous and “idle” programs waking up.

                                          1. 2

                                            1995 article “A Plea for Lean Software”

                                            Heh. Nothing new under then sun.

                                          Stories with similar links:

                                          1. Software disenchantment via freetonik 2 years ago | 42 points | 12 comments