You can print infinite Legos. It'll just take a high quality printer (e.g. a Prusa MK3s) and a bunch of test prints to get the tolerances right.
Now that I've got my settings for Legos dialed in I add Lego nubs to all sorts of things so you can attach regular Legos to them.
For example, I've printed a great many magnetic pins for my son's robotics team to give away as swag at competitions. They all had Lego nubs around the perimeter so the kids could attach Minifigures and other Lego parts to the pins.
Precise it is. But the hard part with any manufacturing method is tolerance or expanding/shrinking material. When you 3d print 10.85mm long bar it might actually end up as 10.88 depending on material and denseness of the print. Printing compatible Lego parts is possible, but requires some trial and error to get things right.
I'm curious to know what people think about elisp as a extension language. Would Emacs be better if everything was implemented in elisp including the core data structures (assuming elisp was very fast)? Do people suffer from lack of static typing?
Elisp is nowhere near perfect, but it's fast enough in general. I recently wrote an indent function for a private DSL; it looks like a big slow mess, but when I run it on a code file, it does its job with no noticeable lag. You can write slow code in any language, of course.
Not off-hand because it's been a while, but IIRC the names of some methods were changed, arguments were added/removed. I will say that was before version 1.0, so it may be more stable now.
Last I saw the nvidia driver situation did not improve though. I wanted to come back to some old code, installed a new version of PyTorch. It complained that my GPU drivers were not recent enough, had to do this long tedious process that took over an hour to get newer drivers working.
I asked myself the same -- should I start with APL, J or K? I concluded that APL is the "original" from which the others draw inspiration, and so it felt most natural to start there. Note that wherever you decide to start, the experience you gain carries over to the others.
static_argnums is really just a way to give a bit more assumptions to attempt to build a quasi-static code even if it's using dynamic constructs. In this example that will force it to trace one only one of the two branches (depending on whichever static_argnums sends it down). That is going to generate incorrect code for input values which should've traced the other branch (so the real solution of `lax.cond` is to always trace and always compute both branches, as mentioned in the post). If the computation is actually not quasi-static, there's no good choice for a static argnum. See the factorial example.
