14 ms·

Alan Kay on the Meaning of “Object-Oriented Programming” (2003)

117 points by siteshwar 12y ago

robert_tweed 12y ago
A lot of the recent trend towards OOP-bashing comes from bad implementations of OOP, just as bashing design patterns is more to do with badly thought out architectures and overuse of those patterns. In fact, the origins of OOP are basically what we would now call microservice architecture (CSP-inspired languages like Go being a specialisation of this). Each service can be as stateless or as stateful as it needs to be (without shared state) and services should be loosely coupled. That's quite different to most large-scale OOP architectures, but it is possible to code in that style in any OOP language. Heavy reliance on inheritance for code reuse is a whole problem class in itself that again has little to do with OOP and lots to do with the influence of C++.
- archagon 12y ago
  It seems to me that you can't really do message passing in most languages with high efficiency? (Objective-C and Swift being the exceptions.)
  - Joeri 12y ago
    I think it's a bit charitable to call what Objective C does to be "message passing". The messages are not asynchronous and have only a single recipient, so in practice I would say they're method calls with late binding.
    - archagon 12y ago
      You can do one-to-many messages via notifications, though it's less elegant.
    - mpweiher 12y ago
      However, they can easily be made asynchronous and address multiple recipients. See Higher Order Messaging[1][2], first implemented in Objective-C[3]. So for example: [[myView onMainThread] setNeedsDisplay:YES]; result = [[someObject future] someMessage:arg]; combined = [[prefixes collect] stringByAppendingString:[suffixes each]]; The reason this is easy in Objective-C is because its brand of message passing is just (barely) powerful enough to qualify as message passing. In fact, if you squint just a little, you can see it as fully reified message passing with the common-case (a synchronous method is invoked) optimized. [1] http://en.wikipedia.org/wiki/Higher_order_message http://en.wikipedia.org/wiki/Higher_order_message [2] http://www.metaobject.com/papers/Higher_Order_Messaging_OOPSLA_2005.pdf http://www.metaobject.com/papers/Higher_Order_Messaging_OOPS... [3] https://github.com/mpw/MPWFoundation https://github.com/mpw/MPWFoundation
    - xsmasher 12y ago
      At least you can redirect messages to another recipient, and write a handler for "unhandled messages." Impossible with c++, at least with standard method calls.
  - rurban 12y ago
    Rather the opposite. Almost all HPC (high-performance computing) systems use message passing and not shared memory. The fastest and imho best unix-like kernel L4 is entirely MP based. So if you want to embrace high performance (and concurrent), go message passing. Alan Kay's favor of late binding does not help performance, as method lookup at run-time dominates the cost then, but the fast systems are early bound, i.e. typed.
    - seanmcdirmid 12y ago
      Well, you are discounting CUDA, which has been seen as suited for many tasks when compared to MPI. Of course, you can use MPI and CUDA together (people are working on that), which you then have messaging between nodes and shared memory (via GPU-style SIMD) within. Of course, you are probably referring to NUMA, but people still actually use that. Pure OO isn't very much desired in the HPC world, but then neither is pure FP.
- alan82 12y ago
  In sports, training coaches sometimes forbid to use some play element. In OOP classes there should be an assignment to design a system without inheritance. Just to show what is most important in OOP.
  - Jare 12y ago
    I was taught OOP using Modula-2 in 1989, by defining structures and functions that took a pointer to the struct as first parameter. No inheritance goodies! I used that style in C until 1996 when I definitely moved to C++. Probably why I am not terribly dismissive of OOP but very much of things like inheritance trees, the Java OOP style, and the overuse of GoF in architecture, literature and especially programming discussions.
  - vince_refiti 12y ago
    In Ada, I remember reading that you can limit the inheritance depth.
  - thewarrior 12y ago
    How would you design something like : Person --> Full Time Employee --> Manager Person --> Contract Employee Without inheritance assuming that salary calculation is the only thing which differentiates them.
    - derefr 12y ago
      Something like... Person HAS A IEmploymentRelationship ContractEmployment IMPLEMENTS IEmploymentRelationship FullTimeEmployment IMPLEMENTS IEmploymentRelationship FullTimeEmployment HAS A IDirectReport Manager HAS A Person Manager IMPLEMENTS IDirectReport And then salary() is a polymorphic function declared by the IEmploymentRelationship interface, where FullTimeEmployment instances use the manager somehow, and ContractEmployment doesn't. You can even put some sugar on that by having a salary() function on Person that calls the salary() function on its IEmploymentRelationship—but I wouldn't, for the same reason I wouldn't denormalize a relational database.
      - 12y ago
