[Doty] The Promise of Forth

forth

    Next

  • 1. Yet another newbie question
    Hi gang, After executing "open <filename>" how can I find the address of the start of this file in memory? Thanks!
  • 2. Description of "Starting Forth editor"
    I have som vague recollection of a command line screen/block editor described in the book "Starting Forth". This doesn't seems to be included in the online version. Does someone have a link to either the scanned chaper from the book or some other description. When searching for this all I find is references to "Starting Forth" but no standalone description. I understand that this is only of historical interest but I'm playing a little with an old Poly-Forth system and would like to understand the logic behind the code (one learns a lot by looking at old code). Ronny
  • 3. FA: Jupiter Ace.
    For those crazy enough to want one : Ebay 320315772511 Jos

[Doty] Re: The Promise of Forth

Postby Andrew Haley » Sat, 05 Apr 2008 18:25:52 GMT










I would have thought the exact same thing that motivates you to spend
so much time posting to this newsgroup.


That's the whole problem here.  You have a feeling that something is
wrong, but you don't know what that something is, so you thrash around
grasping for ideas -- for example, "the lack of a tree-structured
grammar" -- with no idea whether they're relevant or not.

Andrew.

Similar Threads:

1.The Promise of Forth (Doty)

John Doty < XXXX@XXXXX.COM > wrote:
> Jonah Thomas wrote:

> > I can easily believe that a domain expert who's pretty new to Forth
> > can program his own solution faster than he can specify the problem.
> > But then it takes at a minimum a domain expert who knows Forth to
> > read his solution. And they can't necessarily read it fast. He might
> > not be able to read it fast himself, after he's had time to forget
> > the specifics of the problem.
> 
> But the real problem isn't domain experts: the real problem is *Forth*
> 
> experts. Consider, again:
> 
> : mu/ ( ud u--ud )  >R  0 R@  UM/MOD  R> SWAP >R  um/  R> ;
> 
> That's a *Forth* expert's definition (from the FSL). Ugh. Domain
> experts don't usually write such unreadable trash.

What's your problem?

You have the name mu/ . That's a good hint about what the word will do.
With a comment that you left out that says what it's supposed to do,
chances are anybody who knows Forth will know what it's supposed to do.

You have a stack comment that says what its inputs and outputs are.

If you have a set of test cases that give examples of its use, what more
do you need?

If it does what it says it does, who cares about reading the UM/MOD UM/
stuff? Why is that any issue at all?

If it doesn't do what you want then you have the choice of understanding
it and fixing it, or write what you want from acratch. I don't see the
issue. What are you complaining about? 

Tell us what you'd do to make this more readable. Here's what I'd do:
I'd have a short glossary entry that says what it's supposed to do. That
might go something like:

( G: UM/MOD divides an unsigned double by an unsigned single and gives a
single remainder and a single quotient. If the quotient overflows the
answer is wrong. mu/ should return the correct unsigned floored double
quotient in all cases except division by zero. The remainder is dropped.
)

And I'd include some test cases.

Beyond that what is your problem? There are never more than 4 stack
items and it's obvious which are which. The algorithm is simple and
obvious. The only reason to say this is not fully readable is if you
can't read Forth, and you can. You are not making any sense.

And even if it wasn't completely obvious how it worked, you hardly ever
need to read that. Figure out what it's supposed to do. Confirm that it
actually does that. If it makes those clear then how much more
readability do you want?

If you have a routine in C or in Perl or even in Python and it's
supposed to do a fast fourier transform or an LZ compression or
whatever, do you consider it unreadable unless you can read the code and
immediately see that it correctly does the FFT or the LZ compression?
What the hell?

2.The Promise of Forth

People who don't like Forth say, why bother with a data stack at all?
Declare variables, declare locals, let the compiler do the work of
figuring out where everything is. Don't bother your little brain about
it. And Forthers say that with a data stack we get a simpler compiler
and we get simpler subroutine calling. We're encouraged to factor
deeper, and that helps us write simpler code. And they say it isn't
simpler, programming in Forth is like solving a Rubik's cube, you're
handling details the compiler could do better and it costs you in
efficiency.


The Forth promise is that the extra thinking will pay off. That the
normal exponential crufty buildup will be slowed. That the simplicities
will work together so that you'll wind up with less total work. Fewer
places for bugs to hide means faster debugging and the possibility for
actual correct code. The less that extra complexity leaves you making
work for yourself, the more time you have available to think and
simplify and the more actual results you can produce.

It's true for some Forth programmers. When people try Forth and decide
it wouldn't work for them, they may be right. The Forth Promise can't
pay off except for programmers who think of ways to keep it simple.

And if you're an employer, do you want to pay people to think or do you
want to pay them to crank out solutions? One way you get lots of
solutions. Bang. Bang. Bang. Bang. Bang. Bang. Six problems solved
quickly. If your employee spends more time to solve 4 problems and he
changed the problems around to suit himself, how do you decide whether
the time is worth it? It's obviously stupid to measure productivity by
lines of code, but what do you use instead? There are people who try to
measure functionality with function points etc, but I predict that
automated methods to do that will fail, and that to do it correctly
takes competent programmers and requires more time than it does to
produce the code in the first place. For employers it's a leap of faith
to believe the Forth promise. They might believe it from their own
previous experience or from anecdotal evidence. They tend not to believe
it, and Forth has a tiny market share -- mostly limited to customers who
desperately need it to be true.

