Live data from Hacker News

Programming language notation is a barrier to entry

blog.sigplan.org

131–140 of 191 posts

Re: Programming language notation is a barrier to entry

#131
post #114
post #84

Earlier quoted context omitted.

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…

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

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.

Re: Programming language notation is a barrier to entry

#132
post #15

Earlier quoted context omitted.

Except in a programming language designed for learning programming. Ideally, we would have a good educational language with a clear path mapping the notation from that language to more common notation used in programming languages designed for computer science, software engineering, or software development.

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 certainly one of the more complex, nuanced, and difficult notations I've worked with.

Re: Programming language notation is a barrier to entry

#133
post #89

In this I agree with Paul Graham (and note I don't worship the guy). When talking about some lisps, he wrote [1]: > As names, car and cdr are great: short, and just the right visual distance apart. The only argument against them is that they're not mnemonic. But (a) more mnemonic names tend to be over-specific (not all cdrs are tails), and (b) after a week of using Lisp, car and cdr mean the two halves of a cons cell…

6 months in, Agda is just as cryptic as it was on day 1.

I'm not familiar with Agda, but it's entirely possible its syntax is just not good. It doesn't contradict pg's point.

Re: Programming language notation is a barrier to entry

#134
post #120

Earlier quoted context omitted.

It goes implied in pg's remark, and my own opinion, that the notation must be good for practitioners. It's of course possible for notation to be plain bad for everyone. The argument actually says "don't optimize notation for beginners, optimize for practitioners". It doesn't imply making things difficult for beginners on purpose; just that they are not the priority.

I understand that, I read the remark. But you were replying to a comment about Perl, and I want to make it clear that there are plenty of people and languages that make excuses in favor of practitioners when it's convenient and that they shouldn't. I just don't even think it's a useful remark because you can just claim people you disagree with are beginners and people you agree with are practitioners and now anything…

I wasn't commenting on perl, in case there's any confusion.

I wouldn't call people who disagree with me on PL design issues beginners. I would call beginners beginners. It's not a matter of disagreeing, it's a matter of experience and time working on real projects with a language.

Re: Programming language notation is a barrier to entry

#135
post #13

Ironic that this uses "PL notation" in its title - an ungoogleable acronym (luckily Hacker News has clarified this as meaning programming language notation).

The article was actually posted twice before and I chose to expand PL for exactly that reason, making it more approachable. The article itself is really really good.

Re: Programming language notation is a barrier to entry

#136
> someone was sharing a photograph of a forearm with a tattoo of the Y combinator. Benjamin Pierce looked at it for a moment, thought, and said, “That’s not the font I would have chosen”.

They might have preferred this "font"

https://mindsarentmagic.org/2020/02/19/a-picture-of-grahams-...

Re: Programming language notation is a barrier to entry

#137
I agree that programming language notation is a barrier to entry, but I don't think that there's anything to be done about it other than good resources for learning it.

The problem is that you still need to worry about the semantics of the language. If that's standardized across languages, then you only have one language.

Consider a bunch of languages that all share a standard lambda syntax. If one of the languages has different capture semantics than another (e.g. move vs copy), then you only superficially understand the standard syntax. They mean different things. Having the same syntax doesn't buy you very much.

Re: Programming language notation is a barrier to entry

#138
post #103
post #97

Earlier quoted context omitted.

PG's point is that language syntax and notation should be aimed at practitioners. For beginners, almost anything will be a hurdle till the get the hang of it. Afterwards, they'll be practitioners. Being a beginner is a temporary situation; practitioners are forever.

> For beginners, almost anything will be hurdle till the get the hang of it. Afterwards, they'll be practitioners. Being a beginner is a temporary situation; practitioners are forever. What about languages who support multiple ways to do something in a semi-inconsistent manner? For example with Elixir, in a lot of cases you end up calling certain standard library functions like foo(hello: :world) while others are foo…

> What about languages who support multiple ways to do something in a semi-inconsistent manner?

But that's not really a beginner-specific problem. Even practitioners will likely find it to be a nuisance.

Re: Programming language notation is a barrier to entry

#140
post #89

In this I agree with Paul Graham (and note I don't worship the guy). When talking about some lisps, he wrote [1]: > As names, car and cdr are great: short, and just the right visual distance apart. The only argument against them is that they're not mnemonic. But (a) more mnemonic names tend to be over-specific (not all cdrs are tails), and (b) after a week of using Lisp, car and cdr mean the two halves of a cons cell…

A long time ago I settled on FST and RST as the Right Names for the two halves of a cons cell. The argument is:

1. It's vaguely mnemonic of FirST and ReST, but compactified enough that it's still parseable as abstract names with no particular semantics

2. It's composable the same way that CAR and CDR are, e.g. FFRST == CAADR.

Another good pair of names is LHS and RHS for Left Hand Side and Right Hand Side. Same argument applies.

Post reply on HN