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