Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programming language notation is a barrier to entry

blog.sigplan.org

Post reply on HN
Print view View original

61–70 of 191 posts

Re: Programming language notation is a barrier to entry

#61

Post by ImprobableTruth »

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.

Re: Programming language notation is a barrier to entry

#62

Post by valand »

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.

Re: Programming language notation is a barrier to entry

#63

Post by beagle3 »

marcosdumay wrote: post #52
ht_th wrote: post #15

Earlier quoted context omitted.

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

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.

Re: Programming language notation is a barrier to entry

#64

Post by ardfard »

x86_64Ubuntu wrote: post #28

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.

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.

Re: Programming language notation is a barrier to entry

#65

Post by ClikeX »

LandR wrote: post #20
rkangel wrote: post #6

Earlier quoted context omitted.

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

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.

Re: Programming language notation is a barrier to entry

#66

Post by siraben »

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=10.1.1.41.... (typo fixed)

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

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

Re: Programming language notation is a barrier to entry

#67

Post by beagle3 »

seg_lol wrote: post #59
TeMPOraL wrote: post #11

Earlier quoted context omitted.

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.

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

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

Re: Programming language notation is a barrier to entry

#68

Post by beagle3 »

screye wrote: post #44
swiley wrote: post #2

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

Music notation is actually terrible, even musicians agree to that. It clearly developed as a way to reason about music that already existed in the west at that point, rather than be a principled way to go about understanding the underpinnings of music.

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)

Re: Programming language notation is a barrier to entry

#69

Post by beagle3 »

MontyCarloHall wrote: post #41
swiley wrote: post #2

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

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:

    ,//

    |/0(0|+)\
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".

Re: Programming language notation is a barrier to entry

#70

Post by Izkata »

beagle3 wrote: post #26
Waterluvian wrote: post #10

Earlier quoted context omitted.

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

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.

Post reply on HN