A step higher than teletype text stream

[vladimir-vg]

Hey everyone. Recently I've read this article and really liked some plain ideas that seem to be unnoticed. https://programmingmadecomplicated.wordpress.com/2017/08/12/there-is-only-one-os-and-its-been-obsolete-for-decades/

Why do so many languages have a function called print instead of write or something else? They were influenced by C. Ever wonder why C called it so? Now you know. It literally printed ink onto paper. ... this is still the only way we can get anything done in the world of programming! Typing textual orders into a “terminal” or “console” application—nothing more than an emulator for the teletype!

So I got this feeling that there must be an API that would replace text pipes that we enjoy today in Unix world. Maybe this API is not discovered yet, but it definitely will be discovered sooner or later (just like lisp was discovered). What it should look like then?

Everything should be made as simple as possible, but not simpler.

Currently I think about it on the level of the API, not on a transport level. I don't know will it use TCP or UDP sockets, or Unix pipes, or how it gonna be encoded, it unrelated for now.

Here are my thoughts:

1. Very simple API that is easy to implement on many platforms without mistakes.
2. Convenient for providing access to complicated nested data between different programs.
3. Convenient for inspecting remote object (say, interface for debugging).
4. Don't demand any prerequisites for reading, filtering or transmitting. No prerequisite dependencies should be required: no grammar or types (unlike Protobuf or ASN.1).
5. Suitable for delivering structured logs and events.

Some related ideas to think about: https://www.youtube.com/watch?v=1O8PwkXfDJg GraphQL also reminds something like that, but looks too complicated. Must be simpler.

I've implemented something similar when I was working on complicated frontend code. A big tree of objects, to different parts of which you may subscribe and receive diffs. These diffs are accepted on other side and might be applied to get fresh information that we're interested in.

This idea of sending diffs for a tree which may be saved and applied at any moment in timeline is really beautiful. You got updates for your data and also the history of changes. It Very similar to VCS textual diffs, but for trees (AST ?).

diff: { resource1: { status: started, startedAt: 1 } }
diff: { resource1: { status: stopped, stoppedAt: 2 } }
----------
tree: { resource1: { status: stopped, startedAt: 1, stoppedAt: 2 } }

Same trees might be used to deliver changes in AST during code editing.

Yet this API certainly gonna be used for delivering logs and events. Providing keys for each event is tiresome and requires to maintain state. So it must provide not only nested trees, but also sequences of objects.

seq: {event: "app start", at: 1}
seq: {event: "function-call start", at: 2, funcName: "foobar", args: [1, 2]}
seq: {event: "app stop", at: 5}

Then it came to me that this way we can integrate existing pipe-based outputs as sequences of binaries that are split by new line or by arbitrary size (say, size of the buffer).

One of the painful things when you deal with pipes is that everything is one-channel sequential. If you want to provide several kinds of data then you have to make interleaving, or create additional pipe.

So it came just natural that this API should be able to provide several channels of data, that allow you to filter out data you don't need. In these terms normal unix application provides two output channels: stdout and stderr. In this API you would be able to have many of them.

Here are some questions to consider: should channels have type (tree or sequence)? Should we think about trees as sequence of diff objects, therefore just sequence? Or maybe allow every channel have sequence and tree under same name? This looks somewhat convenient with HTTP requests: having body as a sequence and headers and meta info as a tree.

I can easily see this API being used for everyday problems with that sed, awk, grep used to solve. This API will naturally have some kind of shell environment (language?), position which held by bash in today world. An IDE where you observe flowing data, just like how you observe in now in DevTools in Chrome.

But that's really complicated issue, and I would love to hear feedback about written above first.

[yozlet]

Have you looked at Windows PowerShell? I've never used it in depth, but its piping and filtering works on objects rather than text, and seems to be pretty powerful. It also has features for dealing with remote connections.

[vladimir-vg]

Actually yeah, they had something similar. Will take a look, thanks for suggestion!

[jdjakub]

Hi vladimir-vg, thank you for the time you put into such a detailed post. I began writing a response but it's grown quite large. Do think it would be better to put it here as a single reply ... or maybe multiple replies ... or even put it as a post on my blog and link to it?

[vladimir-vg]

Hi, Joel.

