[Coco] OO programming - [Was]:Emulator

[Aaron Wolfe]

Taking a clue from our beloved CoCo, I will just say

OK

-Aaron


On Fri, Nov 6, 2009 at 3:41 AM, Fedor Steeman <petrander at gmail.com> wrote:
> 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
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>