Mastodawn

Nate Cull (.social)Oct 1, 2020

Spinning off a new thread because I really like this comment:

https://cybre.space/@jauntywunderkind420/104956363785764927

<< What I do see as a pure virtue that stood for something clear was 9p. Expose your state. Let it span systems. Use common os tools to manipulate state. >>

I like this because I think "expose state and use common tools" is a key design principle in big systems that work (eg, HTTP / REST) - but it also seems the opposite of OOP's "hide state" mantra.

Do we know why?

@jauntywunderkind420 @enkiv2 @byron

JauntyWunderKind (@[email protected])

@[email protected] @[email protected] @[email protected] I take to think those examples are good but also kind of irrelevant. They had good characteristics but only some aspects, amid a lot of things going on. It's too complicated to be clear. What I do see as a pure virtue that stood for something clear was 9p. Expose your state. Let it span systems. Use common os tools to manipulate state.

cybre.space

Nate Cull (.social)Oct 1, 2020

@jauntywunderkind420 @enkiv2 @byron

Eg: I think hiding state is important too! There are many secrets we have to keep private, everything would fall apart if we didn't have information hiding as a key abstraction.

But... for getting things working, it feels like "let sealed objects handle everything" just kind of... doesn't work, because programmers always do bad things in their objects and never fix them, and so exposing state seems to be the only way we can route around bad programs?

Nate Cull (.social)Oct 1, 2020

@jauntywunderkind420 @enkiv2 @byron

Or is it more like "expose all state *that was transmitted to you*, and don't hide any inherited state?" Because that's usually data loss.

I don't know. I really don't know. Nothing much about what actually historically happened with these technologies seems to make sense.

Smalltalk was all about messaging, and was inspired by ARPANET, but the early Web doesn't seem like it was at all Smalltalky, though it was extremely ARPANETty. Do we understand why?

Nate Cull (.social)Oct 1, 2020

@jauntywunderkind420 @enkiv2 @byron

The Web 1.0 wasn't built on Javascript, but the 2020 Web is built on Javascript over CSS over SGML over HTTP over (webapp server) over SQL - at least six completely separate syntax / semantic layers. This seems non-optimal.

What if we removed everything except the somewhat-Smalltalky Javascript?

Could we rebuild the Web on just JS? Would it be better? It would be reasonably trivial to try, because Node.js would be the webapp server.

Nate Cull (.social)Oct 1, 2020

@jauntywunderkind420 @enkiv2 @byron

Alternatively, if rebuilding the entire Web on Javascript message sends (modulo maybe a NotUnderstood facility like Smalltalk had, or whatever else might be needed) demonstrably *doesn't* work, maybe because it's true that state needs to be exposed in some reliable manner...

.. could we go the other way, build a full-stack programming language on an analog of HTTP/REST?

Why or why not?

If 'not' to either of these, what are we missing?

Nate Cull (.social)Oct 1, 2020

@jauntywunderkind420 @enkiv2 @byron

One thing that has always bugged me deeply about OOP is that although it's supposedly all about messages, there is no standard or reliable way to represent 'just a chunk of structured data'.

I mean, you *could* conceivably represent 'a foo with parameters bar, baz' as something like

new foo(bar,baz)

or (something).foo(bar,baz)

but.... those aren't really defined in any sense, and aren't good for large messages (kilobytes to gigabytes).

Do we know why?

Nate Cull (.social)Oct 1, 2020

@jauntywunderkind420 @enkiv2 @byron

You'd *think* that since constructors are a pretty universal part of OOP, that every conceivable data type or structured message WOULD be an instance (sic) of

new foo(bar,baz)

BUT

that just gives you a local reference to an instance of foo

Once you've got that reference... how do you communicate it to another system? It's not a 'message' in any meaningful sense now. Messages can be 'sent'. Objects... are not designed to be 'sent'.

It feels incomplete.

Elias Mårtenson Oct 1, 2020

