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

Re: Programming language notation is a barrier to entry

#161

Post by lisper » Thu, Oct 01, 2020, 11:22 PM UTC

Riverheart wrote: post #157

lisper wrote: post #140

Earlier quoted context omitted.

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?

(defun ffrst (l) (caadr l))

Lather, rinse, repeat.

For extra credit, write a macro that will save you having to type every possible combination out manually.

Re: Programming language notation is a barrier to entry

#162

Post by emidln » Thu, Oct 01, 2020, 11:26 PM UTC

lisper wrote: post #161

Riverheart wrote: post #157

Earlier quoted context omitted.

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

(defun ffrst (l) (caadr l)) Lather, rinse, repeat. For extra credit, write a macro that will save you having to type every possible combination out manually.

I did this once for Clojure and named it car-cdr-construction-set! with an argument for how many levels deep to define in the current namespace.

Re: Programming language notation is a barrier to entry

#163

Post by tomc1985 » Thu, Oct 01, 2020, 11:41 PM UTC

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.

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

Re: Programming language notation is a barrier to entry

#164

Post by agumonkey » Fri, Oct 02, 2020, 12:08 AM UTC

Riverheart wrote: post #157

lisper wrote: post #140

Earlier quoted context omitted.

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?

Some people in university hinted that some lisps had special parsing stages for car/cdr based functionals. They may turn c(.)*r into nested (car (cdr ( ... ) ) ) calls.

Re: Programming language notation is a barrier to entry

#165

Post by agumonkey » Fri, Oct 02, 2020, 12:09 AM 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.

I'd even go further, notation should never .. well that's too radical, rarely be a topic of discussion.

Concepts are way more important. Spending time on syntax is like having a course in tar --flags.

Re: Programming language notation is a barrier to entry

#166

Post by yellowstuff » Fri, Oct 02, 2020, 12:11 AM UTC

cammil wrote: post #60

yellowstuff wrote: post #47

Earlier quoted context omitted.

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

I think I understand your point. Do you think that the "programming language" should sacrifice the usefulness of its syntax in order to appeal to beginners more? There is also I think a difference between Architecture and software development in that an architect aims to design and plan with drawings and documents a building that in the end is distinct from them, whereas software development produces a set of documen…

> Do you think that the "programming language" should sacrifice the usefulness of its syntax in order to appeal to beginners more?

No. This has been tried a lot and has mostly failed. The notation can be a barrier but it isn't the hardest part.

Re: Programming language notation is a barrier to entry

#167

Post by Macha » Fri, Oct 02, 2020, 12:20 AM UTC

taneq wrote: post #33

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.

If you're familiar with a recipe for baking a cake, the barrier to entry for most imperative languages is small. If you're familiar with Lambda calculus, I imagine the barrier to entry for Haskell is similar. In both cases, entry is the easy bit. Learning the notation is a somewhat orthogonal and arguably much smaller impediment than the inescapable difficulty of figuring out what you're trying to accomplish, and the…

There is a tendency among the more academic of CS researchers, of spending so much time in academia to assume that because they find math notation so simple from their experience using it that this means it is clearly superior to the notation actual programmers use in actual programming languages and treat that like some aberration from industry.

Personally I've always found math notation feels like it was optimised for space efficiency and writing speed on paper, akin to legal shorthand rather than the beauty I'm always told it has. Similarly for attempts to bring programming syntax closer to math syntax. In college I found myself translating equations of medium complexity such as the Fourier transform into pseudocode to understand.

Obviously however, my familiarity with programming notation colours my perspective as much as their experience with math notation colours theirs

Re: Programming language notation is a barrier to entry

#168

Post by Macha » Fri, Oct 02, 2020, 12:28 AM UTC

whateveracct wrote: post #151

yencabulator wrote: post #85

Earlier quoted context omitted.

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.

Why is for example easier to read, type, understand, Google, or any dimension really over "fmap"?

Re: Programming language notation is a barrier to entry

#169

Post by whateveracct » Fri, Oct 02, 2020, 12:32 AM UTC

Macha wrote: post #168

whateveracct wrote: post #151

Earlier quoted context omitted.

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.

Why is for example easier to read, type, understand, Google, or any dimension really over "fmap"?

Applicative style for one

    data Person = Person
    { age :: Int
    , name :: Text
    , height :: Int
    }

        Person
     parseAge
     parseName
     parseHeight

Applicative style is one of the easiest constructs to read relative to the power of what it typically does.

Most other times when you use , you're using it instead of something like this:

    fmap f $ x y z

Which is simplified by

    f  x y z

Google is a non-issue. Hoogle exists and works great (and can even index all symbols importable by your project)

Re: Programming language notation is a barrier to entry

#170

Post by phkahler » Fri, Oct 02, 2020, 12:33 AM UTC

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…

>> My key take-away is to consider how the language interacts with its ecosystem, not just how it should ideally operate in isolation.

Please please, how do we convey this to the mathematicians that infest wikipedia?