I think they're missing some dimensions.<p>Namely mutability, side effects, formal verification ie. How equational / axiomatic a language is, how static/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>> 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 "fringe". 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'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://news.ycombinator.com/item?id=20791775" rel="nofollow">https://news.ycombinator.com/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