cligen

nse) as a business attempt to define Java virtual machines as The platform has had many casualties, not the least of which is the quality of discussion of PLang practicalities, not just on HN, but everywhere.

There are also some experimental and probably buggy compiler features to do "term re-writing macros" so that your matrix/bignum library could in theory re-write some bz*ax+y expression into a more one-pass loop (or maybe conditionally depending upon problem scale). I sometimes summarize this as "Nim Is Choice". Some people don't like to have to/get to choose. To others it seems critical. Someone even did some library to make `def` act like `proc`, but I forget its name. Nim has a lot more routine styles than Python, including a special iterator syntax whose "call" is a for-construct. [1] https://github.com/c-blake/cligen/blob/master/cligen/print.n...

/ 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.

search PATH with --help </dev/null >/tmp/help.$c 2>&1 . Caution - be careful if you do this! Have backups/checksums of everything important and run as an unprivileged user. I always have to kill off several processes that just hang doing something or otherwise manually intervene. Anyway, this alone suggests data collection of help text is not a trivial problem. Beyond data collection, many commands did not/do not use CLI toolkits at all. Their commands may have even less regular syntax. Freeform help makes it harder to produce a regular help syntax to convert into the interpreter needed by a completion system. That said, as elsethread commented for some toolkits the Zsh _gnu_generic works great! It essentially IS the "automagic" system you might want, just for a highly restricted circumstance. Any CLI toolkit itself does have the data, by necessity. So, if the CLI framework supports the 2 or 3 common shells there is no need for a translator exactly. You just need a code generator. There is a stab at an auto-generation framework from said data for the Nim CLI toolkit, cligen, over at: https://github.com/c-blake/cligen/blob/master/util/complgen.... but it only works for Zsh right now. Anyway, I don't think perfect should be the enemy of the good or anything like that, but you seemed to ask an earnest "why" question and these are some of the complexities.

undreds of closed issue threads got into a comparison of dups and jdupes ( https://github.com/c-blake/cligen/issues/99#issuecomment-485... ) where Jody shows up. I mean, in my test cases dups fared well, but on what many would call the "boring non-IO bound case". For IO bound cases things rapidly depend a lot on your host OS & devices. I should say that "the point" of most of these things was not caffeine-fueled rage optimization, but more to show how easy it is to get performance & functionality out of Nim. Almost all are much smaller programs (perhaps with many fewer features) than their competing programs. But such catering to The Unix Philosophy felt like it fit well with a CLI toolkit. { Even sys_batch is like a 30 lines of C virtual machine for inside Linux instead of untold 10s of thousands for eBPF & IO uring. While porting to other arches would be more, that 30 lines could probably stay the same. }

001991 sys 99.9 % 5944 mxRS TM 0.940162912 wall 0.935362 usr 0.003988 sys 99.9 % 5916 mxRS TM 1.155755936 wall 1.151529 usr 0.002993 sys 99.9 % 5928 mxRS TM 0.432215672 wall 0.430851 usr 0.000998 sys 99.9 % 5800 mxRS python-3.11.9_p1 TM 2.678891504 wall 2.675141 usr 0.000994 sys 99.9 % 7992 mxRS TM 1.348009364 wall 1.344612 usr 0.001995 sys 99.9 % 7864 mxRS TM 2.018986091 wall 2.014702 usr 0.001994 sys 99.9 % 7972 mxRS TM 0.768633122 wall 0.766915 usr 0.000997 sys 99.9 % 7980 mxRS I recall when Python3 was first going through its growing pains in the mid noughties that promises of eventually clawing back performance. This clawback now seems to have been a fantasy (or perhaps they have just piled on so many new features that they clawed back and then regressed?). Anyway, Nim is even faster than PyPy and uses less memory than either version of CPython: doIt.nim: proc doIt() = var i = 10000000 var r = 0 while i > 0: i = i - 1 r += min(i, 500) echo r doIt() #TM 0.024735 wall 0.024743 usr 0.000000 sys 100.0% 1.504 mxRM In terms of "how Python-like is Nim", all I did was change `def` to `proc` and add the 2 `var`s and change `print` -> `echo`. { EDIT: though if you love Py print(), there is always https://github.com/c-blake/cligen/blob/master/cligen/print.n... or some other roll-your-own idea. Then instead of py2/py3 print x,y vs print(x,y) you can actually do either one in Nim since its call syntax is so flexible. } It is perhaps noteworthy that, if the values are realized in some kind of array rather than generated by a loop, that modern CPUs can do this kind of calculation well with SIMD and compilers like gcc can even recognize the constructs and auto-vectorize. Of course, needing to load data costs memory bandwidth which may not be great compared to SIMD instruction throughput at scales past 80 MiB as in this problem.