@kara_dreamer @mona That's basically what Alan Kay says
"We had two ideas, really. One of them we got from Lisp: late binding. The other one was the idea of objects. Those gave us something a little bit like the arch, so we were able to make complex, seemingly large structures out of very little material, but I wouldn’t put us much past the engineering of 1,000 years ago."
@natecull @kara_dreamer I've never quite trusted the "object" as a programming entity, myself, but then my idea of a good programming language is Fortran.
@mona @kara_dreamer For me it's Prolog, except a theoretical Prolog that doesn't have all the terrible 1970s misfeatures the actually-existing Prolog has.
But I think we need a lot more transparency and clarity in our programming languages.
Sealed mystery meat libraries that do 'something' to data - or to the entire state of the Internet behind your back - which you don't know and can't prove, give me the willies.
'Encapsulation' has bad side effects.
@natecull @kara_dreamer Indeed. I am not the least bit convinced that the information-hiding that's often cited as a major feature of such languages as C++ and Java is really a feature worth having around.
My lingering mistrust of the object model is not terribly well-reasoned, perhaps. I somewhat dislike scattering "state" in little parcels around the code, rather than keeping it in one place.
@natecull @kara_dreamer Right! completely agreed. Having every little entity carry around a little bit of state is a nightmare when one wishes to preserve _all_ state.
@mona @kara_dreamer I agree. From a functional or declarative perspective, state *should* be centralised, and put into something like a transaction.
More and more I think of programming as 'capturing knowledge' more tgan describing proesses.. and forced encapsulation feels like a kind of deliberate ignorance.
I understand the intention behind "hiding the irrelevant details", but on a hostile net the details are no longer irrelevant.