I think it would be better to post it here by multiple replies. I think it's this way is more convenient for maintain discussion between many people.

[jdjakub]

OK. I'm going to give my response inline. Just to be clear: as with everything I write, anything I say here might not be what I think in the future, and I am just a part of this project and not to be taken as representative of others here, so these are my own opinions.

Hey everyone. Recently I've read this article and really liked some plain ideas that seem to be unnoticed.

First, that Unix rant was my all-time favourite article to write, but nobody else seems interested in it :) so thanks for reading it.

Maybe this API is not discovered yet, but it definitely will be discovered sooner or later (just like lisp was discovered).

I have to get off my chest: I think it makes a difference, and is preferable, to see these things (APIs, languages, etc I guess) as having been "invented" rather than "discovered". All our computing practice is only the consequence of human creativity -- or lack of it.

2. Convenient for providing access to complicated nested data between different programs.

Nested: Allow me to suggest the following. Don't limit yourself to nested data. Allow arbitrary graph structures -- they will always be needed, and users (programmers) will inevitably end up hacking your nesting-only structure to support them when they run up against this. Let me give you a real-world example.

In my company, an application I work on consists of a Python server back-end and a Web user interface. But they are by no means separate -- more like two halves of a brain separated by a corpus callostomy operation! They both want the same information, in the same structure -- but one is Python and the other JavaScript. Not too bad, you might think -- as JS and Python are extremely similar, right down to that ridiculous block-scoping rule -- but no, that would make life far too easy!

There is a dark chasm between these nearly-identical software environments (The Void / Howling / Hell.) It is the space between applications (i.e. Unix processes), where there exists nothing except those good old 1D linear bitstreams: files and pipes. And as such, we use JSON to bridge this gap, and "serialise" our objects into things that look like this:

{
  "refs": {
    "3fa15751-7543-4a27-8e72-57141ff2b382": {
      "_python_class": "Bar",
      "key1": "value1",
      "position": [1.0, 0.0, 0.0],
      "nested_sub_obj": {
        "_python_class": "Foo",
        "key2": 23,
      },
      "obj_ref_key1": ["uuid", "b4b9d009-8e2d-4e03-bfb0-e59473d47c54"],
    },
    "b4b9d009-8e2d-4e03-bfb0-e59473d47c54": {
      "_python_class": "Quux",
      "greenspun": "true",
      "obj_ref_container": ["uuid", "3fa15751-7543-4a27-8e72-57141ff2b382"],
    },
    "... and much, much more!": {},
  }
}

JSON is, of course, a 1D linear-bitstream notation for nested trees -- just like XML, and HTML, and YAML, and S-expressions, and all the others. And because it doesn't natively support referring back to an existing node to have DAG or cyclic structures, we have to bodge this in ourselves, as you can see with all the UUID crap.

Unfortunately, because we have to generate and maintain the UUIDs ourselves, we've actually had subtle bugs because of it ... and all the work is to maintain our own implementation of a basic "feature" (non-nesting) that should be supported by something that shouldn't even be necessary in the first place! (JSON text)

Pleeeeeeease don't bake in context-freeness from the outset! :):):)

[jdjakub]

Now, data: "data" is inert and assumes that its interface to human beings, and and interface to other software i.e. "interpreter", are separated and live far away from it. So when the meaning of the data changes (which could be as simple as a change in format), what happens is that all places this data is used (those human- and software- interfaces) go out of date. So you end up with data versioning, backwards compatibility, etc.

And then what happens, is a new version of the "spec" is uploaded to some website in a natural language like English; armies of implementors of the data format around the world (i.e. humans) then read this "spec" and make the corresponding changes to their local human- and software- interfaces to the data.

