Hacker News Reader

Comment by anchpop | Hacker News Reader

Syntax may be irrelevant at the end of the day, but nice syntax can make a big difference in usability imo. I'm not following the Rust example, but discussions of it remind me about discussions about UFCS (Universal Function Call Syntax). That's where `foo(a, b)` can be rewritten as `a.foo(b)`. That may seem minor, but look at this code:

    half_square = divide(square(a), 2)

In comparison to:

    half_square = a.square().divide(2)

Many find the latter much more pleasant to read, and things like this can make a big difference in how fun I find it to use a language.

View on HN

Interesting example...I find the first much easier to read and reason about. ¯\_(ツ)_/¯

I agree with you. I find that in the first example the order of operation is much more explicit at a glance than the second, but I could also get used to the second without much effort. I think it all comes down to what your background is.

It would be nice for both of us to get a brain scan while reading that kind of code, because I find the second immensely more intuitive to parse

I find them completely equivocal. This is the geeky version of the orange/white dress.

Me too but I suspect thats because the first is the pattern used in nearly every language I've spent extended time with since I was a kid (30 years ago).

I don't think either is better but one is definitely familiar.

Generally I try not to care about syntax too much (except putting $ on the front of a variable, that annoys me not so much because they did but because not everyone did so every time I switch from PHP to TypeScript I end up putting $ on at least once a day), the weird part is that I write idiomatic code in both so my brain knows it shifted context but I still put the $.

    let $foo = bar;

Just looks wrong.

Weirder still when I run into code written by people who do

    let $foo = $(foo);

For jQuery stuff (I totally get the reason why).

Brains are funny things.

I think you can skip the empty () in D. The syntax becomes much more readable when you don't have to return to upper levels of functions. Thankfully pipes exist in functional languages, which makes it feel just right

    half_square =
      a
      |> square
      |> divide(_, 2)

Was going to mention pipes... which imho is about the nicest syntax imho in terms of being able to follow workflow.

I left the `()` because in some imperative languages there's a difference between `() -> a` and `a`, which makes `a.b` and `a.b()` different. In Haskell there's `>>>` and `&` in base, which I use all the time for this sort of workflow:

    find_half_square = square >>> (flip divide) 2

This creates a function which takes a value, performs `square`, then performs `(flip divide) 2`. It's written in pointfree style, which means the function's input is never written in the definition of the function, which I find to be extremely aesthetically pleasing (as it allows me to focus on the composition of functions, without thinking about passing arguments around). This is one situation where changes in syntax allow you to reason about programs quite differently.

"(flip divide) 2" can also be written as "(`divide` 2)" – i saw that idiom recently and i'm warming up to it!

Whatever pleasantness may come from that or any other specific example is totally outweighed by the constant overhead of having to remember that there are N ways to do 1 thing. As a primary rule: the best programming grammar has the fewest such ambiguities, ideally zero.

This is a strong assertion with basically no backing, and all modern languages have some level of what you call ambiguity, so this isn't true in practice either.

Folks who really believe that program in lambda calculus.

In practice, syntax is the UI for a programming language. And just as with any UI, there's a bunch of tradeoffs between how easy the language is to use for a newbie (who knows nothing), how easy it is for casual user (who knows a few core constructs but has to lookup advanced functionality), how productive it is for an expert (who has a vast working memory of functionality), and how powerful it is (in terms of which constructs can even be represented). Different users will have different opinions on which tradeoffs are justified, largely depending on where they fall on this continuum.

On one side of the (practical) continuum, you have languages like COBOL, BASIC, PHP, and Hypercard, which are explicitly designed to seem familiar to people who know other non-programming technologies. On another, you have languages like Scheme, C, Go, and Java, which have a small set of broadly-applicable core concepts but require some verboseness to express lots of common patterns. And on the third, you have languages like C++ and Perl where experts can express very powerful programs without a whole lot of typing, but which can be rather impenetrable to people who haven't spent years mastering them.

I think this is a fair summary, but I also think that C++ and Perl can be pretty fairly judged as failures, due to, or in the ways that, you enumerate.

Put another way, it is not true that powerful languages must necessarily be impenetrable.

Put still another way, the amount of typing you do (within certain bounds of reason) is an almost totally irrelevant metric when judging a programming language.

What's a big difference for you got to do with the design of a language used by many others? What makes your experience more important than the experiences of someone with different qualifications?

Why is optimizing for your tastes the correct thing to optimize for?

If it's a big difference to me, it would be surprising if it was not a big difference to some portion of people (in either direction, I wouldn't be surprised if most people hate it). Since it makes a big difference to some portion of people, it is worth discussing. My intention with my comment was to make the argument that spending a long time discussing syntax can be a useful and productive thing for language designers to do.

If you're going to make that argument, you should probably be less vague. It makes a "big impact" to "some portion of people" that the Earth be thought flat, but you can't justify wasting a "long time" arguing about it.

Language designers don't need vague personal opinions masquerading as 'useful' facts, intentionally sculpted for inappropriate generalization. They need to know what the purpose of the syntax is and what the expectations of the language/user base are. Beyond that, you're just contributing noise.

And given that this criticism is largely against bikeshedding, it is interesting that you would try and justify it with statements of self-importance; bikeshedding largely happens because involving people in a decision leads them to massively over-value the importance of the decision simply because they are a part of it. You may be an expert on your own opinions, but if you're not an expert on their relevance, then you're not helping.

Reply on news.ycombinator.com