@jauntywunderkind420 @enkiv2 @byron

You'd *think* that since constructors are a pretty universal part of OOP, that every conceivable data type or structured message WOULD be an instance (sic) of

new foo(bar,baz)

BUT

that just gives you a local reference to an instance of foo

Once you've got that reference... how do you communicate it to another system? It's not a 'message' in any meaningful sense now. Messages can be 'sent'. Objects... are not designed to be 'sent'.

It feels incomplete.

@natecull @jauntywunderkind420 @enkiv2 @byron Talking about method calls as "messages" is something that came out of Smalltalk, and is in my opinion incredibly misleading.

I've had debates with people online who strongly claim there is a difference between method calls in most Java-style object oriented languages and something like Smalltalk that talks about "messages". Most of the arguments seems to revolve around the idea that you can send messages (i.e. call methods) on instances that have not previously been declared to support such method calls.

At the end of the day, it all boils down to dynamic vs. static dispatch. But even for dynamic dispatch, referring to method calls as "messages" does nothing but confuse users and make it seem to complex than it actually is.

@loke @natecull @jauntywunderkind420 @enkiv2 @byron C++ and subsequently Java made that mistake in understanding,, as event based gui systems were not widely experienced yet. . messages are more like events than method calls. you can think of it as tthe difference between desugaring to
sendmsg(objectId, methodname, params) : void
vs
methodname(objectpointer, parans) : somevalue

the difference seems subtle but the former, with an extra level of indirection guves the dispatcher more freedom

@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.

@natecull @zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @loke

i think @zensaiyuki nailed a core point:

> enabling a client (web browser) to interact wirh a server without any prior knowledge of the remote application’s internal structure.

to me, json-ld and microdata or rdfa do a fantastic job of turning rest into a sea of universal & hyperlinked objects that can be navigated. i could not be more excited to start getting app & web app dev folks trying & using these systems, for once they start, i believe users & extensions will notice, & hypermedia & a new form of browsing will take off.

@natecull @zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @loke to call it out a little more, i think it will enable users to be involved with & to gather/collect/manipulate/relate to individual discrete objects.

i don't think we have any current examples of letting users relate to the entities/objects about them. starting to allow this connection is, imo, one of the main requirements to liberate personal computing & begin the revolution.

@jauntywunderkind420 @zensaiyuki @a_breakin_glass @enkiv2 @libc @byron @loke

I really want JSON-JD to be All The Things. But....

How do we scale JSON-JD *down* to the desktop? Can we? Cause I want my data on my desktop.

This is the reason for my question earlier in this thread about 'is JSON really practical for inter-window communication on the desktop?'

I'm not *quite* convinced that all window messages should be JSON-LD running over Structured Clone Algorithm and that's it, job solved.

@zensaiyuki @jauntywunderkind420 @a_breakin_glass @enkiv2 @libc @byron @loke

The obvious answer is that 'shuttling all widget communication through JSON would have the same problems that Electron does, ie, it would make everything bigger and slower and your mouse clicks would take seconds to process and everyone would swear at it'.

I don't know if this is actually the case or not.

I guess Gnome uses D-BUS for something similar, but I don't think its messages are as general as JSON.

@zensaiyuki @jauntywunderkind420 @a_breakin_glass @enkiv2 @libc @byron @loke

I do want, though, something *like* arbitrary JSON objects (up to megabytes in size) to be transferrable either between objects in a process, or widgets in a window, or windows from multiple applications in a desktop, or across the Internet. All with the same data model and semantics, if not the same protocol.

(because if it's not the same data model, you can't link your data; 'hyperdata' breaks down at that point).

@zensaiyuki @jauntywunderkind420 @a_breakin_glass @enkiv2 @libc @byron @loke

So let's say that Structured Clone Algorithm is everything you say it is.

*How many programs other than web browsers* currently implement it? That's my big question.

And why it worries me that the spec seems to be deliberately 'buried' and targeted ONLY at web browser developers.

To be useful, all apps on an operating system would need to implement this algorithm or have access to a service that provides it.

@zensaiyuki @jauntywunderkind420 @a_breakin_glass @enkiv2 @libc @byron @loke

Because the market for "web browser developers" is pretty small - there are like three web browsers in the world now? Chrome, Firefox, Webkit? Maybe Node if we extend it to "Javascript hosts"?

I'd like to see more than three codebases which can support an algorithm if that algorithm is going to be the equivalent of "TCP/IP for the desktop", ie, core infrastructure that MUST be fully understood and trusted.

@natecull @jauntywunderkind420 @a_breakin_glass @enkiv2 @libc @byron @loke because the big banner user facing version of it is this https://en.m.wikipedia.org/wiki/Web_Messaging
i just call it structured clone algorithm to clarify that it is not in fact “json” underneath.

and no there’s not really any non browser implementions that i know of, but the reasons are cultural, not technological. but, on windows anyway, their plan is for all desktop applications to be electron anyway, sooo

@zensaiyuki @jauntywunderkind420 @a_breakin_glass @enkiv2 @libc @byron @loke

Who's the "they" in this case?

@zensaiyuki @jauntywunderkind420 @a_breakin_glass @enkiv2 @libc @byron @loke

Oh! That's interesting. I guess it does have a chance then. Though MS have changed their desktop API story so many times now. Is this alongside or replacing WinRT, which was going to replace .NET, which was going to replace COM?

@zensaiyuki @jauntywunderkind420 @a_breakin_glass @enkiv2 @libc @byron @loke

I hope this strategy works better than Java did.

@natecull @jauntywunderkind420 @a_breakin_glass @enkiv2 @libc @byron @loke microsoft has been all in on the whole “apps are really webpages” strategy all the way back to anti-trust days. a surprising number of their basic apps have been using this thing all along:

https://en.m.wikipedia.org/wiki/HTML_Application