Love this!! :) I thought about being that verbose in Logos lang, but I think language design changes a lot in the modern era.

I suspect we end up with modular compilers, v0.11.0 of logos lang coming soon with some big updates! We have one frontend which is our Logos language, then the intermediate representation a register VM Bytecode IR, then from that we generate Rust, C, and we have a JIT that will just in time directly to RISC-V, Tenstorrent, we’ve been messing with plasticine, and hoping to get our hands on some sambanova RDU’s. We’re burning our language to a chip.

For fun maybe I’ll add a bespoke dialect :p

https://logicaffeine.com/guide

Technically the Rust codegen is from the AST, but then we want to base our other backends on the bytecode VM, although that experiment might get lifted back to the AST, I just am trying to think of the best portable format. We have a treewalker, then I wrote a register based bytecode VM, then from there we did a copy-patch JIT with stencils that can hot-tier to native, and that was the interpreter side, our compiler we have a 40+ pass AOT optimizing supercompiler for Logos to Rust codegen and then we added the C backend, but then I started thinking… if I make it so I can run the optimizer passes then it goes into the VM’s bytecode IR, I could get my optimization passes on all the backends I add for free by generating the code from the IR, so I’ve been experimenting with having our rust codegen from the AST, and the C codegens from the bytecode IR which has the passes applied because they share the core optimization primitives.

It’s a fun experiment but I might go back to the C codegen from the AST as it maintains more useful information that I can use comp-time for more optimizations, but the idea of modular languages and compiler backends interests me. Languages can have “bespoke” front ends quite literally, pick your flavor because really a lot of the flavor can be handled at the parser, and you can have a big nasty language surface area if the parser can clean things up or AOT some of the sugar away. Interesting the idea of sugar in language design as well, we can sprinkle sugar in ways we couldn’t before at all. I just added a bunch of ML primitives for our new CUDA-JIT backend that lets us lower quantized INT8 GEMM’s onto spatial compute fabrics.

Man it’s a crazy time to be alive, I’m not sure how long this period of history will last, but building with an army of agents is amazing.

Last night I for the first time in a while decided to write a little program by hand and after about 30 minutes I had it working but the AI can spit that out in seconds. I admit I’m rusty, that would’ve taken me 5-10 mins at the peak of my degenerate coder phase but the amount you can accomplish now is unparalleled throughout history. When I used to trad code transpilers sometimes single lines would take hours of thinking and work and many lines of iteration to get to. Now I can add an entire new chip architecture as a compile target in a couple weeks.

I'm still working on Logos Language. Just launched v0.10.0 :)

https://logicaffeine.com/benchmarks

This is the silliest take I’ve ever read. Strong type systems are an AI’s best friend.

I wanted to major in Philosophy but was worried I wouldn’t make enough money to support the lifestyle I wanted so majored in Computer Science instead. What irony.

Someday I hope to go back to school to get a PhD in philosophy with a focus on logic. :)

I’ve been shocked by how much LLVM leaves on the table while designing Logos language! Some very exciting benchmarks coming soon that we’ve been working on for over 6 months, but LLVM misses a LOT of potential optimizations when you have a strong type system!

Is there a URL for that language? It is unfortunately a bit un-googleable!

found this: https://logicaffeine.com/guide

Yes that's the language, the v0.10.0 benchmarks are coming very soon and with it some major updates. We've added supercompilation and symmetry breaking to the optimizer pipeline. Sneak peeks available on a branch currently named stream1. https://github.com/Brahmastra-Labs/logicaffeine/tree/stream1

Lately I’ve felt Kolmogorov complexity is an unfair measurement because it takes for granted your underlying programming language as treats it as zero cost. In theory you could create a custom language and embed the program as data and “compress” a large random sequence with a better Kolmogorov complexity for that specific language than Pi, simply by not exposing the ability in the language to even work with Pi. I think what’s maybe more interesting is when you take into account the work of Dr. Futamura and the idea of Jones Optimality and view things through that lens.

His definition of Kolmogorov complexity is a bit loose. The rigorous definition uses Turing machines (or Minsky, or Post, or some sort of lambda expression, etc.) so the size is something specific. Different versions of complexity defined this way may give different values but have the same properties and asymptotics so one might just as well stick with the Turing kind. Chaitin's theorem (about the limit of Kolmogorov's complexity being just entropy) holds for all versions as well.

it's not just that they have the same asymptomatic. once you do the radix conversion (e.g. base 10 has log(10)/log(2) times more symbols), any 2 definitions are only off from each other by a constant

You always include the measurement of things needed to run the program too.

It's a bit like how benchmarks of compression utilities should always include the size of the utility itself. Otherwise someone can just submit a program with a dictionary of 256 common benchmark files for compression and claim "it compresses them to a single byte" :)

Of course you can. Kolmogorov complexity never says anything about finding lower bounds for specific elements. The lower bound is a statament about one string. The upper bound is statement about infinite strings, so you need to prove for infinite strings. In that sense you cant compress all strings and pointing a specific one without representing the index to it with a complexity a least as large as the string itself it represents. Read the part of pointing and telling things apart.

Does that solve the issue? You can always ask yourself if you can embedd something smaller or not? Kolmogorov is just comparing things.. plus, in order to specifically point to pi in the languages internal table, you will need complexity as large as your representation of pi.

Hey all, I didn't actually use Claude for the embeddings on this (bc they don't offer embeddings), but I think we can extrapolate that if a tiny open source model has this level of recognition, surely the SOTA models do. Very interesting to me that we can predict things like gender and college from a sample of writing for authors. Also interesting how much stronger the correlation may be between Coders and their Code to authors and their books. Seems code has a more "unique" fingerprint than your typical book perhaps. (Although actually looking at it again perhaps that's sample size. Would need to research more to know for sure.)

Author recognition seems to climb as a smooth gradient with author exposure in LLM's. :)

Thinking about this as I continue working on Logos language prepping for our 0.10.0 release, finished our copy-patch JIT that does hot-tiering and found myself wondering why I was going to all the trouble to native tier with a big game of compile to Logos Lang -> JIT to either my Bytecode language or Rust for compiled -> GCC -> WASM

So I'm writing a WASM JIT, and I'm wondering why things never got to that point? Is it just beyond human comprehension? (Don't get me wrong here, I would not be writing something Jitting to WASM without AI, and maybe it's these types of projects that simply weren't feasible or something to consider pre-AI unless you were very rich and very bored.)