Hacker News new | past | comments | ask | show | jobs | submit login
Programming language notation is a barrier to entry (sigplan.org)
115 points by seg_lol 25 days ago | hide | past | favorite | 187 comments

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, and languages should be designed for people who've used them for more than a week.

In particular, the last sentence. I find arguments that go "but this looks confusing to a beginner!" unconvincing. Language syntax and notation should be aimed at actual practitioners, not beginners.


[1] https://news.ycombinator.com/item?id=21256727

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). Eventually, the core Julia team chose to use more forgiving scoping in the REPL (virtually always the first point of contact for beginners), while actual projects enforced stricter scoping rules.

My key take-away is to consider how the language interacts with its ecosystem, not just how it should ideally operate in isolation. I have found the Julia team to be consistent in this pursuit. If the first point of contact is intractable for beginners, the project is dead on arrival. A technical tool should be tailored for experts, but you don't want to kill adoption along the way. Engineering is tradeoffs.

This article goes more in depth along the same lines: https://pchiusano.github.io/2016-02-25/tech-adoption.html

[1] https://discourse.julialang.org/t/another-possible-solution-...

I understand there's a larger point being made here but I wouldn't give the decision that the Julia team made about scoping as an example of how to design a language. It makes the language inconsistent and now both beginners and experienced developers have to learn an exception instead of one group having to learn a slightly novel approach to scoping.

Allowing both seems like the worst solution. Inconsistency is annoying for both beginners and professionals.

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

I had not realized that was going on, but it makes a lot of sense now you mention it.

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.

How do you define these so you can use them like CAADR?

(defun ffrst (l) (caadr l))

Lather, rinse, repeat.

For extra credit, write a macro that will save you having to type every possible combination out manually.

I did this once for Clojure and named it car-cdr-construction-set! with an argument for how many levels deep to define in the current namespace.

Some people in university hinted that some lisps had special parsing stages for car/cdr based functionals. They may turn c(.)*r into nested (car (cdr ( ... ) ) ) calls.

I don't exactly disagree: the function names work -- but instead of those functions you could be using pattern matching. When the need for the functions is rarer, the disadvantages of that kind of name become weightier.

I think different languages for different audiences. I also think that languages that are noob friendly can achieve broader appeal and greater mindshare.

For example, ruby has plenty of warts and annoyances that become evident with experience, but I still find plenty of ruby code that’s lovely to read (like it’s telling a story). Plenty of atrocities too, which is exacerbated by the language.

I see the value in succinct languages too, which require a knowledge investment to be productive. Just more efficient.

It’s kinda like QWERTY typists and stenographers, but with far more middle ground. No one can argue that stenographers are faster, but it’s also not a realistic expectation for everyone to learn it.

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.

Alternatively, instead of car and cdr one could have pattern matching, which is more declarative and less error-prone than c(a|d)+r.

Everyone is a beginner before they become a practitioner.

Look at Perl for an example of what happened to a language with syntax that appealed only to people who were already Perl-practitioners.

> Look at Perl for an example of what happened to a language with syntax that appealed only to people who were already Perl-practitioners

It became for several years one of the most successful and widely used scripting languages on Unix?

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.

> and in my experience at least its most ardent fans believe it is a badge of honor.

Indeed. And I disagree with your opinion. For all its terseness its still wonderfully expressive and it goes against the horrible trend set by Python with its "one true way" bullshit. That we all so willingly accept the commodification of our trade so the paymasters can eventually decrease our demand is shameful.

We should strive for a certain level of difficulty if anything to separate the wheat from the chaff. You wanna play with the big boys? Learn to code in a big boy language.

Instead we let the trainwreck that is modern JS take over.

Who is "we"? And take over what? Backend web development? Hardly--that's still mostly PHP. The most sophisticated pieces of the most sophisticated internet application ("web") software are generally written in Java, C++, or Go (some Erlang, some others, etc., but mostly those). "Big boys"? What does that even mean?

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.

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.

At the beginning, languages have zero practitioners. To at least some degree, they have practitioners in proportion to how many non-practitioners bother trying to become practitioners. The more off-putting the syntax is to a non-practitioner, the fewer bother to try to make the leap.

Now, you are right that the syntax is for practitioners. But if it's too bizarre to non-practitioners, it is in fact a barrier to entry.

> 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(:hello, :world). Now, there's special magic happening in the first case but stuff like this is super confusing and it gets easily compounded with more complex examples.

As a beginner I found Ecto's various ways to calls things super confusing and I had to reference examples almost all the time to get the syntax right (which often had multiple ways of being "right"), but I've also talked with more experienced Elixir developers and they get hung up with Ecto's syntax too.

So where do you draw the line between making the language / DSL better and keeping it catered to only folks who are basically at the same skill level of the language creator?

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

