I broadly agree, but expensive homes are an odd example because, like, you can just sell the house later. There might be some opportunity cost relative to investing in a broad market ETF or whatever, but that's not the sort of difference that makes or breaks your early retirement strategy.
It's a bit odd to get moralistic over saving/spending money in general, but that's especially true around expensive homes.
why would it be especially true around expensive houses?
When you own a house, you are still paying an implicit rent to live in it (the opportunity cost of the rent that someone else could pay you instead).
Given that in almost all locales it is so much better financially to rent than to buy right now, Buying a 5m$ house is probably one of the least financially responsible things you could do in the current climate (And especially in the Bay area where the buy-to-rent ratio is all time high)
This is definitely not uniform. I worked on inventory management at Target, and stores had quite a lot of shelf space—to the point where we'd hold large amounts of cheap, non-perishable stuff like cat litter because, well, we had the space for it.
Stores also wanted to look full. We actually had parameters in our inventory management logic to increase inventory just for presentation reasons. If inventory is expensive, having some free, quality inventory can be valuable in and of itself even if it moves slowly.
Bricks and Minifigs stores are like 2000 square feet, much different than a Target. Their overhead per square foot is almost certainly far higher than Target.
Sounds like OxCaml is pretty close to what you want. You get access to similar capabilities as Rust, but also stricter typing and an (optional) effect system. I don't know of an equivalent to Liquid Types, but it seems like the same approach that worked for Haskell would work naturally in OxCaml.
You need a huge corpus of training data for the language for models to be good at using it. Rust has that (so does Go). OxCaml probably does not (unless there's some iceberg of open code out there that I'm unaware of). I'll take a slightly sub-optimal language with excellent training data coverage of my use case over a perfect language that the models have barely seen 100% of the time.
Which is why I think it's silly to suggest creating a new language "for agents". Unless one or more of the frontier AI companies commit to creating a language and the training corpus for a new language, there's no good way to bootstrap a language that is ideal for agents. You need the huge pile of high quality code as a prerequisite for a language being good for agents. And, the argument applies similarly poorly for some language that looks like it has a good shape for agents, if it doesn't have a lot of human written code from the past decade or whatever. It's not a good language for agents unless agents already know the language really, really, well because of a huge pile of code in that language in its training data.
Over my time in the industry I've become increasingly convinced most people haven't seen what good human programmers are like. Otherwise we wouldn't have the popularity of things like Scrum, Clean Code (the book, not the concept), etc.
I was lucky enough to see some good teams when I was a student (both at Berkeley itself and by interning at Jane Street), and it totally changed my intuition for what good programming is like. It's gotten to the point where I'm convinced there are two incommensurable paradigms in programming, and we're constantly talking past each other.
Like, if you have an ongoing project where the codebase has grown over time, do you expect it to get easier to do things or harder? I've worked on projects where it's obvious that things are always getting harder (old code is hard to change, you have to deal with lots of complexity and edge cases and workarounds). I've also worked in codebases where things got easier over time: you get better abstractions, more libraries, more capabilities. That can be a lot of fun; you think of a new thing to try, and you have the pieces to just do it.
Or another point of comparison: do people think that writing good code slows you down (so it only makes sense to avoid bugs), or do people think that writing good code lets you move faster? I've talked to people for whom one or the other is totally and obviously true. (I'm solidly in the second camp myself.)
But the surprising thing was how "obvious" the dynamic was in both cases, even though the two cases are exact opposites of each other! If you ask one group or the other they'd just tell you that, well, that's simply how programming works. Of course things get (easier|harder) over time. That's built into people's fundamental understanding of what programming is and how to do it. And that's exactly what I mean by incommensurable paradigms.
Anyway, this is a bit of a tangent from the main discussion, but it's something I've been thinking about a bunch over the last few years, partly inspired by the advent of AI-powered programming, but largely thanks to experiencing some very different projects and teams...
I think you can get to "easier" if you have the a) budget to hire the people that are good enough and b) the time and discipline to create the abstractions so it gets easier over time.
Most shops will not have that kind of time and money, so the default will be "harder". Also, to be fair, most shops will not be led by individuals that understand why ensuring things get easier / faster is important in the short term, so that also complicates things a bit.
Thank you for drawing the distinction. I've noticed that while ~80% of Uncle Bob's ideas are good, he doesn't seem to have been very good at implementing them, and he often does so in ways that contradict other principles. Much the same with Fowler and other names from that era/community.
> But the surprising thing was how "obvious" the dynamic was in both cases, even though the two cases are exact opposites of each other! If you ask one group or the other they'd just tell you that, well, that's simply how programming works. Of course things get (easier|harder) over time. That's built into people's fundamental understanding of what programming is and how to do it. And that's exactly what I mean by incommensurable paradigms.
Although I mostly see it get harder over time, it certainly feels like it's supposed to get easier.
I’ve seen both side of the fence and if there’s one quality that seems to define that fence, it’s caring about the process. Both sides wants to archieve the same goal, but one care about the process (enough to make it less tedious) and the other don’t (whatever seems to work is Ok).
That’s why they say the best programmers are lazy. Not in the sense of avoiding any kind of work, but avoiding the kind of senseless stuff that’s surely to come down the line if you’ve not taken care of the process
That's an interesting point, and maybe that actually also explains the difference of people that believe that AI is making them more productive and people that believe it doesn't; if you never think about the architecture, then it becomes more slop over time, and it becomes harder to do anything. If you do think about architecture, development becomes easier and faster all the time. AI just accelerates both processes.
That's not true. It self selects for people who are focused on making money, not for the best software guys. There are for sure some people in that venn diagram who overlap, but it is not that self-intersecting. This is mainly because the best software guys are rather more interested in doing their own thing and hacking on whatever interests them, rather than what their boss wants.
It also only self selects for those who want to work in stressful/long working day environments, rather than those who value stability.
I'm failing to understand GP's logic here. Why would someone who's posting some TV show's content in complete disregard of their intellectual property rights be bothered about AI scraping?
Keeps their videos from being taken down automatically by platform content filters. It’s an additive audio track - a running summary of the clip most of the time, and so I imagine this is some fair-usey anti takedown protection. It’s everywhere on short form sites.
Reminds me of my favorite math essay: "When is one thing equal to some other thing?"
It's a great question, much deeper and more interesting than it seems. The essay suggests thinking in terms of isomorphisms (relative to the structure you care about) rather than equality in some absolute sense, and I've found a fuzzy version of that to be a really useful perspective even in areas that can't be fully formalized.
Mathematics is all just explanations for why this is really that. If it didn't have to respect its human audience, and their failure to grasp similarities, the whole edifice could be one implicit statement. (After all, since this is really that, there is no this or that.) So mathematics is about people.
It's a bit odd to get moralistic over saving/spending money in general, but that's especially true around expensive homes.
reply