3 ms·

I think languages that favor an "expressive" syntax, which favor using and building syntactic sugar and macros, suffer from a nicheness problem. That is they a

I think languages that favor an "expressive" syntax, which favor using and building syntactic sugar and macros, suffer from a nicheness problem. That is they are going to have to appeal to people who want that style of programming, and they have the additional hurdles of A) having more stuff one has to learn to use the language, B) dealing with a community of people who all want the magic from their previous language ecosystem imported into this new one, and C) the additional burden on libraries to come about which use these features. Note: I have not used Nim, so please take the above with a lump of salt.

TylerE 1y ago
I've used nim a bit and am going to push back quite hard on this. The core of the language is really quite consise. No harder of a mental overload than say go, or python. I'd also argue that high expressiveness actually allows you to avoid magic. The actual library implementations are rarely very scary. We're ahead of time compiled and type checked so it's not like some rails codebase where a clockwork goblin can just explode out of nowhere.
- liampulles 1y ago
  Thats good feedback, thank you.
  - TylerE 1y ago
    Macros in general are actually hugely anti-magical things because they let you push what normally be runtime checks into the compiler which not only means you get to fail fast but (if your language tooling is decent) means you actually get sane error messages instead of a traceback nested 1000 function calls deep or something.
- cb321 1y ago
  I would also push back (agreeing with @TylerE, but linking in this part of the subthread seems best). It all depends, but sometimes macros change the division of labor between library authors and library users so that they specifically have to learn less. For example, https://github.com/c-blake/cligen https://github.com/c-blake/cligen makes it so that you don't really have to learn an "API" to roll a nice CLI on top of a procedure. You just need to learn literally 2 or maybe 3 names: "cligen", "dispatch", and maybe "help={}". Everything else, you already know from knowing Nim basics (or even Python basics). (The dispatchGen macro itself is rather a monster of static introspection and code generation and not at all pedagogical -- mostly from filling like 100 user requests on closed issues.) It's just important to keep in mind that library / framework authors, library / framework users, and final end users are not all the same person or even type of person. Metaprogramming enables the first group the most, but can deliver benefits to the latter two groups by easing their lives quite a bit. This is easy to lose track of in a niche language like Nim where all 3 groups might well be the same human for most of the life of some project. This partly also relates to how much of a "full stack debugger (of either correctness or performance or both)" personality one has. Then there are even more layers -- like all the levels in the language / compiler itself down to the CPU and beyond (such as "u-code" & micro-architectural resource sharing). What macros mostly do is enable fluid, simple syntax for things either too rare, too niche, too unanticipated or too disagreed upon to be in "the main language", whatever that is. As a shibboleth (or marker for group inclusion), the existence of this expressivity selects for programmers who want to fix rare, niche, unanticipated or disagreed upon things, and these people can be even harder "cats to herd". Nim has other very flexible features - such as the rare "user-defined operators" that enable very nice looking custom syntax. But you can also SCOPE their use very simply. E.g., put their definitions inside a template so that you can say `ptrArithmeticNow: expression` and only have pointer arithmetic within `expression` (maybe with +! to look a little diff from ordinary arithmetic), and (ptrArithmetic itself can be scoped within a module name). It also has even more powerful (and more rare) term-rewriting macros, used most commonly in Lisp systems, perhaps doing computer algebra.

TylerE 1y ago

I've used nim a bit and am going to push back quite hard on this. The core of the language is really quite consise. No harder of a mental overload than say go, or python. I'd also argue that high expressiveness actually allows you to avoid magic. The actual library implementations are rarely very scary. We're ahead of time compiled and type checked so it's not like some rails codebase where a clockwork goblin can just explode out of nowhere.

liampulles 1y ago
Thats good feedback, thank you.
- TylerE 1y ago
  Macros in general are actually hugely anti-magical things because they let you push what normally be runtime checks into the compiler which not only means you get to fail fast but (if your language tooling is decent) means you actually get sane error messages instead of a traceback nested 1000 function calls deep or something.
cb321 1y ago
I would also push back (agreeing with @TylerE, but linking in this part of the subthread seems best). It all depends, but sometimes macros change the division of labor between library authors and library users so that they specifically have to learn less. For example, https://github.com/c-blake/cligen https://github.com/c-blake/cligen makes it so that you don't really have to learn an "API" to roll a nice CLI on top of a procedure. You just need to learn literally 2 or maybe 3 names: "cligen", "dispatch", and maybe "help={}". Everything else, you already know from knowing Nim basics (or even Python basics). (The dispatchGen macro itself is rather a monster of static introspection and code generation and not at all pedagogical -- mostly from filling like 100 user requests on closed issues.) It's just important to keep in mind that library / framework authors, library / framework users, and final end users are not all the same person or even type of person. Metaprogramming enables the first group the most, but can deliver benefits to the latter two groups by easing their lives quite a bit. This is easy to lose track of in a niche language like Nim where all 3 groups might well be the same human for most of the life of some project. This partly also relates to how much of a "full stack debugger (of either correctness or performance or both)" personality one has. Then there are even more layers -- like all the levels in the language / compiler itself down to the CPU and beyond (such as "u-code" & micro-architectural resource sharing). What macros mostly do is enable fluid, simple syntax for things either too rare, too niche, too unanticipated or too disagreed upon to be in "the main language", whatever that is. As a shibboleth (or marker for group inclusion), the existence of this expressivity selects for programmers who want to fix rare, niche, unanticipated or disagreed upon things, and these people can be even harder "cats to herd". Nim has other very flexible features - such as the rare "user-defined operators" that enable very nice looking custom syntax. But you can also SCOPE their use very simply. E.g., put their definitions inside a template so that you can say `ptrArithmeticNow: expression` and only have pointer arithmetic within `expression` (maybe with +! to look a little diff from ordinary arithmetic), and (ptrArithmetic itself can be scoped within a module name). It also has even more powerful (and more rare) term-rewriting macros, used most commonly in Lisp systems, perhaps doing computer algebra.