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

121–130 of 191 posts

Re: Programming language notation is a barrier to entry

#121

Post by the_af »

mcguire wrote: post #119
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.

This explains the success of APL.

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

Re: Programming language notation is a barrier to entry

#122

Post by the_af »

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…

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

They seem like a good thing to me!

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

Re: Programming language notation is a barrier to entry

#123

Post by the_af »

sidlls wrote: post #113
tzs wrote: post #100

Earlier quoted context omitted.

> Look at Perl for an example of what happened to a language with syntax that appealed only to people who were already Perl-practitioners It became for several years one of the most successful and widely used scripting languages on Unix?

Until languages with a different view completely left it in the dust.

There are multiple reasons why that may have happened.

Re: Programming language notation is a barrier to entry

#124

Post by notmyname9173 »

the_af wrote: post #89

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…

6 months in, Agda is just as cryptic as it was on day 1.

Re: Programming language notation is a barrier to entry

#125

Post by st1x7 »

nur0n wrote: post #118
the_af wrote: post #89

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…

There was a huge discussion shortly after Julia 1.0 was released regarding scoping [1]. Beginners intuitively think of scoping in a manner different from the way scoping should work in production projects. There was a lot of tension between seasoned programmers and educators (who had to constantly interact with beginners). The community exhausted the entire design space (along with some full-blown prototypes). Eventu…

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

Re: Programming language notation is a barrier to entry

#126

Post by User23 »

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

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

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

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

Re: Programming language notation is a barrier to entry

#127

Post by rapind »

the_af wrote: post #89

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…

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

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

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

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

Re: Programming language notation is a barrier to entry

#128

Post by jodrellblank »

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

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

Re: Programming language notation is a barrier to entry

#129

Post by striking »

the_af wrote: post #120
striking wrote: post #99

Earlier quoted context omitted.

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

It goes implied in pg's remark, and my own opinion, that the notation must be good for practitioners. It's of course possible for notation to be plain bad for everyone. The argument actually says "don't optimize notation for beginners, optimize for practitioners". It doesn't imply making things difficult for beginners on purpose; just that they are not the priority.

I understand that, I read the remark. But you were replying to a comment about Perl, and I want to make it clear that there are plenty of people and languages that make excuses in favor of practitioners when it's convenient and that they shouldn't.

I just don't even think it's a useful remark because you can just claim people you disagree with are beginners and people you agree with are practitioners and now anything can be argued.

Re: Programming language notation is a barrier to entry

#130

Post by fortran77 »

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.

Maybe it is, maybe it isn't. But it's not keeping people from being musicans.

Im 57, and have been playing the piano for 50 years. (I still practice 2 hours/day).

The problem with piano isn't reading the music, it's getting your hands in the right place, at the right time, with the least amount of effort, to be able to control the keys the way you want to.

Most of my practicing is getting from one place to another on the keyboard. I'm practicing the space "between" the notes (or positions on the keyboard; I start off by 'grouping' things).

That's why I'm amused when I see "learn keyboard" systems that somehow make you believe the problem is simply seeing a C# two octaves above middle C on the staff and figuring out where it is on the keyboard. You can learn all that in a week. The rest takes years.

Post reply on HN