gisborne
commented
5 years ago I am working oin this and have been for years. What I have in mind goes a little further, actually. Mine is based on REST — endpoints are functions with result types; types have various presentations (as an icon, a summary, a table row…). Everything is addressable (REST). Right click on a thing you can see, and you get a HTML presentation of its metainformation (because everything eagerly generates a UI).
The metainformation shows functions that take the result type of this function as an argument, and also the inputs to make this thing, so you can change them and have a new thing.
All this is kept in a general purpose key-value store, where you can store not just scalars and media but also functions, relations, other complex data types. Functions can be created in the store not only by coding but by executing functions — FP, but through API calls and user actions, rather than coding.
My aim is more toward letting non-programmers solve their own problems (kind of like FIleMaker or Excel), but the effect is also to empower developers in the manner your linked article describes.
I should have something to demo by mid-2019, maybe a little earlier. It will be Apache-licensed.
It’s called FREST (Functional REST).
Guyren G Howe On Dec 15, 2018, 15:42 -0800, Dan Cook notifications@github.com, wrote:
Consider this: https://hackernoon.com/some-tentative-guidelines-for-gui-composability-2900abead1d9 Also, someone should find a way to contact this guy and direct him at some of our stuff. I'm sure there are some great opportunities for cross-collaboration — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
d-cook
Consider this: https://hackernoon.com/some-tentative-guidelines-for-gui-composability-2900abead1d9
Also, someone should find a way to contact this guy and direct him at some of our stuff. I'm sure there are some great opportunities for cross-collaboration