I had (have) the same experience with Ecto but Ecto != Elixir.

One of the super cool things about Elixir is how easy it is to extend the language with DSLs. However (and Jose et al are very up front about this), the more DSLs and macros you use, the more confusing it's going to be. Using macros is a tradeoff because it can be a very neat solution but it also obscures what the code is doing quite a bit.

Re. foo(hello: :world) vs foo(:hello, :world) - that one I got the hang of more quickly, though I'll admit it's confusing at first. In the first you're providing a keyword list (which is merely a list of 2-membered tuples where the first member of the tuple is an atom). And when a keyword list is the last (or only) argument to a function it can be provided without the brackets. So the same thing could be written as foo([{hello:, :world}]) or also foo([hello: :world]). In foo(:hello, :world) you're just providing arguments. When you're first learning the language this can definitely trip you up but I think once you become a "practitioner" it's not too bad and ends up being pretty nice.

God Elixir is so cool.

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

They seem like a good thing to me!

The aim is never to make things difficult for beginners on purpose. The point is that making things less confusing for beginners is not worthwhile if it comes at the cost of making things more cumbersome for practitioners.

Addendum: I completely misread the comment I was replying to. My comment "they seem like a good thing to me" makes no sense. Please disregard. Unfortunately, I cannot delete it now.

I actually agree with the comment which states "But that's not really a beginner-specific problem. Even practitioners will likely find it to be a nuisance."

I'm pretty sure I hated writing Perl before, during, and after I was any good at it. It's unnecessarily full of ultra dense symbols, many of which are made dense for no reason. ($| means "hot pipes" means you want to flush all characters always. Set it non-zero to make it do that. Want saner names? Why don't you `use English;`, you rube?)

Sure, being a beginner is a temporary situation, but let's not excuse absurdities and unnecessary convolutions as a result.

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 can be argued.

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.

I'd even go further, notation should never .. well that's too radical, rarely be a topic of discussion.

Concepts are way more important. Spending time on syntax is like having a course in tar --flags.

This explains the success of APL.

In case you're being snarky: it doesn't logically follow that because PL notation should optimize for practitioners, that any notation will be successful. It's possible for a notation to be bad for practitioners as well.

There’s a small group of people (financial analysts, mostly) who use APL derived languages, are hugely productive and make tons of money, and have no interest in changing the language they use. Not every tool is for every purpose and not every language should try to appeal to all users.

Although many of the APL derived languages changed their syntax by removing the fancy symbols. I'm not disagreeing, though: some people like them, some don't, and that's why people use j, k, and APL.

What about beginners who stay beginners?

A lot comments are misunderstanding this article. This person is not complaining about differences in programming syntax across languages at all. He is making a very specific complaint about how PL Notation (i.e metasyntax not syntax) in academic literature isn't standardized. This has nothing to do with the vagaries of Perl vs Lisp and everything to do with how PL white papers are written.

Guilty as charged! I did read the article but misunderstood it. In my (admittedly weak) defense, the conversation that ensued in the thread started by my comment was interesting. But you're right: it was also off-topic!


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

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 a bit weird to me that this seems to be the case in programming.

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.

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.

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

Sure! My research bio is at [1]. And I definitely agree there's a disconnect between how younger individuals learn CS and college-level CS. Often those younger individuals could be seen as "automatic A's" because they've already overcame that first syntax hurdle.

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

Is part of this due to an academic vs. professional dichotomy? i.e. most CS undergrads are CS undergrads to become professional developers, while most CS undergrad courses are taught with an eye towards further graduate/academic work?

I wouldn't say so; I've taught for a community college, teaching college, and R1 and while there are differences, it seems to be a consistent issue across the board. While there are clearly individuals more interested in graduate work, there are groups with a primary goal of preparing students for industry.

That's really interesting - I enjoyed the section on transfer learning. Are there any screenshots of Phanon without having to sign-up to the Utah website?

Do you think that reducing the amount of syntax-errors via a powerful structured-editor would help reduce the syntax burden?

Its not a screenshot, but the Utah team posted this video for ICER [1] (with timestamp). I'm not apart of their team, so that's the best I can offer.

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

[1] https://youtu.be/AdYMJ923Lys?t=90

No one seems to care? What is Python if not a referendum on unclear keywords and whitespacing?

Sorry, I mean to say in the CS Education domain.

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.

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

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.

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.

Sounds interesting! Link please?

I think Python filled that niche.

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.

I've been thinking about this a lot lately, and I agree Python is way better than Pascal or Java which it replaced as an introductory language.

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.

GOSUB/RETURN may be easier to explain, but of course it also doesn't cover many things that functions with local scope do.

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.

Oh, of course. GOSUB/RETURN are easier to explain, but only as a stepping stone towards functions; I like them because unlike functions+locals, which are much more "all or nothing" - whereas when I taught basic, I would start with "GOTO" which is trivial for everyone to understand; then go to GOSUB+RETURN, which is just a tiny bit harder, but still very capable - my complex gosub+return example was flood fill[0]:

    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
Which does recursion, visually, with only gosub/return, lets me touch on stack overflows (trying to fill too big an image would on most interpreters).

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

I have taught newcomers quite a bit and until you've done it you probably shouldn't trust your intuition about what non-programmers will and won't get hung up on.

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.

I have taught GW-BASIC, and also Python, C, Fortran and a couple of other languages through the years. But I don't trust my experience because it spans three decades, in which my experience changed, my student's backgrounds changed, etc.

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.

> being beginner-friendly is about the last thing one should care about

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

> but being beginner-friendly is about the last thing one should care about.

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)

