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

151–160 of 191 posts

Re: Programming language notation is a barrier to entry

#151

Post by whateveracct »

yencabulator wrote: post #85
ardfard wrote: post #64

Earlier quoted context omitted.

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…

Monads, Transformers etc can make Haskell code hard to follow. But the culture of overusing unpronounceable/unmemorable operators is what makes Haskell really hard to read . >@> --> ||| .|. None of the above are made up, all are from real code.

Of code is using , , And , it's probably easier to read & understand at a glance than the the best, most read-optimized Go equivalent.

If you know what those symbols mean (aka the interfaces they belong to.)

If you don't have that knowledge and are instead complaining about the fact that they have symbols period, I suggest you quit spouting answers when you should be asking questions.

Re: Programming language notation is a barrier to entry

#152

Post by tsumnia »

ywei3410 wrote: post #146
tsumnia wrote: post #84

Earlier quoted context omitted.

The issue is that no one in CS seems to care that "Notation in any field is a barrier to entry". Almost all CS Ed research presently focuses on the problem-solving skill of CS rather than the technical literacy. There is almost no interest from educators to train this literacy despite work from myself [1] and others [2] saying that explicitly training these skills improves student performance. The issue, in my opinio…

That's really interesting - I enjoyed the section on transfer learning. Are there any screenshots of Phanon without having to sign-up to the Utah website? Do you think that reducing the amount of syntax-errors via a powerful structured-editor would help reduce the syntax burden?

Its not a screenshot, but the Utah team posted this video for ICER [1] (with timestamp). I'm not apart of their team, so that's the best I can offer.

> Do you think that reducing the amount of syntax-errors via a powerful structured-editor would help reduce the syntax burden?

Truthfully, no. It would resolve syntax errors for sure, but I think there's something inherit to actually interacting and fixing mistakes that can't be replicated with technology. If you think about learning a second language, having an automatic translator will help you speak to other people, but you would not actually know the language. Not attempting to invoke Turing's Chinese Room, but rather there is a educational need to make mistakes, identify them, and resolve them that helps.

[1] https://youtu.be/AdYMJ923Lys?t=90

Re: Programming language notation is a barrier to entry

#153

Post by tsumnia »

jimbob45 wrote: post #88
tsumnia wrote: post #84

Earlier quoted context omitted.

The issue is that no one in CS seems to care that "Notation in any field is a barrier to entry". Almost all CS Ed research presently focuses on the problem-solving skill of CS rather than the technical literacy. There is almost no interest from educators to train this literacy despite work from myself [1] and others [2] saying that explicitly training these skills improves student performance. The issue, in my opinio…

No one seems to care? What is Python if not a referendum on unclear keywords and whitespacing?

Sorry, I mean to say in the CS Education domain.

Re: Programming language notation is a barrier to entry

#154

Post by dodobirdlord »

the_af wrote: post #121
mcguire wrote: post #119

Earlier quoted context omitted.

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.

There’s a small group of people (financial analysts, mostly) who use APL derived languages, are hugely productive and make tons of money, and have no interest in changing the language they use. Not every tool is for every purpose and not every language should try to appeal to all users.

Re: Programming language notation is a barrier to entry

#155

Post by google234123 »

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…

Allowing both seems like the worst solution. Inconsistency is annoying for both beginners and professionals.

Re: Programming language notation is a barrier to entry

#156

Post by the_af »

the_af wrote: post #122
nickjj wrote: post #103

Earlier quoted context omitted.

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

Addendum: I completely misread the comment I was replying to. My comment "they seem like a good thing to me" makes no sense. Please disregard. Unfortunately, I cannot delete it now.

I actually agree with the comment which states "But that's not really a beginner-specific problem. Even practitioners will likely find it to be a nuisance."

Re: Programming language notation is a barrier to entry

#157

Post by Riverheart »

lisper wrote: post #140
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…

A long time ago I settled on FST and RST as the Right Names for the two halves of a cons cell. The argument is: 1. It's vaguely mnemonic of FirST and ReST, but compactified enough that it's still parseable as abstract names with no particular semantics 2. It's composable the same way that CAR and CDR are, e.g. FFRST == CAADR. Another good pair of names is LHS and RHS for Left Hand Side and Right Hand Side. Same argum…

How do you define these so you can use them like CAADR?

Re: Programming language notation is a barrier to entry

#158

Post by int_19h »

beagle3 wrote: post #63
marcosdumay wrote: post #52

Earlier quoted context omitted.

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…

GOSUB/RETURN may be easier to explain, but of course it also doesn't cover many things that functions with local scope do.

Explaining functions and recursion is tricky in general, but necessary for other things to make sense. There are ways to do so that might be more intuitive for a newbie to grasp. For Python specifically, take a look at https://thonny.org - it's particularly well suited to forming a mental model of a running program, including function calls, in a very visual way.

Re: Programming language notation is a barrier to entry

#159

Post by Wezl »

dodobirdlord wrote: post #154
the_af wrote: post #121

Earlier quoted context omitted.

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.

There’s a small group of people (financial analysts, mostly) who use APL derived languages, are hugely productive and make tons of money, and have no interest in changing the language they use. Not every tool is for every purpose and not every language should try to appeal to all users.

Although many of the APL derived languages changed their syntax by removing the fancy symbols. I'm not disagreeing, though: some people like them, some don't, and that's why people use j, k, and APL.

Re: Programming language notation is a barrier to entry

#160

Post by webmaven »

lilott8 wrote: post #132
DonaldPShimoda wrote: post #92

Earlier quoted context omitted.

The problem at hand is not the notation of actual implemented languages, but rather the notation of programming language theory. In other words, when you read a paper published at a PL conference (POPL, PLDI, ICFP, SPLASH, etc.), the notation you are likely to encounter therein. There's like 50 years of notational history, and it can be wildly inconsistent. Some things are somewhat standardized, but there's no centra…

This fact almost killed my Ph.D. I wrote a programming language and type system for biologists and chemists. But the PL theory syntax nearly did me in. TAPL was like banging my head against a brick wall -- completely opaque to me. My PI wasn't familiar with the space either, so I was sort of on my own. The school eventually brought in a PL theory faculty and things sort of got better. But yes, the syntax for PL is ce…

Sounds interesting! Link please?
Post reply on HN