61–70 of 79 posts
Amusing anecdotes on LLMs to:
> It did, in fact, make a lot of mistakes, kept doubting whether such a rewrite was even possible, and wanted to call it a day after each round of coding.
> Hilariously one of the most effective was to tell Claude to “think really hard about edge cases" in a background agent.
Well despite my current anti AI sentiment, I have to admit that after reading the article, It was a good use of AI, done by someone with good technical skills. Still I have the feeling that this only works because of the vast accumulated knowledge pre-AI, and if everybody keeps going in this path, it will end up making everyone not advancing their knowledge at the pace they did before. I feel that this AI immersion i…
Great loop spotting! Recently I was messing around with parquet files in Python and ended up needing to ship the results on Windows, without a Windows machine to test on. Shipping Python to end users is half mad already, and doing it on Windows is exactly the kind of thing I don't want to spend my life maintaining. So I figured I'd rewrite it in Go. But that meant embedding a DLL, and how would I test it? I could spi…
Also Windows used to have a free VHD with a trial license you could download (and convert to different format with qemu-img)
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?
Zuora exposes a Trino-based data warehouse which is quite nice and powerful
Besides the parser side, existing dev tools and docs automatically work, too
> Instead, we use ANTLR, a state-of-the-art, open source parser generator.
I don't agree with this (pre-AI-coding) take. Hand-rolled parsers are much easier to write well and maintain than people think. They also tend to be much faster and produce much better errors than parser generators. I guess if the language you're trying to parse is, say, C++, then you're going to have a miserable time (probably no matter what). But an SQL parser is very doable. (I say this as the author and maintainer of an in-house SQL dialect thingy at work.)
What makes building and maintaining a hand-written parser such a tractable task is:
- The code size can be large, but you can start with a core of a few well-chosen abstractions and then you add lots of parsing code for various language constructs but it's all kind of orthogonal and doesn't add compounding complexity as you go. - It's just about the most testable kind of code there is. You can cover all the various corner cases with tests and really lock in the behavior so that you can very confidently make changes. One approach I like is to make zillions of tiny test files in the target language accompanied by some golden representation of the AST.
And of course, as the author found out, these properties make writing a parser a really good task for AI coding, too. These tools are very, very good at generating a bunch of new code based on existing abstractions and covering it with lots of test cases.
So I agree with where they ended up, just not where they started :)
Earlier quoted context omitted.
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…
Even if we grant your argument that brain volume between species isn’t good proxy for intelligence, It doesn’t immediately hold for comparisons within a specie.
Einstein’s brain reportedly was below average size.
That’s a n = 1 example, but there also is a 50/50 example: man vs women. on average, the brains of males are about 10% larger than those of women (https://en.wikipedia.org/wiki/Neuroscience_of_sex_difference...). That doesn’t show up in intelligence differences (https://en.wikipedia.org/wiki/Sex_differences_in_intelligenc...)
Even only looking at males or females, I don’t think larger (fe)males tend to be more intelligent.
> We didn't write this parser by hand because, at least pre-AI-coding, parsers were extremely difficult to maintain. Writing one without AI would have taken months [...] > Instead, we use ANTLR, a state-of-the-art, open source parser generator. I don't agree with this (pre-AI-coding) take. Hand-rolled parsers are much easier to write well and maintain than people think. They also tend to be much faster and produce mu…
The whole notion grammars are hard is just wrong. They are not only powerful, but super simple in fact. As is the basic regexp if one cares to spend a focused afternoon to understand it. Probably even less time if working with a decent teacher.
Great loop spotting! Recently I was messing around with parquet files in Python and ended up needing to ship the results on Windows, without a Windows machine to test on. Shipping Python to end users is half mad already, and doing it on Windows is exactly the kind of thing I don't want to spend my life maintaining. So I figured I'd rewrite it in Go. But that meant embedding a DLL, and how would I test it? I could spi…
DuckDB Also Windows used to have a free VHD with a trial license you could download (and convert to different format with qemu-img)
I didn't think of checking, but I now learnt there's an extension for DuckDB but it's C++ and also embeds the same DLL [0] https://github.com/flozer/duckdb-firebird
Earlier quoted context omitted.
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.
I think you should clarify that (or whether) while you didn't look at the generated code, you are actually going to adjust it in the future. How did the two approaches compare in terms of code readability?
In the future, we'd make changes by modifying the ANTLR parser first, then using the same approach as in the blog post to get the new parser to parity. We have no plans to get rid of the C++ parser as an oracle!