I found an interesting comment suggesting Lego blocks as an example of how simplicity could make software better. The poster argues there are "no complicated things" in the universe, but that things often merely seem complicated, an illusion our perception of the phenomena, and that if we just look closely enough (reduce it to parts---reductionism) a simple, linear, non-paradoxical design emerges. "Just look closer" the argument goes and you will see the simple, discrete, isolated building blocks of the seemingly complex system.
This is the reductionist argument.
The poster says this of Lego:
In the soil, we have a physical system, but the "parts" that are interacting are not "real" but emergent, such as "fertility" that cannot be located in any one place. Thoughts in the brain cannot be located at anyone one place or time either.
One of the major problems I see with the building block approach to software, the object oriented approach, is that it tries to sever the very feedback loops that make a complex system interesting and useful. It fights against complexity until it creates more confusion or rigidity than it is sometimes worth. There is an entire field of study in computer science centered around the "object relational mismatch," which is just a fancy term for the reality that applications are constructed using inflexible objects and relational database systems store information in ways that can be retrieved paradoxically.
In a relational database, parts can be wholes and wholes can be parts, yet there is no system I know of that can capture this kind of complexity, no application or computing framework that can take advantage of the capacity for paradox and feedback in the database. No, the application must have its rigid, isolated objects, where an address book entry is always an address book entry and its parts are its own business and cannot be part of another entity.
In a database, some entities do not even exist until a question is asked. A new unnamed entity is created by the answer to a question the designers of the database never considered and could not foresee. Very likely "expert system" approaches will one day resolve this problem, applications being developed using coding techniques that are capable of handling paradoxical relationships.
So, I do not believe enforced simplicity and borrowing design principles from mechanistic systems like Lego blocks are effective. Complexity exists, we can't put our heads in the sand, plug our ears and continue pretending it doesn't exist, some day the object oriented paradigm will crash and burn and some new one that takes complexity into consideration will emerge.
This is the reductionist argument.
The poster says this of Lego:
Let's take LEGO. Do you need to test LEGO package? Ofcoz, not. Do you need to test EACH (of hundreds) piece? No.The problem with this analysis is it ignores that in real complex systems, wholes are sometimes parts and parts are sometimes wholes. Object oriented programming, tries to encapsulate each piece of information or action in a single "Lego block" isolated from all other software components, connected through standard interfaces like the pegs on a Lego piece. It is wrong to apply a mechanistic solution like that of the Lego blocks to information. Software is essentially information, and pieces of information can relate to each other in paradoxical ways, just as numbers and theorems in mathematics can. It's difficult for a Lego block to be a part and a whole, although each block is a whole that can be a part, but there is less chance for paradox and feedback in the Lego block system than say in the atmosphere or the soil.
You have:
1. Global design.
2. Common interface to connect bricks (piece) to each other.
3. Pieces specification.
In the soil, we have a physical system, but the "parts" that are interacting are not "real" but emergent, such as "fertility" that cannot be located in any one place. Thoughts in the brain cannot be located at anyone one place or time either.
One of the major problems I see with the building block approach to software, the object oriented approach, is that it tries to sever the very feedback loops that make a complex system interesting and useful. It fights against complexity until it creates more confusion or rigidity than it is sometimes worth. There is an entire field of study in computer science centered around the "object relational mismatch," which is just a fancy term for the reality that applications are constructed using inflexible objects and relational database systems store information in ways that can be retrieved paradoxically.
In a relational database, parts can be wholes and wholes can be parts, yet there is no system I know of that can capture this kind of complexity, no application or computing framework that can take advantage of the capacity for paradox and feedback in the database. No, the application must have its rigid, isolated objects, where an address book entry is always an address book entry and its parts are its own business and cannot be part of another entity.
In a database, some entities do not even exist until a question is asked. A new unnamed entity is created by the answer to a question the designers of the database never considered and could not foresee. Very likely "expert system" approaches will one day resolve this problem, applications being developed using coding techniques that are capable of handling paradoxical relationships.
So, I do not believe enforced simplicity and borrowing design principles from mechanistic systems like Lego blocks are effective. Complexity exists, we can't put our heads in the sand, plug our ears and continue pretending it doesn't exist, some day the object oriented paradigm will crash and burn and some new one that takes complexity into consideration will emerge.
Comments