Comment by teleforce

a) Capabilities:

Perhaps programming language is not the right abstraction to implement capability and need strong support from hardware and OS. OS with CPU based memory segmentation is an old idea probably worth re-exploring.

Implementing capability in the programming languages constructs will only increase cognitive overload and it will not be helpful for the programmer productivity [1].

b) Semi-Dynamic Language:

Dynamic language is what we want but static language is what we need [TM]. Instead of making dynamic language more static why not make static language more dynamic?

I think D language is moving the right direction with the default GC, RDMD based scriting, CTFE, and Variant based standard library features [2].

c) A Truly Relational Language:

Relational is only but one of the techniques of data processing, and other popular ones are spreadsheet, graph and matrices.

Rather than constraint programming languages with relational native constructs, better to provide generic mechanisms with fundamental constructs for data with associative array algebra [2].

d) Value Database:

This very much relates with (c) and can be excellent by-products and side-effects solution of it.

e) A Language To Encourage Modular Monoliths:

I think this is best point and idea from the entire article but as it rightly pointed out this is mainly architecture problem and programming language plays as a supporting role. It's the same as the Internet is based on packet switching rather than circuit switching, regardless of the RFCs and standards are being implemented in any languages.

However, for OS architecture with regard to Linus vs Tanembaum debate, modular monolithic is what we have now and the most popular in the form Linux, Windows and some say MacOS, and together they cover more than 99% of our OSes.

[1] Cognitive load is what matters:

https://mitpress.mit.edu/9780262038393/mathematics-of-big-da...