I imagine an implementation of this is equivalent to writing code and tests with the same level of detail as one might today. Language features put constraints on the solution, but do not reduce the essential complexity of a problem.

Could you elaborate more on what you mean by "could be taken much further"?

I think a language could even more constrain expected behavior so the compiler can catch problems without having to write tests. With tests you have describe the design constraints in two places: the code and the tests. If we could reduce the number of tests and more information into the code it would be a big win. Or a language that can model distributed systems and their interactions. The problem is to still be flexible enough so it will be hard to find the right level. I am pretty sure we will see a lot of development in the next decades. Systems are becoming very complex. If you think an old COBOL codebase is hard to maintain, good luck with a legacy microservice architecture in a few years. And it seems to be getting worse.

Got it, thank you for that explanation. I completely agree that we can eliminate all kinds of erroneous behaviors with better type systems.

> good luck with a legacy microservice architecture in a few years. And it seems to be getting worse.

It is getting worse. The complexity of systems and their dependencies are growing faster than the discipline of seeking to reduce accidental complexity.

Not quite. Dropping a column or updating a row is typically irreversible.

That does depend upon the database, but can be done in some without resorting to a backup.

In PostgreSQL, schema changes are transactional.

> In PostgreSQL, schema changes are transactional.

With a few exceptions (that refuse to run in an explicit transaction): E.g. {CREATE, DROP} DATABASE, {CREATE, DROP} TABLESPACE, {CREATE INDEX, DROP INDEX, REINDEX} CONCURRENTLY, REINDEX {SCHEMA, SYSTEM, DATABASE}.

Also, try adding a value to an enum via ALTER TYPE ... ADD VALUE

Not anymore ;). Well, at least in the upcoming PG 12.

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...

  commit 212fab9926b2f0f04b0187568e7124b70e8deee5
  Author: Thomas Munro <tmunro@postgresql.org>
  Date:   2018-10-09 12:51:01 +1300
  
      Relax transactional restrictions on ALTER TYPE ... ADD VALUE (redux).

There's still some restrictions:

> This patch removes that restriction, and instead insists that an uncommitted enum value can't be referenced unless it belongs to an enum type created in the same transaction as the value.

Decred appears to have solved the PoW 51% attack via a hybrid PoW/PoS consensus mechanism. It's practically unfeasable to attack at this point.

I took an interest in programming in high-school and ran into Todd (mentioned in the article) in the lobby of an online first-person shooter. The topic of programming came up, and I explained where was at in this whole coding-thing.

After a few games, Todd gave me a challenge: Thoroughly understand multilevel pointers, and then explain it back. In doing that, there would be a cash reward.

Hell yeah! So, I studied. Eventually, something clicked and I was able to answer those interview-style questions he threw at me. I ran the whole “money from a video game” thing past my parents, and Todd followed through on his promise. That small gesture fueled an understanding that projected into a career.

Interesting article, it's worth a read; there are good people behind it. Thanks again.