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

Nim 2.0 thoughts

forum.nim-lang.org

Post reply on HN
Print view View original

11–20 of 150 posts

Re: Nim 2.0 thoughts

#11

Post by adenozine »

michaelsbradley wrote: post #6
adenozine wrote: post #4

Potentially unpopular opinion, please go easy on me, I'm a python lover: I find a lot of Nim syntax just unnecessarily noisy. I wish that it had stuck much closer to Python syntax. I'm really excited about Nim, don't get me wrong. I like Araq, he's got a real hacker spirit not oft found at the head of big projects. Anyhow. I'm sure the experts in that topic will sort it all out. ORC is wildly impressive all around.

Can you give an example of noisy syntax? Is it in relation to the type system? I'm writing Nim every day recently; I haven't experienced it being noisy, but I also don't have extensive or recent experience with Python.

Sure.

I'm on phone, so hopefully this paste doesn't look awful, but it's right from the website homepage

iterator oddNumbers[Idx, T](a: array[Idx, T]): T = for x in a: if x mod 2 == 1: yield x

The three different sets of brackets, the mixed : and =, it just seems inelegant to me.

I don't really know how I'd improve it, so it's just pointless, ignorant complaining on my part. Pay me little mind.

Re: Nim 2.0 thoughts

#12

Post by WesolyKubeczek »

adenozine wrote: post #4

Potentially unpopular opinion, please go easy on me, I'm a python lover: I find a lot of Nim syntax just unnecessarily noisy. I wish that it had stuck much closer to Python syntax. I'm really excited about Nim, don't get me wrong. I like Araq, he's got a real hacker spirit not oft found at the head of big projects. Anyhow. I'm sure the experts in that topic will sort it all out. ORC is wildly impressive all around.

I can't get used to the fact that for builtin types grow methods, you need to import corresponding modules everywhere.

You import module X, which gets you objects as defined in the module Y. To use methods defined for that type, you need to import Y yourself. Python, of course, by virtue of binding objects to methods, doesn't need it.

There are some more namespacing quirks that may require one to give up on that sweet syntactic sugar to disambiguate things (two unrelated modules defining methods on a single type, with the same signature but different behaviors, and you need both modules imported for some reason?), but this is, again, something one would have to get used to. It's not a different world like Rust or Prolog.

It's not a complete showstopper, just something I keep bumping my head into now and then.

Re: Nim 2.0 thoughts

#13

Post by osmarks »

khaledh wrote: post #10
adenozine wrote: post #4

Potentially unpopular opinion, please go easy on me, I'm a python lover: I find a lot of Nim syntax just unnecessarily noisy. I wish that it had stuck much closer to Python syntax. I'm really excited about Nim, don't get me wrong. I like Araq, he's got a real hacker spirit not oft found at the head of big projects. Anyhow. I'm sure the experts in that topic will sort it all out. ORC is wildly impressive all around.

I love python as well, and I literally just started exploring Nim yesterday, so this is very timely. The one thing that stuck out to me like a sore thumb is the camelCase convention. I know it's a minor thing (and a personal preference), but I'm a bit biased against languages that use camelCase (Java, JavaScript, etc). There's something uneasy about it IMHO.

It matches identifiers style-insensitively so you can actually use other conventions if you want. Although the online docs are still camelcased.

Re: Nim 2.0 thoughts

#14

Post by planetis »

I just love the new numeric literals syntax:

  proc `'i128`(n: string): Int128 = parseDecimalInt128(n)
  assert fib(184) == 127127879743834334146972278486287885163'i128
It's so sexy!

Re: Nim 2.0 thoughts

#15

Post by michaelsbradley »

khaledh wrote: post #10
adenozine wrote: post #4

Potentially unpopular opinion, please go easy on me, I'm a python lover: I find a lot of Nim syntax just unnecessarily noisy. I wish that it had stuck much closer to Python syntax. I'm really excited about Nim, don't get me wrong. I like Araq, he's got a real hacker spirit not oft found at the head of big projects. Anyhow. I'm sure the experts in that topic will sort it all out. ORC is wildly impressive all around.

I love python as well, and I literally just started exploring Nim yesterday, so this is very timely. The one thing that stuck out to me like a sore thumb is the camelCase convention. I know it's a minor thing (and a personal preference), but I'm a bit biased against languages that use camelCase (Java, JavaScript, etc). There's something uneasy about it IMHO.

