Simula (https://en.wikipedia.org/wiki/Simula) is credited as inventing OOP (even if Kay invented the term to describe it). The motivation for developing it was in fact "to create a language that made it possible for people to comprehend, describe, and communicate about
systems and to to analyse existing and proposed systems through computer based models" as I heard a couple of months back. Modelling used to be considered a rather important part of the OO approach but also something that seems to have been forgotten. My old PL professor is actually working on a book about this aspect (see https://oopm.org).
I saw Kristen Nygaard, Simula's co-inventor, speak at a symposium the year before he died. As best I can remember, he asserted that OO has an undeserved reputation for being difficult to teach because students are shown problems that are too simple. He presented the task of modelling the operations of a bistro, where there are multiple concurrent activities, as a problem that naturally lends itself to OO design.
I often think about the kind of modeling you would do to build a simulation vs the kind of modeling we're doing to build an information system. Are they the same? Or are they different enough that we should consider it unfortunate that we use the same word?
I think a lot of the OO modeling advice out there is more about the simulation kind--like the interactions of the real world are what you're trying to capture. But it's rarely the case. For instance, if you want to simulate a grocery store, you'd have shopping carts and item locations and shelves. But to build information system software to support a grocery, you have a limited set of use cases: Ring up a customer, do inventory, etc. You don't need to simulate the movement of goods through the store. Just facilitate purchases and managerial tasks.
I am not sure I fully follow you, did you not yourself advocate modeling in the post? Obviously, for any application, you need to model what is needed; if flow of goods through the store is unimportant, why would you model that? Is that not the essence of abstraction, to find the core that is important?
From the same talk, there was also the following quote, from Tony Hoare (Record Handling, ALGOL Bulletin, (21), 1965):
"When we wish to solve a problem on a computer, we often need to construct within the computer - a model of that aspect of the real or conceptual world to which the solution of the problem will be applied. In such a model, each object of interest must be represented by some computer quantity which is accessible to the program, and which can be manipulated by it"
> I am not sure I fully follow you, did you not yourself advocate modeling in the post?
Yes, I did.
> Obviously, for any application, you need to model what is needed; if flow of goods through the store is unimportant, why would you model that? Is that not the essence of abstraction, to find the core that is important?
Yes, you're totally right. But many OO design methods teach that we should start by making a simulation model. If a customer buys a broccoli and some carrots, we need a Customer class and a Broccoli class, a Carrot class and a CarrotCollection class (to represent the plurality of carrots). Since a Broccoli isA ProduceItem and Carrot isA ProduceItem, let's introduce a hierarchy to capture that. There will be other types of items, so ProduceItem isA Item. Then we have to choose whether we put the buy() method on Item or on Customer. They do all of this before even considering the problem they're trying to solve. This is a kind of simulation model, where they're building a system that could keep track of the state of every entity in the store.
Simulation models are useful for understanding the system. And this is what Simula was built for--understanding complex adaptive systems and their feedback loops.
And it sounds crazy when I put it that way, but I was taught this kind of modeling at school. And I've talked to many people who still begin their code this way.
The other kind of modeling is about how to build an information system that captures, processes, and stores the information relevant for the role the software plays in the store. In a grocery (highly simplified), the software is the cash register, which tallies the bill as the cashier scans bar codes. In that case, you don't need to represent a Customer at all, nor does Broccoli need any code different from a Toothbrush.
My question is whether these two kinds of models are similar enough to use the same word. Or maybe they're similar enough to cause confusion.
As an experienced functional programmer I'm glad your book exists! I'm interested in it, and I've been sharing the link around to friends and colleagues. Is there a non-Amazon way to purchase it? I don't want to support that company.
I feel we are missing modeling tools. Programming has evolved since UML. It did not follow. There are some other tools such as C4 and archimate but I find they lack dynamism sometimes ; they are static modeling tools. So everyone invents his own technique.
Simula (https://en.wikipedia.org/wiki/Simula) is credited as inventing OOP (even if Kay invented the term to describe it). The motivation for developing it was in fact "to create a language that made it possible for people to comprehend, describe, and communicate about
systems and to to analyse existing and proposed systems through computer based models" as I heard a couple of months back. Modelling used to be considered a rather important part of the OO approach but also something that seems to have been forgotten. My old PL professor is actually working on a book about this aspect (see https://oopm.org).
I saw Kristen Nygaard, Simula's co-inventor, speak at a symposium the year before he died. As best I can remember, he asserted that OO has an undeserved reputation for being difficult to teach because students are shown problems that are too simple. He presented the task of modelling the operations of a bistro, where there are multiple concurrent activities, as a problem that naturally lends itself to OO design.
Thanks for both of these comments.
I often think about the kind of modeling you would do to build a simulation vs the kind of modeling we're doing to build an information system. Are they the same? Or are they different enough that we should consider it unfortunate that we use the same word?
I think a lot of the OO modeling advice out there is more about the simulation kind--like the interactions of the real world are what you're trying to capture. But it's rarely the case. For instance, if you want to simulate a grocery store, you'd have shopping carts and item locations and shelves. But to build information system software to support a grocery, you have a limited set of use cases: Ring up a customer, do inventory, etc. You don't need to simulate the movement of goods through the store. Just facilitate purchases and managerial tasks.
Thanks again for the discussion! I love it.
I am not sure I fully follow you, did you not yourself advocate modeling in the post? Obviously, for any application, you need to model what is needed; if flow of goods through the store is unimportant, why would you model that? Is that not the essence of abstraction, to find the core that is important?
From the same talk, there was also the following quote, from Tony Hoare (Record Handling, ALGOL Bulletin, (21), 1965):
"When we wish to solve a problem on a computer, we often need to construct within the computer - a model of that aspect of the real or conceptual world to which the solution of the problem will be applied. In such a model, each object of interest must be represented by some computer quantity which is accessible to the program, and which can be manipulated by it"
> I am not sure I fully follow you, did you not yourself advocate modeling in the post?
Yes, I did.
> Obviously, for any application, you need to model what is needed; if flow of goods through the store is unimportant, why would you model that? Is that not the essence of abstraction, to find the core that is important?
Yes, you're totally right. But many OO design methods teach that we should start by making a simulation model. If a customer buys a broccoli and some carrots, we need a Customer class and a Broccoli class, a Carrot class and a CarrotCollection class (to represent the plurality of carrots). Since a Broccoli isA ProduceItem and Carrot isA ProduceItem, let's introduce a hierarchy to capture that. There will be other types of items, so ProduceItem isA Item. Then we have to choose whether we put the buy() method on Item or on Customer. They do all of this before even considering the problem they're trying to solve. This is a kind of simulation model, where they're building a system that could keep track of the state of every entity in the store.
Simulation models are useful for understanding the system. And this is what Simula was built for--understanding complex adaptive systems and their feedback loops.
And it sounds crazy when I put it that way, but I was taught this kind of modeling at school. And I've talked to many people who still begin their code this way.
The other kind of modeling is about how to build an information system that captures, processes, and stores the information relevant for the role the software plays in the store. In a grocery (highly simplified), the software is the cash register, which tallies the bill as the cashier scans bar codes. In that case, you don't need to represent a Customer at all, nor does Broccoli need any code different from a Toothbrush.
My question is whether these two kinds of models are similar enough to use the same word. Or maybe they're similar enough to cause confusion.
Thanks!
Eric
https://ceur-ws.org/Vol-3661/10-SHORT-PWinstanley-ISKOUK2023.pdf covers similar explanations for the use of upper ontologies
Amazing article, Eric!
I've written a couple of things about lossy isomorphism here:
https://maxicontieri.substack.com/p/the-one-and-only-software-design-principle-5328420712af
But of course, we stand in the shoulder of giants since these ideas were there for a lot of decades
Hi Eric.
As an experienced functional programmer I'm glad your book exists! I'm interested in it, and I've been sharing the link around to friends and colleagues. Is there a non-Amazon way to purchase it? I don't want to support that company.
Thanks
Try this one: https://ericnormand.me/gsm
I feel we are missing modeling tools. Programming has evolved since UML. It did not follow. There are some other tools such as C4 and archimate but I find they lack dynamism sometimes ; they are static modeling tools. So everyone invents his own technique.