The Unclear Impact

Tracery is programming. HTML is programming. The "real" programming language vs "just" markup/data/notation languages exists to uphold the idea of a wizard or priestly class in computing.

This goes both ways. Saying "HTML is not a programming language, just writing HTML and CSS isn't programming" is just a way of saying, if the thing you work on has immediate, visible or tangible results, it's less virtuous in some way than the less immediate, less visible, more abstract work that is often classed as "real" programming.

But, similarly, saying "I don't code, I just write Tracery grammars" is a contradiction; Tracery is an interpreted logic programming language if PROLOG is.

And if you say we should draw the line at "Turing complete", I say that's silly too, since it's entirely possible to make "real" programming languages that aren't Turing complete; Dhall and VCL come to mind.

There is no distinction. If you are describing how a computer should operate in a form the computer can understand, through however many layers of automation, you are programming that computer.

@noracodes the idea of a wizard class in computing suggests the notion of priest, warrior, and rogue classes in computing too

prestige classes: computing paladin; computing bard; computing gnome pickpocket

This distinction also lets people section themselves and their pursuits off from those they find less desirable, for whatever reason.

"I'm not a tech person, I just write interesting CSS things."

"I'm not really into programming, I just make websites."

"I'm don't do all that programming stuff, I just strap a few APIs together and call it a day."

"Programming is too hard for me. I just write rulesets for the actuarial risk engine."

"Oh, software isn't really my bag. I just tune the numbers on the existing control system."

"No, the programmers are the ones that make the missile hit its target; I just work on the sensors."

You see?

My thing doesn't matter. Please don't look at it too closely. Whatever this system does, it's not my fault.

@noracodes i always giggle a little when i remember that the name “Unix” is a deliberate joke about this

@noracodes I don't know why I am getting triggered when someone says HTML is a programming language. I think I need to go see a doctor.

To bring this full circle, though - these really are qualitatively different things. Frontend is not backend, backend is not database, database is not operating system, libs are not kernel, kernel is not microcode. Or, for instance, experts on building firmware for cars might not be the best at running a social media website a webscale.

Let's just be precise when we talk about things.

@noracodes a Turing Complete General Purpose Programming Language is just a DSL for making computer programmes.

some useless ones like Turing Complete General Purpose Programming Language compilers, and some more useful ones like interpreters for DSLs that solve concrete problems, like Puppet and CSS (same thing, really, just different… Domain)

@noracodes programming is when you make the computer do what you want! opening a text file is programming, playing a song is programming, deleting a file is programming!

@noracodes I don't think it's prejudice, but there's a clear definition what a programming language is and what is not. Of course, this doesn't take anything from HTML, and people who design beautiful sites have all the appreciation.

@noracodes let's make PowerPoint a programming language.

@noracodes i learned/realised this a long time ago, so now, every time this discourse comes up, I'm just like, get on my level!

@noracodes BTW, i also like Hillel Wayne's framing, of how there's loads of programmers out there, but not all of them are software engineers

meaning, their programming is task oriented, and not their version controlled, jira issued, day to day job, with the goal of making / improving software

some of these people would greatly benefit from our methodology, if our tooling for applying these methods weren't so shit

*stares at git forever*

and some of them would greatly benefit from us improving these tools

*stares at git forever more*

@noracodes @nomemory

One way I like to think about programs (I got this brain worm from some summer school on probabilistic programming, I think) is that programs are described by finite terms, but the semantics of terms (defined by structural induction and least fixed points) form some nontrivial \omega-complete partial order when ordered by termination. Which is just abstract nonsense for

1. programs should be described in a finite way
2. you should be able figure out what a program means by looking at their parts and composing them in prescribed ways
3. it should be possible to compare programs by which inputs they terminate on, provided their outputs agree on all inputs they both terminate on
4. composition should be continuous: a program should terminate if all its parts terminate (in parallel, in sequence, or in whatever way the semantics define composition)

after copious amounts of handwaving, this should exclude anything that cannot be executed on a computer (programs with infinite descriptions, or cases when you have to take a non-least fixed point over something infinite – but ltps exist by the Kleene fixed point theorem). but allows expressing the lambda calculus, so it captures all Turing machines

crucially, non-continuous semantics, where a program terminates if a part of it doesn’t terminate is excluded. this encodes the sore lack of a halting oracle

HTML would be excluded because the underlying \omega-cpo is trivial, I think (any HTML page can be rendered in finite time, so there is no meaningful way to compare them by termination). CSS would probably be excluded because the CSS selector language is cleverly crafted to always evaluate in a finite number of steps

the beauty of looking at programs in this way is that this makes clear that the analysis of programs cannot merely depend on their syntax: any sufficiently interesting analysis will have to look at the underlying semantical category, which has much richer structure! handwave, handwave by Turing and Rice we know it is so rich in fact that it’s hopeless to provide a general algorithm for program analysis!

in any other case, where analysis would be possible by just looking at the syntax of terms, we’re facing data (or configuration)

not as if any of this matters for the present topic: humans are rarely practically interested in programs that never terminate in convoluted ways. if it gets stuck in mundane way, like in a loop, we just get bored after a while and figure out enough to just close it

but while creating data or configuration can easily be so complex we’d be better off not to bother, only programs can theoretically provide unfathomably impossible complexity

(nevertheless, I’d expect the complexity faced day-to-day by someone writing “data” in HTML, CSS, Datalog, etc. roughly comparable to someone writing Lisp, C, Java, Haskell, Prolog or anything else outside of mathematical fun times)

@noracodes and then we have the grey-area no-man's-land in between the two that is the Unix Shell. You have to be a wizard to use it but a moron to try.

(Disclaimer, 50% of my code is written in shell because I'm a sysadmin)

@joat @noracodes I keep telling my coworkers that writing something in shell may be the quickest way to do it, but learning about all the things you *have* to keep in mind to make it reliable and secure takes many years, and the end result is you gradually, line by line, rewrite it in something with shell syntax, yet not entirely unlike Python, but with weirder markup... Yes, I still do it - sometimes.

@mrrmot @noracodes I'm always on the lookout for shell tools that can do things we'd normally write scripts for. Like awk for text hackery, jq for JSON, Miller for tabular data, and many other more humble ones. I've avoided writing YAFS with those many times.

@joat The funny thing is one of the people on the Austin group - the standards body behind POSIX - has always held the position that the original purpose of the Unix shell was interactive command execution, and scripting arose merely as a convenience; that the original Bourne shell and now the POSIX one are not meant to be used as programming languages. (Of course, later shells - ksh, zsh, bash - embrace programming as well as interactive use.) So yeah, using what used to be called "the programmer's toolbox" (all those tools you mention plus the "standard" ones - cut, tr, fmt, sort, sed, et al) to avoid writing hundreds of lines of shell code is exactly as intended. @noracodes