- tailrecursion 12y ago
  If we redefine the word "OOP:object" to mean process-with-mailbox, and redefine the word "OOP:message" to mean asynchronous message passing, then objects and messages make sense and are useful. Those are not Smalltalk's definitions -- even though I think you're right on about Alan Kay's original inspiration -- and confusion can arise if we redefine terms.
- rumcajz 12y ago
  Alan Kay may have coined the term, but OOP (as any other word or term) is what people believe it to be. Which is pretty far from CSP.
- trhway 12y ago
  >A lot of the recent trend towards OOP-bashing comes from bad implementations of OOP, just as bashing design patterns is more to do with badly thought out architectures and overuse of those patterns. sorry, but this is no true Scotsman fallacy. All these "bad implementations" is OOP, real OOP, not some idealized ephemeral non-existent Avalon. If an idea easily and more frequently than not lands itself to the bad implementations then there is something wrong with the idea. (I happen to come from a country which was pursuing what was looking like a pretty good idea - communism - which has got a lot of bashing during recent decades, due to "bad implementations" i guess, and as result it was critically rethought and now we know what it is not a good idea really)
pfraze 12y ago
Towards the end: But just to show how stubbornly an idea can hang on, all through the seventies and eighties, there were many people who tried to get by with "Remote Procedure Call" instead of thinking about objects and messages. Sic transit gloria mundi. Can somebody explain to me what distinction he's drawing here? What's the issue with RPC that's solved by Objects+Messages?
- lucio 12y ago
  I understand this passage as a comment on philosophical approach. You can see the same interaction as a "Remote Procedure Call" or as "sending a message to an object".
  - agumonkey 12y ago
    Kay also said later that (anything lost in translation is my fault) he thinks he misjudged the scale of an object, instead of being tiny packs of methods, they should be interfaces for larger "computing devices". Like tiny virtual machines that can live into and move from actual hardware, and computing through communication over any kind of channels (local, remote).
