9 ms·

OOP: History, and challenges for the next fifty years (2013)

MichaelZuo 6y ago
“There may not be any programming a thousand years from now, but Iʼm willing to wager that some form of Dahlʼs ideas will still be familiar to programmers in fifty years, when Simula celebrates its centenary.” I wonder if the former is at all possible, will programming transcend to some higher level of sophistication that obviates the need for code, or language for that matter? Or is there a way for code to attain the level of pure math, something independent of any specific language?
- Guthur 6y ago
  In my opinion mainstream software will be abstracted away to the point where you are working on defining and refining requirements. And will likely look very different. Interestingly I feel software construction might become more craft man like in some areas. And in others a little more workman like. To be open I feel my vision is very far away, maybe 40-50 years
  - MichaelZuo 6y ago
    That sounds similar to virtual lego building, though perhaps with more degrees of freedom. Indeed that might be more natural than any “natural language” ever could be.
  - pjmorris 6y ago
    > In my opinion mainstream software will be abstracted away to the point where you are working on defining and refining requirements. And will likely look very different. In some sense, the same thing could have been said 50 years ago, and the prediction came true. Compare what a typical programmer writes on a typical day, then and now, to the instructions that the machine executes as a result, then and now. I'm with Dijkstra [0] (HN thread [1]), in thinking that we'll always need something more formal (simpler) than natural language to express computation, even if it's only to ask things in a way SkyNet will respond to nicely. [0] http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD667.html http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EW... [1] https://news.ycombinator.com/item?id=24529900 https://news.ycombinator.com/item?id=24529900
  - valenterry 6y ago
    I think it will be twofold. On the one hand, there will be developers who use the most high level languages available and will do what you said: manage requirements, complexity and ambiguity while being able to find workarounds for the cases where performance would not be enough (there will always be these cases). On the other hand, there will be people who specialize in building the foundations for the former developers. They will write high performant algorithms and datastructures and optimize code for devices where resources are scarce.
    - PaulStatezny 6y ago
      Isn't this already true to some extent today?
      - valenterry 6y ago
        Yeah, I think it's already starting to become visible but the specialization will probably become stronger and more explicit.
- dllthomas 6y ago
  The former is clearly possible in more pessimistic ways...
lioeters 6y ago
I quite enjoyed the paper and the many insights into object-oriented programming and its history. Perhaps ironically, the part that I'm left wondering about is that "inheritance can be explained using fixpoints of generators of higher-order functions". Now I'm curious to study what that means, how inheritance can be achieved by "explicit parameterisation" ¹. Another point that made me think is this prediction: > In 1000 years object-oriented programming will no longer exist as we know it. This is either because our civilisation will have collapsed, or because it has not; in the latter case humans will no longer be engaged in any activity resembling programming, which will instead be something that computers do for themselves. I wonder if it's true that in the far future, programming will be done by computers. I suppose humans could be dictating in natural language, or moving and shaping programs in virtual reality, but I'd still consider that programming. --- ¹ The paper cited is: A Denotational Semantics of Inheritance - http://www.cs.utexas.edu/~wcook/papers/thesis/cook89.pdf http://www.cs.utexas.edu/~wcook/papers/thesis/cook89.pdf
- meowface 6y ago
  I think predicting what things will be like in the next 200 years is near-impossible. Maybe even the next 100. For the next 1000, I think the unknown unknowns are so numerous that people alive then would look back and just laugh at 99.9% of predictions, like we do over most of what people predicted in the year 1020. Humans might have merged so thoroughly with some form of technology that it won't make sense to talk about humanity as a concept. I think natural language/VR programming would be considered extremely primitive then; maybe that's something we'll see over the next 100/200 years, but I don't think the next 1000. If humans still exist and remain as mostly independent biological entities (perhaps due to a deliberate decision to minimize merging for ethical/philosophical reasons, even if it may be feasible), I think AGIs will be doing the vast majority of all programming. Maybe there'll be a bit of near-instant "compilation" of human thoughts into a wide variety of applications, enabled by neural interfaces, but I think they'll mostly be toys or just things we make for our own entertainment/amusement. (This might even happen in this century or the early 2100s; who knows.) I think it'll be like toddlers fingerpainting compared to what the AGIs will be concocting and running. Maybe at best we'll sometimes be like middle managers, giving an AGI network extremely high-level requirements and some visual/neural examples/diagrams which they'll work with and adjust to deliver something close to what our true intentions were. Or maybe it won't even make sense to think of them that way, and instead we'll just consider them like extra brain lobes we automatically offload difficult stuff to, with bandwidth equal to or greater than our current intra-brain bandwidth - even though they won't be physically inside of our brains in any way.
