The slope flows the other way IMHO, most of the time most programs I've seen arent abstracting enough and the code is far to sequential and unnecessarily complicated because of it. Excessive if and switches seem far more common to me than excessive use of polymorphism.
Two sides of the same coin. Your example is newbie programmers, mine is the same newbies on their second project. ;)
As usual it's all about striking the balance. I wonder if one day we'll come up with a programming language that can enforce these things in a meaningful way.
My example is not newbie programmers, rather, much code written by experienced OO programmers who don't have a Smalltalk background. I can't say what it looks like now, but I recall Rails active record implementation being heavily procedural in nature when I first looked at it way back and DHH is hardly a newbie. Decompile most classes in the dot net framework, and you'll find a fuck ton of procedural code even though it presents an OO API. 500 line methods are not uncommon.
When you learn OO in a procedural language like ruby or java, you tend to have a slightly odd idea of OO. Just because a language supports objects doesn't make it object oriented, it just allows object orientation.
I thought I knew OO until I learned Smalltalk, and discovered just how deep the rabbit hole can go. If's, foreach, while, unless, switches, these are all procedural constructs. You don't truly grok OO if you can't write a program without using procedural constructs (as an exercise).
And who knows, maybe someone will invent a language that nails the balance, I won't bet on it soon though.
In principle I agree with you, but in general procedural constructs are not harmful and should be used where appropriate.
500 lines is indeed a bit much, but I've seen through 100 line methods without an urge to refactor.
The best programs are those that have both; good use of patterns and the odd suspiciously long method if appropriate.
The worst programs are not only the classic spaghettis but also those that dogmatically stick to a pattern even where it makes no sense. Java is notorious for the latter, but I also often see ruby programs where the author religiously clinges to the belief that no method can be allowed to exceed 5 lines of code. That, in combination with misunderstood unit-testing (foo.MUST_RECEIVE :bar), often leads to ridiculously tight coupling and effectively a monolithic brick that is resilient to change.
I call these programs Gnocchi-code. A close relative of spaghetti, just higher density...
Of course, that's where taste comes in. And I did say "as an exercise", I wasn't suggesting not using them ever, but as a kata to see how much you can do with only objects.
What's so "procedural" about 500 line routines (procedures, methods, functions)?
That's just crappy coding in any language. And I see it all too often, alas.
Having missed out on Smalltalk back in the 80s, I will venture to ask how one does conditional execution or terminates recursion without an "if", though? Even Lisp has its "(COND ...)" expression (yes, I know that's not OOP).
Sequential thinking. Long methods tend to come from thinking only about accomplishing a task step by step rather than building a machine that can solve many problems (an object model).
As for Smalltalk's conditional, of course it has them, but they're not procedural constructs of the language. Smalltalk implements its conditional behavior with an object model of course, the abstract class Boolean has two subclasses, true and false. The keywords true and false reference the single instance of each of those classes. Each class implements a set of methods like ifTrue:ifFalse: which take blocks (closures in modern smalltalks). True implements ifTrue by evaluating the block, False implements ifTrue with a no op, an empty method. Bam, Boolean logic implemented with objects and polymorphism.
Thus in Smalltalk, conditionals are method calls on booleans and come after the comparison rather than before.
