Live data from Hacker News

Programming language notation is a barrier to entry

blog.sigplan.org

171–180 of 191 posts

Re: Programming language notation is a barrier to entry

#171
post #44

Earlier quoted context omitted.

Music notation is actually terrible, even musicians agree to that. 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.

Maybe it is, maybe it isn't. But it's not keeping people from being musicans. 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 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. [...] 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.

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.

Re: Programming language notation is a barrier to entry

#172
The talk by Steele linked in the OP is very good.

I recall attempting to read a PL paper for the first time. My background is in mathematics so I found it a fun puzzle trying to figure out what the notation meant. I think I maybe managed to look up a few things and it was reasonably easy to guess the rest. Some things are very hard to search for (how do you google the notation for inference rules where a horizontal line separates the antecedents from the consequents? I spent 20 minutes trying to find the name for the notation and failed).

The other difficulty with reading PL papers is that you need to know that often you should just read the introduction and definitions and skip the extremely long and tedious proofs by structural induction of (somewhat boring) properties like soundness. It tends to be the case that the contents of these proofs is not generally useful (though it is often necessary that such things are proven).

Re: Programming language notation is a barrier to entry

#173

Earlier quoted context omitted.

The problem at hand is not the notation of actual implemented languages, but rather the notation of programming language theory. In other words, when you read a paper published at a PL conference (POPL, PLDI, ICFP, SPLASH, etc.), the notation you are likely to encounter therein. There's like 50 years of notational history, and it can be wildly inconsistent. Some things are somewhat standardized, but there's no centra…

This fact almost killed my Ph.D. I wrote a programming language and type system for biologists and chemists. But the PL theory syntax nearly did me in. TAPL was like banging my head against a brick wall -- completely opaque to me. My PI wasn't familiar with the space either, so I was sort of on my own. The school eventually brought in a PL theory faculty and things sort of got better. But yes, the syntax for PL is ce…

To this day, TAPL sits on my shelf, collecting dust.

I can tell it is super solid content, but, damn if I can crack it.

Re: Programming language notation is a barrier to entry

#174
post #44
post #2

Meh 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.

Music notation is actually terrible, even musicians agree to that. 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.

> Music notation is actually terrible, even musicians agree to that.

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.

Re: Programming language notation is a barrier to entry

#175
post #118

Earlier quoted context omitted.

There was a huge discussion shortly after Julia 1.0 was released regarding scoping [1]. Beginners intuitively think of scoping in a manner different from the way scoping should work in production projects. There was a lot of tension between seasoned programmers and educators (who had to constantly interact with beginners). The community exhausted the entire design space (along with some full-blown prototypes). Eventu…

>> My key take-away is to consider how the language interacts with its ecosystem, not just how it should ideally operate in isolation. Please please, how do we convey this to the mathematicians that infest wikipedia?

I would love someone like gwern [0] to write an analysis of how Mathematics articles on Wikipedia start off being understandable by most and then get lapped into a submicron finish that only reflects an insular subset of folks. These mathematical nuggets sit like hard grains in mud (sorry wikipedia) that only mathematicians can understand.

And in so doing, they slowly bootstrap themselves so far away from any grounding context that it is incredibly difficult for anyone to _learn_ mathematics from reading wikipedia articles.

There are groups doing great things like Setosa [1], nLab [2] and for concepts, Simplicable [3]

[0] https://www.gwern.net/

[1] https://setosa.io/ev/

[2] https://ncatlab.org/nlab/show/HomePage

[3] https://simplicable.com/new/communication

Re: Programming language notation is a barrier to entry

#176
post #123

Earlier quoted context omitted.

There are multiple reasons why that may have happened.

and a lot of them begin with 'perl is a mess...so...'

Well, we were all told that Python was easy and, lo, so it was. And that Perl was line noise and, lo, so it was. But I still find basic Perl to make as much sense as basic Python when I put my mind to it. And both to be painful in the wrong hands.

Re: Programming language notation is a barrier to entry

#177
post #113

Earlier quoted context omitted.

Until languages with a different view completely left it in the dust.

Such is the way of the world. The same will eventually happen with what is in vogue today, and detractors will appear seemingly out of nowhere to talk shit The idea that today's languages and technologies are truly better than the past is laughable, particularly when they recycle so much of what is old and slap on a new name

The idea that today's languages and technologies are truly better than the past is laughable,

That's really orthogonal to the discussion, though. This isn't about general superiority, it's about legibility and barriers to understanding/skill due to syntax and keywords. Perl is infamous for the "code golf is the default style" syntax, keywords, and tokens it employs in this context, and in my experience at least its most ardent fans believe it is a badge of honor.

It isn't, really, and it's the same mistake PG makes when discussing "car", "cons" and the like.

Re: Programming language notation is a barrier to entry

#178
post #114

Earlier quoted context omitted.

In physics, at least 20-some years ago when I was in academia, the notation of our common language (math) was simply part of the exposition when teaching new material to students. Maybe I had exceptions as instructors, but I carried their methods of presenting new notation into my classroom when I taught. Every field develops jargon and writing shorthand. It doesn’t have to be an artificial barrier to entry, and it’s…

I don't think its so much the introduction of the notation, but rather the lack of practice in ensuring the learning of the notation. The analogies I've used in the past come from music and martial arts. In music, when you are first trying to learn an instrument, you aren't also being tested on music theory or creating brand new musical scores. You are focusing solely on being able to smoothly transition between keys…

Yes, exactly. It is hard for me to imagine a physics instructor at any level introducing new mathematical techniques and more or less leaving the student on his or her own to decipher the runes required. The important part is the physics and the relationships of the quantities; not how they're represented on paper. It's kind of sad that CS doesn't seem to have a similar view.

Re: Programming language notation is a barrier to entry

#179
post #84
post #2

Meh 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 is that no one in CS seems to care that "Notation in any field is a barrier to entry". Almost all CS Ed research presently focuses on the problem-solving skill of CS rather than the technical literacy. There is almost no interest from educators to train this literacy despite work from myself [1] and others [2] saying that explicitly training these skills improves student performance. The issue, in my opinio…

Wow, this really hits on something that's been rattling around my brain for years and has come to the forefront in the last week. In most disciplines to achieve mastery you generally focus on technical mastery first; drills, copying the works of the greats, stuff like that, before moving on to find your own "style" and making new creative works. I think a lot of the wisdom of the past about how to excel espoused the virtues of first being able to copy the works of the greats in your field.

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?.

Re: Programming language notation is a barrier to entry

#180

The talk by Steele linked in the OP is very good. I recall attempting to read a PL paper for the first time. My background is in mathematics so I found it a fun puzzle trying to figure out what the notation meant. I think I maybe managed to look up a few things and it was reasonably easy to guess the rest. Some things are very hard to search for (how do you google the notation for inference rules where a horizontal l…

Yes, it's not uncommon to see papers that omit the proof by saying it's a straightforward structural induction. The upside is that it's easy to mechanize in a theorem prover such as Coq.
Post reply on HN