Programming language notation is a barrier to entry • Hacker News Board

Re: Programming language notation is a barrier to entry

#101

Post by jandrese » Thu, Oct 01, 2020, 5:41 PM UTC

ardfard wrote: post #64

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

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.

Re: Programming language notation is a barrier to entry

#102

Post by jandrese » Thu, Oct 01, 2020, 5:43 PM UTC

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.

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.

Re: Programming language notation is a barrier to entry

#103

Post by nickjj » Thu, Oct 01, 2020, 5:45 PM UTC

the_af wrote: post #97

ForHackernews wrote: post #94

Earlier quoted context omitted.

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.

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

> For beginners, almost anything will be hurdle till the get the hang of it. Afterwards, they'll be practitioners. Being a beginner is a temporary situation; practitioners are forever.

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

For example with Elixir, in a lot of cases you end up calling certain standard library functions like foo(hello: :world) while others are foo(: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?

Re: Programming language notation is a barrier to entry

#104

Post by andi999 » Thu, Oct 01, 2020, 5:47 PM UTC

kwhitefoot wrote: post #37

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…

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.

Re: Programming language notation is a barrier to entry

#105

Post by andi999 » Thu, Oct 01, 2020, 5:50 PM UTC

rkangel wrote: post #8

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.

Re: Programming language notation is a barrier to entry

#106

Post by qppo » Thu, Oct 01, 2020, 5:52 PM UTC

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.

Re: Programming language notation is a barrier to entry

#107

Post by andrewzah » Thu, Oct 01, 2020, 5:52 PM UTC

matthewmacleod wrote: post #45

beagle3 wrote: post #26

Earlier quoted context omitted.

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

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.

Re: Programming language notation is a barrier to entry

#108

Post by AnimalMuppet » Thu, Oct 01, 2020, 5:54 PM UTC

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…

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.

Re: Programming language notation is a barrier to entry

#109

Post by BurningFrog » Thu, Oct 01, 2020, 6:00 PM UTC

TeMPOraL wrote: post #11

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.

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.

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

Re: Programming language notation is a barrier to entry

#110

Post by czynskee » Thu, Oct 01, 2020, 6:03 PM UTC

nickjj wrote: post #103

the_af wrote: post #97

Earlier quoted context omitted.

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

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

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.