The disadvantage is that it has been shown to be unsuited to a large proportion of applications. Specifically those in business, commerce and industry that model a large complex “external” [*1] problem domain. Consider that much of computing outside of academia, computing infrastructure, and the data sciences, previously attempted to model transformation flows and data independently. Over a decade and a half was spent on dataflow diagrams and the entity-relationship models they transformed, during the effectively discontinued era of “structured analysis” methodologies.
As an industry, it seems we are condemned to relearn the lessons of the past with each new generation, and this is an example of my “Best Ever (Ever) Silver Bullet Software Methodology and Technology Treadmill™️”:
(1) Promotion of some previously known (variation of a) method often renamed. (2) Excited adoption as a silver bullet solution for all. (3) Discovery of (often previously learned but now forgotten) limitations over time. (4) Disillusionment. (5) Repeat.
[*1] A problem domain outside of the expertise of the development team
Not that I don’t believe you, but are you able to provide concrete examples? I’m not old enough to have lived through the era of entity-component diagrams etc..
The disadvantage is that it has been shown to be unsuited to a large proportion of applications.
[citation needed]
Clojure is used in lots of domains for all kinds of applications today, and feedback from companies using is overwhelmingly positive.
“Best Ever (Ever) Silver Bullet Software Methodology and Technology Treadmill™️”:
Nobody is claiming any silver bullets here, and obviously each approach has its trade offs. What was said that there are problems associated with OO, and how these problems can be addressed using FP style.
Great article!
I am curious to hear thoughts regarding the application Data-Oriented Programming approach to other programming languages.
There is no question that it is possible to do so.
The real question is: would the community adopt it?
The disadvantage is that it has been shown to be unsuited to a large proportion of applications. Specifically those in business, commerce and industry that model a large complex “external” [*1] problem domain. Consider that much of computing outside of academia, computing infrastructure, and the data sciences, previously attempted to model transformation flows and data independently. Over a decade and a half was spent on dataflow diagrams and the entity-relationship models they transformed, during the effectively discontinued era of “structured analysis” methodologies.
As an industry, it seems we are condemned to relearn the lessons of the past with each new generation, and this is an example of my “Best Ever (Ever) Silver Bullet Software Methodology and Technology Treadmill™️”:
(1) Promotion of some previously known (variation of a) method often renamed. (2) Excited adoption as a silver bullet solution for all. (3) Discovery of (often previously learned but now forgotten) limitations over time. (4) Disillusionment. (5) Repeat.
[*1] A problem domain outside of the expertise of the development team
Not that I don’t believe you, but are you able to provide concrete examples? I’m not old enough to have lived through the era of entity-component diagrams etc..
[citation needed]
Clojure is used in lots of domains for all kinds of applications today, and feedback from companies using is overwhelmingly positive.
Nobody is claiming any silver bullets here, and obviously each approach has its trade offs. What was said that there are problems associated with OO, and how these problems can be addressed using FP style.