Rochus 6y ago
Interesting paper, thanks. Simula was without a doubt far ahead of its time. Though classes as modules is essentially implemented in Java. Concerning Smalltalk and it's features we now have another very interesting paper by Ingalls: https://dl.acm.org/doi/abs/10.1145/3386335 https://dl.acm.org/doi/abs/10.1145/3386335.
- Rochus 6y ago
  For those interested: I'm working on a Simula 67 implementation, the parser already works: https://github.com/rochus-keller/Simula https://github.com/rochus-keller/Simula.
squid_demon 6y ago
> In 1000 years object-oriented programming will no longer exist as we know it. Hopefully more like 5 years or less. OOP is worthless for programming computers and needs to step aside.
mikewarot 6y ago
As a present day Lazarus/Free Pascal programmer... I found this dive into history interesting. I had an almost allergic reaction to the idea of not type checking everything at compile time, but I do see how in some cases it can help if that is postponed. What was REALLY interesting to me was the idea of objects as processes, and passing messages instead of function calls. The machine I'm using to type this has an 8 cores, and I can see that thousands are on the way eventually. Hanging on to programming models that only execute serially will become very time prohibitive in the near term future. The idea of immutable variables always struck me as oxymoronic... but if an object is always resolved by id or name each time it is used, it resolves some rather nasty deadlocks, while allowing failure to be recovered from. It seems obvious to me that I'm going to have to give up the ability to know exactly how variables are stored, in order to gain this flexibility. It seems like it will be worth the trade off, as compute cost declines, and communication costs remain relatively constant. There is much in this to ponder, thanks for sharing.
- dunefox 6y ago
  > The idea of immutable variables always struck me as oxymoronic It is, they're called constants.
  - willtim 6y ago
    That's a bad choice of name from one or more old languages that misused established mathematical terminology (e.g. C misuses void, constant and variable). An immutable variable (or in maths, just "variable') has a value that is unknown at build time but is constant at runtime. A constant has a known value at build time. What nearly every language calls a variable today, is probably better described as a "reference" or "assignable", but sadly that ship has sailed and we'll forever be inconsistent with the math terminology for that one. Immutable variable is therefore a useful synonym for "proper variable".
    - evacchi 6y ago
      I like "(name) binding"
pjmlp 6y ago
Very interesting paper and quite a good read for anyone whose OOP understanding boils down to whatever Java/C#/C++ do.
foxes 6y ago
What is the natural mathematical abstraction to describe object oriented programming? I always feel object oriented languages are some sort of poor approximation to some sophisticated functional programming concepts (lenses, comonads, etc), or havent realised what they are actually describing. Theres things that in practice feel very similar and some ideas that look dual (some sort or co algebra?).
- loopz 6y ago
  Whiteboard. Really, OO was meant to mimic whiteboard drawing and being able to convey meaning to stakeholders in a playful and communicative manner. So messaging and what objects do is central. Objects themselves are black boxes left to actual implementation. Design patterns breaks OO heritage. This is opposed to datamodelling, which is the better approach to actually implementing complex stateful systems.
  - sgt101 6y ago
    >Design patterns breaks OO heritage. I can't see how - the idea of using patterns was that they would provide a common language of design and a "best practice" for common situations that would allow easier consumption of the services provided by other developers. Seems pretty aligned with OO to me!
    - loopz 6y ago
      This in the context of OO used as communication model with non-developer stakeholders.
- danidiaz 6y ago
  There are indeed "coalgebraic" descriptions of OOP. - "Objects and Classes, Coalgebraically" (1995) http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.6018 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.6... - "Codata in action" (2019) https://www.microsoft.com/en-us/research/publication/codata-in-action/ https://www.microsoft.com/en-us/research/publication/codata-... Coalgebras fit very well with the "hidden internal state" that characterizes objects in OOP.
