Live data from Hacker News

Programming language notation is a barrier to entry

blog.sigplan.org

41–50 of 191 posts

Re: Programming language notation is a barrier to entry

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

Re: Programming language notation is a barrier to entry

#42
post #20
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.

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.

Re: Programming language notation is a barrier to entry

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

Re: Programming language notation is a barrier to entry

#44
post #2

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

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

It clearly developed as a way to reason about music that already existed in the west at that point, rather than be a principled way to go about understanding the underpinnings of music.

Re: Programming language notation is a barrier to entry

#45
post #26

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…

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.

Re: Programming language notation is a barrier to entry

#46

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.

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.

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.

Re: Programming language notation is a barrier to entry

#47
post #14

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.

Re: Programming language notation is a barrier to entry

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

Re: Programming language notation is a barrier to entry

#49

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

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.
Post reply on HN