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

181–190 of 191 posts

Re: Programming language notation is a barrier to entry

#181

Post by siraben »

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.

Some of these are explanable from mathematical conventions. In abstract algebra it's common to surround an operator in a circle to denote a "generic" or "lifted" operator. So denotes a "lifted application", i.e.

  ($)   ::              (a → b) → a   → b
  () :: Functor f => (a → b) → f a → f b

Re: Programming language notation is a barrier to entry

#182

Post by siraben »

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…

Alternatively, instead of car and cdr one could have pattern matching, which is more declarative and less error-prone than c(a|d)+r.

Re: Programming language notation is a barrier to entry

#183

Post by tsumnia »

_p1nd wrote: post #179
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…

Wow, this really hits on something that's been rattling around my brain for years and has come to the forefront in the last week. In most disciplines to achieve mastery you generally focus on technical mastery first; drills, copying the works of the greats, stuff like that, before moving on to find your own "style" and making new creative works. I think a lot of the wisdom of the past about how to excel espoused the…

Sure! My research bio is at [1]. And I definitely agree there's a disconnect between how younger individuals learn CS and college-level CS. Often those younger individuals could be seen as "automatic A's" because they've already overcame that first syntax hurdle.

My current research is on exploring different exercise "types" with the hope of building a practice recommendation system that can identify which complexity a student should practice next - a typing or coding exercise, or something in between (Parson's Puzzles or Output Prediction, etc.)

[1] https://research.csc.ncsu.edu/arglab/people/agaweda.html

Re: Programming language notation is a barrier to entry

#184

Post by beagle3 »

int_19h wrote: post #158
beagle3 wrote: post #63

Earlier quoted context omitted.

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

Oh, of course. GOSUB/RETURN are easier to explain, but only as a stepping stone towards functions; I like them because unlike functions+locals, which are much more "all or nothing" - whereas when I taught basic, I would start with "GOTO" which is trivial for everyone to understand; then go to GOSUB+RETURN, which is just a tiny bit harder, but still very capable - my complex gosub+return example was flood fill[0]:

    9000 REM F=FOREGROUND COLOR, X AND Y ARE COORDINATES
    9010 IF POINT(X,Y)=F THEN RETURN
    9020 PLOT(X,Y,F)
    9030 X=X+1 : GOSUB 9000 : X=X-2 : GOSUB 9000 : X=X+1
    9040 Y=Y+1 : GOSUB 9000 : Y=Y-2 : GOSUB 9000 : Y=Y+1
    9050 RETURN
Which does recursion, visually, with only gosub/return, lets me touch on stack overflows (trying to fill too big an image would on most interpreters).

I have never had the chance to teach BBC Basic, but if I did, even though it has PROCs and LOCALs, I would still go the GOTO -> GOSUB/RETURN route, and only then proceed to DEFPROC / LOCAL.

[0] This would also be introduction to multiple statements - I would show this with one statement per line and multiple statements per line and discuss pros/cons

Re: Programming language notation is a barrier to entry

#185

Post by tomc1985 »

sidlls wrote: post #177
tomc1985 wrote: post #163

Earlier quoted context omitted.

Such is the way of the world. The same will eventually happen with what is in vogue today, and detractors will appear seemingly out of nowhere to talk shit The idea that today's languages and technologies are truly better than the past is laughable, particularly when they recycle so much of what is old and slap on a new name

The idea that today's languages and technologies are truly better than the past is laughable, That's really orthogonal to the discussion, though. This isn't about general superiority, it's about legibility and barriers to understanding/skill due to syntax and keywords. Perl is infamous for the "code golf is the default style" syntax, keywords, and tokens it employs in this context, and in my experience at least its m…

> and in my experience at least its most ardent fans believe it is a badge of honor.

Indeed. And I disagree with your opinion. For all its terseness its still wonderfully expressive and it goes against the horrible trend set by Python with its "one true way" bullshit. That we all so willingly accept the commodification of our trade so the paymasters can eventually decrease our demand is shameful.

We should strive for a certain level of difficulty if anything to separate the wheat from the chaff. You wanna play with the big boys? Learn to code in a big boy language.

Instead we let the trainwreck that is modern JS take over.

Re: Programming language notation is a barrier to entry

#186

Post by imtringued »

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.

What about beginners who stay beginners?

Re: Programming language notation is a barrier to entry

#187

Post by imtringued »

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…

C++ has implicit casts and everyone regrets it. Imagine something asinine like assigning a tcp socket object to a string variable and not seeing a compile error.

Re: Programming language notation is a barrier to entry

#188

Post by ClikeX »

christiansakai wrote: post #71
ClikeX wrote: post #53

Earlier quoted context omitted.

I actually had the reverse. Started in PHP and C# before I went into Ruby. And the Ruby notation just clicked a lot better for me. I later went back to bracked notation and never really had a problem anymore. Having each bracket combination be coloured uniquely helps a lot too.

Ruby had a slogan like "programmer's best choice" or some kind, and you can imagine I was so discouraged that I was too dumb for Ruby lol.

That's mostly because Matz (the creator) made that one of Ruby's most important goals. A language made for people. How well the implementation of that goal resonates with you is very personal.

It worked wonders for me. I always felt that brackets were too messy. And I bet it didn't help that, at the time, I usually worked with other students that generally didn't uphold any style guide. So brackets weren't indented properly and not much time was spent in making the code readable.

So when I got my internship I was thrown into Ruby with a style guide to adhere to. Which definately made my introduction a lot smoother compared to what I was used to.

I still prefer the do-end notation for methods, though.

Re: Programming language notation is a barrier to entry

#189

Post by the_af »

hacknat wrote: post #142

A lot comments are misunderstanding this article. This person is not complaining about differences in programming syntax across languages at all. He is making a very specific complaint about how PL Notation (i.e metasyntax not syntax) in academic literature isn't standardized. This has nothing to do with the vagaries of Perl vs Lisp and everything to do with how PL white papers are written.

Guilty as charged! I did read the article but misunderstood it. In my (admittedly weak) defense, the conversation that ensued in the thread started by my comment was interesting. But you're right: it was also off-topic!

Re: Programming language notation is a barrier to entry

#190

Post by sidlls »

tomc1985 wrote: post #185
sidlls wrote: post #177

Earlier quoted context omitted.

The idea that today's languages and technologies are truly better than the past is laughable, That's really orthogonal to the discussion, though. This isn't about general superiority, it's about legibility and barriers to understanding/skill due to syntax and keywords. Perl is infamous for the "code golf is the default style" syntax, keywords, and tokens it employs in this context, and in my experience at least its m…

> and in my experience at least its most ardent fans believe it is a badge of honor. Indeed. And I disagree with your opinion. For all its terseness its still wonderfully expressive and it goes against the horrible trend set by Python with its "one true way" bullshit. That we all so willingly accept the commodification of our trade so the paymasters can eventually decrease our demand is shameful. We should strive for…

Who is "we"? And take over what? Backend web development? Hardly--that's still mostly PHP. The most sophisticated pieces of the most sophisticated internet application ("web") software are generally written in Java, C++, or Go (some Erlang, some others, etc., but mostly those). "Big boys"? What does that even mean?
Post reply on HN