Lambda the Ultimate

The thing is that higher level abstractions allows to reason about larger amount of the code. It is possible to use lower level languages, but you will eventually do tenth of work for ten time more cost.

Let's recall structured programming revolutin. It allowed to split reasonig about program along of syntax tree. One does not need to understand the entire program a the same time. This could be done procedure by produre basis. This was decomposition by delegation.

FP and OOP introduced existential types and black box reasoning. So the reasoning was split even furture. OOP interface or FP function type are reasoning boundaries. One does not need how they are implemented to understand the program one needs to reason up to these boundaries. Or from these boundaries. So OOP and FP make reasoning smaller. And yep OOP and FP are the same thing, FP is optimized for single entry black boxes, OOP for multi entry. OOFP and FOOP languages just unite both together.

If go further, dependency injection frameworks offer new general purpose abstraction mechanism (Systems) that allow to abstract environment and connection from the object. This allows to split reasoning about the code even further, this is why there are almost no modern and large OOP program without any form dependency injection.

Such high level abstractions are not exclusive for programming languages:

For OS-es we have the same mechanism:
* Inidividual: bare metal applications
* Patterns: series of batch jobs
* Delegation: Unix like systems and windows with hierarchy of processes and file system
* Black boxes: containers (currently they use prototype-based inheritance and expose ports as external interface)
* Systems: container orchestration tools (which are basically dependency injection for container)

More at articles:
https://dzone.com/articles/abstraction-tiers-of-notations
https://dzone.com/articles/birth-of-new-generation-of-programming-languages

The thing is that higher level abstractions allows to reason about larger amount of the code.

There is some tautological truth in that but I'm not so sure about its practical truth. Higher level languages automate the checking of some kinds of assertions about large bodies of code but (a) In practice this is at the expense of a reduction in the number of people thinking about that code at all. (b) It doesn't automatically follow from the so-called power of high-level languages that they lead to greater robustness / social responsibility (as opposed to merely a shift in the kinds of failure modes). (c) The possibility of developing composable systems at a lower level of programming language is, in my opinion, under-researched. The academic / advanced commercial imperative for HLL's arose when programmers were very scarce and the whole field felt very complex and esoteric in ways that haven't born out in practice.

Let's recall structured programming revolution. It allowed to split reasoning about program along of syntax tree.

You can also read that "revolution" as the out-loud thinking of academics who did very little real-world practical programming, making only occasional demo projects to show their approach could work to build complex systems. They succeeded at dominating university, and so the labor market went that way - towards "structured" and later "object oriented" programming - but the way these are venerated seems mostly superstitious to me. GOTO (by which I mean thinking in terms of state machines, not "structured" programs) is perhaps under-rated. It's really possible, as far as I can tell, the HLLs as we know them are a fad does more to constrain what we try to build than it does to help us build systems better.

It doesn't automatically follow from the so-called power of high-level languages that they lead to greater robustness / social responsibility (as opposed to merely a shift in the kinds of failure modes). (c) The possibility of developing composable systems at a lower level of programming language is, in my opinion, under-researched.

