The reason behind “how did we get here” […] is that the people who are regulating the Internet have mistaken the Internet — in this case — for a newspaper delivery service. And sometimes we get really dumb policies that mistake the Internet for a video-on-demand service, and sometimes for a jihadi recruiting tool, and sometimes for a pornography distribution system — and it is all of those things, because the Internet is the nervous system of the 21st century.
The stream, mobile applications, and moving images all show a departure from a books-internet toward a television-internet. We seem to have gone from a non-linear mode of communication – nodes and networks and links – toward one that is linear, passive, programmed and inward-looking.
Sometimes I think maybe I’m becoming too strict as I age. Maybe this is all a natural evolution of a technology. But I can’t close my eyes to what’s happening: a loss of intellectual power and diversity. In the past, the web was powerful and serious enough to land me in jail. Today it feels like little more than entertainment. So much that even Iran doesn’t take some – Instagram, for instance – serious enough to block.
“You might think, well that’s just common sense. But last I checked, computers don’t have common sense. Indeed, they must have a formal way to automate these kind of code optimizations. Maths has a way of formalizing the intuitive, which is helpful amidst the rigid terrain of computer logic.”
I recently had a conversation at work on possible coding advice, that quickly diverged into a matter of what I feel is code that speaks for itself vs. code that is ridden with comments because it can’t live on its own.
I tried to illustrate my point by defending some practices on clarity, which really are just a repackaging of common ideas from the world of “functional” programming — adopting recognizable patterns via higher-level functions, aiming for declarative code, centered around data transformations, etc. — in contrast with what I’d consider traditional imperative code — longer methods built around statements, more (and explicit) branching, mutable data and variable reassignments, etc.
My colleague then rightfully remarked that, while map, reduce, filter et al. can be used to make things clearer, they can be abused, and chaining a bunch of these can lead to monstrous spaghetti just as badly as more traditionally imperative code. Similarly, list comprehensions can be nice and concise, but don’t really scale. That got us to try to generalize, which led to my commenting:
I agree that “functional” code, in itself, isn’t immune to spaghettitis. I think the key here is really to keep functions small and as strongly specified as possible, so that 1) one can easily inspect them and understand what piece they represent in the larger chain of data transformations, and 2) anyone can think of them as black boxes (by trusting their specification; not specific to functional, but usually easier, especially with referential transparency) as they are called within a chain of manipulations elsewhere in the code.
In a way, maybe the root of all evil is just about anything we can call a “long anonymous chain of things”. So a long sequence of function compositions in one statement is bad, the same way a long sequence of rules within a list comprehension is bad, the same way a long sequence of statements within a procedure is bad. I added the term “anonymous” in there because I think the naming plays an essential role in the way we can break things down and grasp them. That is why my initial functional example [see below] defined isPopular separately, and it’s why a procedure might be defined in “paragraphs”, where each revolves around a variable or a helper.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Somewhere in the next couple of decades, there will be a tipping point. Scientific breakthrough in distributed systems will have to top the unassailable power, efficiency and convenience of today’s huge central service providers and gatekeepers. Why? Because no amount of regulatory oversight can prevent centralized abuse of power; this article provides just one of countless examples.
That new wave of decentralization may come through home-scaled nodes; it may come through communal pools, in a topology similar to that of the Internet of the early days. Either way, it has to come and succeed.
λ ∧ ¬λ 