@natecull @jauntywunderkind420 @enkiv2 @byron Talking about method calls as "messages" is something that came out of Smalltalk, and is in my opinion incredibly misleading.

I've had debates with people online who strongly claim there is a difference between method calls in most Java-style object oriented languages and something like Smalltalk that talks about "messages". Most of the arguments seems to revolve around the idea that you can send messages (i.e. call methods) on instances that have not previously been declared to support such method calls.

At the end of the day, it all boils down to dynamic vs. static dispatch. But even for dynamic dispatch, referring to method calls as "messages" does nothing but confuse users and make it seem to complex than it actually is.

Luci Rocks Oct 1, 2020

@loke @natecull @jauntywunderkind420 @enkiv2 @byron C++ and subsequently Java made that mistake in understanding,, as event based gui systems were not widely experienced yet. . messages are more like events than method calls. you can think of it as tthe difference between desugaring to
sendmsg(objectId, methodname, params) : void
vs
methodname(objectpointer, parans) : somevalue

the difference seems subtle but the former, with an extra level of indirection guves the dispatcher more freedom

oh yes (sickos mode)Oct 1, 2020

@zensaiyuki @loke @natecull @jauntywunderkind420 @enkiv2 @byron it makes it really weird that no one's implemented a GUI app in Erlang other than Wings and the integrated debugger

