26 ms·

Programming language notation is a barrier to entry

115 points by seg_lol 6y ago

JeremyBarbosa 6y ago
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.
rkangel 6y ago
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.
- andi999 6y ago
  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.
coldtea 6y ago
>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".
- rkangel 6y ago
  > 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?
  - LandR 6y ago
    > 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.
    - matthewmacleod 6y ago
      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…
    - rkangel 6y ago
      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.
    - creatornator 6y ago
      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.
    - ClikeX 6y ago
      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.
    - jandrese 6y ago
      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.
- andrewjl 6y ago
  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?
swiley 6y ago
Meh Notation in any field is a barrier to entry. See programmers takes on both math and music notation that are often posted here. The thing about notation that people sometimes don't think about is that it's used by many different types of people. Some things that would be convenient when notated implicitly make thinking about other things difficult.
- Waterluvian 6y ago
  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.
  - FartyMcFarter 6y ago
    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.
    - Waterluvian 6y ago
      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.
  - beagle3 6y ago
    > 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.
DJBunnies 6y ago
> Adopting standard notations across the field could offer huge benefits They skipped the related xkcd. https://xkcd.com/927/ https://xkcd.com/927/
- christrotman 6y ago
  Ironically the only thing that is ever standard about standards is that the same XKCD comic will always be brought up
- irjustin 6y ago
  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.
  - Semiapies 6y ago
    Yes, because people post it robotically whenever the words "standard" or "new" come up.
- 082349872349872 6y ago
  1968 on adopting standard notation: https://assets.octodon.social/media_attachments/files/002/765/597/original/4d101197e020f780.png 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 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.")
tgb 6y ago
Ironic that this uses "PL notation" in its title - an ungoogleable acronym (luckily Hacker News has clarified this as meaning programming language notation).
- DonaldPShimoda 6y ago
  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.
- seg_lol 6y ago
  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.
cammil 6y ago
Is this saying that a new language is the barrier to learning a new language?
- baobabKoodaa 6y ago
  If you compare C to Java, you will find differences beyond merely notation.
- yellowstuff 6y ago
  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.
  - cammil 6y ago
    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.
    - karmakaze 6y ago
      Not to detract from the main point. A program is also distinct from what it produces unless it's a quine.
    - yellowstuff 6y ago
      > 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.
hehetrthrthrjn 6y ago
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.
- UncleEntity 6y ago
  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.
barrenko 6y ago
There is no real barrier to entry, just like that anywhere the material ahead is massive and not for the faint of heart.
Traubenfuchs 6y ago
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.
- crispyporkbites 6y ago
  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.
  - beagle3 6y ago
    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.
  - siltpotato 6y ago
    But eventually this reaches an equilibrium, or else we'd all be programmers. There is no law stating that more programmers always means more programmers.
- higerordermap 6y ago
  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.
- jefftk 6y ago
  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?
- 6y ago
x86_64Ubuntu 6y ago
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.
- taneq 6y ago
  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.
  - Macha 6y ago
    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
- deleted 6y ago
  [deleted]
- ardfard 6y ago
  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.
higerordermap 6y ago
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.
henrikeh 6y ago
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.
- booleandilemma 6y ago
  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.
halfmatthalfcat 6y ago
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.
booleandilemma 6y ago
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.
kwhitefoot 6y ago
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.
- booleandilemma 6y ago
  What if you’re reading in a DateTime from a string in a file?
- throwaway894345 6y ago
  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.
- henrikeh 6y ago
  I think casting is an important part of documenting and encoding intent. Especially in embedded systems.
- andi999 6y ago
  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.
- imtringued 6y ago
  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.
christiansakai 6y ago
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.
- ClikeX 6y ago
  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.
  - christiansakai 6y ago
    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.
    - ClikeX 6y ago
      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.
beagle3 6y ago
Uniform, well defined programming language notation has been proposed in 1958 by Kenneth Iversion: https://en.wikipedia.org/wiki/APL_(programming_language) 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.
citrin_ru 6y ago
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).
daniel-s 6y ago
Counterexample: lisp
cjfd 6y ago
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.
EamonnMR 6y ago
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 https://en.m.wikipedia.org/wiki/Backus%E2%80%93Naur_form
ImprobableTruth 6y ago
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.
valand 6y ago
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.
siraben 6y ago
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 https://youtu.be/GhERMBT7u4w?t=4395 [1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.8026&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.... (typo fixed) [2] http://okmij.org/ftp/tagless-final/ski.pdf http://okmij.org/ftp/tagless-final/ski.pdf [3] https://github.com/siraben/r5rs-denot https://github.com/siraben/r5rs-denot
recursivedoubts 6y ago
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.
the_af 6y ago
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 https://news.ycombinator.com/item?id=21256727
- ForHackernews 6y ago
  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.
  - the_af 6y ago
    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.
    - AnimalMuppet 6y ago
      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.
    - striking 6y ago
      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.
qppo 6y ago
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.
slykar 6y ago
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.
User23 6y ago
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/EWD1300.html https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/E...
hacknat 6y ago
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.
- the_af 6y ago
  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!
