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

@zens

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.

@zens

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.

@zens

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-

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

Follow

@zens

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?

· · Web · 1 · 1 · 0

@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

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!