against my better judgement, i checked my twitter and noticed someone asking a bit about programming language design. so,
there's a lot of different axes by which you might judge a programming language, and these very often get mixed up. here's the ones that are most relevant for the impending rant:
- learnability: how easy it is to learn? how simple is the syntax, use of conventions or design patterns; are there good examples and tooling?
- improvisability: how much do you need to learn, before it becomes useful? can you keep going off a simplified understanding of it to do what you need, or does its full complexity hit you before you can get anything going?
- explicitness: how much does the code literally say, and how much does the compiler/runtime figure out? how much must the programmer spell out, and how much could i get out of reading it in a plaintext editor?
- defensiveness: how much does the language disallow? how often will it look at my "sensible" code and say, "are you sure? this doesn't seem quite right"
these, and others, combine to make up things like "conciseness" and "maintainability", and further into loosely-defined nonsense labels like "scripting languages", "beginner languages", and "enterprise languages".
now, what's often called a "beginner language" is one that focuses on improvisability, because it's being thrown at people who specialize in something completely unrelated to CS but need some calculations done. yeah, this is the only thing python's got going for it: you can know nothing about how computers work, and eventually limp towards something that achieves your narrow purpose.
and this comes at a pretty big cost to almost everything else. you can't ask the user to be explicit about what they're trying to achieve, even if they knew what that was, because you'd be spending weeks explaining type systems. you can't be defensive, because your entire purpose is to run anything that looks somewhat mathematical.
take the program:
x = 1
x = 2
by calling this "valid", we've already decided a lot about the language:
- variables don't need to be defined before use, or assignment causes definition
- variables don't need to be specified as modifiable, they just are (by default, but where would be specify otherwise?)
- we don't need line delimiters, everything fits on one line or we arbitrarily decide where to split multi-line code
- we don't need to write types, the language can figure it out
and all of these come at a cost to our defensiveness: we can't point out typos, accidentally reassigning the wrong variable, wrongly-parsed multi-line code... and it's important to talk about pointing out, because this is inherently tied to errors. this tiny language cannot provide the cohesive error reporting you get from "real" languages, but they are no less necessary for the beginner.
when you add more of python's decisions - common to other "simple" "beginner" "scripting" languages - it gets even worse. yeah, sure, imported code is just a variable you can overwrite. everything is dynamically typed at runtime, and even with source code type hints, our beginner is not annotating their own functions. of course the libraries you're using can redefine basic parts of the language and inspect your code, for your convenience.
eventually, they write something you cannot possibly make sense of - they trip up one of your various invisible rules, and you have to throw up an unintelligible error message. "something was nil in this massive list of functions" is probably all they'll get out of it, before looking for another tutorial to copy from or just rewriting the whole thing.
this isn't meant to belittle those programmers at all. it's just frustration at the languages, and the choices that lead to them staying in use...
and of course someone's going to look at it all and go "that's almost what we want, but what if we added even more non-standard layers to it & made all the pre-existing examples useless?" and they make GDScript. no, renaming callbacks doesn't make them less difficult to learn. no, you can't hack together your own shitty IDE and call it a day.
other kinds of "scripting" languages are in greyer ground. they often want to handle one-use programs that do a particular narrow task, maybe shuffling numbers from a bunch of files, and because they depend on the local computer so much, like, you can't do type safety when you're invoking a different statically-unknown program every line. but they would also benefit from the safety improvements... jury's still out on that one
eh, i'll continue this some other day, maybe i'll talk about what a "good" beginner's language would be like (and for what "beginners", anyways). enough for now