avocado goblin@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
@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)@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.
@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@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke i dunno, HATEOAS seems like a very smalltalky objecty idea
@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
@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.
@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke well, there’s HAL if you wanna do HATEOS in a more applicationy way
@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke
Hmm, what's HAL? Link?
@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.
@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
still stuck with JSON as a wire protocol but there’s worse fates
@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.
@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
the biggest improvement over json i have seen is json-seq, which addresses a specific issue json has with real time applications
@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”
@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke
Man everything would be much nicer if JSON hadn't made commas and quotes mandatory.
@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
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
@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke
It does seem weird that they even needed an RFC to specify that.
@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
@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
@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.
@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
@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke
Is there any One True Standard structured clone algorithm, or just a general approach?
@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke it is a ratified w3c standard.
@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke
Ah, it's a Javascript thing?
But I thought you just said that JSON isn't great for desktop use and that we'd need a faster protocol?
Or would W3C Structured Clone allow Javascript objects to be shared outside the world of the Javascript VM?
@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke it’s an html thing, technically. (html standard includes all the browser apis one typically thinks of as “javascript” but are in fact, webidl) and yes, it can technically transfer objects out of a javascript vm to other contexts
here’s the spec https://html.spec.whatwg.org/multipage/structured-data.html
@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke
Having read this document, I find myself none the wiser as to what actually has been defined.
It seems to leave quite a lot up to the individual object? What does it serialize *to*?
@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke
Oh.. it serializes object to the "record" type. That's... hmm.
There sure are a lot of exotic new types in Javascript these days.
@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke again, not a javascript thing
@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke or at least, not a thing visible from javascript land. it’s more something you’d run into reading the source code of the v8 engine
@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke
Oh, I see. ECMAScript "specification types" are not runtime Javascript entities.
That's exceedingly weird and frankly it's everything I dislike about modern programming habits.
Not just multiple types but multiple *types of types* that only exist at the VM level. Just.... ugh.
@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke
I mean at least one thing OOP got right was the idea that "everything is one kind of thing"
because if you have things that aren't things, that's just.... asking for trouble really. Or at least it means you end up with this big segmented tower of incompatible languages and systems and shouldn't we, really, know better than that, by now?
@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke look, specs are undeniably weird to read because they’re not written for you or me. they’re for people writing browsers and operating systems. the MDN page on structured clone algorithm is the user’s point of view.
the whole point of it from my perspective *is* how vague it is about how exactly it should work. it’s only specific about how it should appear to work, leaving the implementations free to innovate optimisations
the whole point of it from my perspective *is* how vague it is about how exactly it should work. it’s only specific about how it should appear to work, leaving the implementations free to innovate optimisations
@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke from a user’s point of view, it looks exactly like sending a json message. it just very sneakily doesn’t actially convert anythibg to json or even copy anything. it only needs to look like it’s copied the object in certain contexts
@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke
I feel like this standard/feature is... not entirely implemented yet?
https://dev.to/banks/deep-structured-cloning-in-javascript-5ah9
@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke it’s not implemented natively in node, but you and i have had a previous conversation where i investigated and found the best available polyfills for node.js, which implement the interfaces but don’t really do the optimisation bit.
@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke as for browser implementations, yeah, they all have it, they just don’t really loudly trumpet its pressnce like i do. it’s really a shared implementarion detail between a bunch of other apis where you would normally expect to be storing or sending a json object
@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke there are a number of “native webassembly” run times, i would be surprised if they didn’t have it. i’d also be surprised if they bother to mention it anywhere.
maybe deno has it built in.
maybe deno has it built in.
@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke
Generally if a framework goes out of its way NOT to mention a 'feature', isn't that a very loud warning that the feature is not intended to be used?
alcinnz@natecull I wouldn't say they went out of their way, there's plenty of feature bloat for them to trumpet!
@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke