[lytol]

Interestingly, I feel like this comparison to an IC and input(s) -> output(s) is more akin to functional approaches, and many people complain about OOP being the opposite.

To quote Joe Armstrong:

> I think the lack of reusability comes in object-oriented languages, not functional languages. Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. If you have referentially transparent code, if you have pure functions — all the data comes in its input arguments and everything goes out and leave no state behind — it’s incredibly reusable.

[robotresearcher]

Many ICs contain state. That's RAM's purpose, for example.

The analogy with OOP is that (ideally) you don't need to know how it works internally: you just use the external interface.

[aidenn0]

Heck, many mixed-signal ICs are much harder to use correctly than a typical object; Things like "Vdd must be brought up to +6V or higher before CLK begins toggling" are not too uncommon to see.

[systemvoltage]

It's a loose analogy. You're going to find exceptions. I think its a fantastic analogy to describe what a class is despite of some exceptions.

[aidenn0]

I was actually agreeing with the analogy.

[cxr]

FP comes with the same jungle, especially if you consider that when most people talk about FP, they're allowing for closures. Even if you don't, though, and you do only have pure functions, it's a similar bog.

Consider a function f that itself relies on being able to call function g. In FP, you have to either bind by name, which introduces coupling on par with OO ("the jungle"), or you make it parametric, so f doesn't know anything about g per se, but somebody does―perhaps f's caller, or its caller, etc. OO is parametric, too, but in that case they live as slots on the objects, rather than being passed as arguments.

People can try to squidge this end of the problem and find that it shquoshes up on the other side, or vice versa. There's no real escape from the problem of dealing with state.

Probably the real silver bullet boost to productivity will come when we adapt program execution environments to our dumb brains by way of VR. Think of something like a cellular automaton such as von Neumann's universal constructor:

https://en.wikipedia.org/wiki/Von_Neumann_universal_construc...

... only in 3 dimensions. When we want to debug a program, we project it into a 3-dimensional space, and we trace its execution the way you can look at something progressing through the assembly line on a shop floor, with pieces that you can reach out and touch, and even pick them up and mark some with blue dots and some without, etc. That looks a lot more like OO than FP.

[moron4hire]

My reaction to PT fundamentalists is always the same. "Jesus, what the hell have I been doing, reusing all this unreusable OOP code?"