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 [EMAIL PROTECTED] NOTE, delete texts: "RemoveThis" and "BOGUS" from email address to reply. -- http://mail.python.org/mailman/listinfo/python-list