There was always some of this in the tech world, long before LLMs came along.

I've sat in so many meetings when decisions were made based on "that's what _slightly more prestigious company_ does" rather than objective measurable criteria. (And the evidence that the thing in question wasn't universally followed by _slightly more prestigious company_ carried surprisingly little weight).

Human when preparing a CV: "Make my CV more professional"

LLM many days later presenting a report to HR: "This CV is really professional"

There's probably more to it than that of course.

But it justifies my personal policy of using a different LLM family for code review tasks than for code generation tasks. To avoid the "marking your own homework" problem.

But it's unsettling because it somehow feels more plausible than most thought pieces on where all this is going. Not as a single big-bang, but a multi-year big-squeeze. That and the circumstances being materially different from previous recessions/crises that governments and policy makers won't have a ready-made playbook to refer to.

I expect we'll see governments attempting the old playbook than doing nothing though. Fiscal and, specifically, monetary stimulus.

The nub is something I've thought about before. My contingency plan for AI turning the industry I work in upside down is to make hay while the sun shines before that point. Have enough saved or invested for a (lean) retirement (depending on how far away that point is).

But what if AI turns every industry upside down. Will there be enough overall economic activity to actually invest in at all. Then we're all poor regardless of how much we've individually saved, or what kind of social safety net exists, simply because there's not enough economic activity to fund it.

That is, at the moment, and I hope forever, a very remote possibility. For a whole host of reasons, technological and economic ones. But if that did happen in the next 20-30 years...

Comments URL: https://news.ycombinator.com/item?id=46378873

Points: 5

# Comments: 0

Both situations need an iterative process to fix and polish before the task is done.

The notable thing for me was, we crossed a line about six months ago where I'd need to spend less time polishing the LLM output than I used to have to spend working with junior developers. (Disclaimer: at my current place-of-work we don't have any junior developers, so I'm not comparing like-with-like on the same task, so may have some false memories there too.)

But I think this is why some developers have good experiences with LLM-based tools. They're not asking "can this replace me?" they're asking "can this replace those other people?"

> Rust’s borrow checker is a a pretty powerful tool that helps ensure memory safety during compile time. It enforces a set of rules that govern how references to data can be used, preventing common programming memory safety errors such as null pointer dereferencing, dangling pointers and so on. However you may have notice the word compile time in the previous sentence. Now if you got any experience at systems programming you will know that compile time and runtime are two very different things. Basically compile time is when your code is being translated into machine code that the computer can understand, while runtime is when the program is actually running and executing its instructions. The borrow checker operates during compile time, which means that it can only catch memory safety issues that can be determined statically, before the program is actually run. > > This means that basically the borrow checker can only catch issues at comptime but it will not fix the underlying issue that is developers misunderstanding memory lifetimes or overcomplicated ownership. The compiler can only enforce the rules you’re trying to follow; it can’t teach you good patterns, and it won’t save you from bad design choices.

This appears to be claiming that Rust's borrow checker is only useful for preventing a subset of memory safety errors, those which can be statically analysed. Implying the existence of a non-trivial quantity of memory safety errors that slip through the net.

> The borrow checker blocks you the moment you try to add a new note while also holding references to the existing ones. Mutability and borrowing collide, lifetimes show up, and suddenly you’re restructuring your code around the compiler instead of the actual problem.

Whereas this is only A Thing because Rust enforces rules so that memory safety errors can be statically analysed and therefore the first problem isn't really a problem. (Of course you can still have memory safety problems if you try hard enough, especially if you start using `unsafe`, but it does go out of its way to "save you from bad design choices" within that context.)

If you don't want that feature, then it's not a benefit. But if you do, it is. The downside is that there will be a proportion of all possible solutions that are almost certainly safe, but will be rejected by the compiler because it can't be 100% sure that it is safe.

Comments URL: https://news.ycombinator.com/item?id=35513839

Points: 6

# Comments: 2