Forth's proven successes have been in resource-constrained systems,
where Forth has gotten results smaller than assembly or C. This is
partly because C "optimization" has focused more on speed than size.
Forth has also done well for things like debugging hardware interfaces.
Very interactive, easy to modify it for low-level details, etc. 

The promise of Forth should be manifest more in larger projects. The
bigger the project, the more opportunity for simplification. A project
that's 10,000 lines of code in some other language will have more
functional redundancy than one that's only 1,000 lines, and one that's
100,000 lines should have even more opportunities. 

But in practice there are limits. Forth is great when it's one great
Forth developer doing it all himself. Three Forth experts can cooperate
well, particularly when they have different specialties -- for example
one writes device drivers and low-level code while a second writes the
guts of an application and a third does the user interface. But a large
Forth team is if anything more likely to write redundant code because
they're likely to produce faster. To avoid that it would be necessary
for all of them (or all but one) to know what everybody else is doing.
If you figure that it takes half as long to look at somebody else's code
and see whether there are possible common factors with your own as it
does to write that same code from scratch, a team of 9 Forth programmers
might need to each spent 80% of their time looking at what the others
are doing and only 20% of their time doing things themselves.

Forth is OK for big projects. But it appears the experience with Forth
for big projects involves first getting the specs very very clear. Then
code rigidly to the specs. And finally use Forth's interactive strengths
to handle all the problems in a fast last-gasp race to the deadline.
This works, but it doesn't get such obviously great results that lots of
managers want to try Forth for large software projects. 
Besides everything else there aren't a lot of established candidates for
Forth experts on large projects. I'm going to pull numbers out of the
air, not having good estimates available. Let's suppose that there are
50,000 electical engineers who sometimes use Forth for debugging
hardware etc. And there are, say, 8,000 scientists and engineers etc who
sometimes use Forth or LSE etc for some of their work. And say 1,000
engineers (grading into hobbyists) who use Forth for commercial software
projects that they don't talk about in public. And at any given time
there might be 50 to 100 expert Forth programmers who can drop what
they're doing and spend a year or two on a new large Forth software
project. You simply can't get a lot of large Forth projects starting the
same year, unless you accept some Forthers who don't have very good
credentials. If we got every software manager in the country clamoring
to use Forth for his next project we couldn't possibly fill the need for
programmers. Elizabeth Rather might perhaps produce 50 new Forth
programmers a week. She might find five people she'd trust who could
train 50 programmers a week. In 6 months that approach could produce,
say, 10,000 Forth newbies who'd taken the 1-week course and were basicly
competent. If they were to join 300 or so projects with 30 or so
programmers each, where would we get 300 Forth project managers?

Forth's advantages ought to show up best with projects that can be done
by 1 to 3 Forth programmers. I have the impression that large projects
need to be larger than this because a software manager needs to manage
10 to 30 or more programmers to get the institutional respect an
administrator needs. It isn't that Forth is no good for large projects.
The problem is that Forth's strengths come out when programmers strive
for radical simplicity, and when too many are working in parallel it's
too hard for them to coordinate that. So Forth's promise is diluted and
the advantage is less.


How could Forth break into the large-project market? Could Forth be used
for rapid prototyping? If you plan to throw away the prototype, writing
it in Forth would help to firm up resolve. I read that some successful
large military projects used to have a parallel smaller project. The
secondary project would have 10% of the people and 10% of the funding,
and they would do their best to get results quickly. Could a few
software project managers be persuaded to try that? A fast lean team
might run into some of the pitfalls early and alert the main team to the
coming problems. And they might get results. There could be far more
than 10 times as many 3-person Forth teams available as 30-person Forth
teams. If they get the contract, they stand to win far more than to lose
-- nobody would expect too much from them since they'd be a 3-man team
prototyping for a 30-man team. But if the big team fails when they
succeed then that's a big win.

So, if you'd consider doing this sort of work, you might find two others
you'd work well with. Then find some nascent projects and make your
pitch. I have a thought that a manager who hears from three competing
Forth teams may be more likely to go with one of them than a manager who
only hears from one. It all seems more plausible when there are multiple
teams competing for him, like they're all following the same viable
business model and they think he's a plausible customer.

3.The Good Parts version Was: The Promise of Forth

John Doty said some interesting things mixed in with the usual stuff,
and I wanted to get those things to more readers.

John Doty < XXXX@XXXXX.COM > wrote:
> Jonah Thomas wrote:

