oh yes (sickos mode)@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@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.
@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?"
@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@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.
@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.)
Nate Cull (.social)@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.
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
@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?
@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
@zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke
If it's not a Javascript thing, why is it defined in terms of Javascript objects and Javascript types....?
or do you mean it's not a "Javascript thing" because it's technically ECMAScript?
@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke it’s an abstraction used in the spec, like a “call object” representing the collection of scope variables that get carried along with a closure.
it’s not directly visible from javascript, and might not even actually be in the implementation either. it’s just a way of talking about how it should look like it’s acting
it’s not directly visible from javascript, and might not even actually be in the implementation either. it’s just a way of talking about how it should look like it’s acting