Can a low-level programmer learn OOP?

**Marc 'BlackJack' Rintsch** · Jul 13 '07, 04:35 PM

Re: Can a low-level programmer learn OOP?

On Fri, 13 Jul 2007 09:06:44 -0700, Chris Carlen wrote:

Perhaps the only thing that may have clicked regarding OOP is that in
certain cases I might prefer a higher-level approach to tasks which
involve dynamic memory allocation. If I don't need the execution
efficiency of C, then OOP might produce working results faster by not
having to worry about the details of memory management, pointers, etc.

That's not something tied to OOP. Automatic memory management is also
possible with procedural languages.

But I wonder if the OOP programmers spend as much time creating classes
and trying to organize everything into the OOP paradigm as the C
programmer spends just writing the code?

Creating classes and organizing the program in an OOP language isn't
different from creating structs and organizing the program in C.

On one side Python is a very OOP language as everything is an object. On
the other side it is possible to write parts of the program in procedural
or even functional style. Python is not Java, you don't have to force
everything into classes.

From my experience Python makes it easy to "just write the code". Easier
than C because I don't have to deal with so much machine details, don't
have to manage memory, don't need extra indexes for looping over lists and
so on. And the "crashes" are much gentler, telling me what the error is
and where instead of a simple "segfault" or totally messed up results.

Ciao,
Marc 'BlackJack' Rintsch

**John Nagle** · Jul 13 '07, 04:55 PM

Re: Can a low-level programmer learn OOP?

Chris Carlen wrote:

Hi:
>
From what I've read of OOP, I don't get it. I have also found some
articles profoundly critical of OOP. I tend to relate to these articles.
>
However, those articles were no more objective than the descriptions of
OOP I've read in making a case. Ie., what objective
data/studies/research indicates that a particular problem can be solved
more quickly by the programmer, or that the solution is more efficient
in execution time/memory usage when implemented via OOP vs. procedural
programming?
>
The problem for me is that I've programmed extensively in C and .asm on
PC DOS way back in 1988. Then didn't program for nearly 10 years during
which time OOP was popularized. Starting in 1999 I got back into
programming, but the high-level-ness of PC programming and the
completely foreign language of OOP repelled me. My work was in analog
and digital electronics hardware design, so naturally I started working
with microcontroller s in .asm and C. Most of my work involves low-level
signal conditioning and real-time control algorithms, so C is about as
high-level as one can go without seriously loosing efficiency. The
close-to-the-machine-ness of C is ideal here. This is a realm that I
truly enjoy and am comfortable with.
>
Hence, being a hardware designer rather than a computer scientist, I am
conditioned to think like a machine. I think this is the main reason
why OOP has always repelled me.

Why?

I've written extensively in C++, including hard real-time programming
in C++ under QNX for a DARPA Grand Challenge vehicle. I have an Atmel
AVR with a cable plugged into the JTAG port sitting on my desk right now.
Even that little thing can be programmed in C++.

You can sometimes get better performance in C++ than in C, because C++
has "inline". Inline expansion happens before optimization, so you
can have abstractions that cost nothing.

If it has state and functions, it probably should be an object.
The instances of the object can be static in C++; dynamic memory
allocation isn't required in C++, as it is in Python.

Python is a relatively easy language, easier than C++, Java,
or even Perl. It's quite forgiving. The main implementation,
CPython, is about 60x slower than C, though, so if you're trying
to implement, say, a rapidly changing digital oscilloscope display,
the result may be sluggish.

John Nagle

**Simon Hibbs** · Jul 13 '07, 06:05 PM

Re: Can a low-level programmer learn OOP?

Chris,

I can fully relate to your post. I trained as a programmer in the 80s
when OOP was an accademic novelty, and didn't learn OOP untill around
2002. However now I find myself naturaly thinking in OOP terms,
although I'm by no means an expert - I'm a sysadmin that writes the
occasional utility. I found learning OOP with Python very easy because
it has such a stripped-down and convenient syntax.

The advantages of OOP aren't in performance or memory, they're in the
fact that OOP simplifies the ways in which we can think about and
solve a problem. OOP packages up the functionality of a program into
logical units (objects) which can be written, debugged and maintained
independently of the rest of the programme almost as if they were
completely seperate programmes of their own, with their own data and
'user inteface' in the form of callable functions (actualy methods).

