Mastodawn

Nate Cull (.social)Oct 1, 2020

Spinning off a new thread because I really like this comment:

https://cybre.space/@jauntywunderkind420/104956363785764927

<< What I do see as a pure virtue that stood for something clear was 9p. Expose your state. Let it span systems. Use common os tools to manipulate state. >>

I like this because I think "expose state and use common tools" is a key design principle in big systems that work (eg, HTTP / REST) - but it also seems the opposite of OOP's "hide state" mantra.

Do we know why?

@jauntywunderkind420 @enkiv2 @byron

JauntyWunderKind (@[email protected])

@[email protected] @[email protected] @[email protected] I take to think those examples are good but also kind of irrelevant. They had good characteristics but only some aspects, amid a lot of things going on. It's too complicated to be clear. What I do see as a pure virtue that stood for something clear was 9p. Expose your state. Let it span systems. Use common os tools to manipulate state.

cybre.space

Nate Cull (.social)

@jauntywunderkind420 @enkiv2 @byron

Eg: I think hiding state is important too! There are many secrets we have to keep private, everything would fall apart if we didn't have information hiding as a key abstraction.

But... for getting things working, it feels like "let sealed objects handle everything" just kind of... doesn't work, because programmers always do bad things in their objects and never fix them, and so exposing state seems to be the only way we can route around bad programs?

Nate Cull (.social)Oct 1, 2020

@jauntywunderkind420 @enkiv2 @byron

Or is it more like "expose all state *that was transmitted to you*, and don't hide any inherited state?" Because that's usually data loss.

I don't know. I really don't know. Nothing much about what actually historically happened with these technologies seems to make sense.

Smalltalk was all about messaging, and was inspired by ARPANET, but the early Web doesn't seem like it was at all Smalltalky, though it was extremely ARPANETty. Do we understand why?

Nate Cull (.social)Oct 1, 2020

@jauntywunderkind420 @enkiv2 @byron

The Web 1.0 wasn't built on Javascript, but the 2020 Web is built on Javascript over CSS over SGML over HTTP over (webapp server) over SQL - at least six completely separate syntax / semantic layers. This seems non-optimal.

What if we removed everything except the somewhat-Smalltalky Javascript?

Could we rebuild the Web on just JS? Would it be better? It would be reasonably trivial to try, because Node.js would be the webapp server.

Nate Cull (.social)Oct 1, 2020

@jauntywunderkind420 @enkiv2 @byron

Alternatively, if rebuilding the entire Web on Javascript message sends (modulo maybe a NotUnderstood facility like Smalltalk had, or whatever else might be needed) demonstrably *doesn't* work, maybe because it's true that state needs to be exposed in some reliable manner...

.. could we go the other way, build a full-stack programming language on an analog of HTTP/REST?

Why or why not?

If 'not' to either of these, what are we missing?

Nate Cull (.social)Oct 1, 2020

@jauntywunderkind420 @enkiv2 @byron

One thing that has always bugged me deeply about OOP is that although it's supposedly all about messages, there is no standard or reliable way to represent 'just a chunk of structured data'.

I mean, you *could* conceivably represent 'a foo with parameters bar, baz' as something like

new foo(bar,baz)

or (something).foo(bar,baz)

but.... those aren't really defined in any sense, and aren't good for large messages (kilobytes to gigabytes).

Do we know why?

Nate Cull (.social)Oct 1, 2020

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

Elias Mårtenson Oct 1, 2020

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

