51–60 of 79 posts
Earlier quoted context omitted.
In what way? This was a geometric mean of the improvements from a small test corpus. In production, where it only parses longer SQL that didn't hit the parser cache, the mean parse time went down by 454x, across millions of parses.
Sounds like the real number is 454x faster, not 70x. Checkmate, nerd!
I was hoping to avoid the criticism that I was picking the most favourable number and being misleading!
The thing I would have liked to know is why they don't use an existing fast SQL parser. Was being slightly incompatible with all existing SQL dialects a product requirement?
There’s something kind of amazing here in that having read about property based testing I’m pretty confident I could apply it if I had a good use case.
The thing I would have liked to know is why they don't use an existing fast SQL parser. Was being slightly incompatible with all existing SQL dialects a product requirement?
I think thats exactly what indirectly happened. This guy didnt optimize the parser. Someone else did -- years ago. That work was pulled into the LLM and made it look like magic.
The thing I would have liked to know is why they don't use an existing fast SQL parser. Was being slightly incompatible with all existing SQL dialects a product requirement?
Our SQL is very similar to ClickHouse SQL, in that we used ClickHouse SQL as a starting point as that's what our underlying DB is. We needed to have our own parser so that we could add additional language features on top.
How did the two approaches compare in terms of code readability?
Earlier quoted context omitted.
I think thats exactly what indirectly happened. This guy didnt optimize the parser. Someone else did -- years ago. That work was pulled into the LLM and made it look like magic.
Note that it's not a particularly optimized algorithm: recursive descent + specialized subparser for expressions is simply the standard way to write parsers by hand. It's ANTLR which is super flexible but also dog slow.
So it's technically vibe-coding in the sense you don't really look at the code, you just look at the results and "go by the vibes"... except now you're working to rigorously quantify and enforce those vibes. (Philosophical aside: once vibes are rigorously enforced are they "vibes" anymore?)
Earlier quoted context omitted.
Honestly there might be truth to it, I don't get the downvotes - why?
The correlation between brain volume and intelligence is fairly weak. Neanderthals had larger brains than humans, for example. Looking outside the hominids, we have fairly smart corvids with relatively tiny brains. That means the chain of thought “brains volume decreased, so individuals must have gotten less intelligent. Yet, societies grew smarter, so there must be herd intelligence” breaks at “so individuals must h…
Earlier quoted context omitted.
It took about 2 days to get a proof of concept, and about a week to get something I could ship to production. I skipped a few features for the PoC (like XML tag support, token positions), so most of the delta was adding those back in!
If you didn’t need to look at the code at all, why not write it in asm instead of Rust, and make it even faster?
If we don't care about inspecting the output, why don't we just replace the Rust compiler with something that generates assembly from Rust source, and then cross check the output with a few million random Rust programs?
[flagged]
2. Since this is a tracking cookie, not a cookie required for the website to function, it requires consent. So I believe the banner is non compliant.