Here's a realy excellent tutorial on Python that's fun to follow.
Downloading and installing python, and following this tutorial will
probably take about as long as it took to write your post in the first
place. At the end of it you'll have a good idea how OOP works, and how
Python works. Learning OOp this way is easy and painless, and what you
learn about the theory and principles of OOP in Python will be
transferable to C++ if you end up going in that direction.

I hope this was helpful.

Simon Hibbs

**Simon Hibbs** · Jul 13 '07, 06:05 PM

Re: Can a low-level programmer learn OOP?

Sorry, here's the tutorial link:

hetland.org : Instant Python

http://hetland.org/writing/instant-python.html

Simon Hibbs

**Chris Carlen** · Jul 13 '07, 06:15 PM

Re: Can a low-level programmer learn OOP?

John Nagle wrote:

Chris Carlen wrote:[edit]

>Hence, being a hardware designer rather than a computer scientist, I
>am conditioned to think like a machine. I think this is the main
>reason why OOP has always repelled me.

>
Why?

When pointers were first explined to me, I went "Ok." And rather
quickly ideas lit up in my head about what I could do with them.

When I read what OOP is, that doesn't happen. All I think is "what's
the point of this?" "What can this do for me that I can do already with
the procedural way of thinking?" And if it can't do anything new, then
why rearrange my thinking to a new terminology? It's results that
matter, not the paradigm.

I've written extensively in C++, including hard real-time programming
in C++ under QNX for a DARPA Grand Challenge vehicle.

Did the vehicle win?

I have an Atmel
AVR with a cable plugged into the JTAG port sitting on my desk right now.
Even that little thing can be programmed in C++.

Yes.

You can sometimes get better performance in C++ than in C, because C++
has "inline". Inline expansion happens before optimization, so you
can have abstractions that cost nothing.

That's interesting. But why is this any different than using
preprocessor macros in C?

>
If it has state and functions, it probably should be an object.
The instances of the object can be static in C++; dynamic memory
allocation isn't required in C++, as it is in Python.

Why? Why is OOP any better at explaining a state machine to a computer?
I can write state machines all over the place in C, which tend to be
the core of most of my embedded programs. I can write them with
hardcoded logic if that seems like the easy thing to do any the
probability of extensive changes is extremely low. They are extremely
easy to read and to code. I have written a table-driven state machine
with arbitrary-length input condition lists. The work was all in
designing the data structures. The code to update the state machine was
about 4 lines.

Why would OOP be better? Different is not better. Popular is not
better. What the academics say is not better. Less lines of code might
be better, if the priority is ease of programming. Or, less machine
execution time or memory usage might be better, if that is the priority.

Until I can clearly understand why one or the other of those goals might
better be realized for a given problem with OOP vs. procedures, I just
don't get it.

I will keep an open mind however, that until I work with it for some
time there is still the possibility that I will have some light go on
about OOP. So don't worry, I'm not rejecting your input.

Python is a relatively easy language, easier than C++, Java,
or even Perl. It's quite forgiving. The main implementation,
CPython, is about 60x slower than C, though, so if you're trying
to implement, say, a rapidly changing digital oscilloscope display,
the result may be sluggish.

Yes, I certainly wouldn't consider Python for that.

Thanks for your comments.

--
Good day!

_______________ _______________ __________
Christopher R. Carlen
Principal Laser&Electroni cs Technologist
Sandia National Laboratories CA USA
crcarleRemoveTh is@BOGUSsandia. gov
NOTE, delete texts: "RemoveThis " and
"BOGUS" from email address to reply.

**Evan Klitzke** · Jul 13 '07, 06:35 PM

Re: Can a low-level programmer learn OOP?

On 7/13/07, John Nagle <nagle@animats. comwrote:

You can sometimes get better performance in C++ than in C, because C++
has "inline". Inline expansion happens before optimization, so you
can have abstractions that cost nothing.

This is a bit off topic, but inline is a keyword in C since C99.

--
Evan Klitzke <evan@yelp.co m>

**Neil Cerutti** · Jul 13 '07, 07:35 PM

Re: Can a low-level programmer learn OOP?

On 2007-07-13, Chris Carlen <crcarleRemoveT his@BOGUSsandia .govwrote:

John Nagle wrote:

>You can sometimes get better performance in C++ than in C,
>because C++ has "inline". Inline expansion happens before
>optimization , so you can have abstractions that cost nothing.

>
That's interesting. But why is this any different than using
preprocessor macros in C?

This is OT, however: inline functions have a few benefits over
preprocessor macros.

