avocado goblin@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.
@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke
It doesn't quite look like the level of polish I expect from a "solved problem" though, I guess.
@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke it’s a problem that is solved in browsers, fairly thoroughly and, may i add, invisibly! i think aside from brenden eich i am the only cheerleader for this feature.
to everyone else it’s just invisible and unimportant plumbing.
but- what can you already do with it? compile a c++ program to web assembly and let it draw to a binary canvas and transfer large objects in and out of javascript land without seriali overhead
@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke
"solved in browsers, fairly thoroughly"
Uh...
From 2017:
<<This needs a lot of polish>>
<< we're going to need some serious guidance on how to use them. >>
<< Hopefully this third rewrite of the algorithm is the one that puts us on solid ground. >>
https://github.com/whatwg/html/pull/2421
I... don't quite feel like this *is* 'thoroughly' solved, with statements like this?
[WIP] Refactor structured clone into serialize/deserialize steps by domenic · Pull Request #2421 · whatwg/html
This needs a lot of polish but I wanted to get it up there before @annevk woke up in case he was interested. Some review of the overall strategy would be good too. Points I am actively thinking abo...
@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke oh that. 1. that’s from 3 years ago.
2. it concerns the one outstanding hard problem with the whole areangement which is only a problem in the first place because people expect existing c++ programs to work with this. and that’s SharedArrayBuffer.
the reason it’s a hard problem is up until they realised that was needed, the assumption was this would all be shared nothing
2. it concerns the one outstanding hard problem with the whole areangement which is only a problem in the first place because people expect existing c++ programs to work with this. and that’s SharedArrayBuffer.
the reason it’s a hard problem is up until they realised that was needed, the assumption was this would all be shared nothing
@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke 3. SharedArrayBuffer will not ever be a user accessible feature. not directly. it’s intended to only be used by compiled c++ code with that one weird memory model expectation
@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke what makes it challenging is making sure it only gets used if it absolutely positively has to, because there’s security and safety implications. but the only thing it’s blocking from working is certain specific c++ programs that can’t be written in a different way for some reason
@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke past that, people have been happily using indexeddb, webworkers, and postmessage for years, using the structured clone algorithm without even realising it.
@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke basically, from tbe looks of things, some people want to run their weird old c++ programs in a browser without rewritinf anything and, you need SharedArrayBuffer to do that. but nobody wants to implement SharedArrayBuffer because it’s an awful feature that frankly no one *should* implement, and it’s a shame that makes the whole thing seem “unfinished” or “incomplete” somehow but it really isn’t unless you own the c++ app.
@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke and I just had a peak at deno and it’s there. not visible in any obvious public api, just quietly used as a utility function in any built in module that needs a cloned object- “fetch” and “stream” in particulae
@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke Brendan Eich said this would only be implemented over his dead body, but, here it is. has anyone checked up on him lately?
JauntyWunderKind@zensaiyuki @natecull @a_breakin_glass @enkiv2 @libc @byron @loke
SharedArrayBuffer is amazing & beautiful.
we programmers have collectively lost-our-shit & freaked out that memory is in fact all shared & all mutable, been burned too many times, & have gone into a close-minded fascist totalitarian lockdown against the gods-honest-truth of what we work with.
rather than embrace the power, we have renounced it. but it's still the fastest, most direct, most honest form of programming there is on the web. and much much much good can come from SharedArrayBuffer. there will be countless footguns & pain & security-tracking problems here too, absolutely, but we have amazing multi-agent systems forming on the web, many tabs & workers collaborating, & SharedArrayBuffer is uniquely powerful & competent at connecting us all up.
@jauntywunderkind420 @natecull @a_breakin_glass @enkiv2 @libc @byron @loke pardon me for not wanting a webpage to therac-25 my machine without my consent.