Anyway I thought it was sort of ironic that the idea is this good because it does the thing everyone tells you not to do (hashmap all the things), but now that someone has written a book on it you have at least the air of respectability.
[1] https://www.youtube.com/watch?v=Vz9rkr_p3Ts [2] https://www.manning.com/books/data-oriented-programming
That said, I very much believe in the value of values. Data should have no associated behavior or have a "place" in memory, the place and the behaviour are secondary. That's why, ironically, "Manager" objects are the best type of object you can have, contrary to OO best practice, because they don't own the data, they just provide a place and behaviour for a particular usage.
The idea of "everything is a hash-map" is also possible in statically typed languages to some extent using row-polymorphic structural types. OCaml and Elm or Koka are great examples.
Yes! I've been playing with this recently. For context, long term, I'd like a pushout lattice of theories (types, operators, laws) to get math-like locality. But for a more near-term puzzle, what might highly expressive metaprogramming and collaborative compilation look like?
There are lots of papers on say "tweak some language to add a bit more control over memory layout"... but what if you want subsume all such, concisely. To permit much more gracefully moving around implementation design space. So you can flexibly and concisely express and mixin domain "asks" - this range of values, that variant of `mod`, this handling of alu flags, "try it exact, now bounded exact, now floatNN", with what radix and offsets and scaling, with what intermediates, with what bits landing where manged by whom, etc, etc. With sort of Maude-like[1] "in this scope I want imported these operators and rewrite semantics", but more composably over a higher-dimensional design space.
Apropos a sibling comment, I'm currently at compile/collaboration-time "hashmap all the things", tied in with scoping. Eg, it's not just a literal "5" ast node, it's a rich set of expressed and inferred constraints and preferences on implementation. (If anyone knows of a rich hashmap/assoc/dict combinator library, I'd appreciate hearing of it.)
[1] err, semi-randomly: https://maude.lcc.uma.es/maude321-manual-html/maude-manualch...
But still, I think that the proposed solution is at the wrong level. I think it would be much better to talk about the specification versus the implementation level. Instead of saying this function works correctly when certain pre-conditions are met, you could also say that a function implements a function under for a certain value domain. The article, the function 'floorSqrt' could be viewed as a function, which implements the generic floor of square root function, for a certain value domain, namely positive 'int' values. (You wonder whether the input type was not of 'unsigned int'.) It is not even clear from the context, what is the maximum value of 'int'. That the result is always valid for the input values is clear.
I think that for the development of software engineering, it would be better to focus less on 'programming' languages and more on 'implementation' languages, languages that specify how a generic (often matchematical) problem, can be implemented in a programming language. Instead of developing yet another programming language.