4 ms·

I played with Nim a little bit, loving it for a while, and I quickly ran into the same issue I had with Julia, which was that I had trouble staying in the basic

I played with Nim a little bit, loving it for a while, and I quickly ran into the same issue I had with Julia, which was that I had trouble staying in the basic language. Both Nim and Julia's documentation, and many modules/imports/includes/whatever of those languages, immediately jump to "holy shit we have macros! Importing this module changes the syntax! Isn't that awesome?!" And I'm like, no, it's not awesome. New syntax, new syntactic sugar, etc. is a learning curve every time for me. I'm often skeptical of operator overloading in C++ and python, so macro crazy languages are even worse. I feel like I must be in the minority, or I haven't hit that programming nirvana.

sergiotapia 6y ago
I totally agree with you, that's why I started Nimlings to help new Nim engineers get familiar with the language. Let's face it, you probably won't need macros WELL into your Nim lifecycle. https://github.com/sergiotapia/nimlings https://github.com/sergiotapia/nimlings
planetis 6y ago
...except that macros don't change the syntax of the language! They just offer convenience on top of it, most common example is the `=>` lambda operator from the `sugar` module. I do agree, that the pattern matching macro presented in the article is a bit hard to get used to, but you don't have to, if you don't like pattern matching. And of course there are plenty of alternatives available as well, the simplest one imo is https://github.com/andreaferretti/patty https://github.com/andreaferretti/patty
nimmer 6y ago
In all non-trivial codebases you have to learn how other people implemented something. It can be easy or take time depending on the how well it's written. Macros are not different than functions: one can create readable or crazy spaghetti code in any language. If you find a codebase full of unreadable macros it's not different than any other type of bad code: stay away from it or simplify it. Personally, I'm yet to find a macro that makes the code less readable or more difficult to understand.
dukeyukey 6y ago
Yes! I'm constantly seeing people enthuse about how awesome macros are, and done well they're great, but I don't want every library I use to have a whole new set of syntax.
- haxscramper 6y ago
  While I don't claim to have a comprehensive numbers, I did a quick `rg` on a full clone of nimble package list, and found that macros constitute approximately 0.4% of all definitions (functions, procedures, templates, methods). proc: 401673 macro: 1869 template: 16255 func: 8746 converter: 3538 iterator: 1833 method: 9025 You would be surprised how much can be accomplished just using simpler language constructs - even for the complex operations. Manual for example advises to use the least powerful construct for the job https://nim-lang.org/docs/manual.html#macros-caseminusof-macro https://nim-lang.org/docs/manual.html#macros-caseminusof-mac... > Style note: For code readability, it is the best idea to use the least powerful programming construct that still suffices. So the "check list" is: > Use an ordinary proc/iterator, if possible. > Else: Use a generic proc/iterator, if possible. > Else: Use a template, if possible. > Else: Use a macro. Also - notable portion of the commonly used macros is for embedded DSLs that in other languages would require you to use a separate build step with some external tool, or give way to horrible clutches like operator overloading-based DSL. Note that I did the full clone several months back, and it is missing around two hundred packages that were added in this time, but I doubt it changes numbers greatly.
  - salamanderman 6y ago
    While that may be true, my experience was that you immediately see folks assuming you're using the 'sugar' macros, and then I went to do something with JSON and that was macros as well. Honestly curious, while .4% of all definitions are macros, how many things are using those macros? That's probably hard to tell, but I feel like that would be closer to representing the need for learning all the macros. I hear you, though, that I might have been nearing the end of the steep part of the learning curve.
    - 6y ago

sergiotapia 6y ago

I totally agree with you, that's why I started Nimlings to help new Nim engineers get familiar with the language. Let's face it, you probably won't need macros WELL into your Nim lifecycle. https://github.com/sergiotapia/nimlings https://github.com/sergiotapia/nimlings

planetis 6y ago

...except that macros don't change the syntax of the language! They just offer convenience on top of it, most common example is the `=>` lambda operator from the `sugar` module. I do agree, that the pattern matching macro presented in the article is a bit hard to get used to, but you don't have to, if you don't like pattern matching. And of course there are plenty of alternatives available as well, the simplest one imo is https://github.com/andreaferretti/patty https://github.com/andreaferretti/patty

nimmer 6y ago

In all non-trivial codebases you have to learn how other people implemented something. It can be easy or take time depending on the how well it's written. Macros are not different than functions: one can create readable or crazy spaghetti code in any language. If you find a codebase full of unreadable macros it's not different than any other type of bad code: stay away from it or simplify it. Personally, I'm yet to find a macro that makes the code less readable or more difficult to understand.

dukeyukey 6y ago

Yes! I'm constantly seeing people enthuse about how awesome macros are, and done well they're great, but I don't want every library I use to have a whole new set of syntax.

haxscramper 6y ago
While I don't claim to have a comprehensive numbers, I did a quick `rg` on a full clone of nimble package list, and found that macros constitute approximately 0.4% of all definitions (functions, procedures, templates, methods). proc: 401673 macro: 1869 template: 16255 func: 8746 converter: 3538 iterator: 1833 method: 9025 You would be surprised how much can be accomplished just using simpler language constructs - even for the complex operations. Manual for example advises to use the least powerful construct for the job https://nim-lang.org/docs/manual.html#macros-caseminusof-macro https://nim-lang.org/docs/manual.html#macros-caseminusof-mac... > Style note: For code readability, it is the best idea to use the least powerful programming construct that still suffices. So the "check list" is: > Use an ordinary proc/iterator, if possible. > Else: Use a generic proc/iterator, if possible. > Else: Use a template, if possible. > Else: Use a macro. Also - notable portion of the commonly used macros is for embedded DSLs that in other languages would require you to use a separate build step with some external tool, or give way to horrible clutches like operator overloading-based DSL. Note that I did the full clone several months back, and it is missing around two hundred packages that were added in this time, but I doubt it changes numbers greatly.
- salamanderman 6y ago
  While that may be true, my experience was that you immediately see folks assuming you're using the 'sugar' macros, and then I went to do something with JSON and that was macros as well. Honestly curious, while .4% of all definitions are macros, how many things are using those macros? That's probably hard to tell, but I feel like that would be closer to representing the need for learning all the macros. I hear you, though, that I might have been nearing the end of the steep part of the learning curve.
  - 6y ago