Let we remember that Smalltalk was designed for a kids, so "programming is hard anyway" is in my opinion just too simplified answer. While teaching new Smalltalkers I noticed that those without any programming experience got it faster, specially comparing to those with a relational DB experience. Who were and are still part of mainstream. So, maybe it is better to say that established habits and mental models in programmers heads never changed enough to get OO right? To rephrase a bit differently: Hardly anyone is playing OO right because OO was used too long on top of relational world and the ideas of pure OO were forgotten and lost. Best regards Janko S, Schwab,Wilhelm K piše:

Yes, programming is hard. It's even harder if one is poorly educated and not well read. I don't expect that everyone will have Smalltalk experience, but I would expect someone nearing completion of a PhD in computer science to have at least _heard_ of Smalltalk and Alan Kay. I recently met a very bright count-example to my expectation.

The average programmer I meet, has no historical perspective, can't intelligently compare and contrast oo, structured and functional approaches to software implementation. All they seem to care about is this or that "technology" they saw in a glossy ad.

Do you recall a talk Alan gave some years back at Stanford? He was on a good rant about how our computer science/engineering departments had let themselves be turned into Java certification mills, and ultimately uttered the words "what has happened to the mighty Standford?" I was a little surprised at his candor (took guts) and agreed with every word he said.

The problem is PATHETIC education and self-preparation, IMHO.

------------------------------------------------------------------------ *From:* pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Hernan Wilkinson [hernan.wilkinson@10pines.com] *Sent:* Saturday, February 11, 2012 7:42 AM *To:* The general-purpose Squeak developers list *Cc:* VWNC; va-smalltalk@googlegroups.com; GNU Smalltalk; Pharo-project@lists.gforge.inria.fr *Subject:* Re: [Pharo-project] [squeak-dev] Are Objects really hard?

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.si <mailto: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

-- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

I could not agree more... most programmers don't know what a is closure (for example), have no idea of who is Alan Kay (or worse, Alonso Curch) and they only care about how to use Spring's dependency injection without understanding the real design flaw, or the new Hibernate annotations that will help them to write less "xml code"...... but there is hope :-) On Sat, Feb 11, 2012 at 9:55 AM, Schwab,Wilhelm K <bschwab@anest.ufl.edu>wrote:

Yes, programming is hard. It's even harder if one is poorly educated and not well read. I don't expect that everyone will have Smalltalk experience, but I would expect someone nearing completion of a PhD in computer science to have at least _heard_ of Smalltalk and Alan Kay. I recently met a very bright count-example to my expectation.

The average programmer I meet, has no historical perspective, can't intelligently compare and contrast oo, structured and functional approaches to software implementation. All they seem to care about is this or that "technology" they saw in a glossy ad.

Do you recall a talk Alan gave some years back at Stanford? He was on a good rant about how our computer science/engineering departments had let themselves be turned into Java certification mills, and ultimately uttered the words "what has happened to the mighty Standford?" I was a little surprised at his candor (took guts) and agreed with every word he said.

The problem is PATHETIC education and self-preparation, IMHO.

------------------------------ *From:* pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] on behalf of Hernan Wilkinson [hernan.wilkinson@10pines.com] *Sent:* Saturday, February 11, 2012 7:42 AM

*To:* The general-purpose Squeak developers list *Cc:* VWNC; va-smalltalk@googlegroups.com; GNU Smalltalk; Pharo-project@lists.gforge.inria.fr *Subject:* Re: [Pharo-project] [squeak-dev] Are Objects really hard?

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.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

-- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

-- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

Lead by example. +1. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, February 11, 2012 1:34 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [squeak-dev] Are Objects really hard? Janko 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 2:52 PM, Hernan Wilkinson wrote:

I could not agree more... most programmers don't know what a is closure (for example), have no idea of who is Alan Kay (or worse, Alonso Curch) and they only care about how to use Spring's dependency injection without understanding the real design flaw, or the new Hibernate annotations that will help them to write less "xml code"...... but there is hope :-)

