> I've spent a lot of time writing my own random queries. I don't know that I've ever written a stored function.
And I've spent a lot of my working life cleaning up after people who write random queries who then start blaming the database for being "slow" and insisting they need some sort of over-engineered Redis caching layer or whatever.
100% of the time the database is perfectly fine, but the query is slop.
Not saying you are one of them, but you would very much be in the tiny minority if you are not. ;)
I think it's a bit nuanced, and maybe poorly explained by the original author, but to me, "left-pathers" are always "move fast and break things" to the point that whatever they build really only works as a throw-away prototype, and the effort to architect sensibly is minimal.
"We don't really need to use REST, we can just create some endpoints that have undocumented side-effects. We don't need to abstract vendor calls into a separate class, we can just implement that functionality directly in our endpoint code."
These sorts of decisions aren't actually materially faster, they're just lazier. And maybe that's "a sprinkle of QC"? But it's a lot of unforced errors that don't really save time to implement, and also create a lot of problems later on.
On the other end, with the "right-pathers", you can have people that really try to over-engineer at any opportunity. This is sort of typical of people who have worked in much larger teams. This can mean building out a k8s cluster when you're still a team of 2-3 people, splitting into 10+ microservices, deciding to use Kafka when a simple queue system would work, building out in-house load balancing for dubious reasons, etc.
The middle path is really something that resembles the "Best Simple System for Now" — when I've done this, I think about how I can solve a problem and not have to rebuild it entirely within 12-18 months.
The middle path is people that know that to scout around, you hack quick paths. Then you document your new learning, plan the best road, and then build enough for the actual journey. Every now and then, you go back and adjust everything to account for actual usage.
I’ll go on record and say that AGI will never happen (in the next 50 years). I think that’s also the timeline for white-collar job automation that requires critical thinking.
Google's definition is sufficient[0]. I'd also go so far as to say that LLMs aren't even AI, but that can be a bit pedantic. I align with Richard Sutton's reasoning, in that LLMs (and GPT models more generally) aren't "intelligent" in the same way that RL models are[1].
Small-language models also use GPT. And I agree it's not "LLM vs RL" and that they're orthogonal, however, RL has features that more clearly resemble intelligence.
With integers/floats, he's saying it's not opinionated enough. Anything other than integers with minor-unit precision, unless you have a very good reason, is a bad idea. So "floating point is almost a bad idea" doesn't go far enough, and the other alternatives are presented somewhat equally.
The FX critique is saying that it's glossing over a lot of the complexity. I'd say the same is true for the treatment of DE ledgers, and it borders on bad advice (e.g. "Balance is never stored. It’s derived from the movements of money.")
> Anything other that integers with minor-unit precision, unless you have a very good reason, is a bad idea.
The article clearly communicates this sentiment, no? What else needs to be said? How much further does it need to go, and why?
It might be a mistake for either us or the handbook to be absolute or dogmatic about floats. It’s not a sin to mention that they exist, and it’s a fact that some people in fintech use them for some reasons that have a defensible engineering position and well considered tradeoffs. I’ve been on the side of assuming people don’t use floats for money and then been surprised when I bumped into people here on HN who report using floats in finance routinely.
BTW, is your quote “almost a bad idea” a typo? There’s a world of difference between ‘almost a bad idea’ and ‘almost always a bad idea’. The actual words in the article, if we’re quoting the article, are: “almost never a good idea” in reference to using floating point types.
> it’s glossing over a lot of the complexity.
Of course it is, that’s a good thing. It’s not pretending to be a spec or rules, it’s an introduction and general principles. The article is already introducing new complexities that people outside of fintech might not be aware of. But do we really have to mention ALL complexity? The biggest problem with Wikipedia is that it’s overrun by nuance and complexity, so much that you often can’t read an article on a topic without already being an expert on that topic. This is why experts are often bad teachers. Being unable to gloss over some complexity is not good for learning and doesn’t make a good environment for newcomers. Let’s allow people to write for non-experts and make room for learning. We don’t have to avoid glossing over some of the complexity; it’s useful to get the general direction and gist correct while leaving out some of the detail.
> it borders on bad advice
Be specific. What’s wrong? Note that contributions are invited.
"Monetary value must be stored in integers" is the much stronger statement that the article doesn't make. Obviously there are exceptions, but you're going to need a much longer side discussion in order to justify why you're using floats.
It's like saying "don't write your own crypto algorithm". Of course write your own crypto algorithm, that's how you learn about cryptography. But you'd never put your homegrown cryptographic algorithm into production until after several PhDs worth of understanding of cryptography has been put into it by many other people.
>"Monetary value must be stored in integers" is the much stronger statement that the article doesn't make. Obviously there are exceptions, but you're going to need a much longer side discussion in order to justify why you're using floats.
It doesn't make that statement because arbitrary precision decimals exist. Binary float is not the only and not the most plausible alternative to using integers.
For me quickly scanning over the article, the fact that floating points were even presented as a possibility was an immediate red flag. And I pretty much stopped taking the rest of it seriously.
Without regulation, yes. Brokers (i.e. scalpers) will buy up tickets to events and take all of the risk off of TM’s plate, and reprice however they’d like. ~80% of tickets in the U.S. are sold this way. Stubhub has done a great job of lobbying for this since their existence depends on ticket brokers.
If you want to see what that looks like, I one-shot a browser with Claude that does it[0]. Docs pages are early adopters to this[1][2], so that AI agents can better handle tasks.
