sanderjd

I'm fairly torn about this, honestly. When I was reading the list of "why not"s in the tweet, I just found myself wondering the converse. Why put time into solving those problems - accepting that it won't require nearly as much time as it would have previously - when there are existing tools that already solve those same problems?

You do provide an answer to this question in your comment, in this sentence:

> Ruby continues to have a good balance between expressiveness, and the ease of reasoning about the code, relative to the amount of annotations and boilerplate you need to throw in to get there.

But is "it is easier to read" really enough of a benefit? Even accepting that it is true, it strikes me as a pretty fundamentally aesthetic judgment, and I'm just not sure that matters enough. And is it even true? I feel like after doing this job for a couple decades, I don't find there to be huge differences in legibility between the common high level languages. This is especially true now that I'm reading far more than I'm writing, and relying on static analyses to determine correctness, far more than on my own interpretation of the code.

When I first got into rails, what was awesome about it was how much boilerplate it could either generate or abstract away for me. But my sense is that boilerplate has just become way less of a problem over time... So I'm left unsure what the killer feature of rails is anymore.

But this argument applies to pretty much any framework for anything, and I still think frameworks remain very useful. But maybe they just aren't very ... interesting? But then if everyone comes to that conclusion, then it's even harder than it already was to have a community of people contributing to the frameworks and caring about their quality.

I don't have a conclusion here, just this stream of thoughts about it!

Yeah. That law probably should include negligence though, IMO. It surprised me when I first saw the text of this law that it requires intent.

No? I don't really understand what "outside forces" you're talking about. Property taxes? I'm sorry but that's just an incredibly silly and entitled way to think about land ownership.

For the whole community. For everyone.

Schools closing are a symptom of a community that has not retained a healthy mix of people at different stages of life.

All else equal, I can see why the ability to live in the same house until you die would be given a high moral value. But in practice, IMO, this culture causes a number of problems. For instance, where I live, there was a lot of growth in the 70s and 80s, and a lot of young families, so they built a bunch of schools. It's an attractive place to live, so a lot of those people who lived in those houses when they were new and raised those families and attended those schools have kept living in those houses. But those kids that they raised there can't live in those same neighborhoods as adults, because there's no turnover, so they can't raise their own kids there. So now the schools are all half (or less) full, because the neighborhoods they were built to serve no longer have a lot of families living in them. So then they have to close and consolidate schools and everybody hates that. I don't really have a strong view on the moral question of whether houses "should" be owned by older people who have lived there a long time or by young people families, but from a pragmatic standpoint, this situation seems quite bad to me.

I think if we had a totally different culture, with multigenerational families living in the same house, then this might work better. But this model where we build new family friendly neighborhoods with parks and schools, and then nearly everyone ages in place and all the family amenities become empty over time, and the families all end up in the next new neighborhood and then it repeats, this doesn't seem ideal to me.

It's because you have a blind spot.

Yes but my point was about the attitude, not the aptitude.

No I don't think you misunderstood, I do think I broadened my take between my comment and my reply to you. I don't mean to imply that I think I have this all figured out or anything, I'm still playing with these ideas in my own mind and trying to figure out what I think.

But I do think that my general sense is that it is both similar in scale to the disruption of the web, and also very different in ways that are hard to suss out at this point.

Ok but I think this is just a kind of myopic view that is specifically focused on the things you were / are interested in. AI is a different paradigm that is changing things for a different contingent of people.

To try to demonstrate my point with an example: If you were a journalist, the web changed literally everything in a way that was inescapable. As a software engineer, it changed a lot for a lot of people but it was not inescapable. The situation with AI is, so far, the reverse. Journalists have mostly (and correctly IMO) concluded that this isn't actually that useful to their writing, and it hasn't changed their distribution channels in the way the web did. But for software engineers, it's changing things dramatically.

I guess my perspective is just that new paradigms are not uniformly disruptive.

Pretty much by definition, a new paradigm will be very different from the previously new paradigm.

