I like the concept and I particularly like the way I feel nim shepherds me:
* I very rarely need to come up with a name for a function or other identifier. The correct name can be reused for multiple use cases thanks to the type system and prox overloading.
* to spend a little time designing the interface before jumping in the code
* but also to think what I really need to accomplish and get to it instead of building a grandiose architecture
* to have consistent apis
* to steer away from OOP
* to rely on minimal dependencies and to be kind of minimal in general
* to use the correct tool for the problem (macro are not easy to write and that’s good otherwise you will abuse them. Instead they are great to use)
* to build main table code
* ...
I would be interested in what other nimmers think are the good shepherding.
One might also think of what is bad shepherding of nim, although nothing comes to mind at the moment.
> * to use the correct tool for the problem (macro are not easy to write and that’s good otherwise you will abuse them. Instead they are great to use)
Just wanted to add: Nim has Macros (which are comparable to lisp forms) and Templates, which are closer to C and Lisp macros and are much harder to abuse; It also has built-in inlines and generics, which are essentially the prime use for templates and macros in languages that lack those.
It also has stuff like operational transforms, which lets you state things like "whenever you see x*4 and x is an integer, use x shl 2 itself", so that you CAN apply your knowledge in the places where you know better than the compiler, while still writing the code you meant to write (multiply by 4) and not the assembly you wanted to generate.
Right tool for the right job is a very good description, which I don't think many languages can claim - definitely not minimalist ones like K, nor kitchen sink ones like C++ (no, an accidentally turing complete template expansion system is NOT the right tool for compile time computation).
* I very rarely need to come up with a name for a function or other identifier. The correct name can be reused for multiple use cases thanks to the type system and prox overloading. * to spend a little time designing the interface before jumping in the code * but also to think what I really need to accomplish and get to it instead of building a grandiose architecture * to have consistent apis * to steer away from OOP * to rely on minimal dependencies and to be kind of minimal in general * to use the correct tool for the problem (macro are not easy to write and that’s good otherwise you will abuse them. Instead they are great to use) * to build main table code * ...
I would be interested in what other nimmers think are the good shepherding.
One might also think of what is bad shepherding of nim, although nothing comes to mind at the moment.