I strongly agree with the premise of this article, which is why I am surprised that the author moved away from Haskell to Python.
For some time now it’s felt clear (or at least extremely) compelling that agents need fast compile times in order to be effective, especially when you’re working in parallel. But the other thing that has felt just as obvious is that agents need strong type systems and narrow guardrails in order to constrain their outputs. These two things felt clear enough to me that, like the author, I wanted to choose a language ecosystem that maximized them. There _are_ languages that both have expressive type systems _and_ fast compile times. I wonder if the author investigated any of them, before deciding that no compilation time at all was acceptable.
In my case I landed in OCaml. I think there are other options in the space—Go if you want less typing but faster compiles; Rust if you want more types but slower compiles. My mostly vibes-based evaluation landed on OCaml, and I’ve been pretty happy with the results.
I came away with the exact same conclusion as you. The article describes a rather commonplace career of fraud; more or less every industry has them. There’s nothing unique to classical music here; it’s human nature to generally take people at their word about their past accomplishments, to be impressed by famous names, and to allow their critical judgment to be influenced by what they think they know.
Hi all—I'm the EM for the Search team at Notion, and I want to chime in to clear up one unfortunate misconception I've seen a few times in this thread.
Notion does not sell its users' data.
Instead, I want to expand on one of the first use-cases for the Notion data lake, which was by my team. This is an elaboration of the description in TFA under the heading "Use case support".
As is described there, Notion's block permissions are highly normalized at the source of truth. This is usually quite efficient and generally brings along all the benefits of normalization in application databases. However, we need to _denormalize_ all the permissions that relate to a specific document when we index it into our search index.
When we transactionally reindex a document "online", this is no problem. However, when we need to reindex an entire search cluster from scratch, loading every ancestor of each page in order to collect all of its permissions is far too expensive.
Thus, one of the primary needs that my team had from the new data lake is "tree traversal and permission data construction for each block". We rewrote our "offline" reindexer to read from the data lake instead of reading from RDS instances serving database snapshots. This allowed us to dramatically reduce the impact of iterating through every page when spinning up a new cluster (not to mention save a boatload in spinning up those ad-hoc RDS instances).
I hope this miniature deep dive gives a little bit more color on the uses of this data store—as it is emphatically _not_ to sell our users' data!
Ok, that phrasing is mostly just to keep the pattern going. But I do want to bring to light the fact that there are actually a larger class of games of the same sort as Bridge - imperfect information, high skill, with a body of strategy and discussion - than most Americans are aware of.
I think it’s worth mentioning these for two reasons:
1. They’re really wonderful games! And they have deep cultural roots, which can be added delight for those of us who enjoy engaging with other cultures.
2. Bridge players can be kind of… dicks? That is, it’s unfortunate but true that the culture of Bridge can often be quite rigid and unfriendly. Especially to newcomers. As mentioned elsewhere, a surprising amount of Bridge has to do with the conventions encoded in the bidding, and if you don’t know those conventions you might feel rather lost, and your partner might get very annoyed at you.
Luckily, there are other games in the world that are the ‘Bridge’ of their own countries of origin - deep, strategic, rewarding years of play and study - that the average English speaker has never heard of.
I won’t go into too much detail but some highlights are:
- Preferans, a straight-trick-taking game for three from Russia;
- Skat, a point-trick-taking game from Germany;
- Tarocchino, a point trick taking game played with a 62 card tarot deck from Bologna;
- Koenigrufen, a point trick game played with a 54 card tarot deck from Austria;
- Danish tarok, a point trick game played with a 78 card deck;
- Vira, a straight trick taking game from Sweden;
- a half dozen incredibly deep and challenging games from Hungary alone. Something in the water over there.
In point of fact, Bridge is quite interesting, especially if you’re interested in the meta game of communicating through bidding conventions. I am not; there are other games out there that have really interesting features, lots of strategy, and a history dating back hundreds of years. Check them out!
Because I’m an annoying evangelist for this sort of thing, I’ll make sure my email is in my profile in case you’d like to know more.
I’ve written a fairly long literate program in Literate: https://blog.zdsmith.com/whist.html I really enjoyed the experience. It came out well and it was relatively painless to compose.
Yes, in the first place there's no defined semantics and thus no meaning.
It's also not particlarly appropriate to claim that the language is 'unambiguous'. The intention of the language is to create a notation that allows for the unambiguous expression of relations that would be ambiguous in English, that is, to present a logical or mathematical specification rather than a natural language one. So the ambiguity or lack thereof is entirely in the mind of the reader.
I do have a semantics in mind for it; I have thought about things like operator precedence and currying and stuff. And that matters because you want to be sure that the person reading the specification and the person writing it had the same thing in mind as far as the order of the marks on the page goes.
So there will hopefully be a much more concrete realization of those semantics in a way that still leaves wide open the question of expression evaluation. In other words, it should be an objective fact that `a b c` is evaluated as `a (b c)` - and indeed it is, because the program has parsing rules for function application - but the specifics of what it means to apply `b` to `c` will never be enforced or evaluated on the machine level.
---
In fact, the parent comment's example is a good one because `fib n - 1 + fib n - 2` would be parsed as `fib (n - (1 + (fib (n - 2))))` which is not the intended reading. Right now, that's fine, because it doesn't actually evaluate them. It just pretty prints them back out in the right order and trusts that if you didn't put parentheses there, then the intended meaning should be clear enough to the human reader.
So what, ultimately, will be the relationship between the parsing rules in the program and the semantic openness of the language? Similarly, if I've decided that the language should have implicit currying, such that `f a` where `f` is a function of two arguments, should resolve to a partially applied function of one argument - does that have any meaning aside from a sort of 'suggested reading'? One potential direction for things to evolve is that the language will consist of a set of rules which are enforced by the interpreter and will result in a syntax error if not followed, and a set of rules which are explained in the documentation as a suggested convention but enforced nowhere. In that case the question of something like function precedence is still an odd grey area where the parser does have rules associated with it, but the symbols can flow in and out of the parser without being affected by those rules.
I haven't encountered any compiler bugs, no. I know that they're still really pushing on some of the further reaches—what comes to mind is statically verifying that a value is never `nil`, as well as some of the more industrial-strength elements of the metaprogramming system—but both of those are very much optional.
I have! And I will... I just haven't gotten around to it yet.
The main takeaway is specific to my use-case: writing a dynamic library that can be called from within Python code. The main positive and negative are two sides of the same coin: since Nim compiles to C, you get to use all the existing tools designed for doing C FFI in Python, and don't have to write any C wrappers. And since Nim isn't C, there's still a little bit of detective work involved in replicating all the argument types, GC behavior, etc, that is involved in Nim and the specifics of its realization in C.
I'm very bullish on Nim. We're crossing the finish line of putting our first Nim code into production at work and overall it's been a pretty positive experience.
I've been doing as much Nim as I can recently and really enjoying it. I just took a week to put together a proof of concept Python module wrapper around Nim code and I'm really looking forward to implementing some optimized inner loops for our main Python application at work.
Generative linguistics is largely discredited these days. It has been out of fashion for a little while, but the last few years have seen studies that more concretely disprove it.
[email protected]
[ my public key: https://keybase.io/zdsmith; my proof: https://keybase.io/zdsmith/sigs/nn3-X3J7_ifPWLjxXAIjIUqBjcVfDja9v4vLKxvf8-M ]