Speaking as a Fancy Computer Science Professor at a Fancy Institution of Higher Education who teaches the course on Programming Languages:
-
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.
-
Paul Cantrellreplied to Paul Cantrell last edited by [email protected]
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.
-
@inthehands My take is that this fits into the same category of whether something is art, or music, or a game, or a sport, or drug paraphernalia, or a toy, or a tool, or a vacation. None of these are intrinsic properties of the object or activity, they're ways of engaging with it.
The reason this is even a topic to talk about arises because one can totally use a WSIWYG editor and treat HTML as "text with some parts in italics” which is _not_ a programming type interaction, but you can also do more complex stuff that has to account for a bunch of different situations both today and tomorrow, which is not materially different from the sorts of things what someone writing C++ has to do.
-
@inthehands we need a Cube Rule for languages
https://cuberule.com/ -
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…
Larry Garfield (@[email protected])
@[email protected] I agree about HTML and CSS, but wouldn't that definition also include Word, or Excel, or PowerPoint? Those are all giving the computer instructions that are presumably unambiguous. A definition by example (totally a legit thing) also needs counter examples to define the exclusions. A salad is not a sandwich, unambiguously.
PHP Community on Mastodon (phpc.social)
-
Paul Cantrellreplied to Paul Cantrell last edited by [email protected]
…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.
-
@inthehands @Crell the fun thing about ostensibly defined concepts is that you get edge cases that still very much can claim to be the thing, but which have mutually empty intersection. In this case: implementing NAND gates, wires, and delay lines using Venus fly traps is programming (it's creating a Turing complete device, after all), and writing a markdown document is programming (it's telling a computer how to do stuff, after all), but their intersection is empty (unless, of course, you use a lot of Venus fly traps and implement x86).
I feel like the world is more fun that way, compared to excluding random things.
-
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 -
Paul Cantrellreplied to Paul Cantrell last edited by [email protected]
- not losing sight of the problem in the middle of fighting the machine
- the way social / human problems can come to a head when codified in commands given to a machine
- the way a better abstraction can change whether something is easy, flexible, error-prone, adaptable, correct
- etcViewing computer interaction as a series of increasingly programming-like steps goes a long way toward explaining why your dad can’t figure out how to change the wifi password.
-
Paul Cantrellreplied to Paul Cantrell last edited by [email protected]
Looking at things that way, @nikclayton’s reply is unironically correct:
https://mastodon.social/@nikclayton/113680873868692643I mean, seriously, formatting things with a word processor can feel a hell of a lot like getting some developer API to do this one damned thing that it just…won’t…do.
And it feels the same because •it has the same set of underlying problems•. Machines are surprising. Abstractions are surprising. Human-machine gap-bridging is hard.
-
I know, I know, the Reply Guy Armada is coming to tell me “If •everything* is programming, then •nothing• is!” Cool your jets, my friends.
Some things a very much programming, some things only slightly so. The useful question here is not “Where is the precise boundary?” but rather “How much does it belong to this family of problems, and how can we learn about it by bringing the knowledge and experience of that discipline to bear?”
-
@sophieschmieg @inthehands @Crell 'for any reasonable all-or-none definition of chicken, it has happened at least once in history that a chicken has hatched from an egg laid by a non-chicken, something that can obviously never have happened'
-
Here @aubilenon gets at something really important, and per the above, all the comparisons to “is it art / music / a game” etc etc are on point:
https://peoplemaking.games/@aubilenon/113680577564840603Context matters. Intent matters. Patterns of usage matter •a lot•.
-
@inthehands As I've grown older and more experienced, my definition of programming has ended up shifting to "I knows it when I sees it".
As I said before - it is a silly definition of "programming" that doesn't include Coq and Agda, but does include Minecraft and Rollercoaster Tycoon.
(though I'd argue that the activity one performs while implementing eg. a full-adder with rollercoasters *is* programming, even if Rollercoaster Tycoon is not a programming language.)
-
@inthehands scoped problems, their meta-problems, and their ancestors' and descendants' problems…
-
@inthehands @nikclayton PREACH!
-
@datarama
Agreed, right up to the end: at that point, you're making Roller Coaster Tycoon / Minecraft into a programming language.People who build working machines out of the Game of Life quickly start building up design patterns and abstractions. Programming is a kind of problem and/or a way of using something, not just an intrinsic attribute of the object itself.
-
@billseitz
Heh, I’m game as long as we don’t forget that the purpose of the Cube Rule is to be silly -
@inthehands To me, that just means that you can do programming with something that isn't a programming language - just like you can make music with something that isn't a musical instrument.
-
@inthehands @billseitz If it has a frontend and a backend, it's a compiler. if backend only, it's a database. if it doesn't end, it's called a daemon. if it also has a leftend and a rightend it's ravioli
