Type checking is a symptom, not a solution

I think every comment on this article so far is misunderstanding the argument, which seems optimistic to me—he may be rightly pointing at a dogma.

I learned electronics and dataflow languages before I learned traditional languages, and learning how modern systems were architected was horrifying to me. The level of separation of components is nowhere close to what's possible, because—as the author points out—the default level of abstraction in modern programming languages is the function.

Don't read this article as a critique of types (as in: typed vs untyped), but as a finger pointing at a higher level of abstraction that isn't a first-class concept in the tooling used to architect large systems today.

All that said, I have come across many people beating this drum over the years—usually Alan Kay or Ted Nelson types—and I suspect there's something they're missing as well.

Meh, having been forced to use labview for an engineering class a long time ago, dabbled some in verilog, and worked on some production actor based code, it seems clear to me that we don't see those kinds of approaches often is that they're very quickly impossible to understand when you have a lot of interactions.

Labview was a particular nightmare even for very basic tasks.

Ultimately I think this is cope, but I see this refrain over and over and I think it's what holds the current dogma in-place.

I suspect the issue is that traditional boxes and wires type dataflow IDEs put the burden of abstraction on the programmer, and since most people encounter these tools as students, they understandably fail to set up the abstractions correctly and conclude that the entire concept of high level abstraction is pointless.

I think there's a much better way, but nobody's really built it in a way that cuts through the prejudice.

Coincidentally, I learned how Palantir Foundry works today and it's an interesting case-study.

Or it's just easier to create abstractions with functions as your basic tool. I find that something like differential geometry or representation theory have way more powerful abstractions that you can use to quickly reason about very complicated ideas vs. anything you'll ever see in business programming, and those abstractions are all based on functions (and you'll find that any math book is full of "type annotations").

A function, at its most basic, is a black box that takes an input with a well-defined shape and produces an output of another well-defined shape.

What primitive do you feel is more suitable for a high-level abstraction of processes operating on data?