Path: utzoo!utgpu!watmath!clyde!att!pacbell!ames!mailrus!csd4.milw.wisc.edu!leah!itsgw!steinmetz!uunet!van-bc!root
From: lphillips@lpami.wimsey.bc.ca (Larry Phillips)
Newsgroups: comp.sys.amiga
Subject: Re: Need recommendation on Modula-2 compiler
Message-ID: <2079@van-bc.UUCP>
Date: 30 Dec 88 22:10:41 GMT
Sender: root@van-bc.UUCP
Lines: 126

In <13030@cup.portal.com>, dan-hankins@cup.portal.com (Daniel B Hankins) writes:
>In article <403@nth.UUCP> loyd@nth.UUCP (Loyd Blankenship) writes a
>scathing criticism of TDI's compiler.

And rightly so.

>     Personally, I don't think that it's that bad.  I've successfully
>written a modestly sized program in it without too many problems.  I'm now
>in the process of writing an interpreter for an object-oriented language in
>it (not a small project).  Here's some answers to his points:

How accomplished a Modula-2 programmer are you? It really does make a big
difference. For someone who is not in the 'expert' category, fighting a
compiler in addition to trying to write code can be an almost herculean task.

>>1) The editor eats 50K of RAM every time it is invoked.  The only way to
>>   recover the RAM is rebooting.
>
>     Their editor is lousy anyway.  Don't use it.  MG or DME or just about
>any other editor is superior.  MG in particular has the capability to be
>customized to be syntax-sensitive.

The editor, lousy as it is, is part of the package, advertised as a 'feature',
and paid for by the buyer as much as is the compiler itself. To say it is lousy
anyway and not to use it is ridiculous. Perhaps the user likes the editor in
spite of the bugs and wants to use what he has paid for. To recommend another
editor that he may not have or may not like, and may or may not have the skills
and/or inclination to 'customize to be syntax sensitive' is to ignore the fact
that he does not have something he paid for and expected to be in good working
order. The real kicker to the editor issue is that TDI's answer to criticism of
their non-functional piece of garbage was "You can buy the source from us and
fix it." With attitudes like this, it's a wonder the criticism was only
'scathing'.

>>2) The editor sometimes finds errors, and sometimes doesn't.  Completely
>>   random in functionality.
>
>     Again, don't use TDI's editor.  Use the public domain program m2error
>(available on Fish) which will invariably give the correct error code and
>location.

Sure. Well, that's two programs that you paid for that are unusable. Sounds
like a great way to market software. Buy the package and then scrounge around
finding programs that work.

>>3) The example code given (the BOX code specifically) does not compile. 
>>   Debugging is left as an excercise to the purchaser.
>
>     I won't argue with you here.  I don't know, myself.  In my book,
>compiling example code is usually a waste of time, unless it does something
>in particular that you need.

It obviously wasn't a waste of time to the one criticising the product, or he
would not have bothered to mention it. Again, it rather depends on your level
of expertise, no?

>>4) In the definition files, several variables and types are defined wrong.
>>   It's been long enough that I don't remember specific examples.
>
>     Again, no argument.  I haven't personally encountered any of these.  
>Is this in the documentation, or on the files actually provided on the
>disks?  I haven't yet encountered any errors in the files provided on the
>disks.  If the definition file is wrong, well then I would just use DecSym
>to generate one from the .sym file.  Haven't had a need to try that yet, so
>it may not work.

I wonder... was DSM written in Modula-2 ? If so, it might help to explain why
you haven't run across any problems in the dissk based or the book based .DEFs
(yes, there are errors in both places). Not everyone sticks with plain vanilla
IO, with no Amiga specific Intuition or graphics stuff.

>>5) The documentation is the worst collection of vauge and misleading
>>   statements it's ever been my misfortune to wade through.
>
>     I must have backlevel documentation.  Mine is fairly short, clear, and
>concise.

And how much do you read between the lines, applying your past knowledge of the
Modula-2 environment and idiom. Note that I am not saying that the manual
should teach you how to program in Modula-2, but it should tell you how to go
about compiling and linking in a clear manner. I'm afraid I have to agree with
the critic on this one.

>>6) The index is wrong about 25% of the time.
>
>     You mean you don't grep the .def files on the distribution disks?

Does he even have grep? Come on Dan, he paid for a manual as well, and got a
slipshod piece of garbage that might be satisfactory for someone who doesn't
need it.

>>7) Customer support is non-existant.  When you call on the phone (I tried
>>   both the UK & the US phone #'s), the person who knows anything about it
>>   is 'not available', and not *once* in over 20 attempts did anyone ever 
>>   return my call.
>
>     I haven't needed this yet, so I wouldn't know.  I get most of my
>support from other users, when necessary.

  How very nice for you that you are advanced enough to not need the support.
How very nice that you have easy access to people who are wiling to help you
around the pathetic quality of this package. Don't make the assumption that all
users are as knowledgeable as you, or that they have the same access to help.

  It's attitudes like yours that will ensure the continuing production of
garbage at high prices, under the guise of tools for the Amiga.

  The one good note about all this is that the people that actually wrote the
compiler have recognized at least part of the problem, and TDI is no longer
their North American representative. M2S will be coming out with a new single
pass compiler called 'M2Sprint' early in the new year. Whether it is any good
at all remains to be seen. At least we won't have to deal with the cretins at
TDI any more.

>Dan Hankins

-larry

--
"Intelligent CPU?  I thought you said Intel CPU!" 
        -Anonymous IBM designer-
+----------------------------------------------------------------------+ 
|   //   Larry Phillips                                                |
| \X/    lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips  |
|        COMPUSERVE: 76703,4322                                        |
+----------------------------------------------------------------------+