transfire
Remote: Yes — or onsite/hybrid, any is fine
Willing to relocate: For the right role — especially research
Technologies: Rust, C, Crystal, Elixir, Ruby, Python, TypeScript; LLM training & agents, RAG / vector memory, high-performance parsers & data formats, full-stack + infra/ops
Résumé / Portfolio: https://tabcomputing.com/portfolio
Email: [email protected]
Self-directed systems & AI engineer, available for contract (or the right full-time role). In the last year — solo, mostly from scratch — I've built: an LLM training engine and active research project (AGPT); an AI agent framework that autonomously runs my own production infrastructure (copious); a semantic-memory / RAG library (memo); a C11 YAML 1.2 parser that passes all 308 test-suite cases and outperforms every other compliant parser on real-world benchmarks (YAM); and a serialization format about half the size of JSON that parses ~3x faster (C0DATA). I also maintain Ruby Facets (since 2005). I go from model internals to production ops, and I ship — every link on the portfolio is real, running code. Research is my first love — AGPT above is my own line of it — and the work I'd most gladly relocate for, though I'm every bit as happy shipping production systems. The site also has an AI assistant you can talk to; she'll take a brief and send it to me.
But does it blend? (Actually useable?)
(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.)
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.
† With an occasional UNICODE flourish.
I wonder if hat word processors would have used a separate Enter (or Go!) for?
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.
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.
module Foo
require “bar”
…
end
With Apple’s move to Arm and increasing interest in RISCV, the x86 architecture hegemony seems to finally be cracking.
I find it hard to believe there is no way to secure without requiring an authority in the middle.
And what do certificate buyers gain? The ability for their site to be revoked or expired and thus no longer work.
I’d like to corrected.
The tag schema used is supposed to be modifiable folks!
And why anyone would still be using 1.1 at this point is just forehead palming foolishness.
Is command and commandfor actually a good idea? I understand the point of it, but it seems like yet another layer of cognitive load.
Instead why not just apply the same principle to CSS? If I could make a CSS selector for one element but have the result target other elements, then one could achieve the same results and more. It would require only a few more pseudo-selectors. And while it probably isn’t necessary, I think it might be prudent to mark the properties that undergo state changes. Something like:
#my-popover { display:= none; }
#my-button:click {
|> #my-popover {
display:= block;
}
}
Oh… they just fined turned an already existing model.
It’s no wonder we have endless security issues when documents that should be just data and metadata (layout) declarations are Turing complete. Sigh.
Original books are classics too.