("local" meaning: within the language and library ecosystem they're using, or within their personal projects, whatever -- e.g. if JSON changes then the JSON parser and serialiser in every language needs to change separately -- but all in the same way...!)

Now, what I'm about to say is not nearly concrete or thought-out enough to be considered as a currently-existing "alternative", but I need to get it written down: what if, instead of merely sending "data" around, we also sent the human and software interfaces -- i.e. the "moving parts" -- around too? I think Alan Kay once mentioned an "ambassador" idea, where instead of sending instructions, or "orders", to a remote subject, you instead send a "smart" thing that, once it arrives, will be much more robust and adaptible to the peculiarities of the destination.

The best example I can think of this does actually exist: it is the modern-day Web that we love and hate. The myopic vision of the original inventors of the Web -- the "static Page" lifted straight out of that tempting book of Software Metaphors Based On Physical Media -- was precisely about passing around static descriptions of paper-like entities ("documents"). When the inevitable happened, and people wanted to be able to have these documents change over time according to some sort of automatic decision-making on the user-session timescale, Netscape achieved this by adding a Turing-complete scripting language -- JavaScript.

Because such undecidability was added as an afterthought, it's unsurprising that it paved the way for all sorts of security issues. But these days, having woken up to the reality of the situation and adapted to it, now that we have properly-thought-out isolation of say, browser tabs -- the whole thing asmptotically approaches what it should have been in the first place: namely, a way to safely execute arbitrary code from untrusted and remote sources anywhere in the world. Or, put differently: a way to view, run and interact with other people's dynamic simulations without turning your entire computer into their simulation. (See Pacerier's comments on this StackOverflow question, who opened my eyes to all this)

3. Convenient for inspecting remote object (say, interface for debugging).

Not sure what this means. Do you mean like in the browser's JavaScript console, where you can expand and collapse object nesting?

4. Don't demand any prerequisites for reading, filtering or transmitting. No prerequisite dependencies should be required: no grammar or types (unlike Protobuf or ASN.1).

Hmmmm. Interesting, but ... how would it work instead?

If this is supposed to be layered on top of a serial medium (like the pipe), then I can't see how you can impose structure without having grammars, parsing and serialising ... unless you transmit code and transfer control to it. Otherwise, if this isn't supposed to be on top of the pipe, then I can't imagine what you have in mind :confused:

Some related ideas to think about: https://www.youtube.com/watch?v=1O8PwkXfDJg

In so far as it grasps out for Alan Kay's OO, I'm all for it. But if what you have in mind is improving the Unix teletype interface, it might be overkill? Idk.

[jdjakub]

Providing keys for each event is tiresome and requires to maintain state. So it must provide not only nested trees, but also sequences of objects.

Here I feel an urge to say: a "sequence" is a function / tree whose inputs / keys are integers. This can be an aspect of the hidden implementation, and/or an aspect of the human interface.

Your objection: "it is tiresome" applies to having this as part of the human interface, but not necessarily as implementation. Your other objection: "requires to maintain state" may also apply to the human interface, but definitely applies to the implementation.

Could you expand on this objection of "maintaining state"? If we treat a "sequence" as a "tree" with integer keys, then what state needs to be maintained? Do you mean that if you were to apply a sequence as a "diff" to another sequence, you'd need to make sure 0 is paired with 0, 1 with 1, 2 with 2, and so on...? I think this would still have to be done implicitly anyway.

So it came just natural that this API should be able to provide several channels of data, that allow you to filter out data you don't need. In these terms normal unix application provides two output channels: stdout and stderr. In this API you would be able to have many of them.

Hmm. Interface-wise, the three "standard" channels have special behaviour, yes. But I thought stdin, stdout and stderr were just file descriptors that every process is automatically provided? So you already can have many files / pipes ... is this what you meant?

Here are some questions to consider: should channels have type (tree or sequence)? Should we think about trees as sequence of diff objects, therefore just sequence?

Or sequences as trees, as I mentioned above. Not sure what you have in mind for trees as sequences. Could I get an example? "Tree as sequence of diffs" -- just off my head, it sounds something like this?:

TREE
{a: {b: {c: {}
        }
     d: {e: {}
        }
}
DIFF SEQUENCE
{a: {}} starting from {}
{b: {}, d: {}} starting from a
{c: {}} starting from b
{e: {}} starting from e...?

But the individual items in the sequence are still going to be key/value or input/output mappings, right? So all that seems to have happened, is we've gone from "tree" to "sequence of trees" -- but we might as well just have the original tree.

[jdjakub]

I can easily see this API being used for everyday problems with that sed, awk, grep used to solve. This API will naturally have some kind of shell environment (language?), position which held by bash in today world. An IDE where you observe flowing data, just like how you observe in now in DevTools in Chrome.

In this video at around 25:33 (and elsewhere), Brian Will talks about something that sounds very similar.

And within the assumption of a Unix-like environment and the sort of "programming" we're familiar with, it is a pretty good idea in itself which would make our existing programming environments easier. The Unix wizards missing the point in the comments section are testament to that.

Though, good luck getting any of this codified into the actual OS, default applications, etc. Our fundamental environment seems to be very good at resisting truly deep changes like this; partly because of ideology, partly due to genuine, though unfortunate, technical constraints like the need for widespread compatibility.

Basically, what you're describing is fine as an incremental improvement on the existing accumulated baggage / garbage of computing (here, mostly Unix). That's why the title is "A step higher than teletype text stream".

But putting on my "speaking for this collaboration" hat for a moment -- what we seek to do here is much more than adding embellishments to the conversational interface of teletypes and coming up with new data representations or APIs. We want to make a qualitative leap past what "programming" currently looks like and has looked like for decades.

(Btw, sorry if the signal-to-noise ratio is too low for your particular interest at this point. I'm finding it useful for myself to write and I hope it's food for thought for all reading. I'll now get back to the main point)

So what I understand of your proposal is this:

• Text pipes are the ultimate generality (streams of bits / bytes), which is why they're totally useless on their own without parsing and serialising.
• At the Unix "interactive" shell interface level, the only parsing that happens is the grouping of 8 bits into an ASCII character shape, and similarly for serialisation.
• (As well as recognising the colour red, pronounced \u001b[31m)
• So the interface barely stands above the implementation; flat text, over flat bits.
• It could be different. For example, by being tree structures instead.
• In which case, the open questions are what the human interface and the sofware interface (API) should be.

Is this accurate? If so ... it would be a step higher, yes. :S

[coderextreme]

Aye, expect cyclic references, but you can use class id (name) and object id instead of uuid.

John

On Thu, May 31, 2018, 5:39 PM Joel Jakubovic notifications@github.com wrote:

OK. I'm going to give my response inline. Just to be clear: as with everything I write, anything I say here might not be what I think in the future, and I am just a part of this project and not to be taken as representative of others here, so these are my own opinions.

Hey everyone. Recently I've read this article and really liked some plain ideas that seem to be unnoticed.

First, that Unix rant was my all-time favourite article to write, but nobody else seems interested in it :) so thanks for reading it.

Maybe this API is not discovered yet, but it definitely will be discovered sooner or later (just like lisp was discovered).

I have to get off my chest: I think it makes a difference, and is preferable, to see these things (APIs, languages, etc I guess) as having been "invented" rather than "discovered". All our computing practice is only the consequence of human creativity -- or lack of it.

1. Convenient for providing access to complicated nested data between different programs.

Nested: Allow me to suggest the following. Don't limit yourself to nested data. Allow arbitrary graph structures -- they will always be needed, and users (programmers) will inevitably end up hacking your nesting-only structure to support them when they run up against this. Let me give you a real-world example.

In my company, an application I work on consists of a Python server back-end and a Web user interface. But they are by no means separate -- more like two halves of a brain separated by a corpus callostomy https://en.wikipedia.org/wiki/Split-brain operation! They both want the same information, in the same structure -- but one is Python and the other JavaScript. Not too bad, you might think -- as JS and Python are extremely similar, right down to that ridiculous block-scoping rule -- but no, that would make life far too easy!

There is a dark chasm between these nearly-identical software environments (The Void / Howling / Hell.) It is the space between applications (i.e. Unix processes), where there exists nothing except those good old 1D linear bitstreams: files and pipes. And as such, we use JSON to bridge this gap, and "serialise" our objects into things that look like this:

{ "refs": { "3fa15751-7543-4a27-8e72-57141ff2b382": { "_python_class": "Bar", "key1": "value1", "position": [1.0, 0.0, 0.0], "nested_sub_obj": { "_python_class": "Foo", "key2": 23, }, "obj_ref_key1": ["uuid", "b4b9d009-8e2d-4e03-bfb0-e59473d47c54"], }, "b4b9d009-8e2d-4e03-bfb0-e59473d47c54": { "_python_class": "Quux", "greenspun": "true", "obj_ref_container": ["uuid", "3fa15751-7543-4a27-8e72-57141ff2b382"], }, "... and much, much more!": {}, } }

JSON is, of course, a 1D linear-bitstream notation for nested trees -- just like XML, and HTML, and YAML, and S-expressions, and all the others. And because it doesn't natively support referring back to an existing node to have DAG or cyclic structures, we have to bodge this in ourselves, as you can see with all the UUID crap.

Unfortunately, because we have to generate and maintain the UUIDs ourselves, we've actually had subtle bugs because of it ... and all the work is to maintain our own implementation of a basic "feature" (non-nesting) that should be supported by something that shouldn't even be necessary in the first place! (JSON text)

Pleeeeeeease don't bake in context-freeness from the outset! :):):)

— 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/24#issuecomment-393689302, or mute the thread https://github.com/notifications/unsubscribe-auth/AArE910hS0JbqwUhKsuPsCN1XMCYcKPhks5t4GMfgaJpZM4UO9D1 .

[coderextreme]

Unless of course, you have several machines creating ID's. Then you probably need uuids.

Or you can do something modulo n where n is the number of machines which create ids, where you set the high watermark each time a machine joins. Probably easier to create a uuid out of IP address, socket, time, process id, thread id, counter, ...

On Thu, May 31, 2018, 5:46 PM John Carlson yottzumm@gmail.com wrote:

Aye, expect cyclic references, but you can use class id (name) and object id instead of uuid.

John

On Thu, May 31, 2018, 5:39 PM Joel Jakubovic notifications@github.com wrote:

OK. I'm going to give my response inline. Just to be clear: as with everything I write, anything I say here might not be what I think in the future, and I am just a part of this project and not to be taken as representative of others here, so these are my own opinions.

Hey everyone. Recently I've read this article and really liked some plain ideas that seem to be unnoticed.

First, that Unix rant was my all-time favourite article to write, but nobody else seems interested in it :) so thanks for reading it.

Maybe this API is not discovered yet, but it definitely will be discovered sooner or later (just like lisp was discovered).

I have to get off my chest: I think it makes a difference, and is preferable, to see these things (APIs, languages, etc I guess) as having been "invented" rather than "discovered". All our computing practice is only the consequence of human creativity -- or lack of it.

1. Convenient for providing access to complicated nested data between different programs.

Nested: Allow me to suggest the following. Don't limit yourself to nested data. Allow arbitrary graph structures -- they will always be needed, and users (programmers) will inevitably end up hacking your nesting-only structure to support them when they run up against this. Let me give you a real-world example.

In my company, an application I work on consists of a Python server back-end and a Web user interface. But they are by no means separate -- more like two halves of a brain separated by a corpus callostomy https://en.wikipedia.org/wiki/Split-brain operation! They both want the same information, in the same structure -- but one is Python and the other JavaScript. Not too bad, you might think -- as JS and Python are extremely similar, right down to that ridiculous block-scoping rule -- but no, that would make life far too easy!

There is a dark chasm between these nearly-identical software environments (The Void / Howling / Hell.) It is the space between applications (i.e. Unix processes), where there exists nothing except those good old 1D linear bitstreams: files and pipes. And as such, we use JSON to bridge this gap, and "serialise" our objects into things that look like this:

{ "refs": { "3fa15751-7543-4a27-8e72-57141ff2b382": { "_python_class": "Bar", "key1": "value1", "position": [1.0, 0.0, 0.0], "nested_sub_obj": { "_python_class": "Foo", "key2": 23, }, "obj_ref_key1": ["uuid", "b4b9d009-8e2d-4e03-bfb0-e59473d47c54"], }, "b4b9d009-8e2d-4e03-bfb0-e59473d47c54": { "_python_class": "Quux", "greenspun": "true", "obj_ref_container": ["uuid", "3fa15751-7543-4a27-8e72-57141ff2b382"], }, "... and much, much more!": {}, } }

JSON is, of course, a 1D linear-bitstream notation for nested trees -- just like XML, and HTML, and YAML, and S-expressions, and all the others. And because it doesn't natively support referring back to an existing node to have DAG or cyclic structures, we have to bodge this in ourselves, as you can see with all the UUID crap.

Unfortunately, because we have to generate and maintain the UUIDs ourselves, we've actually had subtle bugs because of it ... and all the work is to maintain our own implementation of a basic "feature" (non-nesting) that should be supported by something that shouldn't even be necessary in the first place! (JSON text)

Pleeeeeeease don't bake in context-freeness from the outset! :):):)

— 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/24#issuecomment-393689302, or mute the thread https://github.com/notifications/unsubscribe-auth/AArE910hS0JbqwUhKsuPsCN1XMCYcKPhks5t4GMfgaJpZM4UO9D1 .

[vladimir-vg]

I should say my initial post wasn't flawless. Having read Joel's comments now I see it clearly.

I have to get off my chest: I think it makes a difference, and is preferable, to see these things (APIs, languages, etc I guess) as having been "invented" rather than "discovered". All our computing practice is only the consequence of human creativity -- or lack of it.

I still do not agree. For me abstractions that we use in programming are akin to abstractions that we use in Math, like matrices or imaginary numbers.

I think of Lisp as of discovery, not an invention. Having data and code represented in simplest compound data structure (linked list), which allowed to equate code and data and provided magic powers -- it feels pretty much like a theorem that we would stumble upon sooner or later.

I think about this teletype-step-higher-API same way.

Don't limit yourself to nested data. Allow arbitrary graph structures -- they will always be needed, and users (programmers) will inevitably end up hacking your nesting-only structure to support them when they run up against this.

I also like the idea of using graphs in everyday world. It might be very convenient to do it with pattern matching.

Yet use of graphs as everyday data structure is very rare on production-used platforms. It means that it would take a lot of painful work to integrate this graph-based API into already working programs. On the contrary -- every platform works perfectly with tree data structure: JSON.

Maybe new shell language associated with this API may have graphs as basic data structure, that would be very convenient. But it shouldn't be part of public input/output API, at least for now.

I think providing support for graphs on top of tree based API is perfectly fine.

Convenient for inspecting remote object (say, interface for debugging). Not sure what this means. Do you mean like in the browser's JavaScript console, where you can expand and collapse object nesting?

Actually it's the same as "Convenient for providing access to complicated nested data between different programs.". Don't know why I added this really.

Don't demand any prerequisites for reading, filtering or transmitting. No prerequisite dependencies should be required: no grammar or types (unlike Protobuf or ASN.1). Hmmmm. Interesting, but ... how would it work instead?

If this is supposed to be layered on top of a serial medium (like the pipe), then I can't see how you can impose structure without having grammars, parsing and serialising ... unless you transmit code and transfer control to it. Otherwise, if this isn't supposed to be on top of the pipe, then I can't imagine what you have in mind confused

Well I think I explained it poorly. Yes, you would need a prerequisite for parsing and decoding diffs and objects. But it shouldn't require anything else to make sense out of data.

Just like JSON: you need JSON parser/formatter to read/write it, but you can manipulate it without full understanding what kind of information it represents. You don't need type description.

Could you expand on this objection of "maintaining state"? If we treat a "sequence" as a "tree" with integer keys, then what state needs to be maintained?

Sorry, it was cumbersome, I wanted to tell something else.

I was thinking that if you make sequence as just part of the tree, and provide key for each element. But it implies that you may change element or even remove it providing diff where you specify it's key. I think of these sequences as streams that shouldn't be stored or changed, but processed and passed further.

So I felt that sequences and trees should be set apart completely, we should work with them differently. And later I realized that diffs are also sequences of tree-changes that just merged into tree.

So it seems like we should have only one kind of channel: sequence of objects. What to make sense of it, does it represents tree or just some events -- it should be decided on level higher.

Hmm. Interface-wise, the three "standard" channels have special behaviour, yes. But I thought stdin, stdout and stderr were just file descriptors that every process is automatically provided? So you already can have many files / pipes ... is this what you meant?

I think of channels akin to resources. Say you have a webserver running which provides channels: players, matches, replays. To any you may connect, subscribe to diffs for particular part of the tree, receive events.

Traditional Unix app provides only binary-stream output channels and it's up to you to figure it out how to work with it.

Not sure what you have in mind for trees as sequences. But the individual items in the sequence are still going to be key/value or input/output mappings, right? So all that seems to have happened, is we've gone from "tree" to "sequence of trees" -- but we might as well just have the original tree.

Diff for tree is also represented as tree. You just merge them into one single tree on receiving.

Sequence of diffs:

{ resource1: { status: started, startedAt: 1 } }
{ resource1: { connectedPlayers: { 'id12345': { rank: 123 } } }
{ resource1: { status: stopped, stoppedAt: 2, connectedPlayers: null } }

resulting tree:

{ resource1: { status: stopped, startedAt: 1, stoppedAt: 2, connectedPlayers: null } }

Diff is just a tree that should be merged into other tree.

In this video at around 25:33 (and elsewhere), Brian Will talks about something that sounds very similar.

Yeah, I think it's very similar to what I want to get. Thank you for sharing.

[vladimir-vg]

what we seek to do here is much more than adding embellishments to the conversational interface of teletypes and coming up with new data representations or APIs. We want to make a qualitative leap past what "programming" currently looks like and has looked like for decades.

I see having this teletype-step-higher-API shell environment as something that goes into direction of direct manipulation and visual programming. It may solve everyday problems better than today, and as a result get wide adoption.

I'm working on Erlang trace visualization tool and noticed that I'm reinventing that kind of API to work with objects I want to visualize. And it feels like some kind of this API is reinvented in other places too.

Maybe it should be made into something more standardized that can be reused between parties.

So what I understand of your proposal is this: Is this accurate? If so ... it would be a step higher, yes. :S

After reading and writing all of this I would say that I want to find out properties of an API that:

1. Provides access to remote resources (trees), sends updates as they change.
2. Provides structured logs, sequence of objects essentially.
3. Simple enough to be used on some remote IoT-device that reports about it's state, sends logs.
4. Simple enough to be implemented on many platforms.

[d-cook]

First off, I'm glad to see this kind of active discussion. I keep up with it, gain insights, and have things to contribute; but never get around to contributing.

Side track: I wonder if this is also the case with others? (I think the same thing was happening on the VPRI FONC list). What can we do about this?... That's one thing I appreciate about Joel's spill-all-the-raw-info approach. (TODO: Move this paragraph to a new issue)

... I'll continue my response in a new comment.

[d-cook]

In general, I'm seeing two different extremes for improving the state of software:

A. Start from scratch and redefine software / programming upon first principles (and perhaps re-determine what those principles are).

B. Find ways to push or augment existing things in a way that moves toward a better ideal, and in a way that is (incremental and) more likely to be adopted into actual use/practice.

I think both have merits (and necessity) not present in the other, and we should create the best environment / setup to support both (whatever that may mean). I see value in being able both to separate such, and to cross-pollinate ideas, goals, and approaches on both sides. (Go read or watch something about "symmetry breaking" by Jim Coplien or Christopher Alexander). Also, I sense a potential division / conflict from a lack of this differentiation between A and B.

(I myself am highly more interested & focused on A than B, and have at times been dismissive of B as not addressing certain problems at the "root")

(TODO: make a whole new issue (topic) for this, with discussion about what and how).

What I see here is perhaps one such situation between Unix (and files) as not a fundamental particle (i.e. why bother), versus as a way to move an existing system a step closer to something better. I'd like to see both sides see their full potential of exploration.

(Btw Joel: EXCELLENT article on the Unix system. I thoroughly enjoyed it, and I think it's highly relevant to a lot of what we are trying to do here)

[vladimir-vg]

(I myself am highly more interested & focused on A than B, and have at times been dismissive of B as not addressing certain problems at the "root")

Yeah, I'm strong proponent of the B =).

[pbazant]

Hi all, I am watching this discussion closely, but have troubles finding time to contribute. I even paused my non-tabular spreadsheet project and decided to first study Smalltalk, Symbolics Genera and Oberon (or Cedar if possible) in detail. My goal is to selectively study systems that are not poisoned by the Unix tradition. Pavel

On Mon, Jun 4, 2018 at 8:48 AM, Vladimir Gordeev notifications@github.com wrote:

(I myself am highly more interested & focused on A than B, and have at times been dismissive of B as not addressing certain problems at the "root")

Yeah, I'm strong proponent of the B =).

— 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/24#issuecomment-394251178, or mute the thread https://github.com/notifications/unsubscribe-auth/AHaunsjlexRnUR_ObrolHe2IxpIu3bGUks5t5NgxgaJpZM4UO9D1 .