@lltp says: > > Imagine yourself in 2 years, Nim is flourishing, a community starts to > > build, the standard lib improved by a lot... However you uncovered a bug in > > it. You have a look at it and you see a perl-ish "Nim" that you spend weeks > > to learn (since the guy who made it didn't care to write proper > > documentation and suddenly disappeared after a few months, so basically you > > are on your own to fix that bug). You finally find that the bug comes from > > a call to another lib, which this time is an Haskell-ish dialect of Nim... > > Is that perspective really appealing?
I don't have to imagine. I'm a long-time Ruby developer and Ruby is a quintessential "many-ways-to-do-one-thing" language. I often come across Perl-ish Ruby, full OO Ruby, functional-style Ruby, Java-esque Ruby, curly braces instead of do-ends, list comprehensions instead of method chaining, and many other styles. None of these is 'the Ruby way' but they all work and the community hasn't been harmed at all by it, quite the contrary, it allows newcomers to the language easy adoption until they figure out the 'right' way. More importantly, it contributes to creativity and diversity of ideas within the community as people learn and develop by comparing different ways to do the same thing. One thing that puts me off Python is the Zen 'only one way to do something' approach. In contrast, Nim's flexibility and versatility is extremely appealing and the ability to 'skin' it would take it to the next level. I agree that the Nim core team should focus on other, more important things, such as stability and documentation. However, if someone would undertake a side project of multi-syntax support, I'd help any way I could within my limited ability.