𒀭𒂗𒆠 ENKI ][e Oct 1, 2020

@loke @natecull @jauntywunderkind420 @byron

It does, however, indicate a philosophy whereby one would expect to be able to send messages to remote nodes through exactly the same mechanisms -- which I think is core to what makes smalltalk-style OO distinct. The idea that messages are things floating around that can be forwarded, stored, sent over different media, ignored, etc. A method call is literally a name associated with a memory address in a text segment on a particular machine.

𒀭𒂗𒆠 ENKI ][e Oct 1, 2020

@loke @natecull @jauntywunderkind420 @byron

Referring to method calls as messages makes things more complicated for folks who already know what method calls are. But smalltalk was intended for, like, eight year olds in the 1970s.

JauntyWunderKind Oct 1, 2020

@enkiv2 @loke @natecull @byron
i like it. in particular, the suggestion that messages begin to re-ify the method call, turn it from abstract computation (loading another frame on the stack) to something fungible (that can be reasoned about & computed on).

that speaks to me much more directly than "static vs dynamic dispatch. programmability, directionally, build-on-top-ability of the message had really interesting whispered potentials.

Luci Rocks Oct 1, 2020

@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

Luci Rocks Oct 1, 2020

@loke @natecull @jauntywunderkind420 @enkiv2 @byron think about messages going onto queues. bring delivered by multiple different listeners, and so on. message streams that can be split, merged, filtered, sent over a network.

message formats as social conteacts, compared to function calls as personal implementation details.

Luci Rocks Oct 1, 2020

@loke @natecull @jauntywunderkind420 @enkiv2 @byron and the biggest one which is that it’s send only; no expectations about an immediate blocking action or return value. the recipient may call back, maybe not. who knows. social contract.

oh yes (sickos mode)Oct 1, 2020

@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 Oct 1, 2020

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

𒀭𒂗𒆠 ENKI ][e Oct 1, 2020

@libc @byron @zensaiyuki @natecull @jauntywunderkind420 @loke

This is a problem that keeps popping up, honestly. We do our GUI toolkits at the wrong layer. We either write them as imperative libraries and then don't make them work properly with modern language features, or we go the webtech way and hack some existing widget into pretending to be a general purpose canvas.

oh yes (sickos mode)Oct 1, 2020

@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?"

𒀭𒂗𒆠 ENKI ][e Oct 1, 2020

@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 Oct 1, 2020

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

𒀭𒂗𒆠 ENKI ][e Oct 1, 2020

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

Luci Rocks Oct 1, 2020

@enkiv2 @libc @byron @natecull @jauntywunderkind420 @loke so then it’s a little ironic to say the web wasn’t smalltalky, since the system it was implemented on was trying very hard to be smalltalky.

Nate Cull (.social)Oct 2, 2020

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

Nate Cull (.social)Oct 2, 2020

@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 Oct 2, 2020

@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

avocado goblin Oct 2, 2020

@natecull @zensaiyuki @enkiv2 @libc @byron @jauntywunderkind420 @loke OLE, OpenDoc, etc weren't truly flexible or open enough to really operate as such an alternative

Luci Rocks Oct 2, 2020

@a_breakin_glass @natecull @enkiv2 @libc @byron @jauntywunderkind420 @loke a bit of a libertarian dream though: turn documents into a dozen little plugin purchases the reader needs to make in order to just view the document

Luci Rocks Oct 2, 2020

@a_breakin_glass @natecull @enkiv2 @libc @byron @jauntywunderkind420 @loke kind of xanadu-like really

avocado goblin Oct 2, 2020

@natecull @zensaiyuki @enkiv2 @libc @byron @jauntywunderkind420 @loke objects were ultimately merely an implementation detail

Nate Cull (.social)Oct 2, 2020

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

Nate Cull (.social)Oct 2, 2020

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

I do think that maybe 95% of what made the Web take off was its being free.

I remember there being *dozens* of competing commercial hypertext systems in the late 1980s. Hypertext was an idea that was in the air, everyone wanted in, but 'globally networked hypertext' still felt like science fiction when even setting up a LAN was very costly.

All the commercial hypertext systems died because WWW was open and free.

Nate Cull (.social)Oct 2, 2020

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

I feel like part of the mystery maybe was the idea of classes was too chunky? Document parsing, and structures of SGML /XML /JSON nodes were much more flexible because you didn't have to bind your whole document to one inflexible 'class' that had to update as a unit?

Or maybe www just leveraged FTP, DNS et all and those weren't OOP-y but were just 'there and good enough'?

Luci Rocks Oct 2, 2020

@natecull @enkiv2 @libc @byron @jauntywunderkind420 @loke adding sgml was part of the process of making it work cross platform. you needed the wire protocol to not care what exact class heirarchy was available at the other end.

Luci Rocks Oct 2, 2020

@natecull @enkiv2 @libc @byron @jauntywunderkind420 @loke you could say that was where the web succeeded and other systems like corba failed. thanks to libwww, you could get the web to work on the computer you actually owned, not some fictional future computer that a theorist was excited would be ubiquitous someday

Luci Rocks Oct 2, 2020

@natecull @enkiv2 @libc @byron @jauntywunderkind420 @loke corba gained traction in enterprise spaces, where you could actually install the same system (and class heirarchy) on every workstation and server that needs to use it. i still need to use a corba based client for my job in 2020

Luci Rocks Oct 2, 2020

@natecull @enkiv2 @libc @byron @jauntywunderkind420 @loke my eyee bugged out of my head when i was watching a demo of the pre-web mac system 7.5’s new networking features: real time collaborative object oriented document editing over a (local) network

Luci Rocks Oct 2, 2020

@natecull @enkiv2 @libc @byron @jauntywunderkind420 @loke apple did implement something like that. it’s, i think what the itunes store was originally written with

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

aside from that, URL’s *are* opaque identifiers as far as http is concerned. the paths are just a convenience for automatically generating them off a file system. but, indeed, web servers don’t need to expose paths, or files. they just take the url as a string and return a response.

WebObjects - Wikipedia

Nate Cull (.social)Oct 2, 2020

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

My point is that I think the REST philosophy strongly disagrees with the idea that 'URLs are opaque'. As I recall, REST argues that URLs have to be strings so humans can write them.

By comparison: OOP identifiers *aren't* strings. They're machine addresses, compiled *from* strings but which only exist in source code files not the finished product. That made them fast but brittle.

Dropping back down to strings was important I think.

Nate Cull (.social)Oct 2, 2020

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

And for HTTP, it also wasn't just that URLs/URIs were strings... but that pages were expressed as 'documents' which were imported as strings.

NONE of this was at all standard late 1980s commercial desktop practice AIUI. Word processing documents weren't strings, they were binary RAM dumps. Everything was moving FROM strings TO objects.

But documents being old 1970s-era strings made the Web hugely accessible, portable and debuggable.

Nate Cull (.social)Oct 2, 2020

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

eg the comparable commercial hypertext systems, all of them that I know of, all had a 'compile' phase. You edited a document in some source form which MIGHT be a text file, or might be a WYSIWYG editor, but then you compiled it to the special secret sauce proprietary hypertext format of the engine of your choice (Hypercard, Microsoft Help, Folio VIEWS etc). The idea of a viewer that read raw text... was a massive throwback.

Nate Cull (.social)Oct 2, 2020

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

But I'm wondering now, was DynaText (being SGML) a missing link in the evolution of WWW?

There has to be a reason why Berners-Lee felt that SGML was an appropriate tool for the job of hypertext?

https://en.wikipedia.org/wiki/Dynatext

Dynatext - Wikipedia

Luci Rocks Oct 2, 2020

@natecull @enkiv2 @libc @byron @jauntywunderkind420 @loke REST is broadly misunderstood actually. one of its core principles is strongly that urls are opaque identifiers. a RESt protocol shouldn’t care what’s inside a url string

Luci Rocks Oct 2, 2020

@natecull @enkiv2 @libc @byron @jauntywunderkind420 @loke but to clarify, REST refers to multiple things, there’s REST the network architecture paper written by roy fielding, detailing the principles behind the deeign of the http protocol, and then theres RESTY apis, this informal idea about mapping urls to objects in an application and using http for application apis.

mathew 🦜☕Oct 2, 2020

@natecull @zensaiyuki @enkiv2 @libc @byron @jauntywunderkind420 @loke
The original HTTP and URL RFCs specified the semantics of parts of the URL, such as paths and query strings. REST built on that. Later RFCs gave up doing that because too many vendors violated the standard semantics, so now URLs are effectively opaque to the right of the hostname.

𒀭𒂗𒆠 ENKI ][e Oct 2, 2020

@natecull @zensaiyuki @libc @byron @jauntywunderkind420 @loke

If I recall, NeXT / ObjC actually *had* its own RPC (i.e., network-transparent message forwarding) and object transfer (can't recall if it serialized or just swizzled pointers).

(If it didn't, it should have, as a natural extension of the smalltalky nature of objc.)

TBL was doing development on NeXT but afaict he wasn't a NeXT *guy*.

𒀭𒂗𒆠 ENKI ][e Oct 2, 2020

@natecull @zensaiyuki @libc @byron @jauntywunderkind420 @loke

For instance, my understanding is that some design decisions around web rendering basically came down to the ease with which NeXTSteP's graphical GUI-builder application could be made to display or implement them -- not a sign that he had swallowed the object orientation ideology, but a sign that (just as with Eich some years later) he had to get this done in a couple days & didn't have time for design or forethought.

𒀭𒂗𒆠 ENKI ][e Oct 2, 2020

@natecull @zensaiyuki @libc @byron @jauntywunderkind420 @loke

TBL showed some interest, years later in web mailing lists, in trying to fix the mistakes he made during this period, and one of the big examples is how hard he argued for creating URIs.

Watching how nobody else in the mailing list really understood what he meant or why it was important for addresses to be disconnected from hosts and paths is depressing & reminds me of reading HN.

бyron Oct 11, 2020

@zensaiyuki @loke @natecull @jauntywunderkind420 @enkiv2 (Finally coming back to this discussion...) It's fascinating how syntactic sugar can matter. It seems C++/Java sort of said "oh hey, if message passing is implemented as method calls, why not just build an OOP language using method calls directly?"

But exposing that implementation detail, so ironically, limits what can be done -- like why OOP prefers setters/getters to direct variable access: so implementations can change.

бyron Oct 11, 2020

@zensaiyuki @loke @natecull @jauntywunderkind420 @enkiv2 It's fascinating how I see both web development and game engines using message passing and event paradigms. Clearly it can be efficient enough, and it's a really flexible approach.

This leads me to why I think CORBA sucked (I remember trying to learn it, sounded neat but was a nightmare in practice) and the web isn't C++ style OOP.

The C++ era OOP idea was coupling methods to data, which is super limited vs. message passing.

бyron Oct 11, 2020

@zensaiyuki @loke @natecull @jauntywunderkind420 @enkiv2 This is why we see this OOP vs FP stuff I think: the original Smalltalk idea (I think???) was that data types weren't inherently coupled to a class. You just send the data and it decides whether to react and how.

By coupling methods to data suddenly you have all these "design patterns" to play twister around the way different classes want to interact with the data, versus in FP where a function can just operate on data if it knows how.

Luci Rocks Oct 11, 2020

@byron @loke @natecull @jauntywunderkind420 @enkiv2

polymorphism > inherence

бyron Oct 11, 2020

@zensaiyuki @loke @natecull @jauntywunderkind420 @enkiv2 In a sense polymorphism is a limited version of what true message passing offers, where message passing just says "you send a message, no guarantee how it will be received" and polymorphism says "whoah, that sounds way too free, how about we just let you sometimes create different methods with the same name and pretend you have one slightly flexible method?"

Nate Cull (.social)Oct 11, 2020

@byron @zensaiyuki @loke @jauntywunderkind420 @enkiv2

I feel like a few things changed from the original OOP idea of "message sending":

1) The introduction of classes (or prototypes) as a way to answer 'what the heck kind of thing am I sending a message to, and what will it do?' Functional programming has a similar problem and 'types' is FP's answer. Both answers have problems.

2) Removing 'NotUnderstood' and making a message *instantly do a thing* instead of *be data that can be parsed*.

Nate Cull (.social)Oct 11, 2020

@byron @zensaiyuki @loke @jauntywunderkind420 @enkiv2

Re 1) I think we need a much more flexible idea of 'contracts' to replace both classes/prototypes and types. We need to be able to probe, prove and constrain what an object will do in response to messages (or else all security and testability dies in fire). But 'this is a Thing X, child of Thing Y' is far too simplistic.

