Little tidbit that isn't mentioned in the article: he was a consultant on the film Quest for Fire and developed movement patterns and gestures for the actors.
In the business of apparel, I think this is a natural consequence of high-end buyers turning their noses up at long-lived brands, and working to differentiate themselves from mainstream middle-class buyers. It's a revolt against modernism making more and more goods accessible to people outside the economic and cultural elite.
If you're fancy, what do you do when mass production and the internet make the markers of fanciness accessible to the very people you're trying to be fancier than? For one, you stigmatize mass production and elevate artisanal handmade goods. Those are inherently impossible to democratize. Another thing you can do is replace the appreciation of quality with the act of discovery as proof of elevated taste. Make taste a moving target, so the dirty unwashed masses are always a step behind.
Brands like Brooks Brothers or Eddie Bauer have no place in this system. The best the masses can do to imitate the elites is buy cheap fast fashion from brands that go viral and don't live long enough for anyone to know their quality before they're gone.
> If you're fancy, what do you do when mass production and the internet make the markers of fanciness accessible to the very people you're trying to be fancier than?
We need a Manhattan Project for curing Cluster B disorders.
Flippant answer: in the U.S., in your twenties, you have no spare space, and visiting friends sleep on your couch. In your forties, you have a guest bedroom, and visiting friends stay at a hotel.
Possibly more accurate answer: it depends on what kind of housing people live in, if they have kids, and if they work at home. Most residential houses were built for couples with children, so if someone owns a house and is single and/or childless, they likely have spare bedrooms that serve as a home offices, hobby spaces, or guest bedrooms. People living in apartments usually don't pay for more space than required for their daily needs.
I don't think that's the way you're supposed to read it? I think you're supposed to read it as, the trendy extremes tell you something about a place, even if the details are silly and ephemeral. People with no filter, no shame, no interest in correctness or consequences, and no pole star except trends are like a cartoon guide to the trends and the mentality driving them.
I think the author would agree with most of what you wrote.
I interpret YAGNI to mean that you shouldn't invest extra work and extra code complexity to create capabilities that you don't need.
In this case, I feel like using the filesystem directly is the opposite: doing much more difficult programming and creating more complex code, in order to do less.
It depends on how you weigh the cost of the additional dependency that lets you write simpler code, of course, but I think in this case adding a SQLite dependency is a lower long-term maintenance burden than writing code to make atomic file writes.
The original post isn't about simplicity, though. It's about performance. They claim they achieved better performance by using the filesystem directly, which could (if they really need the extra performance) justify the extra challenge and code complexity.
Honestly, at this point, if I had a design that required making atomic changes to files, I'd redo the design to use SQLite. The other way around sounds crazy to me.
"Why use spray paint when you can achieve the same effect by ejecting paint from your mouth in a uniform high-velocity mist?" If you happen to have developed that particular weird skill, by all means use it, but if you haven't, don't start now.
That probably sounds soft and lazy. I should learn to use my operating system's filesystem APIs safely. It would make me a better person. But honestly, I think that's a very niche skill these days, and you should consider if you really need it now and if you'll ever benefit from it in the future.
Also, even if you do it right, the people who inherit your code probably won't develop the same skills. They'll tell their boss it's impossibly dangerous to make any changes, and they'll replace it with a database.
> They'll tell their boss it's impossibly dangerous to make any changes, and they'll replace it with a database.
This, 100%. Development today is driven by appearances though, you can take advantage of that. Give it a cute name, make sure you have AI generate an emoji-rich README for it, publish it as an open source npm package, then trigger CI a few thousand times to get a pretty download count. They will happily continue using it without fear!
If you start a new job and on your first day they go "Yeah the last guy said we don't need a database, so he rolled his own." are you gonna be excited, or sweating?
Exception being perhaps "The last team chose to build their own data layer, and here's the decision log and architecture docs proving why it was needed."
Serious question, why are people here acting as if formatted files are somehow more reliable than a DB? That just simply isn't true. For most of software development's history, using flat files for persistence of data was the wrong thing to do with good reason. Flat files can easily be corrupted, and that happens much more often than a DB gets corrupted. The reason you might think otherwise is just sampling bias.
I do believe that you are missing a healthy dose of sarcasm. Such as faking downloads to give yourself inflated statistics so that your employer will trust untested and AI-written garbage.
That said, there really are good use cases for readable formatted files. For example configuration files that are checked into source control are far more trackable than a SQLite database for the same purpose. For another example, the files are convenient for a lot of data transfer purposes.
But for updateable data? You need a really good reason not to simply use a database. I've encountered such edge cases. But I've encountered a lot more people who thought that they had an edge case, than really did.
The problem is that most of the time when you want "atomic changes to files" the only safe API is copy the file, mutate it, then rename. That doesn't factor in concurrent writers or advisory locks.
If that kind of filesystem traffic is unsuitable for your application then you will reinvent journaling or write-ahead logging. And if you want those to be fast you'll implement checkpointing and indexes.
Advice like this turns almost everybody's normal state into a disorder.
"Go to sleep only when you are very tired" is a child's approach to sleep, it's what we all want to do, and by adulthood we learn that it's counterproductive. But we still want it so much that we regularly test it and are reminded why we don't operate that way.
It reminds me of the intuitive eating folks who say, "Ignore standard diet advice, just listen to your body and feed it what it knows you need," but then when you overeat, they say, "You aren't listening properly, you aren't in tune with your body." Then if you ask, "How will I know when I'm in tune with my body and listening to it properly?" they say, "When what it asks for matches standard diet advice."
If my Oura ring can be trusted, alcohol doesn't interfere with my total amount of sleep or my REM sleep, but it reduces my deep sleep drastically and can even result in me getting zero deep sleep, which hasn't happened a single time without alcohol.
Honestly, if I could quit my job for six months and work in a codebase like yours, I'm extremely curious what I could accomplish with AI.
We have a codebase at work that was "stuck." We've consistently done minor library upgrades, but no major upgrades in several years, and was recognized as a major piece of technical debt / minor disaster for almost two years, in that we urgently needed to dedicate an engineer to it for a month or more to bring it up to date. We also suspected that framework upgrades would improve performance enough to save us a little bit in operating costs. I got curious, created a branch, and threw Claude at it. Claude knocked it out in a couple of days while I mostly worked on other things. Then we dedicated several engineer days to doing extra manual testing. Done and deployed. Now we're ready to experiment with giving it less resources to see if the performance improvement holds up in practice.
This codebase was only about 200k lines of code, so probably smaller than yours. Really curious how it would go with a larger codebase.
EDIT: Claude may only have taken a couple of days because I was only checking in occasionally to give it further instructions. I don't know how fast it would have been with my complete attention.
You couldn't go far on those early Prius batteries. I had a circa-2009 Prius and semi-intentionally ran out of gas to see what happened. I was able to drive a couple of miles to a gas station, but the battery was depleting extremely quickly, and I doubt it would have lasted ten minutes.
reply