Can a low-level programmer learn OOP?

[Chris Carlen]

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&Electronics Technologist
Sandia National Laboratories CA USA
crcarleRemoveThis at BOGUSsandia.gov
NOTE, delete texts: "RemoveThis" and
"BOGUS" from email address to reply.