Hi guys,
Again one interesting topic for this weekend to discuss. David Nolen, a Lisp and JavaScript guy posted in his blog an article titled Illiterate Programming [1] where he said:
"...Yet I think Smalltalk still fundamentally failed (remember this is a programming language originally designed to scale from children to adults) because *Objects are really hard* and no-one really understands to this day how to do them right...."
He links to Alan Kay post [2] back in 1998 where he talks about problems with inheritance:
"Here are a few problems in the naive inheritance systems we use today: confusions of Taxonomy and Parentage, of Specialization and Refinement, of Parts and Wholes, of Semantics and Pragmatics..."
Let we concentrate on broader "Objects are really hard and no-one really understands to this day how to do them right" claim and not merely inheritance, please.
Best regards Janko
[1] http://dosync.posterous.com/illiterate-programming [2] http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-April/009261.htm...
Well... functional programming is hard and not everybody really understands it... structured programming is hard and not everybody really understood it... hmm at the end, programming is hard :-)
He gives no reason about his stament nor "demonstration" of it neither... so he has a feeling, me too and a completely different one :-)
On Sat, Feb 11, 2012 at 9:21 AM, Janko Mivšek janko.mivsek@eranova.siwrote:
Hi guys,
Again one interesting topic for this weekend to discuss. David Nolen, a Lisp and JavaScript guy posted in his blog an article titled Illiterate Programming [1] where he said:
"...Yet I think Smalltalk still fundamentally failed (remember this is a programming language originally designed to scale from children to adults) because *Objects are really hard* and no-one really understands to this day how to do them right...."
He links to Alan Kay post [2] back in 1998 where he talks about problems with inheritance:
"Here are a few problems in the naive inheritance systems we use today: confusions of Taxonomy and Parentage, of Specialization and Refinement, of Parts and Wholes, of Semantics and Pragmatics..."
Let we concentrate on broader "Objects are really hard and no-one really understands to this day how to do them right" claim and not merely inheritance, please.
Best regards Janko
[1] http://dosync.posterous.com/illiterate-programming [2]
http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-April/009261.htm...
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
I find the article rather kind to Smalltalk...
Illiterate programming = self literate programming...
Nicolas
2012/2/11 Janko Mivšek janko.mivsek@eranova.si:
Hi guys,
Again one interesting topic for this weekend to discuss. David Nolen, a Lisp and JavaScript guy posted in his blog an article titled Illiterate Programming [1] where he said:
"...Yet I think Smalltalk still fundamentally failed (remember this is a programming language originally designed to scale from children to adults) because *Objects are really hard* and no-one really understands to this day how to do them right...."
He links to Alan Kay post [2] back in 1998 where he talks about problems with inheritance:
"Here are a few problems in the naive inheritance systems we use today: confusions of Taxonomy and Parentage, of Specialization and Refinement, of Parts and Wholes, of Semantics and Pragmatics..."
Let we concentrate on broader "Objects are really hard and no-one really understands to this day how to do them right" claim and not merely inheritance, please.
Best regards Janko
[1] http://dosync.posterous.com/illiterate-programming [2] http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-April/009261.htm...
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
Janok
Frankly I do not care about what other people are thinking. OOP is a success look at Java, C#.
Now let us keep our energy to build better Smalltalks.
Stef On Feb 11, 2012, at 1:21 PM, Janko Mivšek wrote:
Hi guys,
Again one interesting topic for this weekend to discuss. David Nolen, a Lisp and JavaScript guy posted in his blog an article titled Illiterate Programming [1] where he said:
"...Yet I think Smalltalk still fundamentally failed (remember this is a programming language originally designed to scale from children to adults) because *Objects are really hard* and no-one really understands to this day how to do them right...."
He links to Alan Kay post [2] back in 1998 where he talks about problems with inheritance:
"Here are a few problems in the naive inheritance systems we use today: confusions of Taxonomy and Parentage, of Specialization and Refinement, of Parts and Wholes, of Semantics and Pragmatics..."
Let we concentrate on broader "Objects are really hard and no-one really understands to this day how to do them right" claim and not merely inheritance, please.
Best regards Janko
[1] http://dosync.posterous.com/illiterate-programming [2] http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-April/009261.htm...
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
Hi Stef,
S, stephane ducasse piše:
Frankly I do not care about what other people are thinking. OOP is a success look at Java, C#.
Now let us keep our energy to build better Smalltalks.
Well, after hard work it is good from time to time to make a retrospection and let our thoughts to think a bit broader, to look from a distance to our work. To see the forest and not just trees.
So such debate from time to time is certainly refreshing and needed, specially if it is started from a outsider's perspective. Every wise man listen to the opinion of others. Well, of course wisely :)
In this case I see a wise thinking about weaknesses of OO and Smalltalk and how to overcome it by better "best practices". For instance, the newcommers are asking where to find a guidelines for modeling OO domain models in pure OO way. In this guidelines we can emphasise above mentioned best practices, then author's claim that "no one really understands to this day how to do them right" won't be valid much anymore.
Best regards Janko
Stef On Feb 11, 2012, at 1:21 PM, Janko Mivšek wrote:
Hi guys,
Again one interesting topic for this weekend to discuss. David Nolen, a Lisp and JavaScript guy posted in his blog an article titled Illiterate Programming [1] where he said:
"...Yet I think Smalltalk still fundamentally failed (remember this is a programming language originally designed to scale from children to adults) because *Objects are really hard* and no-one really understands to this day how to do them right...."
He links to Alan Kay post [2] back in 1998 where he talks about problems with inheritance:
"Here are a few problems in the naive inheritance systems we use today: confusions of Taxonomy and Parentage, of Specialization and Refinement, of Parts and Wholes, of Semantics and Pragmatics..."
Let we concentrate on broader "Objects are really hard and no-one really understands to this day how to do them right" claim and not merely inheritance, please.
Best regards Janko
[1] http://dosync.posterous.com/illiterate-programming [2] http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-April/009261.htm...
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
help-smalltalk mailing list help-smalltalk@gnu.org https://lists.gnu.org/mailman/listinfo/help-smalltalk
Indeed the article is kind to Smalltalk.
Janko wrote:
In this case I see a wise thinking about weaknesses of OO and Smalltalk and how to overcome it by better "best practices". For instance, the newcommers are asking where to find a guidelines for modeling OO domain models in pure OO way.
The C++, Java and C# textbooks I read before I tried Smalltalk are not very helpful.
I did not order a copy of Kent Beck's "Smalltalk Best Practice Patterns" before if went out of print. Would it help?
It is hard to substitute many hours spent with time-tested Smalltalk source code. Maybe an Active Essay (semi literate!) tourist guide to the kernel and standard libraries would be a helpful learning tool. Hypertext in source code (thanks to Ted Kaehler) still works.
http://wiki.squeak.org/squeak/42
Have fun! David
dcorking wrote
I did not order a copy of Kent Beck's "Smalltalk Best Practice
Great book, but the focus is on technique and I don't think it will help to grok what's special about OOP or Smalltalk. I would recommend "A Mentoring Course on Smalltalk" which goes way deep into how humans relate to the world around them and what that has to do with Smalltalk. Also, I've found it very valuable to read, and re-read, and re-read any relevant articles and papers from the PARC crew, especially Alan and Dan Ingalls. VPRI also has some good papers on their website.
HTH, Sean
-- View this message in context: http://forum.world.st/Are-Objects-really-hard-tp4378814p4382250.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
On Sat, Feb 11, I wrote:
The C++, Java and C# textbooks I read before I tried Smalltalk are not very helpful.
Sean, David, Goran, Tryvge and others: thanks for your insights and your reading recommendations.
I have since read that about a year ago, the Program By Design / Racket group of academics(*) posted an online draft of their Java-based sequel to 'How to Design Programs'. As far as I can tell, the new book has a couple of working titles : 'How to Design Classes' and 'How to Design Components'.
I haven't read it, but the premise of the book seems to tie in with Frank Shearer's comment about objects being higher order functions that close over variables. The preface, which includes a one-line quote from Alan Kay, may prove interesting to the readers of this thread.
http://www.ccs.neu.edu/home/matthias/htdc.html
Have fun! David
* - previously known as TeachScheme! / PLT group
I agree with Hernan. It's not Objects; it's software development in general that's hard. Go work on a large project sometime, and witness the awesome that transpires in a large team best by *cough* process *cough*
On Feb 11, 2012, at 1:58 PM, Janko Mivšek wrote:
Hi Stef,
S, stephane ducasse piše:
Frankly I do not care about what other people are thinking. OOP is a success look at Java, C#.
Now let us keep our energy to build better Smalltalks.
Well, after hard work it is good from time to time to make a retrospection and let our thoughts to think a bit broader, to look from a distance to our work. To see the forest and not just trees.
So such debate from time to time is certainly refreshing and needed, specially if it is started from a outsider's perspective. Every wise man listen to the opinion of others. Well, of course wisely :)
In this case I see a wise thinking about weaknesses of OO and Smalltalk and how to overcome it by better "best practices". For instance, the newcommers are asking where to find a guidelines for modeling OO domain models in pure OO way. In this guidelines we can emphasise above mentioned best practices, then author's claim that "no one really understands to this day how to do them right" won't be valid much anymore.
Best regards Janko
Stef On Feb 11, 2012, at 1:21 PM, Janko Mivšek wrote:
Hi guys,
Again one interesting topic for this weekend to discuss. David Nolen, a Lisp and JavaScript guy posted in his blog an article titled Illiterate Programming [1] where he said:
"...Yet I think Smalltalk still fundamentally failed (remember this is a programming language originally designed to scale from children to adults) because *Objects are really hard* and no-one really understands to this day how to do them right...."
He links to Alan Kay post [2] back in 1998 where he talks about problems with inheritance:
"Here are a few problems in the naive inheritance systems we use today: confusions of Taxonomy and Parentage, of Specialization and Refinement, of Parts and Wholes, of Semantics and Pragmatics..."
Let we concentrate on broader "Objects are really hard and no-one really understands to this day how to do them right" claim and not merely inheritance, please.
Best regards Janko
[1] http://dosync.posterous.com/illiterate-programming [2] http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-April/009261.htm...
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
help-smalltalk mailing list help-smalltalk@gnu.org https://lists.gnu.org/mailman/listinfo/help-smalltalk
-- Janko Mivšek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565
James Robertson http://www.jarober.com jarober@gmail.com
What is funnier any complain I have seen about OOP is always about things that have to do with the way people code than OO itself. As if magically a person will got to another "paradigm" or whatever other flashy word they invent for it and code much better.
Lately I had the pleasure to learn more about functional programming, because I had the pleasure to learn Lisp as well, but I dont see so much anything that can be not utilized with OOP as well.
Actually both Lisp and Python and of course Smalltalk foremost, take such a freeform approach to OOP that makes it very hard to say something really negative about since there are not any real limitations to how one may code with it.
Hi all Smalltalkers!
Only cross posting to squeak and pharo (communities I know), because this turned into a long post. But try reading it - I hope it is both fun and perhaps interesting. :)
On 02/11/2012 01:21 PM, Janko Mivšek wrote:
Hi guys,
Again one interesting topic for this weekend to discuss. David Nolen, a Lisp and JavaScript guy posted in his blog an article titled Illiterate Programming [1] where he said:
"...Yet I think Smalltalk still fundamentally failed (remember this is a programming language originally designed to scale from children to adults) because *Objects are really hard* and no-one really understands to this day how to do them right...."
As Hernan pointed out - it is programming that is hard, not *objects* per se. While that is true, one can of course still reflect on the aspects of OO and why people *perceive* it as hard.
SIDENOTE: As Milan wrote later in the thread - the patterns movement that Kent Beck started together with the Gang of Four led to the creation of TONS of books fully packed with OO designs in various domains. So yes, there is an *abundance* of books on OO design to find *iff* one goes looking for it.
He links to Alan Kay post [2] back in 1998 where he talks about problems with inheritance:
"Here are a few problems in the naive inheritance systems we use today: confusions of Taxonomy and Parentage, of Specialization and Refinement, of Parts and Wholes, of Semantics and Pragmatics..."
Of all OO mechanisms most agree that inheritance is the one that gets abused the most... if we disregard the "abuse" one can find in so called OO code that stems from it not being OO at all :)
Alan writes "confusions" and I suspect he carefully avoids saying one is wrong and the other is right, because its not that simple. Truth is one can use inheritance differently - as long as it makes your life better it can't really be argued to be "wrong". :)
I think most OO developers goes through some "ladder of enlightenment" going something like this:
0. You really have no clue and tend to confuse composition "parts and whole" with inheritance. You just create a mess. Perhaps you avoid this mess by reading a book or attending an OO course, but hey, who does that in 2012? ;). But let's say you *do* read a book - proceed to level 1...
1. You get all into Animals and other "inheritance" examples mirroring the real world. Perhaps you get totally sucked into the "mirror the real world"-idea. Thus, you try desperately to find "ISA" relations among the domain objects and use those for inheritance, without really thinking *why* that is a good idea. And sure, it often gets it fairly right so it's a huge step forward. But let's pretend you now have coded quite a bit and thus proceeds to level 2 :)
2. Specialization. After some time you start to understand polymorphism and the substitution principle etc, so instead of blindly testing if "A isa B" sounds right in your ears you start thinking in terms of generalisation and specialization. And you see objects in your head. You talk about them as if they are concrete and you can hold them in your hand etc. Perhaps you even draw them on whiteboards and envision them in different scenarios "talking to each other". If you use a statically typed language this is where your road stops :). You end up writing fairly good code, but your inheritance will probably be totally focused on enabling polymorphism between objects, which of course is not all bad. But hey, after a few years of Smalltalking - proceed to level 3.
3. As a seasoned Smalltalker you eventually come down from your "OO rush" and realize that... hey, wait a minute! Polymorphism is not *tied* to class inheritance (unless you are trapped in some static type system). In fact, you realize that class inheritance in Smalltalk is "merely" a nice way of reducing the redundancy of code by creating dependencies between separate abstractions of code. This realization enables you to use inheritance in a more liberal fashion - which probably means you tend to use it *less*. And instead you tend to "add more objects" and use composition of objects more and more, relying on brittle deep hierarchies of inheritance less and less.
SIDENOTE: A really cool example of how powerful object composition is: PetitParser by Lukas. For years we have been creating parsers by generating code from specifications and suddenly Lukas decides that hey, why not instead *compose* a parser from ...objects? It is so obvious in retrospect, but the result is a tremendously nicer and more powerful way of constructing parsers.
You also conclude that while you *can* reuse behaviors and compose behaviors using inheritance you are also aware that inheritance creates a life cycle *dependency* between classes that you *may* or *may not* want to have. Class inheritance is a brittle relation. Thus, even if class A *can* inherit from B, you might decide not to - because you anticipate that the development lineage will diverge, or perhaps you have no control over A (library? other developer? bad code?), and you do not want that dependency. But the up side is that sometimes you *really* want that dependency, change superclass and bam - affect all subclasses.
Another obvious benefit of inheritance is of course "documentation structure" that you and other developers can understand.
...well. Of course, the above was written sloppily and can of course be refined or totally shot down. Feel free to do both! :)
regards, Göran
PS. Why oh why did Pharo lose the "double click on ? in the class browser to see inheritance textually"-mechanism? :)
2012/2/13 Göran Krampe goran@krampe.se:
Hi all Smalltalkers!
Only cross posting to squeak and pharo (communities I know), because this turned into a long post. But try reading it - I hope it is both fun and perhaps interesting. :)
On 02/11/2012 01:21 PM, Janko Mivšek wrote:
Hi guys,
Again one interesting topic for this weekend to discuss. David Nolen, a Lisp and JavaScript guy posted in his blog an article titled Illiterate Programming [1] where he said:
"...Yet I think Smalltalk still fundamentally failed (remember this is a programming language originally designed to scale from children to adults) because *Objects are really hard* and no-one really understands to this day how to do them right...."
As Hernan pointed out - it is programming that is hard, not *objects* per se. While that is true, one can of course still reflect on the aspects of OO and why people *perceive* it as hard.
SIDENOTE: As Milan wrote later in the thread - the patterns movement that Kent Beck started together with the Gang of Four led to the creation of TONS of books fully packed with OO designs in various domains. So yes, there is an *abundance* of books on OO design to find *iff* one goes looking for it.
He links to Alan Kay post [2] back in 1998 where he talks about problems with inheritance:
"Here are a few problems in the naive inheritance systems we use today: confusions of Taxonomy and Parentage, of Specialization and Refinement, of Parts and Wholes, of Semantics and Pragmatics..."
Of all OO mechanisms most agree that inheritance is the one that gets abused the most... if we disregard the "abuse" one can find in so called OO code that stems from it not being OO at all :)
Alan writes "confusions" and I suspect he carefully avoids saying one is wrong and the other is right, because its not that simple. Truth is one can use inheritance differently - as long as it makes your life better it can't really be argued to be "wrong". :)
I think most OO developers goes through some "ladder of enlightenment" going something like this:
- You really have no clue and tend to confuse composition "parts and whole"
with inheritance. You just create a mess. Perhaps you avoid this mess by reading a book or attending an OO course, but hey, who does that in 2012? ;). But let's say you *do* read a book - proceed to level 1...
- You get all into Animals and other "inheritance" examples mirroring the
real world. Perhaps you get totally sucked into the "mirror the real world"-idea. Thus, you try desperately to find "ISA" relations among the domain objects and use those for inheritance, without really thinking *why* that is a good idea. And sure, it often gets it fairly right so it's a huge step forward. But let's pretend you now have coded quite a bit and thus proceeds to level 2 :)
- Specialization. After some time you start to understand polymorphism and
the substitution principle etc, so instead of blindly testing if "A isa B" sounds right in your ears you start thinking in terms of generalisation and specialization. And you see objects in your head. You talk about them as if they are concrete and you can hold them in your hand etc. Perhaps you even draw them on whiteboards and envision them in different scenarios "talking to each other". If you use a statically typed language this is where your road stops :). You end up writing fairly good code, but your inheritance will probably be totally focused on enabling polymorphism between objects, which of course is not all bad. But hey, after a few years of Smalltalking - proceed to level 3.
- As a seasoned Smalltalker you eventually come down from your "OO rush"
and realize that... hey, wait a minute! Polymorphism is not *tied* to class inheritance (unless you are trapped in some static type system). In fact, you realize that class inheritance in Smalltalk is "merely" a nice way of reducing the redundancy of code by creating dependencies between separate abstractions of code. This realization enables you to use inheritance in a more liberal fashion - which probably means you tend to use it *less*. And instead you tend to "add more objects" and use composition of objects more and more, relying on brittle deep hierarchies of inheritance less and less.
Well, we like to look at Java and hold our noses, but really, Java has a rubbish type system, regardless of it being static. Now if you were looking at some Haskell code, you'd see some highly polymorphic stuff going on thanks to typeclasses. And in the dynamic functional language corner you'd recognise good Smalltalk practice in Clojure's Protocols. (They like to say that protocols solve the Expression Problem, but really, it's multimethods that do that, not protocols.)
If you'd like to see Clojure's protocols in action, this is a nice demonstration: http://news.ycombinator.com/item?id=3515862
The thing to bear in mind here is that (a) protocols won't surprise you; they're "this thing responds to this set of messages" just as you'd expect and (b) they do not pollute the global namespace: you can add a method to some object _in a scoped manner_.
SIDENOTE: A really cool example of how powerful object composition is: PetitParser by Lukas. For years we have been creating parsers by generating code from specifications and suddenly Lukas decides that hey, why not instead *compose* a parser from ...objects? It is so obvious in retrospect, but the result is a tremendously nicer and more powerful way of constructing parsers.
But you realise the irony here, right? That if you google "parser combinator" you hit all those "non-OO" languages like Haskell (and then the new kids like Scala and F#). (Yes, yes, 3rd hit's Gilad's talk. Not surprising.) But then, that in itself isn't terribly surprising, because not many people get at a deep level that objects are nothing more than higher order functions that close over variables.
I have a long-running argument with a colleague who says (among other reasons) that he thinks Smalltalk is rubbish because class-based systems are rubbish (because of all the issues around inheritance). But, of course, while we happen to use classes all the time, we don't HAVE to. And, indeed, there are several prototype-based Smalltalk libraries. Because, at its core, Smalltalk isn't about classes, it's about objects sending messages to each other.
You also conclude that while you *can* reuse behaviors and compose behaviors using inheritance you are also aware that inheritance creates a life cycle *dependency* between classes that you *may* or *may not* want to have. Class inheritance is a brittle relation. Thus, even if class A *can* inherit from B, you might decide not to - because you anticipate that the development lineage will diverge, or perhaps you have no control over A (library? other developer? bad code?), and you do not want that dependency. But the up side is that sometimes you *really* want that dependency, change superclass and bam - affect all subclasses.
Indeed: you should probably only use inheritance if you _have to_. Exactly because it couples every class in an hierarchy together, and you can no longer understand a method without understanding how that method overrides/replaces/is overridden/is replaced in the tree.
Another obvious benefit of inheritance is of course "documentation structure" that you and other developers can understand.
I'm sure we can do much better though. I'm thinking here of "this is a Stream because it understands <set of standard Stream messages>".
frank
...well. Of course, the above was written sloppily and can of course be refined or totally shot down. Feel free to do both! :)
regards, Göran
PS. Why oh why did Pharo lose the "double click on ? in the class browser to see inheritance textually"-mechanism? :)
On 13 Feb 2012, at 10:23, Göran Krampe wrote:
PS. Why oh why did Pharo lose the "double click on ? in the class browser to see inheritance textually"-mechanism? :)
I just tried in my 1.4 image #14329 image with the standard browser and it works:
ProtoObject #() Object #() Magnitude #() LookupKey #('key')
Association #('value')
Sven
There is no question that over-use of inheritance (failure to understand composition) is a classic beginner mistake. That said, don't underestimate the value of inheritance. Granted, the example I have in mind is perfect for specialization, but beyond that, failure to use (extensive) inheritance can at times lead to lots of duplicate code (which is really bad). Say it once - inheritance can help one do just that (policy up, implementation down, etc.).
Bill
On 02/13/2012 12:22 PM, Sven Van Caekenberghe wrote:
On 13 Feb 2012, at 10:23, Göran Krampe wrote:
PS. Why oh why did Pharo lose the "double click on ? in the class browser to see inheritance textually"-mechanism? :)
I just tried in my 1.4 image #14329 image with the standard browser and it works:
Oh nice! I confess i didn't try the latest Pharo (only 1.2) before I wrote this - I just presumed it still did not work ;) My bad.
regards, Göran
Hi Göran,
Göran Krampe wrote:
Hi all Smalltalkers!
Only cross posting to squeak and pharo (communities I know), because this turned into a long post. But try reading it - I hope it is both fun and perhaps interesting. :)
On 02/11/2012 01:21 PM, Janko Mivšek wrote:
Hi guys,
Again one interesting topic for this weekend to discuss. David Nolen, a Lisp and JavaScript guy posted in his blog an article titled Illiterate Programming [1] where he said:
"...Yet I think Smalltalk still fundamentally failed (remember this is a programming language originally designed to scale from children to adults) because *Objects are really hard* and no-one really understands to this day how to do them right...."
As Hernan pointed out - it is programming that is hard, not *objects* per se. While that is true, one can of course still reflect on the aspects of OO and why people *perceive* it as hard.
There is a mistake in this discussion right from the start that nobody pointed out. When Alan says "Nobody knows how to do objects right" he's not talking about programing in an OO language, but about designing the language and system itself. I agree with this. I prefer Smalltalk to all the systems/languages done afterwards, trying to fix Smalltalk weaknesses. Besides, he praised many times the works of members of his various teams, and of members of this community.
WRT the usual comment, saying that it is hard to program well with objects and that this implies that objects are bad, is like saying the guitar is bad because it is not easy to play it really well. I took ten years of piano classes when I was a kid, but I'm not good enough to play in public, and I guess I'll never be. I'm not talented enough for that. The same can happen to others with programming, and with objects in particular. If the player is not good, it is not the instrument to blame!
SIDENOTE: As Milan wrote later in the thread - the patterns movement that Kent Beck started together with the Gang of Four led to the creation of TONS of books fully packed with OO designs in various domains. So yes, there is an *abundance* of books on OO design to find *iff* one goes looking for it.
He links to Alan Kay post [2] back in 1998 where he talks about problems with inheritance:
"Here are a few problems in the naive inheritance systems we use today: confusions of Taxonomy and Parentage, of Specialization and Refinement, of Parts and Wholes, of Semantics and Pragmatics..."
Of all OO mechanisms most agree that inheritance is the one that gets abused the most... if we disregard the "abuse" one can find in so called OO code that stems from it not being OO at all :)
Alan writes "confusions" and I suspect he carefully avoids saying one is wrong and the other is right, because its not that simple. Truth is one can use inheritance differently - as long as it makes your life better it can't really be argued to be "wrong". :)
I think most OO developers goes through some "ladder of enlightenment" going something like this:
- You really have no clue and tend to confuse composition "parts and
whole" with inheritance. You just create a mess. Perhaps you avoid this mess by reading a book or attending an OO course, but hey, who does that in 2012? ;). But let's say you *do* read a book - proceed to level 1...
- You get all into Animals and other "inheritance" examples mirroring
the real world. Perhaps you get totally sucked into the "mirror the real world"-idea. Thus, you try desperately to find "ISA" relations among the domain objects and use those for inheritance, without really thinking *why* that is a good idea. And sure, it often gets it fairly right so it's a huge step forward. But let's pretend you now have coded quite a bit and thus proceeds to level 2 :)
- Specialization. After some time you start to understand
polymorphism and the substitution principle etc, so instead of blindly testing if "A isa B" sounds right in your ears you start thinking in terms of generalisation and specialization. And you see objects in your head. You talk about them as if they are concrete and you can hold them in your hand etc. Perhaps you even draw them on whiteboards and envision them in different scenarios "talking to each other". If you use a statically typed language this is where your road stops :). You end up writing fairly good code, but your inheritance will probably be totally focused on enabling polymorphism between objects, which of course is not all bad. But hey, after a few years of Smalltalking - proceed to level 3.
- As a seasoned Smalltalker you eventually come down from your "OO
rush" and realize that... hey, wait a minute! Polymorphism is not *tied* to class inheritance (unless you are trapped in some static type system). In fact, you realize that class inheritance in Smalltalk is "merely" a nice way of reducing the redundancy of code by creating dependencies between separate abstractions of code. This realization enables you to use inheritance in a more liberal fashion - which probably means you tend to use it *less*. And instead you tend to "add more objects" and use composition of objects more and more, relying on brittle deep hierarchies of inheritance less and less.
SIDENOTE: A really cool example of how powerful object composition is: PetitParser by Lukas. For years we have been creating parsers by generating code from specifications and suddenly Lukas decides that hey, why not instead *compose* a parser from ...objects? It is so obvious in retrospect, but the result is a tremendously nicer and more powerful way of constructing parsers.
You also conclude that while you *can* reuse behaviors and compose behaviors using inheritance you are also aware that inheritance creates a life cycle *dependency* between classes that you *may* or *may not* want to have. Class inheritance is a brittle relation. Thus, even if class A *can* inherit from B, you might decide not to - because you anticipate that the development lineage will diverge, or perhaps you have no control over A (library? other developer? bad code?), and you do not want that dependency. But the up side is that sometimes you *really* want that dependency, change superclass and bam
- affect all subclasses.
Another obvious benefit of inheritance is of course "documentation structure" that you and other developers can understand.
...well. Of course, the above was written sloppily and can of course be refined or totally shot down. Feel free to do both! :)
Or praised. Very well said, Göran!
Cheers, Juan Vuletich
regards, Göran
PS. Why oh why did Pharo lose the "double click on ? in the class browser to see inheritance textually"-mechanism? :)
Hi all, The answer is yes or no depending on the observer's mindset.
A Smalltalk object has a unique identity and encapsulates state and behavior. Objects in its environment can know its identity and send messages to it. There is no restriction; an object can receive any conceivable message. Inside the encapsulation, we find instance variables and methods. An object selects and invokes a method in response to an incoming message. (The |doesNotUnderstand:| method is one of them).
An isolated object by itself is not interesting. The essence of object orientation is that objects interact to achieve a task. A person who wants to understand how a system of objects works, needs to answer three essential questions: "What are the objects?" "How are they interconnected?" "What do they do?"
/Are objects really hard?/ The answer is YES for a person having a class-based mindset. The class abstraction describes all the properties of an object that are visible when it is observed from its inside. Its environment is outside its encapsulation and is not visible in the class description. Anybody trying to answer the above three essential questions by studying a class is doomed to failure. Objects are really hard for such people.
/Are objects really hard?/ The answer is NO if the question is asked by a person having an object-based mindset:
* Alan Kay's schoolchildren had no problems with interacting objects. * My company developed object-based models for different clients using role modeling (OOram). Again, there was no problem with the idea of interacting objects. * Many developers use CRC cards to elucidate object-based mental models shared by users and developers alike. Again, CRC cards are easy to understand. (A note here. CRC originally was short for /Class-Responsibility-Collaboration/. This was a misnomer since classes do not collaborate, their instances do. People think instance even if they say class. Today, the letters stand for /Candidate role-Resonsibility-Collaboration/. [Rebecca Wirfs-Brock]) * In their book "Lean System Architecture", Coplien and Brøvig recommend programmers to work closely with users to elucidate an object-based system architecture. * A growing community of programmers understand the DCI paradigm and have an object-based mindset. DCI (Data-Context-Interaction) includes both mental models and actual code. It is interesting to note that many members of this community started out with a class-based mindset. As one should expect, changing a mindset can prove very hard. After the hard work of the transition, objects became very simple..
In Smalltalk, anything anybody will ever want to represent in the system will be represented by an object. There is no alternative. The image of objects rests on top of the VM. A few of these objects are special in that the VM knows the position of certain key properties within the object. Instances of class Class are such objects where the VM knows how to find the |methodDict |and other properties. Examples are the properties the VM needs to create a new instance. There are other special objects such as |CompiledMethod |and |SmallInteger|. It is interesting to note that there is no such thing as a "Smalltalk language" in the same sense that there is a Java language. There is a default language for specifying methods in the context of a class. Its compiler is actually a method in the metaclass. Other classes can support other languages. VisualWorks had classes where the methods were written in SQL.
There is nothing in Smalltalk that makes class-based programming mandatory. It makes me sad to think of all the opportunities that have been lost through the past 40 years due to this wholly arbitrary restriction.
Cheers --Trygve
On 2/11/12, Janko Mivšek janko.mivsek@eranova.si wrote:
Hi guys,
Again one interesting topic for this weekend to discuss. David Nolen, a Lisp and JavaScript guy posted in his blog an article titled Illiterate Programming [1] where he said:
"...Yet I think Smalltalk still fundamentally failed (remember this is a programming language originally designed to scale from children to adults) because *Objects are really hard* and no-one really understands to this day how to do them right...."
He links to Alan Kay post [2] back in 1998 where he talks about problems with inheritance:
"Here are a few problems in the naive inheritance systems we use today: confusions of Taxonomy and Parentage, of Specialization and Refinement, of Parts and Wholes, of Semantics and Pragmatics..."
Let we concentrate on broader "Objects are really hard and no-one really understands to this day how to do them right" claim and not merely inheritance, please.
Best regards Janko
[1] http://dosync.posterous.com/illiterate-programming [2] http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-April/009261.htm...
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
Interestingly on the cited page
http://dosync.posterous.com/illiterate-programming
we read
"There's nothing more powerful in aiding readability than a small core set of concepts. In this sense I think Smalltalk continues to be one of the few languages to get anywhere near LISP. "
--Hannes
Hi guys,
Just to conclude this topic: there is a nice talk between Dave Thomas (of OTI fame where IBM VisualAge Smalltalk and nowadays VA Smalltalk came out), James Robertson and David Buck in recent Independent Misinterpretations:
IM 67: Have Objects Failed Us? http://www.jarober.com/blog/blogView?entry=3507708198
What I like is a discussion about OO vs. relational world and ORM in the second half, which is also by my opinion the reason why OO didn't succeed more as it did, and why is considered hard for most of developers until our days.
Best regards Janko
S, Janko Mivšek piše:
Hi guys,
Again one interesting topic for this weekend to discuss. David Nolen, a Lisp and JavaScript guy posted in his blog an article titled Illiterate Programming [1] where he said:
"...Yet I think Smalltalk still fundamentally failed (remember this is a programming language originally designed to scale from children to adults) because *Objects are really hard* and no-one really understands to this day how to do them right...."
He links to Alan Kay post [2] back in 1998 where he talks about problems with inheritance:
"Here are a few problems in the naive inheritance systems we use today: confusions of Taxonomy and Parentage, of Specialization and Refinement, of Parts and Wholes, of Semantics and Pragmatics..."
Let we concentrate on broader "Objects are really hard and no-one really understands to this day how to do them right" claim and not merely inheritance, please.
Best regards Janko
[1] http://dosync.posterous.com/illiterate-programming [2] http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-April/009261.htm...
squeak-dev@lists.squeakfoundation.org