Notation is a tool for thought. You want to optimize it for the problem you're solving. Not that PL notation is optimal, but being beginner-friendly is about the last thing one should care about.
There's like 50 years of notational history, and it can be wildly inconsistent. Some things are somewhat standardized, but there's no central location to look this stuff up. Probably one of the better resources is Benjamin Pierce's "Types and Programming Languages" (often referred to simply as TAPL), but I've seen even recent papers deviate from TAPL's treatment.
So when new people are trying to break into the PL research sphere, there's a huge barrier to entry. Invariably, they'll need to ask other researchers to decipher some of the notation in whatever papers they read because the authors just assumed the notation was prevalent enough to not warrant explanation. This works fine for people privileged enough to already be working in PL research as undergrads, but it's much tougher if you're coming from a different background. The PL research community is fairly active on Twitter, but explanations of decades-old notation do not conform to 280-character text messages very well.
It's a big issue that a lot of us younger PL researchers talk about often. I ask myself: how did I learn this stuff? Many meetings with my first PI as I had to bring up symbol after symbol from whatever papers I was trying to read. I took a graduate course in PL semantics which also helped, but then I've also seen deviations from that notation, so...??? And there's still notation I'm unfamiliar with. I was reading about substructural type systems recently (which are super cool, by the by) and encountered some symbols I didn't know and my current PI didn't know and none of my lab mates knew, so I resorted to a PL Discord server where some grad student at another university across the country was able to chime in with the answer. Such a headache.
I can tell it is super solid content, but, damn if I can crack it.
It's not perfect by any means, but it's better than what people used before (Basic, Pascal).
Anyway, if you want an actually good option, Logo is still around. But it does not let you create anything really interesting, so you better get through it fast or your courses will become boring.
But I'm not sure it's better than old basic. Python is definitely more readable - but it is less helpful than e.g. line numbers in helping form a mental model of a running program; and from my experience, "goto" and then "gosub + return" are easier to explain than funcs with local scope.
If I had to teach newcomers today, I would definitely teach Python -- because, once they do get it, it is actually useful for whatever they need to get done tomorrow morning. But I suspect e.g. BBC Basic (which has goto, gosub but also proc and local) would be easier for them to learn, and would get them farther in understanding programming in a shorter time.
Explaining functions and recursion is tricky in general, but necessary for other things to make sense. There are ways to do so that might be more intuitive for a newbie to grasp. For Python specifically, take a look at https://thonny.org - it's particularly well suited to forming a mental model of a running program, including function calls, in a very visual way.
9000 REM F=FOREGROUND COLOR, X AND Y ARE COORDINATES
9010 IF POINT(X,Y)=F THEN RETURN
9020 PLOT(X,Y,F)
9030 X=X+1 : GOSUB 9000 : X=X-2 : GOSUB 9000 : X=X+1
9040 Y=Y+1 : GOSUB 9000 : Y=Y-2 : GOSUB 9000 : Y=Y+1
9050 RETURN
I have never had the chance to teach BBC Basic, but if I did, even though it has PROCs and LOCALs, I would still go the GOTO -> GOSUB/RETURN route, and only then proceed to DEFPROC / LOCAL.
[0] This would also be introduction to multiple statements - I would show this with one statement per line and multiple statements per line and discuss pros/cons
Also like you mentioned, in even the medium-short term the thing that will get people learning the fastest is the thing that gives them a reason to code. Pretty much always right now that's going to be JS or sure maybe python.
Looking backwards, it is my experience that line-numbers and goto/gosub clicked more quickly and more deeply than function calls.
But, as you say, and as I alluded to in my first post, motivation to write code tomorrow morning is likely a better thing to optimize for.
I would refuse to teach JS, though; it has way too many warts one can't avoid, creating damage that would take a while to undo.
Agreed! I read in some essay (maybe one by pg, even) the following tidbit of wisdom: "I designed this for practitioners, i.e. people with more than a few weeks of experience with the language". This is what languages should strive for.
edit: almost! It was a comment by pg: https://news.ycombinator.com/item?id=21256727
Why is that? If our ideas are good, don't we want the most number of people to know them?
What if PL research isn't getting the population of people and ideas it desires? Look to organizations that have been around longer with even more inscrutable forms of knowledge, how well do they age and evolve?
I think there is a lot more at play here when it comes to optimizing for beginners. Imagine if we had metalanguages for conveying knowledge and that we could distill common subjects from 6 years -> 6 weeks -> 6 hours -> 6 minutes. Or tooling that allowed us to write in both the Simple English Wikpedia, the standard and at the expert level at the same time? Or refactored our writing so it was in the Inverted Pyramid [1], automatically generating tl;drs and keeping our long winded posts on track?
Wouldn't that be amazing.
[1] https://en.wikipedia.org/wiki/Inverted_pyramid_(journalism)
We want that. But notation is for working with and on ideas, not teaching them. You want a tool that maps well to the problem domain, that lets you efficiently operate difficult concepts by proxy of simple symbols, whose relationship maps closely to the rules governing the problem domain.
The task of a beginner isn't to grasp a complex domain immediately (as that's impossible). Their task is to gradually ingest ideas (and increasingly complex notations) until they can operate at the level of the experienced, with the tools of the experienced.
Demanding that a notation used for work is also easy for beginners is just handicapping the experienced, and making advanced work near-impossible. It would be like demanding that every excavator be no larger than 1.5 x 1.5 x 1.5 meters and be made entirely of colorful plastic, because that's what little kids can work with.
The "barrier" that a notation creates isn't there to keep people from crossing it. Building ramps over that barrier is a good thing to do. But the barrier has a purpose - it's there to contain and control the forces of thought that are unleashed inside it.
We want beginner languages to make it as easy as possible to learn programming, and to be able to write a program to do simple things. Our PL ideas may be good, but no, we don't want beginners to need to know them. We want them to be able to learn to program at all, and the fewer ideas they need to learn to do so, the better (that is, the more of them will learn).
And then we want to encourage them to move on to more advanced ideas. To do that, we want to make the more advanced ideas as accessible as possible (which I think was your point). And to do that, we need to make ideas as orthogonal as possible; that is, we need to decouple them as much as possible. This lets someone learn as much as they want about one area without having to first learn all the other areas.
Do you think the tools for broad communication and peer practitioner communication could be very different because they have different aims? Spreading findings in cutting-edge research as broadly as possible is perhaps in some cases not the primary goal.
That is not to say we should in any way that we should gatekeep knowledge! That is unconscionable. It's just that perhaps Watson and Crick's paper on x-ray crystallography of DNA is perhaps not the ideal time to stop and explain what electromagnetism is so that a reader can understand what an x-ray is.
We know that there's a lower limit to distillation that cannot be breached, "Kolmogorov Complexity", which extends Shannon entropy significantly. Furthermore, though this limit is universal, it does (in a well defined way) depend on your prior knowledge. It may seem paradoxical but isn't - it's just too long for this space....
It is not proof in the mathematical sense, mostly because your statement cannot be qualified in such a sense, but it strongly hints that "it would be amazing" because it is impossible.
Which is not to say we cannot do better than where we are today; but there is likely no solution that is, along all scenarios, better.
Are you saying that I am asking for a universal perfect compressor, like I am winning the Hutter Prize [1] ? I don't believe I said that.
To add to the tooling, what if the forum itself "learned you", and took that into account when I respond. It would know everything you wrote, potentially everything you read (on this site), and you in turn would know me. It might help mediate a discussion or prevent folks from talking past each other. What if our systems, could allow us to contextualize communication so that it was grounded in the same basis of knowledge as the receiver?
Might some of those signaling mechanisms be the norms and affectations of each branch of study?
You have given me some things to think about [2]
[2] http://users.ics.aalto.fi/pkaski/kca/
[3] Looks like they have some thought provoking books and interviews https://en.wikipedia.org/wiki/Gregory_Chaitin
Is Mathematics Invented or Discovered? https://www.youtube.com/watch?v=1RLdSvQ-OF0
[4] A physicist looks at linguistics through a complexity lens http://www.its.caltech.edu/~matilde/LinguisticsToronto7.pdf http://www.its.caltech.edu/~matilde/MOL2019MathLinguisticsSl...
> Are you saying that I am asking for a universal perfect compressor,
In many ways, I think you are, of the Kolmogorov/Chaitin kind, if you are talking about language (which I thought you were). If you are talking about tooling, that would expand the same text at different level to different readers, then -- I didn't understand that, and that wasn't my response; I'll have to ponder that for a while before I respond.
I do think that algorithmic complexity is the right context to consider notation, if that wasn't clear -- not in that we can (or should) distill knowledge to the smallest representation, but in the implications of what different "interpretation machines" (that is, persons reading ...) need in order to understand a notation.