[ETA: all of this is about composing code from multiple sources in shared address-spaces. Until you can do that reliably, you can't build programs complex enough to start composing them at the process-level, b/c at a minimum, you have RPC runtimes to link with your own code, and then ... well, here comes that story ...]

I must differ. I remember working at IBM on a "component object model" project in C/C++. At the same time, there were people working on a similar thing at MSFT in C/C++ also. And these efforts failed abysmally. I think we've all forgotten what it was like before the advent of memory-safe GCed languages, when you couldn't download code from repositories on the network and have *any* hope that the code could coexist with other code you'd downloaded, and your own code: you were *guaranteed* masses of memory-leaks and core-dumps, when it even worked at all. I worked on a CORBA marshaller for that object model, and I remember vividly the phrase "marshall garbage and die" -- and nights spent on the phone with colleagues in Europe, helping them debug a crash in our marshaller, only to find that it was in their code, which had broken some memory-safety rule. Not that there were no bugs in our marshaller, but .... you simply couldn't combine multiple independent modules and have any hope whatsoever that things would keep working.

I have a strong memory of when this changed, and it was with the advent of Perl/Python (as the first widely-deployed GCed languages). And (of course, [spit]) Java followed not long after.

Similar things could be said for the advent of cloud computing, and the trend to recast what used to be sysadmin (== "many terminals open, guys typing *really* fast") tasks into programming tasks, via stuff like Terraform.

I must differ. I remember working at IBM on a "component object model" project in C/C++. At the same time, there were people working on a similar thing at MSFT in C/C++ also. And these efforts failed abysmally.

IMHO Component object model efforts (COM, ActiveX, SOM, etc.) was just a wrong place to introduce OOP to OS-es. This is why they did not catch up. This is also a reason why KeyKOS, EROS, CapOS failed to catch up. And this is also a reason why micro-kernels made it possible to have user-space drivers and better fault isolation, but they did not create a new generic application execution environment (they all just another Unix-like from outside).

In OS, procedure corresponds to process, memory corresponds to file system. So right abstraction for OOP object is a container (like Docker). Docker containers have abstraction (we get notion of packaged service), encapsulation, inheritance (prototype-based), and polymorphism (this is one is tricky as entry points are just TCP protocols for now). And this is why they did catch up.

And C++ was a transitional language between generations (like platypus), which allowed to understand what is important and what is not. C++ was C with bolted on objects to simplify tasks that C does well and to do them with minimal overhead. In some sense, C++ was widely deployed language research platform for OOP.

I have a strong memory of when this changed, and it was with the advent of Perl/Python (as the first widely-deployed GCed languages). And (of course, [spit]) Java followed not long after.

GC languages are later reached the right abstraction point, as they washed out C inheritance, that get in the way of OOP, while losing ability to do C job well. C++ just had too much ways to break out object abstraction, but it was required for language goals. GC languages appeared and adopted because it was discovered that memory safety is important, but C compatibility, controlled memory management is not important for many tasks.

And IMHO, Java is still better than Python for large projects. Even limited static typing in early Java greatly simplified teamwork. Modern JVM languages like Kotlin are better from point of view of software developer, but even Kotlin developers acknowledge in the talks on conferences that their compiler and IDE support are up to 10x time slower on some programs than for Java (because of higher language complexity). At Java appearance time, compilation time was a major concern and one of declared features of Java was much faster compilation than C++, while staying statically-typed (many things like too much of type declarations were done to support compilation time). Cursing Java w/o checking design goals and conditions is somewhat unfair. It did well at that time for number reasons, I was one of early adopters, and I was happy with it after C++. Priorities shifted since that time, and now it does not match current priorities, but Java is still evolving to match new priorities.

IMHO Component object model efforts (COM, ActiveX, SOM, etc.) was just a wrong place to introduce OOP to OS-es.

Ah. So first, sure SOM tried to introduce OOP .... but it never worked. COM didn't try to introduce OOP, or more precisely, the only inheritance in COM was inheritance of *interface*. The point of these models was a uniform "wrappering" model for delivering code so that consuming code could use it uniformly. So for instance, there was a standard way of pulling up COM objects into Visual Basic. It was *explicitly* sold and used as a way of glueing together code from many places.

And it was specifically in this way, that it failed. Because without safe pointers and GC, it was just impossible to make work, even for this limited mission. By contrast, in the late 90s there wasn't a lot of O-O Perl, but there was a thriving community of Internet-downloadable Perl modules. And one could with confidence download these modules, use them in one's Perl program, and not endure core-dumps, memory-overruns, etc. Sure, one had to worry about bugs and security, but not about this lower level of error.

And I'll note that Perl5 is effectively LISP (with a tiny object system), with a different syntax.

In practice this is at the expense of a reduction in the number of people thinking about that code at all.

If you mean successfully accomplish your task in changing the application while knowing less about it. This is a goal of high-level abstraction. BTW this thing is essential for teamwork, I have a lot of tasks on my hands, less I required to know about what other doing, the more time I could spend on my tasks.

Human mental capacity is extremely limited and limited by wetware architecture, where symbolic reasoning is slow process above slow but extremely parallel computational process. We cannot change amount of data we are able to process at the same time (number of mental registers is limited (Miller's Number), number of actively tracked objects is limited as well (Dunbar's Number), associative memory is too unreliable). We could only change the way we process the data. Low-level languages provide simpler tools to manage program complexity.

It doesn't automatically follow from the so-called power of high-level languages that they lead to greater robustness / social responsibility (as opposed to merely a shift in the kinds of failure modes).

I do not know why you bring here "social responsibility", because it is orthogonal to PL discussion. But if you would overload the developer with low level constructs, will the developer have spare brain-cycles for "social responsibility"?

For robustness, most bugs per line of the multiplatform code in embedded solutions were found assembler, C, Java in that order (as from discussion with embedded developers I know). I do not use assembler in my work, but C code is sometimes used. The bugs there are much more fatal than bugs in Java/Kotlin code, from my memory of assembler, there are much more ways to break process state than in C. So robustness is not argument for me.

You can also read that "revolution" as the out-loud thinking of academics who did very little real-world practical programming, making only occasional demo projects to show their approach could work to build complex systems. They succeeded at dominating university, and so the labor market went that way - towards "structured" and later "object oriented" programming - but the way these are venerated seems mostly superstitious to me.

Unix has been written mostly in C with few pieces written in assembler. C works in structured programming paradigm. Unix/C designers are not “the out-loud thinking of academics”. They were engineers. There is go to for many reasons, but structured programming is not about go to. It is about to decomposing computational process into hierarchy using delegation concept. It is very hard to reason about this in assembly language, unless the assembly program is using some kind of DSL to support structured programming.

Basic SP idea is decomposition by delegation in code and data, such decomposition is defined first order logic in math. Both FP and OOP rely on common black box mental composition operation. That is represented by existential types in math (which are second-order logic).

So, SP and OOP were engineering revolutions. At time of OOP, academia pushed FP very hard. Academia practically denied the value of OOP at first. But FP is logically the similar to OOP, but with more restriction. As result, FP just had nice syntax for some useful use cases. Recent generations of C++, Java, and C# adopted FP as a syntax sugar.

Immutability concept was pushed by FP as a core concept as well, but it is adopted by OOP too in specific areas where it is useful. On reverse, in FP even Haskell heavily rely on mutable structures: lazy evaluation is mutable structure that is "observably immutable", and Haskell has mutable state internal DSL in form of monads. "Observably immutable" is just misleading, because one need to know mutability details to understand performance. ML just has a mutable state.

GOTO (by which I mean thinking in terms of state machines, not "structured" programs) is perhaps under-rated. It's really possible, as far as I can tell, the HLLs as we know them are a fad does more to constrain what we try to build than it does to help us build systems better.

Flat state machines are the same 'flat pattern' concept. The only composition operation (that flat state machines natively support) is concatenation. You are able to connect entry and exists. Non-flat state-machines (where state has local state and has sub-machine and could accept parameters) is still structured programming.

Also, developers stopped to use control flow diagrams when communicating with each other about the code (standards, design docs). CFD were replaced by structured pseudo-code because it is easier to understand. State machines are still used, but only for niche cases.

In enterprise, there are numerous attempts to introduce state machines as core application concept in form of workflow engines. However, these products fail conquer market because realistic processes look too complex on diagrams for both business users and developers. And there is a lack of tools to compose processes. The same is for data flow tools with visual design language with flat diagrams - they appear and die regularly.

So, GOTO is not underrated. It just not suitable for human brain and large complex process description. This is why it stopped to be used. Not because of some academia push. If you have a process with 200 or more steps, one has to switch to structured programming to understand it (as internal DSL or other language).

If you mean successfully accomplish your task in changing the application while knowing less about it. This is a goal of high-level abstraction. BTW this thing is essential for teamwork,...

I like simple things that work robustly; that aren't flakey. That's also what I mean when invoking social responsibility. In this regard, the last couple of decades of desktop software (to name one example) are, for me, a regression in terms of reliability and flexibility, with some gains in very narrow domains of capacity. Like: Yay, audio processing tools can do a lot more today -- and boo, everything, including those, is flakier and more intractable. Looking at the actual software stacks I rely on, I can only shake my head and conclude that 100% of "software engineering" academia is bullshit.

Also, yes, there are ways to compose state machines that more complicated than concatenation and no that is not identical to structured programming.

I think that state machines are under-rated as an organizing principle for computing systems because I see that in the real world, people without any fancy training can study and "get" electro-mechaniocal state machines extremely well, without needing to rely on overpaid, overly "academic" foolishexperts. I also think they are under-rated because what we are programming are, in fact, literally, state machines.

I have come to the opinion that a great deal of fancy computer science is more about job security than anything good.

I guess you have some ideas and compare ideas against real things.

“Talk is cheap. Show me the code.” -- Linus Torvalds

Real comparison would have been taking a program that is 'flaky' rewrite in your hypothetical state machine language and show:

1. The quality of the application is better or the same
2. The code of the application is easier to understand for trained developer
3. The application costs the same or less to develop
4. The application could be developed by developers with that cost the same or less to train

Unit you cannot demonstrate it on reasonably large applications, your argument is empty (for example, around 100000 lines of OOP code in original application, in your language there might be less of code if it is really better).

Having flaky software now that somehow serves the goal is better than not to have any software at all. It is possible to write high quality software in OOP. It just cost more in time and developer's qualification. When developing commercial applications, the developers invest time into things case sales of application, not into things you need. If application is flaky, but you will still buy and use it, it is OK application. If it is OSS application, but you will download and use it, and possibly contribute back, it is OK application as well.

If you will use your language, I'm sure the people will write flaky applications in it, just because it is cheaper. It is possible to write bad programs in any language.

IMHO some concepts like state machines works well in limited scope for well selected task, but fail miserably on larger scale. This is a real problem with academic research, they do not develop applications with the same amount of functionality as bloody enterprise.

State machines as top-level application language were attempted to be introduced many times in form of workflow engines. But all attempts failed to get traction so far because neither business nor developers could understand code written in them when they grow large enough. And they always grow large enough because for pressure from business requirements. I've worked with some of them, so I'm saying it from personal experience.

Real comparison would have been taking a program that is 'flaky' rewrite in your hypothetical state machine language

Nah. Were it not for weirdly designed "object oriented" languages, for example, I'm pretty sure nobody would design a hypertext system quite so messed up as a typical browser.

A better question might be whether or not it is possible and practical to design a good hypertext system using simpler state machine components, rather than whether or not one could emulate firefox or chromium or whatever.

I'm saying not about internal design. Just high-level user-visible behavior requirements. For browser it would be just external requirements, like opening page (html or even your language), navigating to other pages, dynamic behavior on the page (not necessary JS), etc. Just user visible behavior, nothing else is restricted.

But browser is quite complex case if go down to all functional requirements.

For test, something simpler will work. 100k lines application is just month or two of work for good OOP developer if functional design is ready. If state machine language is really good, it should take even less? Isn't it? You were not happy with some sound processing app before (for example).

The thing is that you cannot (in my opinion). Compilers use state-machine-like intermediate representation internally (control flow graphs), not because it is better, but because it is dumper and they could perform optimizations on it that would lead to ugly code if implemented directly. Assembler is ultimate state machine language now btw. FORTRAN 66 was nice state machine language, before it was replaced by FORTRAN 77 with structured programming.

Generally, the low-level things like state machines have low barrier of entry, but poor cognitive scaling with increasing behavior complexity. OOP languages like Java have higher barrier of entry, but they scale much better. Any paradigm will eventually result in unmanageable code, but at different speed. Java reach that barrier much later than C, and C much later than assembler. If you stay on smaller scale applications, you will not notice the problem with cognitive scaling. 5k of code is peak for structured programming. Around 50k it is falling apart. At 50k or higher programs start doing OOP in C with abstract data types and other patterns. Around 100k lines of the code is a peak of OOP paradigm performance, I think. At 1m lines of code pure OOP starts to fall apart and dependency injection and other high-order design patters are introduced at this point.

Generally, the low-level things like state machines have low barrier of entry, but poor cognitive scaling with increasing behavior complexity.

Perhaps decreasing program complexity should be a goal. Consider that data is what is most valuable and most durable, not behaviours and programs that implement those behaviours. We still use data gathered millenia ago, we don't still use machines from centuries ago; often, not even decades ago.

If access to data is mediated by increasingly sophisticated programs that hides the data behind a lot of complexity, then it inhibits the accessibilty and durability of said data.

So I agree with every point that you've made, but I don't necessarily think that this is the direction we should be going. Consider as alternatives, programming paradigms that expose more of the structure behind data (relational algebra?), rather than mediate access to the data via complex behaviours (OOP). Obviously you sometimes to need data hiding, say for security or privacy, but those seem to be exceptions with well-defined boundaries.

I'm not sure if this agrees with Tim's goal, but state machines necessarily expose a lot of implementation details, and so the data on which they operate is also more exposed. I can see the case for them from this viewpoint.

I've just listened to SMARTDATA 2020 Russian conference, and my impression is that the development is going in the reverse direction. The current trend on data is to put it all into data lake (or swamp if uncontrolled) and discover emerging structure out of it later. So relational or graph structure is something discovered and inferred rather than something planned ahead in a growing number of cases.

Requirements change fast because business changes fast, and the problem is often to discover what exactly changes. Who was able to predict COVID two years ago? But it affected IT infrastructure greatly: from move to remote work model (it changes security model for example), to changes in consumption patterns. Ones who change slower get eliminated. It is really more important for business to get changes done faster than to make them correctly.

I often hear something like 'we want "the happy case" first' from business. They are willing to do manual SQL and rest requests later to fix rare problems, if we deliver basic happy case first. We still need to provide sufficient information in database and logs, but still manual error recovery is OK for business if they get it working sooner for most of cases. Error recovery could be automated later, but missed market share and income cannot be recovered.

This goes strongly against my instincts of software engineer, but that is a life in the bloody enterprise, and I had to find compromises.

What you write about "data lakes" is spot-on. If we go back to the beginning of RDBs, and Ted Codd's original paper ("A Relational Model of Data for Large Data Banks") you can see that he understood that modeling the data as relations on which indices were placed -afterward-, was a key improvement, because it meant that you didn't presuppose how the data was accessed. I'm not going to go back and re-read the paper now, but it follows directly that one expect that as code changes, as requirements change, one could add new access-paths (indices) and stop using old ones. But the data would persist.

As we follow RDBs out into the world, we notice that often real-world "entities" are mapped to multiple tables, and then that mapping itself is one that we wish we could change after-the-fact. So it isn't surprising that people want to find a more-flexible model where relational structure is *inferred* rather than *designed*.

As an aside, there's a wonderful paper (part of a whole body of work) by Alan Fekete, on "Serializable Snapshot Isolation". It describes how to extend snapshot isolation to achieve full-serializability of transactions. In it, he mentions that it is conjectured that a significant part of the "data rot" in RDB applications on Oracle databases, comes from the fact that Oracle shipped (maybe still) with snapshot isolation as the default, and programmers mistakenly (partially b/c of marketing literature) assumed that this was fully-serializable. So they wrote their transactions under this assumption and .... well, obviously it didn't hold. So you ended up with busted invariants in your data, and busted data, full stop.

And this is (or was) the case in the most-wide-deployed RDB on earth. IIRC, Mysql also uses snapshot isolation; again, I won't consult the docs to see if they offer full-serializability as an option, but the default (again, IIRC) is snapshot.

Serialized just more expensive everywhere, as a higher quality of service does not come for free. This is why Oracle and other DB vendors try to discourage it.

Transactions still provide quite weak guarantees, they just shorten window of vulnerability. You will still get funny things like heuristic commits and rollbacks, databases restored from backup, and many other edge cases. The backup case is particularly funny for distributed transactions, when message is sent but database think that it does not, and charge customer twice. If transaction were in place in the moment of backup, you might get reverse decision from what really happened. I’ve written JTA transaction manager myself at one point of time, and the thing just cannot be done completely right. XA spec had just too much undefined behavior.

The interesting trend out there that try to dodge this problem is Conflict-free replicated data types. They could live in the world of CAP theorem. Still no hard guarantees, but softer ones are easier to provide.

The related trend is “event sourcing” (representing business entity as a log of business operations starting from blank state and derive projection every time when it is needed), I will not provide any references, because there are still active wars on what is it (and many parties claim that the war is already won by them), and there are even not-readily-refutable claims from some parties that even Martin Fowler got it wrong on his site. There are also some anti-pattern claims and some of these claims are not really about event sourcing. Take any docs on it with grain of salt.

The current folk wisdom is that data loss and inconsistency is unavoidable in long run. Even for a single database you might get data that obsolete and inconsistent with business situation via backups, even if all transactions worked correctly. Just get ready for it with armies of lawyers and technical support.

(1) You might want to look at MDCC by Tim Kraska. Any CRDT scheme involves a bunch of copies;in Kraska's scheme, you can see how, with those copies, you can achieve full serializability with two message delays.
(2) It's true that full serializability incurs latency (not cost), but this is the price you pay for serializability. The problem with what Oracle did was not that "snapshot isolation is worse" (though it is) -- it is that they *advertised* their DB as supporting serializability, when it did not. This caused programmers to write incorrect trans.
(3) A friend of mine once spoke with a head honcho at Netflix, whose tech for running in AWS at the time was all based on best-effort, and some of it on eventual-consistency. I asked my friend to ask the head honcho the following question:

Q: you can't use eventual-consistency/best-effort to provide exactly-once durable trans; what do you do about that, I mean, every business needs those?
A: oh sure, for streaming movies, we use best-effort: I mean, what's the worst that can happen? Somebody gets an extra hour of watching that they didn't pay for? But for real money trans? We send them to a regular J2EE app in a regular datacenter.

Systems like Cassandra don't actually work except as caches: there is a well-written explanation for why by Joydeep Sen Sharma: http://jsensarma.com/blog/?p=64

I'll highlight one of them: in the presence of inter-table consistency constraints (e.g. foreign keys), eventual consistency produces inconsistency.

CRDTs are great in theory. Sure.

The problem with what Oracle did was not that "snapshot isolation is worse" (though it is) -- it is that they *advertised* their DB as supporting serializability, when it did not.

That is funny. Serialization was basically banned on the project where we have used Oracle. The comandment of db architect was to use read-committed everywhere, if it requires serialization, change it to work with read-committed. Possibly this issue was a reason for it.

We have inherited Cassandra from the previous team, and it has worst query langauge that I've seen. For example, it is not possible even to compare two columns together like 'a > 0.8 * b' there is no 'or' and many other things are missing. It is still used as denormalized db dump, but due to the query language limitations we have to load too much of data into memory for post processing. We are trying to push some intermediates into the picture like Apache Ignite to move memory load from JavaEE to applications that are designed to handle it, but customer is resisting.

Back in the day, Cassanda did not have virtual nodes. This meant that when a replica synced with another replica, the amount of time for that replication operation was a function of the data-to-be-replicated (or maybe even the data-set-size -- I forget). [ISTR that for key-range-indexed data, it was indeed data-set-size, but again, I could be wrong.] In any case, since that size could grow over time, the time-to-perform-one-atomic-step of replication would grow. And since the MTBF was not thus growing, eventually you'd reach a point where the Cassandra cluster couldn't heal from failures, b/c it couldn't perform a replication step without crashing. Good times, good times.

Maybe they've added "virtual nodes", which makes that "replica size" much smaller, but doesn't fix the root problem. If you're going to build what passes for an arbitrarily-scalable store, there's only one way to do it, and that's the way Bigtable did, with splittable partitions.

I remember well talking with a guy at Goldman, who was a *giant* Cassandra fan, and even he was pretty clear that it was just a cache. It's incredibly rare to find any system that uses an eventual-consistency store as a source of truth, even with the replication count set to high enough to (theoretically) ensure durability. I remember that there was (probably still is) a strategy so that when you want to write to N replicas, but the N replicas you need are not all available, you can choose other replicas more-or-less dynamically. It was a massive kludge, and blew up any guarantees they purported to have.

All craziness. All craziness.

Data lakes make sense to me, and it leads naturally to something like event sourcing, where you just capture the data in an append-only log and then subsequently build your domain-specific representation for easy reading. The tooling and APIs around this is still not great though.

GOTO (by which I mean thinking in terms of state machines, not "structured" programs) is perhaps under-rated.

Is programming with state machines not a form of structured programming? Mealy machines, Moore machines, etc. seem structured to me. Meanwhile, representation of state machines using GOTO is still relatively awkward and difficult to reason about.

I've found it interesting that Kahn process networks can be usefully understood both as sanely composable state machines (i.e. multi-channel Mealy machines), and as partial evaluation of pure functions (channels are essentially partially computed lists).

I think that the biggest problem with 'structured' programs today is that the popular structures are terribly awkward for modeling concurrent interactions. There are quite a few alternative structures, e.g. based around KPNs or guarded command language and transactional memory.

It doesn't automatically follow from the so-called power of high-level languages that they lead to greater robustness / social responsibility (as opposed to merely a shift in the kinds of failure modes).

If we can avoid some especially troublesome failure modes, such as ransom-ware, I think that would not be a small win for high-level languages.

I'm more concerned that high level languages are mis-applied, solving non-critical problems. Higher levels of abstraction for correctness or productivity are just a couple paths HLLs could pursue. We could instead be pursuing self-explaining and easily debuggable computations, the ability for normal users to casually create and interactive artifacts, easy algorithm reuse across a wide range of contexts and scales, etc..

While some of what the author writes is correct, a lot of it is based on a highly political reading of a history that also has roots in basic pricing policies and the reactions of customers to same.

Just be aware that in a lot of people's understanding, pricing is determined by the social relations of production (the social customs by which production takes place), and those relations are to be identified with politics.