Nim is partially case-insensitive:

https://nim-lang.github.io/Nim/manual.html#lexical-analysis-...

my_foo, myfoo, and myFoo are interchangeable. MyFoo is different because the first letter is capitalized.

If it's not clear, what I mean is that if you've imported a module that exports myFoo, you can refer to it in your code as my_foo, if you prefer.

Some people love this aspect of Nim, others loathe it. I don't have strong feelings about it, though one has to be mindful of it when searching through a codebase with e.g. the_silver_searcher.

Re: Nim 2.0 thoughts

#16

Post by xigoi »

adsharma wrote: post #9
adenozine wrote: post #4

Potentially unpopular opinion, please go easy on me, I'm a python lover: I find a lot of Nim syntax just unnecessarily noisy. I wish that it had stuck much closer to Python syntax. I'm really excited about Nim, don't get me wrong. I like Araq, he's got a real hacker spirit not oft found at the head of big projects. Anyhow. I'm sure the experts in that topic will sort it all out. ORC is wildly impressive all around.

If you prefer python syntax, you can code in python and transpile? Py2many supports nim. I wonder if there is sufficient interest in having a python stdlib compatible library for nim.

https://github.com/Yardanico/nimpylib

Re: Nim 2.0 thoughts

#18

Post by sp33der89 »

khaledh wrote: post #10
adenozine wrote: post #4

Potentially unpopular opinion, please go easy on me, I'm a python lover: I find a lot of Nim syntax just unnecessarily noisy. I wish that it had stuck much closer to Python syntax. I'm really excited about Nim, don't get me wrong. I like Araq, he's got a real hacker spirit not oft found at the head of big projects. Anyhow. I'm sure the experts in that topic will sort it all out. ORC is wildly impressive all around.

I love python as well, and I literally just started exploring Nim yesterday, so this is very timely. The one thing that stuck out to me like a sore thumb is the camelCase convention. I know it's a minor thing (and a personal preference), but I'm a bit biased against languages that use camelCase (Java, JavaScript, etc). There's something uneasy about it IMHO.

Even though it's not according to the styleguide, you can just use snake_case whenever and wherever you want, consumers of your libraries or other way around will never notice!

Re: Nim 2.0 thoughts

#19

Post by khaledh »

michaelsbradley wrote: post #15
khaledh wrote: post #10

Earlier quoted context omitted.

I love python as well, and I literally just started exploring Nim yesterday, so this is very timely. The one thing that stuck out to me like a sore thumb is the camelCase convention. I know it's a minor thing (and a personal preference), but I'm a bit biased against languages that use camelCase (Java, JavaScript, etc). There's something uneasy about it IMHO.

Nim is partially case-insensitive: https://nim-lang.github.io/Nim/manual.html#lexical-analysis-... my_foo, myfoo, and myFoo are interchangeable. MyFoo is different because the first letter is capitalized. If it's not clear, what I mean is that if you've imported a module that exports myFoo, you can refer to it in your code as my_foo, if you prefer. Some people love this aspect of Nim, others loathe it. I don't have s…

Good to know. Although I'd argue that this is something that I'd count _against_ the language. I'm also biased against languages that allow you to do the same thing in multiple ways (hint: Scala). Code bases tend to vary according to the team's own conventions, so you have to keep adapting to whatever code base you happen to be reading.

Re: Nim 2.0 thoughts

#20

Post by xigoi »

adenozine wrote: post #11
michaelsbradley wrote: post #6

Earlier quoted context omitted.

Can you give an example of noisy syntax? Is it in relation to the type system? I'm writing Nim every day recently; I haven't experienced it being noisy, but I also don't have extensive or recent experience with Python.

Sure. I'm on phone, so hopefully this paste doesn't look awful, but it's right from the website homepage iterator oddNumbers[Idx, T](a: array[Idx, T]): T = for x in a: if x mod 2 == 1: yield x The three different sets of brackets, the mixed : and =, it just seems inelegant to me. I don't really know how I'd improve it, so it's just pointless, ignorant complaining on my part. Pay me little mind.

The equivalent in Python would be:

  T = TypeVar("T")
  def odd_numbers(a: list[T]) -> Iterator[T]:
      # implementation
I don't really find that less verbose, in terms of brackets and symbols…
Post reply on HN