tromp 6y ago
> 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-number/ https://mindsarentmagic.org/2020/02/19/a-picture-of-grahams-...
wtetzner 6y ago
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.
bpyne 6y ago
Ironically, I ran into this talk by Guy Steele today. He presents the development of the Computer Science Metalanguage. https://youtu.be/dCuZkaaou0Q https://youtu.be/dCuZkaaou0Q
dan-robertson 6y ago
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).
- siraben 6y ago
  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.

115 points by seg_lol 6y ago

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.

rkangel 6y ago

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.

andi999 6y ago
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.

coldtea 6y ago

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

rkangel 6y ago
> 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?
- LandR 6y ago
  > 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.
  - matthewmacleod 6y ago
    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…
  - rkangel 6y ago
    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.
  - creatornator 6y ago
    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.
  - ClikeX 6y ago
    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.
  - jandrese 6y ago
    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.
andrewjl 6y ago
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?

swiley 6y ago

Meh Notation in any field is a barrier to entry. See programmers takes on both math and music notation that are often posted here. The thing about notation that people sometimes don't think about is that it's used by many different types of people. Some things that would be convenient when notated implicitly make thinking about other things difficult.

Waterluvian 6y ago
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.
- FartyMcFarter 6y ago
  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.
  - Waterluvian 6y ago
    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.
- beagle3 6y ago
  > 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.

DJBunnies 6y ago

> Adopting standard notations across the field could offer huge benefits They skipped the related xkcd. https://xkcd.com/927/ https://xkcd.com/927/

christrotman 6y ago
Ironically the only thing that is ever standard about standards is that the same XKCD comic will always be brought up
irjustin 6y ago
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.
- Semiapies 6y ago
  Yes, because people post it robotically whenever the words "standard" or "new" come up.
082349872349872 6y ago
1968 on adopting standard notation: https://assets.octodon.social/media_attachments/files/002/765/597/original/4d101197e020f780.png 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 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.")

tgb 6y ago

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

DonaldPShimoda 6y ago
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.
seg_lol 6y ago
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.

cammil 6y ago

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

baobabKoodaa 6y ago
If you compare C to Java, you will find differences beyond merely notation.
yellowstuff 6y ago
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.
- cammil 6y ago
  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.
  - karmakaze 6y ago
    Not to detract from the main point. A program is also distinct from what it produces unless it's a quine.
  - yellowstuff 6y ago
    > 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.

hehetrthrthrjn 6y ago

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.

UncleEntity 6y ago
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.

barrenko 6y ago

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

Traubenfuchs 6y ago

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.

crispyporkbites 6y ago
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.
- beagle3 6y ago
  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.
- siltpotato 6y ago
  But eventually this reaches an equilibrium, or else we'd all be programmers. There is no law stating that more programmers always means more programmers.
higerordermap 6y ago
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.
jefftk 6y ago
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?
6y ago

x86_64Ubuntu 6y ago

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.

taneq 6y ago
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.
- Macha 6y ago
  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
deleted 6y ago
[deleted]
ardfard 6y ago
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.

higerordermap 6y ago

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.

henrikeh 6y ago

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.

booleandilemma 6y ago
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.

halfmatthalfcat 6y ago

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.

booleandilemma 6y ago

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.

kwhitefoot 6y ago

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.

booleandilemma 6y ago
What if you’re reading in a DateTime from a string in a file?
throwaway894345 6y ago
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.
henrikeh 6y ago
I think casting is an important part of documenting and encoding intent. Especially in embedded systems.
andi999 6y ago
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.
imtringued 6y ago
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.

christiansakai 6y ago

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.

ClikeX 6y ago
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.
- christiansakai 6y ago
  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.
  - ClikeX 6y ago
    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.

beagle3 6y ago

Uniform, well defined programming language notation has been proposed in 1958 by Kenneth Iversion: https://en.wikipedia.org/wiki/APL_(programming_language) 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.

citrin_ru 6y ago

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

daniel-s 6y ago

Counterexample: lisp

cjfd 6y ago

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.

EamonnMR 6y ago

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 https://en.m.wikipedia.org/wiki/Backus%E2%80%93Naur_form

ImprobableTruth 6y ago

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.

valand 6y ago

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.

siraben 6y ago

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 https://youtu.be/GhERMBT7u4w?t=4395 [1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.8026&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.... (typo fixed) [2] http://okmij.org/ftp/tagless-final/ski.pdf http://okmij.org/ftp/tagless-final/ski.pdf [3] https://github.com/siraben/r5rs-denot https://github.com/siraben/r5rs-denot

recursivedoubts 6y ago

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.

the_af 6y ago

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 https://news.ycombinator.com/item?id=21256727

ForHackernews 6y ago
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.
- the_af 6y ago
  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.
  - AnimalMuppet 6y ago
    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.
  - striking 6y ago
    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.

qppo 6y ago

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.

slykar 6y ago

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.

User23 6y ago

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/EWD1300.html https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/E...

hacknat 6y ago

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.

the_af 6y ago
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!

tromp 6y ago

> 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-number/ https://mindsarentmagic.org/2020/02/19/a-picture-of-grahams-...

wtetzner 6y ago

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.

bpyne 6y ago

Ironically, I ran into this talk by Guy Steele today. He presents the development of the Computer Science Metalanguage. https://youtu.be/dCuZkaaou0Q https://youtu.be/dCuZkaaou0Q

dan-robertson 6y ago

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

siraben 6y ago
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.