On Sat, Feb 11, 2012 at 9:55 AM, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote: Yes, programming is hard. It's even harder if one is poorly educated and not well read. I don't expect that everyone will have Smalltalk experience, but I would expect someone nearing completion of a PhD in computer science to have at least _heard_ of Smalltalk and Alan Kay. I recently met a very bright count-example to my expectation.

The average programmer I meet, has no historical perspective, can't intelligently compare and contrast oo, structured and functional approaches to software implementation. All they seem to care about is this or that "technology" they saw in a glossy ad.

Do you recall a talk Alan gave some years back at Stanford? He was on a good rant about how our computer science/engineering departments had let themselves be turned into Java certification mills, and ultimately uttered the words "what has happened to the mighty Standford?" I was a little surprised at his candor (took guts) and agreed with every word he said.

The problem is PATHETIC education and self-preparation, IMHO.

From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Hernan Wilkinson [hernan.wilkinson@10pines.com] Sent: Saturday, February 11, 2012 7:42 AM

To: The general-purpose Squeak developers list Cc: VWNC; va-smalltalk@googlegroups.com; GNU Smalltalk; Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [squeak-dev] Are Objects really hard?

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.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

-- Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

-- Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

Thankfully I did Smalltalk (V/DOS) at university, not looked back since... Regards, Gary ----- Original Message ----- From: Lawrence Kellogg To: Pharo-project@lists.gforge.inria.fr Sent: Tuesday, February 14, 2012 5:16 PM Subject: Re: [Pharo-project] [squeak-dev] Are Objects really hard? Do you recall a talk Alan gave some years back at Stanford? He was on a good rant about how our computer science/engineering departments had let themselves be turned into Java certification mills, and ultimately uttered the words "what has happened to the mighty Standford?" I was a little surprised at his candor (took guts) and agreed with every word he said. Here is a reference to an interview Alan did with ACM where he mentions Java vocational training: http://queue.acm.org/detail.cfm?id=1039523 " AK Yes, that was the big revelation to me when I was in graduate school—when I finally understood that the half page of code on the bottom of page 13 of the Lisp 1.5 manual was Lisp in itself. These were “Maxwell’s Equations of Software!” This is the whole world of programming in a few lines that I can put my hand over. I realized that anytime I want to know what I’m doing, I can just write down the kernel of this thing in a half page and it’s not going to lose any power. In fact, it’s going to gain power by being able to reenter itself much more readily than most systems done the other way can possibly do. All of these ideas could be part of both software engineering and computer science, but I fear—as far as I can tell—that most undergraduate degrees in computer science these days are basically Java vocational training. I’ve heard complaints from even mighty Stanford University with its illustrious faculty that basically the undergraduate computer science program is little more than Java certification. " I think goodness that my first computer science professor tore two pages out of the LISP manual and drummed it into our thick skulls that the whole execution cycle was contained in APPLY and EVAL. I owe that guy a lot. Thanks, Eddie Storm. Larry

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:

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.

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? :)

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

Janko Mivšek <janko.mivsek@eranova.si> writes:

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. I thin OO has clearly won hands down. Look in every languages these days. There are classes and objects. Even in the "main-stream" languages like C#, and Java it's not a question whether OO but only how. There are still things lacking. That are blocks (I know they wer introduced recently in both Java and C#) but probably not used that much. The same is true for ORM, it's not if but how it's done. I for my part see the biggest mistakte in doing that. Yes one can it make work, but it's always a break and/or one is not using OO as it was meant to be used.

Since ages we get promised that OODBS or the like are the future but what do you really have key/value pairs (that's since the good ole Berkeley DB times) now the DBs got the name NoSQL, but in the end the complete IT infrastructure relies and is build on RDBs (maybe with some O extension in it. I guess therefor we'll be stuck with new approaches to persistence through RDBs. Some will work under certain limits and others's won't. And I don't think it's considered hard to do OO with Smalltalk, Ruby etc. It is hard for C++ because this is a language full of rites and that's makes it look that hard. Just remember the big hype around Talingent? Now what's left of it. Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus