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

Nim 1.6.2

nim-lang.org

Post reply on HN
Print view View original

151–160 of 162 posts

Re: Nim 1.6.2

#151

Post by rthomas6 »

spaniard89277 wrote: post #74
FridgeSeal wrote: post #72

Nim is everything Python and Go should be/want to be, as far as language features and semantics go (haha). It has their easy-to-learn properties, but has a better type system, the generics system and macros are arguably more useful, and more usable than what is offered in either language. It deserves far more attention than it currently gets.

As someone learning programming, should I try nim for my first compiled language, instead of C++? I know it's likely harder to find answers in the Internet, but at the same time it looks easier, coming from Python and JS. If nim picks up pace in a few years and I already have a sense of it, it may be a good for prospects too.

I would recommend just vanilla C for maximum learning value. Learning about stack vs heap, pointers, memory allocation, etc. lets you learn more about what the computer is actually doing. It will make the computer seem less like a magic box, and you will see the things other languages abstract away.

Re: Nim 1.6.2

#152

Post by lenkite »

klibertp wrote: post #111
adamrt wrote: post #106

Earlier quoted context omitted.

Cool thanks for the info. Nim having selective imports solves any annoyances I would have. But you mentioned all the reasons it was ok in Nim. But the answer is always that the compiler knows. That isn’t why I personally dislike this type of import. I dislike it as a user. I find it super annoying not knowing where an identifier is coming from. I love having ‘fmt.Printf()’ instead of ‘Printf()’. Trivial example I kno…

There's a reason why wildcard/selective[1] imports are favored in Nim. It's because of the uniform function call syntax[2]. In short, this: split("a string", " ") is exactly the same thing as this: "a string".split(" ") `split` here is a normal function, not any kind of method. This means that you can chain normal functions as if they were methods on objects: "a string".split(" ").join("\n") now, if you imported modu…

C++ somewhat solved this using Koenig lookup https://en.wikipedia.org/wiki/Argument-dependent_name_lookup

Re: Nim 1.6.2

#153

Post by lenkite »

vlovich123 wrote: post #99
nicoburns wrote: post #85

Earlier quoted context omitted.

Consider either Rust or Go of you want something easier than C++, but that still has a large community and lots of learning resources.

Go yes. Rust? I wouldn’t say that Rust is easier although I may be biased with my long C/C++ background. The ownership model is a pretty complex thing to learn. I guess maybe if you Box a lot? It does have an easier on-ramp story for getting started/adding dependencies and that may be important for getting started.

As someone who properly learned C++ only some years ago, I can confidently state that Rust is harder to learn than C++. You can effectively code in C++ by learning only 20% of the language, but Rust has a far larger mental overhead to start coding. You have to do everything "The Rust Special Sauce Way".

Re: Nim 1.6.2

#154

Post by dflock »

jokoon wrote: post #30
posharma wrote: post #3

Genuinely curious - why should I care about Nim? There are already a plethora of general purpose languages (both compiled and interpreted). Also, is anyone using Nim today? What's the adoption?

If I would pick one, I would pick Zig. The language that is missing is a simple language that can work well with C or C++, compiles fast, is easy to read, has a good lib, etc. There are not enough non-GC languages that are statically compiled. I really, really want a pythonic, statically compiled language. I don't want templates, OOP, abstract stuff, just A C-like language, more readable, with good syntactic sugar. M…

Nim's GC is optional - you can switch it off and do manual memory management, if you want.

There's also no need to use any of the language features that you don't want?

Re: Nim 1.6.2

#155

Post by qalmakka »

beagle3 wrote: post #146
qalmakka wrote: post #70

Earlier quoted context omitted.

This is quite bad. Relying on uppercase/lowercase equivalences in a Unicode world is by definition a code smell, no matter if they force the comparison to be based on ASCII. This whole ordeal causes any sort of issue if Unicode letters are allowed, because they will pass through `toLowerAscii` untouched and it is bound to cause confusion or to force people to avoid using Unicode in identifiers altogether. Case insens…

Keywords are in English, and 99% of identifiers in all code I met are too, even when comments are in French or russian. Pascal and old basic (among other languages) have been case insensitive for decades, and that has not been a problem. In UI, you are by all means correct. But code is a formal language that happens to be expressed in Latin letters. APL is the only real language that doesn’t impose a western characte…

> Pascal and old basic (among other languages) have been case insensitive for decades

... because back then Unicode was still a pipe dream in the mind of some visionary. Everything used 8 bit encoding, and everyone assumed ASCII or at least something compatible with the 7 bit subset of ASCII.

