Is Nim unsafe? • Hacker News Board

Re: Is Nim unsafe?

#11

Post by deathanatos » Sat, Jun 06, 2015, 1:21 AM UTC

dom96 wrote: post #9

SamReidHughes wrote: post #5

Earlier 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…

>> Nim also allows passing by non-const reference without any indication of such at the call site.

> Why is this a problem?

I have no experience with Nim. In C++, I've heard people argue that this is poor language design because at the call site, you cannot see that the variable is potentially being mutated; making it explicit that a mutable reference is being passed allows the reader of the call site to understand what mutations might occur without needing to know the signature of every function involved.

I've been learning Rust, which requires notation at the call site that you're passing a mutable reference, and thus far, I quite prefer it; I had been concerned that it might be "too much typing", but it's proven to be rare and unobtrusive.

Re: Is Nim unsafe?

#12

Post by beagle3 » Sat, Jun 06, 2015, 1:58 AM UTC

SamReidHughes wrote: post #10

dom96 wrote: post #9

Earlier quoted context omitted.

> 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 h…

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

Re: Is Nim unsafe?

#13

Post by tomjakubowski » Sat, Jun 06, 2015, 1:59 AM UTC

deathanatos wrote: post #11

dom96 wrote: post #9

Earlier quoted context omitted.

> 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…

>> Nim also allows passing by non-const reference without any indication of such at the call site. > Why is this a problem? I have no experience with Nim. In C++, I've heard people argue that this is poor language design because at the call site, you cannot see that the variable is potentially being mutated; making it explicit that a mutable reference is being passed allows the reader of the call site to understand w…

> I've been learning Rust, which requires notation at the call site that you're passing a mutable reference, and thus far, I quite prefer it; I had been concerned that it might be "too much typing", but it's proven to be rare and unobtrusive.

I'm so glad Rust made this design choice, because it means that a programmer can see very quickly where borrows are happening and understand where and where not new borrows could be inserted.

Take this example:

    struct Widget {
        name: String
    }
    
    fn jabberwock_the_widget(w: &mut Widget) {
        w.name.push_str(" (modified)");
    }
    
    fn main() {
        let jimbo = Widget { 
            name: "Jimbo".to_string() 
        };
        let name = &jimbo.name;
        jabberwock_the_widget(&mut jimbo);
    }

If that call were just `jabberwock_the_widget(jimbo)`, and I didn't have `jabberwock_the_widget`'s signature at hand, I would have to run the code through a compiler to see that there is an illegal mutable borrow on jimbo. With mutable borrows written so explicitly, it's clear at the call site that it can't happen with the existing borrow on the widget's name.

Re: Is Nim unsafe?

#14

Post by beagle3 » Sat, Jun 06, 2015, 2:08 AM UTC

oldmanjay wrote: post #8

rbehrends wrote: post #6

Earlier quoted context omitted.

> 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.

> 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.

Re: Is Nim unsafe?

#15

Post by Gankro » Sat, Jun 06, 2015, 2:28 AM UTC

tomjakubowski wrote: post #13

deathanatos wrote: post #11

Earlier quoted context omitted.

>> Nim also allows passing by non-const reference without any indication of such at the call site. > Why is this a problem? I have no experience with Nim. In C++, I've heard people argue that this is poor language design because at the call site, you cannot see that the variable is potentially being mutated; making it explicit that a mutable reference is being passed allows the reader of the call site to understand w…

> I've been learning Rust, which requires notation at the call site that you're passing a mutable reference, and thus far, I quite prefer it; I had been concerned that it might be "too much typing", but it's proven to be rare and unobtrusive. I'm so glad Rust made this design choice, because it means that a programmer can see very quickly where borrows are happening and understand where and where not new borrows coul…

This has pretty limited scope, though. If a function you call returns an &mut you have no way to tell thanks to type inference, and when you use that value it looks like you're passing by-value.

Similarly if you call a method, there's no indication at all how `self` is being passed.

Re: Is Nim unsafe?

#16

Post by MichaelGG » Sat, Jun 06, 2015, 2:34 AM UTC

SamReidHughes wrote: post #5

gjm11 wrote: post #3

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 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…

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.

Re: Is Nim unsafe?

#17

Post by rbehrends » Sat, Jun 06, 2015, 3:03 AM UTC

SamReidHughes wrote: post #10

dom96 wrote: post #9

Earlier quoted context omitted.

> 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 h…

> 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.

Just a second, let me put on my Eiffel/Ada hat for this question.

The contract between a caller and callee is a potentially complex thing; it specifies not only which arguments can be mutated (if at all), but also how their abstract state before and after relate to each other or what other visible side effects may be produced. I refer you to the Eiffel and Ada language specifications for possible ways to specify such contracts, invariants, and pre- and postconditions. Common convention is that functions that return a value do not have visible side-effects at all (the Ada '83 rationale specifically found limitations that disallowed all side effects at the language level too limiting). See: Command-query separation. Adhering to CQS, queries do not mutate arguments, and commands are expected to; hence, you need to know the specific contracts for commands and how they affect their arguments, but can rely on query arguments not changing.

More generally, mutability of arguments is just one aspect of a contract; importantly, in order to be able to optimize or change the internal representation of an object, we may desire the option of having mutability of the concrete state even where the abstract state remains immutable (e.g. splay trees or self-organizing lists, arguments that have internal caches, etc.). Languages that force a knowledge of immutability of the concrete state at the call site can thus violate principles of modularity in that they limit how the implementation may change.

Declarations of immutability of only the location of the variable at the call site (as with out/ref parameters in C#) are of even more limited value; while they guard against some clerical errors, it is not clear that this protection justifies the additional syntactic footprint.

Back to Nim: The simple solution to ensure that a variable is not being modified by the callee, if you desire that, is to use a "let" rather than a "var" declaration. In fact, using "let" for values that you do not intend to change further and only use "var" variables where they are expected to be mutated throughout a procedure is already idiomatic Nim [1] and should guard against the majority of related clerical errors of this kind.

[1] https://github.com/Araq/Nim/wiki/Style-Guide-for-Nim-Code

Re: Is Nim unsafe?

#18

Post by rwallace » Sat, Jun 06, 2015, 3:33 AM UTC

beagle3 wrote: post #12

SamReidHughes wrote: post #10

Earlier quoted context omitted.

> 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 h…

> 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 P…

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

Well it's a cognitive load if you deal with it manually and the source of bugs if you ignore it, but if you use an automatic indenting program, that solves it once and for all, along with a few other problems.

Re: Is Nim unsafe?

#19

Post by PopeOfNope » Sat, Jun 06, 2015, 4:38 AM UTC

gjm11 wrote: post #3

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 us…

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.

Re: Is Nim unsafe?

#20

Post by PopeOfNope » Sat, Jun 06, 2015, 4:42 AM UTC

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?