1a) 'Inheritance' I think came from AI and 'frame logic' and I'd like to see more digging into that ancient idea.

Nate Cull (.social)Oct 11, 2020

@byron @zensaiyuki @loke @jauntywunderkind420 @enkiv2

Re 2) I want to see messages which are proper objects and can be stored, filtered, re-routed, created, etc. You can't do most of that with 'methods' in most post-Smalltalk OOP systems. I don't even know how easy it is to reify a message as an object in Smalltalk. But messages being inspectable objects that can be changed in transit is *exactly* what made both TCP/IP and the Web work. It's also the Net's biggest security flaw.

Nate Cull (.social)Oct 11, 2020

@byron @zensaiyuki @loke @jauntywunderkind420 @enkiv2

But, eg, since OOP is usually used alongside the GUI message loop, it's always shocked me that the message loop almost never operates on anything that remotely resembles an OOP 'message'.

Here's a programming paradigm based on 'objects send events', implemented in a programming language based on 'objects send messages' - but messages themselves aren't events! Madness!

Luci Rocks Oct 11, 2020

@natecull @byron @loke @jauntywunderkind420 @enkiv2 yeah it’s kinda funny how we ended up with these environments built on “object oriented” languages that you still had to build elaborate machinery in (event queues, event loops) to handle what is supposed to be just nativey object oriented message passing

