it's not really possible to stay human readable and get the compression levels and random access properties I was going for. But it is as human tooling friendly as possible given the constraints.
I find it obvious that your first attempt failed. Try again, you have not even remotely failed enough if you are making the argument that this is kinda readable. Yes, ascii words are easy to pick out, you didn’t do that, you did the part that makes it all harder.
CLI is an API, so I decided to treat it as such and created Jargon (for Crystal). Define CLI in JSON Schema, get argument parsing, validation, help text, and shell completions for free. Supports nested options with dot notation, subcommands, config file loading and merging, env vars, XDG base dir compliant, and JSON to stdin.
Honestly if it were not for my extensive Ruby background that I have now been able to carry over to Crystal, I probably would have dived into Guile.
(I have been enjoying Elixir too, but at the end of the day it doesn’t quite sit right with me — just feels a bit clunky. Gleam seems an attractive alternative though. The BEAM rocks, but it is a heavy dependency that doesn’t fit all distribution needs.)
But readability has a lot to do with what you are used to.
The only exception might be FORTH. A very well written FORTH implementation (and I mean very well written) probably would be fairly readable to anyone — at least at the higher levels of abstraction.
"In 1968, while employed at the United States National Radio Astronomy Observatory (NRAO), Moore invented the initial version of the Forth language to help control radio telescopes."
I know of one: the U.S. Naval Observatory near Flagstaff, Arizona. I lived in Flagstaff in 1979. I knew the astronomer and visited him at the observatory at night. He showed me a terminal running Forth that could control the telescope.
That FORTH cannot muster the decency to include a simple «U» in its name rather scuppers any hope of an aesthetic parley before the tea’s even been poured.
Joking aside, FORTH’s reliance on the stack as virtually its only data structure – along with its insistence on applying it to everything and everyone – is simply too impractical outside a few niche areas, such as low-level hardware programming or document rendering (hello, PostScript!). I have no doubt a JSON parser in FORTH will emerge as part of Advent of Code 2038, but I can’t imagine it will inspire hesitating potential converts to embrace the language with open arms.
I’ve not used FORTH, but I learned UIUA last year which has the stack paradigm. You just have to be more careful about your function design and the order of application. I was using emacs and there were annotations by the language server that said how many items you’re taking from the stack and how many will stay behind.
This sounds like an interesting idea, can you elaborate more may be with a concrete example. I am wondering if this can be implemented easily as a plugin in optillm.
One could argue TF-IDF is a case of an attention layer... but not quadratic in inference/training and kinda just a quotient. Yeah maybe we should go back
reply