Popular conceit about learning programming languages

[maney at pobox.com]

Michele Simionato <mis6 at pitt.edu> wrote:
> language, according to different phylosophies. Here it is the solution
> I came out in Python in two seconds of thinking, the "natural"
> solution at this stage of my knowledge of Python:
> 
> def print_OS_evaluation():
>    "Gives a thought evaluation of operating systems"
> 
>    import sys
> 
>    def GoodBox():
>        print "This is a good box"
> 
>    def BadBox():
>        print "This is a bad box"
>   
>    def UnknownBox():
>        print "This is not a box"
>          
>    printEvaluation={
>       'linux2':GoodBox,
>       'sunos5': GoodBox,         
>       'win32':BadBox}.get(sys.platform,UnknownBox)
> 
>    return printEvaluation
> 
> The code is pretty obvious ...

Seems overelaborated to me.  Why in the world invent functions to print
a string?  (of course it is even sillier to invent entire classes to
print a string, but that seems to have been an unstated requirement for
the Java examples: goodness increases with classes, whether sensible or
not?)

def print_OS_evaluation():
    import sys

    osGood = 'a good box'
    osBad = 'not a box'
    osUnknown = 'unknown'

    osEvaluation = {
       'linux2': osGood,
       'sunos5': osGood,         
       'win32':  osbad
    }

    return 'This is %s' % osEvaluation.get(sys.platform, osUnknown)

Or to be really analogous to the Java versions, change 'return' to
'print'.

Is this less extensible than the far more elaborate 'best' Java
version?  My take on it is that that SOO+PS version is certainly the
most over-built, adding layers of complexity that the problem
description certainly doesn't require in order to... well, to what?  It
allows extension, but how is it easier to extend that than the above? 
Why, it requires you to modify two things in two separate files!  It
does allow easier customization of behavior per-OS, but since there's
no need for that, this seems like premature overgeneralization, which
may be the root of most OO programming evil.  :-/

Not that I'm opposed to generalizing a solution in general, but as the
Java examples demonstrate pretty clearly, there is usually a cost
associated.  AndOfCourse those examples did have the unstated
requirement of being "classy" in order to allow the predetermined
hierarchy to be imposed on them.  Which is a complaint I've had with a
large portion of all OO examples that are designed to meet pedagogical
ends without also being required to be sensible.

Remember all those stunningly stupid attempts to shoehorn animals as
classes into a pretty single-inheritance hierarchy of classes?  Pfui!

> Very ugly, but these languages (I refer to the old Basic of the early
> 80's I learned as my first programming language, or Fortran 77 which
> is unfortunately still too much used in the scientific environment)
> don't allow you to do much more than that. You cannot simply *think*
> of another solution.

I thought there were ways to install tables of data in both [fairly]
early Basics as well as FORTRN, but they were both a long time ago and
I may be mixing in memories of improved versions of both (Ratfor,
mostly, in the case of FORTRN).

> On the other hand, was I working in Pascal or C, where "case" and
> "switch" constructs exist, I would have certainly used them. The code
> would have been less ugly, and more adapted to these languages, not
> simply a translation from Basic.

With less excuse, but I follow your thinking.  This problem would
certainly have become an exercise in switch in any C language text.

> When I learned Python I discovered dictionaries and I immediately get
> in love with them; I started using dictionaries from my first
> programs.

I could probbaly tell an anlogous story with a few substitutions. 
"associative arrays" and "AWK" would seem to be the key ones.  :-)

> I want to comment on OOP, too. As a I said in a previous posting, I
> am still in the process of learning OOP. At this state of my
> knowlegde, I tend to think that OOP is a great idea, but sometimes
> overkill and too verbose.

I remain very pleased that I took some time to learn about OOP by
diving into a Smalltalk implementation.  I have always thought that it
was good to be forced to use OO methods, at least for an experienced
procedural programmer, but seeing just how an ideological purity leads
to contrived solutions that just aren't needed in a mixed-mode language
seems more and more relevant these days.

> That's the reason why even if the original
> code in http://csis.pace.edu/~bergin/patterns/ppoop.html used a
> class, I prefer to use a function instead. It seems to me that, for
> simple tasks, functions are still better and easier to grasp.

When there's no reason to invent a class except that the pure OO
language *requires* all functions to be hidden away inside one class or
another...  This is exactly the problem with language purity; I suppose
Lisp would be the poster child for an escape from such problems, but
like you and others who have spoken up here, I have never found it an
approachable one.  Form *is* liberating, at least as long as it manages
not to be excessively restrictive.

Or, as Joel's characters put it, balance is the way...

> Of course objects have their advantages, but if I don't plan to
> inherit from a class doing the job of print_OS_evaluation, why should
> I use a class at all ?

Ah.  Classes are also useful as an organizing principle - they give a
form to the solution that it might not otherwise have, or which anyway
would not be so visible.  A problem whose solution needs one small
lookup table wrapped with very little code behind a single, simple
interface needs little if any such elaboration.  Like any form, classes
can be ill-suited to some problems, so it's good to be able to choose
*not* to use them.

> Functions are shorter and easier to maintain, in my view. Still, the
> biggest issue I have with OOP is a syntactical one: too verbose for
> my taste.

If OOP is too verbose, then either it's being applied where it is not
a good choice - those Java examples fit here - or perhaps the language
manages to support OOP badly.  Or both.