I believe the author ascribes most non-local problems to "incidental complexity". Incidental complexity introduces bugs, which in turn make code less predictable, which causes non-local problems. Furthermore, Grainger focuses on carrying out non-destructive data transforms, à la functional programming, which alone should wipe out a large percentage of non-local problems, as you shouldn't find yourself having to chase down any erroneous value-change bugs.

In fact, Grainger's whole point is about the attitude that you express being typical -- we focus on the fixing the problems created by the imperative programming paradigm within the imperative programming paradigm, rather than simply replacing the imperative paradigm with something more appropriate.

This essay is basically what all our CS lecturers have been saying for the last 40 years....

Ah, but the thing is that the back-end that allows the formula to be shown in a mathematical notation is an abstracting backend. In current programming, the formula has a machine representation that maps to a single visual representation. Once we start storing abstract forms, we can let the IDE present it according to the user's wishes and knowledge.

... and herein lies one of computing's biggest paradoxes. We are obsessed with plaintext as being the only suitable format for code because it is "human readable", yet almost every coder on a project of any scale uses an ID with autocompletion etc. The IDE would be much easier to use if it was freed from the constraints of plain text -- rather than linear code ordering, we could order instead by dependencies, and display on screen left-to-right ordered by call when viewing the logic. Away from plaintext, we could start using standard mathematical notation for mathematical problems (see also TFA). We could eliminate most typo bugs by simply not allowing an undefined keyword or label to be used. And we could implement spreadsheet/database-style table displays for the setting of nested arrays of data, rather than faffing around with bracket-matching and erroneous commas.

We need computing to be more closely bound to the IDE.

I was always a pretty competent coder, but I hardly ever code these days. I'm perfectly happy thinking in logical terms -- my problem is keeping the logic in my head while I spend several days coding around the logic. When I'm fighting with syntax, eccentricities in library execution etc, I have to not only think about the problem logic, but also the language logic, the library logic, etc etc etc. This is what Grainger calls "incidental complexity" -- everything other than the problem at hand. It distracts from solving the actual problem, and it places a massive unnecessary cognitive load on the coder. It becomes frustrating and limiting, and you sometimes find at the end of the day that you haven't coded exactly what you intended to, because you were so distracted. But all that incidental complexity means that it's very difficult to unpick your code and rewrite it to what you wanted. Incidental complexity is very bad both for the experienced and inexperienced coder.

Yes, and someone suffered to bring you that video... just not the uploader. There is more suffering in a vapid Hollywood blockbuster than in a 3 minute homemade short, but the repeated uploading of the same blockbuster does not constitute new art.

You've never been involved in any commercial film production then: it's a long, arduous process. Or code development: it's also a long, arduous process. Perhaps in these cases it's the toolchain that's at fault, but at present, suffer you will. But there's nothing that you can do to stop your fingers hurting if you want to learn the guitar to a really high level.

YANAL. The DMCA states that companies must take reasonable steps to prevent reuploading. Designing a system with the express purpose of not being able to prevent uploading would be thoroughly illegal.

On the other hand, it could be argued by the same token that internet sharing and lolcatz-esque memes are actually a drug that latches onto that need, corrupting it and distracting us from the act of creation by giving us a false sense of achievement through constant sharing. If we take pride in posting other people's creations, we cheat ourselves of the urge to create something unique ourselves.

After all, why should I suffer hours of preparation to put something on the net and get a few dozen views, when for a few minutes work I can copy someone else's file and get a million views?

I suspect that they use more than just a plain hash. Even if you just use hash plus explicit filesize, you've narrowed down the chance of hash collisions massively.

Yes, scoping is very powerful, and almost all languages use it for very good reason. The point is that in JavaScript the easiest scope to use is the effective global one (yes, it's a property of the "window" object, but as far as the programmer's concerned, "window" is "main"). The easiest thing to use should always be the safest -- the programmer should always have to make an active choice to do something the more dangerous way.

"Environment variables" must exist, whether as a passed object (which my university lecturers favoured) or as bog-standard global variables. But as soon as environment variables are available, lazy programmers will use them as global variables. Attempting to engineer mechanisms to prevent this happening is a complete waste of time, and only makes programming more complicated. You can't just make the "wrong way" harder -- you've just got to make the right way a little easier than the wrong way. Grainger's Aurora seems to follow that principle quite well -- whereas functional programming tried to force you not to update values (destroying data) unnecessarily by making it practically impossible to do so, Grainger simply makes non-destructive data processing one step easier than destructive data processing: the only destructive action is an explicit update with the result of a non-destructive process.

The default "lazy" state is therefore the right one, so the appropriate behaviour is rewarded. Doing unnecessary destructive changes takes the programmer longer and makes the code less clear, so will naturally be avoided. But crucially, programmers are still able to do whatever they want, when they want.

A lightning collector would never gather enough power to offset the energy used in its construction.

Clouds are formed as water vapour condenses, so the local humidity decreases as the clouds form.

Hydro destroys river ecosystems. For an extreme example of the effects of damming on waterways, look at France. It's a mass of hydroelectric plants and drinking water reservoirs, and its major rivers have almost all been canalised, with a network of locks and sluices to reduce winter flow to ensure that the water level is high enough for navigation during the summer months. Fish stocks in the French rivers are dangerously low, with the Atlantic Salmon now all but unknown to French anglers.

All human activity has an impact, and there is no such thing as "clean" electricity.

Clouds are not made of water vapour, but of water. Liquid water droplets suspended in mid-air. Water vapour is a gas, and is indeed a greenhouse gas. Greenhouse gases allow certain infrared wavelengths through, but block others: specifically they allow the light of the sun in, but reflected/radiated heat from the Earth is kept in.