Ironically, no

I recall an article on personalized pricing that had it reversed - the poor pricing is actually higher, bc it's harder to buy more at bulk rate / shop around / just not buy it (discretionary).

Yes, aka the boots theory or at least similar to it: If you can afford a higher upfront price you have options with a better value over the products lifetime - bulk discounts are just a special case of that.

That doesn’t look super awful to me? Hardly extreme code golfing.

The far more interesting part is the order of magnitude. If they can pull off a 20k LOC with zero dependencies (implying a pretty concise project size) and it still works well on meaningful applications, that’s pretty neat. A 1000x reduction in code size and matching/exceeding in perf is worth looking at. Probably also implying a better architecture as code golf isn’t gonna get you 1000x less code. Again - their claims not mine, so we’ll see.

But at that point they can triple the LOC to 60k with nothing but white space, new lines, and comments, for all I care. It won’t even add a zero.

it looks dense but perfectly readable. arguably more readable that way than if it had a bunch of extra new lines, definitions, and code blocks spreading the logic out into a larger visible area.

I'm inclined to agree. While not always appropriate or popular, it makes some sense to me to have the visual weight/area of the code being ~proportional to it's significance. Communicates the ideas more clearly. Instead of spending the majority of space telling me what _isn't_ going to happen, and hiding what is.

I often find myself wishing this was more ergonomic in languages.

Amazing! I wonder if the Every Noise At Once[1] site could be updated with the metadata from this?

[1] https://everynoise.com/

Thanks for linking that page, interesting rabbit hole that I hadn't heard about until today…

I’m working on a new UMAP alternative - curious what kinds of improvements you’d be interested in?

A few things

Table stakes for our bigger users:

- parity or improvement on perf, for both CPU & GPU mode

- better support for learning (fit->transform) so we can embed billion+ scale data

- expose inferred similarity edges so we can do interactive and human-optimized graph viz, vs overplotted scatterplots

New frontiers:

- alignment tooling is fascinating, as we increasingly want to re-fit->embed over time as our envs change and compare, eg, day-over-day analysis. This area is not well-defined yet common for anyone operational so seems ripe for innovation

- maybe better support for mixing input embeddings. This seems increasingly common in practice, and seems worth examining as special cases

Always happy to pair with folks in getting new plugins into the pygraphistry / graphistry community, so if/when ready, happy to help push a PR & demo through!

> alignment tooling is fascinating, as we increasingly want to re-fit->embed over time as our envs change and compare, eg, day-over-day analysis. This area is not well-defined yet common for anyone operational so seems ripe for innovation

It is probably not all the things you want, but AlignedUMAP can do some of this right now: https://umap-learn.readthedocs.io/en/latest/aligned_umap_bas...

If you want to do better than that, I would suggest that the quite new landmarked parametric UMAP options are actually very good this: https://umap-learn.readthedocs.io/en/latest/transform_landma...

Training the parametric UMAP is a little more expensive, but the new landmarked based updating really does allow you to steadily update with new data and have new clusters appear as required. Happy to chat as always, so reach out if you haven't already looked at this and it seems interesting.

Mentioned in the article's comments:

> Why not use UUID7?

> "ULID is much older than UUID v7 though and looks nicer"

For those unfamiliar, UUIDv7 has pretty much the same properties – sortable, has timestamp, etc.

ULID: 01ARZ3NDEKTSV4RRFFQ69G5FAV

UUIDv7: 019b04ff-09e3-7abe-907f-d67ef9384f4f

UUID 7 is so much easier than the ULID in the article manipulate. Pretty much every language and database has the string manipulation and from_hex functions to extract the timestamps without any special support function. Whereas a format that is too clever is way more complicated to work with.

UUIDv7 looks better in the eye of this beholder.

I know it may sound stupid but in my latest project I chose ULIDs because I can easily select them as one word, instead of various implementations of browsers, terminals, DB guis, etc each have their own opinion how to select and copy the whole UUID. So from that point of view ULIDs "look" better for me as they are more ergonomic when I actually have to deal with them manually.

I don't think it's stupid and this is one of the reason I prefer ULIDs or something like it. These IDs are very important for diagnostics, and making them easily selectable is a good goal in my book.

It’s also quite common to base62 the UUID value so in this case “31prI2bsccbXJB7cvbtV9”

Of note, Sam’s co-founder in Atomic Semi is none other than Jim Keller (!)

On the contrary, I think that was a wonderful answer and reflects the POV well. Hard to imagine something more Stallman-esque!

Ghostty is a terminal like iTerm. This compiles it so it runs in the browser directly, or browser-based environments like VS Code or the Hyper terminal. Without that you’d have to reimplement a whole terminal in JavaScript. Which is what people have been doing with via the xterm.js project. Naturally, there is effort and bugs that go into maintaining a clone/port like that. This lets you use the Ghostty terminal code directly - compiled to WebAssembly and with no other dependencies - as an API-compatible drop-in replacement

Only other relevant thing to add is that Ghostty is also written in zig and makes for a good showcase of the language.

There are a couple philosophies in that vein, like finitism or constructivism. Not exactly mainstream but they’ve proven more than you’d expect

https://en.wikipedia.org/wiki/Finitism

https://en.wikipedia.org/wiki/Constructivism_(philosophy_of_...

That looks closer to https://en.wikipedia.org/wiki/Ultrafinitism