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

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

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

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

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

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

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

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