Popular conceit about learning programming languages

[Donn Cave]

Quoth Dennis Lee Bieber <wlfraed at ix.netcom.com>:
...
|         Unfortunately, OO is not a language specific feature... It is a whole 
| philosophy of how to look at a problem.
|
|         While not easily done, one /can/ apply OO to even FORTRAN applications.
|
|
|         I'll admit I tend to have difficulty applying OO to abstract things 
| (like records in a database <G>).
|
|         Much easier to learn by applying to real-world objects. Are you 
| familiar with RPN calculators? (mainly because I don't want hassle with 
| the ugliness of arithmetic/algebraic/algebraic-with-parens processing).
...
|         Or a radio... The basic radio has a tuner and an amplifier. A tuner 
| has frequency as a settable parameter, amplifier has volume setting. 
| Fancier radios may extend the object with balance, FM/AM, frequency 
| band settings, etc.

Sure, but that's just the first O in OOP.  Objects have attributes,
anyone can penetrate this mystery.  The question is, given the initial
statement of a programming problem, like ``turn MIDI data into a
printed score'', where do the objects come from and how do they help?
If your grasp of Python is strongly OO, you'll find answers that you
can explain, but you probably won't be able to explain how you found
them.  We don't think by enumerating facts about the tools we use.

Of course Python is totally mainstream as a procedural OOP language,
and one could argue that it's this way because that is the natural
estate of the ordinary programmer mind.  If so, maybe all it takes
is to open the book and see the Object there, and you're on your way,
as you will naturally recognize the promise of this system of thought.

I think there may actually be something to that, but it's not totally
benign.  We do naturally objectify things, and that has its good and
bad points, but even worse, we definitely all have a weakness for a
system that promises a quick boost.  Pretty soon you're doing the OO
thing by reflex, and it feels like you're really quite the software
engineer now, but the reality is that for any substantial problem there
are way more possible bad OO solutions than good ones, and finding a
good one is not any kind of easy.

The procedural aspect of Python is also natural but not necessarily
benign.  This is basically the linear descendent of assembly language,
with variables for registers and other superficial differences;  the
alternative (or one of them, anyway) is the equational reasoning you
find in functional and logic programming languages.  It's arguably
true that the normal programmer can more easily conceive a procedural
solution to a problem, but it is not true that this solution will
naturally be robust and maintainable.  Structured programming relieved
us of some of the scariest opportunities to go wrong, but subroutines
still tend to be a conceptual spaghetti of state variables, and OOP
can bite here when it adds unsuspected side effects that make it even
harder to reason correctly about what you're looking at.

So the first challenge may be to learn to think in Python, but then
you need to learn to think beyond it.

	Donn Cave, donn at u.washington.edu