Can a low-level programmer learn OOP?

[Bruno Desthuilliers]

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.