> Why is that? If our ideas are good, don't we want the most number of people to know them?

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.

If you go into a bike shop, you see that the bikes for beginners are quite different from the bikes for experts, and especially those for professionals. I mean, even the riding posture is different.

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.

> Why is that? If our ideas are good, don't we want the most number of people to know them?

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.

> Wouldn't that be amazing.

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.

You got me to chuckle at, "thought terminating thought experiment". I will file that in my cliché attaché.

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]

[1] http://prize.hutter1.net/

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

I'm not sure how I contributed to your cliche attache, but I'm happy to help :) (The quotes imply it's reference to my words - but I wonder which ones?)

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

The learning curve is definitely important when I decide what language to use.

You'll miss out on the most powerful tools this way, though.

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

> The problem with piano isn't reading the music

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.

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.

True (I hate it too).

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)

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

And just like programming, there are versions of those with easier notation to ease entry.

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.

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

Guitar tabs exist, but were only for people who wanted to play without taking the time to actually learn the craft

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.

The fact that tablature is ancient doesn't mean it's great for "learning the craft" (in other words, understanding music theory). The age of a notation system is completely irrelevant when deciding what notation system to use, really.

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.

I just added an edit: I wrote this, but this wasn't my mindset -- that was the mindset of every teacher and adult around me growing up, including those who couldn't read sheet music and used tablature to play.

(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).

Another math example:

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 1, we used typed-up worksheets that didn't have different styling. And even then, on occasion we had to write the "x" as part of an answer, or the teacher on the blackboard while teaching, which was more what I was thinking of anyway.

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.

Historically if I'm not mistaken, dot is multiplication between scalars, and only later became "dot product". But this is distinction without difference. You used "cross" or "dot" to denote scalar multiplication. You did NOT use "a dot product restricted to scalars".

TIL dot is dot product. I just thought it’s another syntax for multiplication. That’s a pretty good example.

It's interesting that guitar tabs are quite close to old tablature notation, which was used for lots of string instruments such as the lute. Renaissance lute music is usually tabbed.

Thanks for sharing. I had no idea.

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.

> Some things that would be convenient when notated implicitly make thinking about other things difficult.

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.

I disagree. There’s a reason NumPy is extremely popular and APL/J never were, even though semantically they are extremely similar [0]. It’s not because it’s difficult for people to grasp the underlying concept of array-based programming, it’s because NumPy’s notation is far simpler to learn.

[0] https://analyzethedatanotthedrivel.org/2018/03/31/numpy-anot...

APL (and especially J and K) are about a lot more than array based programming, and NumPy didn't try to encompass those, which is part of the reason it is easier to learn.

K below:


The first expression is usually called "flatten" (take a nested list and produce the list of all items in a single-level, in order). The second expression is a solution to the maximum-subarray-sum problem. Both of them leverage a hell of a lot more than "array" programming; in each case, every single character brings its own semantics, and the combination yields the semantic of the entire expression.

Not disagreeing that NumPy is more popular. Am disagreeing that they are "extremely similar".

That doesn't sound right to me; APL's notation is not particularly difficult to learn, especially if you're familiar with existing basic math and programming language symbols. What's hard is grasping the underlying concept of array-based programming and using it to do useful work and solve problems. NumPy is popular because it piggy-backs on a popular, widely used, and free language which also does a lot more than array manipulation, if NumPy existed on its own then its notation would not be simpler to learn it would be bizarre.

Oleg Kiselyov, a prominent functional programming researcher, has advocated for using a language like Haskell or OCaml alongside or in place of equations where things like denotational semantics would usually be. I quote [0]

Running [code] is a good thing because in Cartwright and Fellisen[1], [there is a] trivial typo (- instead of =). When you write things in TeX it's easy to make some mistakes, it's a good thing that it happens as a clear typo here but it could be a less clear typo and then it requires significant thinking [..] what was the correct thing. The advantage of using Haskell as a metalanguage is that if you replace = with - by mistake, almost certainly the compiler will not let you get away with this, you will catch it right away.

