3 ms·
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.
by nathan_compton 1y ago
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.
- Lerc 1y ago>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
- hmmokidk 1y agoLow 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.