Nowadays files are formatted in UTF-8, and most modern languages actually fully support UTF-8 identifiers. Nim itself supports UTF-8 "letters" in identifiers, and what is "upper case" or "lower case" 100% depends from the current locale. Restricting your case normalization logic to ASCII is __really bad__, because it basically means that non-Latin letters in identifiers won't be normalized, with possibly unexpected consequences.

> APL is the only real language that doesn’t impose a western character set.

- Rust uses UTF-8: https://doc.rust-lang.org/reference/identifiers.html

- Go allows any Unicode letter in identifiers: https://go.dev/ref/spec#Identifiers

- Swift is also famous for allowing you to use emojis in identifiers.

- Python supports non-ASCII identifiers: https://www.python.org/dev/peps/pep-3131/

And the list goes on. Even C++ can optionally support Unicode in identifiers (for instance, Clang and GCC do indeed support things like `constexpr auto 黒 { "lol" };`).

Re: Nim 1.6.2

#156

Post by beagle3 »

qalmakka wrote: post #155
beagle3 wrote: post #146

Earlier quoted context omitted.

Keywords are in English, and 99% of identifiers in all code I met are too, even when comments are in French or russian. Pascal and old basic (among other languages) have been case insensitive for decades, and that has not been a problem. In UI, you are by all means correct. But code is a formal language that happens to be expressed in Latin letters. APL is the only real language that doesn’t impose a western characte…

> Pascal and old basic (among other languages) have been case insensitive for decades ... because back then Unicode was still a pipe dream in the mind of some visionary. Everything used 8 bit encoding, and everyone assumed ASCII or at least something compatible with the 7 bit subset of ASCII. Nowadays files are formatted in UTF-8, and most modern languages actually fully support UTF-8 identifiers. Nim itself supports…

> ... because back then Unicode was still a pipe dream in the mind of some visionary. Everything used 8 bit encoding, and everyone assumed ASCII or at least something compatible with the 7 bit subset of ASCII.

They could still have been case sensitive (C was), so I don't understand how that's relevant to the idea that "case insensitivity is a problem".

> Rust, Go, Swift, Python

All of these languages impose ASCII for their keywords and directives. They allow you to use other characters for identifiers, but impose ascii in everything that has pre-defined semantics. Original APL is the only "real"/practical language that I'm aware of that gave up the "western centric view" of the world to the point that it doesn't have a single English keyword. (Brianfuck, etc. exist as well, but ....)

And they all impose a left-to-right reading order, which is just as western-centric. Arabic/Farsi/Hebrew go right-to-left, and there are languages that can also go top-to-bottom.

I think the outrage about "western centrism" is misguided. This is a formal system, and just like math, it reflects some history by using latin letters and left-to-right for the predefined symbols, and even preferred use of latin characters in identifiers.

> Nim itself supports UTF-8 "letters" in identifiers, and what is "upper case" or "lower case" 100% depends from the current locale.

If that's true, that may be a problem. I'll look into that, thanks for pointing out - from memory, Nim only folds the lower 7-bit by a 32 difference in ascii code, so it is well defined regardless of locale, but I'll check.

The whole idea of utf-8 in identifiers is a minefield, whether you fold case or not; e.g:

"Εхаｍрⅼе" and "Example" have no single letter in common (I chose them that way using[0]) and no language that allows utf-8 identifiers is going to warn you about that.

[0] https://www.irongeek.com/-attack-generator.php

Re: Nim 1.6.2

#157

Post by pietroppeter »

michaelcampbell wrote: post #137
sekao wrote: post #91

Earlier quoted context omitted.

