rwhaling

That's a great question - right now it is only looking at the results from a battery of several dozen indicators that we compute upstream of the model itself (which saves massively on tokens)

As small models continue to improve, and edge hardware becomes more capable, we would really like to run larger models that could incorporate full page content and screengrab data, which would be more likely to catch these kinds of attacks.

But we also find that sites that do one shady thing usually do others, which is a big reason why a tiny model like this can work - and why we are betting on low latency being a differentiating factor in real-world impacts.

CLAVIER is amazing, the wire system alone is such a huge improvement over ORCA, and it's now feasible to make much larger patches and refactor safely, kudos to River for all the hard work on the polish and quality-of-life.

I was testing MIDI on a prerelease build last weekend and it turned out quite nice: https://www.instagram.com/p/DOUUIfeEQWY/

Excited for more folks to get to play with it!

Yep absolutely! It reminds me of writing cryptic perl one-liners or something.

Love 100r! There aren't a ton of examples online, but their livecoding music software/language, ORCA, is a remarkable instrument. https://100r.co/site/orca.html

I posted a clip to bsky a few weeks back: https://bsky.app/profile/r.whal.ing/post/3lpyrm4vrqs2d

And Allieway Audio made some great Youtube videos about ORCA too if people would like to learn how it works in more of a tutorial format: https://www.youtube.com/watch?v=RaI_TuISSJE&t=446s

(I love the Dwarf Fortress background for this video, it absolutely nails the vibe)

clearly Factorio

Really cool - the stuff they are doing with the Excel API to inspect editing modes is super interesting: https://www.sharpcells.com/docs/blog/monitoring-edit-mode

I work with data warehouses, but I'm really jealous of the way our Finance team uses some abysmal plugin to directly query our GL from inside Excel - building something like that the can make the contents of a modern data warehouse available to Excel users has always been a holy grail for me.

My hunch is that exposing free-form SQL in Excel doesn't work, but something more like structured metrics (something roughly like dbt metrics) could potentially work? And tooling like this is probably what I'd want to prototype with.

Airbnb wrote a few great blog posts about why they built a standardized metrics layer - I think this one gives better technical context on the "what" and "why" than this announcement does:

https://medium.com/airbnb-engineering/how-airbnb-achieved-me...

