I think this requires a big shift in community thinking. Programmers are trained in universities to throw OOP principles at every problem, and the DRY principle has deeply taken hold. Obviously both have their place, but they often used overzealously and come at the expense of readable and maintainable code.

All that does is move somewhat messy language constructs into somewhat messy data constructs.

The data is static-ish, which is nice. But the associated code has exploded in complexity and with XML particularly you can't even be sure if it's truly compliant - especially if it's coming from an outside source.

So I think that whole talk is spectacularly missing the point. The idea is good but functional/read-only doesn't solve the problem.

Because some problems are just hard, and no amount of functional twiddling makes the hardness go away.

Names are hard. International localisation is hard. Dates and calendars are hard. International holidays and special dates are hard. Addresses are hard. Timezones and time systems are hard. Phone numbers are hard.

There is no trivial solution to any of these problems.

The most effective solution would be an international standard collection of algorithms and APIs baked into identical standard libraries for each mainstream language.

What you get instead is a lot of people wasting time and energy solving these problems over and over - badly.

And in fact XML, JSON, SQL, etc are similar. There are countless libraries and frameworks for managing these, and they're all slightly different and likely to fail in different ways - not just in different languages, but in multiple competing frameworks for the same language.

The problem isn't the code, it's the culture around it. Instead of solving a problem completely and standardising, the industry is addicted to nearly-but-not-quite solving the same problems over and over.

That's where a lot of unnecessary complexity comes from.

I am lacking context, but SQL was made for data.