How do you go from SaaS to “not super challenging”? The part of a SaaS product that I’m working on uses graph algorithms to work with what’s essentially an interactive form. There’s some mildly university-level computer science stuff and it’s mixed with enough domain expertise that Opus 4.7 is still unable to make even small changes without breaking everything or going against the architecture.
Poor? In what sense? I graduated a few years ago (in Europe) and I think I could’ve gone through my entire education without owning one. Math, for me, went from nice numbers to ugly numbers that you had to do by hand (because that was the point), then to just letters and squiggles.
At no point was there a need to work with hard numbers or to learn to work with a physical calculator (I haven’t seen one in the wild in years).
The other day I calculated what it would take to run my entire country on pure solar, assuming magical infinite storage capacity. Even here in Central Europe, the required area for all the panels was a pretty insignificant number that, even if built as a single huge circle, would easily fit in many different places.
Same for apps and games. I understand English just fine, no need to switch to your shitty Google-translate localization just because my iPhone or PlayStation is set to my native language.
For me it’s not about the numbers It’s 800€ for a laptop that’s not total junk. I could probably get the same 8 or 16 and 512 numbers in cheaper laptops, but they would be [what I would consider] sad annoying plastic junk.
What I see is 800 EUR for a sturdy body, a solid screen, a solid keyboard and good battery life. That's the baseline for what I want in a laptop. Only after these boxes have been checked, we can start talking numbers. And you know what, even 8 and 256 is still perfectly usable for me. Two years ago I was still using a MacBook Air with 256 GB SSD, happily. Now my wife is using it, happily.
Good. The article makes sense to me, it gives names to certain things I've already sort of internalized intuitively and not only does it not end with a proposal to use AI to fix everything, it actually explains how AI (or at least today's LLMs) fails at the same boundaries as we do, which is exactly what I've been seeing so far.
I'm looking forward to whatever these people come up with, because I believe they do understand the problem, which is the best starting position you can have.
> The problem of course is that type systems and databases are not meaningfully "domain-specific." They aren't technical magic bullets but they separately provide real value for the use cases of "web and API serving, transaction processing, background processing, analytical processing, and telemetry." So then why hasn't the industry settled on a specific type system? Why do database vendors (and the SQL standard) keep breaking the relational model in favor of something ad hoc and irritating?
I'm not sure what point you're trying to make here. The list you're referring to is definitely a bit hand-wavy, but it also makes sense to me to read it as, for example, "today's relational databases (software) are almost perfectly aligned to the domain of relational databases (concept)". As in, MariaDB running on my Mac wraps an insane amount of complexity and smarts in a very coherent system that only exposes a handful of general concepts.
The concepts don't match what I'd like to work with in my Rails app, which makes the combination of both a "fragmented system", as the article calls it, but the database itself, the columns, tables, rows and SQL above it all, that's coherent and very powerful.
It depends on what you mean by "almost perfectly aligned to the domain of relational databases" but by my standards I can't think of a single production database where that's true, in large part because it's not true for SQL itself.
- Tables are not relations. Tables are multisets, allowing duplicate rows, whereas relations always have a de facto primary key. SQL is fundamentally a table language, not a relational language.
- NULL values are not allowed in relations, but they are in SQL. In particular, there's nothing relational about an outer join.
In both cases they are basically unscientific kludges imposed by the demands of real databases in real problems. "NULL" points to the absence of a coherent answer to a symbolic rule, requiring ad hoc domain-specific handling. So this isn't a pedantic point: most people wouldn't want to use a database that didn't allow duplicate rows (the SQL standard committee mentioned a cash register receipt with multiple entries that don't need to be distinguished, just counted). Nullable operations are obviously practical even if they're obviously messy. Sometimes you just want the vague structure of a table, a theory that's entire structural and has no semantics whatsoever. But doing so severely complicates the nice symbolic theory of relational algebra.
That's the point I'm getting at: there isn't really a "domain" limitation for relational algebra, it's more that there's a fundamental tradeoff between "formal symbolic completeness" and "practical ability to deal with real problems." Eventually when you're dealing with real problems, practicality demands kludges.
If the article is a product of a LLM, I am willing to pay good money to be able to use that exact LLM for development. Because it seems to understand many things that current LLMs and their loudest proponents don't seem to understand.
That isn't some turbo specialty, the effect is the same in both NA and turbo engines. And AFAIK it isn't really feasible anymore. I don't know about other manufacturers, but for example Volkswagen Group's EA211 EVO2 engines run pinned at lambda 1 no matter what.
All I know is my last turbo'd vehicle was always running at 13.8, and that was a 2013 Nissan with a turbo'd L4, and it annoyed the piss out of me. Pretty much guaranteed only getting 26 MPG at highway speeds. This was despite claims in the manual saying the AFR was fuel octane dependent & would automatically vary (which I found out through experimentation was full of shit). It just stayed pinned to 13.8 whether you ran 87 or 91.
> overstrain them, and put huge turbos on the engines
This doesn't really mean anything. You can build an engine at any point of the spectrum from naturally aspirated to turbocharged, to turbo-compound, to actually not having any pistons at all (e.g. the "turbofans" that we put on airliners). What you want is to match the engine to the machine and build it out of the right materials.
Most people don't know shit about engineering and have weak intuition about materials, stress and physics in general. What the common person thinks about a random engineering topic literally does not matter, because they are 90% wrong about everything. Regarding cars, it's more like 99%. People still recite torque figures like they mean anything, ffs. That bad boy with 200 Nm at the crank? Cool, I make 150 Nm pedalling a bike.
My previous car before an EV had a 1-litre 3-cylinder engine, a 1.0 TSI. Pure gas, not a hybrid. That's an engine that's rated for 81kW (it actually delivers a bit more than that) and that can do 60 mpg on country roads (regularly). When it came out in 2015, "car enthusiasts" were laughing hysterically at the idiots who'd buy the car and have to replace the engine every 2-3 years. 11 years later, the cars are driving around just fine. The 1.0 TSI, just like the entire EA211 family, is a good engine with no major reliability issues.
So far I’m not that impressed.
reply