(As the article notes, Transform's founders are Airbnb vets who worked on Minerva)

In practice - complicated time series metrics, especially on top of derived temporal-logic attributes like funnels, activation, etc., are phenomenally difficult to write by hand in SQL for most analysts. We are in the process of switching to dbt metrics and it cuts the effort down for this kind of thing 5x-10x, and the SQL code dbt generates runs signficantly faster too.

One of Transform's strong suits is their Tableau integration - they have really good tooling for pushing metrics out to Tableau, rather than relying on Tableau to pull them in. Apparently AirBnb was/is still a very dedicated Tableau shop.

The biggest win to me is: when your data pipelines are in SQL, changes and maintenance can be somebody else's problem.

I've had a ton of success asking our marketing and business teams to own changes and updates to their data - very often they know the data far better than any engineer would, and likewise they actually prefer to own the business logic and to be able to change it faster than engineering cycles would otherwise allow.

Speaking as a data practitioner - data lineage is a profoundly hard and still unsolved problem.

In the last few years, I feel like we've begun to crack it - dbt's data lineage graph is a huge advance over anything I've ever used before:

https://docs.getdbt.com/terms/data-lineage

But in general - as an industry, we aren't there yet. All judgments about Meta's practices aside - no large organization likely has the ability to comply with a law like this without years or decades of engineering work, and the law seems pretty clearly intended for selective enforcement.

One change I have seen in recent years is that I find fewer and fewer new engineers learn SQL, especially folks entering the industry from bootcamps. And conversely, more and more folks from a business/econ/etc background learn at least a little bit along with excel.

I've been thinking about this a ton lately - I think the holy grail is something that extends the spreadsheet UX with the capability to address much larger data sets, roughly equivalent in power to a Jupyter notebook.

This probably means constraining some of the totally free-form data entry and imposing some kind of discipline onto columns? As well as some way to intuitively group together groups of cell-level formulas into a logical "row", and describe row-level operations, with some kind of rough type checking or duck typing?

But you might want to still retain an ability to lay out the result of computations free-form for invoice and other reporting uses that Excel is still great for?

Better graphical visualization would be nice too and I think that's actually in reach - there are great open source options like vegalite and apache echarts that open up a lot of possibilities for new tools.

Algol 60 had lexical scoping in 1960 (while Lisp was in development) and this was known to be equivalent to the lambda calculus by the folks working on it by 1965 or so - https://dl.acm.org/doi/10.1145/363744.363749

I think the consensus is that Scheme was the first Lisp to fully embrace lexical scope, in 1975?

[edited for clarity and punctuation]

Always an interesting read. A ton of insights, but I always find it a bit hard to make sense of, and it feels so disconnected from a modern distributed systems context.

In retrospect, I think a lot of the Spark SQL Dataframe workflow comes pretty close to what D/Tutorial D aspire to - static typing, functions on relations, imperative style but fundamentally unordered, etc.; however, it's only a processing system, not a storage system.

I have kept my distance from the "data lake" buzzword circles, but maybe a transactional, Spark-based data lake does approximate what Darwen/Date are going for? The only thing really missing might be nested relations?

I think I shared this last time Sonic Pi got posted here, but Sonic Pi is also extremely flexible when you bus the MIDI output to other tools - Ableton, external synthesizers, etc. I posted a clip on IG a while back -

https://www.instagram.com/p/CKKvWP6h3xQ/

And I've also seen it play well with ORCA and other livecoding tools:

https://github.com/hundredrabbits/Orca

Looks great!

I have a question the planned Alpha 7 feature: "smaller than 32-bit values (char/byte)" - I'm so used to bytes being a fundamental primitive in programming languages that it's hard for me to imagine not immediately having access to them.

Can you explain a bit why this is non-trivial, and what the implementation is going to look like?

for background, the original author of nbdev has a good post outlining exactly how it relates to jupyter -

https://www.fast.ai/2019/12/02/nbdev/

This is really exciting! I've been building a data engineering practice around jupyter notebooks, Netflix's papermill, and k8s cronjobs for scheduling, and it's been great...except for code review, weird dependency/virtualenv glitches, tests, and documentation.

At first glance, this seems like it would address all of my pain points? Will be interesting to try it out.

Coming to Factorio from a Scala/streaming/data background, I got the connection pretty immediately - so much of Factorio is about designing correctly for backpressure, such that your factory works stably at different levels of capacity and resource consumption. That said, I still never really got the knack of blueprints and large-scale planning, so I've got a long way to go still.

I recently got obsessed with some music made for the OPN2, one of the chips modeled here - Yuzo Koshiro's soundtracks for the Sega Genesis:

Streets of Rage 2: https://www.youtube.com/watch?v=E5g-QHq925o

Streets of Rage 3: https://www.youtube.com/watch?v=kRrf-WxRsgs

The SOR3 soundtrack in particular showcases an avant-garde edge, closer to Autechre or Aphex Twin than traditional video game music, and generally more of a "club" aesthetic than anything I've heard in other 90's game music.

Great to see Orca on here! Really really fun to play with for generative music; I made a song with it last year that I posted: https://www.instagram.com/p/BzVjW7LBv1K/

I also learned a lot from watching Allieway Audio's Orca series on Youtube: https://www.youtube.com/channel/UCeo2Fo1OidWpT83BT5xmCZw/vid...

Orca is fascinating because it is so limited compared to most "programming languages", and trying to figure out how to express ideas 1) compactly, 2) without abstraction or recursion, and 3) flexible enough for real-time editing, is a great, rewarding challenge.

That was my immediate thought as well - CQRS doesn't fit well with the "everything should be deterministic" principle, unless they have a very different definition of CQRS than what is in common use.

In theory, it is possible to do "synchronous CQRS", where the update to your write-side is done in a single transaction with the update to the read-side, but that's not how I've ever done it in my (Scala/Postgres based) CQRS app experience.

