Discussion on: Programming Paradigms and the Procedural Paradox

Hey Alex,

Interesting discussion!

I sympathize with this line of thought because I often find myself in arguments on the side you're taking. I.e., "can't we just do the obvious thing that we know works?" Often it comes down to programmers not being aware of prior work.

I don't know if I agree with you in general, though. Programmers reuse "bricks" all the time. We reuse "bricks" on many levels. For instance, the database software, the web framework, the compiler for our language, third-party libraries, the operating system, and more.

But I'm sure you know that. So I guess I don't know what you're referring to by "bricks" in your analogy.

I think though that it could be that we don't know what the bricks are in software yet. Look at bricks: they are a commodity that you can buy at the store, they're very reliable (old technology that has been perfected), completely interchangeable, and their properties are known. Do we have something like that in software? Further, I would argue that we do have to re-engineer bricks all the time under some conditions. That is, where bricks are not available as a commodity, you have to build the bricks yourself. This is essentially an engineering problem.

To take it one step further: bricks actually don't scale that far without advanced architecture. You could make a quite simple house out of bricks if the house is small, just by stacking the bricks. But to make a multi-storied house, or a very long wall, you have to start relying on architecture. That is, techniques for arranging those bricks that are also considered "problem solving". And this problem with scaling is what Alan Kay was trying to solve with OOP. Some way to "build an arch".

So I guess I don't agree because I think someone has to go deep and reinvent everything because we still don't know how to build software all that well.

Thanks for the discussion! Looking forward to hearing your response.
Eric