7 ms·
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 clo
by adenozine 5y ago
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.
- michaelsbradley 5y agoCan 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.
- adenozine 5y agoSure. 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.
- xigoi 5y agoThe 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…
- adenozine 5y agoYeah, I guess you're right.
- memco 5y agoDoes Nim have comprehensions? Even if you're striving for equivalent signatures the inner body of the function can be expressed as a comprehension in Python: T = TypeVar("T") def odd_numbers(a: Iterable[T]) -> Iterator[T]: yield from (n for n in a if n % 2 == 1)
- michaelsbradley 5y agoSee collect: https://nim-lang.org/docs/sugar.html#collect.m%2Cuntyped%2Cuntyped https://nim-lang.org/docs/sugar.html#collect.m%2Cuntyped%2Cu...
- xigoi 5y agoUnfortunately, Nim doesn't have `yield from`, which would make a comprehension useless here. That's one of the things I'm missing in the language.
- planetis 5y agoThat's an obscure/not optimal way to write this code though. I mean why would you use LIST comprehension if you are going to yield each element.
- nerdponx 5y agoIt's not list comprehension, it's generator comprehension, which is lazily computed. However it's still an unnecessary layer of iteration, when you could just return the comprehension instead.
- nerdponx 5y agoI think the "full" version is easier to read: T = TypeVar("T") def odd_numbers(nums: Iterable[T]) -> Iterator[T]: for n in nums: if n % 2 == 1: yield n Although yet another option is to just return the generator instead of immediately yielding from it: T = TypeVar("T") def odd_numbers(nums: Iterable[T]) -> Iterator[T]: return (n for n in a if n % 2 == 1)
- xioren00 5y agoStatic typing aside, I don't find it any more verbose (noisy) than Python. In fact I find it strikes a perfect balance.
- sp33der89 5y agoDo you have examples of what you mean with unnecessarily noise? For me it's the JSON operators. `@[]` for sequences could also be a thing, but it's really minor(for me).
- adsharma 5y agoIf 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.
- khaledh 5y agoI 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.
- osmarks 5y agoIt matches identifiers style-insensitively so you can actually use other conventions if you want. Although the online docs are still camelcased.
- michaelsbradley 5y agoNim is partially case-insensitive: https://nim-lang.github.io/Nim/manual.html#lexical-analysis-identifier-equality 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.
- khaledh 5y agoGood 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.
- planetis 5y ago--styleCheck:on to enforce the style every identifier is declared in your code base.
- 5y ago
- WesolyKubeczek 5y agoI 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.
- michaelsbradley 5y ago> you need to import corresponding modules everywhere It's a good practice to re-export "all modules whose types appear in public symbols of the current module". For that and other good advice, see The Status Nim style guide: https://status-im.github.io/nim-style-guide/03_language.html#import-export https://status-im.github.io/nim-style-guide/03_language.html...
- Nimitz14 5y agoI agree. The syntax is the main reason I don't use it.
- mrweasel 5y agoCompletely fair, syntax is something that resonate differently from person to person. I love the idea of Rust, it’s speed, capabilities, it’s politics and it’s independence, but I cannot stand it’s syntax. That’s fine, I can use other languages and it doesn’t take anything away from Rust or the people who love the syntax.
- Aardappel 5y agoIf you want a statically typed language with Python-alike syntax but Nim is too "noisy" for you, then Lobster (http://strlen.com/lobster/ http://strlen.com/lobster/) is likely spot-on.