Two mutually exclusive things I want:
* Everything is a live stream of filtering/reducing functions over Lisplike tokens (because reactive and symbolic and literate)
* Everything is also an object (because safe)
You'd think that a function could *be* an object. You just keep 'sending' it (applying it to) a sequence of values, those are the messages.
But how does it receive the 'end stream' message? What value is that?
A similar problem to
.apply-filter [ .* 2 ] [ 1 2 3 ]
@natecull an object is a materialized view of a live stream
Yep. That's where I want to get to, using as few core abstractions as possible. On the possibly foolhardy assumption that 1) you can get to global simplicity by using a smaller set of core abstractions, and 2) that simplicity makes things better. Either of which assumptions may be wrong.
ie we currently have OOP systems which don't even surface their stream of method calls *as* a user-code-facing object, which seems about as helpful as trying to build an Internet with all the packets being completely hidden from software inspection.
Which is probably one reason why 'microservices' have become such a thing. Because maybe by abstracting out 'message sending' to a protocol, you can build in the parts of message sending that didn't make it into C++.
@natecull yeah that's it. Plus having to serialise and deserialise forces one to design an interface with simple and transparent dependencies.
it could be built that way as a monolith, but the convenience of making everything singletons and global variables, and undocumented dependence of the specific shape of some proprietary library is just too tempting.
@natecull that is, I once haeard a talk about software architecture, that architecture isn't about what the collection of boxes, it's how you structure the lines between the boxes.
which mirrors Alan Kay's statements aout OOP/messages.
Another article makes a compelling case that an important measure of software complexity is if the graph of the whole system's interdepencies is embeddable in 2D, and colourable- as in the four colour map colouring puzzle-
That makes sense! And I guess that means each part needs to have a minimum of connections to others, and they need to be 'localised' somehow. Like two or three neighbours, max?
@natecull a single state on a map could look like the middle of a daisy, with 20 modules all depending on the one module. what’s harder to construct is the kind of dependency graphs that result in mutual incompatibilities, circular dpeendencies, queue jumping.
@natecull
a b c d e f g could all depend on z, but but then you can’t get more than 2 of those to depend on each other
@natecull if software is representable as a flat 2D "map", no lines crossing over, it's much easier to fit into a single human head.