I think we're mixing some things up here. If I have added to that confusion, I apologize.
Yes, OO is great. It's all of modern computing. Love me some abstraction levels -- as long as they actually abstract things. Any layer that I spend more time screwing around with other than making things people want is a net negative.
And there's my point: I'm not talking about the mechanics of FP or OO. I'm also not talking about the relative successes or failures of either model. My only point was how various modes of thinking end up solving problems different ways.
I find this a recurring theme. At the end, it's all Category Theory. So we're not talking about magic sprinkles here. Whatever we put on top of the math to help us reason about problems -- OO, FP, pure FP, and so on -- has various effects on the way we reason about problems.
Hell I don't care if you program COBOL. What's fascinating to me is how some folks read essays like this and go "Of course! Very cool" and others start talking about how it's all theoretical.
I read half-assed essays everyday that could mostly be described as some version of "I learned OO and now I think of everything as objects" The natural consequences of this thing -- which is not wholly bad -- is the same as the natural consequences of poor abstraction layers in coding: the person using them spends more time thrashing around trying to keep consistency and nomenclature aligned than they do working on the important stuff. Can you do the same with FP? Sure! But that's a conversation for a different day -- because it's a different failure mode.
Hmm. I thought it was all binary machine instructions. Or was it all NAND gates? Or everything is an object? Or everything is a list? Everything is a file?
Reductionist revelations are fun, and they also have some utility. But we have to be careful, because we tend to latch on to one of them and think that this is the one to rule them all. For different instances of "this" depending on person and time.
> Whatever we put on top of the math to help us reason
The math is another one of those magic sprinkles you put on top of the NAND gates. If that's the one that gets you going, good for you! And it certainly has its uses. But don't get carried away.
> half-assed essays everyday ... "I learned OO and now I think of everything as objects"
Funny, I don't see any of those these days, maybe you're thinking of the 90s? Instead, I see a ton of blog posts claiming that "everything is category theory". ¯\_(ツ)_/¯. Very often, they then take an interesting problem, claim that it's really this other problem solved elegantly by FP. By stripping away all the properties of the problem that made it interesting and useful. But at least now it typechecks. Sigh.
Anyway...
> Love me some abstraction levels -- as long as they actually abstract things.
Yes. This is important. Really, really important. In my current thinking, there are currently three levels of this: just indirection, compression, and actual abstraction.
A lot of people think they've contributed abstraction when they're really just adding indirection. When you find an abstraction, it really is magic, but those are fairly rare. So you typically want to keep it as direct as possible, while trying to compress (trading off with directness as appropriate). The compression can point you towards an abstraction:
Another point is that the point of OO is not the program, it is the system created by the program. That is at the same time its greatest strength, and its greatest weakness, because it means that in order to build those systems, the program that constructs the system has to based on "side effects". But that's really a limitation of our call/return architectural pattern:
Thesis: Architecture Oriented Programming is what Object Oriented Programming wanted to be. It talks about instances and systems rather than classes and programs. It also lays a solid foundation for meta programming (connectors). -- https://twitter.com/mpweiher/status/1100283251531411457
So the systems are great (or can be, if you have a great systems builder), but the way we are forced to build them is pretty bad. FP tends to recognise the latter but not the former. See also:
Yes, OO is great. It's all of modern computing. Love me some abstraction levels -- as long as they actually abstract things. Any layer that I spend more time screwing around with other than making things people want is a net negative.
And there's my point: I'm not talking about the mechanics of FP or OO. I'm also not talking about the relative successes or failures of either model. My only point was how various modes of thinking end up solving problems different ways.
I find this a recurring theme. At the end, it's all Category Theory. So we're not talking about magic sprinkles here. Whatever we put on top of the math to help us reason about problems -- OO, FP, pure FP, and so on -- has various effects on the way we reason about problems.
Hell I don't care if you program COBOL. What's fascinating to me is how some folks read essays like this and go "Of course! Very cool" and others start talking about how it's all theoretical.
I read half-assed essays everyday that could mostly be described as some version of "I learned OO and now I think of everything as objects" The natural consequences of this thing -- which is not wholly bad -- is the same as the natural consequences of poor abstraction layers in coding: the person using them spends more time thrashing around trying to keep consistency and nomenclature aligned than they do working on the important stuff. Can you do the same with FP? Sure! But that's a conversation for a different day -- because it's a different failure mode.