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*?
@natecull @a_breakin_glass @enkiv2 @libc @byron @jauntywunderkind420 @loke it doesn’t. that’s the point. it pretends to serialise to something but under the covers it’s just passing pointers and doing copy on write
JauntyWunderKindalso, lol, webidl originated with OMGIDL & CORBA. i have no idea how much CORBA legacy lives there.
for the most part WebIDL is abstract, is my impression. it defines what objects & platform stuff will be in the browser, what they will look like in JS. but i don't think it dictates how or what objects, methods, &c look like to the runtime, that they can structure themselves how they want. that said, there ARE language bindings for WebIDL that do just that, but i think the primary consumer of WebIDL is spec authors & browser users using it for reference materials, not for doing CORBA like stuff. i could be mistaken!
@zensaiyuki @natecull
pardon, chiming in at weird times. ya'll got into this split between the runtime objects & spec pretty shortly on your timelines. i keep jumping in where interested.
i agree it's weird & i really hope we can get webidl typing information more usable & in front of developers. it's weird that we have so many typescript enthusiasts, but so few people who care about types in the runtime??
@jauntywunderkind420 @natecull yes that’s right, WebIDL’s primary consumers are browser vendors. i didn’t realise that wasn’t clear from how i spoke. but i did want it clear that the stuff I was talking about isn’t “javascript stuff”, but stuff that’s intended to be available in any environment WebIDL specs for.
@jauntywunderkind420 @natecull it’s a bit anti-intuitive why i should be excited about a serialisation spec where the serialisarion format is implementation defined, but my point is it addesses the concern about json being ineffecient for local desktop use, by just vaguely pretending the serialisation format is still “JSON”, (and in some implementations it might be!) but since it’s put in places where the wire format is not directly observable, it can be anything, and do any optimisation
@jauntywunderkind420 @natecull and since it’s in webidl that could be between a javascript app and a c++ app. though i haven’t seen any specific examples of this, there’s no weird javascript specific impedence mismatch things standing in the way
@jauntywunderkind420 @natecull as for CORBA vs WebIDL, very similar actually. the original idea of CORBA after all was just to enable a standard way of shuttling function calls between different languages. putting a network in the middle was just an incidental and disasterous afterthought.
@jauntywunderkind420 @natecull aaand, that’s all WebIDL is. a machine readable spec for the interfaces between Javascript and the browser implementation language. or between Java and an html library. or whatever other combinations.