Technical dimensions of programming systems

I think they&#x27;re missing some dimensions.<p>Namely mutability, side effects, formal verification ie. How equational &#x2F; axiomatic a language is, how static&#x2F;dynamic a language is (runtime typing etc), how concurrent, how scoped a language is eg. Red vs Koka.<p>All of the above have a massive influence on the structure and intent of a language.

intro:<p>&gt; Programming is done in a stateful environment, by interacting with a system through a graphical user interface.<p>i think all statments in that sentence could be argued with.

I find fascinating that the authors analysed only systems that are nearly all &quot;fringe&quot;. The Web itself is not really used as described either.<p>It sounds like this work end up producing something that does not even consider the reality of the field but only what the author&#x27;s imagine the field would be.<p>In that scope it is deeply interesting of course. And what they point to in the opening is important. But i would have loved an implementation that does look at how easy each system make testing. Composability. Refactoring. Linting. Different compilers. Repl. New projects. Compiler driven development. Formatting. Etc<p>There is a wide analysis of the technical side to do there between php and Rust as example. It feels like a missed opportunity.

The last author is the author of Write your own Excel in 100 lines of F# <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20791775" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20791775</a>, 84 comments.

An inspiring collection of thoughts. The section on feedback loops had me thinking: Would it be possible to program without feedback (or with minimal feedback). How would that look?<p>Pen and paper still has some feedback as one can see more than can be held in working memory.<p>edit: typo

Really interesting writeup!