I've read/heard people express themselves like this many times when talking about certain languages or language's features.
"It's just syntactic ...
For further actions, you may consider blocking this person and/or reporting abuse
You make a good point. About how when things are made with this "syntactic sugar its put there to make things easier". Which I agree with at the same time I feel like there are times where that syntactic sugar can lead people down the wrong road.
I would say the most common example of this would have to be with javascript Class method in ES6. Its syntactic sugar to make it as you said easier for others to come into the language. As well as making it easier to write inheritance in javascript. But at the same time, I feel like this syntactic sugar can complicate learning the language as for one javascript isn't a class-based language.
So I feel like if this syntactic sugar is going to be placed for one it should at least match what the language is actually doing. Not trying to make it look like something it's not.
Lastly, I also don't think its always bad to understand the things going on behind the syntactic sugar because it can actually help understand the reasoning behind the black box. But as you mentioned at the same time we write the code for each other and our future self. So while understanding the black box is good it's important to still make sure to choose whether or not using the syntactic sugar is a better solution than writing out the entire solution.
Ruby and Rails are beautiful examples of syntactic sugar. The whole language is easy to read. Rails does some magical things that has tripped me up a couple times. Digging into that black box is something I always want to do. Sometimes it's necessary. Other times it just slows you down. While learning I think it is useful to understand things.
As a compiler writer I have a different opinion of what "syntactic sugar" actually is. To me, it's something that I can implement in the parsing and syntax tree generation phase.
That is, consider the stages Leaf uses to compile code:
Anything I can implement in phases 1-2 is definitely syntactic sugar. It didn't require any changes in the langauge's abstract machine, or typing rules.
Some things in Step 3 I'd also consider syntactic sugar if they are plain rewriting rules. These are almost like parsing rules, but required a higher level of logic than the syntax tree conversion could do.
At a user level this would imply a feature that can be completely described in reference to other features or already existing concepts. It doens't add any new power or flexibility to the language. It certainly can make it nicer to use though.
As a not compiler writer in the slightest (or a compiler reader for that matter) this made perfect sense. Thank you.
I really love this article - especially this quote:
Of course, it's best to avoid making code less efficient for the sake of readability!
Oh man I have heard JSX described as syntax sugar like three times the past year. If so handlebars, liquid tags, directives, markup, markdown is also syntax sugar?
I for one am more inclined to adapt a language/framework that has the path of least resistance...
Correct me if I'm wrong, but I think the difference here is that JSX is always converted to vanilla JavaScript before it ever reaches the browser or a compiler (see: reactjs.org/docs/jsx-in-depth.html). Whereas markup like HTML can be read as-is. I don't know what happens to handlebars before it reaches the browser, but the infamous Flash Of Unstyled Content issue leads me to think that it's special syntax that handlebars parses and replaces, not syntactic sugar for something else.
I read this about 3 times: jasonformat.com/wtf-is-jsx/
Thanks for the added info re: converted to vanilla JS before reaching browser. I hadn't thought of that at all. The vibe I was agreeing with is that OP feels "syntactic sugar" may be a poor metaphor for something syntactically hybrid (aka writing JS in your HTML).
Markup is parsed as dom tree first I thought, then style sheets + JS are read, but in the case of react, the taskrunner decides what is compiled and rendered first...?
lol at "flash of unstyled content". I only just thought about what kind of mechanism that could be.
I was excited to code for the aliens before you ruined the fun.
Anyway, I am with you there. The fact Someone Somewhere said
just syntactic sugaralready makes me wince. It was said to me before and felt like I was the dumbest to not know what that syntactic sugar is. It being a syntactic sugar doesn't make it any less easier with other syntax. I have to learn it nonetheless.Several years ago I encountered a StackOverflow answer about C++ virtual functions - a seemingly unrelated subject, but one paragraph has changed my view about these things:
I believe this wisdom can be applied to many things - not just virtual functions and not just performance. Many facilities and practices are shunned for reasons like "reducing performance", "introducing complexity" or "increasing the risk of bugs". But when they explain why that thing has these harmful effects, they usually ignore their purpose.
In the case of virtual functions, for example, the purpose is polymorphism - but the comparisons don't use polymorphism. So you run polymorphism code for nothing - of course it would be slower. If you used a benchmark where runtime polymorphism is actually needed, you would have had to implement it in some other fashion - which would have probably reduced performance as much as virtual functions.
Back to the subject
A syntactic sugar usually replaces a more complex code. Removing the sugar does not mean removing it's complexity - it means trading it for the complexity of the desugared code, and I fail to see the gain in that...
Lots of interesting thoughts here! I'll add one of my own in response to this:
This is definitely true in the way you described it here, when it comes to what syntax to use.
Regarding what to write – that might end up being for users, or possibly aliens :P
Syntax and what to write don't really have much of a tradeoff though, so I think it makes sense to write for other programmers, as you say :)
Whatever server your reader best. It would however be strange NOT to use language features because they are not implemented in other languages or are just not well known features. I'm not surprised you picked this in a context of Kotlin because it seems to have lots of ways to achieve the same effect and may produce very dense code.