12 ms·

Is Nim unsafe?

47 points by Pharohbot 11y ago

Dewie3 11y ago
Good old null pointer.
gjm11 11y ago
The 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".)
- SamReidHughes 11y ago
  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.
  - ossreality 11y ago
    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.
  - dom96 11y ago
    > 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.
    - SamReidHughes 11y ago
      > 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.
      - beagle3 11y ago
        > 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. I disagree. Moving code around in Java or C++, pure brace languages, has at least as much cognitive load as Python does, and as most languages do. Are the variables referenced defined in the new scope? do break/continue still function as expected? Are exceptions properly handled and propogated? The indentation is usually the least of one's worries when moving code around; and at the very least, Python (and I assume Nim, though I hardly have any experience with it) guarantees that the visual and logical code hierarchies match; The fact that they might not is a constant cognitive load in curly brace languages (and a source of bugs if you ignore it).
  - MichaelGG 11y ago
    I didn't get the feeling it was about being clever. Nim just seems like a lot of assorted ideas, stuff you might think up while writing in C++ or something and say "it'd be nice if...". There doesn't seem to be a grand overarching theme or design; it doesn't have the elegance some languages do. But it seems that doesn't matter. Some people really like it, and perhaps some interesting new feature will come out of it and benefit the world.
    - TylerE 11y ago
      It's a GetShitDone language.
      - dmytrish 11y ago
        Or gets_hit_done one.
- rbehrends 11y ago
  > 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 http://nim-lang.org/docs/nimgrep.html [2] http://nim-lang.org/docs/nimsuggest.html http://nim-lang.org/docs/nimsuggest.html
  - oldmanjay 11y ago
    > 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.
    - beagle3 11y ago
      > if you enable them to do the stupid thing, they will do the stupid thing Yes, that's generally true, but I think irrelevant to this specific question. Most languages do not enforce a naming convention. Yet, Java projects almost always follow the same (horrible IMHO) standard, Python program almost always follow one of two standards (underscore_lowercase for everything, or the same with CamelCase for classes), C programs follows one of 20. Even though Java & Go programmers can do the stupid thing in this specific instance, they generally don't, even without enforcement. A C/C++ project usually has a salad of coding conventions, because each of the different libraries (e.g. Qt, GSL, libc/libm) has a different one - regardless of how conformant developers are to their official style guide. Nim actually has an advantage in this respect: It allows you to maintain a uniform style in your codebase, even though it is expected to call out to different styled ones; though I agree a "nim --verify_style=blah_blah" would have been a useful option. Personally, I think that's misguided - if you're using a library, it is better to use the original style (whatever it is) so you don't have to translate back-and-forth from examples, forum discussions, etc. But to each his own.
- PopeOfNope 11y ago
  So the largest thread here is about something off-topic (case sensitivity has nothing to do with safety in Nim) and it's something that's utterly irrelevant. Bravo.
  - deleted 11y ago
    [deleted]
  - vortico 11y ago
    It's pretty typical for Hacker News to be a forum for talking about whatever.
