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

It was almost exactly the same expect in VB you had use some esoteric code to access databases — and they kept changing what was the “proper” way to do it. (I think by the time I quit VB it was ADO?)

It was indeed ADO (ActiveX Data Objects) - Connection, Command, Recordset etc - and this is also the API used by Access.

Microsoft wouldn't be Microsoft without having confusing naming for its APIs, so the one before ADO was called DAO (Data Access Objects).

There was also some very confusing layering in play. ADO didn't work with the database directly - it was a layer on top of either ODBC or OLE DB, depending on the database.

I don't recall it being particularly esoteric. There were libraries to call various databases. In my first job I converted a vb6 application from Foxpro to SQL server. I was just getting into Ruby on Rails at the time and wrote a COM library the the data layer that was somewhat like activerecord, and ended up using it from ruby scripts. Fun times. Just looked it up and the software still seems to be being sold 20 years later.

Is this a reflection of the economy in general or just Intel’s own troubles?

With Apple’s move to Arm and increasing interest in RISCV, the x86 architecture hegemony seems to finally be cracking.

I'm going to guess both.

Intel's troubles are deep and existential in nature, but the state of the economy makes addressing those troubles far more difficult than they would otherwise be.

RISC-V is at least a decade away from threatening x86 or high-end Arm.