The Promise of Forth
Jonah Thomas
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.
Axel Harvey
> 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.
>
> [ ... ]
>
> 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.
As for the Rubik's cube analogy I find it odd that
so many people have the same reaction. Programming
is not my first occupation, probably not even my
twelfth, but I have translated C manuals and looked
at other languages, and I know that Forth is the
simplest for me.
As for the problem of redundancy, I think Forth makes
it fairly easy to write words that find redundancies
in files of Forth code. I did that in a small way a
long time ago, and I'm not Babbage. Large-scale
project management software for Forth must already
exist.
Rod Pemberton
"Jonah Thomas" <jeth...@gmail.com> wrote in message
news:20080322215618.3...@gmail.com...
> 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.
The same issue affects assembly doesn't it? (I'll basically use assembly as
a synonym for FORTH for most of the rest of my response.) I prefer C to
assembly, in part, because I can focus on programming instead of keeping
track of, losing track, tracking down, and correcting the register, stack,
and memory locations of variables... For assembly, I've spent unknown
amounts of time on this. I spend no time for it in C. It's just handled
correctly. It shows the advantage of an implemented solution to a solved
problem. One step forward...
> And Forthers say that with a data stack we get a simpler compiler
> and we get simpler subroutine calling.
That's true. But, most don't have to deal with say C's prolog, epilog, or
the stack.
> ... you're
> handling details the compiler could do better and it costs you in
> efficiency.
That's true too. Well written C can almost match assembly. But, I usually
can't out code a C compiler, in assembly, in areas where it's optimization
are strong: constant folding and constant propagation. Although, there are
places where C compilers aren't strong and hand coded assembly can
outperform a compiler.
> The Forth promise is that the extra thinking will pay off.
That makes quite a few assumptions about people's abilities. It implies
"practice makes perfect," but assumes the result of extra time and thought
happens to be productive and not wasteful - "going 'round in circles". My
academic experience has proven to me very few people can solve problems.
And, of those that can solve problems, very few can actually think. I've
seen numerous people deemed "exceptionally bright," supposedly far brighter
than me in most cases, who could solve numerous problems as effectively as
I, not be able to solve similar problems if a trivial change was
introduced... This is a strong indication to me that they'd developed some
method to solve problems without real comprehension of the problem.
> 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.
All of your statements can be applied legitimately to the argument for using
variables and not the stack or registers... Each thing you must do to solve
a problem in code has the potential to introduce error. From that
perspective, which is more likely to reduce coding errors: 1) keeping track
of variables by yourself or 2) not keeping track of variables by yourself?
The variable tracking has already been solved and debugged in a HLL, like C,
so these are all true when it comes to using variables:
1) "That the simplicities will work together so that you'll wind up with
less total work."
2) "Fewer places for bugs to hide means faster debugging and the possibility
for actual correct code."
3) "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."
The question in my mind is, "If someone or something else can solve the
problem, why must the rest of society be forced to waste time and resources
resolving the problem over and over again?" How many people have to spend
their lives mastering mathematics, when those who came prior could've
provided solutions to real world problems instead of providing books of
problems to solve? Shouldn't we be producing means to advance the next
generation from our generation's "solved problems" to the next generations
"unsolved problems"? How do we expect the next generation to advance if
they are well over age sixty before an exceptionally few of them have
learned enough to solve more challenging problems? Are we going to depend
on IQ's increasing on generation to generation, or are we going to reduce
the next generation's comprehension requirements and work load?
Your statements could also be applied to learning mathematics. I had four
semesters of Calculus (plus AP Calculus in HS), Differential Equations,
Engineering Mathematics, only to learn that 98% of all Calculus problems
that I'd ever face in engineering can be solved with Laplace Transforms.
Basically, all math from Linear Algebra (10th grade?) in HS to my senior
year in college was a complete waste... of time, money, energy, life. And,
in reality - since I didn't end up in engineering - I never needed any of
it.
> 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?
I want someone who can both think and can correct the cause, not the effect,
of a problem effectively and correctly. But, that's not what employers I've
worked for cared about. They cared about: people getting to work on time,
making unrealistic deadlines, denying people raises because performance
goals weren't met and then giving millions to charity, paying as little as
possible to the least experienced and poorest thinkers they could get who'd
do the job - "cut 'n' paste", being able to tell upper management the
problem was fixed - without telling them it was buggy, inefficient, and
would require much rework and costs later - "job preservation", rewarding
employees for solving "big" problems - even if that same employee created
the "big" problem, etc.
> ... that to do it correctly
> takes competent programmers and requires more time than it does to
> produce the code in the first place.
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.
There are a number of language design differences that "bloat" C compared to
FORTH. I see little reason why a C variant (might not be ISO C compliant)
couldn't produce code as compact.
> Forth has also done well for things like debugging hardware interfaces.
> Very interactive, easy to modify it for low-level details, etc.
I still miss the interactiveness of interpreted BASIC as compared to
assembly or C. But, you either get a compiler or interpreter - it's rare,
except for some FORTHs - to get both. Today, you have to produce compiled
code...
> 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.
Isn't the "redundant code" issue either a lack of a standardized library or
a lack of separation of tasks?
Rod Pemberton
Paul E. Bennett
> 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.
The extra thinking does pay off very handsomely. Project managers have to
be enlightened to see this though. Sadly, too many expect the code
monkey's to churn out the solutions then they end up with very extensive
debug cycles. With Forth, because the thinking was up front where, in
proper systems engineering terms it belongs, there is less time and
money wasted late in the project.
> 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.
Only those who think complex problems demand complex solutions think that
way. By all accounts this is a large number.
> 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.
I'd rather they are thinkers myself (not that I employ often).
> 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.
There are tools that assist (not all automated ones and some of the best
are simple pen & paper techniques). Forth is really for those into
proper systems engineering (see
http://en.wikipedia.org/wiki/Systems_engineering for an explanation).
However, it is probably harder to see where the dividing line for
improvements in solutions due to systems engineering and improvements in
solutions due to use of Forth would lie.
[%X]
> 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.
...and only a systems engineering approach would be likely to find such
opportunities in the first place. The trouble is, using a systems
engineering approach, these opportunities would become more apparent no
matter what programming language was used.
> 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.
In order to keep track of the components it only takes a database that is
easy to search. That was essentially what Wolf Weiggard (of Holon fame)
did. However, you need such databases to very searchable using the sort
of terms that each individual programmer would use.
> Forth is OK for big projects. But it appears the experience with Forth
> for big projects involves first getting the specs very very clear.
Always a good start on any project.
[%X]
> This works, but it doesn't get such obviously great results
> that lots of managers want to try Forth for large software projects.
Yet Forth has been used for some truly massive projects with a great deal
of success.
> How could Forth break into the large-project market?
Given that your number guesses are anywhere near right why would we want
to? The only large system projects that would occupy a single system
that I could think of would be massive database projects (National
Health Records, Licencing Records etc). I am not sure that I would
consider projects in that vein but I am sure there are those Forthists
who would.
--
********************************************************************
Paul E. Bennett...............<email://Paul_E....@topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Marcel Hendrix
[..]
> Are we going to depend
> on IQ's increasing on generation to generation, or are we going to reduce
> the next generation's comprehension requirements and work load?
Exactly 50% of any generation will have an IQ below 100 :-)
[..]
-marcel
Jonah Thomas
> Jonah Thomas <jethom...@gmail.com> wrote:
>
> > 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.
> >
> > [ ... ]
> >
> > 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.
>
> As for the Rubik's cube analogy I find it odd that
> so many people have the same reaction. Programming
> is not my first occupation, probably not even my
> twelfth, but I have translated C manuals and looked
> at other languages, and I know that Forth is the
> simplest for me.
When you're dealing with two or three items it's no trouble to keep them
on a stack. You won't forget what they do. You won't get them mixed up.
And if you do, it will come out the first time you test. This is the
sort of mistake that's hard to hide from yourself.
When you have six items it's easy to get the stack confused and it's
easier to have names for things.
Using Forth, you assume that you'll be smart enough to find a way to use
a few items at a time, and so the things that are complicated for other
people won't be complicated for you. It usually works. Every now and
then somebody posts a counterexample and we argue about it.
> As for the problem of redundancy, I think Forth makes
> it fairly easy to write words that find redundancies
> in files of Forth code. I did that in a small way a
> long time ago, and I'm not Babbage. Large-scale
> project management software for Forth must already
> exist.
It's easy to find direct repeats. You can easily go through a lot of
source code and find all the DUP ROT sequences, even when there's a
variable number of spaces or linefeeds between the DUPs and the ROTs.
But what if the other guy used SWAP NUP instead? You wind up looking for
every combination of stack operators that has the effect ( a b -- b b a
). Or every one that's likely to be there.
What if two people solve a similar problem in different ways? You
typically can't put "similar problem" into a search engine and have it
find the code that could be factored if some of the code got rewritten.
But that's the result you want.
I'm not saying it's impossible to do automation that would have a good
result, but I'm saying that to fulfill the promise of Forth in a large
project you'd need to have somebody look at all the code and understand
it well enough to see how to simplify it.
Andrew Haley
> 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.
Do you have any actual data or experience to support this, or is it
just what you've heard from somewhere?
> 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.
Or this?
Andrew.
Jonah Thomas
> "Jonah Thomas" <jeth...@gmail.com> wrote
> > 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.
>
> The same issue affects assembly doesn't it? (I'll basically use
> assembly as a synonym for FORTH for most of the rest of my response.)
>
Forth could be considered the assembler for a simplified virtual
machine. Designed to be easily extendable.
> I prefer C to
> assembly, in part, because I can focus on programming instead of
> keeping track of, losing track, tracking down, and correcting the
> register, stack, and memory locations of variables... For assembly,
> I've spent unknown amounts of time on this. I spend no time for it in
> C. It's just handled correctly.
Done right, this is not a time issue for Forth. It takes as long to
define your variables as it does to comment your stack.
> > ... you're
> > handling details the compiler could do better and it costs you in
> > efficiency.
>
> That's true too. Well written C can almost match assembly.
Carefully-written Forth compilers come within shouting distance of C.
Pretty impressive considering how few Forth programmers are involved in
writing them.
> > The Forth promise is that the extra thinking will pay off.
>
> That makes quite a few assumptions about people's abilities. It
> implies"practice makes perfect," but assumes the result of extra time
> and thought happens to be productive and not wasteful - "going 'round
> in circles". My academic experience has proven to me very few people
> can solve problems. And, of those that can solve problems, very few
> can actually think. I've seen numerous people deemed "exceptionally
> bright," supposedly far brighter than me in most cases, who could
> solve numerous problems as effectively as I, not be able to solve
> similar problems if a trivial change was introduced... This is a
> strong indication to me that they'd developed some method to solve
> problems without real comprehension of the problem.
Sure. It only works for the people it works for. Before I started using
Forth I thought the biggest thing that made me good at programming was
that I could hold a lot of detail in my mind at once. I could look at
the output of a complicated buggy program and easily guess where the
problems were, and fix them. When I tried Forth I started with a Forth
system that came with 8 pages of documentation. There were two pages
that listed the commands with short comments about what they did, and 6
pages that explained how to write a colon definition, CREATE DOES>
VARIABLE CONSTANT and control structures. I picked up that stuff pretty
quick but my coding methods didn't work. I'd write a long string of code
and get stuck in stack comments 17 items deep. It was slow and
confusing. I thought, other people can write in Forth, why can't I? Are
they smarter than me? I didn't want to admit I wasn't smart enough to do
it, so I kept trying. It didn't work. Then I tried to make it as simple
as I could hoping I could at least get something done that way. And that
was just fine. All of a sudden I was getting stuff that worked, that
very often worked right the first try. The smaller the procedure, the
more likely it worked right the first time.
I think a lot of people say "I'm smart and I'm good at what I do, and
Forth doesn't work for me. So Forth is bad." Maybe some people who're
not good at other computer languages would be good at Forth because some
of the needed skills are different.
> > 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.
>
> All of your statements can be applied legitimately to the argument for
> using variables and not the stack or registers... Each thing you must
> do to solve a problem in code has the potential to introduce error.
> From that perspective, which is more likely to reduce coding errors:
> 1) keeping track of variables by yourself or 2) not keeping track of
> variables by yourself? The variable tracking has already been solved
> and debugged in a HLL, like C, so these are all true when it comes to
> using variables:
If you use global variables and you don't initialise them, you can
occasionally run into hard-to-find bugs when you re-use a name and
clobber some of your results.
If you use global variables and you do initialise them, you have the
bother of initialising them each time and the possibility you'll make
mistakes doing that. But it will tell you when you re-use a name that's
in scope. There's a place for global variables but it's better not to
overdo it.
If you use locals then you have to initialise them each time. Most Forth
routines ought to be short enough that you get very little benefit from
locals. There's a place for local variables but it's better not to
overdo it.
> 1) "That the simplicities will work together so that you'll wind up
> with less total work."
> 2) "Fewer places for bugs to hide means faster debugging and the
> possibility for actual correct code."
> 3) "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."
>
> The question in my mind is, "If someone or something else can solve
> the problem, why must the rest of society be forced to waste time and
> resources resolving the problem over and over again?"
If it's harder for you, you don't have to do it that way. In Forth you
can define as many variables as you want and use them. If you don't like
having to do @ ! on variables, you can use values that present their
data and you use TO [name] to put new data in. Or you can use locals
that do the same thing.
VALUE A
VALUE B
VALUE C
: 2+2=4
2 TO A
2 TO B
A B + TO C
C . ;
This looks kind of ridiculous to me, but it works.
10 a=2
20 b=2
30 c=a+b
40 print c
It's more complicated than the same thing in Basic because you have to
declare your values first.
: 2+2=4
2 2 + . ;
Is this really harder? As long as the routine is simple, it shouldn't be
hard.
10 PRINT 2+2
You can do some simplicity in Basic, too.
> How many people have to spend
> their lives mastering mathematics, when those who came prior could've
> provided solutions to real world problems instead of providing books
> of problems to solve? Shouldn't we be producing means to advance the
> next generation from our generation's "solved problems" to the next
> generations"unsolved problems"? How do we expect the next generation
> to advance if they are well over age sixty before an exceptionally few
> of them have learned enough to solve more challenging problems? Are
> we going to depend on IQ's increasing on generation to generation, or
> are we going to reduce the next generation's comprehension
> requirements and work load?
It's a problem. To some extent you have to understand what's come before
or you won't know which problems are unsolved. You can spend your life
re-inventing the wheel. But when it takes too long to understand that,
it's bad. So we have a continual process where we try to simplify the
existing knowledge to make it easier to learn, so we'll have the
headspace to learn more. Sometimes we wind up throwing away stuff that
could be useful because nobody has the time to learn it. I noticed that
with microbiology, there are lots of things from the early 1900's and
late 1800's that you can sort of read about now, but that nobody really
follows anymore. Work done on bacterial cultures that nobody maintains.
If you look you could surely find similar cultures, and if you try you
could figure out enough of how they were grown to get similar results,
and you could do a lot more with the new methodologies -- but nobody
has.
> Your statements could also be applied to learning mathematics. I had
> four semesters of Calculus (plus AP Calculus in HS), Differential
> Equations, Engineering Mathematics, only to learn that 98% of all
> Calculus problems that I'd ever face in engineering can be solved with
> Laplace Transforms. Basically, all math from Linear Algebra (10th
> grade?) in HS to my senior year in college was a complete waste... of
> time, money, energy, life. And, in reality - since I didn't end up in
> engineering - I never needed any of it.
Figuring out how the math worked has been good for me. It provided
techniques that have been useful for other things too. Sometimes they're
useless -- mathematical reasoning is if anything worse than useless for
legal problems, for example -- but often it works. YMMV.
> > 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?
>
> I want someone who can both think and can correct the cause, not the
> effect, of a problem effectively and correctly. But, that's not what
> employers I've worked for cared about. They cared about: people
> getting to work on time, making unrealistic deadlines, denying people
> raises because performance goals weren't met and then giving millions
> to charity, paying as little as possible to the least experienced and
> poorest thinkers they could get who'd do the job - "cut 'n' paste",
> being able to tell upper management the problem was fixed - without
> telling them it was buggy, inefficient, and would require much rework
> and costs later - "job preservation", rewarding employees for solving
> "big" problems - even if that same employee created the "big" problem,
> etc.
So, simple factoring doesn't work well for management. Try to divide a
problem into pieces and assign them to different people, and the people
tend to want job preservation, which means their part of the problem is
never actually solved but only managed. It's hard to divide up the
problem into pieces with clear interfaces, so one guy can do sneaky
sabotage that gets the failure blamed on somebody else. Without a clear
method to detect quality, how can they pay for quality? If they're
likely to get shoddy work even with high pay, why not pay less and still
get shoddy work?
It's a problem and Forth doesn't give us a solution. Find a good
solution to the management problem, start a company, build it up, split
it into two good companies, build them up, in 5 generations you might go
a long way toward taking over the country.
> > 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.
>
> There are a number of language design differences that "bloat" C
> compared to FORTH. I see little reason why a C variant (might not be
> ISO C compliant) couldn't produce code as compact.
Yes, and when that gets done well Forth might be driven out of that
market niche. Why pay for a Forth expert when you can get results that
are almost as good by hiring an average C programmer and giving him a
great compiler?
> > Forth has also done well for things like debugging hardware
> > interfaces. Very interactive, easy to modify it for low-level
> > details, etc.
>
> I still miss the interactiveness of interpreted BASIC as compared to
> assembly or C. But, you either get a compiler or interpreter - it's
> rare, except for some FORTHs - to get both. Today, you have to
> produce compiled code...
With some modern Forths you can produce compiled code and still keep it
supremely interactive. Even on a small microcontroller.
> > 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.
> Isn't the "redundant code" issue either a lack of a standardized
> library or a lack of separation of tasks?
Yes. If you already have a good standardised library then everybody can
use what they need from it. Or if you have a standardised library that
partly fits the needs everybody can contort their code around it. If
you're building the special-purpose library for the particular project,
somebody has to notice what's needed and build the library, except
everybody else is busy coding while the library is being built. You
don't always know what you'll need until you see it being used.
Separation fo tasks at least keeps people out of each other's way. But
there are likely to be libraries that could be profitably used within
the different separate tasks. You lose some chances for simplification
if you don't follow up on that. The more people involved, the harder it
gets to keep it simple. The "surgical team" approach can help. Get one
great programmer in at the beginning, who organises the project, and
then bring in assistants as he finds use for them. They can design
widgets for him. The lowest-level code is the most likely to be mostly
independent.
Jonah Thomas
> Jonah Thomas <jeth...@gmail.com> wrote:
>
> > 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.
>
> Do you have any actual data or experience to support this, or is it
> just what you've heard from somewhere?
My own experience with large projects is limited to a minor role in one
project that Elizabeth Rather had a very large role in. I wouldn't say
that my view of that particular example is clearer than that of the
various people who were more central. It's my best guess, based on my
limited experience and what I've heard from others.
My guess that it takes half as long to understand somebody else's code
well enough tp optimally factor it as it would to write it is only a
guess. Depending on the details some code might be far easier to
understand.
> > 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.
>
> Or this?
It's indisputible that we don't have lots of managers who want to try
Forth for large software projects.
We have a few examples of large Forth software projects that succeeded.
The Riyadh airport. OTA. Others? Sendit? These are kind of old. We have
a few examples of large Forth projects that failed. Valdocs. IBMCAD
(which didn't completely fail). Even older. These are not such obviously
great results that lots of managers want to try Forth. I'm clear on that
much.
I say that Forth is OK for big projects, based on the successes. I don't
know how often large Forth projects follow the pattern I describe, but
how many projects are we talking about? If you'd like to disagree I'll
be fascinated to hear about your experience and/or opinions. It might be
safer to say that there isn't enough data to have an opinion, but I'd
rather try things out and see where they lead.
My opinion is that there aren't enough active, accredited and available
Forth programmers at any one time to support more than one large
project. So large Forth projects will be anomalies. Even if more than
one manager wants one, we can't do it except by filling out with lots of
relative newbies.
To the extent that corporate culture increasingly wants large projects
instead of small ones, Forth's place shrinks even more. How can Forth
keep a niche in an biome of large projects? Possibly Forth could fill
the rapid-development niche? Build the quick prototype in Forth while
the other-language team chugs along behind. Possibly Forth could fill
the testbed role. Quickly build the scaffolding to test the production
code. Etc.
I have the idea that a team of 3 Forth programmers will generally be
more credible than a single Forth programmer in that environment. I
don't have anything to support this idea, it just makes sense to me. If
you like you can try it both ways and see what works. Multiple Forth
teams competing for the same slot would look more credible than a single
team. One Forth programmer might be mistaken for a lone kook. One Forth
team gets compared to, say, a Python team to do the same work, and the
Python team would tend to look better other things equal because the
Python language is newer. Three Forth teams might tend to get compared
to each other. Pretty much anything you do, it won't look as radical if
you aren't the only one doing it. Just an idea.
Andrew Haley
> code well enough to optimally factor it as it would to write it is
> only a guess. Depending on the details some code might be far easier
> to understand.
OK, but I'm not at all sure how much of this is dependent on a
particular programming language. Most of these issues are to do with
software development management, and happen with all programming
languages.
>> > 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.
>>
>> Or this?
> It's indisputible that we don't have lots of managers who want to
> try Forth for large software projects.
> We have a few examples of large Forth software projects that
> succeeded. The Riyadh airport. OTA. Others? Sendit? These are kind
> of old. We have a few examples of large Forth projects that
> failed. Valdocs. IBMCAD (which didn't completely fail). Even
> older. These are not such obviously great results that lots of
> managers want to try Forth. I'm clear on that much.
> I say that Forth is OK for big projects, based on the successes. I
> don't know how often large Forth projects follow the pattern I
> describe, but how many projects are we talking about? If you'd like
> to disagree I'll be fascinated to hear about your experience and/or
> opinions. It might be safer to say that there isn't enough data to
> have an opinion, but I'd rather try things out and see where they
> lead.
I guess I don't have much data either, so I'm certainly not going to
push a definite opinion, pro or anti, about the suitability of Forth
as a programming language for large projects.
For what it's worth, I'm not convinced that the choice of programming
language has the biggest impact: when things go awry in a programming
project it's usually due to higher-level problems such as the lack of
processes for testing and code review, or just bad design. When a
well-managed team discovers that the lack of some abstraction layer or
well-defined interface, they refactor, redesign, and create that new
set of interfaces. And they do that in C, Forth, COBOL, whatever. Of
course, if the language or its implementation makes this very hard, or
if your programmers are no good, you're doomed.
Andrew.
William James
> 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.
You are dishonest, or illogical, or both.
If you want your brain to do all of the work,
then don't use a computer. Ever. Understand?
> And Forthers say that with a data stack we get a simpler compiler
Untrue. Only those whose highest ambition is flushing a
toilet say that.
And why would the one using a compiler want it to be
as simple as possible? That's what the lazy creator
of the compiler would want: "Let the users do most of
the work, not me."
> and we get simpler subroutine calling. We're encouraged to factor
> deeper, and that helps us write simpler code.
Untrue.
> 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.
Untrue.
For example, you posted this stack spaghetti:
: BOX4 ( x1 y1 x2 y2 -- )
2>R
R'@ OVER 2R@ LINE
OVER R@ 2R@ LINE
2DUP OVER R> LINE
R> OVER LINE ;
Those of you who are honest and willing to think
will note the lack of factoring, the unreadability.
and the multitude of places for bugs to hide.
It is as though the programmer set out to generate
the worst possible gibberish. Anyone who thinks
that this is acceptable code has a gigantic
mental blind spot.
I would never hire a programmer who produced
code like that. I would never hire a "programmer"
who had a paranoid fear of local variables.
> 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.
The code you posted was hideously complex.
>
> 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
You are capitalizing it as though it were your god.
I think that this is a religious belief that has no
connection with facts or reason.
> can't
> pay off except for programmers who think of ways to keep it simple.
As simple as your BOX4?
Or as simple as one approach using locals:
: from_corner { x y xx yy -- }
x y xx y line
x y x yy line ;
: box { x y xx yy -- }
x y xx yy from_corner
xx yy x y from_corner ;
Jonah Thomas
> > 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
>
> You are capitalizing it as though it were your god.
> I think that this is a religious belief that has no
> connection with facts or reason.
I'm trying to state the essential thing that keeps Forth programmers
using Forth. When you just experience it, you don't necessarily know how
to say it. I'm trying to say it and I may not be doing a good job of
that.
What is it that keeps you using Forth? Why haven't you moved on to
Python or Ruby or whatever?
John Doty
But what really matters is what caused old Forthers to move on, and what
keeps new ones away. We stubborn die-hards are not typical.
--
John Doty, Noqsi Aerospace, Ltd.
http://www.noqsi.com/
--
History teaches that logical consistency is neither sufficient nor
necessary to establish practical, real world truth. Those who attempt to
use logic for that purpose are abusing it.
John Passaniti
> 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?
Your message is chock full of false dichotomies. You started with the
false dichotomy of choosing Forth or another language. That ignores
that you can also choose both, using Forth where it gives maximum
benefit and other languages where they excel. Most systems of any size
are decomposable into cooperative subsystems, and each of those
subsystems can be individually considered for what language is most
appropriate for the expression of the solution to a problem.
You next move into the false dichotomy of paying people to think or pay
people to crank out solutions. I work for a company that has clients
who want both. Some clients are paying us to come up with the smallest,
most elegant, well thought-out solutions we can. Then we have clients
who say, "we have a trade show in 25 days and we need to show a
prototype there." So there are times when we're all huddled around a
whiteboard diving into details, and other times when we're slapping
together existing solutions.
Neither is right or wrong. It depends on the needs of the client, the
product lifetime, the level of innovation in a system and so on.
> 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.
In other words, Big Design Up Front projects that follow strict
waterfall processes and that turns programmers into mindless robots
following orders.
> 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.
I love how nearly every discussion in comp.lang.forth that discusses
project management usually degenerates into a series of insults about
management.
Here's a more realistic view: Large projects are large because they do
more, and they incorporate a wider set of skills. The largest project I
was on had 30 engineers on it. Why? Not because they wanted to get
"institutional respect" but because the project was complex. There was
low-level hardware that needed device drivers. There was gateware that
needed experts in FPGAs. There was high level software to provide a
sophisticated web interface. There was some mid-level connectivity
software that had to talk to other systems. There were real-time
aspects. There were scripting aspects. There was some sophisticated
algorithms. There was some dumb "jellybean" code. We needed people who
were aware of some esoteric networking technology. And we needed people
who could just slap some scripts together.
It was a large project because it was... large. It combined the skills,
interests, and insights that would be extremely unlikely to find any one
person had.
Jonah Thomas
> Jonah Thomas <jeth...@gmail.com> wrote:
> > My guess that it takes half as long to understand somebody else's
> > code well enough to optimally factor it as it would to write it is
> > only a guess. Depending on the details some code might be far easier
> > to understand.
>
> OK, but I'm not at all sure how much of this is dependent on a
> particular programming language. Most of these issues are to do with
> software development management, and happen with all programming
> languages.
I agree. My point is that when one person designs an application of
reasonable size, he *can* factor ruthlessly. He can wind up with an
application that's much smaller than it might be in another language
where programmers don't try so hard to factor.
When 10 Forth programmers work together on a large application, each of
them can factor his own code ruthlessly, if they're a mind to. But it's
much harder for them to factor *everybody's* code. I don't say it's
impossible, and of course it's better to have 10 programmers each
factoring their own work than 10 programmers doing bloat. And it's
possible to factor without using Forth. My claim is that it's harder to
get the best factoring when the work is being done by 10 people than by
1 person, whether you're attempting to factor in Forth or in some other
language.
Forth is designed to make it easy to factor. Forth has weaknesses that
mostly show up when you don't factor. Forth's strengths will be less and
the weaknesses greater when the sheer size of a project (and especially
the number of people involved) makes it harder to factor. Other
languages have different tools designed to help them handle unfactored
code, Forth has less of that because the intention is that you will
factor well.
> I guess I don't have much data either, so I'm certainly not going to
> push a definite opinion, pro or anti, about the suitability of Forth
> as a programming language for large projects.
We have examples of Forth being used successfully for large projects. So
it's known to be possible. We have dozens of Forth programmers who've
participated in large Forth projects that can be publicly revealed. We
have two? three? five? software managers who've helped to manage a
successful large Forth project. Unless there are large military Forth
projects whose existence must be kept secret, we don't have a large body
of trained people for large Forth projects. It has been done. It will be
done again when there's a customer who wants it. I'm not holding my
breath. In the meantime, Forth programmers may find ways to fit into
smaller niches in large projects. Carve out a piece of it that can be
handled by a team of three Forth programmers, and find a way to get the
contract for that piece.
> For what it's worth, I'm not convinced that the choice of programming
> language has the biggest impact: when things go awry in a programming
> project it's usually due to higher-level problems such as the lack of
> processes for testing and code review, or just bad design. When a
> well-managed team discovers that the lack of some abstraction layer or
> well-defined interface, they refactor, redesign, and create that new
> set of interfaces. And they do that in C, Forth, COBOL, whatever. Of
> course, if the language or its implementation makes this very hard, or
> if your programmers are no good, you're doomed.
Agreed. Forth and maybe Python, Ruby, etc are supposed to make it easy.
But what they can do is stay out of the way when you're going after the
actual problems that need to be solved. If Forth gets in the way 1%
while C gets in the way 60%, thats important. If Forth gets in the way
1% while Python gets in the way 8%, that isn't as important. You can say
it's 8 times as good at staying out of the way, but for productivity
that translates to 99/92. Not a big deal. I should include the
disclaimer that these numbers are entirely made up out of nothing, to
get an idea across.
The point of a programming language is to let you solve the problems you
have to solve to make the application work. It gets in the way, and the
better it stays out of the way the better it works. As languages get
better at staying out of the way, the value of further improvements goes
down. The less your time gets wasted struggling with the language, the
less room for improvement there is for better language. Any language
that lets you spend 80% of your time actually solving your problems and
20% or less of your time fighting the language, will come out about the
same. Improvements in that last 20% will tend to get lost in the noise.
Guy Macon
Rod Pemberton wrote:
>Well written C can almost match assembly. But, I usually
>can't out code a C compiler, in assembly, in areas where it's optimization
>are strong: constant folding and constant propagation. Although, there are
>places where C compilers aren't strong and hand coded assembly can
>outperform a compiler.
A few biased opinions:
A really good assembly language programmer will always outperform
even the best C compilers.
The kind of assembly language programmer that you can actually
find and hire will, in general, underperform the best C compilers.
If the job is big enough, it may take that good assembly language
programmer longer than the heat death of the universe to outperform
the best C compilers.
If the program spends 99% of the time executing 1% of the code,
it is stupid to code the whole thing in assembly.
A good Forth programmer will usually write code that outperforms
the code written by the kind of assembly language programmer that
you can actually find and hire by doing a better job of factoring.
A really good assembly language programmer knows this and uses
forthlike techniques where appropriate, thus once again coming
out ahead.
Elizabeth D Rather
...
>
> When 10 Forth programmers work together on a large application, each of
> them can factor his own code ruthlessly, if they're a mind to. But it's
> much harder for them to factor *everybody's* code. I don't say it's
> impossible, and of course it's better to have 10 programmers each
> factoring their own work than 10 programmers doing bloat. And it's
> possible to factor without using Forth. My claim is that it's harder to
> get the best factoring when the work is being done by 10 people than by
> 1 person, whether you're attempting to factor in Forth or in some other
> language.
That's a strange view of how groups work. The project manager's job is
first to factor the *project* into semi-independent tasks that the
different programmers can work on. They will have fairly little
overlap, and it's absurd to expect anyone to factor anyone else's code.
The 10 (or so) programmers will agree on interfaces between their
respective modules, but are not otherwise responsible for anyone's code
but their own.
What *does* happen is that someone will see a needed facility that he
senses must be a common need. So, he says (or emails) "has anyone
developed a word to do <this>?" And if someone has, it will be shared.
If not, they'll discuss briefly what would make it generally useful,
and it's developed and shared.
As I've said before, if the team members agree on a common style of code
layout and commenting, the sharing is easier. And, if John Doty is
reading this, I'm not talking about imposed "rigid standards," but a
mutually developed and agreed-upon set of guidelines. If the group
develops and agrees on them, they're usually willing to follow them,
because they see the mutual benefit in doing so. And if someone isn't
playing along, peer pressure is quite effective.
If it's a really big project (multiple companies, etc.) there will be
multiple teams, each of which will work out its own internal practices,
and figure out how best to work with the other groups. Usually there's
a lot less task overlap between entirely separate teams, so less need
for this kind of intimate sharing.
And nothing in these paragraphs is in any way peculiar to Forth.
...
>> For what it's worth, I'm not convinced that the choice of programming
>> language has the biggest impact: when things go awry in a programming
>> project it's usually due to higher-level problems such as the lack of
>> processes for testing and code review, or just bad design. When a
>> well-managed team discovers that the lack of some abstraction layer or
>> well-defined interface, they refactor, redesign, and create that new
>> set of interfaces. And they do that in C, Forth, COBOL, whatever. Of
>> course, if the language or its implementation makes this very hard, or
>> if your programmers are no good, you're doomed.
Correct. And if your project management is no good you may be doomed
regardless of how good your programmers are. I've seen projects in
which excellent programmers have tried to work things out despite truly
awful managers. Sometimes that works, but it's difficult.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Jonah Thomas
> Jonah Thomas wrote:
> > 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?
>
> Your message is chock full of false dichotomies.
Yes, agreed. I've resolved some of them.
> You started with the
> false dichotomy of choosing Forth or another language. That ignores
> that you can also choose both, using Forth where it gives maximum
> benefit and other languages where they excel.
Yes, that was my conclusion. There are very few large projects that are
done entirely or even mostly in Forth. But Forth could capture smaller
niches in large projects.
> You next move into the false dichotomy of paying people to think or
> pay people to crank out solutions.
I didn't mean that to be a false dichotomy. The basic ideas that claim
Forth has an advantage, claim that Forth has an advantage for
programmers who think. We haven't claimed an advantage on the other
side. Should we?
Forth is good for factoring, and factoring is good for simplicity, and
simplicity is good for debugging speed, and correctness, and easier
maintenance. Forth is also good for being interactive which is good for
debugging speed and development speed and maintenance. But there are
lots of other interactive languages now. So I stress the factoring.
Factoring is good for people who think. It does not give Forth an
advantage for employers/customers who want people to quickly crank out
routine solutions. This is a limitation for Forth. I don't see what to
do about it beyond try to be good at what Forth is good at.
> Neither is right or wrong. It depends on the needs of the client, the
>
> product lifetime, the level of innovation in a system and so on.
Agreed.
> > 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.
>
> I love how nearly every discussion in comp.lang.forth that discusses
> project management usually degenerates into a series of insults about
> management.
This stereotype is not limited to Forth. See for example Kelly Johnson's
Rule #14.
http://en.wikipedia.org/wiki/Kelly_Johnson#Kelly_Johnson.27s_14_Rules_of_Management
There's a time-honored tradition that part of managers' compensation is
related to the number of people they manage. That wasn't invented on
clf. Of course it isn't true everywhere, as Kelly Johnson and others
have created counterexamples.
> Here's a more realistic view: Large projects are large because they
> do more, and they incorporate a wider set of skills. The largest
> project I was on had 30 engineers on it. Why? Not because they
> wanted to get "institutional respect" but because the project was
> complex. There was low-level hardware that needed device drivers.
> There was gateware that needed experts in FPGAs. There was high level
> software to provide a sophisticated web interface. There was some
> mid-level connectivity software that had to talk to other systems.
> There were real-time aspects. There were scripting aspects. There
> was some sophisticated algorithms. There was some dumb "jellybean"
> code. We needed people who were aware of some esoteric networking
> technology. And we needed people who could just slap some scripts
> together.
>
> It was a large project because it was... large. It combined the
> skills, interests, and insights that would be extremely unlikely to
> find any one person had.
Sure. And they chose that 30-person project instead of two 15-person
projects that would predictably be faster and cheaper to complete
because.... because it worked for them to. They had a reasonable belief
that this one could be a success, that's vital. Was it the most
plausibly profitable use of those resources? Maybe. Maybe the corporate
climate had something to do with it too. Some people's career trajectory
might have benefitted more from this project than a smaller one. Etc.
I'm in no position to say that's true -- I don't know anything about
your project except what you say about it. But is it at all plausible
that nontechnical factors might have had some influence on which viable
project was undertaken?
I predict that average project size is likely to continue to increase,
even though large projects often fail. Sometimes we'll see large
projects that could plausibly be described as conglomerations of many
small projects that are only loosely linked. These might be managed as
if they were independent small projects, and so might have a greatly
increased chance of success. But they'll be described as large projects
and funded as large projects.
I don't claim any tremendous expertise about such things. But I think
you're agreeing with my conclusions even though you disapprove of some
of the stereotypes I base those conclusions on. We can expect increasing
project size and Forth will mostly not be the dominant language for
these projects. For Forth to have a role in any of them, we need
relatively small niches that Forth can fill inside the large projects.
Which you have been doing. You prove it's possible.
Bruce McFarling
> 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.
This has been hard for me to get a handle on, but I think that what
John (quick, copy and paste) Passaniti said crystallized it for me.
On the one hand, this reads like you are trying to engineer a
solution to winning a Usenet news argument. "I say toe MAY toe,
you say toe MAH toe ...".
And on the other hand, it sounds like you are trying to engineer
a solution to winning the hardest possible market to reach, rather
than looking for niches within reach but out of the present grasp
to reach for.
After all, the key to getting Forth into big projects is to have
(1) people who have a niche skill needed in a number of big
projects who (2) prefer to use and are more productive in Forth
and (3) have experience with using Forth to drive modules in
different languages and providing bindings that can easily be
driven by other languages.
Getting there would seem to be a matter of, in no particular order:
(1) Tools in Forth for sharing solutions more easily
(2) Repositories for collecting solutions that do, in fact, receive
contributions
(3) Collections of bindings in Forth for other languages / libraries
(4) Collections of Forth bindings for other languages / libraries
(5) Lots of little projects in lots of areas
There is, I think, no "The" Forth promise.
There is, rather, a distinctive cluster of traits that has an
internally coherent logic, and that is the strategic space that Forth
occupies.
There is also a wider collection of characteristics that Forth has
inherited from its original legacy as being able to be a customized,
special purpose BDOS and BIOS on systems "too small" to have a general
purpose BDOS and BIOS, a customized, tailored OS on systems "too
small" to have a general purpose OS, a tailored, special purpose shell
on systems "too small" to have a free-standing shell, etc. One problem
with that was that individual Forth programmers sometimes fell prey to
Not Invented Here syndrome.
There's no reason that Forth can't "play well with others". The
example brought up in this newsgroup this last week of the Forth for
the HP-71B ... it was a model of integration with the HP-71B system,
and in particular of the facilities for co-residing with and calling
into Basic. I saw it mentioned, indeed, as the in-system development
platform of choice for the HP-71B, and reading the description of the
development of the Forth, important clues for its success might be
found in the combination of effective integration with the rest of the
system and inclusion of support for "normal" assembler syntax in CODE
words.
And, further, there's been no evidence advances to support the premise
that getting Forth a big role in big projects is going to provide the
biggest bang for the effort expended in terms of getting more people
to use Forth.
The C64DTV may be just a retro games joystick, but if it was
programmed to use Quickwriting as an input in its one joystick port,
and the second joystick port brought out as a port rather than used
for auxiliary control buttons, 1Mb of internal Flash Ram and the lines
to drive two SPI devices, with display on a $20-$30 5" CRT color TV,
gives quite a bit of possibility in a setting like the Democratic
Republic of Congo. It certainly was not developed for that purpose,
but, if the producers were to fix the PAL resister ladder
manufacturing glitch, it exists. Now, that is a context where the
traditional Forth legacy comes in handy. But it would be far better if
the Forth was integrated as well with the C64 system as the HP-71B
Forth was with the HP-71B system.
And never forget that those who use computers daily and could benefit
from a little bit of programming to tailor their programs to their
specific needs outnumber all computer programmers by a wide margin. On
the question of whether "a lot of thinking" to come up with elegant
solutions has any leverage ... a "lot of thinking" to come up with
elegant solutions for comfortable, effective, safe and powerful macro
programming tools for normal people would go a long way. But to get
there, instead of hypothesizing about ninja Forth programmer teams
spreading across the country, would require things like volunteering
to teach word processing skills at the local community center, to find
out what are the things that get in the way of regular people making
more effective use of the bloatware they are struggling to cope with.
Bruce McFarling
> A good Forth programmer will usually write code that outperforms
> the code written by the kind of assembly language programmer that
> you can actually find and hire by doing a better job of factoring.
> A really good assembly language programmer knows this and uses
> forthlike techniques where appropriate, thus once again coming
> out ahead.
So does this mean that a really good programmer who uses Forth for his/
her main programming and drops down into assembly for the 1%-10% where
the program spends all its time will be able to turn around to the
assembly language programmer and say, "I, as a Forth programmer, can
crank out code faster than you", and turn around to the Forth
programmer and say, "I, as an assembly language programmer, can crank
out code that's faster than yours." ?
Jonah Thomas
> Jonah Thomas wrote:
> ...
> >
> > When 10 Forth programmers work together on a large application, each
> > of them can factor his own code ruthlessly, if they're a mind to.
> > But it's much harder for them to factor *everybody's* code. I don't
> > say it's impossible, and of course it's better to have 10
> > programmers each factoring their own work than 10 programmers doing
> > bloat. And it's possible to factor without using Forth. My claim is
> > that it's harder to get the best factoring when the work is being
> > done by 10 people than by 1 person, whether you're attempting to
> > factor in Forth or in some other language.
>
> That's a strange view of how groups work. The project manager's job
> is first to factor the *project* into semi-independent tasks that the
> different programmers can work on. They will have fairly little
> overlap, and it's absurd to expect anyone to factor anyone else's
> code.
> The 10 (or so) programmers will agree on interfaces between their
> respective modules, but are not otherwise responsible for anyone's
> code but their own.
Sure.
> What *does* happen is that someone will see a needed facility that he
> senses must be a common need. So, he says (or emails) "has anyone
> developed a word to do <this>?" And if someone has, it will be
> shared.
> If not, they'll discuss briefly what would make it generally useful,
>
> and it's developed and shared.
That seems to me like a good way to get some needed shared
functionality. Some things will be useful across the semi-independent
tasks. Sometimes people will notice that early. You can wind up with
libraries of code that's useful in multiple contexts.
I want to believe that a really good Forth programmer will tend to do
that extremely well for his own code. And he can make a start at doing
it for everybody's code, where he "senses" the common needs. My
expectation is that his "sensing" will be less efficient than when he
does it for his own code where he knows everything that's going on. The
result would tend to be more bloat than you'd get in a smaller project
done by fewer people. I wouldn't expect this to be controversial. Good
Forth guys would predictably make less bloat than programmers with other
languages who aren't trying so hard to factor. They'd have a harder time
of it on large projects than on smaller ones.
> As I've said before, if the team members agree on a common style of
> code layout and commenting, the sharing is easier. And, if John Doty
> is reading this, I'm not talking about imposed "rigid standards," but
> a mutually developed and agreed-upon set of guidelines. If the group
> develops and agrees on them, they're usually willing to follow them,
> because they see the mutual benefit in doing so. And if someone isn't
>
> playing along, peer pressure is quite effective.
Agreed.
> If it's a really big project (multiple companies, etc.) there will be
> multiple teams, each of which will work out its own internal
> practices, and figure out how best to work with the other groups.
> Usually there's a lot less task overlap between entirely separate
> teams, so less need for this kind of intimate sharing.
Yes, and so less well-factored shared code and more bloat. Not in any
way a show-stopper. Just not as close to optimal as you can get with
reasonable effort on a smaller system.
> And nothing in these paragraphs is in any way peculiar to Forth.
Agreed, except that with Forth there's likely to be much more of an
attempt to reduce unneeded complexity and reduce redundancy etc. If
Forth on a large project is less successful at that than Forth on a
smaller project, still it should predictably be far better at it than
efforts where that isn't much of a consideration.
> ...
> >> For what it's worth, I'm not convinced that the choice of
> >programming> language has the biggest impact: when things go awry in
> >a programming> project it's usually due to higher-level problems such
> >as the lack of> processes for testing and code review, or just bad
> >design.
>
> Correct. And if your project management is no good you may be doomed
> regardless of how good your programmers are. I've seen projects in
> which excellent programmers have tried to work things out despite
> truly awful managers. Sometimes that works, but it's difficult.
Sure. The biggest show-stoppers are not language-related, any adequate
language is likely to be adequate if everything else works out.
I ask, what does Forth offer that other languages don't, particularly.
Your company and MPE can offer extremely talented individuals who would
be extremely talented whatever language they used. That's great for you
and MPE, but it doesn't say much about Forth.
Forth allows great interactive stuff. Forth is not unique in that any
more, that isn't so special.
Professional Forth systems provide a simple toolchain that's pretty well
debugged, it doesn't pull a lot of surprises that people have to program
around. That's increasingly true for other languages too, though it
still tends to be somewhat less true.
Forth allows and encourages (and somewhat depends on) a whole lot of
factoring. More than any other language. It's embedded in the Forth
culture, it's made easy with Forth tools, and Forth tools tend not to
make it easy to avoid factoring. Factor too little and your code gets
hard to read and hard to debug, and if you haven't paid attention to any
previous warning signs that ought to do it.
I think this is what Forth provides that you won't easily find
elsewhere. It's possible to factor in other languages. People who're
good at it can write Forth in any language, kind of like the guys who
write Pascal in any language. But factoring is a signature strength for
Forth. Adequate Forth programmers will do it well. Genius Forth
programmers will simplify so thoroughly they make it look easy.
Is there disagreement about this part? Is this not a central Forth
advantage? Are there other important advantages that no one has caught
up to?
If you agree this far, here's my second idea. Other things equal, I'd
expect that the bigger the project, the bigger the advantage for Forth.
The bigger the project, the more room for cruft. The more redundancy.
The more people writing code that does similar things but not quite the
same, that they don't factor. The bigger the project, the more chances
for excess complexity to bite them. The bigger the complexity problem,
the more room for Forth to shrink things. It follows logically, other
things equal. The bigger the system, the more room for unneeded
complexity to hide. At one size a good Forth solution might be half the
size of a good C solution. At a bigger size it might be a quarter the
size. At some bigger size still the Forth solution might be a tenth as
big.
But other things aren't equal. Large numbers of Forth programmers have
their communication problems too. So I expect clutter to build up in
large Forth projects also, though not at the same rates you'd expect for
other languages. This seems reasonable to me, and plausible, and you
seem to agree. It may have sounded like I was saying that it shouldn't
be that way, that there was something wrong with Forth to make it that
way. I don't mean to say that.
Here's my tentative conclusion -- if as I tend to think, Forth provides
its biggest force-multiplier on projects that can be completed in a
reasonable time by one to three Forth programmers, then maybe that's a
good size project to go after. Maybe Forth could be used for a part of a
larger project, if there are more large than small projects available.
It's easier to find teams of three Forth programmers than teams of 30,
so that's another plus.
Robert Miller
"William James" <w_a_...@yahoo.com> wrote in message
news:b8aa71fb-ae8f-4158...@e6g2000prf.googlegroups.com...
>
> As simple as your BOX4?
>
> Or as simple as one approach using locals:
>
> : from_corner { x y xx yy -- }
> x y xx y line
> x y x yy line ;
>
> : box { x y xx yy -- }
> x y xx yy from_corner
> xx yy x y from_corner ;
Factoring seems to be part of the 'art' of Forth and is not something that
is well explained (in a how-to sense) anywhere I have found so far. I'm sure
I haven't yet mastered this art and certainly appreciate anything by way of
enlightenment.
Your example is undoubtedly more readable than BOX4 , and I presume you have
unintentionally omitted the LOCALS| declarations . This clearly demonstrates
the value of the locals word set but sometimes we are constrained.
Unfortunately, the Forth I'm using (SwiftX for the TI msp430) apparently
doesn't include the optional ANSI locals word set. I can envision a variant
using VARIABLE declarations for x, y, xx, and xy but that would permanantly
allocate scarce (in my application ) RAM. Would you care to venture a well
factored version of BOX4 that doesn't use locals or variables but to which
you wouldn't apply the harsh criticism you had for BOX4?
Bob Miller
Marcel Hendrix
[..]
> So does this mean that a really good programmer who uses Forth for his/
> her main programming and drops down into assembly for the 1%-10% where
> the program spends all its time will be able to turn around to the
> assembly language programmer and say, "I, as a Forth programmer, can
> crank out code faster than you", and turn around to the Forth
> programmer and say, "I, as an assembly language programmer, can crank
> out code that's faster than yours." ?
"I, as a non-participant in these discussions, turn out more of that
Forth code than all of you." :-)
-marcel
Jonah Thomas
> And on the other hand, it sounds like you are trying to engineer
> a solution to winning the hardest possible market to reach, rather
> than looking for niches within reach but out of the present grasp
> to reach for.
Good thought.
> After all, the key to getting Forth into big projects is to have
> (1) people who have a niche skill needed in a number of big
> projects who (2) prefer to use and are more productive in Forth
> and (3) have experience with using Forth to drive modules in
> different languages and providing bindings that can easily be
> driven by other languages.
>
> Getting there would seem to be a matter of, in no particular order:
> (1) Tools in Forth for sharing solutions more easily
> (2) Repositories for collecting solutions that do, in fact, receive
> contributions
> (3) Collections of bindings in Forth for other languages / libraries
> (4) Collections of Forth bindings for other languages / libraries
> (5) Lots of little projects in lots of areas
Those all look useful and some of them are vitally important.
> There is, I think, no "The" Forth promise.
Why Forth instead of Python? There are technical matters -- the Forth
compiler can be much much smaller, etc. These get progressively less
important outside small niches.
There's sensibility. A novice who learns Python has learned a
programming language. What makes it work? It just works. A novice who
learns Forth has access to a virtual machine that gives him a concept of
what the processor does. It makes sense on a much deeper level. This is
unimportant to a lot of people.
I think Forth's big emphasis on simplicity is the most important thing
Forth has to offer. It wouldn't bother me to see other very important
values or even some more important ones.
> There is, rather, a distinctive cluster of traits that has an
> internally coherent logic, and that is the strategic space that Forth
> occupies.
>
> There's no reason that Forth can't "play well with others".
Yes!
> And, further, there's been no evidence advances to support the premise
> that getting Forth a big role in big projects is going to provide the
> biggest bang for the effort expended in terms of getting more people
> to use Forth.
That's a good thought too.
> The C64DTV may be just a retro games joystick, but if it was
> programmed to use Quickwriting as an input in its one joystick port,
> and the second joystick port brought out as a port rather than used
> for auxiliary control buttons, 1Mb of internal Flash Ram and the lines
> to drive two SPI devices, with display on a $20-$30 5" CRT color TV,
> gives quite a bit of possibility in a setting like the Democratic
> Republic of Congo. It certainly was not developed for that purpose,
> but, if the producers were to fix the PAL resister ladder
> manufacturing glitch, it exists. Now, that is a context where the
> traditional Forth legacy comes in handy. But it would be far better if
> the Forth was integrated as well with the C64 system as the HP-71B
> Forth was with the HP-71B system.
That sounds good.
> And never forget that those who use computers daily and could benefit
> from a little bit of programming to tailor their programs to their
> specific needs outnumber all computer programmers by a wide margin. On
> the question of whether "a lot of thinking" to come up with elegant
> solutions has any leverage ... a "lot of thinking" to come up with
> elegant solutions for comfortable, effective, safe and powerful macro
> programming tools for normal people would go a long way. But to get
> there, instead of hypothesizing about ninja Forth programmer teams
> spreading across the country, would require things like volunteering
> to teach word processing skills at the local community center, to find
> out what are the things that get in the way of regular people making
> more effective use of the bloatware they are struggling to cope with.
That sounds good too.
Albert van der Horst
And with each new generation IQ-tests have to be adapted to accomplish
this. (People get smarter all the time.)
>
>-marcel
<SNIP>
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Bruce McFarling
> Bruce McFarling <agil...@netscape.net> writes Re: The Promise of Forth
> [..]
Certainly than any of me. I'm still trying to get my little scripts
class in Mini-OOF to work. I guaran-dam-tee you if there is nobody in
the room but the good Forth-specialized programmer, good assembly
language-specialized programmer, and programmer who is good at both
are in the room, I'm not around to hear the conversation.
Elizabeth D Rather
> John Passaniti <put-my-firs...@JapanIsShinto.com> wrote:
...
>> You next move into the false dichotomy of paying people to think or
>> pay people to crank out solutions.
>
> I didn't mean that to be a false dichotomy. The basic ideas that claim
> Forth has an advantage, claim that Forth has an advantage for
> programmers who think. We haven't claimed an advantage on the other
> side. Should we?
>
> Forth is good for factoring, and factoring is good for simplicity, and
> simplicity is good for debugging speed, and correctness, and easier
> maintenance. Forth is also good for being interactive which is good for
> debugging speed and development speed and maintenance. But there are
> lots of other interactive languages now. So I stress the factoring.
> Factoring is good for people who think. It does not give Forth an
> advantage for employers/customers who want people to quickly crank out
> routine solutions. This is a limitation for Forth. I don't see what to
> do about it beyond try to be good at what Forth is good at.
People who think often produce solutions as fast or faster than drones
who don't. Forth has a reputation for nearly 40 years of helping
thinking people produce results more quickly than other tools. So it
should appeal both to folks who think and folks who want quick solutions.
I see no reason to dumb down Forth for people who don't want to think
(or can't). As John Passaniti often points out, people should be able
to chose the language that suits the problem at hand. Forth will never
be all things to all people; nothing else is, why should Forth be? If
Forth is a good language for "thinking people" I don't see why that's a
"limitation".
Bruce McFarling
> Why Forth instead of Python?
I turn that around. Why would I use Python instead of Forth?
The answer is simple ... I would use Python instead of Forth because
there is some big code base that does what I want to do, and I can get
at if I can say something in very simple Python to ask for it, and a
simple introduction to the language is enough for me to work out how
to speak that very simple Python.
If Forth needed a little bit of work but there were clear instructions
how to do that little bit of work, I'd still probably use the Forth
binding ... so it is far from an level playing field. Yet still, as
things stand now, the odds are fairly short that its easier to find a
handle to use that code base directly in a tool that I use with some
difficulty, than to find a hand to use that code base with some
difficulty in a tool I use more directly.
(If, on the other hand, there was a binding like the HP-71B Basic
binding ... which were four words that each handed string to Basic and
either returned an integer, a float, a string, or nothing. That's
plenty. With the amount of software code out there as free cultural
works, installing the hooks on the other side for that kind of binding
ought to be possible ...)
Indeed, I very much like AWK for precisely the things it is good at,
far more than I like sed or grep, but I figure it has been easier for
me to slowly add to a Forth bits and pieces of precisely the
capabilities I most miss from AWK than it ever was trying to get up to
speed on Perl as AWK on steroids, since each step of the way I have a
little something a little more useful than I had before, and until it
gets all the way there I still have the CHARSCAN words from TOOL2002
to get by.
In the end, I don't know how to try to write things so hypothetical
forth programmers pursuing a hypothetical business model with
hypothetical businesses can have a better shot at success, but I can
tell when I have written something that I find useful.
John Doty
> Jonah Thomas wrote:
>> John Passaniti <put-my-firs...@JapanIsShinto.com> wrote:
>>> You next move into the false dichotomy of paying people to think or
>>> pay people to crank out solutions.
>>
>> I didn't mean that to be a false dichotomy. The basic ideas that claim
>> Forth has an advantage, claim that Forth has an advantage for
>> programmers who think. We haven't claimed an advantage on the other
>> side. Should we?
>> Forth is good for factoring, and factoring is good for simplicity, and
>> simplicity is good for debugging speed, and correctness, and easier
>> maintenance. Forth is also good for being interactive which is good for
>> debugging speed and development speed and maintenance. But there are
>> lots of other interactive languages now. So I stress the factoring.
>> Factoring is good for people who think. It does not give Forth an
>> advantage for employers/customers who want people to quickly crank out
>> routine solutions. This is a limitation for Forth. I don't see what to
>> do about it beyond try to be good at what Forth is good at.
>
> People who think often produce solutions as fast or faster than drones
> who don't. Forth has a reputation for nearly 40 years of helping
> thinking people produce results more quickly than other tools. So it
> should appeal both to folks who think and folks who want quick solutions.
It has no such reputation in my world. Its reputation is for encouraging
write-only, unmaintainable code.
>
> I see no reason to dumb down Forth for people who don't want to think
> (or can't). As John Passaniti often points out, people should be able
> to chose the language that suits the problem at hand. Forth will never
> be all things to all people; nothing else is, why should Forth be? If
> Forth is a good language for "thinking people" I don't see why that's a
> "limitation".
The thinking people have given up on Forth. They're off accomplishing
things with other tools. Forth in its present sorry state only appeals
to a certain kind of *stubborn* person.
And it takes one to know one ;-)
>
> Cheers,
> Elizabeth
Elizabeth D Rather
>> If it's a really big project (multiple companies, etc.) there will be
>> multiple teams, each of which will work out its own internal
>> practices, and figure out how best to work with the other groups.
>> Usually there's a lot less task overlap between entirely separate
>> teams, so less need for this kind of intimate sharing.
>
> Yes, and so less well-factored shared code and more bloat. Not in any
> way a show-stopper. Just not as close to optimal as you can get with
> reasonable effort on a smaller system.
No. These separate teams will probably be doing things so diverse that
meaningful sharing opportunities will be limited. For example, on one
such project I remember there was a group programming database stuff on
a mainframe, another doing PC-based local control terminals with heavy
user interface requirements, and still another working on tiny embedded
data acquisition devices. Completely different environments, needs, and
solutions.
John Passaniti
>> You next move into the false dichotomy of paying people to think or
>> pay people to crank out solutions.
>
> I didn't mean that to be a false dichotomy. The basic ideas that claim
> Forth has an advantage, claim that Forth has an advantage for
> programmers who think. We haven't claimed an advantage on the other
> side. Should we?
The base premise is faulty. And insulting.
All non-trivial programming is thinking. It's thinking about how to use
the power of the language to express a solution. Thinking in Forth
means viewing problems in terms of explicit manipulations of state and
(ideally) defining linguistic constructs that map well to the problem
domain. But that's not the only way to think about programming.
Equally valid is for programmers to think in terms of implicit
application of functions to data, avoiding state. Another equally valid
way to think is to model the world as bundles of state and behavior.
Saying that "Forth has an advantage for programmers who think" only
considers a Forth-centric way of thinking. It ignores that there is a
wealth of programming paradigms that are expressed in terms of
languages, libraries, and techniques. And sometimes, a more clear,
simple, and elegant solution can be made by choosing a different model.
So at best, if you're going to go with this premise, you should be
specific about what you mean by "thinking." You mean that the
programmer is concerned with explicit manipulation of program flow and
state. You mean that (typically) that the programmer spends their time
building up the necessary infrastructure instead of focusing on reusable
libraries. You mean that (typically) programs have a low level of
abstraction and because they are optimized for the solution, (typically)
a low level of reuse.
> Forth is good for factoring, and factoring is good for simplicity, and
> simplicity is good for debugging speed, and correctness, and easier
> maintenance. Forth is also good for being interactive which is good for
> debugging speed and development speed and maintenance. But there are
> lots of other interactive languages now. So I stress the factoring.
> Factoring is good for people who think. It does not give Forth an
> advantage for employers/customers who want people to quickly crank out
> routine solutions. This is a limitation for Forth. I don't see what to
> do about it beyond try to be good at what Forth is good at.
Forth is only good for a specific kind of low-level factoring. That is,
Forth makes it relatively easy to extract from a word a sequence of
words and give it a name. There are various mutations of this (colon
definitions, DOES> definitions, vectored execution, macros) and it's
done for different reasons (eliminating common terms, defining new
control structures, crude polymorphism, etc.). But that's pretty much it.
There are other kinds of factoring. There is factoring towards larger
patterns that have proven themselves. While the Forth community was
spending time endlessly reimplementing Forth and arguing over how to
define string literals, the rest of the world was busy rising up above
the low-level kind of factoring that Forth allows and looking for
larger, more substantial kinds of factoring. And along the way, they
noticed something-- that this kind of higher-level factoring is (for the
most part) language independent.
So at best, if you're going with this premise, you should be specific
about what you mean by "factoring." You mean that because Forth isn't
an expression-based language, it allows fine-grained extraction of
sequences of words within definitions. That's it.
>> I love how nearly every discussion in comp.lang.forth that discusses
>> project management usually degenerates into a series of insults about
>> management.
>
> This stereotype is not limited to Forth. See for example Kelly Johnson's
> Rule #14.
>
> http://en.wikipedia.org/wiki/Kelly_Johnson#Kelly_Johnson.27s_14_Rules_of_Management
>
> There's a time-honored tradition that part of managers' compensation is
> related to the number of people they manage. That wasn't invented on
> clf. Of course it isn't true everywhere, as Kelly Johnson and others
> have created counterexamples.
Please provide evidence that this is still common today. Does it exist?
Sure. Is it common enough to even bring it up? I have little
evidence for it. So prove it.
>> It was a large project because it was... large. It combined the
>> skills, interests, and insights that would be extremely unlikely to
>> find any one person had.
>
> Sure. And they chose that 30-person project instead of two 15-person
> projects that would predictably be faster and cheaper to complete
> because.... because it worked for them to.
You're amazingly fearless in discussing projects you know nothing about.
The project in question was fluidly factored into N-person subprojects
over the project's lifetime. That is the norm, in at least the various
industries I've worked in.
> They had a reasonable belief
> that this one could be a success, that's vital. Was it the most
> plausibly profitable use of those resources? Maybe. Maybe the corporate
> climate had something to do with it too. Some people's career trajectory
> might have benefitted more from this project than a smaller one. Etc.
> I'm in no position to say that's true -- I don't know anything about
> your project except what you say about it. But is it at all plausible
> that nontechnical factors might have had some influence on which viable
> project was undertaken?
Not specific to what you're writing here, but the larger tone of what
you write seems to have a whole lot of assumptions about people's
motivations in how they approach a project.
So here's a fun challenge for you:
I know that there are a set of axioms that many people in
comp.lang.forth seem to accept without question. One meta-axiom is the
nature and motivation behind the business decisions used by software
managers. Stated informally, this meta-axiom is that Dilbert isn't a
comic strip, but a shocking documentary in comic strip form. This feeds
into the mythology of Forth-- that Forth is just "too good" and that a
pervasive culture of waste drives everything away from Forth. Gosh, if
we only sprinkled magic Forth dust on everything, every project would be
done on time, on budget, and would have zero bugs. Oh, and it would
make everyone's teeth whiter, disinfect bathroom surfaces, and make your
car get more miles per gallon.
But let's say that instead of accepting all these as axioms, you instead
took a more curious stance. Instead of assuming people having nefarious
motivations, you think instead about people just trying to do their jobs
competently, with practical decisions they think are best. Instead of
viewing decisions in terms of some underlying "career trajectory," you
realize that most people have an honest desire to do good work.
So my challenge is this: Rework your statements without predicating
them on an assumption of nefarious motivation and without the insults.
Whenever you think "gosh, large projects are only large because some
manager wants to get paid more," question where that assumption comes
from. Find a source. Demand proof.
Yes, I know. If everyone in comp.lang.forth started to ask the basic
kinds of questions I repeatedly ask, this might be a newsgroup more
about finding solutions than reiterating sour grapes. But I can dream.
> I don't claim any tremendous expertise about such things. But I think
> you're agreeing with my conclusions even though you disapprove of some
> of the stereotypes I base those conclusions on. We can expect increasing
> project size and Forth will mostly not be the dominant language for
> these projects. For Forth to have a role in any of them, we need
> relatively small niches that Forth can fill inside the large projects.
> Which you have been doing. You prove it's possible.
It's possible when people stop thinking in terms of language choice
being a zero-sum game. It's often cited that part of what Charles Moore
was doing with Forth was getting rid of layers and getting rid of a
multitude of languages. And in some contexts, that's a very good thing.
But it's completely wrong in other contexts. Not every language out
there is just another variation of Algol. Forth is just one model for
computation-- imperative, procedural. It's not the only model. Charles
Moore may have successfully replaced imperative procedural languages
that didn't need to exist. But he didn't replace the variety of
programming paradigms that exist.
Bruce McFarling
> I didn't mean that to be a false dichotomy. The basic ideas that claim
> Forth has an advantage, claim that Forth has an advantage for
> programmers who think. We haven't claimed an advantage on the other
> side. Should we?
There's got to be a less ambiguous way to say that.
Forth may (or may not) have an advantage for programmers who think *in
a particular way*, or who design *in a particular way*, or who test
their work *in a particular way*. It may have an advantage *somewhere*
in a "horizontal" continuum (albeit a multidimensional and therefore
entirely allegorical horizontal plane) ... but to try to claim a
vertical distinction in terms of having an advantage for programmers
who think as opposed to for programmers who do not ...
... hmm, tempting. I hated coding in C because I am a programmer who
thinks, and because I hated coding in C, I sucked at it ...
... but, ultimately, no, I hated coding in C because I didn't like C,
and it may have had something to do with learning styles or habits of
design, or work styles ... but it was not about whether or not I was a
programmer who thought. And I didn't suck at it because C was beneath
"thinking" me, but because I'm not a very good programmer.
William James
> People who think often produce solutions as fast or faster than drones
> who don't. Forth has a reputation for nearly 40 years of helping
> thinking people produce results more quickly than other tools. So it
> should appeal both to folks who think and folks who want quick solutions.
>
> I see no reason to dumb down Forth for people who don't want to think
> (or can't). As John Passaniti often points out, people should be able
> to chose the language that suits the problem at hand. Forth will never
> be all things to all people; nothing else is, why should Forth be? If
> Forth is a good language for "thinking people" I don't see why that's a
> "limitation".
Forth is for those who don't think; for wretches who spend
their time on the tedious, menial, mindless task of keeping
track of where on the stack their variables are. Very
unproductive and primitive. And they have a religious
belief that avoiding local variables is The Right Thing
To Do! Chucky and Lizzy told them so!
Jonah Thomas
> > Factoring is good for people who think. It does not give Forth an
> > advantage for employers/customers who want people to quickly crank
> > out routine solutions. This is a limitation for Forth. I don't see
> > what to do about it beyond try to be good at what Forth is good at.
>
> People who think often produce solutions as fast or faster than drones
>
> who don't. Forth has a reputation for nearly 40 years of helping
> thinking people produce results more quickly than other tools. So it
> should appeal both to folks who think and folks who want quick
> solutions.
Agreed. And yet, sometimes employers/customers want somebody cheap who
can do routine things quickly and cheaply. They don't want to pay for
people to think, and maybe find something better or possibly waste the
thinking time.
> I see no reason to dumb down Forth for people who don't want to think
> (or can't). As John Passaniti often points out, people should be able
>
> to chose the language that suits the problem at hand. Forth will
> never be all things to all people; nothing else is, why should Forth
> be? If Forth is a good language for "thinking people" I don't see why
> that's a "limitation".
I fully agree, and yet it is a limitation for Forth's market share. At
the moment we're facing much worse limitations, but that one is lurking
too.
Andrew Haley
> Forth allows great interactive stuff. Forth is not unique in that any
> more, that isn't so special.
> Professional Forth systems provide a simple toolchain that's pretty well
> debugged, it doesn't pull a lot of surprises that people have to program
> around. That's increasingly true for other languages too, though it
> still tends to be somewhat less true.
> Forth allows and encourages (and somewhat depends on) a whole lot of
> factoring. More than any other language. It's embedded in the Forth
> culture, it's made easy with Forth tools, and Forth tools tend not to
> make it easy to avoid factoring. Factor too little and your code gets
> hard to read and hard to debug, and if you haven't paid attention to any
> previous warning signs that ought to do it.
> I think this is what Forth provides that you won't easily find
> elsewhere. It's possible to factor in other languages. People who're
> good at it can write Forth in any language, kind of like the guys who
> write Pascal in any language. But factoring is a signature strength for
> Forth. Adequate Forth programmers will do it well. Genius Forth
> programmers will simplify so thoroughly they make it look easy.
> Is there disagreement about this part? Is this not a central Forth
> advantage?
It's important, but it's not all. When you program in, say, C, you're
not just using C, but a bunch of other languages such as the shell,
linker scripts, and so on. With Forth, even a Forth co-resident with
some OS, you can spend all your time interacting with Forth. You
don't have to think about those other languages. (Smalltalk and some
LISP systems have similar advantages.) This only works if your Forth
supplies everything you need to control your computer.
It's worth quoting Chuck Moore here:
"The software provided with large computers supplies a hierarchy of
languages: the assembler defines the language for describing the
compiler and supervisor; the supervisor the language for job control;
the compiler the language for application programs; the application
program the language for its input. The user may not know, or know of,
all these languages: but they are there. They stand between him and
his computer, imposing their restrictions on what he can do and what
it will cost.
"And cost it does, for this vast hierarchy of languages requires a
huge investment of man and machine time to produce, and an equally
large effort to maintain. The cost of documenting these programs and
of reading the documentation is enormous. And after all this effort
the programs are still full of bugs, awkward to use and satisfying to
no one."
The simplicity of the Forth is a great advantage: you don't have to
waste time trying to understand the syntax and the bugs in the
implementation of the language of Tool X, it's just more Forth.
Andrew.
Jonah Thomas
> Jonah Thomas wrote:
> >> You next move into the false dichotomy of paying people to think or
> >> pay people to crank out solutions.
> >
> > I didn't mean that to be a false dichotomy. The basic ideas that
> > claim Forth has an advantage, claim that Forth has an advantage for
> > programmers who think. We haven't claimed an advantage on the other
> > side. Should we?
>
> All non-trivial programming is thinking. It's thinking about how to
> use the power of the language to express a solution. Thinking in
> Forth means viewing problems in terms of explicit manipulations of
> state and (ideally) defining linguistic constructs that map well to
> the problem domain. But that's not the only way to think about
> programming. Equally valid is for programmers to think in terms of
> implicit application of functions to data, avoiding state. Another
> equally valid way to think is to model the world as bundles of state
> and behavior.
True.
> Saying that "Forth has an advantage for programmers who think" only
> considers a Forth-centric way of thinking. It ignores that there is a
>
> wealth of programming paradigms that are expressed in terms of
> languages, libraries, and techniques. And sometimes, a more clear,
> simple, and elegant solution can be made by choosing a different
> model.
That's true too. You can build the tools to use the different model in
Forth, but that's an extra step. And there might be nothing in Forth to
encourage the different model.
> > Forth is good for factoring, and factoring is good for simplicity,
> > and simplicity is good for debugging speed, and correctness, and
> > easier maintenance. Forth is also good for being interactive which
> > is good for debugging speed and development speed and maintenance.
> > But there are lots of other interactive languages now. So I stress
> > the factoring. Factoring is good for people who think. It does not
> > give Forth an advantage for employers/customers who want people to
> > quickly crank out routine solutions. This is a limitation for Forth.
> > I don't see what to do about it beyond try to be good at what Forth
> > is good at.
>
> Forth is only good for a specific kind of low-level factoring. That
> is, Forth makes it relatively easy to extract from a word a sequence
> of words and give it a name. There are various mutations of this
> (colon definitions, DOES> definitions, vectored execution, macros) and
> it's done for different reasons (eliminating common terms, defining
> new control structures, crude polymorphism, etc.). But that's pretty
> much it.
I have the idea that Forth is also good for allowing quick rewriting and
testing. So if you see a factor that doesn't work quite the way you've
been working, you can create the factor and relatively quickly rewrite
your old code to use it. You might consider that just more low-level
factoring, though.
> There are other kinds of factoring. There is factoring towards larger
>
> patterns that have proven themselves. While the Forth community was
> spending time endlessly reimplementing Forth and arguing over how to
> define string literals, the rest of the world was busy rising up above
>
> the low-level kind of factoring that Forth allows and looking for
> larger, more substantial kinds of factoring. And along the way, they
> noticed something-- that this kind of higher-level factoring is (for
> the most part) language independent.
Tell us more about that? Has the Forth community been slow to use the
language-independent high-level factoring? Something new that's
available to us?
> So at best, if you're going with this premise, you should be specific
> about what you mean by "factoring." You mean that because Forth isn't
>
> an expression-based language, it allows fine-grained extraction of
> sequences of words within definitions. That's it.
OK.
> > This stereotype is not limited to Forth. See for example Kelly
> > Johnson's Rule #14.
> >
> > http://en.wikipedia.org/wiki/Kelly_Johnson#Kelly_Johnson.27s_14_Rules_of_Management
> >
> > There's a time-honored tradition that part of managers' compensation
> > is related to the number of people they manage. That wasn't invented
> > on clf. Of course it isn't true everywhere, as Kelly Johnson and
> > others have created counterexamples.
>
> Please provide evidence that this is still common today. Does it
> exist?
> Sure. Is it common enough to even bring it up? I have little
> evidence for it. So prove it.
That's incidental to my point. increasingly projects are getting
described as large projects, for whatever reason. However, as both you
and Elizabeth have pointed out, this often amounts to a collection of
mostly-independent smaller projects that are collectively called a large
project. When it's small projects that ahare nothing but different sides
of a specified interface, there's more chance for Forth to be used for
one of them.
> Not specific to what you're writing here, but the larger tone of what
> you write seems to have a whole lot of assumptions about people's
> motivations in how they approach a project.
>
> So here's a fun challenge for you:
>
> I know that there are a set of axioms that many people in
> comp.lang.forth seem to accept without question. One meta-axiom is
> the nature and motivation behind the business decisions used by
> software managers. Stated informally, this meta-axiom is that Dilbert
> isn't a comic strip, but a shocking documentary in comic strip form.
> This feeds into the mythology of Forth-- that Forth is just "too good"
> and that a pervasive culture of waste drives everything away from
> Forth. Gosh, if we only sprinkled magic Forth dust on everything,
> every project would be done on time, on budget, and would have zero
> bugs. Oh, and it would make everyone's teeth whiter, disinfect
> bathroom surfaces, and make your car get more miles per gallon.
Surely there are cultural factors etc that have some effect. How useful
is it to try to dissect those here? Things work better when the cultural
stuff works, but what can we say about how to make it work? Probably not
much.
Here's a story from around the mid-1990's. On comp.lang.forth there was
a claim that -- in those days -- Forth could often get results
considerably faster and cheaper than other languages, that in fact it
could be 1/4 the cost. The claim was that some unnamed Forth shops would
attempt to get government contracts, and they would estimate their
programming costs at 1/4 of the competition. That is, they believed
their own claims. But these bids were never accepted. And it turned out
that the US government consistently threw out bids that were too low as
unserious. They did *not* believe it. One of the steps necessary to get
the contracts was to raise the bid closer to industry norms.
This does not insult US government management. They could have various
legitimate reasons for it. For example, they might sometimes get low
bids that result in predictable cost overruns. It does indicate a
reasonable response.
> But let's say that instead of accepting all these as axioms, you
> instead took a more curious stance. Instead of assuming people having
> nefarious motivations, you think instead about people just trying to
> do their jobs competently, with practical decisions they think are
> best. Instead of viewing decisions in terms of some underlying
> "career trajectory," you realize that most people have an honest
> desire to do good work.
> So my challenge is this: Rework your statements without predicating
> them on an assumption of nefarious motivation and without the insults.
>
> Whenever you think "gosh, large projects are only large because some
> manager wants to get paid more," question where that assumption comes
> from. Find a source. Demand proof.
My thought was that increasingly, funded projects are large. For
whatever reason. I was thinking that could make a difference. But it
doesn't have to make much difference. Maybe it just isn't important.
> Yes, I know. If everyone in comp.lang.forth started to ask the basic
> kinds of questions I repeatedly ask, this might be a newsgroup more
> about finding solutions than reiterating sour grapes. But I can
> dream.
Finding solutions. Outside Forth, about Forth's place in the world.
About interacting with management and customers and such. That's the
point, right? So, suppose someone were to find a newsgroup that real
honest-to-goodness software managers attend, and invite them to
crosspost here describing their needs.... Chances are they don't think a
whole lot about computer languages. That's just one of the early choices
they make, and once the choice is made it's hard to change it. And for
any project (or part of a project) there might be several languages that
are widely regarded as adequate, and some that are considered inadequate
for that particular sort of need, and they choose one. But if they say
what their needs are, it might suggest a software product that could
help to fill those needs, and that product could be written in Forth.
And a sense of what they think they need would help people who want to
work for them.
Would that be a good thing, or would we automatically argue with them
about why they should use Forth for everything, and why they're wrong
about whatever they happen to believe, etc?
> It's often cited that part of what Charles Moore
> was doing with Forth was getting rid of layers and getting rid of a
> multitude of languages. And in some contexts, that's a very good
> thing.
>
> But it's completely wrong in other contexts. Not every language out
> there is just another variation of Algol. Forth is just one model for
>
> computation-- imperative, procedural. It's not the only model.
> Charles Moore may have successfully replaced imperative procedural
> languages that didn't need to exist. But he didn't replace the
> variety of programming paradigms that exist.
Sure. I never meant to say that Forth is the only thing that can be
useful. Here's my claim: Forth's promise is extreme simplicity at all
levels. That's where Forth is headed. To the extent that it delivers,
that's what it delivers. There's value in that though it isn't the only
value that's worth having. "As simple as possible but no simpler."
Am I wrong? Is there some other central value here?
ken...@cix.compulink.co.uk
jeth...@gmail.com (Jonah Thomas) wrote:
> These are kind of old. We have
> a few examples of large Forth projects that failed.
The number of failed IT projects in any particular language seems to
depends largely on the number of IT projects attempted in that language.
The failure of large IT projects is it seems largely down to the users
not being able to specify them correctly. At least that is what seems to
have happened with large government programs in the UK.
Ken Young
Jonah Thomas
> Jonah Thomas <jeth...@gmail.com> wrote:
> > I think [factoring] is what Forth provides that you won't easily
> > find elsewhere.
>
So the central point is not factoring, it's simplicity. Factoring is
only one way to make things simpler.
Elizabeth D Rather
> Elizabeth D Rather <era...@forth.com> wrote:
>> Jonah Thomas wrote:
>
>>> Factoring is good for people who think. It does not give Forth an
>>> advantage for employers/customers who want people to quickly crank
>>> out routine solutions. This is a limitation for Forth. I don't see
>>> what to do about it beyond try to be good at what Forth is good at.
>> People who think often produce solutions as fast or faster than drones
>>
>> who don't. Forth has a reputation for nearly 40 years of helping
>> thinking people produce results more quickly than other tools. So it
>> should appeal both to folks who think and folks who want quick
>> solutions.
>
> Agreed. And yet, sometimes employers/customers want somebody cheap who
> can do routine things quickly and cheaply. They don't want to pay for
> people to think, and maybe find something better or possibly waste the
> thinking time.
Sure, there's a junior-level job slot. The appropriate way to staff
that is with young bright people who are learning, not with non-thinking
drones. You need to have a career path for the kids who will be your
experts in a few years.
>> I see no reason to dumb down Forth for people who don't want to think
>> (or can't). As John Passaniti often points out, people should be able
>>
>> to chose the language that suits the problem at hand. Forth will
>> never be all things to all people; nothing else is, why should Forth
>> be? If Forth is a good language for "thinking people" I don't see why
>> that's a "limitation".
>
> I fully agree, and yet it is a limitation for Forth's market share. At
> the moment we're facing much worse limitations, but that one is lurking
> too.
It's not one to worry about now, if ever. The biggest "limitation"
right now is that most people have never heard of Forth, and those who
have heard the old negative cliches rather than actual information.
This is not a technical problem, and as much as you'd love to find a
technical problem and solve it, there's not a technical solution.
Ask yourself where people hear about cool languages. It's articles in
magazines (both print and online), college, and word-of-mouth. Forth
actually does pretty well at word-of-mouth; programmers who have used
Forth and migrate to new jobs often take it with them, or at least
spread their good experiences. But there are way too few of them. If
you want to do something to promote Forth, write some articles about
successful projects and what Forth contributed to their success, and get
them published. Stop whining about the lack of Forth published code and
publish some. Do something useful.
Andrew Haley
> Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
>> The simplicity of the Forth is a great advantage: you don't have to
>> waste time trying to understand the syntax and the bugs in the
>> implementation of the language of Tool X, it's just more Forth.
> So the central point is not factoring, it's simplicity. Factoring is
> only one way to make things simpler.
Yes, and yes. But simplicity without power is no use. It's not so
hard to make a simple system that is not powerful, or a powerful
system that is not simple. Forth can hit a sweet spot where it's
possible to be both powerful and simple. LISPs -- or at least some
kinds of LISP -- are similar in this respect.
Andrew.
Doug Hoffman
> Here's my claim: Forth's promise is extreme simplicity at all
> levels. That's where Forth is headed. To the extent that it delivers,
> that's what it delivers. There's value in that though it isn't the only
> value that's worth having. "As simple as possible but no simpler."
Would you consider Forths that perform "optimizing" for the compiled
code as violating your vision of simplicity? Context is resource rich
environment (although that may not matter).
-Doug
Elizabeth D Rather
> John Passaniti <put-my-firs...@JapanIsShinto.com> wrote:
...
>> patterns that have proven themselves. While the Forth community was
>> spending time endlessly reimplementing Forth and arguing over how to
>> define string literals, the rest of the world was busy rising up above
>> the low-level kind of factoring that Forth allows and looking for
>> larger, more substantial kinds of factoring. And along the way, they
>> noticed something-- that this kind of higher-level factoring is (for
>> the most part) language independent.
>
> Tell us more about that? Has the Forth community been slow to use the
> language-independent high-level factoring? Something new that's
> available to us?
It's the kind of project factoring I was talking about in a recent post
here. What are the useful components of the project? What are the
appropriate job assignments (for individual team members or sub-teams)?
I don't think "the Forth community" has a role here, because it's the
role of senior engineers or project managers. We have a few of these
here, who presumably do these things, but also a lot of individual
programmers and hobbyists for whom it's irrelevant. And, since it is
largely language-independent, there's nothing you can "fix" in Forth to
address it.
...
> Here's a story from around the mid-1990's. On comp.lang.forth there was
> a claim that -- in those days -- Forth could often get results
> considerably faster and cheaper than other languages, that in fact it
> could be 1/4 the cost. The claim was that some unnamed Forth shops would
> attempt to get government contracts, and they would estimate their
> programming costs at 1/4 of the competition. That is, they believed
> their own claims. But these bids were never accepted. And it turned out
> that the US government consistently threw out bids that were too low as
> unserious. They did *not* believe it. One of the steps necessary to get
> the contracts was to raise the bid closer to industry norms.
>
> This does not insult US government management. They could have various
> legitimate reasons for it. For example, they might sometimes get low
> bids that result in predictable cost overruns. It does indicate a
> reasonable response.
That's actually my story, from the 70's when I was very stupid and naive
about bidding projects. The govt was right to reject bids that were far
too low; it generally indicates that the bidder doesn't understand the
problem, and dealing with such a bidder will cost far more in the long
run. The thing a bidder has to do is find out how much the customer
thinks the contract is going to be worth, and bid slightly under that.
It's always a good move to bid to your customer's perceived value rather
than your cost (assuming that perceived value is high enough for the job
to be profitable to you).
...
> My thought was that increasingly, funded projects are large. For
> whatever reason. I was thinking that could make a difference. But it
> doesn't have to make much difference. Maybe it just isn't important.
I don't think projects are particularly larger today than in the past.
There's always been a mix of projects of all sizes, and will continue to
be. IMO that's a red herring.
> ... So, suppose someone were to find a newsgroup that real
> honest-to-goodness software managers attend, and invite them to
> crosspost here describing their needs.... Chances are they don't think a
> whole lot about computer languages. That's just one of the early choices
> they make, and once the choice is made it's hard to change it. And for
> any project (or part of a project) there might be several languages that
> are widely regarded as adequate, and some that are considered inadequate
> for that particular sort of need, and they choose one. But if they say
> what their needs are, it might suggest a software product that could
> help to fill those needs, and that product could be written in Forth.
> And a sense of what they think they need would help people who want to
> work for them.
>
> Would that be a good thing, or would we automatically argue with them
> about why they should use Forth for everything, and why they're wrong
> about whatever they happen to believe, etc?
Well, there's comp.arch.embedded, for example, which has a mix of
engineers, senior engineers, project managers, etc. But it would be a
serious mistake for you to go barging in there will the sort of
arm-waving and speculation you go in for here. They'll just write you
off as another Forth nut. What's useful is concrete discussions by
engineers who speak from actual experience and engineering know-how,
telling how Forth works for them.
...
>
> Sure. I never meant to say that Forth is the only thing that can be
> useful. Here's my claim: Forth's promise is extreme simplicity at all
> levels. That's where Forth is headed. To the extent that it delivers,
> that's what it delivers. There's value in that though it isn't the only
> value that's worth having. "As simple as possible but no simpler."
>
> Am I wrong? Is there some other central value here?
It's a fine value. But I'm not sure what good it does to recognize
that, it's pretty much something we all know.
Gerry
> John Passaniti <put-my-first-name-h...@JapanIsShinto.com> wrote:
> > Jonah Thomas wrote:
<snip>
>
> > There are other kinds of factoring. There is factoring towards larger
> > patterns that have proven themselves. While the Forth community was
> > spending time endlessly reimplementing Forth and arguing over how to
> > define string literals, the rest of the world was busy rising up above
>
> > the low-level kind of factoring that Forth allows and looking for
> > larger, more substantial kinds of factoring. And along the way, they
> > noticed something-- that this kind of higher-level factoring is (for
> > the most part) language independent.
>
> Tell us more about that? Has the Forth community been slow to use the
> language-independent high-level factoring? Something new that's
> available to us?
>
Try googling software patterns or consult the GoF book "Design
Patterns" which is hardly new. And yes the Forth community has been
slow to use these as they are object oriented. I would recommend
trying out some of these patterns using a simple OO Forth like Mini-
OOF - you might be pleasantly surprised how easy it is. As well as
providing well-tried design solutions easily implemented in Forth,
with Forth and Mini-OOF you can implement these patterns and use them
in a way that other language users can't. You can always use your
lower level factoring as well. Using these higher level abstractions
comes at a cost of course, the code is usually bigger (but on my
desktop machine with 1GByte of RAM do I care if an extra K is used?)
and a bit slower (so things happen in a instant instead of a faster
instant).
Gerry
Jonah Thomas
> <jethom...@gmail.com> wrote:
> > John Passaniti <put-my-first-name-h...@JapanIsShinto.com> wrote:
> > > There are other kinds of factoring. There is factoring towards
> > > larger patterns that have proven themselves. While the Forth
> > > community was spending time endlessly reimplementing Forth and
> > > arguing over how to define string literals, the rest of the world
> > > was busy rising up above the low-level kind of factoring that
> > > Forth allows and looking for larger, more substantial kinds of
> > > factoring. And along the way, they noticed something-- that this
> > > kind of higher-level factoring is (for the most part) language
> > > independent.
> >
> > Tell us more about that? Has the Forth community been slow to use
> > the language-independent high-level factoring? Something new that's
> > available to us?
> >
>
> Try googling software patterns or consult the GoF book "Design
> Patterns" which is hardly new. And yes the Forth community has been
> slow to use these as they are object oriented.
Thank you. So now we have two hypotheses about what John was talking
about, and they're both useful whether or not they catch his meaning.
Bruce McFarling
> Agreed. And yet, sometimes employers/customers want somebody cheap who
> can do routine things quickly and cheaply. They don't want to pay for
> people to think, and maybe find something better or possibly waste the
> thinking time.
> > I see no reason to dumb down Forth for people who don't want to think
> > (or can't). As John Passaniti often points out, people should be able
> > to chose the language that suits the problem at hand.
However, there is no reason that a language for doing routine things
quickly and cheaply cannot be designed in Forth, with Forth available
to create new things to be done quickly and cheaply.
Elizabeth D Rather
Yes, I think that's really how we all work. Except this "language"
consists of the extensions that we're using in a particular application
domain. Everyone here has a pet set of extensions. Some people go on
at length about whizzy string operators, for example -- I'd never use
them, because the work I do rarely deals with strings and to the extent
it does the standard words work fine. But if you're in a
string-intensive project you definitely need stuff. And so on. What's
"routine" for you may be bloat to me, and vice-versa.
Robert Miller
"Elizabeth D Rather" <era...@forth.com> wrote in message
news:13ufd5t...@news.supernews.com...
>
> It's not one to worry about now, if ever. The biggest "limitation" right
> now is that most people have never heard of Forth, and those who have
> heard the old negative cliches rather than actual information. This is not
> a technical problem, and as much as you'd love to find a technical problem
> and solve it, there's not a technical solution.
>
Too true. Those old negative cliches have had an adverse impact on APL as
well. It too has a reputationas being unreadable. Because it is rather
criptic, Forth can be unreadable. But to some extent readability is in the
eyes of the reader. (Is there anyone here besides me who finds Chinese
somewhat unreadable?) IMO readability is not so much a language issue as a
programmer issue. In any event and regardless of language, good comments
and good choice of function/word names can completely dispell readability
and consequent maintainability issues.
> Ask yourself where people hear about cool languages. It's articles in
> magazines (both print and online), college, and word-of-mouth. Forth
> actually does pretty well at word-of-mouth; programmers who have used
> Forth and migrate to new jobs often take it with them, or at least spread
> their good experiences. But there are way too few of them. If you want
> to do something to promote Forth, write some articles about successful
> projects and what Forth contributed to their success, and get them
> published. Stop whining about the lack of Forth published code and
> publish some. Do something useful.
>
Amen!
Bruce McFarling
> > However, there is no reason that a language for doing routine things
> > quickly and cheaply cannot be designed in Forth, with Forth available
> > to create new things to be done quickly and cheaply.
> Yes, I think that's really how we all work. Except this "language"
> consists of the extensions that we're using in a particular application
> domain. Everyone here has a pet set of extensions. Some people go on
> at length about whizzy string operators, for example -- I'd never use
> them, because the work I do rarely deals with strings and to the extent
> it does the standard words work fine. But if you're in a
> string-intensive project you definitely need stuff. And so on. What's
> "routine" for you may be bloat to me, and vice-versa.
But, of course, we are programming in Forth, so we don't want a simple
language that lets you do straightforward things and bleeps at you
when you seem to be doing something out of the ordinary and double-
checks that you really want to do it ... IOW, while most Forth
programmers writing for themselves could create this kind of language
quite easily, few would want to do it for themselves. It requires some
Forth programmers working with people for whom the programmer-oriented
Algol languages are forbidding or a headache, designing a language
that is easy for those folk to work with and easy for a Forth
programmer to extend.
And then of course public repositories and a simple to support
secondary library oversight system for importing portable code from
outside a system, to make those languages more readily available.
John Doty
> It's worth quoting Chuck Moore here:
>
> "The software provided with large computers supplies a hierarchy of
> languages: the assembler defines the language for describing the
> compiler and supervisor; the supervisor the language for job control;
> the compiler the language for application programs; the application
> program the language for its input. The user may not know, or know of,
> all these languages: but they are there. They stand between him and
> his computer, imposing their restrictions on what he can do and what
> it will cost.
>
> "And cost it does, for this vast hierarchy of languages requires a
> huge investment of man and machine time to produce, and an equally
> large effort to maintain. The cost of documenting these programs and
> of reading the documentation is enormous. And after all this effort
> the programs are still full of bugs, awkward to use and satisfying to
> no one."
And this quote should make it absolutely clear that the claim that
"Forth was always for embedded systems, not general-purpose computing"
is revisionist baloney. Chuck wasn't writing about embedded systems
(which when he wrote this were almost exclusively programmed in assembly
language): he was writing about mainframe computers.
>
> The simplicity of the Forth is a great advantage: you don't have to
> waste time trying to understand the syntax and the bugs in the
> implementation of the language of Tool X, it's just more Forth.
But it really isn't. The difficulty is that each Forth application
programmer creates a custom notation for the problem. That notation is
generally impenetrable even to a domain expert because it lacks any
syntactic clues as to its structure. And instead of 30 languages for
10,000 applications, you get one notation (usually not even really a
language, just a pidgin) per application. The complexity Chuck
complained about isn't really avoided: it just returns and charges interest.
I think it would be better to treat Forth not as a language, but as a
radically extensible VM with a simple notation for extensions. Build a
real language (or maybe a handful of them) atop that. Forget this "I
don't want to change Forth" nonsense. Everything changes, and there's
nothing in this idea that prevents using some current Forth as a foundation.
Bruce McFarling
From my perspective, if the Forth *can* be implemented in a simple,
non-optimizing compiler, and the optimizations succeed in working
behind the scenes, so that the optimizing compiler does not introduce
any additional complexity into the mental model of the user, then it
would not violate anything.
And if the simpler model is easier to optimize behind the scenes
without any concession required in the programming, *because* of the
simplicity of the fundamental model, then it would be an additional
incentive for the simplification.
Elizabeth D Rather
> Andrew Haley wrote:
>
>> It's worth quoting Chuck Moore here:
>>
>> "The software provided with large computers supplies a hierarchy of
>> languages: the assembler defines the language for describing the
>> compiler and supervisor; the supervisor the language for job control;
>> the compiler the language for application programs; the application
>> program the language for its input. The user may not know, or know of,
>> all these languages: but they are there. They stand between him and
>> his computer, imposing their restrictions on what he can do and what
>> it will cost.
>>
>> "And cost it does, for this vast hierarchy of languages requires a
>> huge investment of man and machine time to produce, and an equally
>> large effort to maintain. The cost of documenting these programs and
>> of reading the documentation is enormous. And after all this effort
>> the programs are still full of bugs, awkward to use and satisfying to
>> no one."
>
> And this quote should make it absolutely clear that the claim that
> "Forth was always for embedded systems, not general-purpose computing"
> is revisionist baloney. Chuck wasn't writing about embedded systems
> (which when he wrote this were almost exclusively programmed in assembly
> language): he was writing about mainframe computers.
I don't believe anyone has claimed that "Forth was *always* for embedded
systems, not general-purpose computing." True, the early uses were in
an embedded-type project (antenna control and data acquisition), but
subsequently I and others did quite a few commercial IT/database
projects. Nowadays my company chooses to focus on embedded systems as a
business decision, because that's what we're good at and also where we
feel Forth's advantages are most relevant. But some of our customers
and many others are writing great Windows programs and other kinds of
applications.
>> The simplicity of the Forth is a great advantage: you don't have to
>> waste time trying to understand the syntax and the bugs in the
>> implementation of the language of Tool X, it's just more Forth.
>
> But it really isn't. The difficulty is that each Forth application
> programmer creates a custom notation for the problem. That notation is
> generally impenetrable even to a domain expert because it lacks any
> syntactic clues as to its structure. And instead of 30 languages for
> 10,000 applications, you get one notation (usually not even really a
> language, just a pidgin) per application. The complexity Chuck
> complained about isn't really avoided: it just returns and charges
> interest.
The notion that Forth programmers create something that is "impenetrable
even to a domain expert" is pure baloney. I don't know where you get
such an idea. I can't think of one example, and many counter-examples.
Jonah Thomas
> Try googling software patterns or consult the GoF book "Design
> Patterns" which is hardly new. And yes the Forth community has been
> slow to use these as they are object oriented.
I remembered running into the jargon before some. So first I checked
Wikipedia. They made it seem like design patterns are a specific OO
cult. The particular design patterns they describe mostly appear to be
designed to allow extra flexibility to inflexible OO systems. They do
things that I wouldn't have thought would be an issue in the first
place.
On a hunch I next goggled "design patterns" "in Forth" hoping to find
the concepts described in a way that's closer to what I'm already
familiar with. The first hit was kind of humorous:
http://www.as3dp.com/2007/05/12/why-design-patterns/
"Without a doubt, the brightest bunch of programmers I ever hung out
with were FORTH programmers. At the time I was going to weekly meetings
at General Dynamics in San Diego with professional programmers who did
things like write a program in FORTH on the fly and have it communicate
with the Space Shuttle. Members of that group were so smart that they
could imagine a functioning program and go off and write it in FORTH,
and it would run circles around any other attempt to do the same things
in languages like C++. In fact they scoffed at C++ and other languages
that were getting puffed up about being object oriented. To the
engineers using FORTH, working with objects came naturally, and
considering that FORTH was (and still is) an assembly language, that?s
no small feat.
"Given that background, I?m not the kind of person who is impressed by
the latest thing, especially after working with world-class programmers
whose programs stood up where C++ failed.
....
"After working with OOP more or less for a number of years, I was never
convinced that it offered a great deal. In part, this is because most of
the programs I wrote were relatively short, and they stood the test of
time both in functionality and my ability to upgrade and change them.
Also, I was of the belief that a good algorithm was worth all of the
overblown code offered by OOP. So, OOP started off as a nice-to-know
instead of a must-have."
But then he started to see the value.
"... it dawned on me that design patterns are really a roadmap to good
OOP. In the Foreword to Design Patterns: Elements of Reusable
Object-Oriented Software (Addison-Wesley) by GoF, Grady Booch notes that
he judges OOP programs by the attention developers pay to the common
collaboration among objects. When I thought about that comment for a
moment, it was an epiphany that clarified the real purpose of both OOP
and design patterns. Objects in OOP are just that ? objects. The real
value in OOP is how objects are related and how they work together
smoothly."
Just like Forth, OO doesn't help much until you learn how to use it
well. People talk lke it lets you design your object independently, but
to make it work you have to design them carefully so they work together
smoothly, and the design pattern ideas are about how to do that.
The third link was about design patterns in Forth.
http://wiki.forthfreak.net/index.cgi?ForthDesignPatterns
It looks at Forth coding practices that can be valuable. Since it's a
wiki, anybody who wants can add more or change the existing ones.
Stephen Pelc
> The number of failed IT projects in any particular language seems to
>depends largely on the number of IT projects attempted in that language.
>The failure of large IT projects is it seems largely down to the users
>not being able to specify them correctly. At least that is what seems to
>have happened with large government programs in the UK.
Les Hatton's work also seems to indicate that project failure and
reliability are unrelated to programming language. Im my experience,
large project success or failure is determined by the project
management, and failure mostly to weak project management.
Stephen
--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
Andrew Haley
> Andrew Haley wrote:
> The simplicity of the Forth is a great advantage: you don't have to
>> waste time trying to understand the syntax and the bugs in the
>> implementation of the language of Tool X, it's just more Forth.
> But it really isn't. The difficulty is that each Forth application
> programmer creates a custom notation for the problem. That notation
> is generally impenetrable even to a domain expert because it lacks
> any syntactic clues as to its structure.
Well, that depends on how good the application writer is. Experience
has shown me that a thin layer, with the minimum of syntactic sugar,
usually works best. This is because the user who already knows
Forth doesn't have so much to learn.
> I think it would be better to treat Forth not as a language, but as
> a radically extensible VM with a simple notation for
> extensions.
You could say the same about LISP, I suppose. I don't think it's a
very useful distinction to make.
Andrew.
Stephen Pelc
<rsmi...@compmore.net> wrote:
>Unfortunately, the Forth I'm using (SwiftX for the TI msp430) apparently
>doesn't include the optional ANSI locals word set. I can envision a variant
>using VARIABLE declarations for x, y, xx, and xy but that would permanantly
>allocate scarce (in my application ) RAM.
A few years ago we used our PowerView embedded GUI as a test case for
"delocalling" some old code. What we found was that you use locals
when:
a) you have unstructured data
b) you intrinsically have more data items than fit comfortably
on the stack.
In a graphics environment, you do not have unstructured data, you
have a collection of points. Especially if you are building a GUI
you have a collection of horizontal and vertical lines. For most
displays, it is worth optimising the line draw routine for these
two cases.
: h-line \ x y len --
: v-line \ x y len --
: rect \ x y w h --
\ *G Draw a rectangle at *\i{x,y} with width and height *\i{w,h}.
2>r \ -- x y ; R: -- w h
\ 1st vertical: x y h v-line
2dup r@ v-line
\ 2nd vertical: x+w y h v-line
2dup swap 2r@ \ -- x y y x w h ; R: -- w h
-rot + -rot v-line
\ horizontal: x y+h w h-line
2dup r> + r@ h-line \ -- x y ; R: -- w
\ horizontal: x y w h-line
r> h-line
;
The higher level code can now deal with everything in terms of
rectangle or line structures passed by address. You can use
a word to unpack the structure.
: rect>coords \ rect -- x y w h
For NCC compilers, the overhead of unpacking the structure is
balanced by the reduction in stack shuffling. Phrases of the
form:
dup lit + @
should generate one instruction, just as a stack fetch or
save will.
Gerry
> Gerry <ge...@jackson9000.fsnet.co.uk> wrote:
> > Try googling software patterns or consult the GoF book "Design
> > Patterns" which is hardly new. And yes the Forth community has been
> > slow to use these as they are object oriented.
>
>
> The third link was about design patterns in Forth.
>
> http://wiki.forthfreak.net/index.cgi?ForthDesignPatterns
>
> It looks at Forth coding practices that can be valuable. Since it's a
> wiki, anybody who wants can add more or change the existing ones.
These aren't design patterns or higher level abstractions that started
this thread. There are only 3 entries.
The first is a low level coding trick ( R> DROP ) that isn't ANS Forth
and won't work on all systems, therefore very dubious.
The second is again a bit of low level code.
The third (by you I think) discusses the use of variables.
Gerry
John Doty
Then why do domain experts find Forth code "unmaintainable" and
"write-only"? These are not cliches: they represent the actual
experiences of real people.
Jonah Thomas
> Jonah Thomas <jethom...@gmail.com> wrote:
> > Gerry <ge...@jackson9000.fsnet.co.uk> wrote:
> > > Try googling software patterns or consult the GoF book "Design
> > > Patterns" which is hardly new. And yes the Forth community has
> > > been slow to use these as they are object oriented.
> >
> [snip]
> >
> > The third link was about design patterns in Forth.
> >
> > http://wiki.forthfreak.net/index.cgi?ForthDesignPatterns
> >
> > It looks at Forth coding practices that can be valuable. Since it's
> > a wiki, anybody who wants can add more or change the existing ones.
>
> These aren't design patterns or higher level abstractions that started
> this thread. There are only 3 entries.
If you don't think of these as design patterns, you could add some real
design patterns to show how it's done.
> The first is a low level coding trick ( R> DROP ) that isn't ANS Forth
> and won't work on all systems, therefore very dubious.
It doesn't have to be implemented with R> DROP . The idea is to have
aptly-named words that execute EXIT to bail out from the current word,
without having to type ... IF EXIT THEN ... each time. That can be
useful apart from how it gets implemented.
> The second is again a bit of low level code.
Simple control structures. Did it concentrate too much on (not fully
portable) ways to implement them and not enough on their use?
> The third (by you I think) discusses the use of variables.
Pretty much everything but the data stack. Variables, locals, values,
data structures, allocate, rubber-band memory, return stack. I didn't
mention blocks. Simple advice on when to use each tool. If you can say
how to do it better, you're welcome to revise it.
Jonah Thomas
> Elizabeth D Rather wrote:
> > The notion that Forth programmers create something that is
> > "impenetrable even to a domain expert" is pure baloney. I don't
> > know where you get such an idea. I can't think of one example, and
> > many counter-examples.
>
> Then why do domain experts find Forth code "unmaintainable" and
> "write-only"? These are not cliches: they represent the actual
> experiences of real people.
Clearly, domain experts tell you this and they don't tell Elizabeth
this.
Is it that they don't want to hurt her feelings?
Is it that they show you bad Forth code that they don't show her?
Is it that she shows them good Forth code and you don't?
Ideally you might get some of the domain experts you know to email her
about it, and see what results might evolve. It seems like a much better
use for email than for the newsgroup.
John Doty
> Gerry <ge...@jackson9000.fsnet.co.uk> wrote:
>> Jonah Thomas <jethom...@gmail.com> wrote:
>>> Gerry <ge...@jackson9000.fsnet.co.uk> wrote:
>>>> Try googling software patterns or consult the GoF book "Design
>>>> Patterns" which is hardly new. And yes the Forth community has
>>>> been slow to use these as they are object oriented.
>> [snip]
>>> The third link was about design patterns in Forth.
>>>
>>> http://wiki.forthfreak.net/index.cgi?ForthDesignPatterns
>>>
>>> It looks at Forth coding practices that can be valuable. Since it's
>>> a wiki, anybody who wants can add more or change the existing ones.
>> These aren't design patterns or higher level abstractions that started
>> this thread. There are only 3 entries.
>
> If you don't think of these as design patterns, you could add some real
> design patterns to show how it's done.
>
>> The first is a low level coding trick ( R> DROP ) that isn't ANS Forth
>> and won't work on all systems, therefore very dubious.
>
> It doesn't have to be implemented with R> DROP . The idea is to have
> aptly-named words that execute EXIT to bail out from the current word,
> without having to type ... IF EXIT THEN ... each time. That can be
> useful apart from how it gets implemented.
I use && and || in LSE64 by analogy with "short-circuit" evaluation in
other languages. I really like this approach to Forth flow control: it
fits the evaluate-straight-ahead RPN model much better than the
traditional scrambled Algol approach.
>
>> The second is again a bit of low level code.
>
> Simple control structures. Did it concentrate too much on (not fully
> portable) ways to implement them and not enough on their use?
>
>> The third (by you I think) discusses the use of variables.
>
> Pretty much everything but the data stack. Variables, locals, values,
> data structures, allocate, rubber-band memory, return stack. I didn't
> mention blocks. Simple advice on when to use each tool. If you can say
> how to do it better, you're welcome to revise it.
>
Marcel Hendrix
[..]
>> The first is a low level coding trick ( R> DROP ) that isn't ANS Forth
>> and won't work on all systems, therefore very dubious.
> It doesn't have to be implemented with R> DROP . The idea is to have
> aptly-named words that execute EXIT to bail out from the current word,
> without having to type ... IF EXIT THEN ... each time. That can be
> useful apart from how it gets implemented.
[..]
Wil Baden called that ?EXIT . I use it often, and sometimes find ?LEAVE
appropriate also.
-marcel
Jonah Thomas
> Jonah Thomas wrote:
> > ... So, suppose someone were to find a newsgroup that real
> > honest-to-goodness software managers attend, and invite them to
> > crosspost here describing their needs.... ....
> >
> > Would that be a good thing, or would we automatically argue with
> > them about why they should use Forth for everything, and why they're
> > wrong about whatever they happen to believe, etc?
>
> Well, there's comp.arch.embedded, for example, which has a mix of
> engineers, senior engineers, project managers, etc. But it would be a
>
> serious mistake for you to go barging in there will the sort of
> arm-waving and speculation you go in for here. They'll just write you
>
> off as another Forth nut. What's useful is concrete discussions by
> engineers who speak from actual experience and engineering know-how,
> telling how Forth works for them.
comp.arch.embedded has a fair exposure to Forth and vice versa, I won't
post there. I might find something else. And my purpose would be to ask
volunteers to describe what's important to them, not to speculate to
them. If it reaches the point that I do it, I'll send my proposal to you
first and I won't post it anywhere if you suggest I not.
> ...
> > Here's my claim: Forth's promise is extreme simplicity at all
> > levels. That's where Forth is headed. To the extent that it
> > delivers, that's what it delivers. There's value in that though it
> > isn't the only value that's worth having. "As simple as possible but
> > no simpler."
> >
> > Am I wrong? Is there some other central value here?
>
> It's a fine value. But I'm not sure what good it does to recognize
> that, it's pretty much something we all know.
I wanted to get clear a way to say it. Sometimes in the past I've gotten
bogged down in talking about things like factoring, which are part of it
but not quite at the core. Simple and powerful. That's the point.
John Doty
If you walk away from Forth, why would you ever deal with Elizabeth at
all? What would be the point? Those who have walked away don't miss it.
It didn't prove an adequate tool, while other languages did. They don't
want it fixed: they just don't want to have to deal with it any more.
It's only a few stubborn die hards like me who don't idolize it but who
also believe it still has potential value.
John Doty
> "Elizabeth D Rather" <era...@forth.com> wrote in message
> news:13ufd5t...@news.supernews.com...
>> It's not one to worry about now, if ever. The biggest "limitation" right
>> now is that most people have never heard of Forth, and those who have
>> heard the old negative cliches rather than actual information. This is not
>> a technical problem, and as much as you'd love to find a technical problem
>> and solve it, there's not a technical solution.
>>
>
> Too true. Those old negative cliches have had an adverse impact on APL as
> well. It too has a reputationas being unreadable. Because it is rather
> criptic, Forth can be unreadable. But to some extent readability is in the
> eyes of the reader. (Is there anyone here besides me who finds Chinese
> somewhat unreadable?) IMO readability is not so much a language issue as a
> programmer issue.
The language itself has an important role. I have been told that
Japanese people find Spanish an easier language to learn than English.
This cannot be familiarity: there is much English vocabulary in modern
Japanese, and English is commonly used to spice up Japanese advertising.
Spanish is rarely encountered in Japan. However, Spanish spelling and
grammar are much more regular than English: that, I am told, is a big
advantage for Spanish.
> In any event and regardless of language, good comments
> and good choice of function/word names can completely dispell readability
> and consequent maintainability issues.
Comments are *not* an antidote to unreadable code. Comments are a
complement to the code, for things that the computer need not know but
the human reader needs.
Elizabeth D Rather
> Elizabeth D Rather wrote:
>> The notion that Forth programmers create something that is
>> "impenetrable even to a domain expert" is pure baloney. I don't know
>> where you get such an idea. I can't think of one example, and many
>> counter-examples.
>
> Then why do domain experts find Forth code "unmaintainable" and
> "write-only"? These are not cliches: they represent the actual
> experiences of real people.
What "real people"? Yes, I've heard Michael Coughlin's tale about the
project at Smithsonian in the 70's where programmers "couldn't read
their own code". And I've heard managers say they're afraid to use
Forth because they've heard it's unmaintainable, though that's really in
the folklore domain. But I don't know any domain experts who have been
involved in a Forth project (involved enough to learn some Forth and
participate in the programming, which is the normal case in most
projects I've been on) who later felt uncomfortable about its
maintainability.
Jonah Thomas
> Jonah Thomas wrote:
> > Clearly, domain experts tell you this and they don't tell Elizabeth
> > this.
> > Is it that they don't want to hurt her feelings?
> >
> > Is it that they show you bad Forth code that they don't show her?
> >
> > Is it that she shows them good Forth code and you don't?
> >
> > Ideally you might get some of the domain experts you know to email
> > her about it, and see what results might evolve. It seems like a
> > much better use for email than for the newsgroup.
> If you walk away from Forth, why would you ever deal with Elizabeth at
>
> all? What would be the point? Those who have walked away don't miss
> it. It didn't prove an adequate tool, while other languages did. They
> don't want it fixed: they just don't want to have to deal with it any
> more. It's only a few stubborn die hards like me who don't idolize it
> but who also believe it still has potential value.
Elizabeth says it's people who don't actually know about it who tell
these stories. You say it's people who did use it and walked away from
it.
I'm sure there are people who talk who don't know. I occasionally say
bad things about Pascal when I've never used it beyond puzzling out some
of the details with a student, and translating a couple of programs from
Pascal to Forth. I've said some bad things about COBOL when I've never
used it beyond looking at a manual some and translating a couple of
programs out of it. It's quite possible for a language to get an
unjustified reputation.
Or maybe it's people who actually hired incompetent Forth programmers
who couldn't read their own code. There have been some programmers like
that in every other language, why not Forth too?
Or maybe it's people who closely associated with Forth amateurs.
Scientists who started programming in the 1970's or 1980's for
themselves, with no training except maybe a Forth datasheet or two. With
interactive Forth they could get stuff that worked! They started
building up a bigger and bigger body of code that worked, that did just
what they wanted it to, with no structure and no organisation, jusst
doing whatever they needed to do each day, until the whole thing got so
unwieldy they couldn't keep it going any more. That happened to a lot of
people and not primarily with Forth. But if you were going to do that
Forth gave you the tools to do it particularly effectively. They make a
giant mess and their associates blame it on Forth.
Or could it be people who actually did use Forth and it met their needs,
but later they used something that fit their needs even better? Maybe
they're comparing Forth-79 with block files against whatever GUI they're
using now?
None of those people talk to Elizabeth or to me. I'm not sure what it
would mean if they did.
John Doty
> Or maybe it's people who closely associated with Forth amateurs.
> Scientists who started programming in the 1970's or 1980's for
> themselves, with no training except maybe a Forth datasheet or two. With
> interactive Forth they could get stuff that worked! They started
> building up a bigger and bigger body of code that worked, that did just
> what they wanted it to, with no structure and no organisation, jusst
> doing whatever they needed to do each day, until the whole thing got so
> unwieldy they couldn't keep it going any more. That happened to a lot of
> people and not primarily with Forth. But if you were going to do that
> Forth gave you the tools to do it particularly effectively. They make a
> giant mess and their associates blame it on Forth.
This is a common scenario, I think. But consider that with Python, the
same kinds of people using the same approaches pushed past those
problems and created a fabulous public base of reusable code. That never
happened with Forth.
Bruce McFarling
> I think it would be better to treat Forth not as a language, but as a
> radically extensible VM with a simple notation for extensions.
That sounds like not calling a duck a duck, because someone has the
impression that only cowards duck.
A Forth implementation implements a radically extensible VM, a library
of named operations for that VM, and a way to interpret a notation for
extensions. We call that library of named operations for the VM and
notation for extensions, "Forth".
Bruce McFarling
> Wil Baden called that ?EXIT . I use it often, and sometimes find ?LEAVE
> appropriate also.
I mentioned this the other day, and it just struck me that a good name
for:
... 0= IF EXIT THEN ...
might be ?STAY
John Doty
> John Doty wrote:
>> Elizabeth D Rather wrote:
>>> The notion that Forth programmers create something that is
>>> "impenetrable even to a domain expert" is pure baloney. I don't know
>>> where you get such an idea. I can't think of one example, and many
>>> counter-examples.
>>
>> Then why do domain experts find Forth code "unmaintainable" and
>> "write-only"? These are not cliches: they represent the actual
>> experiences of real people.
>
> What "real people"?
For example, the hundreds of astronomers who gave up Forth.
> Yes, I've heard Michael Coughlin's tale about the
> project at Smithsonian in the 70's where programmers "couldn't read
> their own code".
And you failed to take it seriously. Your response to anything contrary
to your ideology is denial.
> And I've heard managers say they're afraid to use
> Forth because they've heard it's unmaintainable, though that's really in
> the folklore domain.
Are you *sure* it's really folklore? Sounds like more denial to me.
> But I don't know any domain experts who have been
> involved in a Forth project (involved enough to learn some Forth and
> participate in the programming, which is the normal case in most
> projects I've been on) who later felt uncomfortable about its
> maintainability.
Yes, but you are not in a position to know what's typical. I'm sure
Dennis Ritchie's experience of projects in C differs from most C users'
experience. The difference, though, is that he has a billion lines of
published code written outside his immediate sphere of influence to
point to as evidence of his language's productivity.
John Doty
But can one call a notation that lacks the properties of a language,
"language"? Is it OK to so torture the word because insiders within the
Forth club use it that way?
Is Cuba really a democracy because its political leadership uses that term?
Aleksej Saushev
Don't get into politics.
> Is Cuba really a democracy because its political leadership uses that term?
Is U.S.A.?
Hitler did win elections and plebiscite.
--
CKOPO BECHA...
CKOPO CE3OH...
Bruce McFarling
> But can one call a notation that lacks the properties of a language,
> "language"?
What in your view is the properties of a language? And why, in your
view, are the connotations associated with that particular use of the
term the only normal connotation of the term?
It seems very much as if you defy the way words are used in everyday
discourse even as you demand that Forth should be more like the
natural languages we use in everyday discourse.
John Doty
> On Mar 24, 4:16 pm, John Doty <j...@whispertel.LoseTheH.net> wrote:
>> But can one call a notation that lacks the properties of a language,
>> "language"?
>
> What in your view is the properties of a language?
The universals linguists identify in languages: syntax, tree structured
grammar, parts of speech, ...
> And why, in your
> view, are the connotations associated with that particular use of the
> term the only normal connotation of the term?
Because without those it's an empty term. If anything qualifies as a
language, what's the point of using the word? Propaganda, maybe?
Gerry
> Gerry <ge...@jackson9000.fsnet.co.uk> wrote:
> > Jonah Thomas <jethom...@gmail.com> wrote:
> > > Gerry <ge...@jackson9000.fsnet.co.uk> wrote:
> > > > Try googling software patterns or consult the GoF book "Design
> > > > Patterns" which is hardly new. And yes the Forth community has
> > > > been slow to use these as they are object oriented.
>
> > [snip]
>
> > > The third link was about design patterns in Forth.
>
> > >http://wiki.forthfreak.net/index.cgi?ForthDesignPatterns
>
> > > It looks at Forth coding practices that can be valuable. Since it's
> > > a wiki, anybody who wants can add more or change the existing ones.
>
> > These aren't design patterns or higher level abstractions that started
> > this thread. There are only 3 entries.
>
> If you don't think of these as design patterns, you could add some real
> design patterns to show how it's done.
>
I doubt if I could do better than implement some of the GoF patterns
in Forth but given the Forth world seems to have little or no interest
in OO Forth (rather strange that as the CREATE... DOES> ... construct
is a rudimentary class/object system) there doesn't seem much point.
I've got plenty of other things to do.
> > The first is a low level coding trick ( R> DROP ) that isn't ANS Forth
> > and won't work on all systems, therefore very dubious.
>
> It doesn't have to be implemented with R> DROP . The idea is to have
> aptly-named words that execute EXIT to bail out from the current word,
> without having to type ... IF EXIT THEN ... each time. That can be
> useful apart from how it gets implemented.
I thought the idea of having ... R> DROP ... inside a word was to exit
from the *calling word* not the current word i.e. not to return to the
caller but to the caller's caller. This is not the same as ... IF EXIT
THEN ... in the current word. If I'm right perhaps you'd like to
explain how you can do the equivalent of ... R> DROP ... in ANS Forth
>
> > The second is again a bit of low level code.
>
> Simple control structures. Did it concentrate too much on (not fully
> portable) ways to implement them and not enough on their use?
>
> > The third (by you I think) discusses the use of variables.
>
> Pretty much everything but the data stack. Variables, locals, values,
> data structures, allocate, rubber-band memory, return stack. I didn't
> mention blocks. Simple advice on when to use each tool. If you can say
> how to do it better, you're welcome to revise it.
>
I wouldn't presume to say I could do better, I just said it wasn't a
design pattern but advice. I wasn't criticising the advice.
Gerry
Jonah Thomas
> > If you don't think of these as design patterns, you could add some
> > real design patterns to show how it's done.
> >
>
> I doubt if I could do better than implement some of the GoF patterns
> in Forth but given the Forth world seems to have little or no interest
> in OO Forth (rather strange that as the CREATE... DOES> ... construct
> is a rudimentary class/object system) there doesn't seem much point.
> I've got plenty of other things to do.
I'm beginning to get an interest in OO. I can imagine a Forth OO system
that has no runtime overhead at all, that works entirely by restricting
options at compile-time or even perhaps during editing. By restricting
your choices, OO can help you avoid mistakes.
> > > The first is a low level coding trick ( R> DROP ) that isn't ANS
> > > Forth and won't work on all systems, therefore very dubious.
> >
> > It doesn't have to be implemented with R> DROP . The idea is to
> > have aptly-named words that execute EXIT to bail out from the
> > current word, without having to type ... IF EXIT THEN ... each time.
> > That can be useful apart from how it gets implemented.
>
> I thought the idea of having ... R> DROP ... inside a word was to exit
> from the *calling word* not the current word i.e. not to return to the
> caller but to the caller's caller. This is not the same as ... IF EXIT
> THEN ... in the current word. If I'm right perhaps you'd like to
> explain how you can do the equivalent of ... R> DROP ... in ANS Forth
For example,
: ?EXIT
POSTPONE 0= POSTPONE IF POSTPONE EXIT POSTPONE THEN ; IMMEDIATE
I like to use a ]] word that postpones everything.
: ?EXIT
]] 0= IF EXIT THEN [[ ; IMMEDIATE
A Forth94 word that takes something off the return stack that it didn't
put on it has an environmental dependency -- there are standard Forth94
systems that will give unexpected results for that. But you can have the
word instead lay down the EXIT inside the word that calls it. This has
other limitations. It ought to work on any Forth94 system, but it won't
dependably run except when you're compiling some other word. For
portability purposes it's compile-only.
Elizabeth D Rather
> Elizabeth D Rather wrote:
>> John Doty wrote:
>>> Elizabeth D Rather wrote:
>> ....
>>>> The notion that Forth programmers create something that is
>>>> "impenetrable even to a domain expert" is pure baloney. I don't
>>>> know where you get such an idea. I can't think of one example, and
>>>> many counter-examples.
>>>
>>> Then why do domain experts find Forth code "unmaintainable" and
>>> "write-only"? These are not cliches: they represent the actual
>>> experiences of real people.
>>
>> What "real people"?
>
> For example, the hundreds of astronomers who gave up Forth.
Has someone done a comprehensive survey of them to ascertain the reasons?
I actually know several of them, and what they (most recently, Jim
Harwood, of the Univ. of HI astronomy dept) told me is that they
continued using Forth happily until the equipment it was supporting was
replaced. Then the task of programming the new stuff fell to their
graduate students, who were allowed to pick their own language, and they
picked what they'd just been studying (which wasn't Forth). NRAO's 36'
telescope was still controlled by Forth until it was dismantled just a
few years ago. Astronomers at the Univ. of Minnesota were controlling a
series of telescopes with Forth-based software, which they had
maintained on their own for over 10 years; it didn't survive the
migration to Windows, because Windows was too slow for their real-time
control. Those are real stories from real astronomers, and pretty
recent ones, at that.
>> Yes, I've heard Michael Coughlin's tale about the project at
>> Smithsonian in the 70's where programmers "couldn't read their own code".
>
> And you failed to take it seriously. Your response to anything contrary
> to your ideology is denial.
It's hard to take seriously an isolated incident 30 years ago. Forth is
vastly different from what it was then, as are standard coding practices.
>> And I've heard managers say they're afraid to use Forth because
>> they've heard it's unmaintainable, though that's really in the
>> folklore domain.
>
> Are you *sure* it's really folklore? Sounds like more denial to me.
Do you have any actual evidence one way or the other? Whenever someone
asks you this question, you say something like, "what else could it be?"
Then when folks chime in with several perfectly plausible
alternatives, you reject them out of hand.
I know managers say that, it's a common cliche. I've never heard it
from one who's had that issue personally.
>> But I don't know any domain experts who have been involved in a Forth
>> project (involved enough to learn some Forth and participate in the
>> programming, which is the normal case in most projects I've been on)
>> who later felt uncomfortable about its maintainability.
>
> Yes, but you are not in a position to know what's typical. I'm sure
> Dennis Ritchie's experience of projects in C differs from most C users'
> experience. The difference, though, is that he has a billion lines of
> published code written outside his immediate sphere of influence to
> point to as evidence of his language's productivity.
I'm not speaking from my experience here, but from our customers'. We
have several thousand of them, and we're in regular communication with
many. Most are, in fact, domain experts (in various domains) who are
using Forth successfully in a variety of projects. I submit that I am
in regular touch with >100 domain experts using Forth, on their own,
without any direct participation of Forth, Inc. How many domain experts
did you base your assertion on, or are you still relying on this
hypothetical "hundreds of astronomers"?
Aleksej Saushev
> John Doty wrote:
>> Elizabeth D Rather wrote:
>>> John Doty wrote:
>>>> Elizabeth D Rather wrote:
>>> ....
>>>>> The notion that Forth programmers create something that is
>>>>> "impenetrable even to a domain expert" is pure baloney. I
>>>>> don't know where you get such an idea. I can't think of
>>>>> one example, and many counter-examples.
>>>>
>>>> Then why do domain experts find Forth code "unmaintainable"
>>>> and "write-only"? These are not cliches: they represent the
>>>> actual experiences of real people.
>>>
>>> What "real people"?
>>
>> For example, the hundreds of astronomers who gave up Forth.
>
> Has someone done a comprehensive survey of them to ascertain the reasons?
>
> I actually know several of them, and what they (most recently,
> Jim Harwood, of the Univ. of HI astronomy dept) told me is that
> they continued using Forth happily until the equipment it was
> supporting was replaced. Then the task of programming the new
> stuff fell to their graduate students, who were allowed to pick
> their own language, and they picked what they'd just been
> studying (which wasn't Forth).
So, why the language they studied wasn't Forth?
> NRAO's 36' telescope was still
> controlled by Forth until it was dismantled just a few years
> ago.
That's just a legacy. Where're new systems?
> Astronomers at the Univ. of Minnesota were controlling a
> series of telescopes with Forth-based software, which they had
> maintained on their own for over 10 years; it didn't survive the
> migration to Windows, because Windows was too slow for their
> real-time control.
You're silent about the end of the story. I guess it isn't that bright,
otherwise you would add something like "and it works till nowadays",
still it stayed in past tense.
> Those are real stories from real
> astronomers, and pretty recent ones, at that.
Right. No indication of Forth success, it was held as legacy of past time
and was substituted on the first convenient occasion.
>>> And I've heard managers say they're afraid to use Forth
>>> because they've heard it's unmaintainable, though that's
>>> really in the folklore domain.
>>
>> Are you *sure* it's really folklore? Sounds like more denial to me.
>
> Do you have any actual evidence one way or the other? Whenever
> someone asks you this question, you say something like, "what
> else could it be?" Then when folks chime in with several
> perfectly plausible alternatives, you reject them out of hand.
Which alternatives? Common acceptance? Forth was accepted by
community in past, but was thrown away later. FORTRAN and LISP
survived, Forth did not.
Orgranization support? Neither Perl, nor Python didn't have any
organization behind them. Is SAGE written in FORTH? Is FSL in
any way comparable to NumPy? Where's the SymPy analogue?
Marcel Hendrix
[..]
> Astronomers at the Univ. of Minnesota were controlling a
> series of telescopes with Forth-based software, which they had
> maintained on their own for over 10 years; it didn't survive the
> migration to Windows, because Windows was too slow for their real-time
> control.
So they switched to a language that was faster than their Forth under
Windows? Even when they could have upgraded to SwiftForth or VFX?
What language and/or OS *did* they eventually use? If they stopped using
Windows, there still should've been a Forth for them if they wanted?
-marcel
Bruce McFarling
> Bruce McFarling wrote:
> > On Mar 24, 4:16 pm, John Doty <j...@whispertel.LoseTheH.net> wrote:
> >> But can one call a notation that lacks the properties of a language,
> >> "language"?
> > What in your view is the properties of a language?
> The universals linguists identify in languages: syntax, tree structured
> grammar, parts of speech, ...
However, people are perfectly capable of understanding body language
without any parts of speech at all.
You start with the adoption of a common term into a field as a
technical term and then insist that that jargon is the only
permissible use of the term.
It doesn't work like that in the social sciences. A discipline gets to
define the terms it uses within the scope of technical discussions
amongst social scientists in that field ... and normally within the
scope of technical discussions amongst those using a particular
approach in that field ... but its certainly doesn't get to restrict
all use of that term in all other social settings.
Here's some of the define:language results from Google
A language is a system, used to communicate, comprised of a set of
symbols and a set of rules (or grammar) by which the manipulation of
these symbols is governed. These symbols can be combined productively
to convey new information, distinguishing languages from other forms
of communication.
The human use of spoken or written words as a communication system.
Language can also include a system of communication based on signs,
gestures, or inarticulate sounds.
# a systematic means of communicating by the use of sounds or
conventional symbols; "he taught foreign languages"; "the language
introduced is ...
# speech: (language) communication by word of mouth; "his speech was
garbled"; "he uttered harsh language"; "he recorded the spoken
language of the streets"
# terminology: a system of words used to name things in a particular
discipline; "legal terminology"; "biological nomenclature"; "the
language of sociology"
# linguistic process: the cognitive processes involved in producing
and understanding linguistic communication; "he didn't have the
language to express his feelings"
# the mental faculty or power of vocal communication; "language sets
homo sapiens apart from all other animals"
# lyric: the text of a popular song or musical-comedy number; "his
compositions always started with the lyrics"; "he wrote both words and
music"; "the song uses colloquial language"
Forth qualifies as a language under the first definition, the second
definition, and the first and third sense of the third definition.
John Doty
> I actually know several of them, and what they (most recently, Jim
> Harwood, of the Univ. of HI astronomy dept) told me is that they
> continued using Forth happily until the equipment it was supporting was
> replaced. Then the task of programming the new stuff fell to their
> graduate students, who were allowed to pick their own language, and they
> picked what they'd just been studying (which wasn't Forth).
So, the advantages of Forth were so unimpressive to him that he was
unwilling to steer his students in the direction of Forth. And they
apparently got the work done, so it would seem they made a right choice.
When I show students the simplicity of Forth these days, they understand
what I'm getting at, but they still don't become Forth users. They don't
perceive it as an *overall* project simplification. Coding is not a
major chore any more. A megabyte of memory costs $0.10. For the new
generation, Forth solves the wrong problems, and aggravates others (like
intra-project communication).
> NRAO's 36'
> telescope was still controlled by Forth until it was dismantled just a
> few years ago.
Sure. There's still an x-ray optics test setup at Goddard controlled by
software I originally wrote in LSE in the 1980's. But nobody's doing new
stuff with it: that's the issue.
> Astronomers at the Univ. of Minnesota were controlling a
> series of telescopes with Forth-based software, which they had
> maintained on their own for over 10 years; it didn't survive the
> migration to Windows, because Windows was too slow for their real-time
> control. Those are real stories from real astronomers, and pretty
> recent ones, at that.
So, Forth's purported advantages cannot survive migration to new
hardware. Sounds like unmaintainability to me.
>
>>> Yes, I've heard Michael Coughlin's tale about the project at
>>> Smithsonian in the 70's where programmers "couldn't read their own
>>> code".
>>
>> And you failed to take it seriously. Your response to anything
>> contrary to your ideology is denial.
>
> It's hard to take seriously an isolated incident 30 years ago. Forth is
> vastly different from what it was then, as are standard coding practices.
Forth is *slightly* different from what it was then. The rest of the
computing landscape has changed drastically, but Forth has hardly
changed at all. Adapt or die.
>
>>> And I've heard managers say they're afraid to use Forth because
>>> they've heard it's unmaintainable, though that's really in the
>>> folklore domain.
>>
>> Are you *sure* it's really folklore? Sounds like more denial to me.
>
> Do you have any actual evidence one way or the other? Whenever someone
> asks you this question, you say something like, "what else could it be?"
Indeed. And nobody has satisfactorily answered.
> Then when folks chime in with several perfectly plausible alternatives,
> you reject them out of hand.
Oh, come on. The alternatives are things like "Forth is unpopular". It
certainly is, but it is unpopular because most of its user base
abandoned it (why?). Or Guy's ridiculous analogy that requires that a
volcano is the same thing as nothing.
>
> I know managers say that, it's a common cliche. I've never heard it
> from one who's had that issue personally.
What do managers know? Talk to the people who do the work. Talk to
people who use Python and understand why they use it.
I've heard computer scientists badmouth C for 30 years. And the answer
to all those Lisp and Ada fans is the billion lines of published C code,
much of it very widely used. But there's nothing to show people who
badmouth Forth. So, where's that radical productivity?
>
>>> But I don't know any domain experts who have been involved in a
>>> Forth project (involved enough to learn some Forth and participate in
>>> the programming, which is the normal case in most projects I've been
>>> on) who later felt uncomfortable about its maintainability.
>>
>> Yes, but you are not in a position to know what's typical. I'm sure
>> Dennis Ritchie's experience of projects in C differs from most C
>> users' experience. The difference, though, is that he has a billion
>> lines of published code written outside his immediate sphere of
>> influence to point to as evidence of his language's productivity.
>
> I'm not speaking from my experience here, but from our customers'.
And of course, those who've walked away aren't your customers. So you
have no insight to offer here.
John Doty
But you are just trying to define the problem away: language, as
understood by linguists, is what engages the human "language instinct",
and that's a powerful mental "muscle". Weaker definitions only suit a
weak language, one that cannot as effectively employ human mental power.
Jonah Thomas
> > Astronomers at the Univ. of Minnesota were
> > controlling a
> > series of telescopes with Forth-based software, which they had
> > maintained on their own for over 10 years; it didn't survive the
> > migration to Windows, because Windows was too slow for their
> > real-time control.
>
> So they switched to a language that was faster than their Forth under
> Windows? Even when they could have upgraded to SwiftForth or VFX?
The way I remember the history, Windows 95 came out and there was no
Forth for it. Win32Forth took awhile to start working and at first it
had some Windows problems. Things that ran in DOS boxes were kind of
jerky, Windows might at any time step in and steal a few hundred
milliseconds.
People said that you could keep that from happening if you used a DLL.
But I didn't hear about Forth systems that did that routinely, though
there were special-purpose Forth applications that handled timing under
Windows that way.
Meanwhile the C guys were having only the usual Windows troubles.
Perhaps part of the problem was that it takes so few people to maintain
a Forth system. So a Windows commitment that might add a few extra
people to the payroll for a C compiler turned into a relatively big
investment for a Forth.
Windows ran without a commercial Forth for years. I don't remember when
SwiftForth was first released, but the first message on the SwiftForth
message archive is dated December 28, 1998. It would have made sense for
astronomers etc to run DOS on new microcomputers so they could keep
using Forth. And a few people did run DOS to use the special OO
GUI-interface production-control/simulation package. But mostly they
went with Windows and dumped PolyForth.
Robert Miller
"John Doty" <j...@whispertel.LoseTheH.net> wrote in message
news:Er-dnWiz-a5eY3ra...@wispertel.com...
> Robert Miller wrote:
>>
>> In any event and regardless of language, good comments and good choice
>> of function/word names can completely dispell readability and consequent
>> maintainability issues.
>
> Comments are *not* an antidote to unreadable code. Comments are a
> complement to the code, for things that the computer need not know but the
> human reader needs.
I did say good comments AND good choice of function/word names.
Believe me, even though the words comprising the language are clear enough,
it is possible to write unreadable code in C. For a test application, I
once had occasion to adapt some C code written by one of the company's
system programmers. This twit made a point of giving functions names that
bore no relation to what they did and he stripped all comments before he
checked in his code. (Makes one wonder just how slack his manager was.) When
I questioned him about this, he said he kept the commented version and that
he did this because he felt it gave him job security. I was not able to
get the commented version from him! Had it been in my power, I would have
fired him on the spot. It was almost as much work reverse engineering his
code as starting from scratch.
With Forth, because the dictionary is somewhat cryptic, it is much easier to
write code that is difficult to decipher. I know this for a fact, because
I've learned the hard way that good comments are not an option -particularly
with Forth. Too many years ago, a collegue and I decided to do a job that a
couple of contractors using assembly language had failed to do in two
months. This was done over a weekend because management wouldn't authorize
starting all over again. In the end, on Monday morning we delivered
complete and working code, but due to the rush, sans comments. When it came
to maintaining this code a few weeks later, it was easier to rewrite than
decipher the uncommented (and probably very poorly factored) code. Any code
I have written (in any language) since that experience has been generously
and thoroughly commented.
With regard to the topic of this thread, despite the maintenance problems,
this was an example of Forth's strength. IMO Forth, like APL, is an
end-user's language more than a programmer's language. The assembly language
contractors were given a very clear and complete specifiacation for driver
software for a custom test board. It had probably taken a good man-week for
the two of us (essentially hardware engineers) to write that specification.
We had guestimated that it should take less than two man months and were not
impressed when at the end of a two month contract they asked for a one month
extension. In those two months, one of our test programmers had rewritten
MVP forth to run on our 6809 based processor card. Test engineers were now
writing their own code rather than writing software specifications and
waiting for software manpower to come free. And in doing so were getting the
code working in about the same time it had taken to write the spcifications.
There is considerable advantage in having the people who have the
requirement implement the code to meet it rather than trying to communicate
the requirement to someone who doesn't fully understand either the hardware
or the requirement.
Bob Miller
Duke Normandin
Having read this thread from its beginning, it sweep over this newbie that
the current Forth community - such as it is - is _not_ a co-operative
society, but rather a chronically argumentative one. It is truely sick!
I've read a lot of editions of the Forth Dimension, and I honestly did not
ever once get the sense that the Forth community - in its FIG incarnation
- was falling apart at the seams, like the current community appears to
be. I get the feeling now that the Forth community efforts have regressed
to that of a multi-national pissing contest.
If I'm correct, this to me is truely sad! I know that I am _never_ going
to be in the same league as any one of you "forthers". This community is
made up of some extremely bright folks - but you guys can't get your shit
in one bag!! I cannot imagine anything that you guys could not accomplish
if you did get it together! It's depressing to listen to the lot of you
pop off! -- and in public where the whole world can witness the last
members of a community argue themselves into extinction / oblivion.
I agree with John Doty in that I sense that Forth has the makings of
becoming great in some form. I have no clue what needs to change with
Forth. All I know is that I taught myself Perl, PHP, TCL/Tk and now
newLisp with very little effort. But for some reason, I'm struggling with
Forth. It feels like a hodge-podge of kludges to me. Perl is like that too
in some ways, IMO.
So what'll it be? Are you guys going to continue along the sophist path to
extinction if not utter irrelevance, or are you willing to at least _try_
to get your shit together? If you can't do for yourselves, could you do
for the self-esteem of Forth in general? Or have you all degenerated to
being more Fart(h)ers than Forthers? Please give this newbie some hope for
Forth! Let's resurrect FIG!! Can we do that together? Can we crank out a
"generic Forth" that we can all live with to be the new FIG flagship?
Maybe the new "generic Forth" can include something from each of the
current Forth hackers' Forth ;) You guys set up a core team and designate
who can commit code to the project, a la the FreeBSD project. What do you
say? You guys have the brain-power to do it -- and you need now is the
WILL!
Ok -- I'm done! BTW, none of the above was written with _any_ malice!
--
Duke Normandin
dukeo...@ml1.net
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
John Doty
> "John Doty" <j...@whispertel.LoseTheH.net> wrote in message
> news:Er-dnWiz-a5eY3ra...@wispertel.com...
>> Robert Miller wrote:
>>> In any event and regardless of language, good comments and good choice
>>> of function/word names can completely dispell readability and consequent
>>> maintainability issues.
>> Comments are *not* an antidote to unreadable code. Comments are a
>> complement to the code, for things that the computer need not know but the
>> human reader needs.
>
> I did say good comments AND good choice of function/word names.
>
> Believe me, even though the words comprising the language are clear enough,
> it is possible to write unreadable code in C.
Of course, but so what? It's *customary* to write unreadable code in Forth.
> For a test application, I
> once had occasion to adapt some C code written by one of the company's
> system programmers. This twit made a point of giving functions names that
> bore no relation to what they did and he stripped all comments before he
> checked in his code. (Makes one wonder just how slack his manager was.) When
> I questioned him about this, he said he kept the commented version and that
> he did this because he felt it gave him job security. I was not able to
> get the commented version from him! Had it been in my power, I would have
> fired him on the spot. It was almost as much work reverse engineering his
> code as starting from scratch.
A Forth programmer could obfuscate code even more easily. But I wonder
about his lack of professionalism: usually when someone behaves like
that it reflects abuse by management.
>
> With Forth, because the dictionary is somewhat cryptic, it is much easier to
> write code that is difficult to decipher. I know this for a fact, because
> I've learned the hard way that good comments are not an option -particularly
> with Forth.
So, you're saying that Forth code is weaker at speaking for itself.
That's a real problem.
> Too many years ago, a collegue and I decided to do a job that a
> couple of contractors using assembly language had failed to do in two
> months. This was done over a weekend because management wouldn't authorize
> starting all over again.
There is no doubt in my mind that if you need code in a hurry, Forth is
very effective. But as you found, it's more difficult to make
maintainable code:
> In the end, on Monday morning we delivered
> complete and working code, but due to the rush, sans comments. When it came
> to maintaining this code a few weeks later, it was easier to rewrite than
> decipher the uncommented (and probably very poorly factored) code. Any code
> I have written (in any language) since that experience has been generously
> and thoroughly commented.
Yes, because you need to remember what the code is for and why you made
the choices you made. But the code should speak for itself as to *how*
it gets the job done. That's what a programming language is for:
otherwise you might as well just program in hex.
>
> With regard to the topic of this thread, despite the maintenance problems,
> this was an example of Forth's strength. IMO Forth, like APL, is an
> end-user's language more than a programmer's language.
Used to be. But end users mostly feel they have better options these days.
> The assembly language
> contractors were given a very clear and complete specifiacation for driver
> software for a custom test board.
Of course, they no doubt complained that the specification wasn't clear.
The other day, I was talking with an astrophysicist about one of his
projects, and he was complaining that the head of the project wasn't
really writing requirements for the engineers: instead, he was telling
them (badly: he's not much of an engineer) how he wanted them to
implement the instrument under development.
I said "you know why he does that, of course". "Sure," he replied, "when
he gives the engineers proper requirements, the response is 'Huh?'".
The purpose of a programming language is to support domain experts, not
programmers. Programmers without the domain knowledge are harder to
program than computers are.
> It had probably taken a good man-week for
> the two of us (essentially hardware engineers) to write that specification.
> We had guestimated that it should take less than two man months and were not
> impressed when at the end of a two month contract they asked for a one month
> extension. In those two months, one of our test programmers had rewritten
> MVP forth to run on our 6809 based processor card. Test engineers were now
> writing their own code rather than writing software specifications and
> waiting for software manpower to come free. And in doing so were getting the
> code working in about the same time it had taken to write the spcifications.
> There is considerable advantage in having the people who have the
> requirement implement the code to meet it rather than trying to communicate
> the requirement to someone who doesn't fully understand either the hardware
> or the requirement.
I certainly agree with that. But that's not the direction Forth has
gone. It's not designed for domain experts, it's designed for Forth
specialists.
Bruce McFarling
> But you are just trying to define the problem away: language, as
> understood by linguists, is what engages the human "language instinct",
> and that's a powerful mental "muscle". Weaker definitions only suit a
> weak language, one that cannot as effectively employ human mental power.
I am not "trying to define the problem away". I am pointing out that
you are trying to smuggle your conclusions in by way of definition
instead of making a coherent argument for them.
The idea of a human language instinct is itself not entirely
uncontroversial ...
... neither, indeed, is the idea that the precise substantial content
of that instinct is a settled point. Chomsky, for example, finds that
the language instinct results in languages that have both a surface
structure and a deep structure. Not all linguists agree with that ...
for some, language is a self-reproducing system that *is* a coherent
system, with a coherent structure, and different aspects of that
structure may evolve at different rates, but at any one point in time
it forms a single concrete and largely coherent whole.
However, the controversy of those points is nothing compared to the
gist of your argument, because while they are not settled points, on
the other hand there are serious students of human language who will
present a persuasive argument in support.
The heroic leap is the jump that finds in the focus of linguists on
their subject of study, human languages, the basis for arguing that
not just *some* computer languages, and not just *most* computer
languages, but *each and every* computer languages should be
exclusively designed to engage human language instincts in preference
over any other type of reasoning.
The audacity of that leap is quite stunning.
In order to make the case that *all* computer languages should be
tailored to verbal reasoning to the detriment of their support of
other types of reasoning, it has to be shown that verbal reasoning
will provide superior results to all other types of reasoning in all
problem areas that any designer of any computer program may encounter.
Since you are not making the argument that, "there should be a
computer language that ..." does such and so. You are making the
argument that, "there should never be a computer language that does
not ..." do such and so.
So I understand that temptation to argue, "any computer language
worthy of the name language will be designed in this way, because I
declare that only computer languages designed this way are worthy of
the name language", but its still trying to smuggle your conclusion in
via assumptions that only you are willing to grant.
And in particular, while there are linguists who will argue that
language is the only way of thinking that is worthy of the name, in
addition to being loquacious animals, humans are also tool making
animals. And in addition to an instinct of language, there is an
instinct of workmanship.
And while it may appeal to the loquaciousness of humankind to design
computer languages that are present simulcras of human language, in
which humans express to the machine what they desire to occur, it also
appeals to our tool-using instinct to design computer languages that
allow us to build the tools that work as we wish them to work.
I am not convinced that a dead simulcra of living human language is
the one and only thing that a computer programming language should
every be allowed to be. I think that being a tool for building tools
is also one worthwhile model for computer program design languages.
Bruce McFarling
> Having read this thread from its beginning, it sweep over this newbie that
> the current Forth community - such as it is - is _not_ a co-operative
> society, but rather a chronically argumentative one.
Don't confuse this for a Forth community ... its a Usenet newsgroup.
You ask a question and you get:
(1) someone saying you are terrible to be thinking of the problem in
those terms
(2) an answer that does not work from someone who knows less than you
(3) a 542 post argument rehashing who did what to whom at some obscure
meeting in 1982
(4) four intriguing ideas that have nothing to do with your question
but are interesting nevertheless and
(5) if you luck out, a useful answer to your question ... sometimes
none, and sometimes five excellent onces written at almost exactly the
same time some two days after the 542 post re-argument has died down.
When you find a Usenet newsgroup that looks like it functions as a
community, its because a community exists (or several do and they find
it worth their while to jointly maintain the newsgroup as a common
bazaar) and members of the community keep acting like members of a
community when they are on the newsgroup.
Frank Buss
> Please give this newbie some hope for Forth!
Forth is not like a tree, which needs water to live and for which you can
have some hopes. It is more like mathematics: The standard is written and
if Forth works for your project, you can use it. And because of the simple
basic concepts, it is even possible to write your own implementation, if
you need it, unlike e.g. for C++, which needs many man years of work.
And I think there are more active Forth programmers than posters in this
newsgroup, maybe because of too many non-technical postings like this one.
> Let's resurrect FIG!! Can we do that together? Can we crank out a
> "generic Forth" that we can all live with to be the new FIG flagship?
There is already an ongoing process for the next Forth:
http://www.forth200x.org/forth200x.html
If you want to change something, you can participate in the RfD/CfV
process.
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Duke Normandin
Point taken! Can you show me the way to San Jose? ;)
Jonah Thomas
> Having read this thread from its beginning, it sweep over this newbie
> that the current Forth community - such as it is - is _not_ a
> co-operative society, but rather a chronically argumentative one. It
> is truely sick!
First, note that comp.lang.forth mostly gets posts from the same dozen
or so people repeatedly, and may not be representative of the whole
community. On the other hand, there aren't a lot of places that
represent the whole Forth community. The communication that isn't going
on here may not be going on anywhere else either.
> I agree with John Doty in that I sense that Forth has the makings of
> becoming great in some form. I have no clue what needs to change with
> Forth. All I know is that I taught myself Perl, PHP, TCL/Tk and now
> newLisp with very little effort. But for some reason, I'm struggling
> with Forth. It feels like a hodge-podge of kludges to me. Perl is like
> that too in some ways, IMO.
That could be valuable! If you don't mind, would you write down what
looks like kludges to you as you notice them? If you keep learning Forth
after awhile the things that seem wrong will start to look natural and
you'll forget that they ever looked kludgey.
I remember a few from when I was first learning Forth. Like, I looked at
how IF ... ELSE ... THEN worked. I wrote a definition that had it, and
then I looked at the code that got laid down.
: FOO
IF 5 ELSE 3 THEN ;
And the code went
0branch address1 lit 5 branch address2 lit 3 exit
address1 was the address of the lit in "lit 3" and address2 was the
address of the exit.
There was an unconditional branch to an exit, for no reason. It would
have worked better to just do EXIT. Shorter and quicker.
But then I thought about it, and I considered how much more complicated
it would be to handle that kind of thing, and I realised that we got a
much simpler control structure if we just ignored these little
inefficiencies. A few years ago I read that ColorForth has extremely
simple control structures that make it easy to do this without the
waste. It took Chuck Moore something like 20 years to get around to
finding the better way.
I remember I wanted to do something with strings, and I thought the
command WORD ought to be useful. You give WORD a character and it gives
you a string from the input buffer that ends just before that character.
Or the rest of the input buffer if the character isn't there. Just what
I needed. But the Forth I was using didn't quite do that. It copied my
string onto the top of the dictionary, along with a byte to say how long
it was, and it flipped a bit on the last character. It did far more than
I wanted it to, so that I couldn't use it. Ten years later we
standardised PARSE which did some of what I wanted. Now we're
standardising PARSE-NAME which almost does the rest.
One of the things that seemed most kludgy to me was DO +LOOP . After I
studied it I understood why it had to be that way, but I forgot a few
times and had to track down bugs because of it.
: TEST1 10 0 DO I . 1 +LOOP ;
: TEST2 -10 0 DO I . -1 +LOOP ;
TEST1
0 1 2 3 4 5 6 7 8 9
TEST2
0 -1 -2 -3 -4 -5 -6 -7 -9 -9 -10
If you can accept that it has to be this way, then you'll accept any
other oddity you find in Forth.
People get blinded to such things. Write them down while you still
notice them.
> Let's resurrect FIG!! Can we do that together?
I don't know. We're scattered so monthly physical meetings had better
not be important. There's been a reasonably active Forth Chat which I
hear is not nearly as abrasive as comp.lang.forth. Maybe write up stuff
and publish it on a wiki?
> Can we crank out a
> "generic Forth" that we can all live with to be the new FIG flagship?
> Maybe the new "generic Forth" can include something from each of the
> current Forth hackers' Forth ;) You guys set up a core team and
> designate who can commit code to the project, a la the FreeBSD
> project. What do you say? You guys have the brain-power to do it --
> and you need now is the WILL!
Gforth was intended to be something like that, and it looks like a
technical success to me.
Just in case it helps, I'll tell you my story. I started out with Forth
because I was playing with a toy computer that only had Basic. I could
buy Forth on a ROM that replaced the Basic ROM and it was in theory far
more powerful. I taught myself how to use it. Forth in 8K ROM *did* do
far more than the Basic 8K ROM. And it was simple. After awhile I
learned that Forth well enough to decompile all the Forth commands. I
found a chart of the Z80 command set and I wrote a disassembler, and I
got the assembly language commands for the Forth primitives. I felt like
I really understood how it worked, far better than any other computer
system I'd ever seen.
I wrote some simple programs. An assistant for the DM of an AD&D game. A
hybrid genetic algorithm for the traveling salesman problem. It solved
the parts of the problem it was good at, and it displayed a map and let
the user solve the parts that human eyeballs helped with. A local
dispatch game, you'd send trucks around a map picking up stuff and
bringing it back to the warehouse, and you wanted to minimise the
distance traveled but new calls came in at random. Etc.
I got a new computer. I wrote a disassembler for the M68000. The new
Forth system was more complicated and I thought not as well done, but I
could use it. I never got around to decompiling it all. I lost interest
in adding assembler routines because it always seemed to be fast enough.
And I didn't have as much time.
I started using PCs and used F83. The standard did a lot of things
better but people complained. I wrote population genetics simulations,
plasmids spreading in evolving bacterial populations. I could write a
Forth program for my M68000 computer and then it ran unchanged on F83.
Impressive. I tried out lots of new ideas from Forth Dimensions but
somehow didn't use many of them. I particularly remember the generic
stack operator. You could make names like abcde|aabbeb and it would
figure out a way to get that stack effect and compile a command to do
it. It looked like a good idea but I never ever used it. And there were
lots of people coming up with improved CASE statements. Lots and lots. I
looked at the ideas and thought about which ones were better, but I
never ever used any CASE .
Then I got my own PC and I tried out Pygmy Forth. Pygmy had a
metacompiler that was very easy to use. So if you didn't like something
about the way it was designed, you could redesign it from source code
and if you didn't make any mistakes and you didn't change something that
would keep it from being metacompiled, you could make a Forth that did
it your way. Not just add your own commands on top, you could change the
fundamentals of how it worked. Suddenly all the things I didn't like
about whichever Forth I used, were open for change! I changed things for
my convenience. So for example, I didn't like the inconvenience of
changing BASE . Particularly when compiling, sometimes I'd want to
change to base 16 or base 2. But I had to switch back or later code
might be all wrong. Usually I'd do BASE @ >R and when I was finished I'd
to R> BASE ! to restore the old value. This was tedious. Sometimes I
wanted to use the return stack for something else and my base would get
in the way. Sometimes I wanted to keep the new base for more than one
input-buffer length and the system would treat my base as a return
address. It seemed -- kludgey. But now I had the power! I made a
separate stack to hold base values. I made a separate stack to hold DO
LOOP values, so it didn't interfere with the return stack. I changed
Pygmy around to suit myself. Occasionally I'd send my changes to Frank
Sergeant who wrote Pygmy, in case he was interested in any of them. I
wrote a simple routine that compared his source code and mine, so that
similar code always had the same block numbers. That way he could look
at his version and then switch to mine with a keystroke to see what was
different. He used a few of my changes including a few of my changes to
the metacompiler. But he basicly didn't like what I was doing to his
Forth. I was heading somewhere he didn't want to go. I made lots of
changes that made programming easier for me, but nobody else could run
my code unless they wanted to run my Forth. And nobody wanted to run my
Forth, they had their own Forths. The more changes I made, the more it
turned into my own private programming language that nobody else had any
interest in. And after awhile Pygmy was running in a DOS box on a
Windows computer. There was no hope to build marketable applications
with it. Designing my perfect Forth was a waste.
I looked at how to write maximally portable programs. It turns out that
the maximally portable parts are the glue that holds together the
special stuff. Different hardware requires different code. Different
Forths require different code in subtle ways. It was a mess. Very simple
code could be maximally portable pretty easily. Do anything the least
bit complicated and you had to know a whole lot to tell whether it would
port. Easier to build a lot of tests and test them on the new system and
hope that it would be OK if it passed the tests. Often it's harder to
port a complex application than it is to port the Forth the application
runs on. Why use another Forth? Just because it's available on the
target system? Port your Forth and your application doesn't have to deal
with subtle incompatibilities.
Now I leave comp.lang.forth for awhile, and then I come back and see
extremely interesting conversations going on. I participate, and after
awhile it looks like a lot of people don't like what I'm saying, and
that isn't what I want so I leave again. You can't expect to get much
more than argument from a Usenet newsgroup. That's what the format
encourages, and it doesn't encourage much else. You might do better with
something like a wiki. Explain what you want to accomplish. People who
agree with your goals can look at how to achieve them. People who
disagree can make their own wikis. Make it all fit into a design
specification, and build software to manage multiple paths toward
implementing what gets specified. I have some ideas about a format that
might encourage people to work together, different from Usenet. But when
I tried to present them on comp.lang.forth I got told that the experts
already know how to manage software projects, and I should shut up about
it. What you'd expect from a Usenet newsgroup.
Stephen J. Bevan
> Bruce McFarling wrote:
>> On Mar 24, 4:16 pm, John Doty <j...@whispertel.LoseTheH.net> wrote:
>>> But can one call a notation that lacks the properties of a language,
>>> "language"?
>> What in your view is the properties of a language?
>
> The universals linguists identify in languages: syntax, tree
> structured grammar, parts of speech, ...
The following trivial gramar (using EBNF) defines an idealised
concatenative notation (I'll refrain from calling it a language) :-
expr := symbol | number | '[' expr ']' | { expr } .
program := expr .
The following trivial grammar defines a idealised Lisp :-
expr := symbol | number | '(' { expr } ')' .
program := expr .
Either both define a language or neither do. If the former, then
Forth can have a grammar if having one is important, if the latter
then Lisp isn't a language.
Clearly grammar alone does not define a language, without semantics it
is all just meaningless symbols. Lisp, APL, and concatenative
languages share a trait that they have a trivial grammar and push
almost everything into the semantics. Thus grammar is mostly
irrelevant and semantics are what is important. That approach appeals
to some, but others abhor it. For example, Larry Wall, a trained
linguist, has nothing good to say about the Lisp approach and thinks
that the Perl approach is the right way. I'm with
McCarthy/Iverson/Moore but it seems that the majority is with Wall.
Marcel Hendrix
[..]
> So what'll it be? Are you guys going to continue along the sophist path to
> extinction if not utter irrelevance, or are you willing to at least _try_
> to get your shit together?
You are pointing at us, while it is let's-do-it enthusiasts like you that
are organizing the conferences, setting up the chapter meetings, writing the
docs, committing the papers, and getting the libraries set up :-)
-marcel
Gerry
> > > > The first is a low level coding trick ( R> DROP ) that isn't ANS
> > > > Forth and won't work on all systems, therefore very dubious.
>
> > > It doesn't have to be implemented with R> DROP . The idea is to
> > > have aptly-named words that execute EXIT to bail out from the
> > > current word, without having to type ... IF EXIT THEN ... each time.
> > > That can be useful apart from how it gets implemented.
>
> > I thought the idea of having ... R> DROP ... inside a word was to exit
> > from the *calling word* not the current word i.e. not to return to the
> > caller but to the caller's caller. This is not the same as ... IF EXIT
> > THEN ... in the current word. If I'm right perhaps you'd like to
> > explain how you can do the equivalent of ... R> DROP ... in ANS Forth
>
> For example,
>
> : ?EXIT
> POSTPONE 0= POSTPONE IF POSTPONE EXIT POSTPONE THEN ; IMMEDIATE
But this doesn't do the same thing. I'll summarise the technique used
in the Wiki. This advocates using this type of structure
: c ( evaluate some condition) IF R> DROP THEN ;
: b ... c ... ;
: a ... b ... ;
When executing c if the condition is TRUE the R> DROP returns control
to the body of word a, otherwise it returns to b. This is non-standard
and non-portable and therefore not good.
Replacing the IF R> DROP THEN with IF EXIT THEN simply returns control
to b as does your ?EXIT. Of course you can return a flag to b and put
IF EXIT THEN inside b but this is what the Wiki idea is trying to
avoid.
Offhand the only way I can think of doing a similar thing in ANS Forth
is to use CATCH in a and a THROW in b which misuses exceptions and
does not have the economy of R> DROP.
Gerry
Bernd Paysan
> Forth is only good for a specific kind of low-level factoring. That is,
> Forth makes it relatively easy to extract from a word a sequence of
> words and give it a name. There are various mutations of this (colon
> definitions, DOES> definitions, vectored execution, macros) and it's
> done for different reasons (eliminating common terms, defining new
> control structures, crude polymorphism, etc.). But that's pretty much it.
No, that isn't it. If you stop Forth there, you can also stop arguing with
us about "thinking" - you aren't doing it, you are only scratching the
surface. Forth allows you to add whatever paradigm you just want to have to
the language. Like object oriented programming, or pattern matching, fuzzy
logic, or rule based programming; whatever you like (I've seen all of that
done in Forth, done quite elegantly, sometimes done way too often, like the
OO extensions). Maybe the embedded programming people with their small
programs frown at this, but it *is* done.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Bernd Paysan
> But you are just trying to define the problem away: language, as
> understood by linguists, is what engages the human "language instinct",
> and that's a powerful mental "muscle". Weaker definitions only suit a
> weak language, one that cannot as effectively employ human mental power.
That's under the theory that the human mind thinks in terms of language
only. A rather stupid theory IMHO; if it would be true, 90% of our brain
would have been wasted (maybe it *is* wasted with most of the
population). "A picture says more than 1000 words" already tells you that
people have severe difficulties to map graphical thoughts into language.
They have the same problems with other thoughts, that's why mathematics
invent their own way of communication instead of using normal language.
Your critic that Forth forces the user to think like a computer IMHO is the
strength of Forth. In order to program a computer, I have to think like a
computer, I can't use the imprecise, inaccurate thinking I do when talking
to other people (often the main message is between the lines, e.g. when
joking). The computer needs to be told exactly what it must do and in which
order.
Forth allows me to do that easily, because it is rather unambiguous about
how the computer understands it (unlike e.g. C, where different
implementations can even have different precedence rules for some
operators, or at least had in the transition between K&R and ANSI - today,
I only use GCC, and won't see the problem anymore). I view my brain as a
flexible entity, and I can wrap it around the problem, not the other way
round. That's why the language that fits me allows me to wrap the language
around the problem, too.
Even if Larry Wall is right, and the majority of the population likes a
computer language that allows them to talk to the computer like they talk
to humans (imprecise ;-), I hate his language. Perl IMHO is gibberish (it
resembles a cat walking over a keyboard much more than any natural
language), and the semantics is so imprecise that most Perl programs I had
to maintain (typical write-once-run-a-few-times programs) were a bag of
bugs, which were better replaced completely (in my case by Forth programs).
If Larry Wall's language design is a consequence of the psychology of most
programmers, I don't want to know what madness lies behind that ;-). Maybe
there's no accident that Larry won the obfuscated C contest twice.
Bernd Paysan
> Having read this thread from its beginning, it sweep over this newbie that
> the current Forth community - such as it is - is _not_ a co-operative
> society, but rather a chronically argumentative one. It is truely sick!
Hey, this is a debate club, if you want to watch debates (often the same
over and over again ;-), watch here. This is not the place where people
write useful Forth programs, this is not "the" community. A number of
posters here are deliberately trying to provoke discussions (they are not
as awful as other usenet trolls ;-), or at least try to provoke thoughts.
For simple reasons, those who are best to provoke discussions have the
longest threads, and therefore most of the content here.
Richard Owlett
> Elizabeth D Rather wrote:
>
>> John Doty wrote:
>>
>>> Elizabeth D Rather wrote:
>>
>>
[snip]
>> Yes, I've heard Michael Coughlin's tale about the project at
>> Smithsonian in the 70's where programmers "couldn't read their own code".
>
>
> And you failed to take it seriously. Your response to anything contrary
> to your ideology is denial.
>
Gee, Ms. Rather has not yet learned that only the great Doty is *RIGHT*
-- by definition (that is "his definition" and who is better to define
it, he is after all right (by definition ;)
Andrew Haley
> Having read this thread from its beginning, it sweep over this
> newbie that the current Forth community - such as it is - is _not_ a
> co-operative society, but rather a chronically argumentative one. It
> is truely sick!
No, it's just the usual crap from John Doty, who has his obsession _du
jour_ and pushes it into every discussion, relevant or not. And we
argue against him because we think he's wrong.
I suppose we could change the Subject line by adding [Doty] every time
this happens, thus making it easy for people to use their killfiles.
Andrew.
Jonah Thomas
> > > > > The first is a low level coding trick ( R> DROP ) that isn't
> > > > > ANS Forth and won't work on all systems, therefore very
> > > > > dubious.
> >
> > > > It doesn't have to be implemented with R> DROP . The idea is to
> > > > have aptly-named words that execute EXIT to bail out from the
> > > > current word, without having to type ... IF EXIT THEN ... each
> > > > time. That can be useful apart from how it gets implemented.
> >
> > > I thought the idea of having ... R> DROP ... inside a word was to
> > > exit from the *calling word* not the current word i.e. not to
> > > return to the caller but to the caller's caller. This is not the
> > > same as ... IF EXIT THEN ... in the current word. If I'm right
> > > perhaps you'd like to explain how you can do the equivalent of ...
> > > R> DROP ... in ANS Forth
> >
> > For example,
> >
> > : ?EXIT
> > POSTPONE 0= POSTPONE IF POSTPONE EXIT POSTPONE THEN ; IMMEDIATE
>
> But this doesn't do the same thing.
It does nearly the same thing. It's a macro instead of a called command,
though.
> I'll summarise the technique used
> in the Wiki. This advocates using this type of structure
>
> : c ( evaluate some condition) IF R> DROP THEN ;
>
> : b ... c ... ;
>
> : a ... b ... ;
>
> When executing c if the condition is TRUE the R> DROP returns control
> to the body of word a, otherwise it returns to b. This is non-standard
> and non-portable and therefore not good.
>
> Replacing the IF R> DROP THEN with IF EXIT THEN simply returns control
> to b as does your ?EXIT. Of course you can return a flag to b and put
> IF EXIT THEN inside b but this is what the Wiki idea is trying to
> avoid.
: c [compile a macro] ; immediate
: b ... IF EXIT THEN ... ;
: a ... b ... ;
> Offhand the only way I can think of doing a similar thing in ANS Forth
> is to use CATCH in a and a THROW in b which misuses exceptions and
> does not have the economy of R> DROP.
This is another way. It has the disadvantage that the whole macro gets
compiled fresh every time you use it. In my example that's 2 words plus
an IF (at least 2 cells in many implementations) that get compiled into
*every* word that uses ?EXIT instead of just one call.
It isn't ideal, but it is portable to systems that R> DROP won't work.
But then, R> DROP will work on most Forth systems. The ones it won't are
special. 32-bit Forths with 16-bit address spaces and a 16-bit return
stack, etc.