benashford

I think most of this applies to software engineering generally, not just fintech.

For example the parts talking of retries, idempotency, event ordering, etc. This applies to all systems that require any degree of accuracy, even if no money is directly involved. I've seen so many systems built on the assumption that "we can always retry", but you can only retry if you fail cleanly in the first place, and if the downstream system offers the same level of idempotency that you think it does. Quite often these are not put to the test.

Any shared sense of rigour is just completely torpedoed by the LLM world, particularly the cloud LLM world it seems, and we are reduced to cargo culting. Nobody is any more right or wrong than anyone else.

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).

Intuitively this feels obvious. Content generated by the model will be shaped by its training, therefore when reading it back it will resonate with that same training and have a positive view as a result.

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.

This is a speculative piece that is, by the author's own admission, a scenario rather than a prediction.

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.

I think I get the gist of the moral of this story. But I'm not sure I'm fully agreeing with the specifics.

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...

This is true. But, it's also true of assigning tasks to junior developers. You'll get back something which is a bit like what you asked for, but not done exactly how you would have done it.

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?"

Aren't these two points contradictory? Forgive me if I'm misunderstanding.

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.

It daunts me too, and reminds me of the early-days of commercial flight. I hope we'll have a similar "we cannot continue like this moment".

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.

It daunts me how much software is getting unreliable, but trying to shame people to hold them accountable is naive.

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.

That isn't what they were saying at the time. Even level-headed forums like Hacker News had a lot of comments (gathering positive votes, although I suspect not all were organic) trying to describe with a wide-array of pseudo-science why Bitcoin was the king of a new world of inherently superior currencies.

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

The headline says "Bitcoin", the speech which included the anonymity claim said "cryptocurrencies".

If the government is saying the cost will be £14.5B then they must think only 1.5M people will sign up

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.

Pretty much everything successful now was ridiculed or dismissed in the past, but that doesn't mean everything that was ridiculed or dismissed became successful.

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.

I don't think Apple ever applied throttling to devices prior to the iPhone 6. As you say, old 5Ses would shutdown at 20% (or lower), but it was with the iPhone 6 and later where devices would occasionally stop at 50%, so became a much bigger issue. Presumably this was due to the A8 CPU having a wider-range of power consumption (this is a guess, if anyone actually knows why I would be interested to know).

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.

The tone taken by the financial press towards cryptocurrencies is interesting. They give plenty of press to the sceptics, the warnings from central bankers, etc. But they also give plenty of positive press, arguably undeserved when compared to the size of similar ventures funded by traditional means.

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.

It showed the "unknown developer" warning box when running the app, would that have been shown if the app was already authorised to access the keychain?

There is more than one shortwave band, some are more useful than others and there are fairly large gaps between them, so it would feel sparse even if there were a lot of stations: https://en.wikipedia.org/wiki/Shortwave_bands

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.

They absolutely would do both of those things.

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.

There's a few in the works, but none live yet that I know of.

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

With one-or-two exceptions, what the paper describes is very familiar and sounds like most software teams, but most teams don't achieve Google-like performance/stability/success.

The differentiation is in details that the paper doesn't explore.

I agree, this paper will just lead to more monolithic Git repos "because it's good enough for Google", without the appreciation of Google's other tooling and processes.

Apple appears to be banking on software efficiency gains offsetting the reduction in battery capacity. They've done this with various iPhone and iPad releases several times.

But the trouble with trying the same thing for the Mac is the wider variety of software people run on macOS. Third-party software may not have got any more efficient, meaning the battery doesn't last as long.

But if you stick to Mail.app and Safari then, in theory, you'll get the expected battery life.

Also an interesting Radio 4 programme on the same topic: http://www.bbc.co.uk/programmes/b07lhh6z

I'm no expert on the streaming industry either, but I'd guess it's because Spotify has much larger numbers of casual listeners (the free tier), which provides a long-tail for popular songs that aren't new enough for "exclusives".

So it's essentially Spotify's way of saying "if you don't want our customers to listen to the album when it's new, don't rely on us for listeners when it's old".

Although these claims are going to be essentially impossible to prove. Who's to say what should or shouldn't be in a playlist, for example?

Go's approach requires specific code to handle errors in each and every function, and it's very easy to forget or introduce a bug in the propagation of the errors (or to ignore one altogether).

So I wouldn't use that as proof that the world has settled on global "stop the world" exceptions vs checked exceptions.

Rust is another one that requires specific Result<DataType, ErrorType> to be passed back to a calling function, that either contains the return value or an error. But unlike Go, it's very difficult to ignore the error entirely, but it does require code to handle and propagate errors up the stack.

Although both Go and Rust also have the concept of a panic, that does stop the world (or at least the current thread, unless the panic is captured but that's another story...).

There was something about that video that makes me think DRU isn't a serious proposition; and even if it were, it isn't yet being used for actual deliveries.

This is a common theme with new technology. The sceptics always claim "it's decades away", the enthusiasts always claim "it's nearly here - look!" But what usually happens is something in between. Essentially both are right, some stepping-stone will launch or be trialled, but it takes decades to be refined to the point where it actually delivers on the hype that was "real soon now" way back when; and by the time that happens, everyone has got used to it so the milestone passes without anyone noticing.

In the case of automatic vehicles I don't know when that clock started ticking, so I don't really know how far along we really are.

How could that particular error (using that as an example) be improved?

error: the trait `core::fmt::Debug` is not implemented for the type `T`

That pretty much is the problem. It seems the bigger pain point is as you say "they make sense in hindsight", but that's because (as the author acknowledges) of expectations driven by other programming languages. C++ wouldn't have raised an error because the type-checking is done after template expansion, whereas Rust is the other way around.

The biggest criticism from me would be the hints underneath advising the author to implement the Debug trait, whereas the solution is to add a trait bound to the code instead.

If anything I'd say Rust's compilation errors are above average in both the accuracy of the error message, and helpful hints. The learning curve around concepts such as lifetimes and moved values and other rare features do take time, however.

That story had an unexpectedly happy ending.

Several times in the past when I've needed to complain about external consultants cutting corners, I've found the consultants have got in first and told my own management about their unique red-tape cutting powers, and how things like continuous integration (yes, the first thing they did was to switch off the CI server so no-one knew what was happening) were a time-consuming luxury.

Is the .NET version actually spawning any threads at all? It uses Tasks to collect the results, but all the work is done in the main thread by the looks of it.

How's that different from any other freelancer? They all pay themselves a salary until they get to the higher income tax bands, then they pay a dividend. That's the most tax efficient way of doing it usually due to the presence of the personal allowance on income.

They were also unanimous it would happen last century?

What do we mean by "human level" anyway? Last time I got talking to an AI expert he said current research wouldn't lead to anything like a general intelligence, rather human level at certain things. Machines exceed human capacities already in many fields after all...