2,469 karma · joined December 7, 2014
It wouldn't make sense to say "I've grown out of being impressed by complex prose" - you're welcome to enjoy Faulker or not, but he simply didn't have the same goals as the authors of the Stripe documentation, and judging both pieces of writing by the same standard is basically pointless (except, perhaps, as an art project of its own).
I'd even apply this to coding itself. Day to day, I think everybody around me should be writing Blub, grug-brain code, but I'm happy there are people trying creative, weird languages and mind-bending ideas elsewhere and I'm curious what they find out.
It's frankly unbelievable how frequently this happens. "Swimming around" in these concepts inspires solutions that otherwise seem to come from nowhere.
My impression after my own, shallower dive is that trainable dictionaries are an underappreciated part of the (or at least my) system design toolkit.
For example, say you're serving Wikipedia - a bunch of pages that are kind of static. In order to minimize disk space, you'll be tempted to compress the content. Compressing the whole corpus gets a good compression ratio, but it means that, to read an arbitrary item, you need to decompress everything (or 50% of everything, on average, I guess).
So to get random access, you compress each page. That's ok, but you get a worse compression ratio because every compressor starts from scratch.
But with Zstandard and a trainable dictionary, you could train a dictionary on a couple pages, then use that dictionary to compress and decompress arbitrary items.
As far as I can tell, that's probably the best of both worlds - close to the compression ratio of compressing the whole corpus with gzip, but the random access of compressing each item individually.
This seems really generalizable - e.g. maybe Facebook has to store a zillion photos that are very rarely accessed, but 10% of them are selfies. If we use a vector search to find clusters of similar items, we can compress those items with a single dictionary.
In fact, taking another step back, it seems like databases ought to offer this out of the box. Just like the concept of an index, it's not always a win and there are a lot of knobs that you might want to tune, but the benefits seem clear.
Maybe all of this already exists, or there's something I'm missing, but I really appreciate article's like OP's that break things down so clearly.
Smokey would have a different tone too. "Only you, plus our array of guided missiles, can prevent forest fires."
Beard? :)>
I think Joel Spolsky explained the main Office moat well here: https://www.joelonsoftware.com/2008/02/19/why-are-the-micros...
> ... it might take you weeks to change your page layout algorithm to accommodate it. If you don’t, customers will open their Word files in your clone and all the pages will be messed up.
Basically, people who use Office have extremely specific expectations. (I've seen people try a single keyboard shortcut, see that it doesn't work in a web-based application, and declare that whole thing "doesn't work".) Reimplementing all that stuff is really time consuming. There's also a strong network effect - if your company uses Office, you'll probably use it too.
On the other hand, people don't have extremely specific expectations for LLMs because 1) they're fairly new and 2) they're almost always nondeterministic anyway. They don't care so much about using the same one as everyone they know or work with, because there's no network aspect of the product.
I don't think the moats are similar.
The obvious military applications for this technology are explored in Tom Clancy's novel "Rainbow Six" (1998).
I know this is a consequence of NP-completeness and so on and so forth, but I also find it a funny and charming way to phrase it. Once we've solved the fundamental problem (what courses to take), we're able to solve simple specializations and derivatives (boolean satisfiability).
Interesting to read in light of the other recent item "How I ship projects at big tech companies": https://news.ycombinator.com/item?id=42111031
> You only know you’ve shipped when your company’s leadership acknowledge you’ve shipped. A congratulations message in Slack from your VP is a good sign, as is an internal blog post that claims victory. For small ships, an atta-boy from your manager will do. This probably sounds circular, but I think it’s a really important point.
> There are a lot of ways to put your money into the stock market; some of them feel mostly like “fun gambling,” while others feel like “boring sensible investment of retirement savings in the long-term growth of the economy.” A lot of retail brokerage accounts will let you do both. If you are young, carefree and confident, and don’t have very much money, you might gravitate toward the gambling stuff. And then later, as you get more money and responsibility and grow up a bit, you will get more curious about buy-and-hold investing in low-cost index funds.
> And you can do both of those things — and transition between them — in the same brokerage account. This is good! Arguably it is socially useful for brokerage apps be competitive with, say, sports gambling apps, to be as fun and easy-to-use and exciting and risky as sports gambling. Because investing is competing with sports gambling for young, risk-seeking people’s attention. But the brokerage app is better positioned to transition those people into boring responsible investing. There is no analogous transition in sports gambling. Here is a recent paper finding that sports betting “does not displace other gambling or consumption but significantly reduces savings, as risky bets crowd out positive expected value investments.” Zero-day options are, arguably, a bit better than that.
> Again you cannot get too carried away with this theory. Is it socially beneficial to introduce riskier and zanier financial products to retail brokerages? Well, if the zanier products lure customers away from sports betting, and start them on a road to mature sensible investing, then yes. If the zanier products lure customers away from index funds, and start them on a road away from sensible investing, then no. I’m not sure there’s an a priori answer.
0. https://github.com/google/closure-compiler/wiki/Annotating-J...
"... it has been argued that there are cases in which it is not possible to determine whether two programs are the same without making reference to an external semantics. Sprevak (2010) proposes to consider two programs for addition which differ from the fact that one operates on Arabic, the other one on Roman numerals. The two programs compute the same function, namely addition, but this cannot always be established by inspecting the code with its subroutines; it must be determined by assigning content to the input/output strings"
"The problem can be tackled by fixing an identity criterion, namely a formal relation, that any two programs should entertain in order to be defined as identical. Angius and Primiero (2018) show how to use the process algebra relation of bisimulation between the two automata implemented by two programs under examination as such an identity criterion. Bisimulation allows to establish matching structural properties of programs implementing the same function, as well as providing weaker criteria for copies in terms of simulation."
(Of course, it isn't surprising that this would be relevant, because proofs and programs themselves are isomorphic).
This technique seems rather stricter than what Gowers has in mind, but it seems helpful as a baseline.