1. They are type-safe.
2. They never evaluate their arguments more than once.
3. They don't require protective parentheses to avoid precedence errors.
4. In C++, they have the additional benefit of being defined in a
namespace, rather than applying globally to a file.

As an experienced C programmer you're probably used to coping
with the problems of preprocessor macros, and may even take
advantage of their untyped nature occasionally. Even C++
programmers still use the advisedly.

I will keep an open mind however, that until I work with it for
some time there is still the possibility that I will have some
light go on about OOP. So don't worry, I'm not rejecting your
input.

In my opinion OOP is usefully thought of as a type of design
rather than a means of implementation. You can implement an OO
design in a procedural langauge just fine, but presumably an OO
programming language facilitates the implementation of an OO
design better than does a procedural language.

Going back to the stack machine question, and using it as an
example: Assume you design your program as a state machine.
Wouldn't it be easier to implement in a (hypothetical)
state-machine-based programming language than in a procedural
one? I think John was insinuating that a state-machine is more
like an object than it is like a procedure.

--
Neil Cerutti

**Bruno Desthuilliers** · Jul 13 '07, 08:05 PM

Re: Can a low-level programmer learn OOP?

Chris Carlen a écrit :

Hi:
>
From what I've read of OOP, I don't get it. I have also found some
articles profoundly critical of OOP. I tend to relate to these articles.
>
However, those articles were no more objective than the descriptions of
OOP I've read in making a case. Ie., what objective
data/studies/research indicates that a particular problem can be solved
more quickly by the programmer, or that the solution is more efficient
in execution time/memory usage when implemented via OOP vs. procedural
programming?

None. Definitively. wrt/ developper time and memory, it's mostly a
matter of fit-your-brains. If it does, you'll find it easier, else
choose another programming style. wrt/ cpu time and memory, and using
'low-level' languages (C/C++/Pascal etc) OO is usually worse than
procedural for simple programs. For more complex ones, I'd say it tends
to converge since these programs, when written procedurally, usually
rely on many abstraction/indirection layers.

The problem for me is that I've programmed extensively in C and .asm on
PC DOS way back in 1988. Then didn't program for nearly 10 years during
which time OOP was popularized. Starting in 1999 I got back into
programming, but the high-level-ness of PC programming and the
completely foreign language of OOP repelled me. My work was in analog
and digital electronics hardware design, so naturally I started working
with microcontroller s in .asm and C. Most of my work involves low-level
signal conditioning and real-time control algorithms, so C is about as
high-level as one can go without seriously loosing efficiency.

You may still want to have a look on some more functional languages like
Haskell, OCaml or Erlang. But if you find OO alien, I doubt you'll have
a strong feeling for functional programming.

The
close-to-the-machine-ness of C is ideal here. This is a realm that I
truly enjoy and am comfortable with.
>
Hence, being a hardware designer rather than a computer scientist, I am
conditioned to think like a machine. I think this is the main reason
why OOP has always repelled me.

OTOH, OO is about machines - at least as conceveid by Alan Key, who
invented the term and most of the concept. According to him, each object
is a (simulation of) a small machine.

Perhaps the only thing that may have clicked regarding OOP is that in
certain cases I might prefer a higher-level approach to tasks which
involve dynamic memory allocation.

While OO without automatic memory management can quickly become a major
PITA, OO and GC are two orthogonal concepts - some languages have
builtin support for OO but nothing specific for memory management
(ObjectPascal, C++, ObjectiveC), and some non-OO languages do have
builtin memory management (mostly but not only in the functional camp).

If I don't need the execution
efficiency of C, then OOP might produce working results faster by not
having to worry about the details of memory management, pointers, etc.

It's not of feature of OO per se. But it's clear that not having (too
much) to worry about memory management greatly enhance productivity.

But I wonder if the OOP programmers spend as much time creating classes
and trying to organize everything into the OOP paradigm as the C
programmer spends just writing the code?

Don't you design your programs ? AFAICT, correct design is not easier
with procedural programming.

Now to answer your question, I'd say it depends on your experience of
OO, and of course of the kind of OO language you're using. With
declaratively statically typed languages - like C++, Java etc - you are
forced into a lot of upfront design (way too much IMHO). Dynamic
languages like Smalltalk, Python or Ruby are much more lightweight in
this area, and tend to favor a much more exploratory style - sketch a
quick draft on a napkin, start coding, and evolve the design while
you're coding.

And FWIW, Python doesn't *force* you into OO - while you'll be *using*
objects, you can write most of your code in a procedural way, and only
"fall down" into OO for some very advanced stuff.