I've been using nim for a few years. I wouldn't have made either design choice (i always do qualified imports, it's just a few extra characters of typing). That said, there is a reason these superficial things always come up in HN threads. If you haven't used a language before, syntax is the only thing you can talk about. It's the equivalent of low effort political banter and the dopamine hit you get from junk food o…

> If you haven't used a language before This just feels like gatekeeping. I like nim, I've used it, talked to Dom and the author a few times in chat, filed some small bug reports. But even if I hadn't, I'd still hate the case insensitivity; I'm an experienced developer and I don't need to have used a language to know I will like or dislike some aspect of it.

To me it feels more like gate opening: if you feel discouraged to try a language by this specific feature that you do not like, do not fear, come in and try it since as far as we know no people actually using the language suffered from this feature

Re: Nim 1.6.2

#158

Post by qalmakka »

beagle3 wrote: post #156
qalmakka wrote: post #155

Earlier quoted context omitted.

> Pascal and old basic (among other languages) have been case insensitive for decades ... because back then Unicode was still a pipe dream in the mind of some visionary. Everything used 8 bit encoding, and everyone assumed ASCII or at least something compatible with the 7 bit subset of ASCII. Nowadays files are formatted in UTF-8, and most modern languages actually fully support UTF-8 identifiers. Nim itself supports…

> ... because back then Unicode was still a pipe dream in the mind of some visionary. Everything used 8 bit encoding, and everyone assumed ASCII or at least something compatible with the 7 bit subset of ASCII. They could still have been case sensitive (C was), so I don't understand how that's relevant to the idea that "case insensitivity is a problem". > Rust, Go, Swift, Python All of these languages impose ASCII for…

> They could still have been case sensitive (C was), so I don't understand how that's relevant to the idea that "case insensitivity is a problem".

The point here is that case insensitivity is only a viable option if you severely limit the encoding allowed in whatever you are using - be it a programming language, filesystem, etc. If the encoding of your files is something is basically akin to ASCII or ISO-whatever (which was what BASIC and Pascal used back in the day) then case insensitivity is trivial and safe.

This whole thing breaks apart as soon as you enter a Unicode world and start accepting identifiers containing more than ASCII, and then the whole concept of "case insensitive" becomes obsolete and outright wrong.

The Unicode equivalent of "case insensitive" is Normalization [0] and it's a big heck of a minefield because it is defined depending on the locale in use. For instance, "FILE.TXT" and "file.txt" are to be considered equivalent under en_US, but not under tr_TR, where the lower case version of "FILE.TXT" is "fıle.txt" and the upper case version of "file.txt" is "FİLE.TXT". This means that normalizing strings can cause to unexpected results depending on the locale, which is especially problematic with filesystems (where a path may exist or not depending on the locale).

> Nim only folds the lower 7-bit by a 32 difference in ascii code, so it is well defined regardless of locale

yes, it is well defined but allowing the entirety of the Unicode letters also means that identifiers may contain glyphs from alphabets that have separate cases, chiefly Greek and Russian, or even accented letters such as `è` or `ö`. Case insensitivity instead of proper normalization makes them potentially confusing, and quite breaks the intent behind allowing Unicode identifiers by making non-US locales second class citizens.

IMHO it is arguably very confusing to non-English speakers that 'mela' is equivalent to 'MELA' but 'tè' isn't equivalent to 'TÈ' while 'Tè' is. It basically means you have to remember what letters are ASCII and what are not, which makes the whole "case insensitive" a potential source of confusion.

I think it is safe to say that in 2021 case insensitivity is an obsolete concept and an obstacle to proper internationalization. Case insensitivity only really works on legacy encodings and with the basic Latin alphabet, and you can rest assured it will be almost always improperly implemented anyway.

[0] https://en.wikipedia.org/wiki/Unicode_equivalence

Re: Nim 1.6.2

#159

Post by beagle3 »

qalmakka wrote: post #158
beagle3 wrote: post #156

Earlier quoted context omitted.

> ... because back then Unicode was still a pipe dream in the mind of some visionary. Everything used 8 bit encoding, and everyone assumed ASCII or at least something compatible with the 7 bit subset of ASCII. They could still have been case sensitive (C was), so I don't understand how that's relevant to the idea that "case insensitivity is a problem". > Rust, Go, Swift, Python All of these languages impose ASCII for…

> They could still have been case sensitive (C was), so I don't understand how that's relevant to the idea that "case insensitivity is a problem". The point here is that case insensitivity is only a viable option if you severely limit the encoding allowed in whatever you are using - be it a programming language, filesystem, etc. If the encoding of your files is something is basically akin to ASCII or ISO-whatever (wh…

I understand your point, but still disagree with it. As I see it, the real problem is unicode identifiers, as I demonstrated with "Example" above, and as follows from your demonstrations as well. Unlike the thousands of unicode characters, which are unlikely to be all familiar to any single person, and whose meaning and "conjugation" (casing, conjugation, pre-joined pairs, precomposed versions, etc) are different in different cultures -

The ascii case folding, as employed by Nim and Pascal refers to 26 specific well known characters. It's a non-issue.

Re: Nim 1.6.2

#160

Post by xigoi »

BiteCode_dev wrote: post #81
FridgeSeal wrote: post #72

Nim is everything Python and Go should be/want to be, as far as language features and semantics go (haha). It has their easy-to-learn properties, but has a better type system, the generics system and macros are arguably more useful, and more usable than what is offered in either language. It deserves far more attention than it currently gets.

I like Nim, and probably will learn it at some point. But no, Nim is not everything "python should/want to be". The name case insensitivity and the implicit imports on the global namespaces are perfect examples of stuff that are better in Python.

The global namespacing is what allows UFCS to work. You can rewrite parseInt("6") to "6".parseInt, but you can't rewrite strutils.parseInt("6") to anything.
Post reply on HN