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

Nim: Scripting Ease in a Compiled Language

junglecoder.com

Post reply on HN
Print view View original

81–90 of 169 posts

Re: Nim: Scripting Ease in a Compiled Language

#81

Post by Insanity »

petre wrote: post #76
Stratoscope wrote: post #35

Earlier quoted context omitted.

It's not just case insensitive, it's underscore insensitive. So MyNimName, mynimname, MY_NIM_NAME, My_Nim_Name, __MYNIM___name_, and any other variation you can think of are all the same name! Most search tools have the option of case sensitive or insensitive search, but a search that does that and ignores underscores? Not too many of those outside the Nim world. An interesting contrast is Nim's policy on tabs and sp…

Banned tabs? Good to know. From now on I'll just ignore everything about Nim. I will also applaud the Go team's decision to include a formatter instead of such nightmare restrictions.

Gofmt is pretty great, I really hope more languages take such an opinionated approach!

Re: Nim: Scripting Ease in a Compiled Language

#82

Post by Insanity »

m45t3r wrote: post #41
ac29 wrote: post #24

Earlier quoted context omitted.

As an admittedly amateur programmer, I think the reasoning is solid. Its difficult to read and understand code that does things like myvalue = myValue. I think they made the right tradeoff, in that value != Value (the case of the first letter is used), so if you really need to have to values with the same name, you can still do it. As an aside, is there some reason that using the same identifier with different cases…

> As an aside, is there some reason that using the same identifier with different cases is desirable? It is mostly for conventions, however different cases are generally used to represent different things. For example, in Python: - ALL_CAPS: global variables - PascalCase: for classes, and now that Python has typing annotations, types - snake_case: everything else, from variables to function/method names (This is not…

You get used to the capitalisation. In python the _ prefix threw me off at first as well, but it just kind of grows on you I suppose.

Re: Nim: Scripting Ease in a Compiled Language

#83

Post by derriz »

ac29 wrote: post #24
nphard85 wrote: post #18

One thing I find annoying about Nim is the case insensitivity [0]. There was no strong reason for this "feature" and literally no mainstream language does it. Moreover it makes code search a pain. [0] https://nim-lang.org/docs/manual.html#lexical-analysis-ident...

As an admittedly amateur programmer, I think the reasoning is solid. Its difficult to read and understand code that does things like myvalue = myValue. I think they made the right tradeoff, in that value != Value (the case of the first letter is used), so if you really need to have to values with the same name, you can still do it. As an aside, is there some reason that using the same identifier with different cases…

But you’re not fully solving the problem of devs using inappropriate names and you make using popular tools like text editors, grep, ctags, etc more difficult to use effectively. I mean how do you stop devs picking easily confused pairs of identifiers like “xxxxxxxx” and “xxxxxxxx” for example?

Feels like a poor design decision to me based on cost/benefit of user ergonomics.

Re: Nim: Scripting Ease in a Compiled Language

#84

Post by jdc »

Seb-C wrote: post #49
Stratoscope wrote: post #35

Earlier quoted context omitted.

It's not just case insensitive, it's underscore insensitive. So MyNimName, mynimname, MY_NIM_NAME, My_Nim_Name, __MYNIM___name_, and any other variation you can think of are all the same name! Most search tools have the option of case sensitive or insensitive search, but a search that does that and ignores underscores? Not too many of those outside the Nim world. An interesting contrast is Nim's policy on tabs and sp…

Sounds like a nightmare.

It's a misfeature, but let's not to be melodramatic.. just use a formatter.

Re: Nim: Scripting Ease in a Compiled Language

#85

Post by andybak »

lone_haxx0r wrote: post #27

Nim's syntax is everything I hate in a language. It's not bad, objectively speaking, but its design opinions are the polar opposite of mine.

I'm half and half. I adore syntactic whitespace and it makes me sad that it hasn't become more prevalent.

However the flexible identifier rules bother me no end. But as soon as my editor of choice handles it transparently then I guess I might come round.

Re: Nim: Scripting Ease in a Compiled Language

#86

Post by jamil7 »

treeform wrote: post #11
dglass wrote: post #3

Is there anyone using Nim either in side projects or in production that can comment on how they like it? I keep hearing about Nim and it sounds interesting, but I'm not sure I have the mental capacity right now to do a deep dive into the language and build something with it. I'd like to at some point soon though.

I use Nim in production. I been using it for more than 1 year in production. I like it. For me, it started out as a faster python that prevents typos. But it has really grown on me. I really like that I can share libs on server (compiling to c) and client side (compiling to plain javascript). Basically any C library is also a Nim library with a tiny wrapper. That's a huge ecosystem! I also like how Nim can integrate…

I have some code duplication between android, iOS and a webapp / PWA. How realistic is it to look at something like nim for codesharing?

Re: Nim: Scripting Ease in a Compiled Language

#88

Post by jstimpfle »

Jefro118 wrote: post #14

Shameless plug - I interviewed Andreas, the creator of Nim, about his philosophy and design choices here: https://sourcesort.com/interview/andreas-rumpf-on-creating-a... Might be an interesting read for people who are thinking about using Nim and wondering how it compares to the C family, Python, Go, etc.

> The C-family of languages has quirky syntax, grossly unsafe semantics and slow compilers but is overall quite flexible to use. This is mostly thanks to its meta-programming features like the preprocessor and, in C++'s case, to templates.

> The Pascal family of languages has an unpleasant, overly verbose syntax but fast compilers. It also has stronger type systems and extensive runtime checks make it far safer to use. However, it lacks most of the metaprogramming capabilities that I wanted to see in a language.

While Nim somehow is not appealing to me, this absolutely nails it.

Re: Nim: Scripting Ease in a Compiled Language

#89

Post by ploika »

staticassertion wrote: post #29

How do data scientists feel about Nim? It feels very pythony, but way faster - could be a really cool language for them, similar to what Julia is trying to be. Curious if anyone in a DS role has tried it out. I'm certainly tempted to try it out, I'm sure I'm losing lots of performance in parts of my analytics pipeline due to Python being garbage slow.

The lack of mature libraries in the style of pandas, sklearn or the tidyverse, and the lack of a stable REPL is a major drawback for "production" data science. On the other hand though I've had fun playing with it in a personal capacity precisely because of the rough edges.

If I want to fit a particular kind of model I'll probably have to roll my own, meaning I have to be familiar with what the algorithm is doing and why, rather than just importing something straight from sklearn.

I also need to pay more attention to the code as I'm writing it instead of lazily debugging by trial and error in the REPL like I can with Python.

Basically, I wouldn't recommend it at work, but it's been fun and useful at home.

Re: Nim: Scripting Ease in a Compiled Language

#90

Post by enriquto »

ac29 wrote: post #24
nphard85 wrote: post #18

One thing I find annoying about Nim is the case insensitivity [0]. There was no strong reason for this "feature" and literally no mainstream language does it. Moreover it makes code search a pain. [0] https://nim-lang.org/docs/manual.html#lexical-analysis-ident...

As an admittedly amateur programmer, I think the reasoning is solid. Its difficult to read and understand code that does things like myvalue = myValue. I think they made the right tradeoff, in that value != Value (the case of the first letter is used), so if you really need to have to values with the same name, you can still do it. As an aside, is there some reason that using the same identifier with different cases…

> As an aside, is there some reason that using the same identifier with different cases is desirable?

I do it all the time, in numerical code. If you have two pairs of points, for example, it is very natural to name them "a,A,b,B"

Post reply on HN