[Coco] OO programming - [Was]:Emulator

[Fedor Steeman]

Hi again,

@MM:
> > FWIW I don't think we're ever going to agree or convince one another...
> ;)
>

On the contrary, I have to disagree! ;-)
I think we are closing in on a consensus, but we just do not realize it yet!
I see you both actually confirming a lot of the points I made earlier,
whilst maintaining disagreement. :-D


> @AW:
> "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,


Well, see? We actually agree on this! Abstraction in general and, may I add,
OO specifically, do 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.
>

Judging from your own explanations, you show that you _do_ have an idea how
abstraction relates to easier programming, namely "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".
Wrapping up all trivial logic into their own little black boxes, makes a
huge difference for managing your code.


> 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.


I was merely using hardware abstraction as an example. More broadly, I meant
wrapping up trival logic. I think we understand each other on this issue.


> @MM:
> > 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.
>

Perhaps only, or perhaps not. I agree that it is an issue to debate whether
OO is suitable for developing a CoCo emulator.


> @MM:
> >> 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
>
@AW:
> 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.


Obviously. But if we want to compare the two paradigms then that factor (the
skill of the programmer) should be kept the same. I never said that OO is a
magic bullet that makes everything automatically easier. But, depending on
the application, it can have major advantages, as both of you more or less
admit.


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

It does sound to my ears that you guys find all that modelling and
conceptualizing a lot of fuzz and rather want to go straight to the fun part
of programming and getting things to work. I can well understand as I am
also often tempted in that direction. However, from my own, admittedly
relatively limited, experience with programming higher level applications, I
always end up regretting it. In contrast, I experience that I end up saving
a lot of development and debugging time in the long run. If I then also
apply unit testing then I feel even more in control. Perhaps you also find
unit testing too much of a fuzz to bother with? :-)

Anyways, if this were just limited to my own personal experiences then you
may just shrug your shoulders, but OO D/P has become a major force in the
industry and the recommended practice as endorsed by major system
development gurus. So I am not just fooling myself in any case.

>
>  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 :)
>

If a methodology can keep bad programmers on the right track, imagine what a
highly-skilled programmer might achieve with it! Wait, no need to imagine,
it is alreay happening all around us! :-)


> 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.
>

Hold on there! I think you missed my earlier remark that procedural
languages may be well suite for hardware-focused programming, whereas OO
languages are more suitable for human-focused programming. Obviously then,
an OS Kernel is best written in a procedural language, whereas a business
application, subject to a large number of business rules and specifications,
addressing real world problems and armies of irrational users, is best
served with an OO design model.

Say, I wonder what something like OpenOffice is written in, hmmm.....

http://www.ohloh.net/p/openoffice/analyses/latest

Well, waddayaknow! C++ and Java abound! :-D

Also, one must not forget that the Linux kernel was written over 18 years
ago, before OO became a factor to reckon with, and, interestingly, most
Linux distributions today encourage you to write your non-kernel
contributions in other languages than C (Java for Red Hat, Python for Yellow
Dog and Debian, Ubuntu...)

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
>

Can't blame Paul Graham for protecting his brain child. Yet I would like to
see him write an Office package in Lisp. :-)

For each article you can find criticising the Object Oriented paradigm by a
self-confessed non-user, and thus probably not fully understanding it, you
can find long books describing its benefits. Martin Fowler, Craig Larman,
Eric Gamma, Kent Beck, Alan Kay, Bruce Eckel, Fred Brooks. Can all these
guys (two of whom have received Turing Awards for their contributions to
Computer Science) be simply wrong about the object oriented paradigm,
because they're mediocre programmers who work for IBM? Doesn't really sound
like a reasonable arguement to me. :-)


> @AW:
> 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.
>
>@MM:
> 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.

Fair enough. Admittedly, an emulator like this is not like a bloated
business application and it sounds sensible enough to mimic hardware
processes with hardware near procedures. Not in the least because they are
timing-critical. It would probably not have been a good idea in the early
nineties, but nowadays, I would find it odd that this would be an issue when
running it on a multi-core CPU with several Gigs of RAM. I mean if it can
run Vista, it can run anything! :-)

> 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.

Nice to see you confirming the benefits of OO design. :-)
I would dare venture that at least re-use, low coupling, maintainability,
and the resulting flexibility can be of benefit too when developing a CoCo
emulator. E.g. the easy switching of one component with another (say, a
SAM+VDG with a GIME?). Heck, with a loosely coupled bag of finished objects
we construct all kinds of different hardware configurations. It would be
like playing with Lego! Want a CoCo4 emulator? Should we trying SockMaster's
3 x 6309-option or combine a 68000 with some custom graphics chip? How about
emulating a TomCat TC-9 or TC-70? We have got most components already done!
I can only see infinite possibilties. Besides the perhaps steep initial
stages, you may eventually end up saving time and speed up development,
which after all is the whole objective of OO design!

Thus, all these so-called "inefficiences", which mainly pertain performance
and overhead, would be nullified by modern hardware and the benefits of the
OO approach. What's more, it simultaneously provides a way of better
understanding what makes a CoCo "tick". Now don't get me wrong: Of course
there should be limits to how deeply the machine logic should be
implemented. But just saying beforehand that it won't fly sounds a bit
premature. Even worse: I don't understand why anyone would discourage any
positive initiative in our small community. On the other hand, it does sound
like a challenge to my ear that I would most certainly want to try to meet,
had I ample time and resources.

Regards,

Fedor Steeman

BTW: In all these discussions, I forgot to stress that although I hopped in
on a thread with the OP criticizing existing emulators, I in no way endorse
this kind of negativity when dealing with any project that people do in
their spare time for the fun of it and for the benefit of people sharing
their interests.