[Coco] OO programming - [Was]:Emulator

[Aaron Wolfe]

On Tue, Nov 3, 2009 at 6:36 PM, Fedor Steeman <petrander at gmail.com> wrote:
> 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.
>

Agreed, but whether these black boxes are objects or functions or
modules or libraries makes little difference.  When you have to write
all or most of the black boxes yourself, as I would expect in a Coco
emulator project, it makes even less difference how they are packaged.

I am a huge fan of abstraction, its a fundamental CS concept that
predates OO by some tens of years.  I don't see the many benefits a
properly layered system provides as something one would attribute to
OO design, since abstraction is found in practically every system
regardless of whether it is object oriented.

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

Unit testing is great.  It's yet another concept that predates and
continues to exist outside of OO design.  I have a general feeling you
might be attributing things to object orientedness that are in fact
not exclusive to that paradigm.
http://en.wikipedia.org/wiki/Unit_testing

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

That's like saying, "if training wheels keep a kid from falling over
on their bike, imagine what Lance Armstrong could do if he installed
them on his racing bikes".  bad logic.

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

You've missed my point.  Whether the Linux kernel targets hardware is
irrelevant.
Linux is a massive project with a huge number of programmers written
over many years.  Most parts of it have been rewritten or updated on a
regular basis.  New functionality is added in each release. Stability
and inter-operation between all the various parts is critical.
Abstraction is present in almost every component.  Sounds like all the
things that OO design would be used to deal with, yet this project
does not use OO design and has come out incredibly well.

I present this example as evidence that a very large project can
achieve the same benefits that OO design provides, without using OO
design.

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

I'd hoped we could focus on the points Mr. Graham makes in his essay,
not details about his background.  I think his words are accurate and
reflect what I've seen in my own experiences as a programmer.

Of course I could provide a long list of equally impressive names
who've written negatively about OO design.  Wikipedia has such a list
in their article on OO design if you're interested.  The truth is that
even strong proponents admit problems with OO design, and strong
opponents concede that it has valuable elements.

I don't think any of those experts would argue that OO design is
always the best way to write software, or the only way to achieve the
benefits attributed to OO design.   I would not expect the experts on
your list to blindly apply OO principles to a project that does not
benefit from them.

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

These are benefits that can be achieved in a number of ways.  They are
not the exclusive domain 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!
>

All of these great things could be done in a procedural system.   OO
design is not a requirement.

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

The coco is not an object oriented system.  I don't see how using one
to implement a Coco would improve one's understanding of the Coco any
more than writing a procedural emulator would.

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

As I said in my first post, I think it would behoove our small
community to focus our limited resources on projects that provide the
most bang for the buck.  MESS is a good emulator.  It already runs on
a huge number of systems, because it is open source, it will continue
to run on new systems as they come out.  We can add or correct
features in MESS any time we want to.  Certainly this can be done more
easily than writing a whole new system.  There are no limitations in
MESS that prevent implementing any feature (that I've heard of, at
least) that is desired from a new emulator.

I don't like negativity either, but I feel that bad ideas that can be
easily corrected are worth pointing out.  I'll be the first to admit
that sometimes I am an overly critical a-hole, but honestly my
intentions are to steer any efforts in the most beneficial direction
for the community (and likely the individual), not to stifle them.

> 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.
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>