Is Nim unsafe?
github.com
Is Nim unsafe?
1–10 of 41 posts
Re: Is Nim unsafe?
#2Good old null pointer.
Re: Is Nim unsafe?
#3The same FAQ has a question "Why is it case/style insensitive?" and an answer giving four reasons, none of which supports "style insensitivity" in any way.
"Style insensitivity" means that in Nim the following identifiers are treated as equivalent: nOpenFiles, no_pen_files, Nope_NFiles. Insertion and removal of underscores, as well as case, is ignored. I hope you weren't expecting to find anything in your codebase using grep.
It seems a reasonable guess that, oh, maybe 99% of people wondering why Nim is "case/style insensitive" are more worried about "style insensitivity" than about mere "case insensitivity". (The other 1% haven't yet learned that Nim is "style insensitive".)
Re: Is Nim unsafe?
#4> Is Nim unsafe?
Are the binaries hosted on SourceForge?
Re: Is Nim unsafe?
#5The same FAQ has a question "Why is it case/style insensitive?" and an answer giving four reasons, none of which supports "style insensitivity" in any way. "Style insensitivity" means that in Nim the following identifiers are treated as equivalent: nOpenFiles, no_pen_files, Nope_NFiles. Insertion and removal of underscores, as well as case, is ignored. I hope you weren't expecting to find anything in your codebase us…
Nim also has an experimental feature for a+b * c to parse as (a + b) * c, and for a -b to get parsed as a(-b), because of the whitespace. The documentation itself gives an example of echo (a,b) getting parsed as echo((a,b)).
Nim also allows passing by non-const reference without any indication of such at the call site. Also it has semantic indentation, which is cute and clean-looking but more effort to safely edit than the popular alternatives.
Everything I see in Nim is designed around being clever. Even in the documentation they have clever extensions to BNF syntax that save such precious characters.
Re: Is Nim unsafe?
#6The same FAQ has a question "Why is it case/style insensitive?" and an answer giving four reasons, none of which supports "style insensitivity" in any way. "Style insensitivity" means that in Nim the following identifiers are treated as equivalent: nOpenFiles, no_pen_files, Nope_NFiles. Insertion and removal of underscores, as well as case, is ignored. I hope you weren't expecting to find anything in your codebase us…
> I hope you weren't expecting to find anything in your codebase using grep.
This is what nimgrep [1] and nimsuggest [2] are for.
That said, it is still expected to use a consistent style within your codebase. The feature exists so that third-party libraries with a non-standard style can be used without style changes in your codebase.
Re: Is Nim unsafe?
#7The same FAQ has a question "Why is it case/style insensitive?" and an answer giving four reasons, none of which supports "style insensitivity" in any way. "Style insensitivity" means that in Nim the following identifiers are treated as equivalent: nOpenFiles, no_pen_files, Nope_NFiles. Insertion and removal of underscores, as well as case, is ignored. I hope you weren't expecting to find anything in your codebase us…
Nim also has an experimental feature for a+b * c to parse as (a + b) * c, and for a -b to get parsed as a(-b), because of the whitespace. The documentation itself gives an example of echo (a,b) getting parsed as echo((a,b)). Nim also allows passing by non-const reference without any indication of such at the call site. Also it has semantic indentation, which is cute and clean-looking but more effort to safely edit th…
This sounds like a god damn nightmare. Are there people that want this?
Didn't we just go through this the other day with Torvold's latest rant? Don't make me sit here and remember half the spec and precedence for operations. That SLOWS development speed, not increases it.
Re: Is Nim unsafe?
#8The same FAQ has a question "Why is it case/style insensitive?" and an answer giving four reasons, none of which supports "style insensitivity" in any way. "Style insensitivity" means that in Nim the following identifiers are treated as equivalent: nOpenFiles, no_pen_files, Nope_NFiles. Insertion and removal of underscores, as well as case, is ignored. I hope you weren't expecting to find anything in your codebase us…
> I hope you weren't expecting to find anything in your codebase using grep. This is what nimgrep [1] and nimsuggest [2] are for. That said, it is still expected to use a consistent style within your codebase. The feature exists so that third-party libraries with a non-standard style can be used without style changes in your codebase. [1] http://nim-lang.org/docs/nimgrep.html [2] http://nim-lang.org/docs/nimsuggest.h…
> That said, it is still expected to use a consistent style within your codebase.
One of the fundamental truths I've learned over my decades of designing software for consumption by other developers is if you enable them to do the stupid thing, they will do the stupid thing. Expectations aren't really anything meaningful without enforcement.
Re: Is Nim unsafe?
#9The same FAQ has a question "Why is it case/style insensitive?" and an answer giving four reasons, none of which supports "style insensitivity" in any way. "Style insensitivity" means that in Nim the following identifiers are treated as equivalent: nOpenFiles, no_pen_files, Nope_NFiles. Insertion and removal of underscores, as well as case, is ignored. I hope you weren't expecting to find anything in your codebase us…
Nim also has an experimental feature for a+b * c to parse as (a + b) * c, and for a -b to get parsed as a(-b), because of the whitespace. The documentation itself gives an example of echo (a,b) getting parsed as echo((a,b)). Nim also allows passing by non-const reference without any indication of such at the call site. Also it has semantic indentation, which is cute and clean-looking but more effort to safely edit th…
> and for a -b to get parsed as a(-b)
It almost looks like you're suggesting that `a -b` will be parsed as a*(-b). Let me just clarify, that is not the case. With the 'strongSpaces' feature, `a -b` results in a compile-time error. Without that feature, it works as expected (`a-b`).
> Nim also allows passing by non-const reference without any indication of such at the call site.
Why is this a problem?
> Also it has semantic indentation, which is cute and clean-looking but more effort to safely edit than the popular alternatives.
Could you give an example of how exactly semantic indentation makes the language less safe? I have been using Nim (and Python) for years and have not found this to be the case.
Re: Is Nim unsafe?
#10Earlier quoted context omitted.
Nim also has an experimental feature for a+b * c to parse as (a + b) * c, and for a -b to get parsed as a(-b), because of the whitespace. The documentation itself gives an example of echo (a,b) getting parsed as echo((a,b)). Nim also allows passing by non-const reference without any indication of such at the call site. Also it has semantic indentation, which is cute and clean-looking but more effort to safely edit th…
> and for a -b to get parsed as a(-b) It almost looks like you're suggesting that `a -b` will be parsed as a*(-b). Let me just clarify, that is not the case. With the 'strongSpaces' feature, `a -b` results in a compile-time error. Without that feature, it works as expected (`a-b`). > Nim also allows passing by non-const reference without any indication of such at the call site. Why is this a problem? > Also it has se…
> With the 'strongSpaces' feature, `a -b` results in a compile-time error.
Unless there's a function named a? It doesn't matter, you're cherry-picking your response.
> Why is this a problem?
Go ahead and tell us what benefits and detriments you're already aware of, having thought about the question, and I'll tell you if you've missed anything. e: I recommend looking at why C++ has non-const reference parameters and how C# handles the problem and considering whether the benefits of this feature could be had without its detriments.
> Could you give an example of how exactly semantic indentation makes the language less safe?
I said that it was more effort to safely edit. Your question drops the specificity that we're talking about making edits to the code, and also that we're talking about an effort/safety trade-off. Also, it's specifically the kind of semantic indentation found in Python, not (to such a degree) the kind typically found in Haskell. It's easy to find examples: Almost every edit that moves code around takes higher cognitive load than the equivalent done in a language where blocks are explicitly delimited.