- Joeri 12y ago
  A remote procedure call blocks on the response, ensuring the system is only as strong as its weakest link. If every object communicates asynchronously with every other object, using messages instead of shared memory (hence avoiding locking issues), the design by necessity evolves in ways which becomes more robust and easy to scale. Synchronous RPC calls encourage unscalable and unreliable architectures.
  - pfraze 12y ago
    This is a good answer, but it doesn't cover everything Kay is suggesting. If it did, then the topic would be sync vs async messaging.
  - jcrites 12y ago
    All remote calls must have a timeout. The lack of timeouts in certain RPC implementations was an implementation weakness, not a conceptual one. [Edit: I've removed most of my original comment since it pertained to messaging between machines, rather than within an application.]
jayvanguard 12y ago
"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things." Bam. That is it right there. Java really messed this up. Strong static typing and OO is an abomination.
- wellpast 12y ago
  So what specifically about OO gets so much better as soon as you take types away? Can you give a specific improvement?
  - Jare 12y ago
    Ability to change or replace object instances (maybe with instances of different types) on the fly could be an example. In general, you can design incredibly dynamic and reconfigurable systems. Whether you want to or not, and at what level should you stop doing it, is certainly a good debate to have.
    - backlava 12y ago
      If the system you are building makes sense, there is probably a reasonable type system that shows it to be well typed.
      - Jare 12y ago
        Yeah, "makes sense" and "reasonable" would be criteria involved in the debated I mentioned.
agumonkey 12y ago
@previously (1272 days ago) https://news.ycombinator.com/item?id=2628897 https://news.ycombinator.com/item?id=2628897
davidw 12y ago
I wonder what he thinks of Erlang, as it's very much about message passing, hiding of process state, and late binding. Of course, this is built at a higher level and it's not turtles all the way down: you don't send messages to numbers to do basic math.
- edgurgel 12y ago
  He will be here: http://www.erlang-factory.com/sfbay2015 http://www.erlang-factory.com/sfbay2015 . Hopefully he will share his thoughts.
jonahx 12y ago
>My math background made me realize that each object could have several algebras associated with it, and there could be families of these algebras Could someone explain what he meant here?
- tailrecursion 12y ago
  For example an automobile can be thought of as an emitter of pollution, if your problem concerns pollution, or, it can be thought of as a particle, if your problem concerns traffic congestion. The auto "fits" into each of these different problem domains.
  - jonahx 12y ago
    Thanks for the reply, but I'm still not seeing the connection to algebra?
    - jfarmer 12y ago
      He means "algebra" in the "universal algebra" sense of the word: http://en.wikipedia.org/wiki/Universal_algebra http://en.wikipedia.org/wiki/Universal_algebra That probay doesn't clarify the connection, but at least you'll be pointed in the right direction! :)
    - deleted 12y ago
      [deleted]
    - deleted 12y ago
      [deleted]
- noblethrasher 12y ago
  Algebra is the study of sets and their operations. "High school algebra" is usually limited to the study of real numbers and the operations of addition and multiplication. In upper division undergraduate mathematics, you learn about other kind of algebras. For example, there is the set of regular polygons with operations such as rotation and reflection. In OO, a class of objects defines the operations (methods) that are valid, and thus, a class is an algebra, and a set of classes is a family of algebras. I suppose that you would need a form of multiple-inheritance in order to have a family of algebras for an object.
read 12y ago
Why Alan Kay came up with object-oriented: I wanted to get rid of data. I didn't understand the monster LISP idea of tangible metalanguage then
- abecedarius 12y ago
  He said he did understand before he created Smalltalk.
  - read 12y ago
    Can you point to the sentence where he said that?
    - abecedarius 12y ago
      First sentence of the next paragraph.
      - read 12y ago
        Thanks. I still find it fascinating people do good work without fully understanding an area. It's as if you're not supposed to. I wonder if this could be used as a guiding principle in making things. If what you are working on originally looks understandable, you should be alarmed.
        abecedarius 12y ago
        Yes, Feynman kept telling people to find problems that appeal to them and try to work them out, and not rely so heavily on reading. (One source: Feynman Lectures on Computation.)
        fsloth 12y ago
        I presume by 'understanding an area' you mean being familiar with established abstract models of that area? I think that often in practical conditions the abstract models are not the area under work. They are the mapping of the area to some formal system. And that the 'area' under question - whatever it may be - can be mapped to an infinite amount of formal systems. For lots of practical purposes, there is some 'obvious' algebra of a thing one wants to do - in these instances all that is needed is an individual who can map the problem to any logically coherent structure, even just a private one in their head, and a willingness to solve the problem - and great stuff can ne done without a literature review. Sometimes the establishes models are really, really good since they either simplify a messy looking problem and/or point out to some not so obvious aspects of a system at which point an expert in the field can have an advantage over the clever layman. I think sometimes the knowledge of existing formal models can make a person blind to certain facets of the system they are working with. Also, if one approaches a thing by a burning desire just to implement one single thing on top of it they will probably have an internal model that is very much focused on the problem they are solving.This practical need can induce them to create a new formal model or just sidestep lots of non-issues that would be a burden to deal with.
cesarbs 12y ago
> I wanted to get rid of data. What exactly does he mean by that? How does one get rid of data? > The B5000 almost did this via its almost unbelievable HW architecture. I've heard about the B5000 numerous times here on HN. What was so fantastic about it?
- tim333 12y ago
  http://en.wikipedia.org/wiki/Burroughs_large_systems#B5000 http://en.wikipedia.org/wiki/Burroughs_large_systems#B5000
vishnugupta 12y ago
"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them." Such a pity that this filtered essence about OOP was lost on me during formative years of learning OO-programming; for no fault of mine! It took me half a decade into professional programming in Java to realize the importance of these key concepts. And the worse part is that most of the books/blogs start OO programming tutorial with examples that try to literally model the problem state using Objects (e.g., "Animals", "Shapes" etc.,). I guess tutorials, classes just focus on these key goals and show how concepts such as "polymorphism", "inheritance" etc., are work towards achieving (or not) them. What generally happens is that one is taught about all these peripheral concepts and students are left to wonder the problems they are trying to solve.
- swalsh 12y ago
  Those examples worked really badly for me too. It wasn't until about a year after I got my first paycheck for writing code that I made this switch in my mind. My thought process started out something along the lines of "ok, i just need to get all these things in line... somehow... and then I can accomplish the goal". However at some point I realized, I did some similar things quite often, and I needed to make some piece of code kind of generic. My mindset kind of changed dramatically. Instead of thinking about how I could make something work, I started to think of how I'd like the API to look. How could I make the code reusable. I thought about the perspective of another dev using the code rather than the goal itself, since that eventually became the easy part. Once you start thinking in terms of the API, and how you can design it so someone with minimal documentation could still use it (though you still document it!) you start wanting to hide the implementation etc, and all the other OOP ideas fall into place. of course, I don't think it's something that can be taught. It's an evolution. When you first start programming, everything is unknown, so you don't have the brain power to focus on design. When you learn more, and you free up brain power you can start concentrating on these other things.

117 points by siteshwar 12y ago

A lot of the recent trend towards OOP-bashing comes from bad implementations of OOP, just as bashing design patterns is more to do with badly thought out architectures and overuse of those patterns. In fact, the origins of OOP are basically what we would now call microservice architecture (CSP-inspired languages like Go being a specialisation of this). Each service can be as stateless or as stateful as it needs to be (without shared state) and services should be loosely coupled. That's quite different to most large-scale OOP architectures, but it is possible to code in that style in any OOP language. Heavy reliance on inheritance for code reuse is a whole problem class in itself that again has little to do with OOP and lots to do with the influence of C++.

archagon 12y ago
It seems to me that you can't really do message passing in most languages with high efficiency? (Objective-C and Swift being the exceptions.)
- Joeri 12y ago
  I think it's a bit charitable to call what Objective C does to be "message passing". The messages are not asynchronous and have only a single recipient, so in practice I would say they're method calls with late binding.
  - archagon 12y ago
    You can do one-to-many messages via notifications, though it's less elegant.
  - mpweiher 12y ago
    However, they can easily be made asynchronous and address multiple recipients. See Higher Order Messaging[1][2], first implemented in Objective-C[3]. So for example: [[myView onMainThread] setNeedsDisplay:YES]; result = [[someObject future] someMessage:arg]; combined = [[prefixes collect] stringByAppendingString:[suffixes each]]; The reason this is easy in Objective-C is because its brand of message passing is just (barely) powerful enough to qualify as message passing. In fact, if you squint just a little, you can see it as fully reified message passing with the common-case (a synchronous method is invoked) optimized. [1] http://en.wikipedia.org/wiki/Higher_order_message http://en.wikipedia.org/wiki/Higher_order_message [2] http://www.metaobject.com/papers/Higher_Order_Messaging_OOPSLA_2005.pdf http://www.metaobject.com/papers/Higher_Order_Messaging_OOPS... [3] https://github.com/mpw/MPWFoundation https://github.com/mpw/MPWFoundation
  - xsmasher 12y ago
    At least you can redirect messages to another recipient, and write a handler for "unhandled messages." Impossible with c++, at least with standard method calls.
- rurban 12y ago
  Rather the opposite. Almost all HPC (high-performance computing) systems use message passing and not shared memory. The fastest and imho best unix-like kernel L4 is entirely MP based. So if you want to embrace high performance (and concurrent), go message passing. Alan Kay's favor of late binding does not help performance, as method lookup at run-time dominates the cost then, but the fast systems are early bound, i.e. typed.
  - seanmcdirmid 12y ago
    Well, you are discounting CUDA, which has been seen as suited for many tasks when compared to MPI. Of course, you can use MPI and CUDA together (people are working on that), which you then have messaging between nodes and shared memory (via GPU-style SIMD) within. Of course, you are probably referring to NUMA, but people still actually use that. Pure OO isn't very much desired in the HPC world, but then neither is pure FP.
alan82 12y ago
In sports, training coaches sometimes forbid to use some play element. In OOP classes there should be an assignment to design a system without inheritance. Just to show what is most important in OOP.
- Jare 12y ago
  I was taught OOP using Modula-2 in 1989, by defining structures and functions that took a pointer to the struct as first parameter. No inheritance goodies! I used that style in C until 1996 when I definitely moved to C++. Probably why I am not terribly dismissive of OOP but very much of things like inheritance trees, the Java OOP style, and the overuse of GoF in architecture, literature and especially programming discussions.
- vince_refiti 12y ago
  In Ada, I remember reading that you can limit the inheritance depth.
- thewarrior 12y ago
  How would you design something like : Person --> Full Time Employee --> Manager Person --> Contract Employee Without inheritance assuming that salary calculation is the only thing which differentiates them.
  - derefr 12y ago
    Something like... Person HAS A IEmploymentRelationship ContractEmployment IMPLEMENTS IEmploymentRelationship FullTimeEmployment IMPLEMENTS IEmploymentRelationship FullTimeEmployment HAS A IDirectReport Manager HAS A Person Manager IMPLEMENTS IDirectReport And then salary() is a polymorphic function declared by the IEmploymentRelationship interface, where FullTimeEmployment instances use the manager somehow, and ContractEmployment doesn't. You can even put some sugar on that by having a salary() function on Person that calls the salary() function on its IEmploymentRelationship—but I wouldn't, for the same reason I wouldn't denormalize a relational database.
    - 12y ago
tailrecursion 12y ago
If we redefine the word "OOP:object" to mean process-with-mailbox, and redefine the word "OOP:message" to mean asynchronous message passing, then objects and messages make sense and are useful. Those are not Smalltalk's definitions -- even though I think you're right on about Alan Kay's original inspiration -- and confusion can arise if we redefine terms.
rumcajz 12y ago
Alan Kay may have coined the term, but OOP (as any other word or term) is what people believe it to be. Which is pretty far from CSP.
trhway 12y ago
>A lot of the recent trend towards OOP-bashing comes from bad implementations of OOP, just as bashing design patterns is more to do with badly thought out architectures and overuse of those patterns. sorry, but this is no true Scotsman fallacy. All these "bad implementations" is OOP, real OOP, not some idealized ephemeral non-existent Avalon. If an idea easily and more frequently than not lands itself to the bad implementations then there is something wrong with the idea. (I happen to come from a country which was pursuing what was looking like a pretty good idea - communism - which has got a lot of bashing during recent decades, due to "bad implementations" i guess, and as result it was critically rethought and now we know what it is not a good idea really)

pfraze 12y ago

Towards the end: But just to show how stubbornly an idea can hang on, all through the seventies and eighties, there were many people who tried to get by with "Remote Procedure Call" instead of thinking about objects and messages. Sic transit gloria mundi. Can somebody explain to me what distinction he's drawing here? What's the issue with RPC that's solved by Objects+Messages?

lucio 12y ago
I understand this passage as a comment on philosophical approach. You can see the same interaction as a "Remote Procedure Call" or as "sending a message to an object".
- agumonkey 12y ago
  Kay also said later that (anything lost in translation is my fault) he thinks he misjudged the scale of an object, instead of being tiny packs of methods, they should be interfaces for larger "computing devices". Like tiny virtual machines that can live into and move from actual hardware, and computing through communication over any kind of channels (local, remote).
Joeri 12y ago
A remote procedure call blocks on the response, ensuring the system is only as strong as its weakest link. If every object communicates asynchronously with every other object, using messages instead of shared memory (hence avoiding locking issues), the design by necessity evolves in ways which becomes more robust and easy to scale. Synchronous RPC calls encourage unscalable and unreliable architectures.
- pfraze 12y ago
  This is a good answer, but it doesn't cover everything Kay is suggesting. If it did, then the topic would be sync vs async messaging.
- jcrites 12y ago
  All remote calls must have a timeout. The lack of timeouts in certain RPC implementations was an implementation weakness, not a conceptual one. [Edit: I've removed most of my original comment since it pertained to messaging between machines, rather than within an application.]

jayvanguard 12y ago

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things." Bam. That is it right there. Java really messed this up. Strong static typing and OO is an abomination.

wellpast 12y ago
So what specifically about OO gets so much better as soon as you take types away? Can you give a specific improvement?
- Jare 12y ago
  Ability to change or replace object instances (maybe with instances of different types) on the fly could be an example. In general, you can design incredibly dynamic and reconfigurable systems. Whether you want to or not, and at what level should you stop doing it, is certainly a good debate to have.
  - backlava 12y ago
    If the system you are building makes sense, there is probably a reasonable type system that shows it to be well typed.
    - Jare 12y ago
      Yeah, "makes sense" and "reasonable" would be criteria involved in the debated I mentioned.

agumonkey 12y ago

@previously (1272 days ago) https://news.ycombinator.com/item?id=2628897 https://news.ycombinator.com/item?id=2628897

davidw 12y ago

I wonder what he thinks of Erlang, as it's very much about message passing, hiding of process state, and late binding. Of course, this is built at a higher level and it's not turtles all the way down: you don't send messages to numbers to do basic math.

edgurgel 12y ago
He will be here: http://www.erlang-factory.com/sfbay2015 http://www.erlang-factory.com/sfbay2015 . Hopefully he will share his thoughts.

jonahx 12y ago

>My math background made me realize that each object could have several algebras associated with it, and there could be families of these algebras Could someone explain what he meant here?

tailrecursion 12y ago
For example an automobile can be thought of as an emitter of pollution, if your problem concerns pollution, or, it can be thought of as a particle, if your problem concerns traffic congestion. The auto "fits" into each of these different problem domains.
- jonahx 12y ago
  Thanks for the reply, but I'm still not seeing the connection to algebra?
  - jfarmer 12y ago
    He means "algebra" in the "universal algebra" sense of the word: http://en.wikipedia.org/wiki/Universal_algebra http://en.wikipedia.org/wiki/Universal_algebra That probay doesn't clarify the connection, but at least you'll be pointed in the right direction! :)
  - deleted 12y ago
    [deleted]
  - deleted 12y ago
    [deleted]
noblethrasher 12y ago
Algebra is the study of sets and their operations. "High school algebra" is usually limited to the study of real numbers and the operations of addition and multiplication. In upper division undergraduate mathematics, you learn about other kind of algebras. For example, there is the set of regular polygons with operations such as rotation and reflection. In OO, a class of objects defines the operations (methods) that are valid, and thus, a class is an algebra, and a set of classes is a family of algebras. I suppose that you would need a form of multiple-inheritance in order to have a family of algebras for an object.

read 12y ago

Why Alan Kay came up with object-oriented: I wanted to get rid of data. I didn't understand the monster LISP idea of tangible metalanguage then

abecedarius 12y ago
He said he did understand before he created Smalltalk.
- read 12y ago
  Can you point to the sentence where he said that?
  - abecedarius 12y ago
    First sentence of the next paragraph.
    - read 12y ago
      Thanks. I still find it fascinating people do good work without fully understanding an area. It's as if you're not supposed to. I wonder if this could be used as a guiding principle in making things. If what you are working on originally looks understandable, you should be alarmed.
      - abecedarius 12y ago
        Yes, Feynman kept telling people to find problems that appeal to them and try to work them out, and not rely so heavily on reading. (One source: Feynman Lectures on Computation.)
      - fsloth 12y ago
        I presume by 'understanding an area' you mean being familiar with established abstract models of that area? I think that often in practical conditions the abstract models are not the area under work. They are the mapping of the area to some formal system. And that the 'area' under question - whatever it may be - can be mapped to an infinite amount of formal systems. For lots of practical purposes, there is some 'obvious' algebra of a thing one wants to do - in these instances all that is needed is an individual who can map the problem to any logically coherent structure, even just a private one in their head, and a willingness to solve the problem - and great stuff can ne done without a literature review. Sometimes the establishes models are really, really good since they either simplify a messy looking problem and/or point out to some not so obvious aspects of a system at which point an expert in the field can have an advantage over the clever layman. I think sometimes the knowledge of existing formal models can make a person blind to certain facets of the system they are working with. Also, if one approaches a thing by a burning desire just to implement one single thing on top of it they will probably have an internal model that is very much focused on the problem they are solving.This practical need can induce them to create a new formal model or just sidestep lots of non-issues that would be a burden to deal with.

cesarbs 12y ago

> I wanted to get rid of data. What exactly does he mean by that? How does one get rid of data? > The B5000 almost did this via its almost unbelievable HW architecture. I've heard about the B5000 numerous times here on HN. What was so fantastic about it?

tim333 12y ago
http://en.wikipedia.org/wiki/Burroughs_large_systems#B5000 http://en.wikipedia.org/wiki/Burroughs_large_systems#B5000

vishnugupta 12y ago

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them." Such a pity that this filtered essence about OOP was lost on me during formative years of learning OO-programming; for no fault of mine! It took me half a decade into professional programming in Java to realize the importance of these key concepts. And the worse part is that most of the books/blogs start OO programming tutorial with examples that try to literally model the problem state using Objects (e.g., "Animals", "Shapes" etc.,). I guess tutorials, classes just focus on these key goals and show how concepts such as "polymorphism", "inheritance" etc., are work towards achieving (or not) them. What generally happens is that one is taught about all these peripheral concepts and students are left to wonder the problems they are trying to solve.

swalsh 12y ago
Those examples worked really badly for me too. It wasn't until about a year after I got my first paycheck for writing code that I made this switch in my mind. My thought process started out something along the lines of "ok, i just need to get all these things in line... somehow... and then I can accomplish the goal". However at some point I realized, I did some similar things quite often, and I needed to make some piece of code kind of generic. My mindset kind of changed dramatically. Instead of thinking about how I could make something work, I started to think of how I'd like the API to look. How could I make the code reusable. I thought about the perspective of another dev using the code rather than the goal itself, since that eventually became the easy part. Once you start thinking in terms of the API, and how you can design it so someone with minimal documentation could still use it (though you still document it!) you start wanting to hide the implementation etc, and all the other OOP ideas fall into place. of course, I don't think it's something that can be taught. It's an evolution. When you first start programming, everything is unknown, so you don't have the brain power to focus on design. When you learn more, and you free up brain power you can start concentrating on these other things.