Hacker News Reader

Comment by nathan_compton | Hacker News Reader

This appears to be a pile of syntactic sugar on top of Lua, which is an idea which would have appealed to me a lot as a younger developer. But the older I get the more I realize that its almost never actually syntax or brevity that gets in the way in a software project and that this sort of thing often introduces a lot of cognitive overhead. It isn't that these extra doodads are hard to wrap your head around, but the fact that we have two very similar languages (Pluto, Lua) that we are interactive with on a regular basis (because Pluto works within the Lua ecosystem) and now we have to think about that a lot.

I think a lot of programmers when they first learn Lisp go crazy with macros, adding all sorts of flimflam to their programs because they can, but then eventually you realize that just makes life harder, or at least marginally more complicated, and you gradually give it up. Feels like a similar calculation could apply here.

View on HN

Absolutely agree. In my experience, languages that have multiple forms of syntax for doing the same thing are just laborious to read.

Kotlin has some great ideas, but it's kind of frustrating to have half my code yellow-highlighted because the IDE has detected that there's a short-hand version of everything.

I feel like good syntactic sugar should reduce cognitive load.

for example in JavaScript

    let fish = 5
    let cheese = 27
    let nop = 0x4e71

being able to do

    result = {fish,cheese,nop}

Is 'only' syntatic sugar but significantly reduces the cognitive load over

    result = {fish:fish,cheese:cheese,nope:nop}

looking at the latter it is harder to take in the options at a glance, when reviewing you have to check if the names match. If they don't match was it intentional or accidental. Whereas if you encountered

    result = {fish,cheese,nope:nop}

You are left with no doubt that the nope is not a typo but a explicit name specifier.

I don't know, from my point of view having both syntaxes is clearly more to think about, and all you get from the shorter one is typing a few fewer keystrokes.

Philosophically, I feel a little ambivalent about the briefer syntax because it mixes two sorts of denotations. Variables refer to scoped objects for which, from the point of view of what the program means, vanish (in compiled languages they literally can totally vanish - variable references are just resolved into the appropriate reference to memory). The keys of a hash table are totally different sorts of things and persist at runtime. I'd prefer that these two very distinct conceptual spaces remain separate, even if in a certain sense they overlap in a specific case.

Doesn't really matter, though.

>I don't know, from my point of view having both syntaxes is clearly more to think about

That's storage, not load. You need you know more, but you don't have to think about as much at any one time.

BrainFuck has extremely simple operations. You don't have to think about very many different things at all, but you need to think about them a lot.

>and all you get from the shorter one is typing a few fewer keystrokes.

I'm not particularly concerned about keystrokes (unless I'm golfing). I'm happy to increase the size of the content to reduce how much I think about it. Reducing the number of elements I have to look at to grasp the same concept is distinct from keystrokes.

Sometimes

   ArbitraryLongVariableName = 43

is better than

   a = 43

one the other hand I'd take

   ArbitraryLongVariableName += 1

over

   ArbitraryLongVariableName = ArbitrarilyLongVariableName + 1

Low key this is so interesting because in Elixir there was this specific example with a library that extended the lang to do this.

The concise syntax was tossed out, but I have a soft spot for it.

Reply on news.ycombinator.com