(no title)
tc4v
|
1 year ago
Everyone need to stop comparing Nim with Python. Nim is closer to pascal, and the only thing it shares with Python is indentation base syntax. It doesn't have the expressivity and flexibility of Python. It's a nice language, but there is no good reason to compare it to Python.
cb321|1 year ago
I know both languages well and personally I consider Nim to be more expressive and syntactically flexible than Python although it is admittedly a difficult thing to quantify (which "more"/your comment framing implies). As just a few examples to make the abstract more concrete, in Nim you can add user-defined operators. So, with https://github.com/SciNim/Measuremancer I can have let x = a +- b or let y = c ± d construct uncertain numbers and then say y/x to get a ratio with uncertainty propagated. Function call syntax is more flexible (and arises more often than uncertain value algebras), e.g. "f(x)", "x.f", "f x", and even "f: x" all work for any kind of routine call. The need to be specific about let/var constancy & types is slightly more verbose but adds semantic/correctness value (e.g. first use). Just generally Nim feels like "much more choice" than Python to me. In fact, the leading whitespace itself can usually be side-stepped with extra ()s which is not true in Python.
I am speculating, but I think what might make you feel Python is more expressive may come from ecosystem size/support effects such as "3 external libraries exist that do what I want and I only need to learn the names of how to invoke whichever". So, you get to "express" what you "want" with less effort (logic/coding), but that's not really PLang expressivity. Python is more dynamic, but dynamism is a different aspect and often leads to performance woes.
Joker_vD|1 year ago
Anyhow, what are we allowed to compare with Python?
visarga|1 year ago
Assuming you need to use libraries for stuff, you choose the language that has the better ecosystem, more users and more StackOverflow support. As a company you choose the language that makes it easier to hire devs in, and move them around from a project to another. Only when execution performance trumps all other concerns you select the faster/stricter language, and only for mature projects not for a POC which might be thrown away soon.
So you use the strict/performant languages for mature, execution intensive code that doesn't need much library support and where you don't need to hire many devs.