- coldtea 11y ago
  My problem with most languages is not that they are not perfect. Not perfect I can understand and work around. The problem is that they go out of their way to add some batshit crazy stuff like this, or cripple themselves without a reason, when they could be so much better with small and simple additions. Would it be so difficult for Javascript to not ever have those crazy silent coercion rules and have lexical scoping by default? It would have been a trivial compiler change back in 199x when JS was designed. Would it be so difficult for Golang to have a proper generics system from the start and be done with it? Would it be so difficult for Java to add closures 10 or so years ago? etc...
  - mercurial 11y ago
    There is a difference between "not having features" (even not having features by design) and going out of your way to design an absolutely terrible solution to a problem that is, AFAIK, not used in any other language out there.
    - coldtea 11y ago
      Yeah, this Nim thing is on the top of the crazy list...
      - Pyxl101 11y ago
        Why is it crazy? I've wanted this feature recently in other languages. Just because someone else wrote FunctionName doesn't mean that I want to write it that way. Case insenstive search solves the matching problem adequately. You could also do underscore-insensitive searching. Why is it a problem, or crazy? It's a natural extension of being insensitive to whitespace and formatting. If you like your code to look_like_this, fine. Someone else PrefersThis. It can all interoperate. I think that's great. Leave style to each person's preference.
        coldtea 11y ago
        >Just because someone else wrote FunctionName doesn't mean that I want to write it that way. If it's different codebases, you can do that in almost any language. Have some comebases write fooBar and others write foo_bar or whatever, whatever each one prefers. It's not very good even in that case, because you'll often have to read somebody else's codebase (which is why people praise go fmt and organizations have coding guidelines), but at least there it's OK. But if you're talking about FunctionName and functionName and function_name in the SAME codebase (and obviously you do, since for the previous case you don't need Nim at all as I said) then that's were madness lies -- willingly impairing yourself to identify optically a symbol to be the same as another or not, because it can have 20 variations... I've never found this "flexibility" and bike-shedding that ensues useful in any language. I'd even prefer a fixed brace style, even it's not the one "I like". It takes a few weeks of familiarity to learn to perfectly see a different formatting style and even "like it".
pyre 11y ago
> Is Nim unsafe? Are the binaries hosted on SourceForge?
PopeOfNope 11y ago
When I read between the lines, this section says to me: "Yes, Nim is unsafe, but there are features on the way to help it be more safe." 'not nil' sounds like a great addition to the language, but what if you wanted that to be the default behavior without having to pepper it throughout every variable in your codebase?
- Pharohbot 11y ago
  Well the biggest concern for most is null pointers, so invoking not nil on the pointers would suffice for most
overgard 11y ago
> It's not hard to "fix" this issue anyway. Where "fixing" means "pretending Nim created Ansi C code in the first place" (which it doesn't). They should probably fix the wording of this -- as an outsider I can't really parse the message conveyed here. If it doesn't create C code then why does the comparison matter? Or is it just about the "ansi" part? But then why does that matter?)

47 points by Pharohbot 11y ago

Good old null pointer.

gjm11 11y ago

The 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".)

SamReidHughes 11y ago
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.
- ossreality 11y ago
  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.
- dom96 11y ago
  > 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.
  - SamReidHughes 11y ago
    > 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.
    - beagle3 11y ago
      > 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. I disagree. Moving code around in Java or C++, pure brace languages, has at least as much cognitive load as Python does, and as most languages do. Are the variables referenced defined in the new scope? do break/continue still function as expected? Are exceptions properly handled and propogated? The indentation is usually the least of one's worries when moving code around; and at the very least, Python (and I assume Nim, though I hardly have any experience with it) guarantees that the visual and logical code hierarchies match; The fact that they might not is a constant cognitive load in curly brace languages (and a source of bugs if you ignore it).
- MichaelGG 11y ago
  I didn't get the feeling it was about being clever. Nim just seems like a lot of assorted ideas, stuff you might think up while writing in C++ or something and say "it'd be nice if...". There doesn't seem to be a grand overarching theme or design; it doesn't have the elegance some languages do. But it seems that doesn't matter. Some people really like it, and perhaps some interesting new feature will come out of it and benefit the world.
  - TylerE 11y ago
    It's a GetShitDone language.
    - dmytrish 11y ago
      Or gets_hit_done one.