sgt101 6y ago
In terms of future ideas : Objects for multicore : I just don't buy it. The problem is that application concerns are orthogonal to implementation concerns and the point of programming languages is to abstract the implementation concern away from the application programmer. The hardware engineers / os engineers should focus on providing transparent access to system resources. Application concerns just don't map onto resource consumption in my experience. I found the articulation of mobility/cloud rather odd. I thought it was going to be about lambda (AWS) and cloud runner (GCP) and other cloud serverless offers (???) which encapsulate a collection of functionality and abstract the concerns of providing a callable interface and resources to run the functionality. Instead it outlined a scheme for failover and fault tolerance, which seems to rely on centralised naming and a global OS. I can't see that OO has much to do with serverless, and I can't see that it is really implicated in the failover story articulated here either. I would make similar comments about the section on reliability. What is really strange is that the future of OO doesn't seem to be focused (according to this paper) on the concerns of maintainability, abstraction, readability and reuse that I think made it an attractive line for development in the past, and this is perhaps why it hasn't persisted as "the way and the only way" of software development into the current decade. I think that the community has dead-ended on these challenges and is now casting about for other stories to move forward on, which is basically the death-nell for this line of programming languages I think. I think this is probably because everyone knows that the four challenges I mention are extremely hard - even to define and more so to metricate, let alone solve - and those who take them on will be out published by folks working on virtually anything else. Also, sadly for comp sci, these are fuzzy, soft and human problems to do with people and organisations - and computer scientists scorn those who do not deal with bundles of cut and dried efficiency equations and derived bounds. How to move forward - well I do have a plan. The way forward is to infiltrate all funding bodies and then strangle all the maths grants that are avoiding the rigor of pure math funding by pretending to be something to do with software development or AI. The freed up money can go to engineers solving problems that matter and the theory folks can go and justify their work to the funding programs that they should be justifying their work to. Until that happens I am afraid that I see no future for OO !
- andrekandre 6y ago
  isnt the actor model [0] by hewitt more akin to the "oo" that alan kay was talking about? im pretty sure its quite rigeriously defined in mathematical terms... am i perhaps missing something? [0] https://en.wikipedia.org/wiki/Actor_model_and_process_calculi https://en.wikipedia.org/wiki/Actor_model_and_process_calcul...
deleted 6y ago
[deleted]
agumonkey 6y ago
Anybody ever seen a systemic interpretation of OO (or even modularization) ? A way to simply cut through possible spaces and divide things grossly in order to prototype without painting yourself in a corner ? an also minimize the amount of change if the the modules have to be changed (impact analysis comes to mind).
- CyberDildonics 6y ago
  I don't think any interpretation of OOP comes close to being a full solution to software architecture. That being said I'll just copy a previous comment that breaks down why I think 'OOP' get debated in a circle without any resolution: "OOP" is really three different things that people conflate together. 1. Making data structures as tiny databases with an interface that simplifies storing and retrieving data correctly (no transformations in the class itself to other data types hopefully to minimize dependencies!) 2. The school taught java/old C++ debacle of inheritance. This is where things fall apart. Inheritance means not only dependencies but opaque dependencies. It almost always means pointer chasing and lots of allocations. It used to be necessary because it was the only way to get generic containers. The speed hit to use a chain of pointers was also much smaller. In modern times this destroys performance and is not needed due to templates. 3. Message passing - 'at a certain scale, everything becomes a network problem'. I think the flexibility in having this integrated into the core of a language like smalltalk is not a good trade off, but I do think message passing at a courser architectural level offers large benefits without limiting the speed of more granular and fundamental data structures and functions. I think OOP will always be debated in a circle because people conflate these three aspects. The first I think is extremely useful and vital. The second I think is obsolete. The third I think should be treated as a higher level architecture approach with large chunks of data passed around to large non-trivial modules/libraries/nodes/plugins etc. The higher level can be more dynamic and flexible because the overhead for a flexible structure is much smaller if it is done with large chunks of data and not integrated into a language and used for vectors / hash maps / one line math functions, etc.
  - agumonkey 6y ago
    Honestly the 3rd point is cute but message passing seems like level zero of networking approach for large scale systems. I wish to find more thorough models.

