Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is Nim unsafe?

github.com

Post reply on HN
Print view View original

31–40 of 41 posts

Re: Is Nim unsafe?

#31

Post by kibwen »

Gankro wrote: post #15
tomjakubowski wrote: post #13

Earlier quoted context omitted.

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

  > If a function you call returns an &mut you have no way 
  > to tell
Indeed, but also consider that a function can't return a `&mut` unless a `&mut` was passed in to it somehow. This means that the only way to implicitly introduce a `&mut` is via a method call like `foo.bar()` that takes `&mut self`, but also consider that it would be impossible to call the method here unless `foo` were explicitly declared as mutable to begin with. Given that mutable variables in Rust are relatively rare, these factors conspire to broadcast any mutable references quite clearly.

Re: Is Nim unsafe?

#32

Post by beagle3 »

rwallace wrote: post #18
beagle3 wrote: post #12

Earlier quoted context omitted.

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

Same is true of Python (and I assume, Nim)

Re: Is Nim unsafe?

#33

Post by mercurial »

Pyxl101 wrote: post #29
coldtea wrote: post #28

Earlier quoted context omitted.

Yeah, this Nim thing is on the top of the crazy list...

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

> Leave style to each person's preference.

That's fine for hobby projects. That's pretty much the last thing you want for a codebase of a significant size. I don't like C#'s style conventions, for instance, but I'd rather work with a language that has uniform style conventions I dislike than in the free-for-all you get with Nim.

Python's "There should be one-- and preferably only one --obvious way to do it." applies to style as well.

Re: Is Nim unsafe?

#34

Post by beagle3 »

mercurial wrote: post #26
beagle3 wrote: post #14

Earlier quoted context omitted.

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

There is a difference between "enforcing a style convention" and "treating different style conventions as equivalent". The first is much preferable to the second (eg, you could easily enforce lowercase_with_underscore for identifiers and CamlCase for types). Treating different conventions as equivalent, though, is an excellent of ending with code that looks visually different (library A can still use Capitalized_with…

It's been awhile since I've used Pascal, and I'm not yet on the Nim bandwagon - but when I did use pascal (and I did for a few years), the case insensitivity was not, in fact, a source of surprising behaviours. I have no idea what you're talking about.

It is not really confusing that you can't have both MoveFilesEx and MoveFileSex in the same scope (and that you can refer to a variable or procedure by a either name). Nim just feels like taking this a little farther - making '_' the lower case version of no character. Not at all a big jump from Pascal, and pascal is not confusing.

In fact, experiments teaching Python to non-programmers indicated that the two biggest confusing issues were case sensitivity and integer division[0].

> The Nim "solution" is one of the things that kept me from even wanting to spend two hours checking it out.

That sentiment is very often expressed by people coming from C/C++/Java about Python's indentation (What? Whitespace is significant to semantics? That's awful!). And you know what? I know not of one person who actually tried Python and actually had a problem.

[0] http://www.alice.org/ - can't find the rational description now; but I was following its development, and IIRC those were the two biggest stumbling blocks in Python (which were therefore changed in Alice)

Re: Is Nim unsafe?

#35

Post by Pyxl101 »

coldtea wrote: post #30
Pyxl101 wrote: post #29

Earlier quoted context omitted.

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

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

If we were following this idea, then I think source would be displayed according to your preference whenever you looked at it. You'd never need to deal with multiple symbol variations. The goal would not be to use multiple styles in on code add so much as make style entirely personal.

Re: Is Nim unsafe?

#36

Post by dmytrish »

TylerE wrote: post #22
MichaelGG wrote: post #16

Earlier quoted context omitted.

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

It's a GetShitDone language.

Or gets_hit_done one.

Re: Is Nim unsafe?

#37

Post by mercurial »

beagle3 wrote: post #34
mercurial wrote: post #26

Earlier quoted context omitted.

