Back

@vkc (To be clear, the position I endorse is both “HTML is programming” •and• the heckler blocking.)

Beyond the reasons of “don't heckle, don't be an asshole” and “this boundary-drawing is elitist” — reasons which, to be clear, are •entirely sufficient• to justify the OP on their own — I am willing to defend the assertions that writing HTML is programming and that HTML is a programming language on the merits:

1/?

HTML is a way for humans to express their ideas and their intentions in a form that is unambiguously interpreted by a machine. We express our ideas, then turn them loose. The machine's interpretation may diverge from our human understanding; when it does, our ideas talk back to us and they •surprise• us.

If that’s not programming, I don’t know what is.

2/

We might draw a line about Turing completeness or intended purpose. Both completely miss the point.

It is fun to try to find Turing tarpits in HTML and/or CSS! But that’s not what makes programming programming.

The previous post is it. The problems of programming — the things that make it difficult, the things that make it rewarding — all come from that collision of human intent with unambiguous machine interpretation. That’s the game right there.

/end

An addendum, a useful word:

An ••ostensive definition•• is a definition by example. No bright line that distinguishes “is” from “isn’t;” instead, we have a set of examples we agree clearly fit the word, then ask, “How does this other thing resemble the examples?”

Some words are best defined ostensively. “Sandwich” is a great example. You can have silly fun playing with the boundary conditions — A quesadilla is a sandwich!! A hot dog is a taco!! — but to get pendantic about that fun is foolish.

With a word like sandwich that’s defined ostensively, instead of asking “Is it a sandwich or not? Binary yes or no!!,” it’s better to ask, “•How• is it a sandwich?”

Similarly: “How is ____ a programming language?”

How does it resemble the pattern? How does it depart from it? Which lessons we’ve learned about programming apply here? Which don’t? Will it need…technical learning? precision? testing? debugging? version control? docs? knowledge sharing? curiosity? resilience to frustration? etc.

Thanks, @Crell, I'm glad you asked!

Nontrivial Excel usage is quite obviously programming. Come on. But beyond that:

We’d have a much better understanding of usability failures if we understood tiny UI actions as itty bitty moments of programming. We’re asking people to momentarily span the bridge between human understanding and machine execution. Pretending that bridge doesn't exist is a perennial footgun.

“What, even clicking a button, Paul?!?” Well…

https://phpc.social/@Crell/113680660849631952

…try looking at it that way:

A button is a machine abstraction designed to accommodate human expression. It has a syntax whose underlying fabric is clicks/taps and mouse/finger motion. It assigns semantics to that syntax. Humans click the button with human intentions, and the machine executes the instructions.

It is a ~3-state DFA, a few teeny tiny itty bitty atoms of programming.

If a UI button is a programming language, it's a tiny, trivial one. But that lens of “In what ways is this user interface a form of programming?” does open the door to insights about what experiences humans are going to have trying to use it.

We programmers understand the difficulties and the dangers of:

- compounding complexity
- mismatch between mental model and machine implementation
- error states
- unintended consequences
- solving the problem at hand using the building blocks available