Broken cmForth 
Author Message
 Broken cmForth

Quote:
> > I find it amusing that Chuck introduced a bug in cmForth because of
> > his zeal for eliminating DO .. LOOP
> There was no need in cmFORTH to compile colon or CODE definitions  across
> screen boundaries, thus its THRU worked just fine. And, as Jan  Stout pointed
> out, it is easily modified to allow compiling colon or  CODE words across
> screen boundaries, if one's factoring is so poor (as  mine is on occasion)
> that he needs that facility.

A bug that doesn't happen to show up in a particular application is
still a bug.

A bug that is easy to fix is still a bug.

One of the reasons that Forth has a bad reputation is because there
are so many half-hearted Forth implementations floating around.
Too many Forth implementors have a tendency to take shortcuts that
compromise the quality of their implementations.  The "I don't need
that feature this week, so the heck with it" attitude has probably
damaged Forth's reputation more than anything else.

Mitch



Mon, 09 Aug 1993 03:14:13 GMT  
 Broken cmForth


Quote:
> A bug that doesn't happen to show up in a particular application is
> still a bug.

> A bug that is easy to fix is still a bug.

I get the impression that the bug is really that CM changed the definition
of THRU instead of picking another word.

Quote:
> One of the reasons that Forth has a bad reputation is because there
> are so many half-hearted Forth implementations floating around.
> Too many Forth implementors have a tendency to take shortcuts that
> compromise the quality of their implementations.  The "I don't need
> that feature this week, so the heck with it" attitude has probably
> damaged Forth's reputation more than anything else.

Hmm.  I find this a peculiar point of view.  I have heard it said that
one doesn't really know Forth until one has implemented it.  As Forth
implementions qua personal-systems, I see no problem with taking
short-cuts.  As for products, I don't understand why market forces
haven't straigtened the situation around.  The "problem" is that
shareware/PD systems abound and somehow it is those systems that scare
people off?  My question is why are there so few PD/Shareware C
systems (semi-rhetorical question) and why has the Forth PD/Shareware
market had such a great eclipsing influence over the "professional
product" market?

