More REST, less code

[gisborne]

The simplest starting point for our intentions is to make coding less necessary. This is another way of saying "muggles should be able to do computing without code" or "code should be maximally user-modifiable without coding".

Consider Microsoft Access or Apple's FileMaker. These are exactly the sort of thing we want, right? They let non-programmers ("muggles") manipulate useful data types through a GUI, not through code. This is great, but I've no idea why we stopped there. Let's not stop there. Where does this take us?

Well, whatever we do should be open-source and network-first. State of the art in general-purpose APIs is REST. So let's see what we can do with REST.

REST espouses two particularly useful things for our purposes: that everything should be addressable; and that everything should be discoverable ("HATEOAS").

Note that "everything is addressable" means that everything should be an endpoint. Which is to say all useful articulation points within the system should be addressable. HTTP requests are just function calls — you invoke a thing, give it some arguments, get back a result. If that isn't a function call, I don't know what is (the difference with the likes of SOAP comes down to such things as statelessness).

So all our functions are addressable. We invoke them with a set of named arguments. The logical next step is to take this substrate of addressable functions and add LISP-style programming constructs. You can add your own functions to the substrate by invoking suitable function-building functions.

The main such metafunctions features are currying, and argument substitution. We store these constructed functions using a hash-based structure similar to a S-expression (hash based because we're using named arguments to functions here).

This is already great. I have a programmable API so the users of my service can customize what my API needs to do for them, so that my service usually does less work and the results are more useful.

Now we wrap all this in a GUI. We use a reasonably rich type system, eventually a rich ontology for this. We have default HTML representations for everything. So I can write a function that returns a set of similarly-structured values. I declare that the type of the result is an enumerable relation over some structured type. Default presenters for the relation and within it the structured type take over and I get a nice table of the results.

Everything generated stores how it was made (what calls with what arguments) at a UUID. This is available in the UI. When I right-click on something I can see, the UI does an OPTIONS request back to the server, which returns a list of functions applicable to that thing. What we see is a result of a set of function calls. The user will be able to drill through the arguments, including the defaults, and change them, either directly, or by feeding them through a function, or by getting them from somewhere else in the UI.

The user will also be able to feed what they can see (also all addressable) into functions to add to the UI or replace parts of it.

I've worked out a lot of details I won't go into here. One that I will mention is that non-ground functions present as forms.

The user will be able to get the URL of anything here and use those URLs to indicate the input into other things that are going on. Even on other similar websites.

Eventually, the intention is to give the user access to any and all data manipulation features that programmers use. In particular, I intend to let the user manipulate multiple separate or related models, with branch-merge, diffing, synchronization and such. Also encryption, signing, block chain and all that. IFTTT-type event-based behavior.

If this is all a bit vague, another way of putting it is that I'm implementing a rich NoSQL store that can store any sort of reasonable value, particularly including the functions that apply to those values and relations between them.

[vladimir-vg]

Now we wrap all this in a GUI. Eventually, the intention is to give the user access to any and all data manipulation features that programmers use.

I see UI as the main problem. How UI should look like to allow to create complex programs? Such UI that allows create programs with same level of complexity that text-based programming currently allows.

[coderextreme]

I see the GUI as desktop objects working with certain domains (calculators [date, string, numbers], documents, branch, form, ...). The program consists of operating on these desktop objects (mini apps) and recording copy/cut/paste between objects. selectiona are also unpietabr

John

On Fri, Jun 8, 2018, 3:03 AM Vladimir Gordeev notifications@github.com wrote:

Now we wrap all this in a GUI. Eventually, the intention is to give the user access to any and all data manipulation features that programmers use.

I see UI as the main problem. How UI should look like to allow to create complex programs? Such UI that allows create programs with same level of complexity that text-based programming currently allows.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/d-cook/SomethingNew/issues/25#issuecomment-395668528, or mute the thread https://github.com/notifications/unsubscribe-auth/AArE92urhYLdMCYpIaypLa5vAHZTiiz_ks5t6iGtgaJpZM4UfKI- .

[gisborne]

This won't replace coding. The idea is to give a GUI expression to anything we reasonably and usefully can.