rbehrends 11y ago
> 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 http://nim-lang.org/docs/nimgrep.html [2] http://nim-lang.org/docs/nimsuggest.html http://nim-lang.org/docs/nimsuggest.html
- oldmanjay 11y ago
  > 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.
  - beagle3 11y ago
    > if you enable them to do the stupid thing, they will do the stupid thing Yes, that's generally true, but I think irrelevant to this specific question. Most languages do not enforce a naming convention. Yet, Java projects almost always follow the same (horrible IMHO) standard, Python program almost always follow one of two standards (underscore_lowercase for everything, or the same with CamelCase for classes), C programs follows one of 20. Even though Java & Go programmers can do the stupid thing in this specific instance, they generally don't, even without enforcement. A C/C++ project usually has a salad of coding conventions, because each of the different libraries (e.g. Qt, GSL, libc/libm) has a different one - regardless of how conformant developers are to their official style guide. Nim actually has an advantage in this respect: It allows you to maintain a uniform style in your codebase, even though it is expected to call out to different styled ones; though I agree a "nim --verify_style=blah_blah" would have been a useful option. Personally, I think that's misguided - if you're using a library, it is better to use the original style (whatever it is) so you don't have to translate back-and-forth from examples, forum discussions, etc. But to each his own.
PopeOfNope 11y ago
So the largest thread here is about something off-topic (case sensitivity has nothing to do with safety in Nim) and it's something that's utterly irrelevant. Bravo.
- deleted 11y ago
  [deleted]
- vortico 11y ago
  It's pretty typical for Hacker News to be a forum for talking about whatever.
coldtea 11y ago
My problem with most languages is not that they are not perfect. Not perfect I can understand and work around. The problem is that they go out of their way to add some batshit crazy stuff like this, or cripple themselves without a reason, when they could be so much better with small and simple additions. Would it be so difficult for Javascript to not ever have those crazy silent coercion rules and have lexical scoping by default? It would have been a trivial compiler change back in 199x when JS was designed. Would it be so difficult for Golang to have a proper generics system from the start and be done with it? Would it be so difficult for Java to add closures 10 or so years ago? etc...
- mercurial 11y ago
  There is a difference between "not having features" (even not having features by design) and going out of your way to design an absolutely terrible solution to a problem that is, AFAIK, not used in any other language out there.
  - coldtea 11y ago
    Yeah, this Nim thing is on the top of the crazy list...
    - Pyxl101 11y ago
      Why is it crazy? I've wanted this feature recently in other languages. Just because someone else wrote FunctionName doesn't mean that I want to write it that way. Case insenstive search solves the matching problem adequately. You could also do underscore-insensitive searching. Why is it a problem, or crazy? It's a natural extension of being insensitive to whitespace and formatting. If you like your code to look_like_this, fine. Someone else PrefersThis. It can all interoperate. I think that's great. Leave style to each person's preference.
      - coldtea 11y ago
        >Just because someone else wrote FunctionName doesn't mean that I want to write it that way. If it's different codebases, you can do that in almost any language. Have some comebases write fooBar and others write foo_bar or whatever, whatever each one prefers. It's not very good even in that case, because you'll often have to read somebody else's codebase (which is why people praise go fmt and organizations have coding guidelines), but at least there it's OK. But if you're talking about FunctionName and functionName and function_name in the SAME codebase (and obviously you do, since for the previous case you don't need Nim at all as I said) then that's were madness lies -- willingly impairing yourself to identify optically a symbol to be the same as another or not, because it can have 20 variations... I've never found this "flexibility" and bike-shedding that ensues useful in any language. I'd even prefer a fixed brace style, even it's not the one "I like". It takes a few weeks of familiarity to learn to perfectly see a different formatting style and even "like it".

pyre 11y ago

> Is Nim unsafe? Are the binaries hosted on SourceForge?

PopeOfNope 11y ago

When I read between the lines, this section says to me: "Yes, Nim is unsafe, but there are features on the way to help it be more safe." 'not nil' sounds like a great addition to the language, but what if you wanted that to be the default behavior without having to pepper it throughout every variable in your codebase?

Pharohbot 11y ago
Well the biggest concern for most is null pointers, so invoking not nil on the pointers would suffice for most

overgard 11y ago

> It's not hard to "fix" this issue anyway. Where "fixing" means "pretending Nim created Ansi C code in the first place" (which it doesn't). They should probably fix the wording of this -- as an outsider I can't really parse the message conveyed here. If it doesn't create C code then why does the comparison matter? Or is it just about the "ansi" part? But then why does that matter?)