[Coco] OO programming - [Was]:Emulator

Fedor Steeman petrander at gmail.com
Fri Nov 6 03:41:26 EST 2009


Hi again,

WARNING: The below text contains a number of bombshells that some may regard
as flamebait!

@Willard Goosey
> Mark McDougall wrote:
> > Again, don't let this stop any of you from starting your own Coco
> emulator
> > project, whether it be in C, C++, BASIC, ASM, Lisp.... OK, Lisp? Really?
> > Think about it... Java... Java? You deserve what you get... ;)
>
> Isn't there a CoCo emulator in Java?  Mocha I think it's called?
>

Thank you for bringing this to attention. Yes, if what you get is an
emulator that can be run anywhere, anytime on any system supporting Java
without installation and right away in a browser, well I think we can be
certainly happy that someone took the initiative. That being said, using an
OO language by no means implies a "proper" OO design, but I would love to
see the source code.

@Mark McDougall
> I think it can be safely said that Fedor, Aaron and myself generally agree
> at some level; where we differ is our opinion on its suitability and
> proported benefits for a Coco emulator. And here we shall remain divided. :)
>

On the contrary, I actually agree that it is a subject of debate whether OO
is suitable for writing a CoCo emulator, as I clearly have expressed several
times now. I disagree with Aaron in that I think it is actually worth a try
for anyone to take a shot at it in any other language than "C" (blegh) and
they should not be discouraged from doing so. Something that you also, if
not at least partially, agree with.


> @Aaron Wolfe
> 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.  [...]
>
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.
>

I am sorry, but if you think that you serve our small community by shooting
holes into any initiative that cannot be shoehorned into your own usual
approach to things, then you are misleading yourself. If you really want to
be the one steering any efforts in the most beneficial direction then do so
in a constructive way and do not presume that anything that conflicts with
your own way of thinking is worthless. Please don't mistake your own
personal habits and preferences with what is right and will work for
everyone.

Look, people are different and what works for one person may not work for
another. For someone who understands the workings of computer electronics
and the hardware of systems like the CoCo in and out, procedural programming
could indeed be the closest to their way of thinking and what they would
prefer for any project, and what they would be most productive with. People
like that would tend to gravitate toward highly technical, hardware-near,
embedded programming, or emulation of such, anyway, because that is what
they are most familiar with. For more intuitive programmers who think in
concepts and seek to solve outside world, human-focused problems, an
object-oriented approach would make more sense.

That is what I meant with "accessible" which was misconstrued as to mean
"easy to get your hands on". The "C" programming language does not agree
with everyone, and not everyone (I would say barely everyone) has been
educated in it, whether they are IT professionals or hobbbyists. Therefore,
it would be more than fair for them to use a platform that they themselves
prefer. I think a lot of people here are happy that no one discouraged and
stopped the development of Mocha or the like.

Which again leads me to underlining for the zillionth time that, heck, I
don't know if the OO-approach would be suitable for CoCo emulation. It would
be interesting for someone to try, 'though, and I see no reason why the
options should be narrowed to a mechanical, imperative language like C. For
most people, a natural, object-oriented language would most probably be
easier to learn, understand and remember than something like "C".

And that is another bone I still have to pick with you: The "C" programming
language has not been a part of my CS education nor of any of my buddies
that I asked. Instead, we had Java or some other OO language. One buddy, an
engineer, even thought the notion that it was required for any IT
professional to have had "absurd". He did not have a high regard of the
language BTW. Whatsmore: A cursorial googling on "computer science
curriculum" did not give me the immediate impression that any computer
language was regarded as required. Instead, of what I have read, any Object
Oriented approach was deemed required rather than a particular language.
Maybe C was prevalent in education a decade or two ago, but we have moved on
since then.

> Agreed, but whether these black boxes are objects or functions or modules
> or libraries makes little difference.
>
I disagree. Using objects allows you to group similar functionality
logically in constrained units by convention, making its use significantly
more intuitive. Procedural programming doesn’t allow this.

> I am a huge fan of abstraction, its a fundamental CS concept that predates
> OO by some tens of years.
>
That is actually not correct. There is no programming language from before
1952 (much less 1942) that uses any concept of abstraction. To my knowledge
Simula is the first programming language that introduces abstraction, and at
the same time, the first object oriented language.

> Unit testing is great.  It's yet another concept that predates and
> continues to exist outside of OO design.
>
While it’s true that you can interpret unit test to mean “testing
functions”, it was not until the advent of OO design, applications became
complex enough that you needed unit tests You need unit tests when your
algorithm cannot be mathematically proven to be error free. Otherwise, it is
just an easier alternative to doing the math.

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

No one is debating that you CAN’T write well designed, complex software
using procedural programming. You can drive a car with your feet if you want
to. That doesn’t mean it’s a good idea. Yes, I concede that a large group
can on occasion write complex, well written software in archaic languages.
But it takes an order of magnitude more time. Look at the progress other
Open Source projects have made in the last 18 years. FireFox, Eclipse, Open
Office...

> I'd hoped we could focus on the points Mr. Graham makes in his essay,
>
We could. But it would be more useful to discuss reality. Mr. Grahams
“points” are nothing but religious opinions, and every one of them is wrong.
You can’t discus OOP with someone who doesn’t even understand the basic
principles, and has a pseudo-religious predisposition that is demonstrably
wrong. It’s like discussing evolution with a creationist, astronomy with an
astrologist or dentistry with someone who believes in the tooth fairy. He
doesn’t even address a single one of the Object Oriented principles. He just
fires up a, frankly disturbingly ignorant, elitist rant about how it’s
unfair that people who don’t have to use punch cards, can’t possibly be as
hardcore as he is.

As said before, I would love to see Paul Graham develop a Word Processor or
the like using one of his pet languages.

 > 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.
>
> Bad analogy. Mediocre programmers are not like kids just learning to bike
compared to professional sportsbicyclers. Besides, I get the general
impression that you are only hearing half of my argumentation.
Highly-skilled programmers are already achieving a lot of great work using
OO D/P, which was my main point.

> I don't think any of those experts would argue that OO design is always the
> best way to write software,
>
 But that is also what I have emphatically been stating all the time! I just
oppose the view that it is generally useless, as it clearly is not.

> or the only way to achieve the benefits attributed to OO design.
>
I strongly doubt they would ever agree to that there never was any need to
invent OO design.  :-D

Cheers,

Fedor Steeman



More information about the Coco mailing list