# 1\. Name and about Nim is the smartest name a language could have nowadays, since the Nimrod myth points to the human blindness seeking for power and richness that lead to the kind of confusion and humiliation of having multiple languages.
Nim is on the way to correct this human mistake, serving as a lingua franca for coding, from web frameworks to microcontrollers and dsl's. The Nim Crown is there to remember the way we need to walk to restore the unity, with simplicity and enabling everyone build good stuff with less effort. Yet there is a kind of secrecy about the name and inspiration/purpose of Nim lang. As people always refers to a forum post, looking unnoficial and prone to changing. Why is this important? To reason about meaning, put purpose int what we do, how we do and for what we do. Would be nice if it would explicitly expressed. # 2\. Conventions are not so bad There is some discussion about case sensitivity and underscore usage. Some things should be considered in this aspect: * DocGen generated shows the name of procedures used in code. So, reading a documentation, someone sees many kinds of naming conventions, leading to an cracked experience of errors and trials. It is not good, specially for bigger projects. * NimSuggest allows lsp to serve code names. It need to respect the name found in a code. So, if I use under_score in my code and some dependency uses camelCase, or vice-versa, I would end disabling completion tool (limiting my work) or in a compulsion for refactor any complete piece of code. Even people not prone to that, will look at their own code less proudly and satisfied. There are users accostumated with current state, but even them will recognize the long term benefits. Newcommers will feel more comfortable (independently from where they come). As time passes more * Package naming also can't have hiphens but can have underscores. It also would need to stick with the naming convention for a matter of simplicity. # 3\. Visual shortcuts at compilation messages When compiling code today, there is a coloured "error" message followed by stack trace. Would be nice the message between <> after "type mismatch: got" and each of "but expected one of:" could have some distinguishable way of print, with color, bold or even formatting. This would make easier to reason on debugging spotting the errors, specially for bigger stacks. # 4\. Tips about overloads When there are overloads, it is difficult to discover how and where a function is being overloaded and witch types of its parameters. Nimsuggest shows that a function has overloads. There is no signature, no indication where each overload is to look for. A way to show it would ease a lot. # Conclusion As a new user of the language, these are superficial things I could spot after two months of usage. I don't know the extension and complexity of the current issues to be roadmapped. But as suggestion, I need to be honest contributing with this perception.
