I've read the article: I'm more furious at the author's handwavy criticisms than anything else. Going down point by point: > 1. Good hardware is masking reall

I've read the article: I'm more furious at the author's handwavy criticisms than anything else. Going down point by point: > 1. Good hardware is masking really bad software. This point assumes that there isn't any other reason other than "developer laziness" that bad software exists. It glosses over the fact that "wasteful" development practices are often hoisted onto developers due to the need(s) of: - Making the software grokkable/comprehensible for new/incoming developers - Ease of software maintenance (related to earlier point) - Limiting failure states of the software in question (related to earlier point) - Time constraints & mandated requirements from 3rd parties (often business/legal people that focus on "get it done", rather than the necessity of such constraints/requirements in the first place) ------ > 2. All the bad code is piling up, and we don’t know how to get rid of it. The author failed to mention that the edge cases encountered in the wild & the additional complexity needed to accommodate them are often the main reasons for such "bad code" existing in the first case. The aforementioned edge cases, along with the time constraints & mandated requirements, are what lead to "bad code", along with feverent disapproval of its removal due to <insert edge case/legal requirement/business case here>. ------ > 3. Programs used to be pipeable. Now, GUIs are killing pipes. This is in large part due to the unwillingness of (a whole lot of) non-developers to learn how to use pipeable tools in question, instead hoisting it back onto developers to "give me something that *I* can work with". This is fundamentally a social issue that hasn't been addressed at all, in that the increased self-voluntary infantilization of the general public is inducing demand for GUIs. There are definitely non-developers that decry this trend of simpler-&-worse GUIs, but the silent majority have altogether said that "this is fine", and that they're willing to be coddled in order to obtain the luxuries that they desire, even if it induces further infantilization. ------ > 4. Computers are telling me what to do, but I can’t tell them what to do. This is again related to (3), and the self-infantilization that a lot of people are willing to undergo for the sake of convenience. It also exposes the author's unwillingness to take the necessary steps in order to perform the self-customization that they so desire. This point also glosses over the reality that as the number of possible configurations increases, the number of possible failure states grows at least linearly at the same pace, with said failure states often growing at a multiplicative pace in proportion to the number of possible permutative states of configuration. Is it no wonder that in an effort to decrease the surface area of failure states, that said configurations are walled off in favor of funneling everyone towards the default? ------ > 5. Software is not technology. It is ideology. The quote that the point entirely uses rests on 2 points: 1) Hollywood's system, when compared against software development, has someone assuming directive control, whereas software doesn't have such a person. 2) There's an equivalency whereby (interactive software == movies) (1) does exist in modern software development, with the list of requirements & general architecture drawn up by product owners & lead developers respectively, with overall development handled by the rest of the development team. (2) is false due to the fact that whereas movies only need to showcase 1 linear series of synchronized video & audio, interactive software has to account for all possible interactions with the software itself. A more proper analogy that could be drawn would be choose-your-own-adventure novels, from which interactive text-based games were partially derived from. Even so, said novels do not have to deal with malformed inputs, & the choices given by the novel do not need to internally carry state. ------ > 6. Computers are fast, but in the dumbest way possible. The point in question is potentially performing a lie via omission, in that the author left out the rest of the interview that they were quoting from. (http://worrydream.com/refs/Mead%20-%20Gene%20Youngblood%20Interview.pdf http://worrydream.com/refs/Mead%20-%20Gene%20Youngblood%20In...) (Side note: The interview in question, even if there is no concrete date for the interview, can de dated to the early-to-mid 80s, due to the interview's usage of terms like floppy disks (pg. 18), the Intel 286 processor (pg. 5), & the 1.5um silicon manufacturing processes (pg. 4). Since then, SIMD, GPGPU programming, and compiler-derived vectorizations & optimizations have allowed for further performance improvements, on top of the increased CPU performance that has accrued since then.) In said interview, Carver lays out that the 10000x solution being touted are none other than FPGAs & ASICs: |> GENE: What do you call the kind of architecture you're talking about? |> CARVER: I call them silicon algorithms. You just map the application right into silicon. And the technology for doing that we understand pretty well. I don't mean we've worked it all out. But we've developed the technology for taking high-level descriptions and putting them on silicon. It's called silicon compilation, which is the obvious next step. You need to compile things right down into the chip instead of compiling them into some code that you feed to this giant mass of chips that grinds away on it trying to interpret it. |> GENE: So the silicon compiler solves not only the complexity problem but also the problem of massively parallel architectures by allowing us to experiment with the dedicated hardware that alone can realize the full potential of that architecture. |> CARVER: You bet. Otherwise there's no hope. Because then you're stuck. If it takes five years to design a chip nobody's going to experiment with algorithms in silicon, right? Because it takes years to get any place. And that's in series with your learning curve. So you have to have a technology for experimenting with designs in silicon more rapidly than that. Ironically, the inability to customize, which was lamented in (4), are further compounded by the crystallization of algorithms into "silicon algorithms", whether via FPGAs or ASICs: The algorithm in question becomes much harder to modify as it descends downwards from general software into silicon gates, with any bugs/mistakes requiring much larger efforts to fix them. ------ > 7. No one knows what they’re doing, and it’s a civilizational problem. The entire point rests on the axiom that unless everything with a system can be understood by a single person, said system shouldn't be built. This is nothing short of a "complex == bad" type of thinking, wherein in order for something to exist, everything from top to bottom has to be understandable to a single person. Leaving aside the fact that the same sort of thinking can be applied towards everything else in modern society (modern plumbing & electrical systems, cars/planes/trucks/<insert transport here>, legal/tax laws, institutions/bureaucracies, economics, geopolitics, modern medicine, etc.) & that there's no sort of alarmism from the author applied to said things/systems, the author fails to recognize the fact that the distribution of responsibilities is the foundation of modern civilization, and that the resulting specializations & improvements made towards each component of the entire system results in a system that is overall better off than if everyone w forced to build everything themselves. There are definitely some technical debts that can be removed from each part of the overall system, but to say that everything more complex than what can fit in one person's head should be barred from existence is a exceedingly prescriptive way to view how the author's ideal society should function. ------ All in all, the author has not realized that they've willingly allowed themself to undergo software infantilization, nor have they (at least publicly) done any steps towards weaning themselves off from the process itself, *WHILST* having the gall to complain to the world about how "everything about computers now = bad". They've not publicly shown any willingness to at least take the bare minimum in software self-discovery in the first place.