There is a difference between "enforcing a style convention" and "treating different style conventions as equivalent". The first is much preferable to the second (eg, you could easily enforce lowercase_with_underscore for identifiers and CamlCase for types). Treating different conventions as equivalent, though, is an excellent of ending with code that looks visually different (library A can still use Capitalized_with…

It's been awhile since I've used Pascal, and I'm not yet on the Nim bandwagon - but when I did use pascal (and I did for a few years), the case insensitivity was not, in fact, a source of surprising behaviours. I have no idea what you're talking about. It is not really confusing that you can't have both MoveFilesEx and MoveFileSex in the same scope (and that you can refer to a variable or procedure by a either name).…

> It is not really confusing that you can't have both MoveFilesEx and MoveFileSex in the same scope (and that you can refer to a variable or procedure by a either name).

This "feature" makes it just as annoying as dealing with, eg, PHP, where the same codebase may feature NULL or null. It encourages inconsistency.

> Nim just feels like taking this a little farther - making '_' the lower case version of no character.

Yes, because making grep (and search functions from code editors and IDEs) useless is a fantastic idea :(

> That sentiment is very often expressed by people coming from C/C++/Java about Python's indentation (What? Whitespace is significant to semantics? That's awful!).

I have no issue with Python's indentation (apart from the fact that reindenting badly indented Python is not fun). That's a different problem. Whitespace is a different solution, but not particularly confusing.

> In fact, experiments teaching Python to non-programmers indicated that the two biggest confusing issues were case sensitivity and integer division[0].

I feel that basing the design of a language based on the use-cases of non-programmers, for something they will likely not consider an issue after two weeks, at the expense of code maintainability is a mistake.

Re: Is Nim unsafe?

#38

Post by beagle3 »

mercurial wrote: post #37
beagle3 wrote: post #34

Earlier quoted context omitted.

It's been awhile since I've used Pascal, and I'm not yet on the Nim bandwagon - but when I did use pascal (and I did for a few years), the case insensitivity was not, in fact, a source of surprising behaviours. I have no idea what you're talking about. It is not really confusing that you can't have both MoveFilesEx and MoveFileSex in the same scope (and that you can refer to a variable or procedure by a either name).…

> It is not really confusing that you can't have both MoveFilesEx and MoveFileSex in the same scope (and that you can refer to a variable or procedure by a either name). This "feature" makes it just as annoying as dealing with, eg, PHP, where the same codebase may feature NULL or null. It encourages inconsistency. > Nim just feels like taking this a little farther - making '_' the lower case version of no character.…

> This "feature" makes it just as annoying as dealing with, eg, PHP, where the same codebase may feature NULL or null. It encourages inconsistency.

This is not a problem in practice, after two weeks. Seriously - Pascal has fallen out of favor, but there are large pascal codebases that demonstrate this point. NIL, NiL, nIl, nil are all accepted as the null pointer. It really isn't a problem in practice, not even remotely.

> Yes, because making grep (and search functions from code editors and IDEs) useless is a fantastic idea :(

No, grep is not useless, though it isn't quite as useful (just as much as #define makes grep less potent in C/C++). nimgrep fills some of the void.

> I feel that basing the design of a language based on the use-cases of non-programmers, for something they will likely not consider an issue after two weeks, at the expense of code maintainability is a mistake.

The Alice study was just an example BASIC and Pascal (and its predecessors) were designed in the late '60s and early '70s and feature case insensitivity. Nim follows Pascal, not Alica.

It looks like you are really upset with choices because of some theoretical objection. I have not really used Nim, but I have used both BASIC and Pascal very extensively. Case sensitivity and alternate spellings are NOT problems in practice, even though you try very hard to imagine that they are.

Re: Is Nim unsafe?

#39

Post by Pharohbot »

PopeOfNope wrote: post #20

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?

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

Re: Is Nim unsafe?

#40

Post by mercurial »

beagle3 wrote: post #38
mercurial wrote: post #37

Earlier quoted context omitted.

> It is not really confusing that you can't have both MoveFilesEx and MoveFileSex in the same scope (and that you can refer to a variable or procedure by a either name). This "feature" makes it just as annoying as dealing with, eg, PHP, where the same codebase may feature NULL or null. It encourages inconsistency. > Nim just feels like taking this a little farther - making '_' the lower case version of no character.…

> This "feature" makes it just as annoying as dealing with, eg, PHP, where the same codebase may feature NULL or null. It encourages inconsistency. This is not a problem in practice, after two weeks. Seriously - Pascal has fallen out of favor, but there are large pascal codebases that demonstrate this point. NIL, NiL, nIl, nil are all accepted as the null pointer. It really isn't a problem in practice, not even remot…

> It looks like you are really upset with choices because of some theoretical objection. I have not really used Nim, but I have used both BASIC and Pascal very extensively. Case sensitivity and alternate spellings are NOT problems in practice, even though you try very hard to imagine that they are.

I'm not upset, I happen to think that these choices add complexity and promote inconsistency for little practical gain.

> This is not a problem in practice, after two weeks. Seriously - Pascal has fallen out of favor, but there are large pascal codebases that demonstrate this point. NIL, NiL, nIl, nil are all accepted as the null pointer. It really isn't a problem in practice, not even remotely.

If you want to enforce a consistent style, it's one more obstacle in your way. And considering how often projects end up with little technical lead and no enforcement of style whatsoever, I'd rather avoid that.

> No, grep is not useless, though it isn't quite as useful (just as much as #define makes grep less potent in C/C++).

It makes it useless to find an identifier, which means useless 90% of the time I want to use it on a codebase.

> nimgrep fills some of the void.

See? More complexity for no appreciable benefit. A much saner approach would be to implement a compiler warning for this kind of thing.

Post reply on HN