|
|
|
|
|
|
by jamesgeck0
1829 days ago
|
|
|
My experience learning Nim is that it's more fiddly and less elegant than Python. The OOP syntax in particular could be streamlined a lot (the Nim by Example macro code demonstrates this). In addition to learning the basic syntax, there are a fair amount of features implemented as pragmas; there's some important things like {.base.} mixed into this sort of junk drawer of stuff. They often felt sort of like an afterthought to me. |
|
|
Nim intentionally gives you very spartan objects. It is by no means an OOP-first or even an OOP-heavy language. The object type is little more than a storage container for named values, and should be treated as such. There is no magic like what you get with Python objects.
I've said it before, but the frequently thrown around, "it's just like Python but typed and compiled" has probably been a net negative for the language. It is syntatically similar, but once you get beyond those initial appearances it is a very, very different beast. So if you try to write Pythonesque Nim, you're not going to have a good time with it. It's no different than trying to write JavaScript like Python - they're just different languages that don't work the same way.
The macro chapter in Nim by Example is a good tutorial for writing a macro, but I don't know that it's a big improvement. For the most part, it just allows you to remove the `self: ObjectType` from methods that act on an object. I guess that's okay? But even Python makes you include the `self` in class methods.