This isn’t really a devblog, friends.
It’s more of a scratchpad for draft versions of articles and essays. I used to be a writer, but writing got too hard for me, so I dug clams and collected driftwood for a while.
A couple of dev-related drafts that I am poking away at are:
1) How Programmers Are Ruining the Web. The back-end people have moved into the front-end, and brought their video-game-boy culture with them. Process-oriented outlooks, black-hole projects, multiple layers of abstraction, obscurantist jargon, conference fads. Too many scripts and preprocessors and remote links. (“Dependencies,” as we say in dev cant.) Pages go down and no one can fix them because they were generated by kidneystone.js and webmangler, and nobody here now can do that, and anyway the servers got migrated so we’re not sure where this code lives. Ten years ago if you had a broken link it usually meant nothing worse than a missing image or a bad URL. Now it often breaks the entire page.
2) Slacker Jobs Have Vanished. This Is a Bad Thing. A tangential backstory to the foregoing. Artistic and technological progress both depend upon an ample supply of easy-to-get “day jobs” for our creative risk-takers. (They are not really “slacker” jobs, but I call them that here because that is how they are often regarded, inasmuch as they are not career-oriented.) Golden Age was 1980-2000. Steady decline since then. Bad for business, bad for society, bad for culture.
[ADDENDA 18 mar 2014:]
3) Dev-Tech Jargon is wrongheaded, misleading, obscure. Why? Particularly noticeable in web development.
Big example: The pieces of a webpage are collectively called the DOM. But what does DOM mean? Document Object Model? That is as clear as mud, and probably less useful. There’s a Document here, certainly; but there’s no Object, not in the programming sense. (Object is another near-meaningless term—see below.) And Model? It’s not a Model; it’s the final result, the end-product, the actual real-life thing that shows up on your screen. Alternative phrases for DOM are Presentation Layer and Page Markup and Source Code with related assets. These all have slightly different meanings, but they aim in the same approximate direction as DOM, and they are user-friendly besides.
Then you have API, supposedly for Application Programming Interface. Ask ten developers what an API is, they’ll give you fourteen different answers. So far as I can tell, an API is a set of shorthand instructions that the site programmers create and make available to the general public, in order to enable outside developers to come up with add-ons and customized implementations. Isn’t there something else we could call this? How’s about Toolbox?
Then you’ve got the ever-popular var. What is a var? The term is apparently short for variable. However, a var is not a variable. “It’s sort of like a container,” an instructor once told me. I thought of a can of peas, only without the peas, and with the label removed. This didn’t help me a bit. Because a var is not a container, and it’s not like a container; it’s more like the thing in a container—a pea, say. A single pea that you name Fred, or myPea. It’s a single identifiable instance of something, and it’s identifiable because you give it a name. And why do you give it a name to make it identifiable? So you can write code to tell it what to do. Here, Fred, roll across my screen—back and forth, back and forth—and double in size every five seconds! Attaboy, Fred!
I can’t tell you why Dev-Tech jargon is so awful, but I sense these problems go back a long way. Back at least to the early days of OOP, or object-oriented programming. Before my time. Maybe it all began with OOP. Do you know what object-oriented programming means? It just means modular programming. You try to design each section of your code as a separate, reusable building-block. So why didn’t they call it building-block programming, or prefab programming, or modular programming? Because then it would be too easy to understand?
Yes, I think that could very well be part of it.