“There may not be any programming a thousand years from now, but Iʼm willing to wager that some form of Dahlʼs ideas will still be familiar to programmers in fifty years, when Simula celebrates its centenary.” I wonder if the former is at all possible, will programming transcend to some higher level of sophistication that obviates the need for code, or language for that matter? Or is there a way for code to attain the level of pure math, something independent of any specific language?

Guthur 6y ago
In my opinion mainstream software will be abstracted away to the point where you are working on defining and refining requirements. And will likely look very different. Interestingly I feel software construction might become more craft man like in some areas. And in others a little more workman like. To be open I feel my vision is very far away, maybe 40-50 years
- MichaelZuo 6y ago
  That sounds similar to virtual lego building, though perhaps with more degrees of freedom. Indeed that might be more natural than any “natural language” ever could be.
- pjmorris 6y ago
  > In my opinion mainstream software will be abstracted away to the point where you are working on defining and refining requirements. And will likely look very different. In some sense, the same thing could have been said 50 years ago, and the prediction came true. Compare what a typical programmer writes on a typical day, then and now, to the instructions that the machine executes as a result, then and now. I'm with Dijkstra [0] (HN thread [1]), in thinking that we'll always need something more formal (simpler) than natural language to express computation, even if it's only to ask things in a way SkyNet will respond to nicely. [0] http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD667.html http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EW... [1] https://news.ycombinator.com/item?id=24529900 https://news.ycombinator.com/item?id=24529900
- valenterry 6y ago
  I think it will be twofold. On the one hand, there will be developers who use the most high level languages available and will do what you said: manage requirements, complexity and ambiguity while being able to find workarounds for the cases where performance would not be enough (there will always be these cases). On the other hand, there will be people who specialize in building the foundations for the former developers. They will write high performant algorithms and datastructures and optimize code for devices where resources are scarce.
  - PaulStatezny 6y ago
    Isn't this already true to some extent today?
    - valenterry 6y ago
      Yeah, I think it's already starting to become visible but the specialization will probably become stronger and more explicit.
dllthomas 6y ago
The former is clearly possible in more pessimistic ways...

lioeters 6y ago

I quite enjoyed the paper and the many insights into object-oriented programming and its history. Perhaps ironically, the part that I'm left wondering about is that "inheritance can be explained using fixpoints of generators of higher-order functions". Now I'm curious to study what that means, how inheritance can be achieved by "explicit parameterisation" ¹. Another point that made me think is this prediction: > In 1000 years object-oriented programming will no longer exist as we know it. This is either because our civilisation will have collapsed, or because it has not; in the latter case humans will no longer be engaged in any activity resembling programming, which will instead be something that computers do for themselves. I wonder if it's true that in the far future, programming will be done by computers. I suppose humans could be dictating in natural language, or moving and shaping programs in virtual reality, but I'd still consider that programming. --- ¹ The paper cited is: A Denotational Semantics of Inheritance - http://www.cs.utexas.edu/~wcook/papers/thesis/cook89.pdf http://www.cs.utexas.edu/~wcook/papers/thesis/cook89.pdf

meowface 6y ago
I think predicting what things will be like in the next 200 years is near-impossible. Maybe even the next 100. For the next 1000, I think the unknown unknowns are so numerous that people alive then would look back and just laugh at 99.9% of predictions, like we do over most of what people predicted in the year 1020. Humans might have merged so thoroughly with some form of technology that it won't make sense to talk about humanity as a concept. I think natural language/VR programming would be considered extremely primitive then; maybe that's something we'll see over the next 100/200 years, but I don't think the next 1000. If humans still exist and remain as mostly independent biological entities (perhaps due to a deliberate decision to minimize merging for ethical/philosophical reasons, even if it may be feasible), I think AGIs will be doing the vast majority of all programming. Maybe there'll be a bit of near-instant "compilation" of human thoughts into a wide variety of applications, enabled by neural interfaces, but I think they'll mostly be toys or just things we make for our own entertainment/amusement. (This might even happen in this century or the early 2100s; who knows.) I think it'll be like toddlers fingerpainting compared to what the AGIs will be concocting and running. Maybe at best we'll sometimes be like middle managers, giving an AGI network extremely high-level requirements and some visual/neural examples/diagrams which they'll work with and adjust to deliver something close to what our true intentions were. Or maybe it won't even make sense to think of them that way, and instead we'll just consider them like extra brain lobes we automatically offload difficult stuff to, with bandwidth equal to or greater than our current intra-brain bandwidth - even though they won't be physically inside of our brains in any way.

