I actually wonder about his conclusion that 50 years hence English will be unrecognizable.

There will be changes of course. Yet we are also more connected than ever, whereas the next town over would be a whole day trip in the past. The separation allows for more divergence.

Well, maybe if we get to Mars, differences might crop up again.

This isn't how I read his conclusion. He's saying English will be different in fifty years, but he's not saying it'll be unrecognizable. Look how little difference there is between the 1900 passage and the 2000 passage.

In fairness , Dickens is quite dry. My mind would wonder off.

In some sense, it's better these days, competition has led to care for the reader that probably didn't exist as much then, since so few people can read.

The alternative is one type, with many functions that can operate on that type.

Like how clojure basically uses maps everywhere and the whole standard library allows you to manipulate them in various ways.

The main problem with the many type approach is several same it worse similar types, all incompatible.

Yeah, there's something of a tension between the Perlis quote "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures" and Parse, don't validate.

The way I've thought about it, though, is that it's possible to design a program well either by encoding your important invariants in your types or in your functions (especially simple functions). In dynamically typed languages like Clojure, my experience is that there's a set of design practices that have a lot of the same effects as "Parse, Don't Validate" without statically enforced types. And, ultimately, it's a question of mindset which style you prefer.

Do those design practices protect you when you apply a refactor and now you don't know which call sites may be broken now?

Yes

There's probably a case for both. Core logic might benefit from hard types deep in the bowels of unchanging engine.

The real world often changes though, and more often than not the code has to adapt, regardless of how elegant are systems are designed.

Coalton ( https://coalton-lang.github.io ) is the sort of thing I like: a Haskell-style language hosted inside a very dynamic one with good interop.

Yes it's quite the blend!

I don't really get why this is getting flagged, I've found this to be true but more of a trade off than a pure benefit. It also is sort of besides the point: you always need to parse inputs from external, usually untrusted, sources.

This sounds like the "stringly typed language" mockery of some languages. How is it actually different?

It's not an alternative.

Start with a more dynamic type, do stuff that doesn't care about the shape, parse into a more precise type, do stuff that relies on the additional invariants, drop back into the more dynamic type again.

I find a balance is important. You can do nominal typing in a structural type system with branding, and you can kinda do structural typing in a nominal type system, but it's not as ergonomic. But you should probably end up doing a mix of both.

There are more than two alternatives, since functions can operate in more than one type.

Iterating often is not helpful for stable systems over time.

I like go's library it's got pretty much everything needed out of the box for web server development. Backwards compatibility is important too.

But open source didn't do the Linux model. It did the GitHub model of open to anyone.

If anything the heirarchy of trust the Linux model uses will be more important now.

Possibly, but AIs might shift to more curated content, which has it's own dangers I suppose.

There are definitely challenges, but I've been around long enough now that we'll adapt, and muddle through.

The trouble will come from humans' reaction to the changes, less from the changes themselves

God please no. Do not involve government in this. That's a terrible terrible idea, and would do the opposite of intended.

It could push back more, true. Although it's role in pair programming is the driver, you are the navigator. I often begin a session with exploring and asking it questions of the code as I would a junior developer.

Saves this old man from typing anyway.

That’s not pair programming as I use it. Pair programming is where two people work on the same code directly and bounce ideas or critique each other.

If I do something that is not ideal the other person will catch me, and I do the same in return. I kinda see it like rock climbing.

This is how I always did it too. When the whole does it every day, juniors don't stay junior for long!

If all software could be as good as sqlite, I would not care how they do open source

Yes; yet... I thought the efficiency per compute has to do more with the nm process shrinking the die than anything else. That and power use is divided by so many more instructions per second