Ultimately I don't care what the *name* is for how I program. I just
need to produce results.

Indeed !-)

So that leads back to objectivity. I have a
problem to solve, and I want to find a solution that is as quick as
possible to learn and implement.
>
Problem:
>
1. How to most easily learn to write simple PC GUI programs

GUI are one of the best (and more successfull) application of OO - and
as a matter of fact, even GUI toolkits implemented in plain C tend to
take an OO approach (GTK+ being a clear example, but even the old
Pascal/C Mac GUI API does have a somewhat "object based" feeling).

that will
send data to remote embedded devices via serial comms, and perhaps
incorporate some basic (x,y) type graphics display and manipulation
(simple drawing program). Data may result from user GUI input, or from
parsing a text config file. Solution need not be efficient in machine
resource utilization. Emphasis is on quickness with which programmer
can learn and implement solution.

So what you want is an hi-level, easy to learn language with a rich
collection of libraries. The Goodnews(tm) is that Python is one of the
possible answers.

2. Must be cross-platform: Linux + Windows.

Idem. You can even add most unices and MacOS X to the list.

This factor can have a big
impact on whether it is necessary to learn a new language, or stick with
C. If my platform was only Linux I could just learn GTK and be done
with it. I wouldn't be here in that case.
>
Possible solutions:
>
Form 1: Use C and choose a library that will enable cross-platform GUI
development.
>
Pro: Don't have to learn new language.
Con: Probably will have difficulty with cross-platform implementation
of serial comms. This will probably need to be done twice. This will
waste time.

Con: C is a low-level language (not a criticism - it has been designed
so), which greatly impact productivity.
Con: the only serious C (not++) cross-platform GUI toolkit I know is
GTK+, which is less cross-platform than wxWidgets, and *is* OO.

Form 2: Use Python and PySerial and TkInter or wxWidgets.

I'd probably go for wxWidgets.

Pro: Cross-platform goal will likely be achieved fully.

Very likely. There are a couple of things to take care of, but nothing
close to what you'd have to do in C.

Have a
programmer nearby with extensive experience who can help.
Con: Must learn new language and library.

Yes, obviously. The (other) GoodNews(tm) is that, according to most
estimations, an experimented programmer can become productive in Python
in a matter of weeks at worst (some manage to become productive in a few
days). This won't mean you'll master the language and use it at its
best, but don't worry, you'll get things done, and perhaps in less time
than with C.

Must possibly learn a
completely new way of thinking (OOP)

Not necessarly. While Python is OO all the way down - meaning that
everything you'll work with will be an object (functions included) -, it
doesn't *force* you into OO (IOW : you don't have to define classes to
write a Python program). You can as well use a procedural - or even
somewhat functional - approach, and most Python programs I've seen so
far are usually a mix of the three.

not just a new language syntax.

You forgot one of the most important part of a language : idioms. And
it's definitively *not* idiomatic in Python to use classes when a
simpler solution (using plain functions and modules) is enough.

This might be difficult.

Not necessarily that much.

Form 3: Use LabVIEW
>
Pro: I think that the cross-platform goal can be met.
Con: Expensive. I would prefer to use an Open Source solution. But
that isn't as important as the $$$. I have also generally found the 2D
diagrammatical programming language of "G" as repelling as OOP. I
suspect that it may take as much time to learn LabVIEW as Python.

I don't have much knowledge of LabVIEW so I can't comment on this. But I
remember a thread here about G, and I guess you'll find Python much more
familiar - even if you'll need some 'thinking adjustment' to grok it.

In
that case the time spent on Python might be better spent since I would
be learning something foundational as opposed to basically just learning
how to negotiate someone's proprietary environment and drivers.

IMHO, the biggest gain (in learning Python vs LabVIEW) is that you'll
add a very valuable tool to your toolbox - the missing link between C
and shell scripts.

>
Comments appreciated.
>

HTH

**Bruno Desthuilliers** · Jul 13 '07, 08:25 PM

Re: Can a low-level programmer learn OOP?

Chris Carlen a écrit :
(snip)

>
Why? Why is OOP any better at explaining a state machine to a computer?

I don't know if it's "better", but state machines are the historical
starting point of OO with the Simula language.

I can write state machines all over the place in C,

And even in assembler - so why use C ?-)

which tend to be
the core of most of my embedded programs. I can write them with
hardcoded logic if that seems like the easy thing to do any the
probability of extensive changes is extremely low. They are extremely
easy to read and to code. I have written a table-driven state machine
with arbitrary-length input condition lists. The work was all in
designing the data structures.

