@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.
@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.
@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.)
@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.
@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.
@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?
@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.
@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke
Hmm, what's HAL? Link?
@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.
@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke
Man everything would be much nicer if JSON hadn't made commas and quotes mandatory.
@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke
It does seem weird that they even needed an RFC to specify that.
@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.
@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke
Is there any One True Standard structured clone algorithm, or just a general approach?
@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.
@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?
@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
@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?
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...
@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.
@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?
@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
@natecull ah, my eyes have been fucked up all day, i have finally read that page properly. it’s talking about the state of implementations allowing you to access the structured clone function directly, not the internal version used by various APIs.
being able to access it directly would be handy, but unneeded if the idea is just json-like messaging with something lighter weight than json.
@natecull and that aspect has been around since… *reads notes* 2011
https://developers.google.com/web/updates/2011/12/Transferable-Objects-Lightning-Fast