Just a couple of datapoints based on personal experience:

	* I worked with a VP at a large media outlet who was an old-school programmer who once wrote a page-layout system in assembler.  He didn't think much of objects and it was common to hear him say he could write more functional code in assembly than in any OO language.

	* At the same job I tried to mentor a co-worker moving to OO.  He never did get it -- he didn't see anything as abstractions, everything was  procedural/functional in his world view.
** ''Objection raised below under "Noun Vs. Verb Abstraction".''

	* Based on some Java servlet code I recently worked on (read: followed up after the initial programmer moved on to another job) some VB-style programming habits seem to have become associated with OO.  The code was event-driven, and the 'objects' were all in the respond-to-this-event-do-something model.  Which is OK except that every event was handled in isolation, even though there was really a great deal of commonality of function across the dozen or so 'events'.  A straightforward candidate for CommandPattern, but generally each source file was a poster child for CopyAndPasteProgramming. 
** ''Objection raised below under "Reducing Code".''

-- StevenNewton

-----

I was training two inexperienced C++ programmers ''(who, effectively, only knew C)''...
One who wanted to learn, and the other who really didn't seem to want to be bothered.

From the one who didn't want to be bothered:
	* ''"Why should I put this in a class?  I can make it work with functions."''  [I said that, likewise, I could do it in assembly instead of C, and make it work, but he didn't seem to understand the comparison.]
	* ''"You can't have more than one object [instance] in a program!!!"''
	* He was really confused by COM, even after taking the week long DevelopMentor class:  He insisted that object can and must only be created with QueryInterface, because that was the "standard method" taught in the class.

The other was more interested in learning, and we made a lot of progress.
-- JeffGrigg

''Confused by the COM example.  What was he calling QueryInterface on, if not an object he got through some other route?''

-----

'''So how did ''we'' come to grok objects?'''

See HowiLearnedToLoveObjects
----
'''Noun Vs. Verb Abstraction'''

Re: "At the same job I tried to mentor a co-worker moving to OO.  He never did get it -- he didn't see anything as abstractions, everything was  procedural/functional in his world view."
* ''How are verb-oriented abstractions "worse" or "lessor" than noun-oriented ones? "Linear" textual  code forces us to group by only one or the other as the primary "sort". One is not inherently better or worse, but merely the chosen primary grouping by which which we choose to manage our code. (I tend to use an RDBMS to model and manage my domain "nouns", by the way.) --top''

--------
'''OOP and Code Size'''

Re: "Based on some Java servlet code I recently worked on (read: followed up after the initial programmer moved on to another job) some VB-style programming habits seem to have become associated with OO.  The code was event-driven, and the 'objects' were all in the respond-to-this-event-do-something model.  Which is OK except that every event was handled in isolation, even though there was really a great deal of commonality of function across the dozen or so 'events'.  A straightforward candidate for CommandPattern, but generally each source file was a poster child for CopyAndPasteProgramming." 
* ''Why couldn't shared functions be used to factor out the commonalities? General statements like this do not help the ongoing OO debates. We need specific examples with example "bad" non-OO code being fixed by "good" OO. Note that I have never ever seen an example, toy or real, of OOP reducing code size by any significant amount. And most differences could be chalked up to specific languages. I challenge anyone to produce a code sample that clearly shows OO reducing code that procedural/relational cannot. This seems to be a case of OopSelfFullfillingProphecies.''


-----
See also: ObjectOrientedDesignIsDifficult