crux

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.

Thank you - I wrote that!

Happy to discuss further if anyone has any thoughts.

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!

Tarot (tarock, tarok, tarokk, tarocchi) games are all played with five suits.

Teach your kids Tarock, not Bridge.

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.

Here’s the home page for my static site generator, generated, of course, by the static site generator: https://bagatto.co/

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.

Just in case anyone else was wondering, because it took me some googling: that stands for Art of the Metaobject Protocol.

I think to be fair I can't even claim the joke.

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.

My company has several Nim services in production. Here's an open-source component I wrote that we use:

https://github.com/makingspace/syphus-nim

You, with the rest of us, have been treated to more than enough coverage of the issues at Uber to know that this isn't a series of isolated incidents.

If you really wouldn't stand for this sort of thing, then quit your job.

I use Fossil whenever I can. Unfortunately, this means I have only ever used it for projects where I'm the only contributor.

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.

A few years ago I wrote my own toy ACH framework! I would love to come help out.

I worked at Tekserve for 2 years. It's quite interesting to hear the strong emotional responses that many people express about its closing.

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.

Remarkable how Wolfram can turn any occasion to a celebration of his own achievements and preoccupations.

What's Novice? It's extremely difficult to google.

I feel it's appropriate to link to a Python module I wrote some time ago exploring this book and the systems behind it: https://github.com/subsetpark/necktie

(The link in the read me is unfortunately expired)

I made a custom one that I like:

   -.5 | 1.5 | -.5
   1.5 | -3  | 1.5
   -.5 | 1.5 | -.5

This sort of tone is toxic and anachronistic in the extreme. Please consider the sort of environment you contribute to when you relate to strangers in a public community in this way.

He gives the lie to himself by (almost compulsively!) categorizing his 'marks' as impolite when he feels that they've failed to realize or follow the same rules that he understands so well. It's well and good that he's willing to give people the benefit of the doubt if they're having a bad day, but being unable to relate his coworker's compliment without also noting that it is, in fact, the mark of an impolite person demonstrates that, at core, he doesn't hold her in particularly high esteem. So what's the point of being polite?

Are there languages that include the strong type checking, inference, and typeclass functionality of Haskell while also being a little more forgiving in terms of purity, so that writing ordinary programs is not quite so troublesome as in Haskell?

Good question. In the library, intercalary days are just their own month. So it would just be 2015-14-1.

Sure. The one liner is: spend as much of your free time and energy focusing on giving and helping others rather than enriching yourself.

Find ways to delight in the well-being and success of others—all others, everybody you know, everybody in the world. And when you feel that you aren't getting your fair share, that you'll miss out—take a long, long pause, really feel into that emotion, and see if self-centered thinking ends up getting you more of what makes you happy or not.

Mind: this is incredibly difficult. It's nobody's fault if they can't or don't do this. Almost every single meme and conditioned habit that's in you and the culture you live in works against this pattern.

This is a charming article. But it's somewhat sad to read. Because it operates on the nearly universal assumption that life is a game, or a battle, or a scavenger hunt—and the way to win is to maintain a high 'state' and get lots of 'achievements'. The reason this gaming terminology is so appealing to us is that it overlays nicely on the way we already think about life: you're constantly making some grade or another; you're constantly doing better or worse than your peers. A generation ago business was the most appropriate metaphor. But whether our obsession is with who's giving us a raw deal and who we're getting over on, or where we have advantages and where we have disadvantages (what am I at +1 for?), the basic sensibility doesn't change.

The perspective here is consistently egoistic. It's not even mentioned. It's just assumed that the way one goes through life is as an individual, with one's own interests solely at heart, and one's own state the only thing to be managed. You win by maximizing your own state, by grabbing as many achievements as you can before you die. And even if you're not a dick about it, your concerns are very much limited to your states, health level, and the contents of your inventory.

This is no way to go through life! It leads to suffering and a small view of things. I'm really interested to see, actually, what this community makes of that insight. It will dawn on people eventually—or at least its negative will: that everything we've been putting so much damned energy into isn't making us happy. But this community is so relentlessly introspective, communicative, articulate, well-equipped, and outright successful. And we have so many blogs like this one: so many people actively, sincerely, unabashedly interested in the science of happiness and fulfillment. So the potential there is pretty big. The potential for massive burnout and dissolution or massive reorientation.