VoltDB took this to an extreme - the way you interact with it is by sending it some code which does a mix of queries and logic, and it automatically retries the code as many times as necessary if there's a conflict. Because it all happens inside the DBMS, it's transparent and fast. I thought that was really clever.
I'm using the past tense here, but VoltDB is still going. I don't think it's as well-known as it deserves to be.
Interesting. How is that faster than just having the code running on the same machine as the DB? Guess it could be smarter about conflicts than random backoff.
Usually, you can. But occasionally you get mildly defective tools that require some directory to exist, even though it's empty. It's easier to add a gitkeep than fix them.
And i assume any large organisation running a monorepo has some vaguely equivalent tooling for making mass changes. Have any of them published about that?
You can write automated refactoring with clang tools if you need AST-level knowledge across your project (or monorepo).
I’m not sure if there’s other public examples leveraging this, but Chromium has this document [0] which has a few examples. And there’s also the clang-tidy docs [1].
This is a business that I suspect may not survive BABLR.
> Moderne's build plugins allow for LSTs to be serialized to disk. This makes the process of consuming and editing large quantities of them much more efficient. OpenRewrite's build plugins, on the other hand, store everything in memory and need to be reparsed every time there is a change.
So yeah I'm giving away open standards to everyone for free that do the thing they expect people to pay them for...
> The next-gen LR parser framework for creating elegant and efficient language tools
> BABLR is a new kind of thing that does not quite fit into any category of things that has existed before it. In purpose it is made to be an instrument of code literacy -- a unified toolchain for software developers that supports a new generation of richly visual interfaces for coding. In form BABLR is a collection of scripts and virtual machines written in plain Javascript that run in almost any modern web browser. BABLR is also a community and an ecosystem, including a small but rapidly growing collection of ready-to-use parsers for popular languages.
At first brush, everything about this sounds like overly ambitious vapourware. Is there a reason to think this is going to deliver? People involved, what's already shipped, etc?
I particularly loved this from their roadmap:
> Completed
> Shift operation
> Enables LR parsing of expressions like 2+2
Being able to parse 2 + 2 is definitely good!
And their thoughts on testing:
> How our project reaches production stability is a process that often surprises people. We don't write a lot of tests for example, and we often don't do much testing before we ship releases. Instead we test exhaustively after we ship releases, which is the only way we know of knowing for sure that the product we shipped does what we think it does. [...] We also don't (usually) practice TDD. If you look at the number of tests we have, it likely won't seem like it's anywhere near enough to keep a project of this size stable! The secret sauce here is that our key invariants aren't written in our test files, they're baked into the core of the implementation. Every time you use the code, you're essentially testing it. To gain confidence in our core, we simply try to use it to do a lot of real work.
Man, why did i not think of that, i could have got out of writing so many tests if i'd just baked the invariants into the core of the implementation!
In this case the tool is meant to parse programming languages, so once I write some parser grammars every valid code file in existence is a test case. Seen that way I have more test cases than I know what to do with.
We've come a ways from 2 + 2. This week my goal is to feed our own whole codebase through the JS parser, and I should be able to. I managed to parse a few hundred lines of real JS last week before running into Automatic Semicolon Insertion trouble that I needed to tinker with the core to fix.
While I get that our low profile smacks of vapor, we actually have working packages published: bablr and @bablr/cli. I'd consider them to be beta quality right now, having gone through many previous releases that I'd only consider alpha-quality, and even more releases before that.
It's not too hard to verify my central claim here which is that we're giving away what they charge money for. Their serialization format is secret, proprietary. Ours, CSTML, is open: https://docs.bablr.org/guides/cstml. Their free product make you re-parse the entire project with every code change you make. Ours is built with copy-on-write immutable data structures so that you can always build new things without losing old ones. Our way you can compose fragments of trees together with new code into new trees like you're playing with lego bricks.
> Nevertheless, detecting the holding of locks requires a careful and occasionally interprocedural analysis of the source code, and the other conditions, such as "in a completion handler", are not formally defined and require study of multiple files.
> Due to the complexity of the conditions governing the choice of new argument for usb_submit_urb, 71 of the 158 calls to this function were initially transformed incorrectly to use GFP_KERNEL instead of GFP_ATOMIC.
Okay, but how does Coccinelle help? Is it able to do this careful and not formally defined analysis? Or does it automate the undifferentiated heavy lifting and so make it easier for humans to do it?
It's not illegal to record members of the public without permission in the UK. The test is mostly about whether someone has a reasonable expectation of privacy, but there are all sorts of other considerations:
> The programmer first had to decide what properties they cared about... then also had to say explicitly what state they expected each field to be in.
Yes, this is the point of testing. You have to think about what you're about to write! Before you write it! The technique in the article completely discards this. It's a terrible way to write tests.
I'm using the past tense here, but VoltDB is still going. I don't think it's as well-known as it deserves to be.
reply