Holy Deep Dive, Batman. This has to be the most mathematically heavy design for creating TUIs ever conceived. The name makes sense.

But does it blend? (Actually useable?)

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

FOR loops?

YAML has a merge key <<:, which might be helpful.

The merge key is a clever little trick, but it depends of the special hash key, so lists can’t be merged.

Syntax does matter, which is why YAML matters — even if imperfect.

Merges and anchors are some of the least maintaineable and most error-prone config i've seen.

Doesn't help every yaml parser has their own opinion on what a merge or an anchor should do, exactly.

So brilliant that we’re all still using ASCII!†

† With an occasional UNICODE flourish.

I agree. Separate keys would be better.

I wonder if hat word processors would have used a separate Enter (or Go!) for?

I hope there are no major problems to commercialization. This will be huge!

IDK. They all look a little atrocious to me.

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.

And Forth was invented by Charles Moore while at NRAO!

https://en.wikipedia.org/wiki/Charles_H._Moore?wprov=sfti1#E...

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

W. Richard Stevens wrote a Forth manual for Kitt Peak in the 70s. Now I’m curious how many observatories used the language.

This has some great background on Forth's history and use at observatories.

"The evolution of Forth | History of programming languages---II" - https://dl.acm.org/doi/10.1145/234286.1057832

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.

I’m sure there were many other sites.

I'll bite. Are you able to share any FORTH code/repos that hit that aesthetic spot for you?

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.

Forth user here (Eforth Subleq/PFE). Scheme is not that bad. Haskell, OTOH, and any ML language, looks very difficult to me.

That’s awesome!

Now have it mark blocks of text on or off, so it can ignore irrelevant, or worse erroneous material — no need to include it in the context window.

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.

Back to TF IDF we go.

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

Do we really need a new “code container” type for this? Could modules not serve the purpose by localizing require. e.g.

    module Foo
      require “bar”
      …
    end

So everything bar.rb loads in safely within Foo?

this would be a major breaking change