𒀭𒂗𒆠 ENKI ][e Oct 1, 2020

@libc @byron @zensaiyuki @natecull @jauntywunderkind420 @loke

There are TK erlang bindings. About ten years ago, I ported a large prolog project to erlang (though I didn't, and still don't, really know erlang) & wrote a fair amount of gui code related to that.

But, thing is, the GUI toolkit itself was not erlangy. It was a binding to tk, which is C++ and really intended to be embedded in tcl. So, for instance, it wants to be single-threaded with an event loop.

oh yes (sickos mode)Oct 1, 2020

@enkiv2 @byron @zensaiyuki @natecull @jauntywunderkind420 @loke Erlang ships with Wx bindings, and Wx is.... less antiquated looking OOTB than Tk. still, doing Win32 rawdog programming makes me realize "shit, why can't i just receive {paint, Hwnd, Dc} messages?"

𒀭𒂗𒆠 ENKI ][e Oct 1, 2020

@libc @byron @zensaiyuki @natecull @jauntywunderkind420 @loke

Maybe I used Wx rather than Tk. I don't really remember. It's still sort of the same issue.

And, of course, 'antiquated' is kind of funny because the ideal we're reaching for (properly message-based OO GUI toolkit) is... in smalltalk 78.

Luci Rocks Oct 1, 2020

@enkiv2 @libc @byron @natecull @jauntywunderkind420 @loke i am not sure i understand smalltalk 78 but my understanding is even smalltalk ended up compromising the messages concept, partly because performance of 1979’s conputers, partly because nobody had failed at it enough times yet to know how not to do it.

𒀭𒂗𒆠 ENKI ][e Oct 1, 2020

@zensaiyuki @libc @byron @natecull @jauntywunderkind420 @loke

The underlying implementation of smalltalk for the alto turned messages into method calls for performance reasons. From what I understand, the language itself didn't break the message paradigm despite this, & graphics programming was async-friendly. (But, my familiarity with it is currently mostly second-hand.)

Luci Rocks Oct 1, 2020

@enkiv2 @libc @byron @natecull @jauntywunderkind420 @loke so then it’s a little ironic to say the web wasn’t smalltalky, since the system it was implemented on was trying very hard to be smalltalky.

Nate Cull (.social)Oct 2, 2020

@zensaiyuki @enkiv2 @libc @byron @jauntywunderkind420 @loke

Right! That's one the things that fascinates me. Berners-Lee writes WWW on a NeXT, which at least advertised itself as object-oriented, and if this factoid is true then he writes it heavily relying on NeXT's OOP framework...

... But no trace of that framework and its objects extends over the network. Isn't that odd? And interesting?

Naively one would expect WWW pages to have been serialised NeXT object classes. They very weren't.

Nate Cull (.social)Oct 2, 2020

@zensaiyuki @enkiv2 @libc @byron @jauntywunderkind420 @loke

For comparison: from the same era, Microsoft Word .doc files of early 1990s were *massively* more OOP than the Web. They were literally just collections of objects but *because* they were just RAM dumps of objects they were unsuited to traversing multiple systems.

And MS thought they'd beat the Web because they were OOP and 'modern' and Web wasn't, until around 1995.

avocado goblin Oct 2, 2020

@natecull @zensaiyuki @enkiv2 @libc @byron @jauntywunderkind420 @loke but that was obviously a proprietary format, and also worked on systems where objects were second class citizens so to speak

avocado goblin Oct 2, 2020

@natecull @zensaiyuki @enkiv2 @libc @byron @jauntywunderkind420 @loke OLE, OpenDoc, etc weren't truly flexible or open enough to really operate as such an alternative

@natecull @zensaiyuki @enkiv2 @libc @byron @jauntywunderkind420 @loke objects were ultimately merely an implementation detail

Nate Cull (.social)Oct 2, 2020

@a_breakin_glass @zensaiyuki @enkiv2 @libc @byron @jauntywunderkind420 @loke

Right. I think that's the part that still niggles at me. Why *did* objects end up just being an implementation detail, when the whole idea of an object was 'here is a small machine that is a thing'?

'An object is a thing' *seems* to make intuitive sense. BUT!

The BIG but is that an object is generally 'a thing you can't give to anyone'.

To 'give' an object you have to radically destructure it. Parse to text etc.

Luci Rocks Oct 2, 2020

@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke down in the dirt, we end up needing to make hard choices

Nate Cull (.social)Oct 2, 2020

@a_breakin_glass @zensaiyuki @enkiv2 @libc @byron @jauntywunderkind420 @loke

So as a programming paradigm, objects seems.... not to be as universal as it wanted to be.

Something about objects seems to weld them to very specific machine contexts that they can't be easily unwelded.

Data formats that can be easily transmitted, and survive multiple systems, seem to be very non-objecty.

This doesn't seem to be what any of the OOP proponents ever wanted. But why couldn't they see that?

Luci Rocks Oct 2, 2020

@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke i dunno, HATEOAS seems like a very smalltalky objecty idea

Luci Rocks Oct 2, 2020

@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke like smalltalk, and OOP, people focused in on the wrong idea in REST: thinking REST was about URLs, when really it’s about hyperlinks (and forms) enabling a client (web browser) to interact wirh a server without any prior knowledge of the remote application’s internal structure. a strong contrast with modern “REST” apis that now have an ecosystem thar has reinvented CORBA again but named it OPENAPI/Swagger

Nate Cull (.social)Oct 2, 2020

@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke

I really like that idea of inverting the application state into a message-like thing that the client holds as a ticket and sends to the server.

However I wish we weren't trying to do that over a protocol built to transfer and display literal documents, because nothing about a REST application is anything like a document.

Especially if we wanted to scale *down* to the desktop - we'd want a very small, fast protocol.

Luci Rocks Oct 2, 2020

@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke well, there’s HAL if you wanna do HATEOS in a more applicationy way

Nate Cull (.social)Oct 2, 2020

@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke

Hmm, what's HAL? Link?

Luci Rocks Oct 2, 2020

@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke https://en.m.wikipedia.org/wiki/Hypertext_Application_Language

Hypertext Application Language - Wikipedia

Luci Rocks Oct 2, 2020

@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke it says it’s “draft” but it’s what amazon uses for all of its apis.

Luci Rocks Oct 2, 2020

@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke a somewhat more sophisticated version is JSONAPI that is still HATEOAS style but addesses some of the annoying limitations of HAL.
still stuck with JSON as a wire protocol but there’s worse fates

Nate Cull (.social)Oct 2, 2020

@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke

I guess I'm wondering if JSON is too heavyweight to be used as a desktop protocol, even for widgets within a windowl? Or do we all have enough excess CPU cycles now that that's not a problem?

Cos if it is too heavyweight then we gonna need another protocol.

Luci Rocks Oct 2, 2020

@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke there’s plenty of binary json-like protocols to choose from, but from what i have seen, the tradeoffs are rarely worth it.
the biggest improvement over json i have seen is json-seq, which addresses a specific issue json has with real time applications

Luci Rocks Oct 2, 2020

@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke don’t bother looking it up. it has a huge rfc that can be summed up as “linefeed seperated json objects”

Nate Cull (.social)Oct 2, 2020

@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke

Man everything would be much nicer if JSON hadn't made commas and quotes mandatory.

Elias Mårtenson Oct 2, 2020

@natecull @zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 It would have been even nicer if they didn't leave fundamental features such as the behaviour of numbers unspecified. Seriously, how useful is a data interchange format where you cannot be certain that storing an integer N will actually return N when deserialised? Well, JSON does that.

Luci Rocks Oct 2, 2020

@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke oh, maybe i need to clarify a bit- json-seq doesn’t address that.
it just specifies that in your message channel you are sending multiple seperate json objects, seperated by lines, instead of just one big single json object. this lets a reciever respond incrementally without first having to parse a big monolithic json it receieves as a big chonk

Nate Cull (.social)Oct 2, 2020

@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke

It does seem weird that they even needed an RFC to specify that.

Luci Rocks Oct 2, 2020

@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke well, you see, three different people had the same idea at the same time, and the different versions are not exactly the same. so the rfcs (and i think all three have them) are to name the variants and pin down exactly what’s different about them

Luci Rocks Oct 2, 2020

@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke the other problem with json as a desktop ipc mechanism is, from the platform engineer’s perspective, all the needless translation between text and objects that goes on. it’s not an issue for small infrequent calls, but say, send an entire photo library from one app to another and your computer hangs from mostly just doing that needless serialisation and i deserialisation

Nate Cull (.social)Oct 2, 2020

@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke

Yep.

I guess that's why I keep coming back to 'at the bottom of the tower of bits, you probably just want something like an array of machine words, a type tag, a length' and even then that gets messy, with bitness, word size, memory allocation, etc.

Nate Cull (.social)Oct 2, 2020

@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke

and if you were doing anything approaching JSON over top of that, you'd probably want a symbol table so strings can be integers, a way of searching that table rapidly, strategies in place for when some evil person tries to give you a petabyte-sized string, etc

Luci Rocks Oct 2, 2020

@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke i keep beating this drum but, “structured clone algorithm” is a direct answer to this specific issue. it just, has a really uncatchy name

JauntyWunderKind Oct 2, 2020

@natecull @zensaiyuki

well there's a lot of ways to do it! json-seq, ndjson, jsonlines! everyone has different ideas for how to stream json-like data. :)

https://github.com/ndjson/ndjson-spec/issues/25 mentions a bunch of these & has some discussion. having read it i think i might switch ndjson->json-seq. also anything with an rfc ftw. #rfc7464!

Relation to JSON Text Sequences standard · Issue #25 · ndjson/ndjson-spec

What is the relation to the JSON Text Sequences RFC? Seems that it is being picked up by some projects, e.g. GeoJSON.

JauntyWunderKind Oct 2, 2020

@natecull imo it's not too heavy.

* json compresses very well, we have wonderful practically free compression tools (zstd is magic, LZHAM for data we compress-once read-many).
* we have very excellent routines to very quickly serialize & deserialize json. throughput is quite good.

there are other serializing techs afoot. i personally think cbor is not-bad, where-as most of them strike me as a whole bag of restrictions & constraints & pain that do nothing to help the broader we, & i think they are actively degrading the field & sapping our energy with "upside" that is fake/wrong.

so technically i think json is pretty good, fair.

(#JsonLD otoh divine. it turns just add a little @context, do the same thing (some caveats do apply), and now everyone knows what it is your are talking about. #HypermediaHo!)

the real struggles we face, trying to find where & how to advance? making the data navigable, exposing it to users. i keep asking how we emerge the data into something usable. the data-format feels tertiary.

JauntyWunderKind Oct 2, 2020

@zensaiyuki @natecull @a_breakin_glass @enkiv2 @libc @byron @loke i had no idea aws uses HAL for it's apis. HAL is fairly old, it ignored some very good existing work, but it is a pretty reasonable pretty decent take from a very good dev.

i had no idea amazon was such a strong practitioner of hypermedia systems!! neat. til. thanks.

Nate Cull (.social)Oct 2, 2020

@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke

I suppose to me the idea of REST that's missing from the conventional windowed deskop is that that every window in any state is a 'view' over some giant abstract space of data, and that every such window has an identifier that you can sort of peel off and save and restore.

Sort of like the UI equivalent of continuations in Scheme, I guess?

It seems something we should have much more of on the desktop.

Nate Cull (.social)Oct 2, 2020

@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke

I think this is the feeling of what's missing that I've been groping for for a while...

... the idea that if possible there shouldn't be separate 'applications' (maybe libraries), there should just be windows into state. And that since each window represents a locus of interaction between you and the machine, you should be able to have as many as you want. They shouldn't block.

But we have so many blocking windows.

Nate Cull (.social)Oct 2, 2020

@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke

Imagine if you were playing a game, and you didn't know what path to go, north or south. So you just right-clicked and spun off another window. Now you got two windows on the game state, each of which you can play at the same time, taking a different path in each one, or close and then open in the future. And the game doesn't know you're doing any of this, so it can't say 'nope'.

This is what I want for all 'apps'.

Nate Cull (.social)Oct 2, 2020

@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke

I put 'apps' in quotes because I don't want there to *be* apps. I want there to be state, and rules that cause state to change, and a user interface that is thoroughly decoupled from any of those rules so they can't get in the way. So there's *always* versioning, history, a 'back' button, save functions, etc. All of that's just done at the UI/OS/VM level. It's none of the 'app's business.

I just want data and rules.

JauntyWunderKind Oct 2, 2020

@natecull @zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @loke

i think @zensaiyuki nailed a core point:

> enabling a client (web browser) to interact wirh a server without any prior knowledge of the remote application’s internal structure.

to me, json-ld and microdata or rdfa do a fantastic job of turning rest into a sea of universal & hyperlinked objects that can be navigated. i could not be more excited to start getting app & web app dev folks trying & using these systems, for once they start, i believe users & extensions will notice, & hypermedia & a new form of browsing will take off.

JauntyWunderKind Oct 2, 2020

@natecull @zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @loke to call it out a little more, i think it will enable users to be involved with & to gather/collect/manipulate/relate to individual discrete objects.

i don't think we have any current examples of letting users relate to the entities/objects about them. starting to allow this connection is, imo, one of the main requirements to liberate personal computing & begin the revolution.

Nate Cull (.social)Oct 3, 2020

@jauntywunderkind420 @zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @loke

I really want JSON-JD to be All The Things. But....

How do we scale JSON-JD *down* to the desktop? Can we? Cause I want my data on my desktop.

This is the reason for my question earlier in this thread about 'is JSON really practical for inter-window communication on the desktop?'

I'm not *quite* convinced that all window messages should be JSON-LD running over Structured Clone Algorithm and that's it, job solved.

Luci Rocks Oct 3, 2020

@natecull @jauntywunderkind420 @a_breakin_glass @enkiv2 @libc @byron @loke can you think of s case where that wouldn’t cut it?

Nate Cull (.social)Oct 3, 2020

@zensaiyuki @jauntywunderkind420 @a_breakin_glass @enkiv2 @libc @byron @loke

The obvious answer is that 'shuttling all widget communication through JSON would have the same problems that Electron does, ie, it would make everything bigger and slower and your mouse clicks would take seconds to process and everyone would swear at it'.

I don't know if this is actually the case or not.

I guess Gnome uses D-BUS for something similar, but I don't think its messages are as general as JSON.

Nate Cull (.social)Oct 3, 2020

@zensaiyuki @jauntywunderkind420 @a_breakin_glass @enkiv2 @libc @byron @loke

I do want, though, something *like* arbitrary JSON objects (up to megabytes in size) to be transferrable either between objects in a process, or widgets in a window, or windows from multiple applications in a desktop, or across the Internet. All with the same data model and semantics, if not the same protocol.

(because if it's not the same data model, you can't link your data; 'hyperdata' breaks down at that point).

Nate Cull (.social)Oct 3, 2020

@zensaiyuki @jauntywunderkind420 @a_breakin_glass @enkiv2 @libc @byron @loke

So let's say that Structured Clone Algorithm is everything you say it is.

*How many programs other than web browsers* currently implement it? That's my big question.

And why it worries me that the spec seems to be deliberately 'buried' and targeted ONLY at web browser developers.

To be useful, all apps on an operating system would need to implement this algorithm or have access to a service that provides it.

Nate Cull (.social)Oct 3, 2020

@zensaiyuki @jauntywunderkind420 @a_breakin_glass @enkiv2 @libc @byron @loke

Because the market for "web browser developers" is pretty small - there are like three web browsers in the world now? Chrome, Firefox, Webkit? Maybe Node if we extend it to "Javascript hosts"?

I'd like to see more than three codebases which can support an algorithm if that algorithm is going to be the equivalent of "TCP/IP for the desktop", ie, core infrastructure that MUST be fully understood and trusted.

Luci Rocks Oct 3, 2020

@natecull @jauntywunderkind420 @a_breakin_glass @enkiv2 @libc @byron @loke because the big banner user facing version of it is this https://en.m.wikipedia.org/wiki/Web_Messaging
i just call it structured clone algorithm to clarify that it is not in fact “json” underneath.

and no there’s not really any non browser implementions that i know of, but the reasons are cultural, not technological. but, on windows anyway, their plan is for all desktop applications to be electron anyway, sooo

Web Messaging - Wikipedia

Nate Cull (.social)Oct 3, 2020

@zensaiyuki @jauntywunderkind420 @a_breakin_glass @enkiv2 @libc @byron @loke

Who's the "they" in this case?

Luci Rocks Oct 3, 2020

@natecull @jauntywunderkind420 @a_breakin_glass @enkiv2 @libc @byron @loke microsoft.
all their major apps are electron apps now. it’s kinda why they bought github, so electron could become the official “native” windows gui toolkit.

Nate Cull (.social)Oct 3, 2020

@zensaiyuki @jauntywunderkind420 @a_breakin_glass @enkiv2 @libc @byron @loke

Oh! That's interesting. I guess it does have a chance then. Though MS have changed their desktop API story so many times now. Is this alongside or replacing WinRT, which was going to replace .NET, which was going to replace COM?

Luci Rocks Oct 3, 2020

@natecull @jauntywunderkind420 @a_breakin_glass @enkiv2 @libc @byron @loke well, they’ve stuck to this story for at least 5 years now, but yeah, all i know is i saw some mucrosoft engineers talking on twitter excited to be building all the office apps in react+typescript, and someday “soon” eliminating that famouse bloated electron download and runtime by making electron the new internet explorer- that is, integrate it into the os so you’re not downloading/executing multiple copies

Nate Cull (.social)Oct 3, 2020

@zensaiyuki @jauntywunderkind420 @a_breakin_glass @enkiv2 @libc @byron @loke

I hope this strategy works better than Java did.

Luci Rocks Oct 3, 2020

@natecull @jauntywunderkind420 @a_breakin_glass @enkiv2 @libc @byron @loke microsoft has been all in on the whole “apps are really webpages” strategy all the way back to anti-trust days. a surprising number of their basic apps have been using this thing all along:

https://en.m.wikipedia.org/wiki/HTML_Application

HTML Application - Wikipedia

Nate Cull (.social)Oct 3, 2020

@zensaiyuki @jauntywunderkind420 @a_breakin_glass @enkiv2 @libc @byron @loke

I mean yes I suppose if we had an "ElectronOS" (which wasn't hard-wired into Google) then that might make things simpler in some ways for this kind of hyperlinking. Just leverage the browser to do everything on the desktop.

I guess I'm jaded because around 1998, this was the expectation we had around the first open-sourcing of Mozilla, that we could use webtech to make desktops, and that just sort of flamed out.

Luci Rocks Oct 3, 2020

@natecull @jauntywunderkind420 @a_breakin_glass @enkiv2 @libc @byron @loke though the underlying protocol isn’t “json” (though it *could* be anything, including json) , i believe the whole thing originared with this 2006/2007 essay from crockford, json’s “discoverer”

https://web.archive.org/web/20070220031311/http://www.json.org/module.html

he got heavily involved in web standards around the time the suspiciously familiar web messaging spec appeared in browsers. i just haven’t found the smoking gun and the fingerprints yet

The <module> Tag

Luci Rocks Oct 3, 2020

@natecull @jauntywunderkind420 @a_breakin_glass @enkiv2 @libc @byron @loke iframes do also have the “sandbox” attribute now which realises most of the rest of the module tag concept

𒀭𒂗𒆠 ENKI ][e Oct 3, 2020

@natecull @zensaiyuki @jauntywunderkind420 @a_breakin_glass @libc @byron @loke

Display postscript was faster, on weaker machines. JSON / javascript isn't the bottleneck in electron; html is

Nate Cull (.social)Oct 3, 2020

@jauntywunderkind420 @zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @loke

Basically I guess JSON as the inter-widget protocol on the desktop would be roughly equivalent to Tcl/Tk and its text string windowing protocol.

Is that feasible, again, now? *Could* we do this?

JSON (or maybe JSON-SEQ) as a protocol for Unix shell pipelines would get us a few steps further towards what Powershell does for Windows.

JauntyWunderKind Oct 4, 2020

@natecull
I used ndjson & will switch to json-seq to push data between programs atm, very easy. But it's for very simple systems, each expecting some specific form of stdin or writing some specific stdout. I don't feel like that's enough handholding, enough structure to build a desktop environment around. It's simple but too simple, anything could be anything.

Linux/freedesktop typically uses DBus. Which tends to require some programming chops to use. One could imagine writing tools to help users & tools publish & consume data there more readily but it's pretty heavy.

There's varlink, which is a json based interface & protocol. Again somewhat programming intensive. I think it makes clearer though some possible structures that "just json" doesnt help with.
https://varlink.org/

VARLINK

The Varlink Website

VARLINK

Luci Rocks Oct 2, 2020

@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke this idea is so normalised now we don’t even see it as anything special. we hear people talk about “REST” and think it must be something more interesting than literally just browsing a dynamic website (say, youtube for instance)

Nate Cull (.social)Oct 2, 2020

@a_breakin_glass @zensaiyuki @enkiv2 @libc @byron @jauntywunderkind420 @loke

I mean, LOTS and LOTS of people, through the 1980s and 1990s, were SCREAMING at the object folks saying 'you are idiots for welding code to data! don't do that! nothing will work!' and all the object folks were like 'no no this is the future you oldies just don't understand'

But I think the oldies turned out to have been right? For every object we build it seems we need a parallel, separate, data format/tool for it.

Nate Cull (.social)Oct 2, 2020

@a_breakin_glass @zensaiyuki @enkiv2 @libc @byron @jauntywunderkind420 @loke

And now in the age of containers and programmable infrastructure, we still use as our unit of state..... text files.

We build objects the size of computers using one-way transformations out of piles of scripts and JSON in text files , because text files are the only thing we can trust to be there between computers.

Maybe this was always how it was gonna be.