FORTH vs C
msi...@tefbbs.com
Face it. FORTH will never be popular.
C was designed to enable large groups of barely competent programmers
to turn out large quasi-realtime databases. And it is excellent for
the purpose. The smart individuals write drivers. The less bright do
production code.
FORTH was designed to allow a smart individual to control all of a
computer system.
Face it. There are not enough smart individuals to make FORTH popular.
Simon
Opinions expressed herein are solely my own and may or may not reflect my opinion at this particular time or any other.
Samuel A Falvo II
Yes, I know this is "flame bait", but I'll bite... :)
>Face it. There are not enough smart individuals to make FORTH popular.
I beg to differ. If this were the case, we wouldn't have two compatible
standards of FORTHs, and OpenFirmware wouldn't exist. If you ask me,
that speak EXTREMELY highly of Forth.
==========================================================================
KC5TJA/6 | -| TEAM DOLPHIN |-
DM13 | Chief Architect and Project Founder
QRP-L #1447 |
msi...@tefbbs.com
Don't get me wrong. I think FORTH is great.
I just think most programmers and hardware designers are not smart
enough to get it. C was designed to isolate programs and programmers
from the machine. FORTH in its soul is the machine.
I have been looking at these issues for a long time. I program in C.
I do everything I can in FORTH.
I cite time gains of 3:1 and total productivity gains of 10:1. Nobody
is interested. (I can do it 3X faster with 1/3 the number of people].
Simon
---------------------------------------------------------------------------------------------------------------
Opinions expressed herein are solely my own and may or may not reflect my opinion at this particular time or any other.
msi...@tefbbs.com
If you look up the libraries at taygeta I have a submission under the
Z-80 (a FORTH for the Super 8].
Just so you don't think I'm anti-FORTH.
It just seems like most managers and programmers are not smart enough
to understand the power of the FORTH.
Simon
----------------------------------------------------------------------------------------------------------------------
Gary Chanson
>I just think most programmers and hardware designers are not smart
>enough to get it. C was designed to isolate programs and programmers
>from the machine. FORTH in its soul is the machine.
Not true. C was intended to be a multi-platform language that did
not prevent the programmer from doing *ANYTHING*. Pascal, on the other hand
was intended to hide the underlying machine from the programmer.
-GJC
-gcha...@user1.channel1.com
---
* Arcane Incantations BBS * Windows95 * Programs - Tools - Support *
* 781-843-7089 * DOS * Free Access
*
Jerry Avins
MY RETURN ADDRESS IS ALTERED TO FOIL SPAMBOTS.
******* REMOVE THE "X" TO REPLY *******
Oh, well; I'm too tired to resist a good bicker. Pascal, like Basic, was
designed as a teaching tool. The fact that several generations of the
students who learned it in school went on to write production code in it
is a perversion not to be blamed on the language. (But then, I don't
think much of Modula either. If I go on, I'll have nasty things to say
about structured assembly code, too.)
-- Jerry
Engineering is the art | Let's talk about what
of making what you want | you need; you may see
from things you can get. | how to do without it.
----------------------------------------------------------
Andreas Kochenburger
A too narrow viewpoint.
It should read: Programmers are not popular - who cares what they do.
Or similarly: Engineers are like camels upon which managers ride
through the desert.
Or as sung by Liza Minelly in 'Cabaret': Money makes the world go
round, go round ...
Since all this leads us to nothing:
If you're too smart for Forth - just leave it.
On Sat, 04 Apr 1998 15:26:10 GMT, msi...@tefbbs.com wrote:
>Face it. FORTH will never be popular.
>
>Face it. There are not enough smart individuals to make FORTH popular.
>
>Simon
Bernd Paysan
msi...@tefbbs.com wrote:
> It just seems like most managers and programmers are not smart enough
> to understand the power of the FORTH.
Sometimes as Forther you feel like a Jedi night. People think about
Forth as an ancient religion, with it's followers doing things like
standing on one hand and lifting stones with the force of their minds.
And well, The Emperor doesn't like Forth.
Computer science is difficult. It needs smart people do get great things
done. However, for a company, smart people don't fit in well. A company
needs tools to have the Wallies do something, even if it's insignificant
and they constantly miss their goals. A typical policy is to make people
replacible. But as Stoustrup says, if you do that, you get replacible
people, thus people who don't do any significant work, and who don't
show their talents.
The result is that you must have tools that everybody can use. Forth
isn't among this class of tools. On the "Echtzeit" ("real time")
exhibition, I met several people who said that they didn't have
understood "that Forth thing", when they tried long ago. It is
different, and it empowers the smarter people. I don't think that
mediocre programmers really write worse Forth programs than C programs,
but the smart people don't write that much better C programs than they
write better Forth programs, so the difference is smaller. And with the
typical lack of libraries in Forth, the mediocre programmers constantly
struggle with things that are available in C environments.
The most important thing is that to write good Forth programs, you must
think layered. Your program will consist of added primitives, basic
functions, intermediate logic, and top-level words, and due to the
nature of good Forth programs, it won't be only application, but is also
a library. But people tend to think lineary in a flat world. Forth
encourages layering much more than C does.
--
Bernd Paysan
"Late answers are wrong answers!"
http://www.jwdt.com/~paysan/
John Nangreaves
Thought:
If Forth were more popular, would we be as 'fanatical' about it
therefore as good at it?
I work with people who have converted from Forth to C recently; they
now have a bunch of techs who program C all working on the same
problems creating piles of fixes that are probably interfering with
eachother creating a system composed of patches with hardly any real
body left to the code. But there is a bunch of them who can do it!
I plug away at my little boards, churning out system after system,
smirking quietly at their anti-Forth jeers, showing them in passing
this week's system...
Let them play. I know I am doing more with less, faster than the lot
of them combined. Maybe I'm fanatical, maybe I'm lucky. Maybe I'm
using the right tool for the job.
msi...@tefbbs.com wrote in article
<35264f0f...@news.megsinet.net>...
> Face it. FORTH will never be popular.
>
> C was designed to enable large groups of barely competent
programmers
> to turn out large quasi-realtime databases. And it is excellent for
> the purpose. The smart individuals write drivers. The less bright
do
> production code.
>
> FORTH was designed to allow a smart individual to control all of a
> computer system.
>
> Face it. There are not enough smart individuals to make FORTH
popular.
>
> Simon
Bill
msi...@tefbbs.com wrote in message <35264f0f...@news.megsinet.net>...
>Face it. FORTH will never be popular.
>
>C was designed to enable large groups of barely competent programmers
>to turn out large quasi-realtime databases. And it is excellent for
>the purpose. The smart individuals write drivers. The less bright do
>production code.
>
>FORTH was designed to allow a smart individual to control all of a
>computer system.
>
>Face it. There are not enough smart individuals to make FORTH popular.
Heck, who wants it to be like 'C'. Give me a Forth with a front end like
VB5 and I'll have some real fun.
Bill
Rainier
Hmmm,
Sounds like missing the point to me.
Point is: What does it matter ?
If you can do a job in Forth and the result is what you want, then fine !
If you can do the job in C and the result is what you want, also fine !
Just to confuse the whole thing:
Try Embedded Pascal:
http://www.geocities.com/SiliconValley/Vista/1170/z180pas.zip
There are good tools, there are bad ones. If a tool fits the job at hand
(and you like it), use it ! Simple.
The problem comes in if you are using a tool that does not fit the job.
Case in point ? Try use Forth for Windows GUI development, or try use
Visual C++ for that little embedded application.
--
Rainier Lamers
R&D Questek Marketing
Johannesburg
South Africa
--
Rainier Lamers
R&D Questek Marketing
Johannesburg
South Africa
msi...@tefbbs.com
I have no idea what the 'C' compiler is doing to my code.
I have always found it clumsy for real time programming vs FORTH.
I do most of my programming at the machine level. There are things
that are trivial in FORTH or assembler that are difficult to very
difficult to impossible in 'C'.
C knows nothing about I/O.
Trying to lay different data in the same memory area is a pain.
Structures and unions of structures etc.
In FORTH or assembly I just tell the machine what I want directly.
- This data goes there, that data goes here.
A Telco database needs more protection than a machine tool.
"Gary Chanson" <no....@please.com> wrote:
>>I just think most programmers and hardware designers are not smart
>>enough to get it. C was designed to isolate programs and programmers
>>from the machine. FORTH in its soul is the machine.
>
>
> Not true. C was intended to be a multi-platform language that did
>not prevent the programmer from doing *ANYTHING*. Pascal, on the other hand
>was intended to hide the underlying machine from the programmer.
>
>-GJC
>-gcha...@user1.channel1.com
>---
> * Arcane Incantations BBS * Windows95 * Programs - Tools - Support *
> * 781-843-7089 * DOS * Free Access
>*
>
>
>
Opinions expressed herein are solely my own and may or may not reflect my opinion at this particular time or any other.
Bernd Paysan
Rainier wrote:
> The problem comes in if you are using a tool that does not fit the job.
> Case in point ? Try use Forth for Windows GUI development, or try use
> Visual C++ for that little embedded application.
No, Forth does much better for GUI development than VC++ does for little
embedded applications. MINOS IMHO does even better than VC++, although
Theseus still needs a lot of work (but since bare MINOS is easy to
program, it doesn't matter that much).
Stephen Pelc
Rainier <rai...@questek.co.za> wrote in article
<35291A...@questek.co.za>...
> There are good tools, there are bad ones. If a tool fits the job at hand
> (and you like it), use it ! Simple.
> The problem comes in if you are using a tool that does not fit the job.
> Case in point ? Try use Forth for Windows GUI development, or try use
> Visual C++ for that little embedded application.
You don't say which Windows Forths and versions you have tried for GUI
development. The GUI tool level within ProForth for Windows has changed
dramatically over the last two years (PFW current version is 2.1) and
provides more functionality than any other Windows Forth.
ProForth is used for large Windows applications. Where all Forths score
over C and C++ is in the ability to perform very rapid debugging of
applications. If you want to find out what large Windows development
with ProForth is like I can give you a reference site in Capetown.
--
Stephen Pelc, MicroProcessor Engineering - More real, less time
133 Hill Lane, Shirley, Southampton SO15 5AF, England
tel: +44 1703 631441, fax: +44 1703 339691, net: s...@mpeltd.demon.co.uk
web: http://www.mpeltd.demon.co.uk
Dave Kenny
Bill <bv...@inetworld.net> wrote:
: Heck, who wants it to be like 'C'. Give me a Forth with a front end like
: VB5 and I'll have some real fun.
"VB5" ?
Is this a "Visual Basic" ?
I've had to use the VBA stuff built into M$ Access on several occasions
and, while there actually _are_ a number of good things about it,
overall, I'd rather be somewhere else.
For me, overall, the most productive environment by far was F83 by
Laxen & Perry. Running off a 360KB 5 1/2 diskette on a <5 Mhz 8088,
it was more responsive and generally useful than any of the so-called
"Integrated Development Environments" from Micro$oft, Borland, or
<gasp> the Free Software Foundation's Emacs/GUD/GDB world, all of
which I ran on _far_ more powerful hardware than F83.
I think these were the major contributors to my productivity:
1) Forth the language encourages better work habits by making it
really easy to test, by making the overhead for modularity
(subroutines) almost negligible, and by discouraging the
use of junk variables which can produce lots of extraneous
coupling between parts of a program.
2) L&P's F83 had a very nice debugging scheme. As I recall you
just said DEBUG SomeWord, then typed in a line of code to
interpret. When it got inside of SomeWord, it printed
the name of the next word to execute and did a .S. You
either continued (within SomeWord, never diving any deeper)
or aborted.
Each time the .S shows something went awry, you debug the
word that did it. Eventually you see where things went wrong.
Zeroing in a problem this way was very fast and simple.
3) F83 was thoroughly commented and self documenting. Each word
had compiled into it a FileNumber/BlockNumber combination
identifying the source block (if appropriate) from which it
had been compiled. A word VIEW was provided that, given the
name of a word, displayed this screen of source code.
This turned code in F83 into a sort of automatic hypertext.
Another word made it very easy to switch from a screen of code
to the associated "shadow" screen which gave the comments.
Because the VIEW and shadow mechanisms were built into F83,
one's own code could also be easily explored, as long there
were comments, particularly in shadow screens.
Finally, because ALL the code to F83 was viewable this way,
even the low level words that had to be metacompiled, the
system itself became a Forth tutorial and handy grab bag
of techniques.
4) There was a little built in hex+ascii dump word. This, together
with the way the dictionary was implemented, made it possible
to understand a great deal just by dumping out the most recent
few dozen bytes of the dictionary. A simple DUMP word is also
great for testing code that is not purely functional but has
effects other than on the top few stack elements.
All this stuff was basically very simple, but "the whole was more than
the sum of its parts." Far more.
msi...@tefbbs.com
I think F-PC has an adequate set of libraries. I have also extensively
cribbed from some of the examples provided.
I love it as a machine control language.
The floating point support is excellent in my opinion. The disk I/o
works for me.
Tim Hentlass' book is excellent.
I have used it for machine communication simulation using two PCs in
FORTH to simulate a HC11 in C and a master controller.
OH yes. Its free. As is the Hentlass book. Tom Zimmer and Tim
Hentlass have made a very valuable contribution.
Simon
Bernd Paysan <bernd....@remove.muenchen.this.org.junk> wrote:
>--
>Bernd Paysan
>"Late answers are wrong answers!"
>http://www.jwdt.com/~paysan/
Opinions expressed herein are solely my own and may or may not reflect my opinion at this particular time or any other.
msi...@tefbbs.com
I think it should be - if you're not smart enough for FORTH just leave
it.
Simon
FORTH is an intelligence test.
------------------------------------------------------------------------------------------------
koch...@khe.scn.de (Andreas Kochenburger) wrote:
>A too narrow viewpoint.
>It should read: Programmers are not popular - who cares what they do.
>Or similarly: Engineers are like camels upon which managers ride
> through the desert.
>Or as sung by Liza Minelly in 'Cabaret': Money makes the world go
> round, go round ...
>
>Since all this leads us to nothing:
> If you're too smart for Forth - just leave it.
>
>
>On Sat, 04 Apr 1998 15:26:10 GMT, msi...@tefbbs.com wrote:
>
>>Face it. FORTH will never be popular.
>>
>>Face it. There are not enough smart individuals to make FORTH popular.
>>
>>Simon
msi...@tefbbs.com
We would be better. the more independent minds on a problem the
faster/better the solution.
With F-PC and a Pentium 90 I can do 90 Million NOOPs a second in
FORTH. Very fine control indeed.
Simon
-------------------------------------------------------------------------------------------------------------
"John Nangreaves" <NOSPA...@mi-systems.com> wrote:
>Thought:
>
>If Forth were more popular, would we be as 'fanatical' about it
>therefore as good at it?
>
>I work with people who have converted from Forth to C recently; they
>now have a bunch of techs who program C all working on the same
>problems creating piles of fixes that are probably interfering with
>eachother creating a system composed of patches with hardly any real
>body left to the code. But there is a bunch of them who can do it!
>
>I plug away at my little boards, churning out system after system,
>smirking quietly at their anti-Forth jeers, showing them in passing
>this week's system...
>
>Let them play. I know I am doing more with less, faster than the lot
>of them combined. Maybe I'm fanatical, maybe I'm lucky. Maybe I'm
>using the right tool for the job.
>
>
>
>msi...@tefbbs.com wrote in article
><35264f0f...@news.megsinet.net>...
>> Face it. FORTH will never be popular.
>>
>> C was designed to enable large groups of barely competent
>programmers
>> to turn out large quasi-realtime databases. And it is excellent for
>> the purpose. The smart individuals write drivers. The less bright
>do
>> production code.
>>
>> FORTH was designed to allow a smart individual to control all of a
>> computer system.
>>
Samuel A Falvo II
>No, Forth does much better for GUI development than VC++ does for little
>embedded applications. MINOS IMHO does even better than VC++, although
>Theseus still needs a lot of work (but since bare MINOS is easy to
>program, it doesn't matter that much).
Do you have any documentation on how to program bare MINOS? There's a few
X programs that I'd like to write. Also, is MINOS fully portable to Win32
without excessive crashing?
Thanks for the information.
Andreas Kochenburger
That was not the point.
Too intelligent people often don't fit well in teams. IMO Forth is
fantastic for individuals. But I have never heard of a CASE system
supporting Forth.
Thus if you want to or have to earn your money with programming, don't
use Forth - take C or whatever fits best to the team goal.
On Wed, 08 Apr 1998 01:52:06 GMT, msi...@tefbbs.com wrote:
>I think it should be - if you're not smart enough for FORTH just leave
>it.
>
>Simon
>
>FORTH is an intelligence test.
>------------------------------------------------------------------------------------------------
>koch...@khe.scn.de (Andreas Kochenburger) wrote:
>
>>A too narrow viewpoint.
>>It should read: Programmers are not popular - who cares what they do.
>>Or similarly: Engineers are like camels upon which managers ride
>> through the desert.
>>Or as sung by Liza Minelly in 'Cabaret': Money makes the world go
>> round, go round ...
>>
>>Since all this leads us to nothing:
>> If you're too smart for Forth - just leave it.
---------------------------------------------------
To reply, change in address: no -> khe, scn <- spam
Bernd Paysan
Samuel A Falvo II wrote:
>
> >No, Forth does much better for GUI development than VC++ does for little
> >embedded applications. MINOS IMHO does even better than VC++, although
> >Theseus still needs a lot of work (but since bare MINOS is easy to
> >program, it doesn't matter that much).
>
> Do you have any documentation on how to program bare MINOS?
Yes, there is the full source ;-). No, there is no tutorial and such
like, but it is under the way.
> There's a few
> X programs that I'd like to write. Also, is MINOS fully portable to Win32
> without excessive crashing?
In principle, yes. In practice, noone had the time to fix all the
problems. It doesn't affect smaller programs that much, but it affects
complex ones like Theseus.
Bernd Paysan
Andreas Kochenburger wrote:
> That was not the point.
> Too intelligent people often don't fit well in teams.
I think it's more that people with different IQs don't fit well into the
same team. If you can't cooperate with meeting going morons, this does
not mean that you can't cooperate at all. If it takes me longer to
explain something than to do it myself, I'll do it myself.
> IMO Forth is
> fantastic for individuals. But I have never heard of a CASE system
> supporting Forth.
If you expand CASE to Computer Aided Software Engineering, Forth is a
CASE system itself. It provides a lot of aids for software engineering.
It just does not threat the programmer as stupid fool. Fools should not
program.
> Thus if you want to or have to earn your money with programming, don't
> use Forth - take C or whatever fits best to the team goal.
Do you really think these meeting going morons that are barely capable
of writing C contribute something to the product (other than bugs and
bad design decisions)? Yes, this is the way many companies work, but
this is also the reason why McKinsey earns such much money. He doesn't
give solutions, either, because this would eventually stop his income.
Andrew Haley
Andreas Kochenburger (koch...@no.spam.de) wrote:
: That was not the point.
: Too intelligent people often don't fit well in teams.
This is based on a poverty-stricken definition of "intelligence".
Intelligence has very many components, and one of them is the ability
to interact with others. Any meaningful use of the word should not
include just technical problem-solving abilities.
Andrew.
Carl Gundel
msi...@tefbbs.com wrote in article <352792d7...@news.megsinet.net>...
> If you look up the libraries at taygeta I have a submission under the
> Z-80 (a FORTH for the Super 8].
>
> Just so you don't think I'm anti-FORTH.
>
> It just seems like most managers and programmers are not smart enough
> to understand the power of the FORTH.
This sounds just like the Smalltalk vs. Java dialogs. ;-)
Carl
Carl Gundel
Andreas Kochenburger <koch...@no.spam.de> wrote in article
<352b41d2.12977570@news>...
> That was not the point.
> fantastic for individuals. But I have never heard of a CASE system
> supporting Forth.
> use Forth - take C or whatever fits best to the team goal.
FORTH is an artistic/architectural medium. Art is usually a product of an
individual's vision.
Carl
Carl Gundel
Andrew Haley <a...@cygnus.remove.co.uk> wrote in article
<6gi9gb$b0k$2...@korai.cygnus.co.uk>...
> Andreas Kochenburger (koch...@no.spam.de) wrote:
> : That was not the point.
> : Too intelligent people often don't fit well in teams.
>
> This is based on a poverty-stricken definition of "intelligence".
> Intelligence has very many components, and one of them is the ability
> to interact with others. Any meaningful use of the word should not
> include just technical problem-solving abilities.
Good point. The problem though is that there aren't enough "intelligent"
people with the drive to cultivate their understanding in others (a
nontrivial goal, to be sure).
Carl
Andreas Kochenburger
Everything just fine - as long as the software project does not exceed
a certain size. Size meaning
- you need a fulltime project manager (freed from programming work)
- you are under time restrictions and need to develop in parallel
lines
- you have to provide support over generations of programmers
- you have to provide support for different software versions at the
same time
et cetera.
How comes that most (afaik even commercial) Forth systems are or were
the babies of one or max. 2 individuals as fathers?
Elizabeth D. Rather
Andreas Kochenburger wrote:
> Everything just fine - as long as the software project does not exceed
>
> a certain size. Size meaning
> - you need a fulltime project manager (freed from programming work)
> - you are under time restrictions and need to develop in parallel
> lines
> - you have to provide support over generations of programmers
> - you have to provide support for different software versions at the
> same time
> et cetera.
We regularly do all of these things, and have for many years, as have
manyof our customers. For example, we are currently supporting a
customer
who is converting a very complex database application to our latest
Windows
software. That application was originally written by Chuck Moore in
1976.
It's been maintained by the customer's in-house staff, occasional hired
consultants, and occasional contracts to FORTH, Inc. over the years.
It's
been through 4 generations of hardware. It's still "state-of-the-art"
in the
sense that no equivalent capability has ever been developed, although
our
customer knows of at least one organization that invested 10 programmer-
years trying.
FORTH, Inc. itself has had a staff of programmers that has evolved over
the years, and we still have occasions when we need to pick up something
done by someone else years ago and update or extend it. Works fine.
We're also supporting a couple of generations of our own products on
a variety of platforms, as does MPE and probably other Forth shops.
I urge you to be careful about saying in public something is
"impossible"
with Forth just because you personally have never done it.
> How comes that most (afaik even commercial) Forth systems are or were
> the babies of one or max. 2 individuals as fathers?
Because it doesn't take any more than that. Do _you_ use 10 peopleto
screw in a lightbulb?
Complex applications, however, are quite another story, and often
require
good-size teams. However, use of Forth in a project does _reduce_ the
size of the team required to do the project effectively, which helps get
it
done quicker and better.
Cheers,
Elizabeth
--
===============================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-372-8493
111 N. Sepulveda Blvd. Fax: +1 310-318-7130
Manhattan Beach, CA 90266
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
===============================================
Jerry Avins
MY RETURN ADDRESS IS ALTERED TO FOIL SPAMBOTS.
******* REMOVE THE "X" TO REPLY *******
Carl Gundel wrote:
>
> Andreas Kochenburger <koch...@no.spam.de> wrote in article
> <352b41d2.12977570@news>...
> > That was not the point.
> > Too intelligent people often don't fit well in teams. IMO Forth is
> > fantastic for individuals. But I have never heard of a CASE system
> > supporting Forth.
> > Thus if you want to or have to earn your money with programming,
> > don't use Forth - take C or whatever fits best to the team goal.
>
> FORTH is an artistic/architectural medium. Art is usually a product of an
> individual's vision.
>
> Carl
How many architects work in a typical office? And what is the typical
team size working on a major project? Projects often bring an
individual's vision to fruition with the help of an enthusiastic,
intelligent team.
Jerry
--
Ken Deboy
msi...@tefbbs.com wrote:
-- snip --
> With F-PC and a Pentium 90 I can do 90 Million NOOPs a second in
> FORTH. Very fine control indeed.
>
> Simon
What does 90 million noops get you? NOTHING ;) I think Forth's big-
gest problem is that it costs WAY too much to get a decent commercial
system. OTOH, 'commercial-grade' C compilers can be had for less than
$200 or so (much less if willing to accept last years 'best').
Also, I think that Forth is the best at certain things, and I think
C is a bad choice for some things. However that doesn't mean that Forth
is the best for everything, and it also doesn't mean that C is poor at
everything. For some things, just _maybe_ C is a better choice...
Other problems I see with Forth are lack of a Standard (hopefully
ANS Forth will cure this, but somehow I doubt it), and lack of good
books. For example, a lot of what I want to do with a computer has to
do with text processing, disk files, etc... How do you do it in Forth?
It depends on what Forth:) Hard core Forthers might say a person is
stupid if they don't just want to write their own file system driver,
etc. In C, it's easy, and more importantly, as a student I can find
examples to show me how to do it.
I will agree that Forth seems to have more 'smart' people 'per capita'
than C, but it's really a shame that some of them don't want to use
their energy to write a good book(documentation WITH EXAMPLES) of an
existing and AFFORDABLE (hint: Win32Forth, iForth, GForth, etc) in-
stead of calling people who like other languages stupid or reinventing
yet another Forth.
With best wishes,
Ken Deboy
Ken Deboy
Bill wrote:
-- snip --
> >C was designed to enable large groups of barely competent
> >programmers to turn out large quasi-realtime databases. And
> >it is excellent for the purpose.
ACtually, C is a pretty crappy language to do data base developing
in. Actually, I believeit was designed to implement an OS (Unix) in,
because it was more portable than PDP-(7? 11?) assembler.
> >FORTH was designed to allow a smart individual to control all of a
> >computer system.
> >
> >Face it. There are not enough smart individuals to make FORTH
Maybe Forth was also designed as a better alternative to assembler...
> Heck, who wants it to be like 'C'. Give me a Forth with a front end
> like VB5 and I'll have some real fun.
>
> Bill
I think there is one (MINOS?) but good luck finding documentation on
it. Maybe ProForth too but it is VERY EXPENSIVE.
Ken
Brian Fox
Elizabeth D. Rather wrote:
>
> Andreas Kochenburger wrote:
>
> > Everything just fine - as long as the software project does not exceed
> >
> > a certain size. Size meaning
> > - you need a fulltime project manager (freed from programming work)
> > - you are under time restrictions and need to develop in parallel
> > lines
> > - you have to provide support over generations of programmers
> > - you have to provide support for different software versions at the
> > same time
> > et cetera.
>
> We regularly do all of these things, and have for many years, as have
> manyof our customers. For example, we are currently supporting a
> customer
> who is converting a very complex database application to our latest
> Windows software. That application was originally written by Chuck Moore in
> 1976.
> It's been maintained by the customer's in-house staff, occasional hired
> consultants, and occasional contracts to FORTH, Inc. over the years.
> It's been through 4 generations of hardware. It's still "state-of-the-art"
> in the sense that no equivalent capability has ever been developed, although
> our customer knows of at least one organization that invested 10 programmer-
> years trying.
<snip>
Elizabeth;
Without telling to much "out of school" would it be possible to briefly
describe the features
of this database that make it so unique and hard for others to copy?
Brian Fox
Keep the Forth
Carl Gundel
Jerry Avins <jya...@Xerols.com> wrote in article
<352D7C...@Xerols.com>...
> Carl Gundel wrote:
> > FORTH is an artistic/architectural medium. Art is usually a product of
an
> > individual's vision.
> >
> > Carl
>
> How many architects work in a typical office? And what is the typical
> team size working on a major project? Projects often bring an
> individual's vision to fruition with the help of an enthusiastic,
> intelligent team.
That's right. There should be a unity of vision in the design of any large
system.
I'll add that good software engineers aspire to be architects. The
officially titled architect should encourage and instruct this kind of
attitude. In this fast changing world of computers, it is essential that
we are always eager to learn new and better ways to build software.
Carl
msi...@tefbbs.com
It gets you quite a bit if you are using them to tune timing loops.
I have a 25 MHz VME at work.
An empty 'for' loop in C on this machine runs 3 micro seconds.
75 clock cycles for a decrement, compare, and branch. Pitiful.
Get F-PC. Get Tim Hentlass' book. All FREE. All VERY GOOD.
Simon
Ken Deboy <glockr@locked_and_loaded.reno.nv.us> wrote:
Opinions expressed herein are solely my own and may or may not reflect my opinion at this particular time or any other.
msi...@tefbbs.com
If you get F-PC and Tim Hentlass' book you will have a system as good
as any 'C' system you can buy. Floating point libraries. File
management words. And its FREE. Try it.
A LOT of examples of working code are included with F-PC. Well
documented.
Simon
-----------------------------------------------------------------------------------------
Ken Deboy <glockr@locked_and_loaded.reno.nv.us> wrote:
Opinions expressed herein are solely my own and may or may not reflect my opinion at this particular time or any other.
Stephen Pelc
Ken Deboy <glockr@locked_and_loaded.reno.nv.us> wrote in article
<352D9D57.3100BC5D@locked_and_loaded.reno.nv.us>...
> > Heck, who wants it to be like 'C'. Give me a Forth with a front end
> > like VB5 and I'll have some real fun.
> >
> > Bill
>
> I think there is one (MINOS?) but good luck finding documentation on
> it. Maybe ProForth too but it is VERY EXPENSIVE.
any other Windows Forth. The effort MPE has put into both the development
and the documentation of this product explains why it appears expensive.
ProForth comes with 1000+ pages of documentation.
Undocumented software costs huge numbers of engineering days.
However, ProForth costs only a few engineering days. Nearly all software
tools are trivially cheap when compared to labour costs.
Jonah Thomas
In article <01bd653b$801cf860$0200a8c0@stephen>,
"Stephen Pelc" <s...@mpeltd.demon.co.uk> wrote:
>Undocumented software costs huge numbers of engineering days.
>However, ProForth costs only a few engineering days. Nearly all software
>tools are trivially cheap when compared to labour costs.
By any rational standard, you're completely right. So why isn't this
argument more convincing?
Is it that the wages are already costed, and aren't considered, while new
software expense is very visible?
It's easy to see why engineers don't make the argument more often. "Buy
me this new $2000 tool, it will make me much more productive and it's a
trivial expense compared to what you're paying me." The number of possible
counterproductive responses far outweighs the number of good responses.
Then there are the training costs to learn new tools. If it takes an
engineer a week to get proficient in the new software, that swamps the
software cost right there. Even if he doesn't spend a week in a strange
city taking classes. Forth is vastly easier to learn than C, particularly
commercial Forths that have libraries full of the things you'd use CREATE
DOES> for. But C is another sunk cost, they already know C. It could
rationally be argued that a good Forth is easier to learn than a new C
environment -- but who would believe it, if they haven't already seen it?
It's predictable that the learning cost for a new language will be higher
than for a new version of a known language.
The first problem might be solved, though not by software vendors. If the
development experts -- the ones who make big money as consultants, DeMarco,
Booch, etc -- were to point out that COTS software costs are trivial compared
to wages, and that it makes sense to allocate a budget for new software (say
5% of engineering wages? 3%?) then over time those recommendations might
start getting into the budgets. If the money is already allocated, it isn't
so important to buy 5 cheap tools instead of one expensive one, as it would
be to dig up new money for one tool.
But would those experts actually recommend this? Introducing new tools in
mid-project would usually delay things. Even worse, if you let the engineers
themselves choose the tools and then learn to use them, both parts of it use
time that they could be working. (One of my friends was going through the
minutes of the old Birmingham USA library board. Somewhere in the 1950's
he found a discussion about a new negro library building [they had separate
libraries then], and they were arguing about which Alabama politician to name
it after. They were deadlocked. Finally after a lot of heated discussion
someone suggested, "Hell, if we can't manage any better than this maybe we
ought to just let the Negroes name it themselves!". Like that.)
Probably the best way to convince management that Forth is easy to learn,
would come if engineers picked it up quickly on the job, without management
particularly noticing. Get one engineer who quickly shows others how to
use his specialized testing tools. Then they get sucked in a little bit at
a time. I think it used to work like that some. One lesson from it -- code
should get labeled as One Time Use or Library code. One Time Use code gets
written and tested quickly, it fits an immediate need, and it should be thrown
away as soon as you've forgotten how it works. Library code is written to
be useful later too. Since Forth users are more productive generally, they
can write mountains of unmaintainable code quicker than others can, when
they try to re-use One-Time-Use code.
But people mostly don't teach Forth on-the-job now. Why is that? Is it that
no one wants to learn? Here's a possibility: Lester Thurow claimed (in
_Dangerous Currents: The State of Economics_ 1983) that in most productive
industries, most of the training that people actually use for their jobs is
OTJ training. They can't go to school to find out how to do their jobs, the
schoolteachers don't know. But to make OTJ training work, the workers who do
the teaching have to feel secure. "Get Joe to show Larry how to do his job,
then we'll fire Joe and get Larry to do it cheaper." If they don't have job
security they won't make the effort to teach others. The seniority system
provided this. If Joe teaches Larry, and later someone has to get laid off,
it will be Larry and not Joe. Otherwise Joe will make sure Larry can't
replace him. The shining example of the other way was the construction
industry. People are expected to have particular skills when they get the
job, there is little or no OTJ training, and the resistance to technical
change is legendary.
Maybe we've hit that. It isn't unusual to see ads, "Rose-Mellon developer
needed, 5+ years experience" "Oracle Financials, 3+ years experience" when
Rose-Mellon itself is only 3 years old and Oracle financials aren't out of
alpha testing. If there is no security and people are rated on their own
individual productivity, why would anybody help anybody else learn Forth?
If answering questions takes 15 minutes out of your schedule, what do you
get for it? And why learn it? It doesn't fit you into one of the slots that
the HR people try to fill.
So why doesn't it matter that the experienced people might try to build in
job security? Because they can't. Next time around the thing will get
mostly rewritten, and if some programmer wrote in something tricky that
nobody but him could handle, it will make delays but probably mostly nobody
will even remember who did it or have any idea they could get him back to
fix it. If you want an extension on your house, you might need 3 carpenters
or 5 carpenters, but you don't worry that the last carpenters did anything
that the new ones will have any trouble understanding or adding onto.
Carpenters are interchangeable. If one carpenter does something that a
standard carpenter wouldn't do, practically any other carpenter can look at
it and say it's bad. A good carpenter does the same job faster.
I don't know where to go from here.
John Passaniti
Bernd Paysan wrote in message
<352C92...@remove.muenchen.this.org.junk>...
>> Thus if you want to or have to earn your money with programming, don't
>> use Forth - take C or whatever fits best to the team goal.
>
>Do you really think these meeting going morons that are barely capable
>of writing C contribute something to the product (other than bugs and
>bad design decisions)?
Actually yes, they contribute greatly. At least that is my experience.
I work for a company that makes digital and analog signal processors for the
music industry. Not to toot my own horn too loudly, but of all the people
at work, I have the most programming experience on the widest range of
platforms. I guess they recognize that, since I have the title of "Senior
Software Engineer." Wooo-- titles.
In my early days where I work, I was so full of myself. Ignoring completely
that once the software was done, people (mostly musicians) would have to use
my software, I thought all of my solutions to problems were fantastic, and
when anyone disagreed with me or my methods, well... they were just morons.
After all, I was a Forth programmer and they were all 'C' programmers, and
we all know that Forth programmers are by definition better people...
That changed when I started to actually talk to the end-users of my
software. They had complaints, and when I thought about their complaints, I
remembered back to the boring meetings we had where people who I thought
were morons brought up the very same concerns. Funny, these paper-pushers
and bean-counters couldn't write code to save their lives, but they knew
what customers wanted, and they knew what would sell. In short, while my
software was oh-so-elegant and oh-so-correct, it didn't meet all the needs
of customers.
I don't know what industry you're in, but there are more to products than
just code. If you feel others merely add bad code and bad design decisions,
then learn how (as I did) to filter out their bad advice. But don't filter
out *everything* or else you'll be eating humble pie.
Bernd Paysan
Andreas Kochenburger wrote:
> How comes that most (afaik even commercial) Forth systems are or were
> the babies of one or max. 2 individuals as fathers?
Because it does not need more work than of at most 2 or so individuals
to write a good Forth system.
When something grows large, than it can't be the system itself - it must
be applications. Elizabeth has some success stories, and at least the
Riad Airport project is a thing that is large enough to qualify
anything. And nobody says "Riad Airport" like they say "Denver Airport"
(I'm in Miami and my luggage is in Alaska ;-).
BTW: I have to add a comment on your requirements that a larger project
needs a full-time "suit" that does nothing but coordination efforts:
nope. There are several examples, Linux is by far the best one. The man
who leads Linux doesn't wear suits and still spends a lot of time
working on programming work (this includes integrating other's efforts).
I guess that he does more programming on Linux than an average engineer
at the average Dilbertian company does on his project (programming is
the time between lunch and meetings ;-).
Bernd Paysan
John Passaniti wrote:
>
> Bernd Paysan wrote in message
> <352C92...@remove.muenchen.this.org.junk>...
> >> Thus if you want to or have to earn your money with programming, don't
> >> use Forth - take C or whatever fits best to the team goal.
> >
> >Do you really think these meeting going morons that are barely capable
> >of writing C contribute something to the product (other than bugs and
> >bad design decisions)?
>
> Actually yes, they contribute greatly. At least that is my experience.
>
> I don't know what industry you're in, but there are more to products than
> just code. If you feel others merely add bad code and bad design decisions,
> then learn how (as I did) to filter out their bad advice. But don't filter
> out *everything* or else you'll be eating humble pie.
I'm in the semiconductor manufacturing industry. We have marketing
(which does lots of promises to the customer), product definition (which
does lots of bad design based on the promises), and product developers,
that are those who have to actually implement and test the ill-designed
products. Whatever, at least the morons at the begin of the pipe don't
actually code things.
To make a good product, you must know two things: what the customer
needs and how (s)he's able to use it. If someone wants a text processor,
we clever people might say "use vi to type in LaTeX sources", but that's
not what they can use. But the solution to use LaTeX to do formating is
still right, it's just that vi as front-end is wrong or needs too much
teaching to be found worthful.
What people usually forget is that you always must layer your code. Your
code might have been elegant and correct, but you stopped at the layer
that was right for you, and counter-intuitive for the end-user.
But my point is that these people don't contribute to the coding effort.
They may contribute to the product to make it useable. Remind that
behind a user friendly interface, there is a terrific human concept (the
concept of the monkey at the keyboard - you need some of those monkeys
to try if you really thought of everything). This, however, doesn't
restrict the language of choise.
Howard Shapiro
Ken Deboy writes:
> I will agree that Forth seems to have more 'smart' people 'per capita'
>than C, but it's really a shame that some of them don't want to use
>their energy to write a good book(documentation WITH EXAMPLES) of an
>existing and AFFORDABLE (hint: Win32Forth, iForth, GForth, etc) in-
>stead of calling people who like other languages stupid or reinventing
>yet another Forth.
>
And, while Stephen Pelc points out that ProForth is expensive because it
comes with 1000+ pages of documentation, that documentation isn't the
kind of book for which Ken is asking and for which I have begged several
times on this newsgroup, i.e., a solid tutorial with examples.
I've been programming in Forth for the 80x86 platform for over 15 years,
and I know enough about Windows programming to have stumbled through a
few programs in C/C++ and, more recently, in Delphi (which I wish had
the Forthlike facility someone else recently asked and was willing to
pay for). I haven't progressed very far with either Win32Forth or
ProForth for Windows. I'm sorry Ray Duncan abandoned the idea of doing
a 32-bit WinForth, because the documentation he produced for his 16-bit
version was excellent and made the system easier to learn than any of
the 32-bit Windows Forths I've seen. I suppose if I could devote six
straight months of my time to learning one of the 32-bit Forths, I'd be
able to write the book, but I haven't got the six months. And a student
of mine went from a standing start to writing Delphi code to do what my
DOS Forth code does, with a Windows interface, in four months, which
begins to make me unsure I want to learn a Windows Forth.
-Howard Shapiro
h...@shapirolab.com
Marcel Hendrix
Bernd Paysan <bernd....@remove.muenchen.this.org.junk> writes Re: FORTH vs C
> Andreas Kochenburger wrote:
>> How comes that most (afaik even commercial) Forth systems are or were
>> the babies of one or max. 2 individuals as fathers?
> Because it does not need more work than of at most 2 or so individuals
> to write a good Forth system.
Let me ask a counter question:
"What will happen when you put Bernd Paysan, Marcel Hendrix and Wil Baden
together in a team to write VisualF++?"
You can take any combination of three or more other contributors to this
newsgroup, if that makes the answer easier. I can think of some hilarious
combinations :-)
You might counter that the contributors to clf are a special case, but all
Forthers I've met (so far) have their alter egos in this group...
-marcel
Marcel Hendrix
hms...@shore.net (Howard Shapiro) writes Re: FORTH vs C
> Ken Deboy writes:
>> I will agree that Forth seems to have more 'smart' people 'per capita'
>>than C, but it's really a shame that some of them don't want to use
>>their energy to write a good book(documentation WITH EXAMPLES) of an
>>existing and AFFORDABLE (hint: Win32Forth, iForth, GForth, etc) in-
>>stead of calling people who like other languages stupid or reinventing
>>yet another Forth.
First of all, the evidence is against Forth. The Forth community can't
point to something like Linux, GNU and the myriad of pd C programs to
show they're so smart (well, they're smart in not rewriting what's already
there, and using their smartness to make money with unheard-of embedded
applications...).
> And, while Stephen Pelc points out that ProForth is expensive because it
> comes with 1000+ pages of documentation, that documentation isn't the
> kind of book for which Ken is asking and for which I have begged several
> times on this newsgroup, i.e., a solid tutorial with examples.
Let me guess what is on these 1000+ pages. A call-by-call documentation
of every little WIN32 lib function converted to reverse polish :-)
Charles Petzold's "Programming Windows 95" is 1099 pages. When you've
finished that book, _and_ have access to the SDK documentation (several
1000 pages?), you might stand a chance in writing a non-trivial Windows
application.
> I've been programming in Forth for the 80x86 platform for over 15 years,
> and I know enough about Windows programming to have stumbled through a
> few programs in C/C++ and, more recently, in Delphi (which I wish had
> the Forthlike facility someone else recently asked and was willing to
> pay for). I haven't progressed very far with either Win32Forth or
> ProForth for Windows. I'm sorry Ray Duncan abandoned the idea of doing
> a 32-bit WinForth, because the documentation he produced for his 16-bit
> version was excellent and made the system easier to learn than any of
> the 32-bit Windows Forths I've seen. I suppose if I could devote six
I have Winforth and don't quite understand your comment. Winforth is 16 bit
which makes its interface to Windows subtly difficult. In general it just
names every low-level Windows call the same as in the SDK with RPN
parameters. For the rest it does not offer any additional abstraction (not
necessarily bad). I succeeded in porting about 30 Winforth examples to
the new NT iForth by adding about 20 WIN32 calls to its C-server. The main
differences are that iForth's command line is a thread and thus _always_
active, and that the iForth graphics are also interactive (not necessarily
WM_PAINT handlers).
Win32forth has a very high level of abstraction in its GUI, but because it
has no documentation at all, it's faster to just reinvent everything
yourself (I'm not being fair, I know).
> straight months of my time to learning one of the 32-bit Forths, I'd be
> able to write the book, but I haven't got the six months. And a student
> of mine went from a standing start to writing Delphi code to do what my
> DOS Forth code does, with a Windows interface, in four months, which
> begins to make me unsure I want to learn a Windows Forth.
But surely, given four months for just writing the GUI, any Windowsforth
would have done as well?
-marcel
Elizabeth D. Rather
Brian Fox wrote:
> Without telling to much "out of school" would it be possible to
> briefly
> describe the features
> of this database that make it so unique and hard for others to copy?
The central feature is a two-dimensional relationship between major
components, call them datasets A and B. Members of A get input from
certain members of B, and each individual member of B contributes to
certain members of A. There are about 30,000 members of one dataset,
and over 100,000 members of the other. Inquiries need to compute values
of a selected member of A, by summing the contributions from its B
components and for each B component considering what A's it is
contributing to. There's a lot more to it than that, but this is the
essence.
Now, I am unfamiliar with any of the commercial relational databases,
but I am told that the experts who have looked at this find that it's
possible to use them in this way for small databases, or large ones
given no performance or size constraints, but for a full-size database
the resources required by commercial databases to deliver acceptable
performance are out of sight. Our customer does it in a regular PC.
Stephen Pelc
> How comes that most (afaik even commercial) Forth systems are or were
> the babies of one or max. 2 individuals as fathers?
projects. What is required is coherency in the architecture. Once the
system is coherent, the number of programmers involved is of minor
importance.
This issue is discussed in the context of a very large software
system in the "The Mythical Man Month".
lis...@zetnet.co.uk
On 1998-04-09 glockr@locked_and_loaded.reno.nv.us said:
:> With F-PC and a Pentium 90 I can do 90 Million NOOPs a second in
:> FORTH. Very fine control indeed.
:> Simon
:What does 90 million noops get you? NOTHING ;) I think Forth's big-
:gest problem is that it costs WAY too much to get a decent
:commercial system. OTOH, 'commercial-grade' C compilers can be had
:for less than $200 or so (much less if willing to accept last years
:'best').
hmm. define "commercial-grade". anything by microsoft? *snigger* doubt
it, unless you think visual basic is also commerical grade. borland?
$550 for a full development kit, which is looking competitive with the
cheaper of the commerical forths. same with others.
on the other hand, is there a free c which offers the same coherence and
integration as any free forth, let alone as comprehensive a product as
f-pc?
:Also, I think that Forth is the best at certain things,
:and I think C is a bad choice for some things. However that doesn't
:mean that Forth is the best for everything, and it also doesn't
:mean that C is poor at everything. For some things, just _maybe_ C
:is a better choice...
we suspect that c is the better choice for writing programs in c, and
that's about it. ;> there are environments which discourage anything
other than writing in c.
:Other problems I see with Forth are lack of a
:Standard (hopefully ANS Forth will cure this, but somehow I doubt
:it), and lack of good books. For example, a lot of what I want to
:do with a computer has to do with text processing, disk files, etc..
:. How do you do it in Forth? It depends on what Forth:) Hard core
well, since most forths are adapting themselves round to ANS
compatibility, you'll probably have your answer by consulting the
apropriate documents. some of us think it should be done a different
way, so we write our own forths. if we were using c, what would we do?
probably write our own operating systems. we use forth because
individualism is less work there. ;>
--
Communa (together) we remember... we'll see you falling
you know soft spoken changes nothing to sing within her...
Ken Deboy
lis...@zetnet.co.uk wrote:
-- snip --
> hmm. define "commercial-grade". anything by microsoft? *snigger* doubt
> it, unless you think visual basic is also commerical grade. borland?
> $550 for a full development kit, which is looking competitive with the
Something with good printed documenation. The best system in the world
is useless without it unless you already know it. If you look, you can
get Delphi or Borland C for about $300, or only $100 if you don't need
printed docs. Of course the client-server version is a lot more, I guess
about the same as a good commercial Forth. But if I don't need the ex-
tras, why would I want to pay for something I don't need? Maybe what
Forth needs is for one of the commercial suppliers to adapt a teired
feature/pricing structure. Either that or maybe FIG or someone could
publish a good set of documentation for GForth (or some other Forth
that runs on Linux). I know I'd buy it. $1700 or so for ProForth is
fine for a corporation, but it's a little (a lot) steep for someone
who wants to learn Forth and also wants some good printed docs to
help with the learning.
> on the other hand, is there a free c which offers the same coherence
> and integration as any free forth, let alone as comprehensive a pro-
> duct as f-pc?
Hmm... gcc and rhide or xwpe? Freely available, source code available,
binaries produced can be very small (at least on Unix), etc. I do like
F-PC, but I didn't until I got the User's Manual. I just wish there was
an affordable (for individuals, not companies) Forth that ran on a good
windowing OS (like Linux or FreeBSD with X), with good PRINTED document-
ation available.
Ken
Howard Shapiro
In article <6gslu1$mvp$4...@news.IAEhv.nl>, m...@iaehv.iaehv.nl says...
>
>I have Winforth and don't quite understand your comment. Winforth is 16 bit
>which makes its interface to Windows subtly difficult. In general it just
>names every low-level Windows call the same as in the SDK with RPN
>parameters. For the rest it does not offer any additional abstraction (not
>necessarily bad). I succeeded in porting about 30 Winforth examples to
>the new NT iForth by adding about 20 WIN32 calls to its C-server. The main
>differences are that iForth's command line is a thread and thus _always_
>active, and that the iForth graphics are also interactive (not necessarily
>WM_PAINT handlers).
Well, I was trying to use WinForth before Win95 came along, which made the
interface less difficult...and, while it didn't offer any abstraction, it
did come with enough documentation to get the user programming.
>
>Win32forth has a very high level of abstraction in its GUI, but because it
>has no documentation at all, it's faster to just reinvent everything
>yourself (I'm not being fair, I know).
I think the lack of documentation was what prompted me and, later, Ken, to
express a yearning for a tutorial book with examples.
>> And a student
>> of mine went from a standing start to writing Delphi code to do what my
>> DOS Forth code does, with a Windows interface, in four months, which
>> begins to make me unsure I want to learn a Windows Forth.
>
>But surely, given four months for just writing the GUI, any Windowsforth
>would have done as well?
>
Very likely, if either of us had been able to learn it well enough to start
writing. Although it seems to me that the visual development environment
you get with Delphi does more for you than what is available for Windows
Forths.
-Howard
Andreas Kochenburger
I never said "impossible" but meant advisable, to come back to the
topic of this thread.
You can do excellent software engineering more or less regardless of
the programming language - and you need excellent tools for big
projects for documentation, debugging, versioning. (Do you use a
commercial CASE system or something of your own make?)
But where no CASE can help is: when you are in need of human resources
with a certain experience in order to have them productive as fast as
possible. I guess that your company can still be called "small" so
that you can act very flexibly. We and our biggest competitors can be
called "big", and before we can hire from outside we have to take
people from other departments due to law and unionist regulations. By
far most of them have C experience (which did not make them dull or
unwilling btw ;-)) but we cannot invest in Forth courses for each new
member.
And as long as UNIX- and NT-makers use C/C++ our customers will accept
when we use C/C++ too. I could imagine our dear competitors starting a
big howling about all those negative Forth aspects, should we announce
to develop in Forth. Be those aspects irrational or not - they would
sow doubts in our market, and this we cannot risk.
On Thu, 09 Apr 1998 11:50:00 -0700, "Elizabeth D. Rather"
<era...@forth.com> wrote:
>I urge you to be careful about saying in public something is
>"impossible"
>with Forth just because you personally have never done it.
---------------------------------------------------
Jonah Thomas
In article <353314a9.3132241@news>,
koch...@no.spam.de (Andreas Kochenburger) wrote:
>You can do excellent software engineering more or less regardless of
>the programming language - and you need excellent tools for big
>projects for documentation, debugging, versioning. (Do you use a
>commercial CASE system or something of your own make?)
Previous discussions have shown Forth teams going either way for
versioning, with excellent results. For debugging, Forth can easily
provide tools to build good test suites, when people bother. For
documentation, Forth lets you do whatever you want. There's the
"problem" that it's much faster to program in Forth but not that much
faster to document function. An extensively-documented Forth product
would have a much higher documentation:code ratio than anyone is used
to. I think documentation in general is an unsolved problem. It isn't
really clear which sorts of documentation are necessary, or how it
should be organized. A team that had a consensus about that could
easily create Forth tools to help, or could use commercial tools if
they happened to do the job.
>But where no CASE can help is: when you are in need of human resources
>with a certain experience in order to have them productive as fast as
>possible.
Yes. If you suddenly need new people and need them to be productive
very quickly, you have a problem.
>We and our biggest competitors can be
>called "big", and before we can hire from outside we have to take
>people from other departments due to law and unionist regulations. By
>far most of them have C experience (which did not make them dull or
>unwilling btw ;-)) but we cannot invest in Forth courses for each new
>member.
Right. C is a sunk cost. If the people who wrote COBOL compilers had
learned to optimise the right things, this argument might have been used
for that, years ago. "Look, we need new people and we need them
productive quickly. If we do the project in COBOL there are a lot of
COBOL programmers out there who already know the language." But they
missed the chance, and now it's too late.
>And as long as UNIX- and NT-makers use C/C++ our customers will accept
>when we use C/C++ too. I could imagine our dear competitors starting a
>big howling about all those negative Forth aspects, should we announce
>to develop in Forth. Be those aspects irrational or not - they would
>sow doubts in our market, and this we cannot risk.
Right. Customers have a stake in your products and updates being ready
on time, and you can't do anything that would raise doubts. If to them
you look exactly like your competitors, then it's a horse race and they
choose by gambling instinct and track record alone. If you look
different then you might be making a mistake and they're making a mistake
to depend on you. Their fears are important. Imagine you're getting
ready for major surgery, and your surgeon explains, "I get dramatically
better results than most surgeons because I use special techniques that
the medical profession generally doesn't accept yet. Don't bother about
getting a second opinion on my methods, practically nobody understands
them and they mostly say the things I do regularly are impossible." Or
an economic forecaster. "our team gets consistently better results than
the industry average because we base our forecasts on astrology." Even
if they have outperformed the industry, you've got to wonder.
These are things that will tend to slow innovation in the field. To the
extent that software has become a matter of large projects that can't be
allowed to fail, it's become a mature industry with accepted methods.
Deviations are unacceptable even when they work. Forth is a deviation.
If Forth is to be used commercially, then, it has to find ways to fit in.
One approach is to stay in niches where these criteria are unimportant.
Embedded systems used to be a niche like that. But as embedded systems
get larger and more expensive to design, that niche will shrink. When
you need a lot of people in a hurry, you'll need C programmers with
embedded experience. When you can't find them, you'll at least be able
to find lots of C programmers. And customers will insist that designs
be in embedded C because they want to be reassured that their large
project will be completed correctly and on time, and everybody else is
doing it in embedded C.
Another approach is to build commercial products and not admit what
language the product was designed in. This has several problems. First,
it needs to be a product with a lot of little users instead of a few
big ones, otherwise you'll be hostage to the big users' fears. Second,
you'll need someone to sell the product. Unless you already have a solid
track record, they'll want to be assured that you'll produce your product
on schedule for them to sell. They need to start advertising long before
it's ready. If you have to show them a completed product before they'll
deal, much of the lifespan of your product is lost. The same problem
again, C++ isn't enough to give you credibility but Forth is enough to
lose it. (You could sell shareware this way, though, so you wouldn't
need to persuade someone else to market it.) Third, if at some point
you want to sell out, if your marketable products are written in Forth
then the customers for your company will be dubious. They won't be sure
they can maintain and upgrade your Forth systems, so they'll be buying
the right to retire your product (which can matter if they're selling an
inferior version) or to rewrite it in C and put it out under the same
name. Etc.
A third approach is to fit into component models. Given a good
interface between components, people can design large projects out of
small projects. It doesn't matter how the small projects were built
provided they work well for their avowed functions. Some of them could
be in Forth. This is wasteful. You could have a single project that
includes a couple of Win32Forth systems, a couple of F-PC systems, a
couple of Pygmy systems, a lot of C routines etc, all cobbled together
with some standard interface. But it could be quicker to cobble together
than a complete redesign. If the current approach of treating the
software industry like the construction industry (hire a contractor who
hires a lot of interchangeable ironworkers, pay them union scale, build
it just like the last one except to a different set of blueprints) gets
replaced with something more modular, Forth might have a place in some
of the modules. But not if it's a Java modular system. You can write
Forth in Java, but you get the constraints of Forth-in-Java on top of
the constraints of Java. Each module that's supposed to be portable by
itself becomes bigger because it has to include a Forth system. To make
that effective you have to make big modules that do a lot of things --
the opposite of the Forth approach. And if you do need to show code to
anyone, they'll tend to disapprove -- many of the things that Java claims
as advantages, strict typing, security, etc, are missing internal to Forth
modules. It's a disadvantage when people assume your code is buggy until
they find out otherwise. CORBA might work as it gets more generally
accepted. I don't know about other modular systems.
A fourth approach is to invent a new niche. If it's something nobody's
ever heard of before, and the standard stuff is all done in Forth, it
might take years before anybody reverse-engineers it in C++ so they can
meet people's expectations. In the meantime you'll have the field to
yourself.
I'd like to hear about a fifth approach.
Anton Ertl
In article <6gofuc$r...@sjx-ixn11.ix.netcom.com>, Jonah Thomas <jeth...@ix.netcom.com@ix.netcom.com> writes:
> It's predictable that the learning cost for a new language will be higher
> than for a new version of a known language.
> But would those experts actually recommend this? Introducing new tools in
> mid-project would usually delay things. Even worse, if you let the engineers
> themselves choose the tools and then learn to use them, both parts of it use
> time that they could be working.
I was at the ETAPS conference two weeks ago. Lots of academia types
like me, but the most impressive talk was held by a practitioner, Kent
Beck.
He told the story where he was called in as consultant to increase the
performance of a payroll system under construction by 50 Cobol
programmers or so for 18 months. The system was apparently a mess, and
he recommended scrapping it, which they did; and they made him leader
of the project to replace it.
He mainly talked about methodology (applicable things like
"programming in pairs", not abstract stuff as I have seen in CACM some
years ago). He mentioned the following only in passing (and some only
when I asked him), but I found it very interesting:
He did the project with a self-selected group of 10 of these Cobol
programmers, taught them Smalltalk (he said they became fabulous
Smalltalk programmers), and they did the system in about one year
(until the first payroll processed); this was three months over
schedule, but IMO still impressive.
Apparently he found it worthwhile to teach them a new programming
language, and thought that this investment would amortize fast enough.
It's probably a good idea to spend a part of the time to check out and
learn new tools. It pays off quickly. On several occasions I found it
useful to create a tool for just one job (e.g., Gforth's prims2x.fs
tool).
- anton
--
M. Anton Ertl Some things have to be seen to be believed
an...@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
Bob Armstrong
Elizabeth D. Rather wrote:
> Brian Fox wrote:
> > Without telling to much "out of school" would it be possible to
> > briefly describe the features
> > of this database that make it so unique and hard for others to copy?
>
> The central feature is a two-dimensional relationship between major
> components, call them datasets A and B. Members of A get input from
> certain members of B, and each individual member of B contributes to
> certain members of A. There are about 30,000 members of one dataset,
> and over 100,000 members of the other. Inquiries need to compute values
> of a selected member of A, by summing the contributions from its B
> components and for each B component considering what A's it is
> contributing to. There's a lot more to it than that, but this is the
> essence.
problem .
In APL , J , or Arthur Whitney`s K , such an algorithm could almost certainly
be expressed in a few short sentences .
The size of your sets is moderate . In K , at least , sets of over a 100,000,000
items ( components ) are now dealt with on ( fat ) laptops .
That`s why these vocabularies are worth understanding .
My problem with these current APL`s is that they are written in C .
I`m hoping to have created enough vocabulary in Win32Forth `s dynamic objects by
the APL98 Conference in Rome in July .
-- BobA -- http://CoSy.com
Elizabeth D. Rather
Bob Armstrong wrote:
Alas, you have clearly been misled by my summarization, which
necessarily left out a lot of detail. Of course, in Forth (as well as
many other languages) given the appropriate infrastructure it can be
done in a single line. The issue is what does that infrastructure
consist of, and how long will it take to execute?
> The size of your sets is moderate . In K , at least , sets of over a
> 100,000,000
> items ( components ) are now dealt with on ( fat ) laptops .
Surely this depends upon how big an "item" is?
RHS Linux User
On Tue, 14 Apr 1998 13:49:13 GMT, Jonah Thomas
<jeth...@ix.netcom.com@ix.netcom.com> wrote:
>In article <353314a9.3132241@news>,
> koch...@no.spam.de (Andreas Kochenburger) wrote:
>
>>You can do excellent software engineering more or less regardless of
>>the programming language - and you need excellent tools for big
>>projects for documentation, debugging, versioning. (Do you use a
>>commercial CASE system or something of your own make?)
>
>Previous discussions have shown Forth teams going either way for
>versioning, with excellent results. For debugging, Forth can easily
>provide tools to build good test suites, when people bother. For
>documentation, Forth lets you do whatever you want. There's the
>"problem" that it's much faster to program in Forth but not that much
>faster to document function. An extensively-documented Forth product
>would have a much higher documentation:code ratio than anyone is used
>to. I think documentation in general is an unsolved problem. It isn't
>really clear which sorts of documentation are necessary, or how it
>should be organized. A team that had a consensus about that could
>easily create Forth tools to help, or could use commercial tools if
>they happened to do the job.
Hi Jet.
I would add that documentation is something that inately lends itself
to third-party involvement, since coders tend to lose sight of what
they used to not know. Documentation is an interest of mine. I like
to draw pictures of stack machines. Forth has a lot in common with
Linux, and I think documentation will be the key to Linux' long-term
future.
Rick Hohensee
http://cqi.com/~humbubba
Dave Kenny
<big snip>
: ... Of course, in Forth (as well as
: many other languages) given the appropriate infrastructure it can be
: done in a single line. The issue is what does that infrastructure
: consist of, and how long will it take to execute?
And how long will it take to _learn_? That too can be a significant
and sometimes prohibitive cost.
Jonah Thomas
In article <slrn6jnc26....@raptor.cqi.com>,
humb...@raptor.cqi.com (RHS Linux User) wrote:
>>There's the
>>"problem" that it's much faster to program in Forth but not that much
>>faster to document function. An extensively-documented Forth product
>>would have a much higher documentation:code ratio than anyone is used
>>to. I think documentation in general is an unsolved problem. It isn't
>>really clear which sorts of documentation are necessary, or how it
>>should be organized. A team that had a consensus about that could
>>easily create Forth tools to help, or could use commercial tools if
>>they happened to do the job.
>I would add that documentation is something that inately lends itself
>to third-party involvement, since coders tend to lose sight of what
>they used to not know.
That makes sense, and it goes farther -- unless you know your audience,
you can't be sure what they'll know and what they won't. At some level
you can expect to be able to say "state machine" or "FFT" or "borel set"
or "negative recombination interference causing linkage disequilibrium"
and expect people to just know what you mean. But when someone without
the right background tries to read that documentation they'll be lost.
I think one of the most useful things for Forth documentation is that
each word should have a comment that says _what_ it does. If you want
to figure out _how_ it works, you look at the documentation for its
various component words that say _what_ they do. But I could be wrong.
>Documentation is an interest of mine. I like
>to draw pictures of stack machines. Forth has a lot in common with
>Linux, and I think documentation will be the key to Linux' long-term
>future.
I don't know what to think about Linux yet. I can imagine that if you
wanted to build something like Linux and you started with something
like a database on a website, and you listed a collectoin of problems
to be solved, and every time people added code they put in links to
the problems they were thinking about when they did it ... and when
they revised the problems to be clearer and more modular, they kept
the old problems stacked hidden underneath the new ones and they looked
carefully at the code that handled the old problems....
I can imagine that something like that could be self-documenting. Not
the code, but the system as a whole. I'm not sure what it would take
to make it work.
Paul E. Bennett
In article <6hilqr$6...@sjx-ixn9.ix.netcom.com>
jeth...@ix.netcom.com@ix.netcom.com "Jonah Thomas" writes:
> I think one of the most useful things for Forth documentation is that
> each word should have a comment that says _what_ it does. If you want
> to figure out _how_ it works, you look at the documentation for its
> various component words that say _what_ they do. But I could be wrong.
Seeing we are discussing documentation of Forth sources again, a comment
per word defined is very useful, especially if it references how it treats
the data it peels from the stack. A trivial example from the ANS/ISO
document to show how this looks:-
: FILL (S c-addr\u\char - )
(G If u is greater than zero, store char in each of u consecutive
characters of memory beginning with c-addr.)
.......... ;
The (G is a commenting word which, when using a documentation tool which
searches through the code for these comments will enable a glossary to be
produced automatically from the source.
This comment in the source file is also useful for those who are testing
the software (if other than the author). So long as the comment is traceable
back to the original requirements spec you have a firm basis for software
certification. Of course, other documentation is still required in the
package.
> >Documentation is an interest of mine. I like
> >to draw pictures of stack machines. Forth has a lot in common with
> >Linux, and I think documentation will be the key to Linux' long-term
> >future.
>
> I don't know what to think about Linux yet. I can imagine that if you
> wanted to build something like Linux and you started with something
> like a database on a website, and you listed a collectoin of problems
> to be solved, and every time people added code they put in links to
> the problems they were thinking about when they did it ... and when
> they revised the problems to be clearer and more modular, they kept
> the old problems stacked hidden underneath the new ones and they looked
> carefully at the code that handled the old problems....
>
> I can imagine that something like that could be self-documenting. Not
> the code, but the system as a whole. I'm not sure what it would take
> to make it work.
As one who delves into the high integrity control systems arena, there is
a right way of generating the documentation required to generate confidence
in the final system. It might seem like a lot of paperwork but it is worth
it in such systems.
1) Take the customer requirements and arrange the analysis such that you
obtain an assessment of the physical, system and management tasks required
for the system in it's environment. Count the function points for cost and
time estimating purposes.
2) List hazards associated with each task, design risk management measures
and revisit step one as necessary.
3) Write an outline technical description of the system and it's interfaces,
modularising appropriately to comply with analysis of the requirements.
4) Write a user guide.
5) Review the written material of steps 1 to 4.
6) If 5 passed successfully write detailed technical description of the
system (including environmental specs) completing the identity of all
modules of the system.
7) Write a test plan that aims to confirm whether or not the system meets
it's requirements in terms of the issues raised in 1 to 4.
8) Refine Hazard Analysis based on 6 and 7.
9) Review stages 6 to 8 for compliance with 1 to 4.
From here it gets quite complex as the system design hierarchy begins to
take effect. Essentially repeat all steps until down at hardware or software
implementation level. Then test against the test plan prior to integrating
each module with others. Integrate and test all modules against test plan
until all modules are incorporated within the system then test whole system
against test plan.
Remember that:-
* all analysis should produce a report.
* all reviews should produce a report.
* all tests should produce a report.
On the basis of all the reports gathered and reviewed you should be able to
clearly define where a system does or does not comply with the original
requirements. If you have such a record in a form that is easily audited
then any claims you make about system safety should be usable with a good
degree of confidence.
If you take the view that even the tiniest code fragment is a component
for a larger more complex component and that each component, no matter how
complex, should be certified as being of a known quality, then the process
should never seem too arduous. Forth permits a very fine granularity of
software component and enables a finer degree of testing overall. In fact
you may do less work to acheive the same end as a team who do not code and
document so finely.
With the example of FILL from above, the code that implements it could be
tested to the plan (for that component) and a certificate of conformity
could be issued so that those who may rely on it's correct behaviour
(under the specified conditions) can feel confident when they make use
of it.
Now encroaching a bit on what I know is another thread, the only thing that
is really lacking in Forth at present is enough by way of the project
management tools that work harmoniously with Forth. Partly this is due to
the fact that most practitioners have so little spare time. Other reasons
may be that we have not yet thought through enough of what we want to
collectively achieve.
I know that there are several tools out there that will assist in project
management aspects but they are not really designed to seamlessly integrate
into a Forth development environment. However, the techniques used in those
tools are worthy of consideration for a tool (or tools) that will integrate
well.
Some of these things are weighty issues but for Forth to really have a future
they need to be addressed as a matter of urgency.
--
Paul E. Bennett ................... <p...@transcontech.co.uk>
Transport Control Technology Ltd. <http://www.tcontec.demon.co.uk/>
+44 (0)117-9499861 <enq...@transcontech.co.uk>
Going Forth Safely
Jason Myers
Grumble, Grumble - Grouch grouch grouch.
Fifth way - use an analogy that was written about in a SF book that had
inventor of a new device threatened with his life. Similar to
developing
an engine that gets 100 MPG - You would be bought out or dead.
The only solution is to 'Give it away'! and hope that their is NO
reprecusions
(like a bullet to the head).
The 'Evil Emporer from the North West' has a complete and total reign
over
the minds of the masses and when you look at a very few products
Linux
Wolfinstein
You can see that they knew it was hopeless to compete, so they gave it
away. Free stuff will ALWAYS get someone to look at it - the only
problem
is getting something that is so good as to entice them away from the
'Evil Emporer' - The ONLY solution that I could come up with is to
make a product that competes with his OS and include ALL of the
products that he 'steals' from the 'good' programmers that are out
there.
The problem isn't writting the better program, but more to the nature
of getting PAID for it.
Forth is a language to design languages, so why is it that 'we' have not
written extentions that compile and run other peoples code? Can you
imagine a c-forth that will read a C-file and execute the native forth.
And you could include modules (easily) that have been created in other
languages (fortran, tcl, perl) into the 'c-forth' program that you were
writting in what you think is 'C'.
If you had a front end for each of the languages and it cost nothing for
the people to use it, then it might fly. Especially if you have a
system
that could compile Linux. - No money on the front end, but the payoff
on the back end should be enormous - ie The demise of the 'Evil
emporer'.
Also consider, if you write in C, and you have a compiler that is good
or
better than anyone elses - People don't care 'Which' compiler you use
ONLY that you use a 'C' compiler. So why not one that is an extention
to 4th?
But then again - Most people are not altruistic... They want the money!
((or in my case, need the money to live - oh, what trouble I would cause
'IF' I ever hit the loto))
Sh.n.
Learning 101 states that you have to 'explode' or 'compress' the problem
untill the solution becomes obvious. And, that it isn't the answer that
is
important but the question, because with the right question anyone can
know the answer. So what is the correct question? That is the real
trick!