tel
“You feel for the lamp because you are crazy. It has no feelings and the new one is much better.”
As I write this it’s very hard not to feel like a psychopath.
Or Fisher in the 1930s with data driven linear didcriminants.
A huge part of my goal is to write a "spec" of the format. I want it to be good enough that users can legitimately file bugs against my primary implementation for not following the spec: it is the source of truth about the language.
So, of course, I find it really interesting to discuss the grey space of "shrug, maybe this is correct". This whole process has been driving me to (a) make the language itself resilient and permissive so that it has _some_ answer for nearly all documents and (b) to constrain the output of the system such that it throws away as much information as possible, enabling us to make claims about semantics more confidently.
I don't know if I'm going to succeed at all my goals. This is sort of a small project and definitely far simpler than, say, a web browser. At the same time, it's very hard to narrow in on what it is, really, that I want such a spec to say.
But to take ownership over words and thought in this way reads as nearly fraudulent to me.
That said, I have no idea what contribution may have been done by Mr. Gomila or not. I don't know if I can ask him for more details. Even if he wrote the whole thing (and either has deeply internalized Claude's voice or had it edited and rewritten by an agent) it's difficult to believe that he's the sort of expert I'd expect of someone who had actually done all this work.
This is basically the same feeling I have about vibe code contributors.
You can toss it at a task with a suitable machine for transforming that raw material into action and it'll rattle through and sample "plausible human behavior" at that endpoint.
There are more clever ways to use it, but a general tool here is to upgrade any sort of stochastic search to use this new form of random sampling. It'll be way more efficient, properly conditioned, because it just won't visit implausible things nearly as often as competing random sources.
Markdown is really interesting. For most readers and most writers it's dead simple and you just get the idea from a few examples or reading a short description. In practice, it's dozens of dialects (though 3 related ones dominate) and dozens more implementations. It's hard to write new, compatible implementations, so they tend to fracture.
(This may be less true with LLMs nowadays, but it might also be worse.)
Often, someone wants to write a Markdown variant because they wish it supported some new extension to help it mesh with the use case and tool they are envisioning. Each one of these is a new fracture.
My goal is a simple specification that's easy to reimplement that eliminates years of cruft and subtle complexity. I'm designing it to be simple and obvious to extend and building a governance model so that extensions can live together, grow, maybe even become mainstream all without ever breaking compatibility.
It's similar to a type system in that regard. The same difference could be applied there (comparing a Python type assert). Types, however, generally only cover checks similar to "the shape of the data is X".
Lean is different in that its language for expressing properties is wide enough to express anything you can imagine. The bottleneck becomes accurately stating properties you'd like to enforce and, subsequently, discovering proofs of whether or not they're true.
Not saying you're wrong. Professionalism is an important tool for maintaining professional relationships. Lack of professionalism is dangerous to the point where it is reasonable for certain kinds of societies to begin to shun people who don't engage with it.
And, at the same time, a certain amount of emotional honesty can be really important to share, too. And that includes some amount of judgement and criticism.
It sounds like Zig's relationship with Bun is over. While Anthropic/Jason/Bun did not write a personal narrative about the end of that relationship, they absolutely were the initiators and could not have done this in a more aggressive way. It feels to me to be approximately the equivalent of moving out in secret and serving the divorce documents through your lawyer.
I think the beating heart is that everyone is there with some passion to learn and build and you're encouraged to do so collaboratively. It's surprising, I feel, how rare it is to have a community of folks who are all learning together and not afraid to dive in and figure things out. Recurse Center is a chance to spend 6 or 12 weeks building and then living in a place like that.
I'm also rebuilding an integrated task/knowledge/publication system I'd previously built atop Gemini's Gemtext format. While I loved the simplicity, I've discovered that there are lots of burrs in that design, especially on the publication side, which I'd be able to lift by using a more fully featured document format like Djot.
Though yeah the edgelord-y style faded after I criticized it a couple times.
https://www.realsenseai.com/products/real-sense-depth-camera...
That said, I don't think splats:voxels as pixels:vector graphics. Maybe a closer analogy would be pixels:vectors is the same as voxels:3d mesh modeling. You might imagine a sophisticated animated character being created and then animated using motion capture techniques.
But notice where these things fall apart, too. SVG shines when it's not just estimating the true form, but literally is it (fonts, simplified graphics made from simple strokes). If you try to estimate a photo using SVG it tends to get messy. Similar problems arise when reconstructing a 3d mesh from real-world data.
I agree that splats are a bit like pixels, though. They're samples of color and light in 3d (2d) space. They represent the source more faithfully when they're more densely sampled.
The difference is that a splat is sampled irregularly, just where it's needed within the scene. That makes it more efficient at representing most useful 3d scenes (i.e., ones where there are a few subjects and objects in mostly empty space). It just uses data where that data has an impact.
For example, the camera orbits around the performers in this music video are difficult to imagine in real space. Even if you could pull it off using robotic motion control arms, it would require that the entire choreography is fixed in place before filming. This video clearly takes advantage of being able to direct whatever camera motion the artist wanted in the 3d virtual space of the final composed scene.
To do this, the representation needs to estimate the radiance field, i.e. the amount and color of light visible at every point in your 3d volume, viewed from every angle. It's not possible to do this at high resolution by breaking that space up into voxels, those scale badly, O(n^3). You could attempt to guess at some mesh geometry and paint textures on to it compatible with the camera views, but that's difficult to automate.
Gaussian splatting estimates these radiance fields by assuming that the radiance is build from millions of fuzzy, colored balls positioned, stretched, and rotated in space. These are the Gaussian splats.
Once you have that representation, constructing a novel camera angle is as simple as positioning and angling your virtual camera and then recording the colors and positions of all the splats that are visible.
It turns out that this approach is pretty amenable to techniques similar to modern deep learning. You basically train the positions/shapes/rotations of the splats via gradient descent. It's mostly been explored in research labs but lately production-oriented tools have been built for popular 3d motion graphics tools like Houdini, making it more available.
And yeah, I agree. Practically, it's the thing that annoys me the most day-to-day. I've mostly got wrapping set up to handle it now, but it remains a little finicky.
It has no inline formatting, only 3 levels of ATX headers (without trailing #s), one level of bullet points using only asterisk and not dash to delimit, does not merge touching non-whitespace lines (thus expecting one line per paragraph), and supports only triple-backtick fenced preformatted text areas that just flip on and off.
Maybe the biggest change is that links are necessarily listed on their own line, proceeded by a `=>` and optionally followed by alt-text.
My gemtext parser is maybe 70 lines and it is arguably 95% of what one needs from Markdown.