win311fwg

But they do still need the job shop machinist which fill essentially the same niche using slightly different tools (mills and lathes rather than forges and hammers). Is your 16 year old implying that LLMs are the programming equivalent of a mill/lathe in metal working?

So you're right. Without AI the average lazy developer would write 50k implementation lines of code and 0 lines of test code, and now they have 450k lines of test code in addition to their 50k of implementation code. It might not be great test code, but I know which I'd still rather have (hint: the tests).

Verification isn't a panacea though. The hard lesson everyone learns when they first start taking an interest in verification is that perfect verification is fundamentally impossible.

It is a higher level concern so that isn't a bad thing. SQL is focused on giving you a view of your data. Whereas you want to combine many different views. That is where composing many different queries should be seen as quite natural at the interface point, not a shortcoming of SQL. If that composition isn't natural, you may want to take a closer look at your application's architecture.

> but then I am implementing what essentially amounts to a join myself

Joins and aggregated views are very different concepts. I think this misunderstanding, which is one I've seen many times before, stems from the hacks used to work around the aforementioned problems. Many have come to believe those hacks actually how SQL is designed to be used, not the hacks that they are.

> I have not seen this in any other general interface for relational databases.

Oracle has their thing. Its name escapes me at the moment. Postgres has json_agg/jsonb_agg and similarly SQL itself has array_agg. Lots of options out there.

But it's not only a question of if it can be done, but if it should be done. There are a lot of other advantages to moving query aggregation out into another application. There is a reason why we stopped sticking SQL servers directly in front of the clients and it isn't just because of SQL using a table representation.

Because you don't need nested results. You can fire off another query.

Although I am venturing to guess that you feel you need nested queries because you're doing doing something stupid like trying to send SQL queries over the network where the cost of firing off another query becomes a great performance burden. But the answer to that is don't do that. SQL was specifically designed to be run on the same machine as your application.

If you need to present the data to network clients where nesting is necessary for performance reasons, turn your application into the network database service that produces nested data (the "API server" as the kids call it). Leave the SQL as an implementation detail hidden behind the scenes.

The second biggest flaw, which isn't really about SQL itself but in implementation, was attaching SQL to the network where latency starts to become a problem. That requires hacks to work around. This is likely this is why you're seeing data duplication — trading all that duplication to avoid the latency problems that wouldn't be a problem if you kept it on the same machine like SQL originally intended.

Realistically, the question isn't meaningfully answered in isolation. One would have to see the bigger picture to put it into context.

It is absolutely true that someone else's life doesn't define their own future path, but that doesn't mean they don't latch onto those stories and project the negativity onto themselves. One cannot see the future, so it is quite common to look to others to predict what the future may hold. As you point out, the future is often completely different to what you imagined, but it is what you are imagining that shapes how you feel.

In reality the people would likely revolt by no longer recognizing private ownership of capital if that were to happen, but technically they don't have to. If they truly believe in capitalism — or, as it pertains to the discussion, there is an army forcing them to believe — they can continue to uphold the right for that private entity to own all the capital.

Maybe you mean that you could see the employees of those companies (although I imagine they also own it, so that's a wrinkle) staging a coup to seize the army for themselves? That's certainly possible. They'd be in a good position to do so. Predicting the future is impossible, but if you want to be on the "right side" of that future army, owning its foundation today is still a reasonable bet.

But I am not sure you are right that it is powerful enough to secure all. I search daily, but cannot remember the last time I used Google. The other AI companies do it better. And I'm not alone in that sentiment. Google's stock price recently took a nosedive because investors have grown quite worried about the competition. Without a sufficiently powerful army stopping them, there will always be someone else ready to try to outdo you.

It is a bit comical how the HN crowd spent the last number of decades trying to convince the audience that a programmer's value was actually in their system thinking, not their arcane knowledge of a particular language, but now that the language barrier is removed it turns out it was just the arcane language knowledge after all...

Although I'd posit that the old school HNers were the ones actually right. From what I see in the average Joes is that, while they can communicate with AI, they don't really see how to leverage it. Granted, the younger generations grew up in a school system that tried to promote system thinking more so than in the past, so that gap will likely shrink over time.

'Winner take all' doesn't mean convincing others to buy your product. If others have something to buy your product with, you've not taken all, fundamentally.

'Winner take all' means having the most powerful army. The assumption is that once AI crosses a certain threshold then there won't be anything the rest of us can do to stop the machine of whomever gets there first, so they will truly be able to take all. Hence why the AI labs sometimes hint about the risk of human destruction.

I think you are right that some people didn't bother to read the entire discussion and then started throwing shit out at random. That is the HN way.

But obviously "go doesn't have generics lol" comments on HN were even more important. Just think of what would have happened if that wasn't repeated multiple times daily for years and that effort was put into getting Go generics into place much sooner. Count your lucky stars or something.

You'd think one of the HN experts would have shown up to offer that expertise, but I guess there was a lot of "go doesn't have generics lol" needing to get out.

If you go back and watch the original Go announcement it was made abundantly clear that they believed Go did need generics but that they didn't have the expertise to do it. Yes it is true that the book was already written on it, but that doesn't mean anyone on the Go team was familiar with it or had the time to become familiar with it. Programming languages do not require gods to design them. Imperfect humans can too.

The experts on HN who know all the ins and outs of generics could have contributed but, you know, shitposting "go doesn't have generics lol" was a better use of their time. There are so many hours in the day.

Only about a year from when the Haskell guys lent their expertise in designing it and it landing in a release. That's actually fairly quick given that it was a pretty significant change under the hood and constrained by only two releases annually.

The Go team was always clear that they didn't have the necessary capabilities internally, despite a lot of failed efforts trying anyway, and were relying on the open source community to lend a hand. Unfortunately, open source doesn't mean open willingness to contribute. It turns out that for all the experts on HN, posting "go doesn't have generics lol" was preferable to helping out.

Now that people are back to writing their applications in languages that aren't as slow as Ruby they've, in many cases, taken the server back out of their application and have returned to the CGI model again; what is often marketed as "serverless".