In my persistent experience as a Nim advocate, various issues of superficial syntax preferences continue to come up - literally on a daily basis...
In the [r/nim link](https://www.reddit.com/r/nim/comments/5pjf3v/nim_makes_slashdot_new_release_of_nim_borrows/) to [Nim making Slashdot](https://slashdot.org/story/321517), a commenter summed up the /. comments as follows: > And the discussion turned into a holy war between White Space Knights, Curly > Braces Commandos and a few Begin/End Revolutionists Some people are addicted to C-isms, some to useless "end" lines, etc - and they won't even consider a language that does things differently. I think the Pythonic ["off-side rule"](https://en.wikipedia.org/wiki/Off-side_rule) syntax [is](https://unspecified.wordpress.com/2011/10/18/why-pythons-whitespace-rule-is-right/) objectively superior in saving keystrokes and screen real-estate while also encouraging correct practices and improving readability - but I also believe in "the customer is always right". And so I would like to re-introduce the topic of _Nim Syntax "Skins"_ to this forum, first by summarizing what I've heard about this idea so far. A year ago [Araq wrote](https://archive.is/enZm9#selection-299.0-303.115): > The initial design of **Nim was envisioned as an AST with multiple "skins"** > so programmer A can have it his way and still use programmer B's module > directly rather than having to interface with a completely different > programming language. And after 10 years this simple idea is still ahead of > its time with the closest implementation for this idea being .NET. [...] The discussion of syntax skins was [raised briefly several times on IRC](https://www.google.com/webhp?q=skin+site:irclogs.nim-lang.org). Here are some of my musings: > **We should all spare Araq our syntax complaining. Everyone should just make > their own Nim "skin".** I've been pondering lots of crazy ideas for this. > > **Having a "skin" that using C-like curly braces without one-off rule would > like double Nim's appeal overnight.** > > I agree that braces are useless, but **more syntax "skins" => more users => > more contribs** => more sushi. > > Nim can be the ideal programming ecosystem, but no one syntax skin can > compete with Python and Rust at the same time. There could eventually be an > even more high-level way to code Nim. Implicit var, implicit type conversion, > much syntax sugar, etc. But that's not a priority for now. > > My Nim skin would also allow avoiding repetitive keywords, like = assignment > operator defaulting to var, ≗ to let, and ≛ to const. Unfortunately, I do not have the depth of knowledge to be the first programmer to implement an alternative skin for Nim. But I think anyone who breaks the ice on this issue by creating a curly brace skin for Nim would bring a lot of added attention and contributions to the Nim ecosystem. That would spark a marketplace of competing syntax philosophies, on which programmers can "agree to disagree" \- all to Nim's benefit.
