4 ms·

If you find it easier, you can do the simpler "build a compile-time string and inject it" D-like metaprogramming in Nim with `macros.parseStmt` or `parseExpr`.

by cb321 4y ago

If you find it easier, you can do the simpler "build a compile-time string and inject it" D-like metaprogramming in Nim with `macros.parseStmt` or `parseExpr`. And just `template` in Nim can go a long ways without all the mucking about with strings. Nim is choice - in many dimensions. Many things that are built into languages even as flexible as D remain not hard-coded in Nim. E.g., it could be different now, but last I checked, D has hard-coded Associative Arrays. In Nim you can give any user type (e.g. B-Trees) the special syntax (no real meta-programming required..just generics). Also user-defined operators. Etc. But, yeah - you need to be familiar with a base language whenever you do any meta-programming anywhere. Anyway, if you ever give Nim a try again, maybe `parseStmt` can be your gateway drug. ;-) (But I recommend starting with generics & template...)

germandiago 4y ago
I do like Nim also. The only problems are the usual ones plus one: - IDEs ecosystem (both for D and Nim) - libraries Additionally, Nim departs quite a bit from C/C++ to look more than Python. As nice as it looks, Nim is not Python, it has a ton more qualifiers and others. It is fast, but it departs from C/C++ a lot and there is much more than it is apparent to relearn. D's path is smoother in that sense. Also, C/C++ compatibility is a problem. Yes, I know you could say Nim is very compatible with C. But at the end of the day is a considerable investment of extra work. If it does not work, if it works half-way even if compatible in theory. I have been there many times, I code hybrid in many occassions with scripting layers that are supposed to work, and at the end, there is extra work...
- cb321 4y ago
  Sorting out your edit/IDE/lib situation & re-learning is part of any PL switch in my experience (& just varies). Trade offs abound in most things. D is undeniably syntactically closer to C if that is the priority. I knew people in the initial Java era who insisted their next PL had to look like C. I know others who prefer Pythonic brevity and Nim is even more brief & to the point in many ways. Compatibility-wise, Nim can also just `emit` C/C++/Javascript (like D|Nim can just emit inline assembly) - arguably max compatibility that can even work with arbitrary non-portable backend compiler pragmas, `__int128` extensions, etc. OTOH, that also ties it to limitations of backends. Possibly relevant is https://github.com/nim-lang/c2nim https://github.com/nim-lang/c2nim & https://github.com/PMunch/futhark https://github.com/PMunch/futhark & the rather old/probably partly stale in both columns https://github.com/timotheecour/D_vs_nim https://github.com/timotheecour/D_vs_nim . There are many choices in Nim. Sometimes https://en.wikipedia.org/wiki/The_Paradox_of_Choice https://en.wikipedia.org/wiki/The_Paradox_of_Choice can be a real problem - in both software or in life - and at many, many levels. :) I am not trying to challenge your own priorities or push choices on you, but to add information others may be unaware of.
  - germandiago 4y ago
    > I am not trying to challenge your own priorities or push choices on you, but to add information others may be unaware of. Not at all. I enjoy researching this topic. Thank you!

by cb321 4y ago

germandiago 4y ago

I do like Nim also. The only problems are the usual ones plus one: - IDEs ecosystem (both for D and Nim) - libraries Additionally, Nim departs quite a bit from C/C++ to look more than Python. As nice as it looks, Nim is not Python, it has a ton more qualifiers and others. It is fast, but it departs from C/C++ a lot and there is much more than it is apparent to relearn. D's path is smoother in that sense. Also, C/C++ compatibility is a problem. Yes, I know you could say Nim is very compatible with C. But at the end of the day is a considerable investment of extra work. If it does not work, if it works half-way even if compatible in theory. I have been there many times, I code hybrid in many occassions with scripting layers that are supposed to work, and at the end, there is extra work...

cb321 4y ago
Sorting out your edit/IDE/lib situation & re-learning is part of any PL switch in my experience (& just varies). Trade offs abound in most things. D is undeniably syntactically closer to C if that is the priority. I knew people in the initial Java era who insisted their next PL had to look like C. I know others who prefer Pythonic brevity and Nim is even more brief & to the point in many ways. Compatibility-wise, Nim can also just `emit` C/C++/Javascript (like D|Nim can just emit inline assembly) - arguably max compatibility that can even work with arbitrary non-portable backend compiler pragmas, `__int128` extensions, etc. OTOH, that also ties it to limitations of backends. Possibly relevant is https://github.com/nim-lang/c2nim https://github.com/nim-lang/c2nim & https://github.com/PMunch/futhark https://github.com/PMunch/futhark & the rather old/probably partly stale in both columns https://github.com/timotheecour/D_vs_nim https://github.com/timotheecour/D_vs_nim . There are many choices in Nim. Sometimes https://en.wikipedia.org/wiki/The_Paradox_of_Choice https://en.wikipedia.org/wiki/The_Paradox_of_Choice can be a real problem - in both software or in life - and at many, many levels. :) I am not trying to challenge your own priorities or push choices on you, but to add information others may be unaware of.
- germandiago 4y ago
  > I am not trying to challenge your own priorities or push choices on you, but to add information others may be unaware of. Not at all. I enjoy researching this topic. Thank you!