Personaly, I feel the answer is that the proliferation of PD/SW
systems tells people that they are dealing with a "little language,"
one so easy to implement that any bozo can do it, and therefore they
would get little out of it ("To carry out the treasure of the Indies
you must carry in the treasure of the Indies" attitude).  The
commercial Forth vendors must distinguish themselves from the
PD/Shareware people.  I find it hard to believe "support" can be taken
seriously as a distinguishing factor when the whole philosophy of
Forth is build your own language to support your application.  How can
commercial vendors expect me to believe they'll support "my" code?
(not a rhetorical question)

I'm curious to know what the commercial vendors see as their added
value.  In anticipation of one obvious answer: "Libraries," I ask
further how that will be affected by the ANSI effort (where the
library will be less unique because it must conform).

-Doug
---



Sun, 08 Aug 1993 21:00:07 GMT  
 Broken cmForth

Quote:
> I get the impression that the bug is really that CM changed the definition
> of THRU instead of picking another word.

You could look at it that way.  However, one might ask why he changed
the definition.  The "new" definition of THRU is in no way an improvement;
it does the same thing as the old THRU, except that it takes away
functionality that used to exist.  Furthermore, I expect that this was
done consciously.  The functionality was given up simply because it
was slightly inconvenient to implement using FOR .. NEXT .

In any case, it still supports my orginal point; FOR .. NEXT is not
an unmitigated win in all circumstances.  Here is a real live example
of a particular weakness of FOR .. NEXT compared to DO .. LOOP , and a
good Forth programmer broke a well-understood function as a result.

There's nothing inherently wrong with FOR .. NEXT per se, but I can't
accept the claim that the existence of FOR .. NEXT renders DO .. LOOP
useless.

Quote:
> As Forth implementions qua personal-systems, I see no problem with taking
> short-cuts.

Nor do I, but I wish people would stop posting and distributing their
half-baked experiments.  And I don't object to half-baked experiments;
I do them all the time.  I just don't pass them around labeled as
"Forth implementations".

Quote:
> As for products, I don't understand why market forces
> haven't straigtened the situation around.

Market forces work best when the market is large.  The Forth market isn't.

To some extent, the market forces do work; crummy Forth implementations
die relatively quickly, and the competent ones survive.  This is
independent of whether they are commercial systems or not.  Crummy
commercial systems die too.

The problem is that crummy systems just keep on coming, and many people
have been and are turned off of Forth because of bad experiences with
crummy Forth systems.

Quote:
> The "problem" is that shareware/PD systems abound and somehow it is
> those systems that scare people off?

I do NOT equate "bad" with PD.  There are several completely competent
PD systems out there, F-PC and F-83 to name just two.  The problem that
I am talking about is when somebody posts the Forth that they wrote
in 2 weeks for their "CS 202" project and it gets stuck up on better
bulletin boards everywhere.

Quote:
> My question is why are there so few PD/Shareware C
> systems (semi-rhetorical question) and why has the Forth PD/Shareware
> market had such a great eclipsing influence over the "professional
> product" market?

It's partially because Forth is not an accepted "respectable" language,
thus many Forth enthusiasts have to buy Forth out of their own pockets,
rather than getting their company to pay for it.  I have lots of customers
who have purchased my system for use at work, paying for it themselves and
hoping someday to impress their bosses to reimburse them.  In fact, I did
the same thing myself when I was starting out with Forth.

Most people are careful how they spend their own money, and will make
do with something that is free rather than commit the bucks.

Quote:
> The commercial Forth vendors must distinguish themselves from the
> PD/Shareware people.  I find it hard to believe "support" can be taken
> seriously as a distinguishing factor when the whole philosophy of
> Forth is build your own language to support your application.  How can
> commercial vendors expect me to believe they'll support "my" code?
> (not a rhetorical question).

Product support takes many forms; it can mean fixing bugs in a timely
fashion, or providing suggestions about good ways to attack a particular
problem, or telling people about system features that may help in their
problem (that they may not have discovered in their reading/exploring),
or helping people find bugs in their code or setup (for instance, I spent
a lot of time on the phone with one customer, only to discover that
he was using a PC-XT as a dumb terminal, and the comm program he was
using dropped characters at 9600 baud).

Speaking only for myself, I spend a great deal of effort doing product
support, and I can name you a lot of customers who appreciate it a
great deal.

The great majority of my customers have considerably less Forth experience
than I have, and they value the ability to "pick my brain" to the extent
of paying me for it.

That is what support means to me.

Quote:
> I'm curious to know what the commercial
> vendors see as their added value.

The above diatribe is part of my added value.  Another is printed, bound
documentation (which lots of people want; no kidding).  Another is
purely administrative; you send me money, I send you a disk.  A lot
of people don't want to fool around with searching for and downloading
a PD system, or figuring out how to get the bits onto the target
machine.

Quote:
>  In anticipation of one obvious answer: "Libraries," I ask
> further how that will be affected by the ANSI effort (where the
> library will be less unique because it must conform).

That too, but I provide a lot of libraries that are not covered by
ANS Forth, for example system-dependent OS calls, window interfaces,
dynamic loading, etc.

Mitch



Wed, 11 Aug 1993 03:21:35 GMT  
 Broken cmForth


+In any case, it still supports my orginal point; FOR .. NEXT is not
+an unmitigated win in all circumstances.  Here is a real live example
+of a particular weakness of FOR .. NEXT compared to DO .. LOOP , and a
+good Forth programmer broke a well-understood function as a result.

I might be inclined to reply to this by saying that CM is not your
average Forth programmer.  No reason to assume he can't make mistakes
or blunders, nor that he won't change his mind.  I would be interested
in hereing further justification.  Was the THRU bug no big deal?  Was
it better factored (as I think it was Frank suggested) this way?
Personally I believe that the bug is that THRU needed more than just a
replace-string done on it.  That FOR NEXT is slightly inferior in this
case doesn't sound the death nell for me as it seems for you.  Perhaps
one of the straws on the camels back, but not that interesting in and
of itself.

+There's nothing inherently wrong with FOR .. NEXT per se, but I can't
+accept the claim that the existence of FOR .. NEXT renders DO .. LOOP
+useless.

As I said in an earlier post, they are nearly isomorphic.  I think
this is an interesting illustration of the deceptive simplicity of
Forth.  Simplicity doesn't "just exist," but is always relative to
something.  Whether DO LOOP or FOR NEXT is "simpler" or "more elegant"
or ....  depends on what you are trying to do.

+The problem is that crummy systems just keep on coming, and many people
+have been and are turned off of Forth because of bad experiences with
+crummy Forth systems.

+I do NOT equate "bad" with PD.  There are several completely competent
+PD systems out there, F-PC and F-83 to name just two.  The problem that
+I am talking about is when somebody posts the Forth that they wrote
+in 2 weeks for their "CS 202" project and it gets stuck up on better
+bulletin boards everywhere.

"Most bad systems are PD, Therefore most PD systems are bad."  I
meant the former, not the latter.  Sorry for any confusion.

It is interesting to note that the same thing doesn't happen with C
compilers/run-time systems.  One of Forth's strengths seems to cast
a bad light here.

+Most people are careful how they spend their own money, and will make
+do with something that is free rather than commit the bucks.

That explains why people might choose a "free" PD/Shareware system,
but not why there are so many to choose from.

+The above diatribe is part of my added value.  Another is printed, bound
+documentation (which lots of people want; no kidding).  Another is
+purely administrative; you send me money, I send you a disk.  A lot
+of people don't want to fool around with searching for and downloading
+a PD system, or figuring out how to get the bits onto the target
+machine.

Printed documentation is a BIG plus.  Not just stuff you can run off
on a half decent dot matrix printer, but nice bound, laser output with
pictures, etc.  Not having to maintain the core system itself, i.e.
unsolicited updates and bug fixes, are also BIG pluses.

Thanks for the detailed reply.  I don't have any dispute with what you
said.  I guess one thing you didn't say is that the quality of the
implementation is much more crucial for commercial success than
PD/Shareware "success."

-Doug
---



Thu, 12 Aug 1993 10:50:43 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. broken cmForth

2. CMFORTH

3. cmForth

4. cmForth

5. cmFORTH?

6. cmForth and IMMEDIATE etc

7. cmForth for Novix binary?

8. Handling group breaks and page breaks run time

9. CPCS - Page Break on Control Break?

10. Is break broken? :) :) :)

11. C5B ABC Report -- How to "page break" in a group break

12. Report Feature--Nested Breaks

 

 
Powered by phpBB® Forum Software