[Coco] OO programming - [Was]:Emulator

[Aaron Wolfe]

On Mon, Nov 2, 2009 at 6:17 PM, Mark McDougall <msmcdoug at iinet.net.au> wrote:
> Fedor Steeman wrote:
>
>> Boy, I sure saw that one coming! :-)
>
> Heh, and I'm sure this discussion has the potential to spiral out of control
> and run for weeks if we allow it. But I'd at least like to respond to a few
> points at the risk of annoying others...
>
> FWIW I don't think we're ever going to agree or convince one another... ;)
>
>> Well, for one thing OO/D&P helps the programmer focus on the problem
>> domain, rather than on trivial hardware or platform-related requirements
>> that in our day and age are or should be abstracted away anyways.
>

"Abstraction" in OO terms has nothing to do with making it easier to
write for the hardware platform you're running your code on.  In OO
design, abstraction is making your code able to perform operations
without directly accessing or even understanding the details of the
underlying data structures in other parts of the program.  This does
have benefits in large, complex programs, but how this relates to
things "that in our day and age are or should be abstracted away
anyways" I have no idea.

Abstraction of low level system details is not an inherent
characteristic of OO design.   Both procedural and OO languages
provide libraries for this type of thing.  The standard C libraries
are one example of this.  In Perl, many libraries can be called either
as objects or as procedures.  They are functionally equivalent.  The
design paradigm is use has no effect on the abstract functionality
available.

> That may be true if there is an appropriate framework already in place that
> is applicable to the problem domain. In the case of a coco emulator, the
> host GUI would be a good (and perhaps only) example.
>
>> long run, it will help the body of code remain easier to overview, easier
>> to understand, easier to develop, easier to manage and easier to change
>> and expand, especially when applying well-established Design Patterns.
>
> Only if well-written, and only if the OO paradigm is applicable to the
> problem. OO is not a magic bullet - it is not _automatically_ easier.
>

Mark is quite right.  OO programming can be quite tedious and give
mediocre results even when done correctly.

Easier to overview and understand.. sometimes.. maybe.  There are
plenty of examples both of good and bad code done in any given
programming style.  The skill and dedication of the programmer(s) has
vastly more influence on this than the technique used.  I'll admit
that one area where OO stands out is in keeping bad programmers "on
the rails" and isolating their mistakes from good code.  It's often
harder to make code that breaks other code with OO design.  Whether
this is actually a good thing or not in the long run, I'm not sure :)

Easier to manage, change, expand.. probably, but only at scale.  In a
large system written by many programmers over many years, OO design
may help you achieve these things.  This is not to say that a properly
designed and managed procedural system could not also be changed and
expanded in an effective way.  I'm familiar with one project that has
thousands of loosely associated, part time contributors, a project
containing over 12 million lines of procedural code.  It turned out to
be one of the most stable, powerful operating system kernels in
existence today: Linux.

Author/hacker Paul Graham has written what I think is a very accurate
essay on OO, which speaks to many of the points we discussed here:
http://www.paulgraham.com/noop.html

>> Perhaps so, but I can see major advantages in abstracting away logic
>> dealing with display and I/O and at the same time implementing the
>> emulated system's machine logic as the signal-exchanging objects that
>> they in reality are.
>

Abstracting display and I/O can be accomplished without OO.
Abstraction and common library/module calls are not OO innovations.
The C programmers working on MESS, for example, do not write code that
directly manipulates your graphics card or disk controller.   there
are many layers of abstraction at work here.  OO design has little if
anything to do with these types of issues.

Implementing the "objects" in your computer (cpu/ram/controllers/etc)
as objects is a cute idea, but the paradigm works only at the simplest
level.  each physical object in your computer would require many
different objects from many classes to implement in an OO design.   An
emulator is a sort of extreme case where OO design's inefficiencies
become more apparent than in an average program.  You're simulating a
computer with another computer.. simple, direct translation of aspects
from one environment to the other is very effective.  creating and
manipulating complex logical structures is unnecessary and extremely
inefficient.

> You touch on the host GUI as I suspected and yes, depending on the host OS
> and cross-platform goals that may be true. But I suspect that the
> implementation of the coco logic may not benefit as much as you hope from OO
> design. For a single-target emulation, you're probably going to spend a
> _lot_ more time architecting and implementing the framework to support your
> ideal design, negating any benefits and in fact complicating the software.
>
> The major benefits in OO design include re-use, loose coupling and
> maintainability - important benefits on large systems with many different
> components interacting and being used simultaneously by several other system
> components. Here abstraction is a huge plus, being able to hide
> implementation details behind a stable and well-known interface as the
> system grows and functionality is added.
>

Again Mark is right on the money.  OO is a great tool in large systems
where the quality of the programmers is unknown and somewhat
uncontrollable, there are different departments or agencies involved,
or the code is expected to be reused in several projects.   In these
types of systems, performance is not a principle goal.  Each party
implements their interfaces to the specifications, and the beast
lumbers lazily along.  When something breaks, it's easy to figure out
who to blame.  The good part is that nobody ever has to know how the
whole thing works, thanks to OO design.  The bad part is that nobody
ever gets to know how the whole thing works :)

> I don't really see where any of this is much use to a coco emulator. And of
> course it comes with a cost - increased development effort (code size) and
> decreased performance (as you concede).
>

ditto

>> A poor craftsman blames his tools. Or: bad craftsmanship is more easily
>> blamed on the craftsman than on his tools. So that argument is not really
>>  valid. :-)
>
> I didn't blame OO at all. My point was that a bad OO program is just as bad
> - if not worse - than a bad procedural program. And I've seen both, trust
> me. So your assessment of my "argument" is not really valid! :-)
>
>> Thanks, I will take your encouragement to heart and hope that I (or
>> someone else) some day will be able to come up with something new and
>> exciting for the community! Whatever it may be and however it may have
>> been developed! :-)
>
> At the end of the day, it doesn't _really_ matter what tools are used, as
> long as they are used properly. And of course, everyone has a toolset with
> which they are more productive and skilled. Myself, I've worked on PC
> business applications in C++, through device drivers in C, down to coding
> assembler on micros and soft-core processors in FPGAs. I try to choose the
> most appropriate tools for the job at hand - though I must admit that C is
> always my fall-back language of choice for a lot of quick-n-dirty jobs that
> perhaps other languages (perl, sed/awk) would be more appropriate.
>
> That said, personally, I probably wouldn't choose to do an OO Coco emulator.

one last ditto :)
-Aaron

>
> Regards,
>
> --
> |              Mark McDougall                | "Electrical Engineers do it
> |  <http://members.iinet.net.au/~msmcdoug>   |   with less resistance!"
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>