Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!hal!nic.MR.NET!csd4.milw.wisc.edu!leah!itsgw!steinmetz!uunet!portal!cup.portal.com!dan-hankins
From: dan-hankins@cup.portal.com (Daniel B Hankins)
Newsgroups: comp.sys.amiga
Subject: Re: Need recommendation on Modula-2 compiler
Message-ID: <13074@cup.portal.com>
Date: 31 Dec 88 02:19:23 GMT
References: <2058@van-bc.UUCP> <403@nth.UUCP> <13030@cup.portal.com> <406@nth.UUCP>
Organization: The Portal System (TM)
Lines: 75

In article <406@nth.UUCP> loyd@nth.UUCP (Loyd Blankenship) writes:

>    Hmmmmm.  So if I buy a car and the engine doesn't work, your
>suggestion (is) to stop whining about the crappy engine that came with the
>car and put in a *real* engine, right?

1. I would hardly call the editor the engine of the compiler package.  More
   like the stereo, if you're going to use the car analogy.  Many compiler
   packages don't come with an editor at all.
2. If you don't like the crappy car stereo that came with the car, why then
   yes you *do* pull it out and replace it with a Blaupunkt or Alpine.

>    But Dan, if you provide someone with example code that won't compile, 
>that probably means that there's an error in it somewhere (or an error in
>the  compiler- 50/50 either way with TDI).

     The compiler isn't quite that bad.  You were using a bit of hyperbole,
I assume.

>  What's the bleedin' point of providing non-working example code? 
>"Here's some code that kinda might work, we aren't sure, but take a look
>at it, and if you fix it up, let us know."

     What's the point of providing example code at all?  I don't see a need
for it.

>    The errors were in the documentation.  The fact that I could recreate
>my own version of the documentation in no way obviates TDI from putting
>correct information in the original.

     Of course not.  I'm simply saying that it's not an impassable barrier.
Your comments earlier about giving up gave the impression that it was. 
Were it an impassable barrier, I wouldn't have been able to write code with
the package.

>>     You mean you don't grep the .def files on the distribution disks?
>   No Dan, I don't.  Y'see, I have this little quirk about using a manual
>to look something up occasionally, so I expect the index to tell me where
>to  look.  See #4 above.

     Yes, I understand that your standards are higher than mine.  I suppose
that after a few years of dealing with IBM's software and documentation
thereof, *anything* looks good.

>    Dan, why are you making excuses for these weasels?  I'm complaining
>about an obviously inferior product, and you sit and give me ways to work
>around  TDI f***ups.

     I'm not making excuses for TDI.  I'm making constructive suggestions
about how you can make effective use of the package instead of just whining
about it.  You have a problem.  TDI can't or won't fix it.  I will, to the
best of my ability.
     I'm not defending them;  I'm just attacking you. :-)
     I'll be the first to admit that TDI's product is imperfect;  hell,
it's pretty lousy.  In fact, I just rediscovered my major gripe with it:
the compiler itself won't work on files in RAM:.
     But it isn't unusable.  I'd rather create a few work arounds than
spend $400 or whatever to go back to a language I really dislike (C, that
is).  Or even to spend $200 to move to a different Modula-2 compiler.

>The point is, I *SHOULDN'T* have to use another editor, and I *SHOULDN'T*
>have to rebuild my own documentation because they were too {lazy|
>careless|stupid} to do it correctly.  And I certainly shouldn't have to
>rely on other users to support a product!  

     No, of course you shouldn't.  TDI's product certainly leaves something
to be desired in areas that seem to matter to you and to some other people.
But since you paid $200 for it, you might as well get *some* use out of it.
If I can, you can.
     There are lots of things in life that one shouldn't have to do, yet
you do have to anyway.  Like lock your house to keep things from being
stolen.


Dan Hankins