Oleg does exactly this in [2]. If the sequent calculus-style rules put you off, there's an OCaml implementation!

As an example I did this to the denotational semantics of R5RS Scheme, translating them to Haskell, the final result[3] is essentially a one-to-one mapping from the math to code.

However there are some aspects of PL theory where you cannot write things as code directly (e.g. operational semantics, typing rules), and you have to resort to notation, but it's used pretty consistently.

[0] https://youtu.be/GhERMBT7u4w?t=4395

[1] http://citeseerx.ist.psu.edu/viewdoc/download?doi= (typo fixed)

[2] http://okmij.org/ftp/tagless-final/ski.pdf

[3] https://github.com/siraben/r5rs-denot

While I agree that a standardized notation would be great (though it's hard, e.g. I think e[v/x] is a lot harder to understand than e[x := v] if you've never seen it before), I take issue with the idea that if people struggle with notation that it must be the fault of the notation.

The author quotes a tweet about someone complaining about the notation used for a basic type judgement for being cryptic. Any introductory text will immediately cover this and looking it up, you can learn the notation (which is really rather simple) in about 5 minutes. Yet, the tweet author claims that they saw this notation 12 years ago and still can't understand it. Well, to me the only reasonable conclusion is that they simply didn't bother spending a few minutes looking it up and instead expected that they would magically understand it after enough time has passed. I seriously doubt that gammas being used instead of the word 'context' is why they're struggling.

And this is my core issue with a lot of these "notation is a barrier" complaints. Instead of being valid complaints about esoteric notation (and especially using this notation without defining it!), it's people who believe that knowing how to program means you should be able to read any PL text without any preparation which is just unreasonable. If you want to seriously engage with a paper, you'll have to read up on the basics first in literally any field.

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

To be fair, this is posted on the SIGPLAN blog. SIGPLAN is the ACM's Special Interest Group on Programming LANguages. (The ACM is the Association of Computing Machinery.) While the title doesn't work well when posted to places like HN, it's not nearly as ambiguous if you're a follower of the blog in general haha.

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.

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

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.

While the notation may definitely be a barrier, I believe that the biggest hurdle for most people is the logic required for formal languages and context free grammar. It is very unlikely that many will have much experience writing mathematical proofs, which is what these language definitions turn into, and is much different than working with prose.

This article is talking about the notation of programming syntax (ie Backus-Naur form[1]) while many of the comments are talking about syntax itself.

[1] https://en.m.wikipedia.org/wiki/Backus%E2%80%93Naur_form

People are being dismissive of the premise here. But I remember when someone gave me a link to a Haskell repository. I had no idea what was going on, or what those alien symbols meant. I can only imagine that the barrier to entry for Haskell is much, much, much higher than that of an Algol descended language.

If you're familiar with a recipe for baking a cake, the barrier to entry for most imperative languages is small. If you're familiar with Lambda calculus, I imagine the barrier to entry for Haskell is similar.

In both cases, entry is the easy bit. Learning the notation is a somewhat orthogonal and arguably much smaller impediment than the inescapable difficulty of figuring out what you're trying to accomplish, and then how to accomplish it.

There is a tendency among the more academic of CS researchers, of spending so much time in academia to assume that because they find math notation so simple from their experience using it that this means it is clearly superior to the notation actual programmers use in actual programming languages and treat that like some aberration from industry.

Personally I've always found math notation feels like it was optimised for space efficiency and writing speed on paper, akin to legal shorthand rather than the beauty I'm always told it has. Similarly for attempts to bring programming syntax closer to math syntax. In college I found myself translating equations of medium complexity such as the Fourier transform into pseudocode to understand.

Obviously however, my familiarity with programming notation colours my perspective as much as their experience with math notation colours theirs

Actually basic Haskell syntax is very simple, it's lot closer to basic math symbol and equation. What make it hard to understand is the use of abstractions like Monad, Transformers etc, and people use it a lot in Haskell. It's very hard in fact to make a useful Haskell program without a Monad. That said, I don't think another mainstream languages that use advanced abstraction like Haskell is gonna be easier to read either. Try to imagine a Java program that trying to use higher-kinded abstraction, I bet it won't be pretty and easy to teach. I have experience trying to explain about Monad in Ruby to a coworker and it's really hard.

It's easy, it's just like higher order forms of math!

Mathematic notation is horrible. We have to teach kids the forms for _years_ and most are still shaky at it once they're adults. You have to memorize everything because the syntax is basically shorthand, nothing is self explanatory. Then we wonder why kids struggle with math.

If a programmer decided to replace his function names with single characters from a different language he would be dope slapped by his colleges. If he always used single character variable names he would be kicked out.