Rochus 6y ago

Interesting paper, thanks. Simula was without a doubt far ahead of its time. Though classes as modules is essentially implemented in Java. Concerning Smalltalk and it's features we now have another very interesting paper by Ingalls: https://dl.acm.org/doi/abs/10.1145/3386335 https://dl.acm.org/doi/abs/10.1145/3386335.

Rochus 6y ago
For those interested: I'm working on a Simula 67 implementation, the parser already works: https://github.com/rochus-keller/Simula https://github.com/rochus-keller/Simula.

squid_demon 6y ago

> In 1000 years object-oriented programming will no longer exist as we know it. Hopefully more like 5 years or less. OOP is worthless for programming computers and needs to step aside.

mikewarot 6y ago

As a present day Lazarus/Free Pascal programmer... I found this dive into history interesting. I had an almost allergic reaction to the idea of not type checking everything at compile time, but I do see how in some cases it can help if that is postponed. What was REALLY interesting to me was the idea of objects as processes, and passing messages instead of function calls. The machine I'm using to type this has an 8 cores, and I can see that thousands are on the way eventually. Hanging on to programming models that only execute serially will become very time prohibitive in the near term future. The idea of immutable variables always struck me as oxymoronic... but if an object is always resolved by id or name each time it is used, it resolves some rather nasty deadlocks, while allowing failure to be recovered from. It seems obvious to me that I'm going to have to give up the ability to know exactly how variables are stored, in order to gain this flexibility. It seems like it will be worth the trade off, as compute cost declines, and communication costs remain relatively constant. There is much in this to ponder, thanks for sharing.

dunefox 6y ago
> The idea of immutable variables always struck me as oxymoronic It is, they're called constants.
- willtim 6y ago
  That's a bad choice of name from one or more old languages that misused established mathematical terminology (e.g. C misuses void, constant and variable). An immutable variable (or in maths, just "variable') has a value that is unknown at build time but is constant at runtime. A constant has a known value at build time. What nearly every language calls a variable today, is probably better described as a "reference" or "assignable", but sadly that ship has sailed and we'll forever be inconsistent with the math terminology for that one. Immutable variable is therefore a useful synonym for "proper variable".
  - evacchi 6y ago
    I like "(name) binding"

pjmlp 6y ago

Very interesting paper and quite a good read for anyone whose OOP understanding boils down to whatever Java/C#/C++ do.

foxes 6y ago

What is the natural mathematical abstraction to describe object oriented programming? I always feel object oriented languages are some sort of poor approximation to some sophisticated functional programming concepts (lenses, comonads, etc), or havent realised what they are actually describing. Theres things that in practice feel very similar and some ideas that look dual (some sort or co algebra?).

loopz 6y ago
Whiteboard. Really, OO was meant to mimic whiteboard drawing and being able to convey meaning to stakeholders in a playful and communicative manner. So messaging and what objects do is central. Objects themselves are black boxes left to actual implementation. Design patterns breaks OO heritage. This is opposed to datamodelling, which is the better approach to actually implementing complex stateful systems.
- sgt101 6y ago
  >Design patterns breaks OO heritage. I can't see how - the idea of using patterns was that they would provide a common language of design and a "best practice" for common situations that would allow easier consumption of the services provided by other developers. Seems pretty aligned with OO to me!
  - loopz 6y ago
    This in the context of OO used as communication model with non-developer stakeholders.
danidiaz 6y ago
There are indeed "coalgebraic" descriptions of OOP. - "Objects and Classes, Coalgebraically" (1995) http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.6018 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.6... - "Codata in action" (2019) https://www.microsoft.com/en-us/research/publication/codata-in-action/ https://www.microsoft.com/en-us/research/publication/codata-... Coalgebras fit very well with the "hidden internal state" that characterizes objects in OOP.

