This note kind of ties down to this discussion. Why does Rails , .Net : VB/ C# or Java , PHP et als succeed : Objects vs code pattern.. ( not design pattern ). Pattern matched copying of code to get an app constructed/ maintained/ extended. What I mean is people learn/ work mostly by pattern they pick up and accumulate as much is necessary for them to go exploring. They really do not go debugging deep and wide. Example: Let us say in VB/ C# or Rails ; you have read how doing steps 1, 2 , 3 and using a pattern of macro's helps get this function done.. they get it going fast by copying , modifying bits/ ids/ etc here n there.. Barely few I have met in C# / .Net / PHP world who really know its deep internals as one imagines Smalltalkers need to know of Smalltalk base. So when they want something else like how to have a Dataset connected with a DB table and do CRUD.. they pick an example , modify by patterns... and get it going. They do not spend time debugging and knowing whats inside the various classes, its "Object" / "Class" etc.. But in Smalltalk, I believe as it exists, it is certainly not that "friendly" or dumbed down for people to simply pattern match.. You need to be innured in browse hierarchy, senders, implementors, references, understand the methods/ messages .. the whole wiring of "Objects"... Java claims and is certainly better than this lot.. but with its XML, struts, templates, even the HTML programming is actually lot easier than Seaside with the need to do Object oriented server side code even for the HTML .. easy for many of us.. but I realize really hard to grok from most of the milling crowd. Easier there of to deploy less experienced/ junior programmers in more divided modules of work... not that we cannot have it in Smalltalk, just that much harder.. I believe to hit it viral, you do need the Rails kind of appeal, even the PHP .. macro's ; pattern matched code / ability to quickly scale from copy-paste pattern matched code, wizards that get you up and running for small / medium apps. Leave the higher order/ comprehension / framework construction to those who do.. but if we can make the entry barrier really low to work with Smalltalk without OOPs baggage.. it might surprise all of us how many could flock in.. This will easily graft people in and then push their need to really dig in, and go up the value chain. Of course the primary motive that hits is making money in what they do.. ! That really begs the point here.. most of such programmers really do not try understand "Objects" as in OOPs with the construct of metaclass/ behavior/MessageSend/ ClassDescription/.. etc .. they just do with what is a pattern of code either as stmts or methods that they see/ copy / run.. rather than worry about correct composition - hierarchy - indirection even simple stuff like double dispatch.. et als. Of course its a grey band .. so many are in the 70% range of the gray band.. but few really do try and understand the OOPs internals deep down.. Debugging / inspection is not wired in.. either On 2/27/12, Janko Mivšek <janko.mivsek@eranova.si> wrote:
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...
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si