python without OO

[Dave Benjamin]

Davor wrote:
> Is it possible to write purely procedural code in Python, or the OO
> constructs in both language and supporting libraries have got so
> embedded that it's impossible to avoid them? Also, is anyone aware of
> any scripting language that could be considered as "Python minus OO
> stuff"? (As you can see I'm completely new to Python and initially
> believed it's a nice&simple scripting language before seeing all this
> OO stuff that was added in over time)

Many people have answered your question already, but I thought I would 
share my opinion as well, since I think I understand where you are 
coming from.

What attracted me to Python was not OO at all but the fact that it was 
somewhat similar to PHP (which I was using heavily at the time) but 
allowed me to encode certain higher-order programming techniques that 
PHP simply could not express. In short, I had become interested in 
functional programming after reading David Mertz's "Charming Python" 
tutorials, and after x attempts at trying to port the ideas to PHP, I 
finally gave up in frustration and started learning Python.

At the time, I was decidedly anti-OO. I grew up around a very liberal, 
punk-rock, nonconformist culture, and the amount of hype around OO made 
it too easy to hate (and, I suppose, it still does). PHP at the time was 
90% procedural; the prevaling attitude (which seems to have changed with 
the advent of PHP5) was that procedural code is all you need to solve 
most problems. With web scripting, it kind of makes sense, because 
(IMHO) objects really don't have much value unless you can hold onto 
them long enough for them to be useful, and many web scripts just pipe 
data from one place to another. Packing the data into objects is kind of 
like putting your possessions into boxes so that you can move them from 
one room to another and immediately unpack.

So, I guess you could say, I learned Python in spite of its rich support 
for OO. =)

It wasn't until I had to implement a large (to me), complex, graphical 
user interface, that I finally had to get off of my soapbox and realize 
that I had no better way to create sophisticated GUIs than OO. There are 
surely non-OO ways to build fancy GUIs, like functional-reactive 
programming, but a) I don't understand them, and b) I had to get my 
project done, and used the tools I had and the techniques I knew.

At that time, I started learning about Smalltalk and Alan Kay's emphasis 
on the "messaging" aspect of OO, and it started making a lot more sense. 
One of the most difficult tasks sometimes is getting various parts of 
the screen to update when the user changes a field or clicks a 
button--in a way that is manageable and doesn't devolve into spaghetti.

Aside from GUIs, however, I am rarely confronted with a task where I 
*need* OO. As a method for encoding abstract data types, it works, but 
it seems like more fashion than substance. As many have pointed out, the 
difference between "method(obj, args)" and "obj.method(args)" is subtle, 
and often inconsequential. In Python, you can program with just modules 
and functions/procedures, and never bother with the fact that you are 
using objects. Sure, a module is an object, and so is a procedure, but 
it's not all up in your face like, say, Java's arcane restriction that 
everything belong to some class.

It has been said of Perl programmers that they often dislike 
abstraction. Sometimes, I really sympathize with this viewpoint. I hate 
having to use a class that offers no value to the problem whatsoever, 
merely because an API is hard-wired to use instances of that class. No 
abstraction can often be better than a bad abstraction, and when it 
comes to debugging, the last thing you want is a bunch of black boxes.

These days, I do use classes and objects in Python, but mainly as a code 
organization technique, and only when I actually want my code organized 
that way. I tend to start with the problem at hand, building procedures 
to remove redundancy and keep my code small and simple. If I start 
noticing that a lot of procedures revolve around a particular data 
structure, I refactor them into a class. This way, I avoid creating 
abstractions that don't fit. It's much more mechanical than any feigned 
attempt at "modeling the real world".

I think that functional programming (FP) is a very powerful methodology 
that can solve a lot of the same problems as OO, and does some things a 
lot better. FP and OO can live in harmony to some extent, but there are 
some places where they contradict each other. For instance, FP offers a 
mind-blowingly powerful tool called pattern matching, which is like a 
switch/case statement on steroids. OO dogma insists that this "violates 
encapsulation", and that any form of switch/case is evil... replace 
conditional with polymorphism... replace conditional with 
polymorphism... replace conditional with polymorphism... repl<hic> On 
the other hand, implementing something as seemingly simple as a 
"__str__" method in functional languages can be surprisingly non-trivial.

The lesson to be learned here is that each methodology (including 
strctures/procedural) has its strong points and weak points, and there 
are always tradeoffs to be made. OO's biggest strong point is that a lot 
of people grok it, so it's a fashionable and friendly user interface for 
a programmer. Python in particular emphasizes this point with its 
no-nonsense, lightweight approach to defining classes and using objects.

However, and this really the main point I wanted to make: *no* paradigm 
is sufficient to solve any interesting problem. I have gotten sucked 
into coutless language and paradigm pissing matches only to go back to 
my desk and try to finish a project I'm working on and realize that 
(gasp!) programming is still hard. It never stopped being hard! And 
sometimes the methodologies just create additional work (cf. jwz's 
comment on regular expressions: "now you have two problems").

The best way to crack through tough problems is to learn as many methods 
and techniques as you can, and develop an intuition for "the right tool 
for the job". What matters most is that you solve the problem at hand, 
in a way that people can hopefully understand and maintain later.

Good luck,
Dave