I have exactly this frustration with math. The notation was confusing at nearly every level of my education perhaps starting with operator precedence in arithmetic and escalating exponentially in college with more advanced forms of math. I remember nearly flunking calculus (saved by a merciful curve) with no concrete understanding, only to find in my later engineering curves that calculus was downright easy and intuitive to me, but the notation (and perhaps the pedagogy) were inhibiting.

To this day, when I'm reading computer science papers, I have to look really hard to make sense of the math gibbrish and get at the actual meaning, and often when I do I realize that it would have been much clearer in a few lines of JavaScript or Python or Go or Rust or just about anything else.

Well, perhaps anything except Haskell, OCaml, and similar. Even after learning the syntax, I still haven't internalized it as effortlessly as I did with other languages. Note that lisp is not very algol-like and I have a much easier time parsing it than I do Haskell despite relatively equal familiarity. I think Haskell has given us a lot of great ideas, and thankfully they've filtered down from the Ivory Tower of academic languages into pragmatic mainstream languages, such as Rust.

Monads, Transformers etc can make Haskell code hard to follow. But the culture of overusing unpronounceable/unmemorable operators is what makes Haskell really hard to read.

>@> <$> <*> <|> <=< <+> <$> --> <&&> <||> ||| .|.

None of the above are made up, all are from real code.

Some of these are explanable from mathematical conventions. In abstract algebra it's common to surround an operator in a circle to denote a "generic" or "lifted" operator. So <$> denotes a "lifted application", i.e.

  ($)   ::              (a → b) → a   → b
  (<$>) :: Functor f => (a → b) → f a → f b

Of code is using <$>, <*>, And <|>, it's probably easier to read & understand at a glance than the the best, most read-optimized Go equivalent.

If you know what those symbols mean (aka the interfaces they belong to.)

If you don't have that knowledge and are instead complaining about the fact that they have symbols period, I suggest you quit spouting answers when you should be asking questions.

Why is <$> for example easier to read, type, understand, Google, or any dimension really over "fmap"?