The first citation of the words "Software Crisis" meaning the inherent difficulty of writing high-quality software in a predictable way was from a NATO conference fifty years ago: https://en.wikipedia.org/wiki/Software_crisis

It is taking a long time for good practices to be discovered and win-out, and even when obvious improvements have been made, they're not necessarily used effectively.

I suspect a large part of the reason why the software industry isn't maturing at the same speed that other industries have had to, is that in software, failure is much easier to hide.

> The root of the problem is the uncontrolled complexity of modern software products.

I think there's a feedback loop between those two things, especially when it comes to government or giant corporation projects. Lack of accountability causes accidental complexity, which in turn causes a lack of accountability.

It starts with a organisation that lacks tech leadership hiring a consultancy, which then treats the project as a "flagship engagement" which means trying to make everything perfect, where perfect is used in the context of the number of future sales-pitches that will cite this one project.

As a result, there's a gap between what the organisation needs and what it gets, which adds to the amount of work required and complexity to navigate, whenever changes are required, and the overall complexity snowballs from there.

Most of the above is business-as-usual for most very expensive projects. The real danger-zone is when you get to the third iteration, six or seven years down the line, and you're forced to re-hire the first consultancy again because they're the only one with the resources to take it on; but the tech-world has moved on, so they see you as a "modernisation engagement". They simultaneously can't criticise their own bad decisions from several years prior, but at the same time they want the wider-industry to see their "transformative" power, so can't merely iterate on what's already there either.

That's how you end up with iOS apps, talking to Ruby-on-Rails APIs (which used to be the primary web-app, before that was replaced with a React frontend), reading and writing from an Oracle database which is also updated with a series of batch jobs dating back to early 2000s Java EE.

The "coal face" developers in all these situations have done the best work to their ability, and quite often achieved minor miracles in stability given the underlying complexity. The problem is always a management (or lack-of management) problem.

Of course it was nonsense, as anyone who'd read about previous bubbles could tell you. But it was a mad time last December.

It's not a government proposal. It's not even a proposal of the opposition, or anyone who would potentially be in a position to actually enact it.

The headline isn't wrong, but the prominence the BBC has given it could trick people into thinking its an official (or at least serious unofficial) proposal.

And even those things that became successful did so in a form that the contemporaneous positive predictions did not expect. The 1990's predictions of the Internet was of decentralised power and freedom of information, what actually happened? There was a land-grab, and a new generation of billion-dollar corporations have become established. Where once there was Blockbuster, now there is Netflix...

My prediction is the same will happen with cryptocurrency and blockchain applications. The technology will live-on, mostly in non-currency applications (e.g. behind the scenes settlement rather than day-to-day transactions); most of the "land grab" phase will die off though. Then, one day, ten or twenty years from now, we'll realise that "fiat" currencies have been blockchain based since some un-trumpeted central bank upgrade eighteen-months prior. But no-one will have noticed, as they still spend "dollars" on a credit card... same as they always did.

For point 2, there is Coconut Battery on MacOS. This is telling me my old iPhone 6 has 90% capacity after 400 odd cycles, which is probably par for the course, but I have no idea if that's bad enough for the performance throttling to kick in or not. Hopefully the new screen is going to be detailed enough to say how much throttling has been applied.

It's almost as though they're writing about it solely because they feel that they should, to avoid the risk of being seen to be taking a stand. As a result coverage of ICOs gets softer coverage than it otherwise would.

But as others have said, in many parts of the world there aren't many shortwave stations left. Africa and parts of Asia still have quite a few however.

A world where Bitcoin was the default currency would rob nations of control over their own monetary policy, which is one of the most important tools for controlling the economy. Not to mention we'd be living in a world of persistent deflation (due to the ceiling on the maximum number of Bitcoins) which would have interesting consequences on the economy too.

The only cryptocurrencies that would be allowed to gain widespread usage would be those controlled by the central banks.

Also, since they're not yet live I can't vouch for them, but here's an example: https://freetrade.io/