Personally, I don't think the interconnected "social" nature of the web turned out very well. Maybe (probably) the "one-man bubble" nature of AI also won't turn out well. But I'm skeptical of holding up the web's social nature as a positive. I think it turned out pretty bad. (I shared everyone's optimism in the late 90s and early 2000s and I used to just be mad at Facebook / Zuckerberg for screwing it up, but I dunno, maybe it was always going to end up this way.)

Both of the comments replying to my comment so far are just demonstrating exactly the point I'm making!

Yes, software engineers have a giant blind spot about "what even is product management" and don't think it's hard. This is exactly what I'm saying!

This is the exact attitude that I'm talking about.

I think this actually gets at a big part of what is causing this existential crisis. You're right, I don't think it was ever true that "the hard part was figuring out what we want". I think there have always been two hard parts: 1. Figuring out what is useful, and 2. Implementing a useful thing well. The second of these has gotten a lot easier, which means the first has become more important. But software engineers have long had a tendency to underrate that first part and consider it easy. I have long perceived a (to me) baffling arrogance that product management is an easier and less important job than software engineering. But that was never an accurate perspective, imo. And now that the "implementing things" job has gotten easier and the "figuring out what to implement" job has become more important, people with this perspective are really being thrown for a loop.

This sounds like a bummer. But honestly I can't relate to this at all. I've never gotten calls like that. It's just not what my relationships with friends and family have ever been about. (Nobody cares about my expertise, and to the extent they have, they always just wanted me to fix their virus interested windows xp machine, because that's the limit of their understanding of what "computer people" know about, and I always hated that!)

The skill isn't "prompting", it is figuring out what to do, validating that it works the way you want, and thinking about how to best support future iterations of things you might want to do.

Which, not coincidentally, is pretty much the same description as what the job was already about.

I mean, to me, this is very similar to how it was when "the web" came into its current pervasive form. You could write exactly this comment about how people were writing about how they liked the web, on the web, and also about how they didn't like it, maybe shockingly, also on the web, etc. etc.

To me, this is just how it is when a new paradigm hits the scene. Whether it's good or bad, whether you care for it or not, it is pervasive.

Some building is done for those reasons, but it's hard to think of examples where building is done at large scale for those reasons.

I have a friend who is in construction management at a firm that exclusively does large projects, usually commercial and sometimes residential towers. I don't think you could come up with a definition for "build" that excludes what he and those he manages are doing. But they do not build those projects because "they take pride in the craft, because they take joy in mastery, because they are relentlessly curious, because they learn by doing, because they want to manifest the abstract because it's a natural desire to leave a mark, a legacy". Some of those things may be true of their work some or all of the time, but they don't do that work because of those things. They do it because somebody considered it to be really useful and worthy of the investment to build that new tower. The reason they are building, the "because" of it all, is the end product. The means with which they build, the craft of it, is only relevant as a means to that desired end.

Software is no different. Some software is built for the craft (and that's great, I personally love doing that), but at large scale, it is the outcome, the end product, that is the goal, that is the thing that matters. If craft is the best way to best achieve the desired outcome then all the better, but a professional will honestly assess whether that is truly the case, and do their work accordingly.

Yes, I think this is the question.

> If large scale battery storage is already cost competitive with turbines and there is still more low-hanging fruit, then presumably battery costs will continue to fall faster than for turbines?

Yes, and this is the assumption that the comment I replied to seems to disagree with. I think the assumption is right and the disagreement is wrong.

> That said, I doubt the cost of either of these technologies is driven so much by the technologies themselves so much as it is our ability to manufacture and install large volumes of them at scale.

Deployment is part of the learning curve.

I think you're agreeing with me (and disagreeing with the comment I replied to) here :)

Wouldn't you agree that we're much further along the learning curve for turbines than for large scale battery storage?

Yeah I'll be curious to see if or when they stop seeing the utility in this!

-- Michael Scott

> There isn't a hard boundary between "training" or "inference", modern post-training is arguably inference-bound :)

Ah this is an enlightening point. 8 hadn't thought about it this way, but you're right.

I think this is an interesting and good theory. They've probably eked out the large majority of the PR benefit at this point, so whether they continue in this vein will tell us a lot about their motivations for this work.

To take this to the next step, what happened after deep mind pretty much solved Go is that they started looking for the next set of things that hadn't been done yet. It does strike me as very likely that this will follow that same path.

Definitely could be, but I've been waiting for that imminent crash for about 4 years now, so who knows.

This doesn't seem consistent with what I'm seeing in the job market at the moment.

I'm not sure. Why wouldn't they?

If nobody can buy anything, the ai companies will go out of business too.

Yeah makes sense. The SQL thing has also been my differentiator (and yeah, straight up arrow if you aren't doing much transformation of the data), but now I'm curious whether polars sql might be just as good. I kind of like that duckdb allows me to work with a database file, like a sqlite db. But maybe persisting parquet (or arrow directly?) is just as good?

This is why I asked someone else who is also figuring this out!