sgt101 6y ago

In terms of future ideas : Objects for multicore : I just don't buy it. The problem is that application concerns are orthogonal to implementation concerns and the point of programming languages is to abstract the implementation concern away from the application programmer. The hardware engineers / os engineers should focus on providing transparent access to system resources. Application concerns just don't map onto resource consumption in my experience. I found the articulation of mobility/cloud rather odd. I thought it was going to be about lambda (AWS) and cloud runner (GCP) and other cloud serverless offers (???) which encapsulate a collection of functionality and abstract the concerns of providing a callable interface and resources to run the functionality. Instead it outlined a scheme for failover and fault tolerance, which seems to rely on centralised naming and a global OS. I can't see that OO has much to do with serverless, and I can't see that it is really implicated in the failover story articulated here either. I would make similar comments about the section on reliability. What is really strange is that the future of OO doesn't seem to be focused (according to this paper) on the concerns of maintainability, abstraction, readability and reuse that I think made it an attractive line for development in the past, and this is perhaps why it hasn't persisted as "the way and the only way" of software development into the current decade. I think that the community has dead-ended on these challenges and is now casting about for other stories to move forward on, which is basically the death-nell for this line of programming languages I think. I think this is probably because everyone knows that the four challenges I mention are extremely hard - even to define and more so to metricate, let alone solve - and those who take them on will be out published by folks working on virtually anything else. Also, sadly for comp sci, these are fuzzy, soft and human problems to do with people and organisations - and computer scientists scorn those who do not deal with bundles of cut and dried efficiency equations and derived bounds. How to move forward - well I do have a plan. The way forward is to infiltrate all funding bodies and then strangle all the maths grants that are avoiding the rigor of pure math funding by pretending to be something to do with software development or AI. The freed up money can go to engineers solving problems that matter and the theory folks can go and justify their work to the funding programs that they should be justifying their work to. Until that happens I am afraid that I see no future for OO !

andrekandre 6y ago
isnt the actor model [0] by hewitt more akin to the "oo" that alan kay was talking about? im pretty sure its quite rigeriously defined in mathematical terms... am i perhaps missing something? [0] https://en.wikipedia.org/wiki/Actor_model_and_process_calculi https://en.wikipedia.org/wiki/Actor_model_and_process_calcul...

deleted 6y ago

[deleted]

agumonkey 6y ago

Anybody ever seen a systemic interpretation of OO (or even modularization) ? A way to simply cut through possible spaces and divide things grossly in order to prototype without painting yourself in a corner ? an also minimize the amount of change if the the modules have to be changed (impact analysis comes to mind).

CyberDildonics 6y ago
I don't think any interpretation of OOP comes close to being a full solution to software architecture. That being said I'll just copy a previous comment that breaks down why I think 'OOP' get debated in a circle without any resolution: "OOP" is really three different things that people conflate together. 1. Making data structures as tiny databases with an interface that simplifies storing and retrieving data correctly (no transformations in the class itself to other data types hopefully to minimize dependencies!) 2. The school taught java/old C++ debacle of inheritance. This is where things fall apart. Inheritance means not only dependencies but opaque dependencies. It almost always means pointer chasing and lots of allocations. It used to be necessary because it was the only way to get generic containers. The speed hit to use a chain of pointers was also much smaller. In modern times this destroys performance and is not needed due to templates. 3. Message passing - 'at a certain scale, everything becomes a network problem'. I think the flexibility in having this integrated into the core of a language like smalltalk is not a good trade off, but I do think message passing at a courser architectural level offers large benefits without limiting the speed of more granular and fundamental data structures and functions. I think OOP will always be debated in a circle because people conflate these three aspects. The first I think is extremely useful and vital. The second I think is obsolete. The third I think should be treated as a higher level architecture approach with large chunks of data passed around to large non-trivial modules/libraries/nodes/plugins etc. The higher level can be more dynamic and flexible because the overhead for a flexible structure is much smaller if it is done with large chunks of data and not integrated into a language and used for vectors / hash maps / one line math functions, etc.
- agumonkey 6y ago
  Honestly the 3rd point is cute but message passing seems like level zero of networking approach for large scale systems. I wish to find more thorough models.