Which is another approach to OO. When programming in C, you do use
structs, don't you ? And you do write functions operating on instances
of these structs ? And possibly, turn these structs into ADT ? Well, one
possible definition of "objects" is "ADT + polymorphism".

Why would OOP be better?

Whoever pretend it's absolutely "better" should be shot down. I do find
OO *easier* than pure procedural programming, but I started programming
with mostly OO (or at least object-based) languages, and only then
learned pure procedural languages (and then bits of functional
programming). It's not a matter of being "better", it's a matter of what
style fits your brain. If OO doesn't fit your brain, then it certainly
won't be "better" *for you*.

Different is not better. Popular is not
better. What the academics say is not better. Less lines of code might
be better, if the priority is ease of programming.

and maintenance, and robustness (AFAICT, the defect/LOC ratio is
somewhat constant whatever the language, so the less code the less bugs).

Or, less machine
execution time or memory usage might be better, if that is the priority.

Indeed.

Until I can clearly understand why one or the other of those goals might
better be realized for a given problem with OOP vs. procedures, I just
don't get it.

Seems quite sane.

I will keep an open mind however, that until I work with it for some
time there is still the possibility that I will have some light go on
about OOP. So don't worry, I'm not rejecting your input.
>

> Python is a relatively easy language, easier than C++, Java,
>or even Perl. It's quite forgiving. The main implementation,
>CPython, is about 60x slower than C, though,

This is a very simplistic - and as such, debatable - assertion IMHO. On
my Linux box, a cat-like program is hardly faster in C than in Python
(obviously since such a program is IO bound, and both implementations
will use the native IO libs), and for quite a few computation-heavy
tasks, there are Python bindings to highly optimised C (or C++) libs. So
while it's clear that Python is not about raw execution speed, it's
usually quite correct for most applicative tasks. And when it isn't,
well, it's always possible to recode the critical parts in Pyrex or C.

**samwyse** · Jul 13 '07, 08:25 PM

Re: Can a low-level programmer learn OOP?

On Jul 13, 1:05 pm, Chris Carlen <crcarleRemoveT ...@BOGUSsandia .gov>
wrote:

John Nagle wrote:

Chris Carlen wrote:[edit]

Hence, being a hardware designer rather than a computer scientist, I
am conditioned to think like a machine. I think this is the main
reason why OOP has always repelled me.

>

Why?

>
When pointers were first explined to me, I went "Ok." And rather
quickly ideas lit up in my head about what I could do with them.
>
When I read what OOP is, that doesn't happen. All I think is "what's
the point of this?" "What can this do for me that I can do already with
the procedural way of thinking?" And if it can't do anything new, then
why rearrange my thinking to a new terminology? It's results that
matter, not the paradigm.

What can this do for me that I can do already with the procedural way
of thinking? Absolutely nothing; it's all Turing machines under the
hood.

Why rearrange my thinking to a new terminology? Because new
terminologies matter a lot. There's nothing that you can do with
pointers that can't be done with arrays; I know because I wrote a lot
of FORTRAN 77 code back in the day, and withouy pointers I had to
write my own memory allocation routines that worked off of a really
big array.

Likewise, there's nothing that you can do in C that can't be done with
C++ (especially since C++ was originally a preprocessor for C);
however C++ will keep track of a lot of low-level detail for you so
you don't have to think about it. Let's say that you have an embedded
single-board computer with a serial and a parallel port. You probably
have two different routines that you use to talk to them, and you have
to always keep track which you are using at any given time.

It's a lot easier to have a single CommPort virtual class that you use
in all of your code, and then have two sub-classes, one for serial
ports and one for parallel. You'll be especially happy for this when
someone decides that as well as logging trace information to a
printer, it would be nice to also log it to a technician's handhelp
diagnostic device.

**Chris Carlen** · Jul 13 '07, 08:35 PM

Re: Can a low-level programmer learn OOP?

Neil Cerutti wrote:

Going back to the stack machine question, and using it as an
example: Assume you design your program as a state machine.
Wouldn't it be easier to implement in a (hypothetical)
state-machine-based programming language than in a procedural
one? I think John was insinuating that a state-machine is more
like an object than it is like a procedure.

I think at this point, I should stop questioning and just learn for a while.

But regarding state machines, I had probably written a few in C the past
before really understanding that it was a state machine. Much later I
grasped state machines from digital logic. Then it became much clearer
how to use them as a tool and to code them intentionally.

