Notation in any field is a barrier to entry. See programmers takes on both math and music notation that are often posted here.
The thing about notation that people sometimes don't think about is that it's used by many different types of people. Some things that would be convenient when notated implicitly make thinking about other things difficult.
The issue, in my opinion, is that notation and technical literacy are skills that students are "expected" to pick up through proxy. They do problem-solving problems, so they are getting experience coding. But the issue with this is that since novices are struggling with notation/syntax, they are juggling problem-solving issues (logic errors) and technical issues (syntax errors).
[1] https://dl.acm.org/doi/pdf/10.1145/3373165.3373177
[2] https://digitalcommons.usu.edu/cgi/viewcontent.cgi?article=8...
Every field develops jargon and writing shorthand. It doesn’t have to be an artificial barrier to entry, and it’s a bit weird to me that this seems to be the case in programming.
Similarly, martial arts often see a high attrition rate. This has a number a reasons, but one that can be addressed is forcing novices to spar with more advanced students way too early. I know the Gracie Jiu-Jitsu schools shifted away from letting new students spar until they've trained for at least 6 months specifically because they didn't want students to show up, get destroyed, and quit out of frustration.
Sort of my point is that the jargon and notation shouldn't simply be introduced and expected to be assimilated without explicit practice that is not confounded with additional problem-solving skills. Those can still be another practice activity, but students should be given the opportunity to just practice the skill without it.
Yet, we think programming is somehow so different, that people should be able to make new creative works (ie: problem solving) at the same time as they're still trying to get a handle on the techniques. Being in the industry for 15 years has shown me there are a lot of really great problem solvers who are terrible at programming, despite having done it sometimes much longer than I have. There's one consistent distinction I generally see. The ones who can code fluently, for whom code just roles off their fingers, all started programming well before a CS program, maybe even back to middle school or earlier.
And I don't believe it's that programming education is that great for the younger age groups (often it's non existent formally), but they have one key advantage. For the most part, they learn to program without the distraction of having to learn CS theory. Not so different from how a musician would likely first learn some simple scales, chords, and songs without any theory. For the unfortunate ones entering a CS program having written little or no code, they're bombarded with very difficulty CS theory and having to learn programming at the same time. I think we'd have both better programmers and better computer scientists if the education system did a better job separating the two.
Thanks for linking your research, I'm going to give it a read soon. Is there a way I can get in touch? I'd love to discuss these ideas with you further and learn more about your research?.
My current research is on exploring different exercise "types" with the hope of building a practice recommendation system that can identify which complexity a student should practice next - a typing or coding exercise, or something in between (Parson's Puzzles or Output Prediction, etc.)
[1] https://research.csc.ncsu.edu/arglab/people/agaweda.html
Do you think that reducing the amount of syntax-errors via a powerful structured-editor would help reduce the syntax burden?
> Do you think that reducing the amount of syntax-errors via a powerful structured-editor would help reduce the syntax burden?
Truthfully, no. It would resolve syntax errors for sure, but I think there's something inherit to actually interacting and fixing mistakes that can't be replicated with technology. If you think about learning a second language, having an automatic translator will help you speak to other people, but you would not actually know the language. Not attempting to invoke Turing's Chinese Room, but rather there is a educational need to make mistakes, identify them, and resolve them that helps.
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.
It clearly developed as a way to reason about music that already existed in the west at that point, rather than be a principled way to go about understanding the underpinnings of music.
Im 57, and have been playing the piano for 50 years. (I still practice 2 hours/day).
The problem with piano isn't reading the music, it's getting your hands in the right place, at the right time, with the least amount of effort, to be able to control the keys the way you want to.
Most of my practicing is getting from one place to another on the keyboard. I'm practicing the space "between" the notes (or positions on the keyboard; I start off by 'grouping' things).
That's why I'm amused when I see "learn keyboard" systems that somehow make you believe the problem is simply seeing a C# two octaves above middle C on the staff and figuring out where it is on the keyboard. You can learn all that in a week. The rest takes years.
I humbly submit that this is the perspective of someone who learned to read music 50 years ago and at an early age, and so who has, for most practical purposes, never not known how to read music.
That perspective will not necessarily be shared by a beginner who has been learning to read music for a few weeks. Sure, you can learn what the lines mean in each clef, and then you can learn to recognise lines above and below the standard five, and then with time you even learn to recognise lines far above and below. You can learn which lines mean something different by default if you have sharps or flats in your key signature, and eventually you actually remember that natural sign just after the start of the current bar before you incorrectly play B-flat for the middle line of a treble clef because your key signature says so. Oh, and you're playing the piano, so you also have to do all of this for a major chord. And a minor chord. And chords with added sevenths. And chords with suspended seconds or fourths instead of thirds. And inversions that almost look like chords with suspended something but that actually have four notes at odd spacing. And then a further note on the octave to make sure all five digits get a workout. With a random double-flat in the middle. Which lasts a strange amount of time, because you're playing that chord as part of a quintuplet. With markings showing suggested dynamics over the whole phrase.
I doubt anyone learns to read all of that fluently in a week, or a month, or even a year unless they are playing far more than any normal beginner. Yes, you can learn the main lines on a stave in a week, but the other 99% of reading music also takes years for most students.
This isn't to say that getting your hand to the right position efficiently and then playing with the action you want doesn't matter; of course it does. I'm just arguing that reading "the right position" from realistic, non-beginner scores is itself a significant challenge for most players, often for many years.
Generally, but not always. I find the deep chromaticism of Messiaen or even Vierne (organ, not piano) very badly served by traditional musical notation - I have to stare at it for ages before it becomes apparent what I should be playing, whereas I can sight-read a typical SATB hymn.
And like democracy, it's the worst idea (except every other system that has been tried). I've looked at many notations over the years, and each seems to get one thing exceptionally right at the expense of nearly everything else (and unusable for some cases), whereas standard sheet music is universally bad for all uses, but not bad enough to make it unusable for any common use -- at least as long as you stay within the 12-notes-per-octave world)
Terrible for what? My understanding is that it is quite good at accomplishing its intended purpose (ie transcribing western music in a dense manner that can be rapidly understood by a professional with only a glance).
I don't know much about music theory myself but the topic of alternative "improved" musical notations came up on HN regarding a music related Show HN that made the front page. Frustratingly I can't seem to dig it up right now. In that discussion many points were made regarding a number of tasks including simultaneously sight reading rhythms and chords, on the fly transposition (I think this was somehow related to symmetry?), and notational density.
Anyone remember all the different ways music was represented as they grew up? What about guitar tabs? I remember simplified math as a kid.
I think this hits on the right approach, which already exists: different languages with different complexity levels for notation.
I don't remember different notations for math and music as a kid...
Music was always sheet music, even when I learned classical guiter; Chord names were "procedures", at times spelled out, and sometimes only referenced. Guitar tabs exist, but were only for people who wanted to play without taking the time to actually learn the craft (at least when I was growing up) EDIT: This was the attitude of every teacher around me growing up, not mine.
As for math - other than having variables written down as empty squares, circles, triangles and stars which were later replaced by letters, I think the first real simplification of math notation that I met was Einstein summation; Everything else was just building on previous things, sometimes with new concepts (like complex numbers) and sometimes as shortcuts (limits and infinites). But they were all shorter than what they replaced, and compatible.
> I think this hits on the right approach, which already exists: different languages with different complexity levels for notation.
There was a guy who proposed something along the article's lines in 1958, which went even farther - instead of "single word descriptions", he chose a single symbol graphical description, because -- though ignored by the author of this article -- most of the world does not have English as their first language. I like the result of that 1958 suggestion a lot; most people place a SEP field over it. The guy is called Kenneth Iverson and the language is called APL with modern descendants J and K.
This attitude really rubs me the wrong way. Tablature is absolutely ancient. It's been around for hundreds of years, and this glib dismissal is just the absolutely epitome of an elitist mindset.
Tablature (for guitar/bass guitar, anyway) reduces note and rhythm information to merely a fret# on a string. This is perfectly fine for people who just want to play a song. I look at tabs sometimes for a quick reference since it's just mentally easier than sheet music.
But if you want to start understanding the theory and relationships between those notes and chords to any meaningful degree, you really do need to start using sheet music. "Fret #3 on the E string to Fret #3 on the A string" doesn't communicate information like "G -> C" does (like the key center, the tonic, etc). It also doesn't limit you to any specific section of the fretboard.
Sheet music is really not that hard to learn. If you want to just use tabs, go ahead, but it's not elitist to point out that sheet music is basically essential for progression as a musician. Music theory is a fundamental part of that progression, unless you just want to play tablature (or sheet music) robotically.
(Yes, I did grow up in a culture highly inspired by older/east european ideals, where kids were welcome to do whatever they want such as learn the guitar, after they've finished their homework, practiced their piano lessons. And as long they're on a path that -- if kept -- would lead them to be on a professional level) I played classical guitar for a few years, but stopped because I just wanted to play popular music, and there were no teachers around who actually taught that who were accomplished enough to be considered worth the money by my parents (who had a very limited budget).
1) First learning multiplication with an "x", as in "4 x 3 = 12".
2) Then in algebra switching to " * " (dot) to avoid ambiguity with x-as-a-variable.
3) Later learning that " * " wasn't multiplication but actually dot product - it just happened to do the same thing with two scalars.
1) When I grew up, multiplication and the letter X were styled very differently in books so that that was never ever a confusion.
2) The switch to dot, was NOT to avoid ambiguity, but to shorten stuff (IIRC we did that when we learned order of operations and started solving simple equations - writing "4 (dot) a" instaed of "4 (cross) a" -- and then just "4a" but multiplications still appear often among parentheses - they were not ALL replaced with dot.
3) That's simply wrong. It is a different operation; dot product reduces to multiplication among scalars -- but so does cross product. It's okay to denote scalar product with either.
Granted, this might be dependent on the exact curriculum one studies through - but mine did NOT have a simplified one that was replaced - instead, it started with the most explicit one, and got simplified (with new, compatible notation that did not replace older one, only extended it) through the years. And it seems this was almost the case for you too.
On 3, I think you misunderstood my point - in 2, we learned dot (the symbol) is multiplication, never touching on dot product because that was a good year or two later, then at that point were corrected to it not being what we first learned.
I think it’s a really interesting approach of stripping away a ton of information and relying on the musician having heard the music before.
This really comes out in math, where choice of notation can call attention to different aspects of a concept. The Wikipedia page for ordinary least squares, for example, freely intermixes (depending on how you count) 3 or so different styles of notation.
I think that this is why I've always been fascinated by Knuth's literate programming. If you want to make something more understandable, saying it twice in two different ways is a great technique.
[0] https://analyzethedatanotthedrivel.org/2018/03/31/numpy-anot...
K below:
,//
|/0(0|+)\
Not disagreeing that NumPy is more popular. Am disagreeing that they are "extremely similar".