Luci Rocks Oct 11, 2020

@natecull @byron @loke @jauntywunderkind420 @enkiv2 might as well drop back down to C and do sendmsg(id, name, params) and method(ctx, params) directly. why bother with the sugar that you ultimately need elaborate patterns to workaround anyway

Luci Rocks Oct 11, 2020

@natecull @byron @loke @jauntywunderkind420 @enkiv2 by the way, one nice thing about

method(ctx*, params*) over say,

method(ctx*, param1, params2, ...etc)

is that it works as a “reducer”, so you could really do cute functional programming inspired tricks with it, like queue up a bunch of messages from sendmsg(id, name, params) and pipe them into the concrete method handlers using “reduce/fold” as a dispatcher

Urusan Oct 12, 2020

@natecull @byron @zensaiyuki @loke @jauntywunderkind420 @enkiv2 Depending on exactly what you mean, this is either already being done in some systems or likely impossible.

How familiar are you with Java enterprise development? Due to how miserable Java is, the name of the game is to avoid writing Java. This has led to some very unusual systems emerging, some of which sound kinda like what you're proposing.

Urusan Oct 12, 2020

@natecull @byron @zensaiyuki @loke @jauntywunderkind420 @enkiv2 On the other hand, if what you are proposing is object oriented networking, then it's unlikely to succeed. Consider the simpler problem of transmitting an object: this was tried and has serious problems, especially if you want a wire format that isn't pure madness.

Maybe something like this is possible with some new ideas though.

Urusan Oct 12, 2020

@natecull @byron @zensaiyuki @loke @jauntywunderkind420 @enkiv2 The general consensus these days is to abandon OOP entirely, either explicitly or implicitly. It's being replaced by functional programming and sending either streams of fundamental data or structs (sometimes called data classes, since many are still in denial about this trend).

Admittedly, the "OOP" found in Java and the like isn't true OOP...