Once I have written a state table, I can implement using flip-flops and
gates or in C as either a state variable and a switch statement or
something table driven. The switch code can be written as fast as I can
read through the state table. That's the easiest implementation, but
the least easy to change later unless it's fairly small.

I will be eager to see how to do this in Python.

I have found the comments in response to my doubts about OOP very
encouraging. I will do some learning, and come back when I have more
Python specific problems...

Thanks for the input!

--
Good day!

_______________ _______________ __________
Christopher R. Carlen
Principal Laser&Electroni cs Technologist
Sandia National Laboratories CA USA
crcarleRemoveTh is@BOGUSsandia. gov
NOTE, delete texts: "RemoveThis " and
"BOGUS" from email address to reply.

**Chris Carlen** · Jul 13 '07, 08:35 PM

Re: Can a low-level programmer learn OOP?

Simon Hibbs wrote:

Sorry, here's the tutorial link:
>

hetland.org : Instant Python

http://hetland.org/writing/instant-python.html

>
>
Simon Hibbs

Thanks Simon. Actually, that's the tutorial that I've started with.

Your comments are encouraging. I'll keep learning.

--
Good day!

_______________ _______________ __________
Christopher R. Carlen
Principal Laser&Electroni cs Technologist
Sandia National Laboratories CA USA
crcarleRemoveTh is@BOGUSsandia. gov
NOTE, delete texts: "RemoveThis " and
"BOGUS" from email address to reply.

**Chris Carlen** · Jul 13 '07, 08:45 PM

Re: Can a low-level programmer learn OOP?

Bruno Desthuilliers wrote:

Chris Carlen a écrit :
>[edit]

> Must possibly learn a completely new way of thinking (OOP)

>
Not necessarly. While Python is OO all the way down - meaning that
everything you'll work with will be an object (functions included) -, it
doesn't *force* you into OO (IOW : you don't have to define classes to
write a Python program). You can as well use a procedural - or even
somewhat functional - approach, and most Python programs I've seen so
far are usually a mix of the three.
>

>not just a new language syntax.

>
You forgot one of the most important part of a language : idioms. And
it's definitively *not* idiomatic in Python to use classes when a
simpler solution (using plain functions and modules) is enough.

I see. That's very promising. I guess some articles I read painted a
picture of religiousity among OOP programmers. But that is not the
impression I am getting at all on the street.

IMHO, the biggest gain (in learning Python vs LabVIEW) is that you'll
add a very valuable tool to your toolbox - the missing link between C
and shell scripts.

Thanks for the comments!

--
Good day!

_______________ _______________ __________
Christopher R. Carlen
Principal Laser&Electroni cs Technologist
Sandia National Laboratories CA USA
crcarleRemoveTh is@BOGUSsandia. gov
NOTE, delete texts: "RemoveThis " and
"BOGUS" from email address to reply.

**Bruno Desthuilliers** · Jul 13 '07, 09:15 PM

Re: Can a low-level programmer learn OOP?

Chris Carlen a écrit :

Bruno Desthuilliers wrote:
>

>Chris Carlen a écrit :

>

>[edit]

>

>> Must possibly learn a completely new way of thinking (OOP)

>>
>>
>Not necessarly. While Python is OO all the way down - meaning that
>everything you'll work with will be an object (functions included) -,
>it doesn't *force* you into OO (IOW : you don't have to define classes
>to write a Python program). You can as well use a procedural - or even
>somewhat functional - approach, and most Python programs I've seen so
>far are usually a mix of the three.
>>

>>not just a new language syntax.

>>
>>
>You forgot one of the most important part of a language : idioms. And
>it's definitively *not* idiomatic in Python to use classes when a
>simpler solution (using plain functions and modules) is enough.

>
>
I see. That's very promising. I guess some articles I read painted a
picture of religiousity among OOP programmers.

That's alas a common disease - I'd say the best way to be definitively
disgusted from OO is to read comp.lang.objec t :(

But that is not the
impression I am getting at all on the street.

Heck. As you said, the important is to get things done. And I guess
that's why we all (here) love Python. Last time I had to work on a
Pascal program (actually Delphi's ObjectPascal, but the whole thing was
almost caricaturally procedural), I found myself having to write tens of
lines of code for thing that would have been no-brainer one-liners in
Python, and define new types (records - Pascal's structs) where Python's
builtin dict type would have do the trick. It's not a matter of
procedural vs OO vs functional, it's a matter of using the appropriate
tool for the job.