I didn't read beyond the first few sections of the post, but it wasn't really clear to me how it relates to postmodernism (ctl-f "modern" didn't turn anything up either). If you're interested in a paper attempting to actually relate postmodernism and programming, the best I've read can be found by querying your local search engine for [Notes on Postmodern Programming].
Yeah, it doesn't have a whole lot to do with postmodernism. On the other hand, it is a useful and practical guide to refactoring imperative code to declarative form, with all the associated benefits.
TL/DR: It's apparently the full text of a talk in which he's basically that saying declarative programming, having its roots in mathematical logic, is an excellent tool for abstraction, the primary tool we as programmers use to manage complexity, and that he wishes he'd discovered it earlier in his 12 year career of commercial programming.
For the moment let’s think of it as “not imperative programming,” where “imperative programming” is you, the Grand Imperator, telling the program what to do. Declarative programming would instead make you the Grand Declarator: you instead tell the program what it is. And, with that, the program no doubt walks away enlightened. (Even if we don’t.)
All declarative systems are abstract, but perhaps not all abstractions are declarative. What makes an abstraction declarative?
some of those declarative solutions may well be qualitatively better than how we might be solving them otherwise—in fact, I think that’s extremely likely
Declarative code is simpler. It’s usually easier to read, in my experience. It’s smaller, if more spread out; easy to get around. It’s more reliable simply because each component has fewer moving pieces which could fail, and fewer joints between them that could break. On top of all of that, the lack of ordering means that declarative code is immune to race conditions, the single largest issue with concurrency. And it is clearly the direction that the market and the industry is heading in: there is a lot of ongoing, exciting research being done in declarative languages and systems and how to survive in an imperative world.
Nice turn of phrase, Grand Declarator, sir! (Personally, I have been getting right in to ABNF of late - generating regex and API systems and such based upon that.)
While I have not read the OP (yet... it's looking kind of long), the title immediately reminded me of Larry's talk/essay. Which I have read, in the past, and considered quite worthwhile. Thanks for digging up the link to that.
> and all the effort you will do is configure and glue stuff together
I've been assigned to my first Java project at work, and during training they would show how much you could do without 'coding'. I guess editing XML files and inserting program code in the strings of said XML files isn't technically 'coding', where I guess 'coding' means writing scary Java code with, you know, type checking and relvant error messages and stuff. Why I need to be able to redefine the class name of our 'beans' internal to the working of our system using a user editable configuration file is beyond me.
Oof! I dealt with a SASL and CAS system that had much of its flow control built into XML strings. Yeah, you may not have to "compile" things, but you end up with a system where everything is a runtime exception. I believe this style of coding was referred to as "inner platform effect" by Martin Fowler.