Applicative style for one

    data Person = Person
    { age :: Int
    , name :: Text
    , height :: Int

    <$> parseAge
    <*> parseName
    <*> parseHeight
Applicative style is one of the easiest constructs to read relative to the power of what it typically does.

Most other times when you use <$>, you're using it instead of something like this:

    fmap f $ x y z
Which is simplified by

    f <$> x y z
Google is a non-issue. Hoogle exists and works great (and can even index all symbols importable by your project)

> I can only imagine that the barrier to entry for Haskell is much, much, much higher than that of an Algol descended language.

Haskell syntax is not more complex than an Algol descended language. It's only confusing if you expect an Algol descended language, for example because you're already familiar with them.

I have an easier time understanding Haskell than Go codebases, and I have equal and large experience with both.

When I first learned Haskell, I only knew C. Haskell codebases were immediately so fun to dive into and learn from. I wouldn't hesitate to hit the "Source" button on Hackage. The fact that all code could be reasoned about locally with just simple symbolic substitution was a breath of fresh air.

To a person with 0 experience at all, Haskell or Algol-descended languages are going to be equally alien. Your experience is because you had asymmetric familiarity.

So I'm not surprised by your experience. But it says more about you than Haskell.

The comments actually hit on the real solution to notation issues: it should be executable.

It might require a library or file of accompanying "assumptions" that enables a concise "display" notation that appears in the text, but it would allow anyone to examine and understand what was being specified by having a common, concrete base of reference and the ability to query and examine it from whatever angle works for the reader.

Or pseudo-code.

I can take some pseudo-code and turn it into a working C (or python) implementation to poke at without too much trouble but papers with pure algorithmic notation usually get put in the "I'll look at that later" folder which I never get around to looking at.

Granted, I'm not the intended audience for most of the papers I read since I have no formal CS (or math) education -- though enough information is out on the interwebs depending on how motivated I am to try out whatever shiny-new I'm learning about.

Uniform, well defined programming language notation has been proposed in 1958 by Kenneth Iversion: https://en.wikipedia.org/wiki/APL_(programming_language)

It goes farther than suggest in the article by dropping words entirely and using symbol, which removes the "need to use English" barrier which is invisible to people whose mother tongue is English but is most definitely there.

It gets treated with a SEP-field by most of the programming community.

The problem is not that objectively "X is a barrier to entry" (for whatever X is). The problem is that everyone has their level of comfort with something they consider natural and everything else needs to be simplified. But that something has a huge variance and unclear mean/median/mode.

One of the very last EWDs[1] has strongly influenced my thinking on this subject. Dijkstra is talking about mathematical rather than programming notation, but by and large the same reasoning applies to both. A program text should optimize for clarity to other programmers reading it.

From the linked text: > others shun clarity lest their work is considered trivial

This is a real problem in industry. Being told that the simple solution you spent 5 days finding for a very tricky problem proves that you were just goofing off when it was that easy is annoying, to say the least.

[1] https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/E...

Is PL notation really that bad? I think the more significant barrier to entry is getting the mental model of programming. Of course not all people can be good programmers, but it doesn't seem all the programming notation would be hard for someone with abstract thinking skills.

Ironically, I ran into this talk by Guy Steele today. He presents the development of the Computer Science Metalanguage.


Is this saying that a new language is the barrier to learning a new language?

I don't like the term "programming language" and your comment illustrates why.

We would expect that an aspiring architect needs to learn a little bit of notation, and a lot about the tradeoffs and constraints of making a building. We should expect that programmers learn a little bit of notation, and a lot about the tradeoffs and constraints of making software.

Knowing your tools well is important, but not sufficient. Focusing on "programming languages" makes people think that the important part is the notation. It is not.

I think I understand your point. Do you think that the "programming language" should sacrifice the usefulness of its syntax in order to appeal to beginners more?

There is also I think a difference between Architecture and software development in that an architect aims to design and plan with drawings and documents a building that in the end is distinct from them, whereas software development produces a set of documents that are synonymous with the software itself.

Not to detract from the main point. A program is also distinct from what it produces unless it's a quine.

> Do you think that the "programming language" should sacrifice the usefulness of its syntax in order to appeal to beginners more?

No. This has been tried a lot and has mostly failed. The notation can be a barrier but it isn't the hardest part.

No, this is about academic notation.

If you compare C to Java, you will find differences beyond merely notation.

At the other end of spectrum, the lack of notation variations limits the vocabulary of a PL, which in turn either limits the feature of a PL and/or making it verbose. Verbosity can make things a bit difficult too. I am still a bit frustrated with Java's annotation simply because something that starts with `@` can mean widely varying things.

Since the author is writing about mathematical notation, it is true that mathematical notations sometimes can be bothersome. `Σ` for example has a better (crude) representation in programming language `.forEach` or `.map`. Someone who doesn't use them very often can be really frustrated by it.

But, this also applies to non-programming languages. Logograms, like Chinese hanzi, Egyptian hieroglyphs, are all symbols and can describe things more succinctly, but has a really really steep learning curve.

Not that far, German has the word "Tschüß" which means "bye". An English-speaking person not actively reading German may imagine the sound of it as "Tshoob" while it actually is closer to "choose". The letter "ß", by intuition, is closer to "B" while it is actually an "ss".

I believe that the other half of the PL-notation-entry-barrier problem is which notations are required for which layer of programming language API. If learning is like going up a stair, it's not just about the angle of the stairs, but the height of each steps.

CSS for example (I would argue that CSS is a non-turing-complete declarative programming language), is rather good for this. You only need to use `.class` and `#` when you're styling something with class or ID. Only after that you will learn how to use `:pseudo-class` for a more complex behavior, after that @keyframe, etc.

I suppose that one advantage of notation is that it isn't language specific, but I don't know how much of an issue that actually is. If you're non English speaking and trying to read a paper written in English, you're going to need to be able to understand the word "cast" in the text, so it probably doesn't matter if you use the same word in the notation.

Is there any relation to an original meaning of cast in the english language to the technical term? I mean '(re)shape' or 'convert' would come more to mind.

There is no real barrier to entry, just like that anywhere the material ahead is massive and not for the faint of heart.

This post touches upon a subject that I really wish was more adopted: having alternate syntaxes for the sake of _clarity_. Syntax "bread" to the syntax sugar.

For example, regular expressions and date strings can be written in a nice and compact form, but how nice would it be write `Not(DigitalCharacter)` instead of `\D`? Or `TwoDigitYear` and `FourDigitYear` instead of `y` and `Y`. The same convenience exists in short and long command line flags; and optional named parameters in function calls.

I think this is what Perl tried (see: TMTOWTDI) What ends up happening is in order to maintain other people’s code it forces you to learn all the different syntaxes and becomes a burden.

> 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"


Slightly off topic: Why do we need to explicitly cast at all?

If the language is strongly typed the compiler should know whether the types are compatible and do it for you or refuse to compile.

I suppose my point is that casting was a poorly chosen example because the obvious solution isn't to have a better notation but to have no notation at all and follow Python's lead with duck typing or functional languages and strong type inference.

Requiring an explicit cast helps prevent type errors. It allows us to create types that mean something different than the original type. Consider a language with a “bytestring” type which is just any sequence of binary data and another “string” type which can only be valid utf8. The two types are compatible as far as the compiler is concerned. If the compiler could automatically cast between these types, we would find bugs from non-utf8 bytestrings passed into functions expecting utf8 strings.

One example is if you want to use the / symbol for integer and float division. Also do you want every multiplication done in a type where the data fits in? (C promotes types a bit too agressively here). So I believe for a low level language there should be more casting and less automatic type promotion.

C++ has implicit casts and everyone regrets it. Imagine something asinine like assigning a tcp socket object to a string variable and not seeing a compile error.

I think casting is an important part of documenting and encoding intent. Especially in embedded systems.

What if you’re reading in a DateTime from a string in a file?

I don't think notation is the barrier, but education. It can't really be standardized because notation is invented all the time, while we still haven't found a better way to teach the syntax of mathematics than a professor scribbling a formula on a chalkboard and student asking what a symbol means.

I agree that if you learn C-style syntax, moving to a more functional syntax (ala Lisp, Haskell) is jarring.

Moving between different C-style languages, once you know one, is not terribly hard however. It really is getting over that hump of learning one language from which you can then take that knowledge into another similar one.

I've picked PHP as my first language instead of Python when I was a kid, because in Python I saw things like `something[3:5]`. In PHP I could see `array_slice` and I knew what it would do without any prior programming experience.

Some time later I did learn Python and I really love it.

Anecdote, my first programming language was Ruby and it was super confusing without the braces. I then found JavaScript and then it clicked because of the braces (though now I have no problem doing Ruby and Python or Rust).

and I am not the only one saying this.

I actually had the reverse. Started in PHP and C# before I went into Ruby. And the Ruby notation just clicked a lot better for me.

I later went back to bracked notation and never really had a problem anymore. Having each bracket combination be coloured uniquely helps a lot too.

Ruby had a slogan like "programmer's best choice" or some kind, and you can imagine I was so discouraged that I was too dumb for Ruby lol.

That's mostly because Matz (the creator) made that one of Ruby's most important goals. A language made for people. How well the implementation of that goal resonates with you is very personal.

It worked wonders for me. I always felt that brackets were too messy. And I bet it didn't help that, at the time, I usually worked with other students that generally didn't uphold any style guide. So brackets weren't indented properly and not much time was spent in making the code readable.

So when I got my internship I was thrown into Ruby with a style guide to adhere to. Which definately made my introduction a lot smoother compared to what I was used to.

I still prefer the do-end notation for methods, though.

Notation is an easy to take barrier compare to what comes next. It's like learning an alphabet when you learn a foreign language - it takes negligible time (unless it hieroglyphic).

Sure, notation is a barrier to entry. I am not sure something should be done about it, though. After one week of experience in your first programming language it is no longer a barrier and perhaps the thing that has been introduced to avoid notation now is holding one back because of its verbosity....

If I may add a pet peeve of me, I would say that auto formatters and bad style guides are a barrier to entry. Some of the things out there seem to not have bothered to be actually adapted to the human visual system. Also, good formatting is a very difficult job to do automatically so the results are likely to be suboptimal. As a visually inclined person non-optimal formatting really disturbs me.

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.

>But at its worst, PL notation obfuscates: a page of symbols is an opaque barrier to entry.

The assumption here is that this is a bad thing. But there's a reason we have doors, gates, locks and so on -- other "barriers to entry".

> But there's a reason we have doors, gates, locks and so on -- other "barriers to entry"

Yes, because we don't want people to get into our house.

Are you seriously suggesting a world where we want to make it harder for people to understand programming language literature?

> Are you seriously suggesting a world where we want to make it harder for people to understand programming language literature?

I'd like the barrier for entry to be a bit higher if I'm honest. Maybe then I wouldn't have to work with code created by so many idiots.

My experience is that the people who hold this sort of view produce the worst output and are the least willing to improve it. Make of that what you will…

We're talking about literature related to programming language design not Stack Overflow here.

More people able to understand the literature means more people who can contribute and contribute effectively. That means better programming languages, better tooling and better educated people.

We have all been "idiots" at some point. Gatekeeping is how you kill a field by removing all the beginners who might one day produce the next big development.

The solution to that isn't to make programming harder, but to make writing poor quality code harder. That's also in part, indirectly, a notation problem.

I don't think making the barrier higher is gonna solve your "issue". I think you'll only achieve having less developers overal.

I've worked with some brilliant booksmart people that produced god aweful code. Being able to understand literature/notation isn't going to make you a better developer by default. There's a lot more that goes into it than that.

This opinion is often followed by laments that their favorite language has only a tiny niche audience and no major accomplishments outside of some academic examples, while some clearly inferior language with a low barrier to entry is inexplicably way more popular than their preferred language.

Or ideas in general, should we ever gate keep the dissemination of ideas and knowledge? Innovation is more likely to occur when people cross disciplines and they can only do that if it is approachable, it is gradual and discoverable. Simple is hard, simplistic is easy. Someone is going to come back with essential vs accidental complexity [1] but we can always strive for simpler, more cohesive ways to exchange knowledge. How much of our current notation systems are essential? And when do they diverge for non-essential reasons? Computer systems form primarily around notation (language and syntax), so notation is definitely important [z]

In the post the author mentions an excellent talk by Guy Steele that goes over issue of notation and balkanization titled, "It's Time for a New Old Language" where he outlines "the history and current status of computer science metanotation". [2]

Notation, like syntax is important, but like a plethora of ill defined and specified Domain Specific Languages (DSL), notation also needs to be defined, regular and learnable. For notation takes words and turns them into pictures that compose into thought structures that cannot be expressed in human written language to the same specificity. Think Feynman [3] and Railroad [4] Diagrams, or musical notation [5]

The abstract explains it beautifully,

> The most popular programming language in computer science has no compiler or interpreter. Its definition is not written down in any one place. It has changed a lot over the decades, and those changes have introduced ambiguities and inconsistencies. Today, dozens of variations are in use, and its complexity has reached the point where it needs to be re-explained, at least in part, every time it is used. Much effort has been spent in hand-translating between this language and other languages that do have compilers. The language is quite amenable to parallel computation, but this fact has gone unexploited.

[1] https://simplicable.com/new/accidental-complexity-vs-essenti...

[2] https://www.youtube.com/watch?v=7HKbjYqqPPQ

slides, https://groups.csail.mit.edu/mac/users/gjs/6.945/readings/St...

paper, https://sci-hub.st/10.1145/3155284.3018773

[3] 6 minute video from Fermilab on Feynman Diagrams https://www.youtube.com/watch?v=hk1cOffTgdk

[4] https://sqlite.org/syntaxdiagrams.html

[5] https://www.mfiles.co.uk/music-notation-history.htm

[z] Wadler's Law

Besides being beginner unfriendly, barriers to entry end up making things worse off for everyone by reducing productivity and efficiency.

There's no reason to consider barriers a good thing, unless one has a motive to restrict use of programming languages. Why would one want that?

Counterexample: lisp

> Adopting standard notations across the field could offer huge benefits

They skipped the related xkcd.


1968 on adopting standard notation: https://assets.octodon.social/media_attachments/files/002/76...

(judging by the picture of Susie at her desk, development environments' handwriting recognition was awesome in 1968, which explains Landin's 1966 comment in Next 700:

https://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf p. 160

> "[The offside rule] is based on vertical alignment, not character width, and hence is equally appropriate in handwritten, typeset or typed texts.")

Ironically the only thing that is ever standard about standards is that the same XKCD comic will always be brought up

wow, you got downvoted pretty hard & fast. tried to help coutneract because while that joke is played out - there's a reason that joke is played out.

Yes, because people post it robotically whenever the words "standard" or "new" come up.

When I teach, I find tooling, first, and conceptual issues, second, to be much higher barriers to entry for programming.

Syntax is where the rubber meets the road, but this is like blaming the stick and puck for making hockey hard.

Lowering barriers of entry to programming considered harmful to career programmers. If you support it without being manager level or above, you are harming yourself.

More genuine concern is lowering bar to entry below a certain level leads to decline of quality.

Just like how there is a class of programmers who don't understand simple CS concepts like algorithm complexity and memory allocation and write horribly inefficient code.

That assumes that more programmers doesn’t mean more programmers. I suspect the inverse, the more programmers we have, the more systems they create to program, and the more programmers we need.

Further, the notation is a "tip of the iceberg" issue; the iceberg is semantics, and I suspect anyone who can grasp the semantics well enough to actually build something, can handle the notation (even if there's a notation they could handle better).

Which possibly means - the more notation-capable-but-semantics-challenged people are working in the field, the more work for the semantics-capapble people to clean after them.

People able to program reasonably well, are not hindered by learning the syntax. Lowering the barrier is only going to bring in more people who are fundamentally unable to think algorithmically. If you are a manager you do not want those people to work for you, and if you are a programmer those people make you look better.

Of all the people I have tutored thus far, if they struggled with a language like Java or C#, trying to program with Scratch was just as hard for them. Taking syntax completely away and making it visual did not make a difference.

That's a very simplistic view. Programmers who work on SDKs and developer tools benefit tremendously from lower barriers to entry to programming.

We were lucky to get into programming at a time when barriers to entry were low. How could we justify putting up obstacles for those that come after us?

I disagree. Java/C# are basically English. It’s not going to get much easier than that.

I’d understand this argument about a language like J, but we can’t dumb J down just so everyone can use it without putting in some effort, or it wouldn’t be J.

The most powerful tools will always have the highest learning curve.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact