Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • This is super cool, and I am totally going to glean from how you handled testing some of this.

    I have a tool I make as a data-plane to a graph engine, and it uses cap'n proto to help (And sqlite as a sort've IPC option). One of the biggest things I have is, I know I am not testing all of it to completion. I am not even really fuzzing, yet.

    Thanks for sharing!

    by jamestexas
  • 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?
    by lovasoa
  • 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.
    by -warren
  • This is pretty much the case with every SQL dialect
    by __s
  • Yeah curious why they didn't use Presto/Trino, DuckDB, or Clickhouse SQL directly with UDFs and views to augment

    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

    by nijave
  • 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.
    by robbie-c
  • Could the agent traces from this be used to improve sqlglot?

    tobymao/sqlglot: Python SQL Parser and Transpiler; with tests and support for 30+ dialects: https://github.com/tobymao/sqlglot

    Ibis depends upon sqlglot: https://github.com/tobymao/sqlglot/network/dependents

    by westurner
  • 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 spin up a VM, sure. But GitHub Actions already has a Windows environment, and there was my loop: let the agent push to the repo, run tests in GHA, rinse and repeat.

    In under an hour it had a full rewrite of my Python, passing every test and producing row-for-row copies of my Parquet output. And it does work on the user machine!

    Spotting a loop like that is as satisfying as noticing you can walk your chess opponent into a smothered mate. Truly empowering.

    by ndr
  • DuckDB

    Also Windows used to have a free VHD with a trial license you could download (and convert to different format with qemu-img)

    by nijave
  • A while ago I had predicted that eventually all coding would eventually become vibe-coding but it would still be a deep engineering discipline (https://news.ycombinator.com/item?id=48040206) -- this is what I meant. Deep technical expertise is still needed, but it shifts from working with the code directly to crafting bespoke comprehensive validation mechanisms around the code. This is a great example of what that could look like.

    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?)

    by keeda
  • That's great but I really wish you guys would do something about the llm integration, I tried using it two days ago to create a cohort of users using a sql query, and I was surprised to see that it said that it could not create cohorts for me and i had to resort to exporting data from a sql insight as a cohort cannot use a sql query. However the worst part was it just writing in the text input slowed down my m4 pro chip to less than 1 fps after 2 prompts and it really left a bad taste in my mouth.

    Perhaps the next target for a 100x improvement

    by justAnotherHero
  • The key parts of this is how not vibecoded it is. Feels like a model of how you should do software with AI. Now that we can easily set up property testing, fuzzing, etc. there's almost no reason not to.
    by russellthehippo
  • that is vibecoding these days
    by spullara
  • This is the type of problem for which LLM generation is great for.

    If you have an oracle, and your problem is largely just a pure function, it's pretty good at generating something that both works and is fast.

    by theLiminator
  • I cannot believe they're sticking to their guns on this website design. It's awful.
    by mikkelam
  • I love it. So different. Slightly BeOS.
    by noja
  • Yeah. It locked up my browser. What a pile.
    by softboyled
  • It's awesome!
    by my-next-account
  • Try clicking 'switch to website mode' on the left side
    by kg
  • They have an excellent branding and have some balls to pull it off, it shows passion, I highly trust it even in company settings.
    by pixel_popping
  • I love that it doesn't feel like every other vibe coded VC backed startup.
    by joshmarinacci
  • I’ve had very good success in similar setups where you have some sort of “oracle” and can generate enormous corpuses of test data, such that you really, really trust the LLM code must work for the inputs you expect it’ll ever need to handle.

    Makes me think of all the algorithms we specify in proof languages and then hand-implement in production languages - this setup could maybe let you just specify the proof of an algorithm and then let LLMs derive efficient implementations with the (slow) proof as an oracle

    by jakewins
  • > 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 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 :)

    by cespare
  • Well… tis difficult if one does not understand how grammars work, and therefore parsers. But we’ve seen people use stuff like ContextFreé’s Design Grammar, without even being IT guys, and still figure themselves around.

    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.

    by larodi
  • That's valid criticism, I kinda hand-waved the "months" part. I read everything I could about parsers while building this (I have a CS background but hadn't thought about parsers in a long time) and came across this blog post https://lakesail.com/blog/sql-parser-in-one-week/ which talked about building a toy parser in a week, so I scaled that up to months for a production one.
    by robbie-c
  • 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 is really about selling our soul to the devil for short term gains.
    by duendefm
  • That can be said for any technology in history that made work easier.

    “Whoa slow down with this ‘writing’ technology. No one will ever remember anything if they can just write it down.”

    by jimbokun
  • It is a tool for some and a crutch for others
    by nijave
  • I think AI is powertool. Period. If you give it to people who are skill, it will create a mess.

    I think democratization of intelligence is going to be interesting. You could say the same with same about internet. I think it is part of evolution. May be intelligence or expertise is what does not make us special. May be it is that we are ingenious amd creative with tools and thats how we evolve.

    by bitlad
  • > till I have the feeling that this only works because of the vast accumulated knowledge pre-AI

    I'm not about to say that there's nothing new under the sun, but parsers are a really well-understood problem where 99.9% of people don't need frontier knowledge and wouldn't be in a position to use it anyway.

    And I don't think that people doing research on parsers would ever rely on LLMs for precisely that reason. But we're not parser researchers right?

    by Daishiman