Multitasking Forth?
Rick Hohensee
interrupt pins are required for true preemptive multitasking. Charles
Moore, as of 1983, prefered a round-robin scheme. I am a musician with an
Amiga. I like true preemptive multitasking. JForth does a nice job of
being one or several tasks, but AmigaDos does the scheduling. I crave a
Forth AmigaDos+. I verbally sketched such an object in a recent post in
here that I will be happy to email to any interested party. If that's you,
email me. :o) This is not intended to conflict with Jax' glittering
remarks about JForth. In fact, my printer just finished emitting Mike
Haas' recent post to the JForth mailserver of his new createtask() words.
Now to the coffepot.
Rick Hohensee
hohe...@tmn.com and/or ri...@cap.gwu.edu
keywords (in no particluar order): Forth music guitar available DC Md
original cycluphonics Amiga1000 MdFIG VRASP TUNING coffee tobacco
Darin Johnson
> interrupt pins are required for true preemptive multitasking. Charles
> Moore, as of 1983, prefered a round-robin scheme. I am a musician with an
> Amiga. I like true preemptive multitasking.
Perhaps there's some confusion here. The Amiga uses round robin
scheduling. And the word "true" is misleading at best, but to
your credit at least you put "preemptive" instead of just saying
"true multitasking". While a Forth virtual machine does not have
interrupt pins, there is no reason it could not just about the
same type of multitasking by polling.
Here's what happens on the Amiga, and most other machines.
When an interrupt arrives, it pauses execution of the current
process (either in the middle of an instruction, or after the
current instruction is done, I don't have my reference), and
runs an interrupt routine. When that routine is over, it continues
where it left off. With time slicing, a clock interrupt routine
may cause a context switch to a new process which will execute when
the interrupt routine finishes (instead of going back to the old
routine). Which process gets to execute next when this happens
is determined by the scheduling algorithm, round robin in this case.
What the interrupt pins help with (other than normal interrupt
handling) is to efficiently detect when a process has used up it's
time slice. With a real chiseled-in-silicon machine, this is
probably the only practical way to get preemptive multitasking.
In a virtual machine however, you can just test stuff after each
instruction (with a variety of help depending upon the real
machine underneath).
Of course, if you're doing pure direct threaded execution (where you
just keep adjusting the IP and doing JSR's), it's a major pain to do
it every instruction, but for context switches, you may not need to
detect it right away (device interrupts are another matter). If the
hardware supported interrupts, you could do context switches
efficiently in a threaded implementation by pushing an address on the
return stack that will get taken on the next return.
Hope this helps clear up any confusion. And correct me if I've
misunderstood what you were saying.
--
Darin Johnson
djoh...@ucsd.edu
"You used to be big."
"I am big. It's the pictures that got small."
Jack Woehr
>I crave a
>Forth AmigaDos+. I verbally sketched such an object in a recent post in
>here that I will be happy to email to any interested party.
Appelman (A4TH) and I mooted such a project which we called
ERP (Exec Replacement Project) back in 1988 but it came to
nought. This is a problem the Forth community has had to face again
and again: there ain't no percentages in reinventing the wheel.
Would that computer history had been different, but it wasn't.
Forth remains the language of the pioneers who live on the fringe. As
civilization catches up with them ... they move further out on the
cutting edge.
If this makes you uncomfortable, join the hordes of the
mediocre and program in C.
=jax=
--
#j...@cygnus.com # I'm not allowed by federal election
#j...@well.sf.ca.us # law to tell you that I'm running for
#72203...@compuserve.com # Congress in Colorado's 6th District.
#SYSOP RCFB (303) 278-0364 # Email jwo...@well.sf.ca.us
Glauber Ribeiro
Jack Woehr <j...@Cygnus.COM> wrote:
[...]
& Would that computer history had been different, but it wasn't.
& Forth remains the language of the pioneers who live on the fringe. As
& civilization catches up with them ... they move further out on the
& cutting edge.
&
& If this makes you uncomfortable, join the hordes of the
& mediocre and program in C.
Sure. Join the hordes of the mediocre who wrote most of the
programs you use and the operating systems they run on...
Glauber
--
glauber ribeiro
gla...@david.wheaton.edu
-------------------------
Klatu... varada... nykto!
Rick Hohensee
I read c.l.f in the msu gopher, so I have to do some shuffling to
quote a message verbatim, which I goofed up this time, so please forgive
the paraphrasing.
You assert that polling can serve in lieu of actual hardware interrupt
servicing. I specifically recall the phrase "just about'. Well, the core
scheduler of a system is no place for polling techniques, and would be
quite unForthlike at best. An OS should be able to respond to hardware
interrupts as easily as it could be made to perform polling, which in fact
would require interrupts to perform the polling, so we're left with tasks
doing the polling. This is so-called cooperative multitasking, which is
distinctly not what goes on on the Amiga, any Amiga. A task on the Amiga
doesn't _need_ to know about any other task, and unless you abuse the
priority scheme, no task will hog the machine. In fact, given certain
environment features, a task on the Amiga doen't need to know much about
AmigaDos, which Woehr/Appelman probably took advantage of with ERP.
You also assert that AmigaDos uses a round robin scheme. Not true enough.
The round robin scheme is merely the final tiebreaker among tasks
negotiating for cpu. Metascopic to the round-robin scheme is the
waiting/ready messaging system Amigados derives from its parent, Tripos.
Metascopic to that is the 256 level priority scheme. Metascopic to that
are the Amiga's 16 virual interrupt priorities which are derived from the
8 interrupt levels of the 680x0. I may have that garbled somewhat, but all
the levels I mention exist, and are dealt with by the Amigados Exec.
That would be a lot of polling. Entropy is self propagating. Forth is
minimum-entropy programming. I'd like to see that extended to a
sophisticated polymorphic task manager. A Forth that exists as a task
within a system like that offers no refuge from the confusion that
explodes when these problems are addressed. These problems are the warp
and woof of music.
Since the reader can easily ignore it, I'll append my Forthbox sketch
below my sig. If you do read on, note that FMOD has features that could
allow task switches approaching zero latency.
Rick Hohensee
hohe...@tmn.com and/or ri...@cap.gwu.edu
keywords (in no particluar order): Forth music guitar available DC Md
original cycluphonics Amiga1000 MdFIG VRASP TUNING coffee tobacco
No flames last time, and the coveted Elwood Blues Design Award, so
here's a reiteration.
This is a fantasy spec for a computer system and organization I wish
existed. Please don't take it too seriously, particularly the bit
about the power supply. I think it's mostly feasible, though. Please
mentally insert an IMHO about every third word.
If something specific looks out-and-out impossible ( besides the whole
thing ) I'd like to know.
The Accessible Computer
Design goals
low-cost minimum configuration
versatility
easy to program
incrementally and extremely upgradeable/extendable
well and widely documented
astounding audio
tcomm capable out of the box
generally Forth-like
numerous outside-world connectors
Company Organization
" Forth solves the software problem."
Charles Moore Rochester 1983
For controlling "robots", yes. Nothing else comes close. This is
due to Forth's continually delightful coherence, and the fact that
no part of the Forth system is inaccessible to change. Forth has
not solved the operating system problem, nor has it solved the
'business model' problem that currently plagues the computer
industry. The innate elegance of Forth can be extended to these
problems, though, and this is my fantasy. Next is an attempt to
imagine a Forth-like business entity.
An extensible partnership of individuals, specifically _not_ a
corporation, may be helpful in creating a business microcosm where
a Forth-based system could thrive. Forth clashes with prevailing
market paradigms based on counter-productive, and therefor
expensive, distinctions like hardware vendor/software vendor,
user/programmer, system/documentation, execute/compile and so on.
A partnership is better able to preserve it's independance than an
entity that is subject to being purchased. The complexities of a
modern corporation are analagous to the complexities of a typical
compiler, ie self propagating and hard to predict. One of the main
reasons usually given for forming a corporation is to avoid
personnal liability. It doesn't work, and is not morally
supportable. The end result is meaningless red tape, entropy.
Said partnership should involve persons responsible for all parts
of the system; hardware, software, docs, peripherals. These are
not intended to imply separate functions. They aren't. That's the
current problem. Even the most elegant current Forths, when sold
as software, suffer from this prevailing business model. Words
like `Turnkey' etc. have no inherent usefulness. They are
necessary for business reasons only under the current paradigm.
Management units should be based on hardware system boundaries,
where definable. The 'sales' function should be considered a
side-effect of documentation, which must be considered an integral
part of any system, and is the logical task of entry-level
personnel. Net support too. 'Marketing' decisions are to be made
by persons who design the system(s). The creative create
'markets'. Others 'compete for market share'. In other words,
'marketing' is product driven.
A certain percentage of revenue should be strictly set aside for
awards for private software authors who put out sourcecode.
Partnership should pro-actively maintain a significant
net.presence.com .
Enclosure
A modular enclosure with a cpu module with dimensions similar to a
single volume of an encyclopedia. Modules stackable. Extensible
via a large female card-edge connector on the cpu module, an
Accessbus port on the cpu module, or by adding modules. Each
module includes a power supply sufficient for that module when
fully configured.
There is an outfit that makes enclosures that fit the modularity
aspect of the above, Bud or Budd something or other.
Required Instruction Set
A selection of core words from the ANS Forth standard. If an
arbitrary cpu were required to implement an ANS Forth from a
CPU-specific 'pre-boot rom' on bootup, would this allow a wide
selection of CPU's? Consider that the remainder of the 'OS' could
be in Forth source.
Also required, a Bana vocabulary ( my personal hypothetical Forth
mutation, which you're welcome to leave out of your
fantasy :o)
Hardware Features of the Default ( minimum cost) CPU Module
reset and vectored reset buttons
Motorola 68020-based 32 bit by 32 bit fully static MPU.
( I heard such a device is due out about now.)
Low-cost modem ( 1200 or 2400) and modular plug
AccessBus low-cost 80 kilobaud 4 wire multi-master bus for
human input devices and other lowspeed devices.
Cheap keyboard OR game controller/rom reader standard
Two complete crt driver systems, TV with rich color and a
low-end monitor driver ( a 6840?)
Support for the addons on the MPU
256k static ram
headphone jack
realtime clock
a couple sources of non-determinism; a thermistor, a register
wired to read bus noise, etc.
a wirewrap area
and at the card-edge connector.....
std serial and parallel
analog to internal adc
MIDI in,out,through
5 channel by several voice audio/music via MuP21-based
subsystem chip ( DIBS! Leave this one to me! )
IDE
IEEE422 ( suggested by D. Edwards)
Whatever's cheap ( a basic genlock? )
Address Space
lots of 'reserved for expansion' address space
2^32 byte address space, access characteristics ( endianism,
minimum size of a store, etc.) based on the 68020
addresses of default hardware registers guaranteed
Default Operating Software
virtual/hardware implementable CPU stack for 0 latency task
switching ( e.g. 2^N sc32s on a chip/wafer)
everything includeable and callable in typical Forth fashion
preemptive multi-tasking , disc operators in rom
GUI available for graphical tasks and for the pre-literate
Singletask/absolute mode
Various task management features, eg task elapsed time metering
ANSI Terminal emulation vocablulary with
zmodem and kermit
a non-patented compress/decompress
full duplex split screen sketch mode
heirarchical file system,
the usual file tools, with sensible names and a Forth
non-syntax
triple 'are-you-sure?' directory types/partitions
branch size prompting by file/directory
'suffixdate' word for filenames
virtual memory block interface
music composition vocabulary
algebraic parser word for newbies/user interfaces ( 'let' ? )
Addons
Dvorak keyboard with hex pad
Asian keyboards
various other AccessBus gadgets, VR glove, proportional joystick,
Infrared transmitters, rom reader, PCMCIA, drumpads, clavier,
etc. ( ref. AccessBus ab...@netcom.com )
Std. drivebay module with SCSI
CPU upgrade
Master host module and slave host modules
video module ( support for Newtek Video Toaster, etc.)
ethernet module
phone module
Summary
A hacker's box, an artist's box, the coherence and interactivity of
a Forth development board with the tools to surf the net at the
entry price of a video game, purveyed by an organization intent on
enabling. Emphasis on audio at the entry level, but upgradeable to
luxurious multimedia capability, and beyond.
Are we having fun yet?
Rick Hohensee
Last quit guys nice.
Mark Adrian Flacy
<Gasp> MS-DOS is written in C? Hard to believe! ;->
Most of the programs that *I* use were written in assembler.
--
/ ------------------------------------------------------------------------ \
/ Mark Flacy "There's a lot to be said for a blow to the head" \
/ fl...@engin.umich.edu - Blue Oyster Cult \
/ "I guess ya had to be there." - Me \
A Reid Anderson Mob
This is beginning to look like a Language War! I've always felt that
FORTH afficionados were very tolerant towards other languages. Speaking
for myself, I prefer programming in FORTH, for a number of reasons.
_But_, I am not averse to using other languages when the _situation_
suits. For example, I am more likely to consider C when writing a program
for the PC, than FORTH or ASSEMBLER, but exclusively use FORTH and
embedded ASSEMBLER when writing EMBEDDED code
It all boils down to subjective preference and situations at hand.
I think what I'm trying to say is cool it. I joined this newsgroup
because I have a genuine desire to expand my knowledge of the FORTH
language, not to listen to the guys I consider experts bicker.
Tony R-A
.. They never leave enough room for me to sign on the dotted line
tst...@cix.compulink.co.uk
Jack Woehr
>This is beginning to look like a Language War! I've always felt that
>FORTH afficionados were very tolerant towards other languages. Speaking
>for myself, I prefer programming in FORTH, for a number of reasons.
>_But_, I am not averse to using other languages when the _situation_
>suits. For example, I am more likely to consider C when writing a program
>for the PC, than FORTH or ASSEMBLER, but exclusively use FORTH and
>embedded ASSEMBLER when writing EMBEDDED code
I posted the statement that started the flamefest, to wit,
" ... or join the mediocre and program in C."
The syllogism is as follows:
A. That which the vast majority does is, by definition,
mediocre.
B. The vast majority of programming is done in C today.
C. Ergo, C programming is mediocrity.
It's not a moral judgement, it's a tautology!
Mike Haas
>hohe...@tmn.com (Rick Hohensee) writes:
>
>>I crave a
>>Forth AmigaDos+. I verbally sketched such an object in a recent post in
>>here that I will be happy to email to any interested party.
>
>Forth remains the language of the pioneers who live on the fringe. As
>civilization catches up with them ... they move further out on the
>cutting edge.
That sounds like what drives Amiga users.
>
> If this makes you uncomfortable, join the hordes of the
>mediocre and program in C.
Sounds to me like John is not uncomfortable with "cutting edge"
at all. And C is a damn good language, not mediocre,
and capable of things today that Forth is not.
I'm amazed that with truely useless languages out there, Forth
folks love to critisize one of the most popular and truly
powerful.
Mike Haas
>> It seems to me that
>> interrupt pins are required for true preemptive multitasking. Charles
>> Moore, as of 1983, prefered a round-robin scheme. I am a musician with an
>> Amiga. I like true preemptive multitasking.
>
>Perhaps there's some confusion here. The Amiga uses round robin
>scheduling.
Nothing could be further from the truth. The Amiga is about as
pre-emptively multitasking as it gets.
One can put a task into a hard loop such as...
there: jmp there ;for assembly guys
BEGIN AGAIN \ the forth fellows
for (;;); \ guess who
..and all other tasks still get time. It includes a complete
prioritized scheduling exec... any task or process may have
a priority from -128 to +128, but generally best to stay
-20 to +20.
>And the word "true" is misleading at best, but to
>your credit at least you put "preemptive" instead of just saying
>"true multitasking".
>While a Forth virtual machine does not have
>interrupt pins, there is no reason it could not just about the
>same type of multitasking by polling.
As long as you are polling at a resolution that is finer than
any possible looping construct occurs in the program, yes.
Of course, a terrible speed penalty is incurred.
>
>Here's what happens on the Amiga, and most other machines.
>When an interrupt arrives, it pauses execution of the current
>process (either in the middle of an instruction, or after the
>current instruction is done, I don't have my reference), and
>runs an interrupt routine. When that routine is over, it continues
>where it left off. With time slicing, a clock interrupt routine
>may cause a context switch to a new process which will execute when
>the interrupt routine finishes (instead of going back to the old
>routine). Which process gets to execute next when this happens
>is determined by the scheduling algorithm, round robin in this case.
No, not round robin. Prioritized. Here's how most pre-emptive
systems work... a given process, while running is usualy at a
middle priority or lower, but if it performs some action which cause it
to have to wait on hardware (for example), it will increase it's
priority and go to sleep, consuming no system resources until
it's gating operation, usually the completion of the I/O
request, wakes it up. In the interim, lower priority processes
run. Being at a higher priority, it pre-empts whatever the
running task is when the I/O completion occurs. The overall
transition takes place at interrupt time in supervisor mode,
but just before control is passed to the waiting process,
user mode is again entered.
A process will be forced to yield the system when it exceeds it's
alloted time-slice, nominally 1/60th sec on the Amiga.
The only thing that even remotely resembles round-robin in the Amiga
is if this time-slice timer expires, the running task is swapped out, and
since no higher-priority tasks are ready to go (else the time-slice
would not have gone), The next process in the waiting process table is
run. (For purposes of this discussion, I am using the terms
"processes" and "tasks" interchangability. There are subtle differences,
but not so far as the exec is concerned.)
Besides, "round-robin" is not normally used to describe
the method by which a preemptively multitasking system
chooses the next process, but a NON-pre-emptive one.
Such systems have not a prayer of achieving decent real-time
response with only a few processes.
>
>What the interrupt pins help with (other than normal interrupt
>handling) is to efficiently detect when a process has used up it's
>time slice. With a real chiseled-in-silicon machine, this is
>probably the only practical way to get preemptive multitasking.
>In a virtual machine however, you can just test stuff after each
>instruction (with a variety of help depending upon the real
>machine underneath).
...and a lot of overhead incurred by all that "testing".
Plus, what good is the "test" without a corresponding
action having been decided by that test. So it's
not just a test that is needed between every instruction, but
a test and a conditional branch that must be executed. very
expensive. And testing on each pass through NEXT isn't
good enough... it actually must be done at the hardware
instruction level. Highly impractical.
Andrew Houghton
: Most of the commercial programs I use were written in C and have BUGS.
: I am constantly working around them, but occasionally they cause a
: real disaster. For ex., a certain highly respected graphing program
: crashed and brought down my CMOS ROM with it. I spent many hours
: reconfiguring my machine because I had neglected to record the settings.
: I could discuss my everyday word processor (written in C), a spread
: sheet I often use, etc. but why bother. They crash, sometimes predict-
: ably and sometimes unaccountably, but every one was shipped with bugs.
: And I am talking of DOS programs. When we consider Windows programs,
: forget it! That's why I don't use Windows often.
Just because the commercial programs you use are written in C and have
BUGS does not mean that the "C" language is to blame. The blame rests
with the programmer being careless and the company not being quality
conscience. Many programming languages give the programmer enough
rope to hang themselves. Forth and C are two good examples. Because
they do give the programmer this extra rope they can be *more* useful
in the proper hands. Many C programmer today should not be
programming in C because they lack the ability to pay attention to
details. It's not a fault with the language.
: My FORTHs, however, have never exhibited bugs. That is not to say my
: OWN programs do not ("What, never?" "No, never!" "What, never?" "Well,
: hardly ever...") crash from time to time, but the reasons are always
: my own carelessness with the stack or writing to the wrong address.
You statement justifies mine.
--
Andrew P. Houghton, MC 265 Internet: a...@oclc.org
OCLC Online Computer Library Center, Inc.
6565 Franz Road
Dublin, Ohio USA 43017-0702 NeXT Mail accepted.
Julian V. Noble
Most of the commercial programs I use were written in C and have BUGS.
I am constantly working around them, but occasionally they cause a
real disaster. For ex., a certain highly respected graphing program
crashed and brought down my CMOS ROM with it. I spent many hours
reconfiguring my machine because I had neglected to record the settings.
Ventura Publisher, that I used to DTP my book, is pretty good, except
when you print a long chapter the machine always crashes and needs to be
rebooted. Doesn't happen on short print jobs.
I could discuss my everyday word processor (written in C), a spread
sheet I often use, etc. but why bother. They crash, sometimes predict-
ably and sometimes unaccountably, but every one was shipped with bugs.
And I am talking of DOS programs. When we consider Windows programs,
forget it! That's why I don't use Windows often.
My FORTHs, however, have never exhibited bugs. That is not to say my
OWN programs do not ("What, never?" "No, never!" "What, never?" "Well,
hardly ever...") crash from time to time, but the reasons are always
my own carelessness with the stack or writing to the wrong address.
--
Julian V. Noble
j...@virginia.edu
Glauber Ribeiro
Mark Adrian Flacy <fl...@engin.umich.edu> wrote:
& <Gasp> MS-DOS is written in C? Hard to believe! ;->
Yes, but mostly true. I don't know what they write the kernel on
(probably assembler), but most everything else was shifted from
asm to C somewhere in between MS-DOG 2.x and MS-DOG 3.2 (watch
everything change from *.COM to *.EXE).
Windows uses asm only for device drivers. OS/2 2.x basically
doesn't support asm at all.
&
& Most of the programs that *I* use were written in assembler.
Interesting. The only program i have that's still pure assembler
is XyWrite 3.51. No, this is a lie. THe only large program in asm
i have is that one. There are the usual millions of little asm
utilities and some great little programs like FORTHCMP, PYGMY,
VDE, etc. This is at home. At work i work for a unix shop, and so
it's mostly C. As a matter of fact, i'll try to install TILE
today so i can play a little with FORTH. If i had a real computer
at home i'd be doing some kind of unix thing, like Linux. :-(
Personally, i'd rather be doing FORTH and Turbo Pascal, or at
least C++, than C.
Network Integrity
>Most of the commercial programs I use were written in C and have BUGS.
>...
>My FORTHs, however, have never exhibited bugs.
Great! This is what we've been looking for. I'm calling a meeting to
suggest we cease devloping our products with a language that causes bugs.
We can gain the competitive edge we seek by using FORTH, thanks to you,
for our future projects.
Anyone have a list of FORTHS suitable for Netware NLM development?
Thanks again!!
-scott
----
Sr. Tech. Consultant s...@world.std.com -or- n...@world.std.com
Network Integrity, Inc. 73116...@compuserve.com -or- 72223,742
201 Boston Post Road West Tel: (508) 460-6670 x303
Marlborough, MA 01752 Fax: (508) 460-6771
Jack Woehr
>In article <DJOHNSON.9...@arnold.ucsd.edu> djoh...@arnold.ucsd.edu (Darin Johnson) writes:
>>Perhaps there's some confusion here. The Amiga uses round robin
>>scheduling.
>Nothing could be further from the truth. The Amiga is about as
>pre-emptively multitasking as it gets.
Oh, I can think of some things that are further from the truth.
Any sycophantic obit of Richard Nixon in the past few weeks contains
many things that are further from the truth ... :-)
Glauber Ribeiro
&
&
& >This is beginning to look like a Language War! I've always felt that
& >FORTH afficionados were very tolerant towards other languages. Speaking
& >for myself, I prefer programming in FORTH, for a number of reasons.
& >_But_, I am not averse to using other languages when the _situation_
& >suits. For example, I am more likely to consider C when writing a program
& >for the PC, than FORTH or ASSEMBLER, but exclusively use FORTH and
& >embedded ASSEMBLER when writing EMBEDDED code
&
& I posted the statement that started the flamefest, to wit,
& " ... or join the mediocre and program in C."
&
& The syllogism is as follows:
&
& A. That which the vast majority does is, by definition,
& mediocre.
&
& B. The vast majority of programming is done in C today.
&
& C. Ergo, C programming is mediocrity.
&
& It's not a moral judgement, it's a tautology!
&
& =jax=
First premise is wrong, then syllogism is void. If it were right,
most things would be considered mediocre, such as, for instance,
breathing, eating and sleeping (things that rank far above
programming in my priorities :-)
Not only this, but by promoting FORTH you would be making
yourself progressively mediocre. :-)
I've programmed in many languages, and will still do so. I
know that greatness/mediocrity in programming cuts across
languages and platforms. What makes a great FORTH programmer
would also make a great Pascal / C++ / Whatever programmer.
Glauber
--
glauber ribeiro
gla...@david.wheaton.edu
-------------------------
em rio que da' piranha, jacare' nada de costas
Darin Johnson
> OWN programs do not ("What, never?" "No, never!" "What, never?" "Well,
> hardly ever...") crash from time to time, but the reasons are always
> my own carelessness with the stack or writing to the wrong address.
Hmm, I would think the very same holds true for more C programmers.
Ie, their crashes are because of their own carelessness, etc,
not because of some inherent flaw in C that causes bugs to appear
in an otherwise perfect piece of code. I have written C code for
over ten years, and only on extremely rare occasions have I been
bit by having incorrect code generated. (granted, I've never used
C on a PC :-)
Billy Tanksley
>Interesting. The only program i have that's still pure assembler
>is XyWrite 3.51. No, this is a lie. THe only large program in asm
>i have is that one. There are the usual millions of little asm
So I guess I'm superior to you, since I have a 7 meg GUI object-oriented
OS written entirely in assembler (PC). :)
Of course, I'm trying to port a forth to it-- will Yerk or Mops be any
good? Is there any previous work in a multithreading multitasking object
oriented (or any compbination of the above) forths?
-Billy
PC/Geos is, of course, the OS. It's FAST!
Darin Johnson
> debugging tools, than the FORTH interpreter/compiler/editor? (Stories
> about OK welcome.)
Er, is this a loaded question or what? :-)
Here's some on par, better in some areas, worse in others.
Lisp Machines. Need I say more? In this realm, even the
Franz GNU Emacs interface is pretty damn spiffy.
Saber C. C interpreter (it can get useless if you're debugging
a long running cpu intensive prog). Detects memory errors as they
happen (would that you could have Forth detect stack errors as they
happen)
Smalltalk. Although this takes a lot of expertise to be able to
use the debugging tools effectively.
> It is the sheer complexity, that is
> generated, when trying to build a big system on top of a bad design.
> And C is the cornerstone of this design.
Why does C help make things worse? Specifics, not just religious
"C is ugly" statements.
Then, state why Forth is so much better.
(especially for reducing design complexity, boggle)
> This is true. And while FORTH gives the poor souls the right debugging
> tools, C gives them tens of megabytes of complex (and buggy) CASE
> software and urges them go to C++.
CASE has nothing to do with C. C, or whatever language is used, comes
into play after the CASE tools have been used to create the design.
However, bringing up CASE and C++ together probably points out that
there's another viewpoint dividing Forth from a lot of other
languages. CASE and C++ really only become useful (or necessary)
with large programming projects with many programmers working on
it. A large majority of Forth programmers, IMHO, work individually
or in small groups. It's a different environment altogether even
when excluding the language being used.
> C vs FORTH is not a language issue. It is a paradigm issue. Or may be
> a religions one?
Probably religious. C has a zillion paradigms already.
I can see where you're coming from though. Personally, I tend
to shudder at C++. Although I recognize a lot of nice things
about it, and specific things that are bad about it, my biggest
reason for disliking it (when I'm honest with myself) is that
everyone's just so gaga over it.
Julian V. Noble
I have used the first and second versions of PC/GEOS. While it may be
true that it wants 7 Mb of yourhard drive, I don't think it fair to call
it a 7 Mb O/S. As I recall, the resident kernel was about 50 Kb, no?
Much of the 7 Mb is clip art, fonts and other crapola that people have
come to expect with windowing GUIs.
--jvn
Billy Tanksley
>I have used the first and second versions of PC/GEOS. While it may be
>true that it wants 7 Mb of yourhard drive, I don't think it fair to call
>it a 7 Mb O/S. As I recall, the resident kernel was about 50 Kb, no?
Well, you're right-- the actual executables (.GEO) total 4megs, but it
does have that much impact on your system. (Unless it's specially tailored
like the Zoomer-- total impact 4 megs.)
-Billy
This is kinda off topic, though-- I wanted info about the
graphical/multithreading/multitasking/object oriented versions of Forth so
I could port them to Geos.
Jeff Fox
GIS...@pharma1.pharma.mcgill.ca (Guy Isabel) writes:
>
>For what it's worth, I am a `minimalist' myself and I actually enjoy
>developing sparse, compact systems using Forth. I am no C enthusiast
>either, although I know the language. What I take issue with is, in my
>view, wrongfully blaming C for the complexity that we seem to have to live
>with, these days. C does not automatically yield complexity anymore than
>Forth does. It is just that the market demands complexity on one hand, and
>decries it on the other. That this complexity be written is the `langage
>du jour' should not reflect badly on said language.
>
>Remember, it could have been Forth :)
>
>Guy Isabel <gis...@pharma1.pharma.mcgill.ca>
Complexity is part of the trend in the shell game of computer marketing
these days. Bigger boxes, and applications that come on 25 high density
compressed diskettes MUST be better than the last version, and demand
the user to upgrade. Complexity is what is marketed and what sells.
I will believe that C does not automatically yield complexity anymore
than Forth when I see a C compiler that runs in a couple K of memory,
and that can compile itself from a few K of source code!
But if a new C compiler does'nt take up all the room on my hard disk and
slow the old computer to a crawl it wouldn't close the loop and force
the purchase of a new bigger computer to run the upgraded compiler
on the new computer...
Most C compilers don't even THINK of providing source code. If they did
how many megabytes would I need for say Microsoft C? Of course GNU's gcc
comes with source, and who would ever call it an example of complexity.
So I guess it is not fair to compare a C like gcc to a Forth that is
one thousand times smaller, but there are lots of small simple Forths,
and lots of big bloated overly complex C environments. And it is not
just the environment, I can compile Forth applications for Windows on
my machine, but not C, I have to buy a bigger computer to do that!
( well at least a bigger disk and a faster CPU and new motherboard etc)
Maybe it's just me, but I can read the complete source to some Forths
on one day, and understand almost all of it the next day. But I have
trouble reading 25 megabytes of C on one day and then claiming to
understand it the next day.
Here on the internet I have been given advice like, "Oh that is easy to
do with the XYZ utility. Just download the source code to GNU gcc, edit
it, and compile it with your C, then download the source code to GNU's
XYZ utility and compile it with gcc." I wanted XYZ to save me a little
time, so I thought this advice was rather funny.
Sure I prefer Forth for most of what I do, and I am not saying Forth
is always better than C. There are lots of times where C is the best
choice for obvious reasons. There are hoards applications where C is
already in place and like COBOL justifies its existence by its
existence. There are hoards of C programmers who are well trained
in wearing the C blinders that make it easy for them to pull together
as a team without being distracted by the big picture. So if your
marketing guys tell you that a bigger box, and more diskettes will
make your product more marketable what do you care about the number
of programmers, or the degree of complexity.
IMHO most of the PC hardware and software sold today is being bought
to inflate the budgets of middle managers who have the authority to
approve these purchases within their group. "If I don't spend the
money on upgrades this year, they won't put it in my budget again
next year." Managers get promoted more often for managing larger
budgets, not for saving money. So I constantly see companies spending
thousands of dollars for hardware and software upgrades every few
months for users who do nothing more than dial in VT100 emulation.
These companies buy hundreds or thousands of copies of unneeded
software upgrades, and then are forced to give the users new machines
to hold the latest inflated version of their software. These same
managers will tell their employees that they cannot get a raise or
that they will have to take a pay cut, and in the same breath tell
them they are getting a new computer for their desktop that cost
a lot for hardware and software.
Years ago this was the game with mainframes, now it is the game with
PCs. Therefore things that add unneeded complexity and inflate the
cost of machines and products are what drive the cycle.
There are many threads in this newsgroup about companies getting
the job done ten times as fast, or with 1/10 the cost by using
Forth. These companies maintain their edge because of the fact
that Forth lets them do what they need to do with less unneeded
complexity.
But in large companies mangers get promoted for making conservative
decisions that will be understood by upper management and for
spending more (not less) than their counterparts in middle management.
I recall one case a couple of years ago where a manager had to choose
between developing an application in C or COBOL. ALL of the programmers
and consultants said the same thing, "This application will cost ten
times as much if it is developed in COBOL." It was, it did, and it
got the manager his promotion for managing a bigger budget than his
peers.
IMHO. Forth is more than a language, it is a mindset. Understand the
problem and remove unneeded complexity. Chuck Moore has said that it
is not large quantities of code that is important, it is well thought
out code. Chuck advises that you do not try to solve a general case
when you only need to solve a specific case. And my favorite quote
from Chuck is that "It is more important what you take away than
what you add."
I see the real power of Forth as the elegant simplicity. This is doubly
true for Forth engines.
Jeff Fox
jf...@netcom.com
Ultra Technology
"For knowledge add a little every day, for wisdom, remove a little
every day."
Penio Penev
| Just because the commercial programs you use are written in C and have
| BUGS does not mean that the "C" language is to blame.
Does the buggines of the programs has anything to do with the
availability of good de-bugging tools? And has anybody heard of better
debugging tools, than the FORTH interpreter/compiler/editor? (Stories
about OK welcome.)
Surely, C is not the only culprit for the bugs. But C fits nicely in
the overall scheme of complexity in the modern commercial software
production. Take out C from it, and what do you get -- an incoherent
mess. C is the mortar for all the weird things, that happen in the
software industry.
| The blame rests
| with the programmer being careless and the company not being quality
| conscience.
Take the recently publicised internal memo from Tom Davis at SGI about
their release of IRIX 5.1 . It is not, that SGI is promoting
carelessness towards quality. It is the sheer complexity, that is
generated, when trying to build a big system on top of a bad design.
And C is the cornerstone of this design.
| Many programming languages give the programmer enough
| rope to hang themselves. Forth and C are two good examples. Because
| they do give the programmer this extra rope they can be *more* useful
| in the proper hands.
This is true. And while FORTH gives the poor souls the right debugging
tools, C gives them tens of megabytes of complex (and buggy) CASE
software and urges them go to C++.
| Many C programmer today should not be
| programming in C because they lack the ability to pay attention to
| details.
This is unfair. I lack the ability to write a complex C program also.
But does this mean, that I cannot (or should not) write usefull ( FORTH)
code?
| It's not a fault with the language.
C vs FORTH is not a language issue. It is a paradigm issue. Or may be
a religions one?
--
Penio Penev x7423 (212)327-7423 (w) Internet: pe...@venezia.rockefeller.edu
Disclaimer: All opinions are mine.
Guy Isabel
>Surely, C is not the only culprit for the bugs. But C fits nicely in
>the overall scheme of complexity in the modern commercial software
>production. Take out C from it, and what do you get -- an incoherent
>mess. C is the mortar for all the weird things, that happen in the
>software industry.
Penio, wouldn't you agree that software has become much more complex in
recent years irrespective of the language most of it is written in? It has
to do with user's expectations; Joe User wants to be able to click on icons
and not worry about learning syntax when playing his favourite multimedia
game. He is willing -- perhaps unknowingly -- to `sacrifice' a great deal
of CPU cycles if the result is a GUI with all the amenities that dispense
from learning about computers.
Suppose for a moment that Forth had become _the_ mainstream language of the
90's, if only because the Windows API was written in it. You would see
Forth everywhere, there would be Forth++, every contemporary (complex)
application would be written in it, etc. Forth would, in your mind, be
identified with complexity. It would be equated with (unavoidable) bugs
that are bound to lurk in any system so complex as to defy understanding by
any single person. And so on.
Robb Miles
Darin Johnson <djoh...@arnold.ucsd.edu> wrote:
<snip>
>> It is the sheer complexity, that is
>> generated, when trying to build a big system on top of a bad design.
>> And C is the cornerstone of this design.
>
>Why does C help make things worse? Specifics, not just religious
>"C is ugly" statements.
>
>Then, state why Forth is so much better.
>(especially for reducing design complexity, boggle)
In six years of 'C'ing, I've found two major problems for large programs.
(Note: I'm sticking to fairly well written programs for both languages.
Hacking in either language can be both useful and detremental to one's
projects.)
First, because of the "func_name(arg,arg,...)" syntax in C, make one change to
the definition and all calls must be hunted down and amended. The implicit
passing of arguments in Forth is a godsend when it comes to extending the
definition of a word.
Second, I've found it easier to emphasize the "high-levelness" of a word _in
terms of usage for its model_ rather than in terms of writing complexity.
At the same time, I'm not completely restricted from the "low-level" words.
Maybe it's again due to the implicit arguement passing, maybe I'm just weird,
but I've always found the simple(!) syntax of Forth encourages good naming
conventions as well as good factoring.
On the maintainability side, the simple syntax of Forth allows me to both
concentrate closely related "phrases" as well as separate those phrases to
the end of enhancing my readability. C can never claim this on a sub-function
level--the nuance of a comma, very long source function calls, absolute
dependance on horizontal indentation, etc., make the actual source code
eye-straining. Period.
>> This is true. And while FORTH gives the poor souls the right debugging
>> tools, C gives them tens of megabytes of complex (and buggy) CASE
>> software and urges them go to C++.
>
>CASE has nothing to do with C. C, or whatever language is used, comes
>into play after the CASE tools have been used to create the design.
>However, bringing up CASE and C++ together probably points out that
>there's another viewpoint dividing Forth from a lot of other
>languages. CASE and C++ really only become useful (or necessary)
>with large programming projects with many programmers working on
>it. A large majority of Forth programmers, IMHO, work individually
>or in small groups. It's a different environment altogether even
>when excluding the language being used.
This is my other beef with many software designs: most of those huge C
programs have no reason to be huge. I have not yet found some problem that
can't be solved in well under my "scribbling limit" (about 6f&b written pages).
I'm not going to argue that larger problems don't exist, but that quite frankly
current software practices tend to enlarge code design without any payback.
To me, there just seems no need to have a large number of people working on any
project that has been well specified. And a large number of people can't well-
specify a project.
>> C vs FORTH is not a language issue. It is a paradigm issue. Or may be
>> a religions one?
>
>Probably religious. C has a zillion paradigms already.
There's no doubt this is a religious issue. Right now, there are so few
ideas about how to program allowed to be expressed over the current software
engineering "ideal" that it's hard to explore the issue.
>I can see where you're coming from though. Personally, I tend
>to shudder at C++. Although I recognize a lot of nice things
>about it, and specific things that are bad about it, my biggest
>reason for disliking it (when I'm honest with myself) is that
>everyone's just so gaga over it.
Good thing I'm not like that :) (heck, I'm still don't have cable)
Robb
Disclaimer: He's a giant chicken, I tell you!
Julian V. Noble
> In article <Cpnrs...@murdoch.acc.Virginia.EDU> j...@fermi.clas.Virginia.EDU (Julian V. Noble) writes:
>
> >Most of the commercial programs I use were written in C and have BUGS.
> >...
> >My FORTHs, however, have never exhibited bugs.
>
> Great! This is what we've been looking for. I'm calling a meeting to
> suggest we cease devloping our products with a language that causes bugs.
> We can gain the competitive edge we seek by using FORTH, thanks to you,
> for our future projects.
What, sarcasm? On comp.lang.forth ? Heaven forfend!
Of course, I meant the FORTHs I bought commercially. They have no bugs
(or at least none I have ever detected) because they are small and simple.
Conversely, the commercial programs--written in C--that do have bugs are
typically very large complex programs, IMHO unnecessarily large and com-
plex considering what they actually ***do***. Of course no language protects
the progammer from himself, much as certain ones try. But some make the
process of writing bug-free code easy and some make it impossibly diffi-
cult. FORTH is one of the easy ones, C is full of pitfalls for the unwary
and even for the wary.
Andrew Houghton
[other stuff deleted]
: Of course, I meant the FORTHs I bought commercially. They have no bugs
: (or at least none I have ever detected) because they are small and simple.
I will agree in principal to this. The smaller any program (in any
language) is, the easier it is to verify its correctness. This is one
reason why Yourdon and Constantine advocate writing small routines,
in C or any other programming language. In addition an ACM article
(I cannot find which issue) on program verification also indicated
that as a routine's size decreases its reusability tends to go up.
The Forth community has known this all along! But it also applies to
C and other languages.
: Conversely, the commercial programs--written in C--that do have bugs are
You are comparing apples to oranges here. The apples being the FORTH
"compiler(s)" (I'll use that word loosely since were most likely
dealing with an interpreter vs. a true compiler) and the oranges being
an application developed by a C compiler. If you want to make that
statment then you should compare a commercial C compiler with a FORTH
"compiler".
Many people think that C is a complex language. It is not. The
language itself only has about ten statements and twenty expression
operators. The FORTH kernel and core word set has about the same.
Now if we look at the ANSI C library routines those equate to the
extension word sets in ANSI FORTH. So the C and FORTH languages are
about the same complexity, IMHO.
The place where I find bugs in comercial C compiler "packages" are
either in the interface to the OS you are using or in alternate API
libraries provided by the vendor. Typically the OS interface problems
are: the compiler runs under a windowing system and it doesn't
correctly pop up a window, etc. Even though you are "running the
compiler" I cannot consider this a bug in the syntactic/semantic
analysis of the compiler. It is a bug in the vendors product but not
in the compiler, proper. There is a subtle difference and we both
need to sure that we are comparing apples to apples.
: typically very large complex programs, IMHO unnecessarily large and com-
: plex considering what they actually ***do***. Of course no language protects
It sounds like your trying to equate program size with the complexity
of the problem being solved. They cannot be equated directly. Take
the simple example were you want to solve the following equation for
C given A and B:
2 2 2
C = A + B
Under MS-DOS and UNIX we just ask the user for say A and B and then
compute C. Under MS-Windows or X-Windows we need to create a dialog
box to get the two numbers and maybe create another dialog box with
the answer. The complexity of the original problem has not changed
in each one of these environments. We still want to solve the same
equation.
: the progammer from himself, much as certain ones try. But some make the
: process of writing bug-free code easy and some make it impossibly diffi-
: cult. FORTH is one of the easy ones, C is full of pitfalls for the unwary
: and even for the wary.
Your statement of "some languages" making writing bug-free code
easier, is subjective. Actually I think FORTH has more pitfalls than
C does. For example: in FORTH leave a parameter to a word off the
stack and watch your program crash and burn. This is one of the most
common mistakes. Or how about saying: "FORGET word" where "word" was
the last word you defined and watch all the words you previously
defined disappear.
All programming languages have pitfalls. We learn these "pitfalls" by
either reading about them or experiencing them first hand. This is
all part of the process of learning to program in a language. FORTH
is no different than C, just the pitfalls change to confuse the
programmer.
Darin Johnson
> the definition and all calls must be hunted down and amended. The implicit
> passing of arguments in Forth is a godsend when it comes to extending the
> definition of a word.
Hmm, bizarre. Matter of preference I assume. In C, if you change
the the number of arguments, or argument order, the compiler will
let you know if you forget somewhere. In Forth, you must also track
down everywhere it was called - if you don't, you get no warnings
except for a bug at runtime.
How can you not hunt down where the word was called??? I haven't
seen a Forth with implicit argument passing! Unless you call
explicitly pushing something on the stack "implicit".
> Second, I've found it easier to emphasize the "high-levelness" of a word _in
> terms of usage for its model_ rather than in terms of writing complexity.
> At the same time, I'm not completely restricted from the "low-level" words.
> Maybe it's again due to the implicit arguement passing, maybe I'm just weird,
> but I've always found the simple(!) syntax of Forth encourages good naming
> conventions as well as good factoring.
I can barely figure out what you mean here. I'll assume that it's not
gobbledygook and that it's just beyond me.
> On the maintainability side, the simple syntax of Forth allows me to both
> concentrate closely related "phrases" as well as separate those phrases to
> the end of enhancing my readability. C can never claim this on a sub-function
> level--the nuance of a comma, very long source function calls, absolute
> dependance on horizontal indentation, etc., make the actual source code
> eye-straining. Period.
This is ENTIRELY subjective. The syntax of C allows you to
concentrate on phrases as well. It has extra punctuation, but
punctuation that naturally fits at the beginning and end of phrases.
How about a concrete example?
To many, C is much easier to read than Forth (so you're different,
big deal). There is not absolute dependece on indenting. Get rid
of indenting in Forth and you have an unreadable mishmash, same as
C. In fact, in C, you have have visual cues to pick up where
blocks begin and end, etc. In Forth, you must have indentation to
figure things out.
Am I falling into a trap here, and arguing with an irrational Forth
zealot (those exist in all languages) that would be better ignored?
> I'm not going to argue that larger problems don't exist, but that
> quite frankly current software practices tend to enlarge code design
> without any payback.
Not the fault of C though, unless of course, you're on a holy mission
to eradicate the language.
Marc DeGroot
Julian V. Noble <j...@fermi.clas.Virginia.EDU> wrote:
>As Brodie says in Thinking FORTH, this is a sign of terrible factoring.
>My guess is that large complex applications could be made 10% of their
>present size with little effort and virtually no loss of performance
>simply by a factoring the functions (or words or whatever) that comprise
>the application. The trick is to discover the orthogonal minimal set
>that spans the space of desired operations.
There's more of a trick than that, in my opinion. The programmer has to
be motivated to factor. C effectively discourages factoring by making
it a big chore to re-declare variables and make sure they're passed correctly.
Forth, on the other hand, encourages factoring because it's easy to factor
code: any in-line sequence of words is simply replaced by the new word name.
Mouse-and-windows systems also contribute to the problem. It is far easier
to copy and paste code, and change the calling arguments, than to make a
single subroutine.
Obligatory enigmatic question: If X only manages the display, why is it
so much larger than the Mac OS, which manages everything?
--
Marc de Groot (KG6KF) San Francisco | "Software is neither science nor
Internet: ma...@kg6kf.ampr.org | engineering. It's really an
UUCP: ..!uunet!hoptoad!noe!marc | obscure form of poetry."
Packet radio: KG6KF @ K3MC |
A Reid Anderson Mob
> I will agree in principal to this. The smaller any program (in any
> language) is, the easier it is to verify its correctness. This is one
> reason why Yourdon and Constantine advocate writing small routines,
> in C or any other programming language.
I'm curious about summat. In the good old days, perhaps still true for
many of you, I developed Forth using a Forth editor. Each screen
contained 16 lines of 64 characters max, ie: each screen could hold a max
of 1k of code.
The criterion was that if the word I was developing was longer than 1
screen then I was not writing *good* code. The environment *encouraged*
short sharp code.
I now program using a text editor. I'm not as fastiduous as I used to be
about the size of a word definition because size is not so obvious now. I
don't think I'm a *worse* programmer/designer for it, but I will admit
that my code tends to be buggier.
James Hague
>
>Years ago this was the game with mainframes, now it is the game with
>PCs. Therefore things that add unneeded complexity and inflate the
>cost of machines and products are what drive the cycle.
As unscientific and idiotic as it sounds, one of the big reasons I like
Forth is that programming in it is fun (well, as about as fun as
programming can be). That's got to be worth *something*, especially as
programming has become less of a problem solving activity and more of a
research field ("How do I do XXX in this operating system?" "Here are
5000 pages of compiler documentation, 5000 pages of operating system
documentation, and 18 megabytes of hypertext help. Go!").
FWIW.
James Hague
junk...@halcyon.com
Marc DeGroot
A Reid Anderson Mob <tst...@cix.compulink.co.uk> wrote:
>This is beginning to look like a Language War! I've always felt that
Test question: Why is your language best?
Argue loudly and forcefully in support of your language. If possible, use
physical violence to defend your views.
50 pushups will be left as an exercise for the reader.
Andrew Houghton
: In article <Cpx7L...@murdoch.acc.virginia.edu>,
: Julian V. Noble <j...@fermi.clas.Virginia.EDU> wrote:
: >As Brodie says in Thinking FORTH, this is a sign of terrible factoring.
: >My guess is that large complex applications could be made 10% of their
: >present size with little effort and virtually no loss of performance
: >simply by a factoring the functions (or words or whatever) that comprise
: >the application. The trick is to discover the orthogonal minimal set
: >that spans the space of desired operations.
: There's more of a trick than that, in my opinion. The programmer has to
: be motivated to factor. C effectively discourages factoring by making
: it a big chore to re-declare variables and make sure they're passed correctly.
: Forth, on the other hand, encourages factoring because it's easy to factor
: code: any in-line sequence of words is simply replaced by the new word name.
You hit the nail on the head: "The programmer has to be motivated to
factor." But I disagree with you that C effectively discourages
factoring. I factor all the time. Its not a chore to setup a function
to do "N" lines of code and call it in the original place as well as
the new place. I will admit that Forth entails fewer keystrokes to
factor, but not necessarily fewer steps.
I think you need to compare equal quantities here. Forth is basically
an expression language. It has operators, lots of them, and
expressions are built up from those operators. C on the other hand
has those same features but adds other syntatic conventions such as
statements, blocks, functions and modules. If we compare Forth and C
at the expression/statement level there is little difference. When we
talk about factoring, things start to get "fuzzy". Forth, cleanly,
considers it just another expression where C adds a syntatic
convention, the "function". I don't see how this "effectively
discourages" factoring. It's just a different syntatic convention
between the languages.
: Mouse-and-windows systems also contribute to the problem. It is far easier
: to copy and paste code, and change the calling arguments, than to make a
: single subroutine.
This is a BIG problem, especially here where I work. But it gets back
to what you originally said: "The programmer has to be motivated to
factor." I estimate that our Online application is about thirty to
fifty percent larger than it should be.
: Obligatory enigmatic question: If X only manages the display, why is it
: so much larger than the Mac OS, which manages everything?
Because X was a University research project were typically there is
no incentive to consider real world, commercial constraints. Research
projects are trying to determine the feasibility of some theory. It's
also somewhat of an unfair comparison since due to the limited memory
on the Mac, 128KB, the team at Apple was highly motivated to factor.
One of those real world, commercial constraints.
Chuck Eaker
|> Of course, I meant the FORTHs I bought commercially. They have no bugs
|> (or at least none I have ever detected) because they are small and simple.
Nothing in my experience suggests that there is a connection
between small and simple, on the one hand, and lack of bugs
on the other. Face up to the fact that much of your life is
dependent on many complex software systems operating without
failure including electronic funds transfer, flight control,
satellite navigation and control systems, and thousands of
business systems that maintain your accounts with hundreds
of companies and government agencies.
What is strongly associated with bug-free software is a
disciplined process used to create it. Not complexity, not the
language, not the operating system, not the tools. It is
applying best engineering practices to the unique demands of
software.
It is ludicrous for the members of the Forth community to
continue to generalize about what yields a good software system
based on their experiences of working alone with Forth.
--
Chuck Eaker / K-1 4C29, P.O. Box 8 / Schenectady, NY 12301 USA
ea...@crd.ge.com Voice: 518 387-5964 Fax: 518 387-6928
john wavrik
In Article 15567 of comp.lang.forth Chuck Eaker writes:
> What is strongly associated with bug-free software is a
> disciplined process used to create it. Not complexity, not the
> language, not the operating system, not the tools. It is
> applying best engineering practices to the unique demands of
> software.
I'm inclined to agree with Chuck Eaker here -- based, oddly
enough, on years of experience with teaching Forth.
In my recent articles on teaching Forth and Forth texbooks, I'm
sorry that I failed to mention "Thinking Forth" -- which I have found
quite appropriate and useful at the college level. [It is ironic that
*this* is the book that went out of print! I applaud FIG for
republishing it.] This book teaches good Forth programming style
which, as it turns out, seems to be good style in any language.
At one time I worried about teaching Forth in my class, knowing
that most of my students would actually wind up programming in other
languages. I justified my use of Forth based on the fact that
(traditional) Forth can be easily learned -- and my feeling that I
could defend it against charges that it teaches "bad" techniques.
(traditional) Forth reinforces and encourages good techniques. The use
of screens, parameter passing in the stack, and the interactive nature
of the language encourage the development of a large application by
using a hierarchical collection of small, well-named, well-tested, and
well-factored components. The simplicity and accessibility of the
underlying system provide total knowledge of the foundations on which
applications are built.
The students in my class who wrote the worst programs tended to
write word definitions extending over several screens (the
continuation arrow --> is immediate in F83) with control structures
nested 6-7 levels deep. Inevitably such programs don't work at the
first try -- and the students want to know "where is the Forth
symbolic debugger?" so that they could track down the bugs. I contend
that such programming is bad in any language -- regardless of what
tools are available for debugging.
The students who wrote the best programs bought into good
factoring, careful design, testing along the way, etc. Forth doesn't
require good programming practices -- but it definitely provides a lot
of support. I remember someone in comp.lang.forth answering a question
about Forth debugging tools. Someone replied: "Forth doesn't need a
symbolic debugger -- Forth *is* a symbolic debugger". And so it is,
if an application is built (in the Forth style) from small, well-
factored definitions.
It is rare (as any college teacher will tell you) to hear from
students after they graduate. I heard from one of mine who was
programming in a "C" shop. He just wanted to let me know that he found
himself using "Forth" techniques in his programming -- and found that,
to his surprise, he was writing more solid programs in shorter time
than his colleagues.
Charles Moore independently invented, as far as I can tell, both a
style of programming and a language to support it. Forth not only
supports structured programming, but anticipated some of the elements
of functional and object-oriented programming. Moore's ideas on
programming have a non-trivial intersection with ideas developed (or
to be developed) within computer science. Read some of the early books
on "structured programming" and you will find that the intent is that
programs should be built up from well-factored, simple components.
The intent was not often carried out -- because the accompanying
languages (like Pascal) easily allowed the use of bad programming
style. "Forth is an amplifier" (paraphrasing a quote by Charles Moore)
"it can make good programmers do better, but it makes bad programmers
worse".
I suspect that I must therefore agree with Chuck Eaker: solid
programming is the result of good technique (independent of the
language). I do not agree with him if he is suggesting that there is
no difference in languages in the extent to which they are supportive
of good technique.
> It is ludicrous for the members of the Forth community to
> continue to generalize about what yields a good software system
> based on their experiences of working alone with Forth.
I fail to see what is ludicrous. My professional need is to be
able to quickly build (working alone -- and as a professional
mathematician rather than a professional computer programmer) very
solid and non-standard applications. There are lots of other people
in a similar position. Not all software systems are generated by a
cast of thousands. I think a good claim can be made that Forth has
properties that make it well-suited for producing systems of the kind
I (and others like me) produce. I use Forth because, as some
comparison shopping has disclosed, I can do as an individual what
would indeed require a team using a more conventional language.
I believe that (traditional) Forth, as a language, has many strong
features which do result in good software systems. Any complaints I
have are not about the "product" -- but about how badly it has been
"developed" and "marketed" by the Forth community.
John J Wavrik
jjwa...@ucsd.edu Dept of Math 0112
Univ of Calif - San Diego
La Jolla, CA 92093-0112
Roger Bicknell
>n...@world.std.com writes:
:: In article <Cpnrs...@murdoch.acc.Virginia.EDU> j...@fermi.clas.Virginia.EDU (Julian V. Noble) writes:
::
:: >Most of the commercial programs I use were written in C and have BUGS.
:: >...
:: >My FORTHs, however, have never exhibited bugs.
::
:: Great! This is what we've been looking for. I'm calling a meeting to
:: suggest we cease devloping our products with a language that causes bugs.
:: We can gain the competitive edge we seek by using FORTH, thanks to you,
:: for our future projects.
:What, sarcasm? On comp.lang.forth ? Heaven forfend!
: C is full of pitfalls for the unwary
:and even for the wary.
I've been watching this discussion for awhile now; I didn't want to
say anything because I know that the language does not dictate
_what_ you do with it; and I also know that the language, its
syntax and semantics, mold your thinking as to what you _will_ do.
But when I read Julian's last comment here, I couldn't resist.
Macros in C: pitfalls for the unlucky.
"Everyone" knows that you "always" surround your macro arguments with
TWO sets of parentheses so that there won't be any surprises when the
macro is rendered. Well... most of the time:
In my current project, the system decided that a type "size_t" would
be rendered as a "long", even though the OS funcs want the size of its
args all in "short"s. I got tired of having to cast every "size_t" usage
into a "short" a la "(short)sizeof(blah-blah)". So I wrote this macro:
#define SIZEOF(x) ((short)sizeof((x)))
The system EXPLODED! Mad, I tell you. "She see macro, she go a crazy!"
What is wrong? Do you see it yet?
Yup. Each time the macro was fed a typedef for an argument, that extra
set of parantheses converted the typedef into a cast!
<Argh!>
I've never seen problems in Forth that I have seen (constantly) in C.
Is this inherant in C? Yes and no. It has a more complicated syntax
(yes, I've had to explain pointer arithmetic to many many new programmers).
But C also has problems _because_ of stupid implementations of concepts -
which muddies the waters even more.
-roger
PS. We won't even start with C's idiotic promotion of chars to ints...
--
bick...@mdd.comm.mot.com (Roger Bicknell)
Remember: "Guns don't kill people and GNU is Not Unix." =]
Andrew Houghton
: It is rare (as any college teacher will tell you) to hear from
: programming in a "C" shop. He just wanted to let me know that he found
: himself using "Forth" techniques in his programming -- and found that,
: to his surprise, he was writing more solid programs in shorter time
: than his colleagues.
I'll second that. I have been programming in C for fifteen years. I
picked up Forth about five to seven years ago. After stumbling around
in Forth I came across "Thinking Forth". Since that time I have
noticed that my C techniques have improved and I'm writing code quicker
than my colleagues and spending a lot less time debugging it. When
new requirements cause changes to my existing designs the changes are
encorporated into the design a lot easier.
Jeff Fox
>
>Nothing in my experience suggests that there is a connection
>between small and simple, on the one hand, and lack of bugs
>on the other. Face up to the fact that much of your life is
>dependent on many complex software systems operating without
>failure including electronic funds transfer, flight control,
>satellite navigation and control systems, and thousands of
>business systems that maintain your accounts with hundreds
>of companies and government agencies.
>
>disciplined process used to create it. Not complexity, not the
>language, not the operating system, not the tools. It is
>applying best engineering practices to the unique demands of
>software.
I will agree that it is applying best engineering practices that
results in bug-free software, but thats about it. While I was an
employee of Bank of America they wrote off losses of about one
million dollars an hour for years. Banks routinely list millions
of dollars lost in electronic funds transfers as no different than
any other business expense, although creative language may be used
to avoid upsetting stockholders. I particularly enjoyed the story
of the bug that went out with their first ATM software.
I would argue that management is usually responsible for doing
things like saving money by leaving off the testing phase of the
project, and putting untested programs into production.
Flight control, ever heard of the F16, Y-22, or 737? Serious
problems appeared after thousands of hours of bug free operation.
If two programs do the same thing and one is 10,000 times larger
than the other I would argue that there are more chances for bugs
to be hiding in the larger program, maybe 10,000 times as many.
In fact I would argue that there would be 10,000 raised to some
power times bugs in the larger software.
But I think we are getting away from the real issue. If testing
is integrated into the development (as is encouraged in Forth)
and testing is seen as important enough to get a reasonable part
of the budget bugs can be reduced. If lives depend on software being
bugfree, or if a company goes out of business because its customers
cannot live with buggy software then bugs become important.
But in the world of PC marketing functionality, usefullness and bug
free operation are not very important. With enough advertizing on
the super bowl users can be convinced that they need something
and will line up to buy it years before it is delivered. They
can also be convinced that a little money and an upgrade will fix
the bugs they are dealing with.
Have you ever seen thousands of computers (and monitors) running
all weekend and displaying new elaborate screen savers? Not to mention
the electrical power needed to run a thousand PCs over a weekend, or
the wear on the drives, or the slow burnout of their monitors, just
look at the upfront cost of thousands of copies of these screen
savers. If a company wants to save the screens of its PCs they
can blank them with $.02 worth of code, or turn them them off, or
they can spend thousands of dollars to put Mickey Mouse on every
computer. Now I would argue that these screen savers are just a
distraction to anyone who is actually trying to get any productive
work done. But they are part of the trendy software packages that
are what PCs are all about these days. And yes people actually
buy bigger disks and new computers so they can run the newest
more elaborate screen savers.
In the PC market big, bloated, buggy software is the norm in the
consumer market.
I was supprised by first exposure to the PC market when I saw that
companies did things like have 30 employees who answer the phone,
take orders and assure the customers that the software is in the
mail, while in the back room one programmer is responsible for
designing, programming, debugging, testing, and documenting
the product.
SO in PC marketing bugs and complexity are not seen the same way
that programmers see them.
As long as management wants to inflate quarterly budgets so the money
will be there next year, and PC consumers continue to buy the
latest and greatest then complexity is not an issue. More programmers
and more testing means a higher budget and a higher position in
the company for someone. And more expensive products in bigger
boxes with more TV commercials are another good way to inflate
your PC budget.
But where development and operating expenses are an issue so is
complexity.
Costs are not just proportional to complexity, but they are proportional
to complexity raised to some power.
Given the same level of attention to quality control a more complex
system will have more bugs. And at some level of complexity it will
become impossible (in the real world) to ever verify that the system
is bug free.
Jeff Fox
Ultra Technology
___
_ _ _ _ |
| | = | | | =
Darin Johnson
> is integrated into the development (as is encouraged in Forth)
> and testing is seen as important enough to get a reasonable part
> of the budget bugs can be reduced.
Beware you don't fall into a trap of thinking testing is vastly
simpler in Forth. It involves more than just checking out each word
as it is written (any interpretive language allows this, and is common
practice). But you have to test each word with a giant range of
inputs and environment conditions. Just because your word seemed to
worked great when you wrote it doesn't mean it will behave the same
way when used as part of your large program. And after a trivial
change to a word, most people (even in Forth) don't go back and
redo all the tests.
While a lot can be simplified in Forth, the "it's integrated
into development" statement (and other preposterous boasting)
can seriously mislead beginners who take it seriously.
--
Darin Johnson
djoh...@ucsd.edu
Support your right to own gnus.
Chuck Eaker
|> I suspect that I must therefore agree with Chuck Eaker: solid
|> programming is the result of good technique (independent of the
|> language). I do not agree with him if he is suggesting that there is
|> no difference in languages in the extent to which they are supportive
|> of good technique.
I am indeed suggesting that. Forth is no more supportive (or
unsupportive) of good software engineering practices than any
other language.
|>
|> > It is ludicrous for the members of the Forth community to
|> > continue to generalize about what yields a good software system
|> > based on their experiences of working alone with Forth.
|>
|> I fail to see what is ludicrous. My professional need is to be
|> able to quickly build (working alone -- and as a professional
|> mathematician rather than a professional computer programmer) very
|> solid and non-standard applications. There are lots of other people
|> in a similar position. Not all software systems are generated by a
|> cast of thousands. I think a good claim can be made that Forth has
|> properties that make it well-suited for producing systems of the kind
|> I (and others like me) produce. I use Forth because, as some
|> comparison shopping has disclosed, I can do as an individual what
|> would indeed require a team using a more conventional language.
I interpret your remarks as saying that your experiences with
Forth are working alone producing software that only you use.
What I'm claiming is ludicrous is the drawing of conclusions
about how all software ought to be developed on the basis of
that very limited experience.
And while I'm at it, I might as well point out that I believe
the claim that an individual can do with Forth what would require
a team in a conventional language is also ludicrous.
john wavrik
In Article 15579 of comp.lang.forth Darin Johnson writes:
> The screens? The only advantage here is forcing you to be small.
The Forth screen fits on a computer screen and can be viewed in its
entirety without scrolling. It is of a size that can be easily scanned
as a whole by eye.
There seems to be something that works about programming in
comprehensible packets that can be viewed as a whole. It's not just
smallness -- its also aptness. What you see should be simple enough to
check for correctness and complete enough so that you don't need to
remember its details when you move on.
When using file-based systems a user will find similar advantages
if coding is done in viewable packets. There is probably some sort
of psychological reason this works.
I once asked someone in the Cognitive Sciences department if they
ever studied programming languages (they haven't -- but they have
studied computer user interfaces and the former department chairman is
now working for Apple).
> There's no need any more for archaic environments that force you to
> learn and use someone elses favorite editor.
Perhaps some day there will be an ANSI-standard editor for
everything. At the moment users of any integrated system (which
includes computer algebra systems as well as program development
environments) must either learn to use the system editor or forgo the
advantages of the interactive integrated environment. I'm happy for
you if you can get by with one editor -- many of us need to use
several.
Of course, one can either write an editor or try to couple a
favorite editor with Forth. This is not a facetious remark [There is a
nice discussion of how to write a screen editor in Kelly/Spies. This
editor was adapted to F83 and used in my course. It's simple to use,
works well, and can be customized.]
> Parameter passing on the stack I sort of consider neutral. It's got
> plusses, but a lot of drawbacks as well. If you forget a parameter
> you have to deal with a runtime error instead of a compile time
> warning.
Usually it's a runtime error which is caught during development
rather than use of an application. Putting together and testing
the application is really analogous to part of a compilation process
rather than part of usage.
It seems to be easier to code if the code consists of a succession
of well-chosen names for actions (with implicit arguments) rather than
requiring the explicit listing of arguments for all actions.
The top level of applications can include interfaces which prompt
for input (just as do programs written in conventional languages).
> It also encourages small definitions, otherwise you go bonkers
> trying to figure out what's on the stack at any time
Yup
> (I'm not saying Forth is bad here, I think it's great. But this
> thread deals with preposterous boasting and people that think Forth
> is flawless.
Actually my article was written to agree with a comment by
Chuck Eaker to the effect that it is careful design and coding
practices (rather than the language) that makes for solid programming.
I see the purpose of the thread to explore reasons why people feel
that Forth is a good programming language. The fact that the thread
got its name because someone several months ago made overinflated
claims is incidental.
> Interactive - Great! Students need that sort of stuff
Actually not just students. Many current application areas for
computers require an interactive environment (witness the fact that
all of the major computer algebra systems provide an interactive
environment).
Mathematics provides good examples of both ends of the spectrum.
Number crunching usually involves application of well-studied
algorithms to varying data. The batch-like environment provided by
conventional compiled languages is not intolerable. In areas not so
historically associated with computation, however, it can be the
algorithms, data representation, etc. that are as much the subject of
change and experiment as the data. It can be necessary for the user
to intervene in the analysis -- making subjective judgments and
possibly alterations in the code. This requires features associated
with an interactive environment (not just the ability to issue
commands from the keyboard, but also things like persistence of values
of variables after commands have executed).
When computer algebra systems are written using conventional
compiled languages, the first step is to use these languages to
implement an interactive interpretive programming language which is
then used for writing most of the system (and provided for users).
> So, as an aside. It's been said you sing in your math classes.
> Do you do so in your Forth classes as well? ;-)
As an aside, aren't you the guy I mentioned who wrote programs that
don't work and flunked my class a few years ago? :-)
Guy Isabel
>[...] How do you stop execution at a
>certain point without a breakpoint without manually executing
>all the stuff that comes first? [...]
Easily enough. Just insert the word `BREAKPOINT' (see below) where needed.
: BREAKPOINT ( -- ) KEY DROP ;
This is only the shareware version of this powerful tool; write me for
details and pricing on the full-fledged commercial version :)))
Guy Isabel <gis...@pharma1.pharma.mcgill.ca>
Darin Johnson
> you if you can get by with one editor -- many of us need to use
> several.
Yep, I'm coming from a workstation/large-computer point of view
(and Amiga). After using, and being able to build my own
environments, it seems to me it would be annoying to be forced
to use someone else's idea of a good environment (well ok, a
committee's idea of one).
> It seems to be easier to code if the code consists of a succession
> of well-chosen names for actions (with implicit arguments) rather than
> requiring the explicit listing of arguments for all actions.
Except the arguments in Forth aren't really that implicit at all.
You must still explicitly put the arguments there, execute a word
that puts them there, or know that they are already there.
In Lisp (and C), you have prefix notation, with parentheses
delimiting what the arguments are. You could do something similar
in a postfix language - assuming parens aren't comment delimiters
but instead are noops, you could have "( 1 ( 2 3 add ) mul )"
(of course, this messes up if you want to swap, pick, etc).
But just because the parens go away, doesn't make anything implicit.
> As an aside, aren't you the guy I mentioned who wrote programs that
> don't work and flunked my class a few years ago? :-)
Nope. Never took a class from you, never flunked a class - but I
did write a handful of programs that didn't work :-)
Julian V. Noble
Much of the complexity of modern code is spurious. One of the things I am
trying to do now is develop a way to measure the inherent complexity of
algorithms, systems, etc. I am trying to read a book on Kolmogorov
complexity theory and information content, but it is heavy sledding...
However, consider MathCad vs. Derive (A Mathematical assistant).
The former wants 18 Mb of my disk, and will run in 8 but wants 16 Mb
of ram. The latter fits nicely in a 640 K PC-XT and does about 90%
of what MathCad does. So why is the former so much bigger? esp. since
it once was a reasonable size. I believe it is because mathCad was
(re)written in C++. (The good thing about C++ is it lets you reuse your code;
the bad thing is, you reuse it and reuse it and ...)
If one examines the Windows PDI (2 volumes of C functions) one notices
a huge number of names like "DoThisThingy_in_Box_39_If_NoMouse".
As Brodie says in Thinking FORTH, this is a sign of terrible factoring.
My guess is that large complex applications could be made 10% of their
present size with little effort and virtually no loss of performance
simply by a factoring the functions (or words or whatever) that comprise
the application. The trick is to discover the orthogonal minimal set
that spans the space of desired operations.
--jvn
john wavrik
I find a recent article by Chuck Eaker rather mysterious. He wrote
an article taking the position that good programming technique is the
major factor in producing solid code. My article, in response,
supported his position with some anecdotes from a course in Forth. I
made the point that the programming practices advanced by experts in
Forth style are compatible with what is taught about programming
practices in beginning courses using other languages. I assume he is
taking issue with the claim that Forth supports good programming
techniques -- but his reply seems to be more directed at who is
allowed to express an opinion about this matter.
I must apologize for the autobiographical flavor of this article.
It is the only way I could think of to clarify the role of good
programming practices in the production of research software -- and
to respond to Eaker's statements directed at me personally.
Chuck Eaker, ostensibly replying to me, writes:
> I interpret your remarks as saying that your experiences with
> Forth are working alone producing software that only you use.
My main professional uses of Forth are in research and teaching.
Almost 15 years ago, I became interested in exploiting the (then new)
availability of microcomputers in parts of mathematics not
historically bound up with computation (particularly abstract algebra
and related fields). My original work involved production of systems
that would allow a mathematician to examine examples and conduct
experiments to guide theoretical work. There was never an intent to
produce commercial software -- but it has always been important that
I be able to recycle code (in the sense that I can modify and reuse
parts of systems for years after they were originally written). In
addition, the ability to write code that others could use (not just
the application but the code itself) was an important consideration in
my choice of Forth as the language for my research. At the time I
selected it, Forth was extraordinarily portable -- so I only felt I
needed to convince myself that one could write clearly in the
language, that it could be appropriately documented, and that code
could be effectively modularized. At the time there were no guides to
Forth style -- so my investigation in this area was influenced by the
computer science literature on programming practices and systematic
experimentation with Forth style, documentation techniques, etc. [I
was delighted to see the eventual appearance of Brodie's "Thinking
Forth" which competently codified the style and techniques developed
at Forth, Inc.]
During the past few years, an additional factor related to coding
arose in my work. In my earlier work, the results obtained from the
computer were just used to produce ideas. The actual end product was
in the form of traditional proofs. Like several other mathematicians,
I am now doing research which requires the use of a computer to check
the validity of assertions. It is necessary to be sure of the
correctness of the implementation -- not just the algorithms but the
coding as well. This places a special premium on the ability to
generate correct code -- so concern with coding technique has assumed
even greater importance.
Research mathematicians are traditionally held accountable
not only for the correctness of the work they do, but for the work of
others that they use in their work. We must not only know that we have
not misapplied someone else's theorem -- but also that their theorem
is correct. Many of us were taught that we should know the proof of
any theorem we use in our work. If use of a computer becomes an
integral part of a mathematical proof, it is to be expected that the
same standards apply. I regard myself as responsible for insuring the
correctness of anything involved in my work. I therefore regard it an
asset of Forth that it provides the requisite degree of knowledge and
control.
An entire research application is often too specialized to be
distributed as a whole. If it can be written in a modular fashion,
it would be possible to distribute a package of generally useful
procedures developed as part of its production. This has not happened
in my case mainly due to the Forth community's abandonment of the
language's potential for portability and the attendant decline in the
language's popularity. There is no reason other than this that
research packages written in Forth could not be distributed and used
by others in the same way that research packages written in
Mathematica or Maple are currently being distributed. (Each of these
systems has a refereed library of software submitted by users. The
packages in these libraries will run unaltered on a wide variety of
platforms.) There is no reason to believe that the Forth language
itself would be unable to support uniform stylistic guidelines,
standards for documentation, etc.
The most recent (Forth) software system I have written was used to
do the research for a paper now being published. The system is being
rewritten (by a team headed by my co-author) as part of a package in
Mathematica so that it can be distributed. [The Mathematica version,
incidentally, runs about 50 times slower than the Forth version and
would have been unsuitable for doing the research. It uses results
obtained with the Forth system.]
-------
I have also been involved in teaching and there, too, with the
issue of programming technique.
I have taught Forth as part of a mathematics course. I used the
language in my research for several years before deciding to develop a
course. One of my colleagues had been enjoined from using BASIC in an
introductory course. The wisdom of the experts (summarized by
Dijkstra, I think) is that BASIC warps the minds of students. I felt
it neccessary to be sure that Forth is supportive of what the
literature teaches about programming technique.
An additional connection with programming practices comes through
my wife who teaches the Advanced Placement course in Computer
Programming at a high school. This is a college-level course which
culminates in a nation-wide exam. The computer scientists who write
the exam are quite strict about matters of programming technique --
thus teachers who teach the course must spend considerable time
learning the current wisdom in this area.
As I said (and this is the jist of the remarks made in my
previous article) I believe that the techniques espoused by experts in
Forth are compatible with what experts in computer science regard as
good programming practices. I found Forth supportive of these
techniques even though it is different stylistically from conventional
languages.
Oh yes, I have written some instructional packages that have
been used by students.
(Personally, I don't think whether or not anyone has run the top
level of your application is anywhere near as demanding as whether
or not you can understand and modify your own code 10 years after
you wrote it -- or whether you can be fairly confident that code is
solid enough to be used as part of a published proof.)
> What I'm claiming is ludicrous is the drawing of conclusions
> about how all software ought to be developed on the basis of
> that very limited experience.
I have no reason to believe that a carpenter who spends his days
hammering up drywall on a construction site learns more or less about
what is good carpentry than someone who (by himself) builds a room
addition on his house. I even allow the possibility of insights coming
from someone who does little carpentry himself, but who has spent time
studying the characteristics of various woods and the design of
woodworking tools.
-------------------
I'm not sure what Chuck Eaker is objecting to. I'd like to ask
him to focus on the ideas at issue:
Are you claiming that the Forth language is not supportive of
good programming techniques? If so could you be specific about
your objections.
In my article I cited Thinking Forth. Is there something in this
book that you feel is objectionable in terms of the treatment of
style and good programming technique?
Is there something about the Forth language that you feel would
make it only suitable for people who write programs for their
own use? If so, be specific.
-------------------
For the record, I have never made claims about the suitability
of Forth for large scale, multi-programmer projects. I have no
reason to believe it would not be viable. I simply don't know
(and, in some sense don't care).
What I tried to point out (apparently with no success) is that
a lot of significant programming is not of the large-scale, multi-
programmer variety.
Whether or not a language would suit the needs of the Defense
Department is irrelevant to whether or not it is useful to people
who design and implement their own software as part of their
job.
> And while I'm at it, I might as well point out that I believe
> the claim that an individual can do with Forth what would require
> a team in a conventional language is also ludicrous.
You may be shooting from the hip if you think you are addressing
what I said. Here is what I actually said:
+ I use Forth because, as some comparison shopping has disclosed, I
+ can do as an individual what would indeed require a team using a
+ more conventional language.
When I started my work I did develop a set of specifications for
the computing environment I felt I would need -- and I did check to
see what would be involved in producing such an environment using
conventional compiled languages. I stand by the statement I actually
made.
--------------------
What I think is preposterious is that people who have only dabbled a
bit with Forth feel themselves in a position to issue ex cathedra
pronouncements about it.
I'm a bit more tolerant of people who have genuine grounds for
enthusiasm but tend to get carried away.
I'm ambivalent about people who use hype to sell us things.
Chuck Eaker
|> I find a recent article by Chuck Eaker rather mysterious. He wrote
|> an article taking the position that good programming technique is the
|> major factor in producing solid code. My article, in response,
|> supported his position with some anecdotes from a course in Forth. I
|> made the point that the programming practices advanced by experts in
|> Forth style are compatible with what is taught about programming
|> practices in beginning courses using other languages. I assume he is
|> taking issue with the claim that Forth supports good programming
|> techniques -- but his reply seems to be more directed at who is
|> allowed to express an opinion about this matter.
|>
|> I must apologize for the autobiographical flavor of this article.
|> It is the only way I could think of to clarify the role of good
|> programming practices in the production of research software -- and
|> to respond to Eaker's statements directed at me personally.
|>
|> Chuck Eaker, ostensibly replying to me, writes:
|>
|> > I interpret your remarks as saying that your experiences with
|> > Forth are working alone producing software that only you use.
|>
My remark was not intended as an assessment of the quality or
importance of your software development experiences. The remainder of
your post indicates that the skill and care you apply to software is as
disciplined and thoughtful as the attention applied to your postings.
Instead, I was commenting on the breadth of your experience, and your
autobiography indicates that it does not include working with customers
other than yourself, working in teams large and small, leadership of
teams large and small, dealing with beta testers, and keeping content a
sophisticated and demanding user community over many years.
My point is simply that the experience you do have does not generalize
well to the areas you haven't seen. I agree that Forth is a wonderfully
enabling environment for a single researcher. I agree that the coding
practices advocated by the Forth community (e.g. *Thinking Forth*)
should be practiced throughout the industry. But there is more to
software development than coding practices or the factoring behind
them. And I don't think Forth is more likely than any other language to
encourage best software engineering practices. Good people do good work
alone or in teams no matter what programming language they use. The
choice of a language is largely based on what a person or a team thinks
will make them most productive in achieving their goals. This appears
to be why you use Forth. It is also why I use it when I need to do quick
experiments to find out how somebody else's software works.
I spent 20 years as a faculty member (some of them in a computer
science department) and advocated and taught Forth for several of
them. I'm now a computer scientist at GE's Corporate Research &
Development Center. It's a whole different world out here.
|> An entire research application is often too specialized to be
|> distributed as a whole. If it can be written in a modular fashion,
|> it would be possible to distribute a package of generally useful
|> procedures developed as part of its production. This has not happened
|> in my case mainly due to the Forth community's abandonment of the
|> language's potential for portability and the attendant decline in the
|> language's popularity. There is no reason other than this that
|> research packages written in Forth could not be distributed and used
|> by others in the same way that research packages written in
|> Mathematica or Maple are currently being distributed. (Each of these
|> systems has a refereed library of software submitted by users. The
|> packages in these libraries will run unaltered on a wide variety of
|> platforms.) There is no reason to believe that the Forth language
|> itself would be unable to support uniform stylistic guidelines,
|> standards for documentation, etc.
I think the major impediment to distributing Forth libraries is that
the Forth philosophy has discouraged it. There is no standard word set
(de facto or de jure) that supports linking to a library in object code
form. The only generally available way to use a Forth library is to
load the source. This, of course, doesn't work. It often doesn't work
with other languages. The new standard should help some, but library
suppliers will not beat a path to our door to give us their source
code. Nor does it help us use libraries such as Win32, Motif or CPLEX
(a commercial linear programming package.) Lack of standard words to
support external linking to libraries from Forth applications and
external linking from other applications to Forth written libraries
will continue to be a major impediment to the growth of Forth.
|> > What I'm claiming is ludicrous is the drawing of conclusions
|> > about how all software ought to be developed on the basis of
|> > that very limited experience.
|>
|> I have no reason to believe that a carpenter who spends his days
|> hammering up drywall on a construction site learns more or less about
|> what is good carpentry than someone who (by himself) builds a room
|> addition on his house. I even allow the possibility of insights coming
|> from someone who does little carpentry himself, but who has spent time
|> studying the characteristics of various woods and the design of
|> woodworking tools.
Building a software product is more like building a house. To build
a house you need far more than the skills of a good carpenter. To build
a software product you need more than the skills of a good programmer.
|> Are you claiming that the Forth language is not supportive of
|> good programming techniques? If so could you be specific about
|> your objections.
No. I believe it is neither more nor less supportive than other
languages. Furthermore, my original claim was intended to cover
the entire software engineering process, not just coding.
|>
|> In my article I cited Thinking Forth. Is there something in this
|> book that you feel is objectionable in terms of the treatment of
|> style and good programming technique?
It's an excellent book. The only thing objectionable about it is that
my name is misspelled ... twice. (Not to mention, of course, Leo's
inability to fully appreciate my major contribution to Forth :-)
|>
|> Is there something about the Forth language that you feel would
|> make it only suitable for people who write programs for their
|> own use? If so, be specific.
|>
It is not as convenient as other languages primarily because of the
lack of conventional support for object code libraries. Choosing
a good configuration management system is far more important for
large projects than choosing a language.
|>
|> > And while I'm at it, I might as well point out that I believe
|> > the claim that an individual can do with Forth what would require
|> > a team in a conventional language is also ludicrous.
|>
|> You may be shooting from the hip if you think you are addressing
|> what I said. Here is what I actually said:
|>
|> + I use Forth because, as some comparison shopping has disclosed, I
|> + can do as an individual what would indeed require a team using a
|> + more conventional language.
|>
|> When I started my work I did develop a set of specifications for
|> the computing environment I felt I would need -- and I did check to
|> see what would be involved in producing such an environment using
|> conventional compiled languages. I stand by the statement I actually
|> made.
|>
I mistakenly interpreted your statement as a generalization about all
software developers and all projects. I apologize.
|>
|> What I think is preposterious is that people who have only dabbled a
|> bit with Forth feel themselves in a position to issue ex cathedra
|> pronouncements about it.
I agree, but I am not a dabbler. I originated the CASE syntax that is
now part of the standard (see pp. 239-240 of *Thinking Forth* for the
reasons many people think it shouldn't be). I have used Forth since
1978. I have written several Forth implementations that were sold
commercially for many years. I was heavily involved in an assembly
line automation project which used Forth. The last I heard, it had been
running for 5 years without any software maintenance other than
replacing a disk driver because of a hardware failure on a board from a
defunct company. I still use a home-grown implementation that suits my
needs almost daily. And check out the Forth entry in the *Encyclopedia
of Computer Science*. (Geez! Talk about shooting from the hip! :-)
I think we agree. You are recommending the coding and factoring
practices described in *Thinking Forth*. I agree. I believe large,
commercial software projects need be concerned with additional
issues such as coordinating the efforts of many people and
testing procedures. What you said about this is:
|> For the record, I have never made claims about the suitability
|> of Forth for large scale, multi-programmer projects. I have no
|> reason to believe it would not be viable. I simply don't know
|> (and, in some sense don't care).
To be perfectly honest, I've lost track of the claim I thought you
made. So I'll just shut up.
Darin Johnson
> of screens, parameter passing in the stack, and the interactive nature
> of the language encourage the development of a large application by
> using a hierarchical collection of small, well-named, well-tested, and
> well-factored components.
The screens? The only advantage here is forcing you to be small. But
it also encourages bin packing (shoving those unrelated one liners
together on the same screen), needless separation (those two related
10-liners that had to be split), and angst (when you have a 17-liner
that can't be split without making it look completely stupid).
There's no need any more for archaic environments that force you to
learn and use someone elses favorite editor. There are other ways to
encourage small words (nazi TA's). Then look at MUMPS; it has nasty
procedure size maximums, but instead of nice factoring most end up
with a lot of "foo_part1 foo_part2 foo_part3 foo_part4 ..." style
of division (ie, split things up every x lines).
Parameter passing on the stack I sort of consider neutral. It's got
plusses, but a lot of drawbacks as well. If you forget a parameter
you have to deal with a runtime error instead of a compile time
warning. Reading code written by someone else requires a lot of
page/screen-flipping to find out what stack values go with what word.
And other things done implicitly in lots of other languages. It also
encourages small definitions, otherwise you go bonkers trying to
figure out what's on the stack at any time - other languages can get
much longer before reaching incomprehensible stage. Of course, many
comment nicely what the stack is doing at each step, something else
done implicitly in other languages.
(I'm not saying Forth is bad here, I think it's great. But this
thread deals with preposterous boasting and people that think
Forth is flawless. Enough people mention the things that are
right about it :-)
Interactive - Great! Students need that sort of stuff, if at the
very least to serve as a convenient tool (you can write throw away
code quickly, whereas an edit-compile-run cycle would discourage
that type of programming).
> Someone replied: "Forth doesn't need a
> symbolic debugger -- Forth *is* a symbolic debugger". And so it is,
> if an application is built (in the Forth style) from small, well-
> factored definitions.
I'll have to disagree here. I associate symbolic debugging with
breakpoints, tracing, and so forth; not just interpretive eval
of expressions and so forth. How do you stop execution at a
certain point without a breakpoint without manually executing
all the stuff that comes first? Granted, interpretive languages
are much nicer in this regard to other languages, especially
once you reach a breakpoint.
> > It is ludicrous for the members of the Forth community to
> > continue to generalize about what yields a good software system
> > based on their experiences of working alone with Forth.
> I think a good claim can be made that Forth has
> properties that make it well-suited for producing systems of the kind
> I (and others like me) produce.
That's the rub. The key word above (I think) was "generalize".
Many people say "well suited for producing systems of the
kind *you* produce." Big difference. So you're right, and he's
right.
But that's not the fault of Forth or it's users really -
overgeneralization is a major fault for almost every language,
user, and paradigm. (am I overgeneralizing here? :-)
--
So, as an aside. It's been said you sing in your math classes.an aside. It's been said you sing in your math classes.
Do you do so in your Forth classes as well? ;-)
--
Darin Johnson
djoh...@ucsd.edu
Erather
know zip about Amigas, I've been doing multitasking in Forth for 20+
years & have $.02 to contribute.
The earliest Forths developed by Moore included sophisticated, very
fast multitasking. For example, handling telescope control, data
taking at kHz rates, graphical analysis, real-time displays and
multiple operators on terminals, all concurrently without
interference, on early computers that made an Apple ][ look like a
mainframe.
He used a very simple, efficient non-preemptive algorithm that took
full advantage of the fact that in real-time applications most tasks
are waiting for I/O most of the time, and the intervening cycles are
available.
Descendents of his multitasking schemes are featured in all our
products, and have been used in some very demanding applications,
ranging from high-sped data transfers running concurrently with
extensive operator interaction, to industrial process control systems
running whole plants, to data base applications with literally
hundreds of users accessing a data base on a 386 PC.
Discussions of including multitasking in ANS Forth bogged down when
it became apparent that the folks doing serious performance-critical
multitasking had very different goals, needs and tools from those
wanting a "simple, high-level model". Not to mention the need of
folks supporting many client systems in the field for not forcing
them to choose between the pariah state of "non-standard
multitasking" and unacceptable performance.
Cheers...
Elizabeth
Raul Deluth Miller
. Discussions of including multitasking in ANS Forth bogged down when
. it became apparent that the folks doing serious
. performance-critical multitasking had very different goals, needs
. and tools from those wanting a "simple, high-level model".
Hmm.. wasn't there a similar issue when it came to file handling?
First off, let me point out a bit of mach terminology [this is from
memory, but it should be generally in the right ball park]:
a "task" is a thing that has resources [memory, etc.]. It doesn't do
anything in and of itself. Memory is usually managed in large chunks
["pages"], and the kernel is free to round requests up to the
appropriate page boundary.
a "thread" is a thing that has flow of control. Threads may be
implemented using any of a variety of methods.
Then you have premptive [interrupt driven] and non-premptive [pure
flow of control] multi-tasking mechanisms.
Did I miss anything?
Raul D. Miller
<rock...@nova.umd.edu>
Loring Craymer
|> Elizabeth Rather:
|> . Discussions of including multitasking in ANS Forth bogged down when
|> . it became apparent that the folks doing serious
|> . performance-critical multitasking had very different goals, needs
|> . and tools from those wanting a "simple, high-level model".
|>
|> Hmm.. wasn't there a similar issue when it came to file handling?
Yes, but file management is a much simpler problem. The controversy which
was dealt with was between the traditional BLOCK-based approach (which is
better for serious data management) and stream files (much preferred for
text management. The rest of the (non-DBMS) world is heavily stream oriented
(UNIX lives) and stream files had managed a significant toehold among the
Forth community, and so we were "forced" to include them. Once that decision
was reached, the only real issue was whether to support buffered or unbuffered
I/O, and buffered (READ-LINE forces buffered I/O) easily won. However, it may
be noted that ANS Forth does not have anywhere near the control over buffered
I/O that C has.
|> First off, let me point out a bit of mach terminology [this is from
|> memory, but it should be generally in the right ball park]:
|>
|> a "task" is a thing that has resources [memory, etc.]. It doesn't do
|> anything in and of itself. Memory is usually managed in large chunks
|> ["pages"], and the kernel is free to round requests up to the
|> appropriate page boundary.
|>
|> a "thread" is a thing that has flow of control. Threads may be
|> implemented using any of a variety of methods.
|>
|> Then you have premptive [interrupt driven] and non-premptive [pure
|> flow of control] multi-tasking mechanisms.
|>
|> Did I miss anything?
Yeah--resource management. Even the set of facilities that you mention would
require a large wordset to begin to cover them. Then you have to add semaphores,
mutexes, inter-task/thread communications, and so on. And, by the way,
traditional Forth I/O is geared towards cooperative (non-preemptive)
multitasking; there is experience in the community with preemptive multitasking,
and there is a clear trend in OS development towards providing preemptive
multithreading, but there is no clear common practice in the Forth community. It
is worth pointing out that there was no opposition in the TC to developing a wordset
for multitasking, but we couldn't quite do it. If you want a fair estimate of
the effort required, try counting the number of words in the FLOATING and
FLOATING EXTENSIONS wordsets--the count for a multitasking wordset would have been
as high and would not have been built on as solid an experience base within the
Forth community.
|> Raul D. Miller
|> <rock...@nova.umd.edu>
Loring Craymer