> "Posix best practices" means ambiguous CLI switches that require a symbol
> table to parse. Not much of a "best practice" here, it's just bad design that
> you prefer because it's slightly easier to type.
I'm not interested in arguing about the merits of each approach. My point is
that if you're writing a new OS then it would make sense to introduce a better
alternative to command line parsing, but Nim is a programming language, it will
be used in multiple operating systems and all of them seem to be converging
into Posix style CLIs.
> I think grep is always a last resort tool as it doesn't understand any
> programming language...
Sorry, I think I didn't explain myself correctly. I'm not referring to the
`grep` tool in particular. It's very common among users to navigate code by
searching, specially if you're looking at the code of others, which can be with
`grep`, any of its more modern alternatives, editor in-built search feature,
etc. Many modern languages are easy to _grep_ since they prefix declarations
with a keyword but in Nim this is slightly harder, I'm not advocating to change
the language for this, just that it might be worth to guide new users with best
practices to navigate a Nim code base.
> You can productive in Nim without templates and macros, but we can't offer
> "runtime alternatives" for these features.
Totally agree, and I would say that the language already provides ways to
implement most software without having to use templates or macros. But somehow
my initial intuition was that it wasn't the case, I think that perhaps the
issue is having several keywords with compile-time semantics, maybe if the
language had a prefix keyword to introduce them the on boarding would be
simpler:
* `when`: `const if`
* `static`: `const block`
* `proc ... {.compileTime.}`: `const proc`