> > Forth gave a similar mystique, but there were many incompatible
> > Forths. Forth-83 made most of the Forth-79 code obsolete. And there
> > was the claim that Forth was easy. Nobody said assembly was easy,
> > and C was still hard.
> 
> But in my shop we just had one Forth, along with a large body of code.
> 
> Still, when C came along, people rather quickly found that it gave
> them the ease of Fortran without the limitations. And by that time the
> 
> edit-make-run cycle was down to about 30 seconds, fast enough to make 
> Forth's interactivity seem a minor advantage.
 
> > Why did C win out over Objective-C?
> > There were important differences in that case. Was it some fatal
> > flaw in Objective-C?
> 
> As someone who preferred Objective-C, I think the answer is similar to
> 
> the answer for Forth: Objective-C has rather odd syntax, confusing to 
> ordinary users.

> > When you talk about particular limitations that matter to particular
> > users, people tend to respond. We've had some talk about how to
> > improve library support, how to add type-checking, how to implement
> > other languages in Forth, improved string handling, the problem of
> > using libraries written in other languages (mostly solved for
> > commercial implementations), etc.
> 
> It's all good, but not, in my judgment, adequate. Tinkering around the
> 
> edges, constrained by the delusion that the standard is something
> valuable.

> >> The only way I know to attack these questions is to study
> >successful > languages, and published code in them. Users can't tell
> >you what they > would want, but their behavior speaks volumes.
> > 
> > Another approach is to watch what works for you. If Chuck had
> > studied successful languages in the 1960's, what would he have based
> > Forth on? COBOL and Fortran? 
> 
> A good approach would have been a "machine-independent assembler" 
> similar to the Forth he created, with an interactive Fortran or BASIC 
> layer above. Bob Frankston actually did something like that when he 
> created ECD BASIC a few years later, but ECD's hardware business lost 
> too much money and the company folded, so few ever saw the product.
> But I did some of the early simulations for the RXTE (xte.mit.edu)
> design with it.
> 
> But Chuck was ideologically committed to a single layer of language,
> as strongly as von Neumann had been to octal a generation earlier.

If you've been ignoring John's discussions about logic, scientific
method, Newton's calculus etc, these might be the most interesting bits.

4.Forth and AI (Was C vs Forth, was Howerd's ANN : Forth Versus C - some InfrequentlyAsked Questions)

Jeff,

    I would be interested in hearing your experiences using Forth with AI.


Steve Graham

===

Bill Spight < XXXX@XXXXX.COM > wrote in message 
news:< XXXX@XXXXX.COM >...

 >>> > Symbolic Computations on a Personal Computer, -- S. N. Baranoff
 >>> >
 >>> > List Processing and Object-Oriented Programming Using Forth, --
 >>> > Dennis L Feucht


 >> It might be interesting to hear from Messers Baranoff and Feucht bout
 >> the difficulties and trade-offs of using Forth for symbolic
 >> computation, in their experience.


I worked with Dennis Feucht a few years ago on a small project, and
did quite a bit of work with one of Dr. Baranoff's students who
went on to teach university courses using Forth after he got his
PHd.  I highly recommend Dennis' book about Writing Personal Expert
Systems in Forth for more information about the subjects of those
Rochester Forth Conferenced presentations about his Lisp like list
processing and his Prolog hybrid implementation in Forth.

A few years ago I also worked on a project that combined
Feucht's Lisp and Prolog Forth extensions with an Aha like
database engine, neural nets and genetic programming. Of
course someone might say that only Forth is Forth and that
as soon as one starts to write an extension toward an
application domain that it shouldn't be called Forth.
Personally I think that is arguing personal definitions
and reaching a bit too far.  But I think it fits right in
with questioning whether I had any idea what I was talking
about in this thread.

Best Wishes

5.Min/Max attribute makes promises it can't keep

I'm disappointed with some allowed syntax that seems a little error-
prone.  Consider the following code:

with Ada.Integer_Text_Io; use Ada.Integer_Text_Io;

procedure Main is

   Nat : constant Natural := 0;
   Pos : Positive;

begin

   Get (Pos);
   Put (Positive'Min(Nat, Pos)); -- Ada does not require the Min
attribute to enforce a Positive result

end Main;

This program happily outputs that the minimum of (0 and whatever
positive value you enter) is 0.  Now, I concede that the program is
working exactly as the ARM specifies.  The Min (and Max) attribute
functions accept and return types of S'Base, in this case
Positive'Base.  But doesn't it seem like a bit of a tease to allow a
programmer to specify S'Min if the compiler is allowed to ignore the
type of S in the function's parameter list and the program does not
raise a Constraint_Error at run-time if it returns a value outside the
range of type S?

If it's too hard to enforce strictly then maybe the functions should
be named Unchecked_Min/Unchecked_Max.  Or maybe the programmer should
be constrained to using the attributes with only a base type.  Or, at
the very least, can't the compiler generate a warning about this?  I
turned on all warnings in GPS and got nothing.

Things that make you go hmmm...

Alex

6. Promises, futures -- implementation suggestions?

7. PLease unban me from irc I Promise not to come in drunk again

8. update on the promised new development environment?



Return to forth

 

Who is online

Users browsing this forum: No registered users and 45 guest