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

21–30 of 41 posts

Re: Is Nim unsafe?

#21

Post by [deleted] »

PopeOfNope wrote: post #19
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.

[deleted]

Re: Is Nim unsafe?

#22

Post by TylerE »

MichaelGG wrote: post #16
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…

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.

Re: Is Nim unsafe?

#23

Post by vortico »

PopeOfNope wrote: post #19
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.

It's pretty typical for Hacker News to be a forum for talking about whatever.

Re: Is Nim unsafe?

#24

Post by coldtea »

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…

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

Re: Is Nim unsafe?

#25

Post by overgard »

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

Re: Is Nim unsafe?

#26

Post by mercurial »

beagle3 wrote: post #14
oldmanjay wrote: post #8

Earlier quoted context omitted.

> 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 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_underscore identifiers everywhere while library B relies on lowercase everywhere, same with Bob and Alice working in the same codebase) but is the source of surprising behaviours.

If you want to enforce style conventions, either make them mandatory at the language level or write gofmt. The Nim "solution" is one of the things that kept me from even wanting to spend two hours checking it out.

Re: Is Nim unsafe?

#27

Post by mercurial »

coldtea wrote: post #24
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…

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

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.

Re: Is Nim unsafe?

#28

Post by coldtea »

mercurial wrote: post #27
coldtea wrote: post #24

Earlier quoted context omitted.

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

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.

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

Re: Is Nim unsafe?

#29

Post by Pyxl101 »

coldtea wrote: post #28
mercurial wrote: post #27

Earlier quoted context omitted.

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.

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_this, fine. Someone else PrefersThis. It can all interoperate. I think that's great. Leave style to each person's preference.

Re: Is Nim unsafe?

#30

Post by coldtea »

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

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

Post reply on HN