I used to work with HathiTrust and attended a few workshops; my experience was that the notion of a "data capsule" that ensures "non-consumptive use" is quite onerous, in practice, and that getting that access can acquire prior approval and supervision of research activities:

https://wiki.htrc.illinois.edu/display/COM/HTRC+Data+Capsule...

I think it's actually a clever technical solution to a hideous legal problem, and it makes a lot of research possible that would be totally illegal otherwise, but it 100% gets in the way of totally legitimate research as well.

I've been using Scala Native for two years now, and I find that it's C interop is state-of-the-art. The way I would pitch it is: Scala Native gives you the capabilities and performance of C, embedded in a Scala DSL.

In particular, pointer arithmetic and memory allocation feel really smooth, and struct syntax is getting reworked for the upcoming SN 0.4 release.

The affinity with C, and with systems programming in general, isn't something you necessarily get with Swift or OCaml to the same extent. And even Rust, although it is outstanding for some systems tasks, isn't 100% mature on concurrency and async use cases yet.

In contrast, Scala Native works really nicely for low-level concurrent programming - I'm writing a book about SN for Pragmatic at the moment [1], and the entire second half is about building up a fully concurrent backend service framework, from scratch, using C libraries like libuv and libcurl. We're also preparing to release an official libuv binding for Scala Native 0.4 [2]

1: https://pragprog.com/book/rwscala/modern-systems-programming...

2: https://github.com/scala-native/scala-native-loop

We use CQRS and event sourcing for most of our backend services at my current employer (https://m1finance.com); it's generally been a good experience, but we've learned a lot along the way.

My thoughts on the process are:

1. Being able to use a pure/functional event-driven model for the command model, and a standard relational model for queries, is the big payoff for us; we get the best of both worlds.

2. Our model does not encapsulate command-side and query-side updates in a single transaction, nor does it require that they live in the same database; this gives us a lot of benefits for scalability, but it introduces eventual consistency, and not having "read-your-writes" consistency can make things harder for our front-end devs.

A simpler model that does transaction updates to both side might be a win for a lot of teams, and I still wonder if we should have gone that way.

3. We use Kafka for bulk dataflow and inter-service messaging, but not as the internal event store; that gives us some leeway for migrations and surgical edits to the event stream where necessary.

We've found that Kafka's immutability and retention properties do not make it a good fit for a primary source of truth; it's way too easy to "poison" a topic with a single bad message.

4. One thing that none of the books/frameworks do a good job talking about is external side effects with vendors/partners/legacy systems. That's definitely been the single hardest part of our implementation, and we're still evolving our patterns here.

Overall, though, it's been a great direction for us, and we're excited to keep pushing our architecture forward.

One benefit that is repeatedly mentioned in the papers is the ability to do tail-call optimization, which is more or less impossible with compile-to-c interpretations, and mandatory for functional languages.

It's always nice to see the papers that come out of Tiark Rompf's group. For background, here are some other great ones:

Lightweight Modular Staging: A Pragmatic Approach to Runtime Code Generation and Compiled DSLs https://infoscience.epfl.ch/record/150347/files/gpce63-rompf...

Collapsing Towers of Interpreters: https://www.cs.purdue.edu/homes/rompf/papers/amin-popl18.pdf

LMS-Verify: Abstraction Without Regret for Verified Systems Programming: http://lampwww.epfl.ch/~amin/pub/lms-verify.pdf

There's a ton more. Nada Amin's talks on the last two papers are excellent also:

https://www.youtube.com/watch?v=QuJ-cEvH_oI https://www.youtube.com/watch?v=Ywy_eSzCLi8

Oh, and I forgot my favorite: Functional Pearl: A SQL to C Compiler in 500 Lines of Code https://www.cs.purdue.edu/homes/rompf/papers/rompf-icfp15.pd...

Some really mind-blowing stuff.

My thought is that, in some ways, Landin would be disappointed that Haskell/Prolog/Scala/OCaml etc., are all implementing whole languages from scratch -- Landin's argument, as I read it, is that devising a new ISWIM variant should be about as easy as writing your own Lisp.

That said, it does feel like the ML and Haskell communities really have taken up that spirit, with their emphases on multiple implementations and relatively ease of extension.