Spinning off a new thread because I really like this comment:
<< 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?
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?
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?
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.
.. 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?
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
but.... those aren't really defined in any sense, and aren't good for large messages (kilobytes to gigabytes).
Do we know why?
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
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.
It's only a local reference of it's not a universal reference. Give the thing a url & or uri & it's now a universal reference. This leads towards schools of thought where more donation objects have canonical URLs. Systems like In-Procesd ReST sorry of ventured this way. NetKernel / 1060 too. Ambient objects are about us.
<< Give the thing a url & or uri & it's now a universal reference. >>
Um, see, that's kind of my point - in order to get a URL you've now got to throw away the idea of 'OOP' and jump into the 1970s-Unix-text-protocol world of the Web.
URLs are not an objecty idea at all. They're a Unix-y filesystem-y idea. An OOP equivalent would literally be a machine address, maybe a pair of machine IP and RAM address in that machine.
This hybrid-ness bugs me...
.. because the point of programming *languages*, or programming languages paradigms like OOP, is that they're *universal*. They should be Turing complete, they should be able to subsume any kind of computation into them. And especially OOP, which views computation *as* communication between 'little computers', ought to be able to subsume all communication between *actual* computers, into itself.
But it didn't. And maybe it couldn't.
That's what bugs me.
To further clarify, in case it's not clear what about 'just use a URL' is bugging me so hard here:
The whole point of Objects as a paradigm is that references to them are *opaque identifiers*. You are not supposed, given an object reference, to be able to infer anything else from it. It's just a reference. The system hides it. That's the whole 'information hiding' deal, which is a key plank of OOP.
URLs are the opposite of that. They're revealed state.
So if we need URLs - or some other kind of identifier which is NOT opaque, which reveals some state - to make something as big as the Web work, when OOP was *specifically designed and intended* to be a universal paradigm for allowing vast networks of computers to communicate....
... then something has gone very wrong in our understanding of very core programming ideas. I'd like to understand what we failed to understand, and why and how we failed.
Like, one possible answer is 'we need a balance: we need to hide SOME state, and we need to reveal SOME OTHER state, and we can't make a planetary scale system without both, but only in the right proportion'.
If so, then okay: maybe we do need two diametrically opposed core philosophical programming paradigms (state hiding, state revealing), and we need to understand how to balance them. So, do we understand what that balance and proportion is?
We should note that we don't *have* URIs as they were originally envisioned. If we did, some of the major problems with webtech would be solved.
So, let's say URI rather than URL and, if possible, eliminate URL completely.
In other words: universal, immutable, unbreakable identifier for a particular version of a particular object, resolved to one of arbitrarily many redundant copies.
Une instance se voulant accueillante pour les personnes queers, féministes et anarchistes ainsi que pour leurs sympathisant·e·s. Nous sommes principalement francophones, mais vous êtes les bienvenu·e·s quelle que soit votre langue.
A welcoming instance for queer, feminist and anarchist people as well as their sympathizers. We are mainly French-speaking people, but you are welcome whatever your language might be.