Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))

38 views
Skip to first unread message

Michael Coughlin

unread,
Aug 28, 2001, 6:56:52 PM8/28/01
to
Erann Gat wrote:
>
> Colin_Pau...@ACM.org (Colin Paul Gloster) wrote in
> message
> news:<slrn9okgjm.gd6.C...@camac.dcu.ie>...
> > In article > <1f4c5c5c.01082...@posting.google.com>,
> > Erann Gat wrote about numerous interesting space-related
> > projects, including:
> >
> > "[..]
> >
> > In 1994 I used Lisp to produce a code patch for an
> > instrument on the Galileo spacecraft in orbit around
> > Jupiter. The instrument (a magnetometer) was programmed
> > in Forth, and had developed a bad memory byte (out of a
> > total 4k bytes of memory). It was estimated that to
> > patch the Forth code (which is notoriously difficult to
> > maintain) would take so long that it was not feasable."
> >
> > I do not understand this. Why was this Forth source
> > code so hard to maintain?
>
> Forth code in general is pretty notorious for being hard
> to maintain, and this forth code in particular was hard to
> maintain because it was generated by a development
> environment that ran only on an Apple II, which was about
> 15 years obsolete by the time this problem arose.
> Also, Forth programmers are almost as hard to find as Lisp
> programmers.
>
> > "I wrote a customized Forth development environment in
> > Lisp that was used to produce a code patch. The total
> > time it took to produce the development environment
> > and the code patch was three months. (The resulting patch
> > is flying today. It's the only thing this development
> > environment was ever used for.)
> >
> > [..]"
> >
> > So was your one-off Forth system superior to the one
> > used earlier?
>
> I never actually got to use the original system (since as
> noted above it only ran on an Apple II, which I did not
> have at my disposal) so I can't say. My system was not a
> complete implementation of Forth, just enough to recompile
> the code that ran on the instrument. On the other hand,
> my system let you write Forth in Lisp sytax, which means
> you could use Lisp macros to write Forth. That's something
> I'm fairly certain the original system didn't let you do.

I've cross posted this to comp.lang.forth since Forth
programmers will want to read and comment on it. You are right.
Forth programs are "pretty notorious for being hard to
maintain". This is not the fault of the Forth language. It is
the fault of Forth programmers and the people who hire them. You
indicate the reason very clearly when you state "Forth
programmers are almost as hard to find as Lisp programmers", so
when an old Forth program needs to be updated, all heck breaks
loose, since there is usually nobody around who knows how to
program in Forth. This particular problem with a Forth program
was solved by someone who programmed in Lisp. Perhaps being a
user of Lisp indicates an interest in a variety of languages so
you got the job that the other programmers who only knew popular
languages wouldn't touch.

Forth could be very easy to read and maintain if Forth
programmers would realize it takes much extra effort to comment
and document it properly. And by that I mean write so the code
can be read by managers (even if they didn't want to). When I
suggest such things to Forth programmers, they reject the idea
for reasons that I will not repeat here. I want managers to use
Forth and not shudder in terror when it is mentioned.

I would be interested to know how Lisp programmers write
code that other programmers can read. When I look at Lisp it
makes no sense to me, particularly the parts with all the
parentheses. Forth code does make sense, but I still can't know
what a Forth program does when things that are obvious to the
original programmer are not written down.

--
Michael Coughlin m-cou...@ne.mediaone.net Cambridge, MA USA

Elizabeth D. Rather

unread,
Aug 28, 2001, 8:16:13 PM8/28/01
to
Michael Coughlin wrote:

> Erann Gat wrote:
> > > I do not understand this. Why was this Forth source
> > > code so hard to maintain?
> >
> > Forth code in general is pretty notorious for being hard
> > to maintain, and this forth code in particular was hard to
> > maintain because it was generated by a development
> > environment that ran only on an Apple II, which was about
> > 15 years obsolete by the time this problem arose.
> > Also, Forth programmers are almost as hard to find as Lisp
> > programmers.
> >

> > > [..]"


> > >
>
> I've cross posted this to comp.lang.forth since Forth
> programmers will want to read and comment on it. You are right.
> Forth programs are "pretty notorious for being hard to
> maintain". This is not the fault of the Forth language. It is
> the fault of Forth programmers and the people who hire them. You
> indicate the reason very clearly when you state "Forth
> programmers are almost as hard to find as Lisp programmers", so
> when an old Forth program needs to be updated, all heck breaks
> loose, since there is usually nobody around who knows how to
> program in Forth. This particular problem with a Forth program
> was solved by someone who programmed in Lisp. Perhaps being a
> user of Lisp indicates an interest in a variety of languages so
> you got the job that the other programmers who only knew popular
> languages wouldn't touch.

Having been writing and maintaining Forth programs (and supporting
customers doing the same) for 30 years, I must say it's definitely
_not_ been our experience that Forth is hard to maintain. For
example, we have a current customer in San Francisco running
a very complex Forth database application originally written in
1977 on a PDP-11. It's since been ported to several newer
architectures and modified a lot, all by engineers who were not
involved in the original project.

Also, nowadays, Forth programmers aren't hard to find: just ask
your favorite search engine for "Forth". But they may not live
next door...

> Forth could be very easy to read and maintain if Forth
> programmers would realize it takes much extra effort to comment
> and document it properly. And by that I mean write so the code
> can be read by managers (even if they didn't want to). When I
> suggest such things to Forth programmers, they reject the idea
> for reasons that I will not repeat here. I want managers to use
> Forth and not shudder in terror when it is mentioned.

It is perfectly possible to write Forth code that can be read
and maintained by anyone familiar with Forth (managers
included). It's pretty hard to write code, particularly complex
code, in any language that can be maintained by someone
unfamiliar with that language, beyond the simplest management
of configuration constants and the like. Do you folks write
Lisp in such a way that a person who has never learned Lisp
can maintain it?

> I would be interested to know how Lisp programmers write
> code that other programmers can read. When I look at Lisp it
> makes no sense to me, particularly the parts with all the
> parentheses. Forth code does make sense, but I still can't know
> what a Forth program does when things that are obvious to the
> original programmer are not written down.

Yes, programmers should certainly document what they're
doing and why, even for themselves (folks do forget things).
But that's not a need peculiar to any language more than any
other.

Cheers,
Elizabeth

--
================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
================================================


Kaz Kylheku

unread,
Aug 28, 2001, 9:27:55 PM8/28/01
to
In article <3B8C20A6...@ne.mediaone.net>, Michael Coughlin wrote:
> I've cross posted this to comp.lang.forth since Forth
>programmers will want to read and comment on it. You are right.
>Forth programs are "pretty notorious for being hard to
>maintain". This is not the fault of the Forth language. It is
>the fault of Forth programmers and the people who hire them. You

You are generalizing about Forth programmers, and crossposting
to comp.lang.forth. That makes you a troll.

I found Erann Gat's account of the various past projects involving Lisp
quite interesting. Now I think this is going to devolve into some kind
of stupid flamewar between two comp.lang.* newsgroups.

> Forth could be very easy to read and maintain if Forth
>programmers would realize it takes much extra effort to comment
>and document it properly. And by that I mean write so the code
>can be read by managers (even if they didn't want to). When I
>suggest such things to Forth programmers, they reject the idea
>for reasons that I will not repeat here.

Which Forth programmers, where? Are they a sufficiently large,
unbiased, random sample of Forth programmers from which some
statistical inferences can be made about the entire population
of Forth programmers?

Don

unread,
Aug 29, 2001, 1:01:03 AM8/29/01
to
Michael Coughlin <m-cou...@ne.mediaone.net> wrote in message news:<3B8C20A6...@ne.mediaone.net>...
<big snip>>
> Forth could be very easy to read and maintain if Forth
> programmers would realize it takes much extra effort to comment
> and document it properly. And by that I mean write so the code
> can be read by managers (even if they didn't want to). When I
> suggest such things to Forth programmers, they reject the idea
> for reasons that I will not repeat here. I want managers to use
> Forth and not shudder in terror when it is mentioned.
>
Bravo!

Both aplications programmers & some vendors in the past have relied on
the IMHO mistaken tenet that well written forth 'prose' is self
documenting.

The ability to create new application specific lexicons with the
create/does feature & friends allows the resultant code to become very
legible at the time of writing but largely unintelligible later on
when the 'application specific mindset' is no longer present to
interpret the code. At this point you find yourself continually
wandering back to locate all sorts of 'clever' words to try to work
out what the heck is going on. Aruably this could be said to be
similar in tracing back C functions.

My experience is based on the following scenario which I suspect is
shared by many others.
1. A product is designed by myself and/or others.
2. It is installed & commissioned & we don't see it again for ages
beyond possible annual service checks. We go & do a million & one
other things, a small portion of which is actually writing code.
3. 5 years later it requires changes or decides to do something
bizarre.
4. At 2am in the morning when the line stops someone has to bounce out
& implement & test the changes/fix.

Having to go back & analyse the entire app to try to 'regain the
mindset' to attempt to find out what the heck is happening is not a
wonderful economic strategy. When the Author was 'Clever' and lacking
in the desire to document then the App may be in for a re-write. Oh
while we are at it let's do it in C so we don't get caught again... (
The best description I have heard of poorly written 'clever' C is ->
Line Noise ;-)

It takes but a moment to explain what your little gem does as at the
time it is written << regardless of how obvious it is at the time >>.
Keeping all of this together with an accurate & up to date user manual
is a fair bit more of a challenge & the results are disasterous if the
two are out of sync.

Stephen Pelc at MPE has helped address this at MPE with DOCGEN in a
commercial product but my favourite in the 'future direction' area is
the work done by Charles Esson with ColdForth which uses html as the
native source format thus allowing embedded diagrams & a general style
similar to that proposed by the Literate Programming Community with
source interspersed amongst text delimited by tags. Another similar
direction was the use of xml by KForth ( I think thats it )as a native
source format.

This direction appeals to me as it addresses the documentation
synchronisation issue and allows the use of embedded diagrams for
state diagrams and the like. I won't even go down the track of the
state chart generating the code ;-)

As both a Forth programmer & a PHB I feel that there is way too little
available up-to-date documentation available to enable us to
efficiently train up new programmers in-house. We own just about
every book ever written on the subject but find that they fall short
in explaining the black art issues of forth that really make it useful
to a commercial programmer( read-> little spare time to go fishing
about for dribs & drabs on the net). Flying Staff over to the States
for a course doesn't count.

This issue spills over to the clf news group too, as most outsiders
think that this group is indicative of the Forth Community. Most code
posted is sparsely, if at all, commented. While people may just wish
to toss ideas back & forth to those in the know, it effectively boxes
out the newcomers. This may not appear a problem to those in academia
who may be comfortable with it left as "an exercise for the reader".
For the rest ( possible Commercial Forth Users ) it merely confirms
their preconcieved notion that forth is unintelligible drivel and they
happily go back to the safety of C. Jack proceeds to say nasty things
about us in his column, old programmers fade away & kids go to Java.

My Company is in the fortunate position to be able to dictate the
development system in most cases hence we use Forth as much as
possible but there are days when we look enviously over the fence at
some of the great toys available to C programmers ( some might say
they need all the help they can get ;-), so much so that some of our
embedded work is done in C to be able to link in libraries.

As a simple example of a beef - A standard, simple, String library
suitable for use in an embedded environment. I mention this as most
Associates who have looked at forth have come back with this one &
tend to simply go away when you say that you have to build your own...

Winge complete... Back to lurk mode again for the rest of the year

Cheers

Don Ingram

Bernd Paysan

unread,
Aug 29, 2001, 8:19:17 AM8/29/01
to
Don wrote:
> The ability to create new application specific lexicons with the
> create/does feature & friends allows the resultant code to become very
> legible at the time of writing but largely unintelligible later on
> when the 'application specific mindset' is no longer present to
> interpret the code. At this point you find yourself continually
> wandering back to locate all sorts of 'clever' words to try to work
> out what the heck is going on. Aruably this could be said to be
> similar in tracing back C functions.

That reminds me of a critic on Forth from my spaghetti-code writing
coworker. He said that Forth is completely uncomprehensible, because
Forth programs are nested functions in nested functions. He rarely nests
functions deeper than 2, and documents the goto-ladden spaghetti code
with spaghetty diagrams (flowcharts). IMHO those flow-charts are even
less readable than his code.

Also, those clever words that implement the foundation of a program
*should* be written in a way that makes the higher-level more readable.
That's possible, even possible beyond what many other languages can
achieve. After all, what you write should be a problem-specific
language, and should be designed for that.

The main issue I see from Michael Coughlin is that Forth by itself can
not be readable, only the comments can. You say more or less the same.
I've seen more and less readable Forth. The more readable Forth is the
one of short definitions with names that say what they do, and clearly
created application specific languages. The less readable Forth is the
one with long definitions, deeply nested control structures and so on,
that also have obscure names, and aren't used as application language,
but as functions like in C. Those programs probably stay unmaintainable
even if they have loads of comments, UML diagrams and so on.

> Having to go back & analyse the entire app to try to 'regain the
> mindset' to attempt to find out what the heck is happening is not a
> wonderful economic strategy.

Might not look like that, but fixing an app in one point without a real
understanding what is happening (and that's something no comment can
help you) is going to ruin many program. Not because they are badly
written, or badly documented, but because the mere idea that poking
around half-witted is flawed.

Readability has two sides: the one of the writer to express himself
clearly, and the literacy of the reader. As a minority language,
literacy of the reader is often poor (not only doesn't he understand the
language, but also has difficulties with the style). Also, the concept
of readable Forth programs is alien to less experienced writers, who
just adopt the style of other programming languages.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

Guido Draheim

unread,
Aug 29, 2001, 9:18:29 AM8/29/01
to
Bernd Paysan wrote:
>
> Readability has two sides: the one of the writer to express himself
> clearly, and the literacy of the reader. As a minority language,
> literacy of the reader is often poor (not only doesn't he understand the
> language, but also has difficulties with the style). Also, the concept
> of readable Forth programs is alien to less experienced writers, who
> just adopt the style of other programming languages.
>
that's it! exactly!

counterpoint: it is no wonder that most younger languages (like java
or perl or php) have adopted the look of another widespread language
being around - while those with peculiar style (like python) have
created another barrier to entrance, sometimes without need. And there
are really portions in forth that would have had no specific need to
be just different - e.g. the outer interpreter could be easily adapted
to understand string-literals just so, and adding backslash-escape
is not problematic either - one of the highest FAQ from developers
around is "how do I put a doublequote into a string-literal". I could
explain to them why this implementation-decision was made (WORD
parses to HERE and we move DP up) but that's not making their live
easier to get along with forth.

So, yes, sometimes forth is different, and that's good choice, but
sometimes it is not. Simply as that.

cheers,
-- guido Edel sei der Mensch, hilfreich und gut
GCS/E/S/P C++$++++ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode)

Stephen Pelc

unread,
Aug 29, 2001, 8:56:58 AM8/29/01
to comp.lang.lisp, comp.lang.forth
On Tue, 28 Aug 2001 22:56:52 GMT, Michael Coughlin
<m-cou...@ne.mediaone.net> wrote:
> Forth could be very easy to read and maintain if Forth
>programmers would realize it takes much extra effort to comment
>and document it properly. And by that I mean write so the code
>can be read by managers (even if they didn't want to).
You could easily remove "Forth" from this and substitute
the name of some other language. Regardless of language,
writing for maintenance is a matter of management and
corporate culture.

Over the last three years we have switched over to a tool
chain (Forth) which extracts documentation as formal
comments from the source code and then generates HTML
and/or PDF manuals. The effect of this has been to
encourage our own programmers and our clients to write
the documentation as the code is written.

When we looked at literate programming tools some years
ago, the problem was that the source for the compiler and
the documentation could get out of step. In our system there
is only ever one file, and the documentation is contained
within formal comments.

Again, documentation and maintainability are NOT a language
issue.

Stephen
--
Stephen Pelc, s...@mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads

Kurt B. Kaiser

unread,
Aug 29, 2001, 12:15:41 PM8/29/01
to
Michael Coughlin wrote:
> I've cross posted this to comp.lang.forth since Forth
> programmers will want to read and comment on it. You are right.
> Forth programs are "pretty notorious for being hard to
> maintain". This is not the fault of the Forth language.

Troll!!

Actually, it _is_ the fault of the Forth language. The parameters for the
functions come in anonymously and also must be accessed using stack
manipulation commands. This can result in incomprehensible code in the hands of
a novice. These anonymous parameters are also the key to legibility in properly
written Forth. I've struggled with this for years. It seems the answer lies in
factoring. Forth is a very sharp tool and should labelled, "experts only."

> It is
> the fault of Forth programmers and the people who hire them. You
> indicate the reason very clearly when you state "Forth
> programmers are almost as hard to find as Lisp programmers", so
> when an old Forth program needs to be updated, all heck breaks
> loose, since there is usually nobody around who knows how to
> program in Forth.

Or Lisp, Eiffel, Ada, Cobol, ML, Assembler, or anything else besides C and VB.
But they aren't hard to find.

> This particular problem with a Forth program
> was solved by someone who programmed in Lisp. Perhaps being a
> user of Lisp indicates an interest in a variety of languages so
> you got the job that the other programmers who only knew popular
> languages wouldn't touch.

IMO, the guy wanted to do a clever hack: write Forth in Lisp. Obviously the
source was available; the question is whether the development environment was.
It's certainly no problem to come up with an Apple II. Not maintaining the
development environment for code running on a live satellite strains
credulity. Since Forth is ideally suited to arranging the in-memory image
exactly as the developer wishes, it's no problem to work around a bad byte, and
the fix should have taken a day or so, not three months.

> Forth could be very easy to read and maintain if Forth
> programmers would realize it takes much extra effort to comment
> and document it properly. And by that I mean write so the code
> can be read by managers (even if they didn't want to).

> When I
> suggest such things to Forth programmers, they reject the idea
> for reasons that I will not repeat here.

Why not?

<snip>


> I would be interested to know how Lisp programmers write
> code that other programmers can read. When I look at Lisp it
> makes no sense to me, particularly the parts with all the
> parentheses.

If so, I doubt you have spent more than two hours making a fair effort to learn
Lisp. Any language can be used to write terrible code, vs. the obfuscated code
contests. IMO, well written Lisp is the most legible of all programming
languages. I've seen descriptions of satellite communication systems presented
in conference viewfoils using Lisp which were more effective than block
diagrams. The design just jumped off the page at you!

Lisp is always developed with an editor which indents the code to display its
structure. The parentheses tend to 'disappear' when you read the code; you are
only concerned with perhaps two sets at a time, about the same as C code, and
for the same reasons.

> Forth code does make sense, but I still can't know
> what a Forth program does when things that are obvious to the
> original programmer are not written down.

This is always true, and in any language. "Written down" includes descriptive
choices for names of data and functions. If these choices are done well and
the code is properly factored, only minimal comments are necessary, usually to
describe the top level design.

Try writing code using two character names and no comments. Even better, lose
the source and work from the disassembly! (I had lunch with an engineering
manager who did exactly that on an instrument which was in production. They had
to disassemble the ROM.)

Regards, KBK

--
K u r t B. K a i s e r
k b k @@ s h o r e .. n e t
------------------------------

Elizabeth D. Rather

unread,
Aug 29, 2001, 1:18:26 PM8/29/01
to
Don wrote:

> My experience is based on the following scenario which I suspect is
> shared by many others.
> 1. A product is designed by myself and/or others.
> 2. It is installed & commissioned & we don't see it again for ages
> beyond possible annual service checks. We go & do a million & one
> other things, a small portion of which is actually writing code.
> 3. 5 years later it requires changes or decides to do something
> bizarre.
> 4. At 2am in the morning when the line stops someone has to bounce out
> & implement & test the changes/fix.

Amusingly enough, we had just such a scenario recently. In the early
90's we installed a production monitoring system in an Owens-Corning
fiberglass plant in Korea. About 3 years ago, we installed a copy of
it in another Owens-Corning plant in Mexico City. Both were written
and installed by an engineer who left us about 18 mos. ago.

In June, the Mexico City plant suffered a disk crash, and were unable
to re-install the software. When attempts to help over long distance
didn't work, it was apparent that we needed to send someone to
Mexico. So we sent an engineer who was familiar with this class of
applications, but who had never seen this particular one. He got them up
and running in a few hours.

We are regularly (few times/year) called upon to fix or modify some
legacy application written in some arbitrary (often one-off) Forth.
Some of these are well-documented, most are not. We are usually
successful.

Gary Chanson

unread,
Aug 29, 2001, 2:11:36 PM8/29/01
to

"Guido Draheim" <guidod...@gmx.de> wrote in message
news:3B8CEBA5...@gmx.de...

>
> counterpoint: it is no wonder that most younger languages (like java
> or perl or php) have adopted the look of another widespread language
> being around - while those with peculiar style (like python) have
> created another barrier to entrance, sometimes without need. And there
> are really portions in forth that would have had no specific need to
> be just different - e.g. the outer interpreter could be easily adapted
> to understand string-literals just so, and adding backslash-escape
> is not problematic either - one of the highest FAQ from developers
> around is "how do I put a doublequote into a string-literal". I could
> explain to them why this implementation-decision was made (WORD
> parses to HERE and we move DP up) but that's not making their live
> easier to get along with forth.

Yes. I do both in my implementations.

--

-GJC
-gcha...@shore.net

-Abolish Public Schools.


Gary Chanson

unread,
Aug 29, 2001, 2:24:31 PM8/29/01
to

"Kurt B. Kaiser" <k...@shore.net> wrote in message
news:3B8D14E1...@shore.net...

>
> Actually, it _is_ the fault of the Forth language. The parameters for the
> functions come in anonymously and also must be accessed using stack
> manipulation commands. This can result in incomprehensible code in the
hands of
> a novice. These anonymous parameters are also the key to legibility in
properly
> written Forth. I've struggled with this for years. It seems the answer
lies in
> factoring. Forth is a very sharp tool and should labelled, "experts only."

Yes! Factoring is the key. If words typically take one or two
parameters, as stack comment is sufficient to identify parameters and it's
easy to track them thru the definitions. It also helps if the stack depth
changes as little as practical within the definition.

Bill Zimmerly

unread,
Aug 29, 2001, 3:05:29 PM8/29/01
to
"Kurt B. Kaiser" <k...@shore.net> wrote in message
news:3B8D14E1...@shore.net...
> Michael Coughlin wrote:
> > I've cross posted this to comp.lang.forth since Forth
> > programmers will want to read and comment on it. You are right.
> > Forth programs are "pretty notorious for being hard to
> > maintain". This is not the fault of the Forth language.
>
> Troll!!
>
> Actually, it _is_ the fault of the Forth language. The parameters for the
> functions come in anonymously and also must be accessed using stack
> manipulation commands. This can result in incomprehensible code in the
hands of
> a novice. These anonymous parameters are also the key to legibility in
properly
> written Forth. I've struggled with this for years. It seems the answer
lies in
> factoring. Forth is a very sharp tool and should labelled, "experts only."
> [Snip]

[Warning ... rant follows...]

With freedom comes responsibility. This is why adults rush in and take
pointy things away from toddlers.

What company would hire an unproven rookie for a mid-or-upper management
position with great responsibility?

Whether we like it or not, the business world does this on a regular basis
when "Computer Programmer" is the job title. Is it any wonder that IT
departments
operate in "crisis mode" so much?

This - more than any other reason - is why the "straight jacket" languages
are
preferable in business. (To the detriment of the Art of Computer Science
in my opinion.)

--
- Bill Zimmerly, http://www.zimmerly.com
"Reasonable people adapt themselves to the world. Unreasonable people
attempt to
adapt the world to themselves. All progress, therefore, depends on
unreasonable
people." - George Bernard Shaw

Gary Chanson

unread,
Aug 29, 2001, 5:00:45 PM8/29/01
to

"Bill Zimmerly" <bi...@zimmerly.com> wrote in message
news:Z1bj7.480$ck.2...@sjc-read.news.verio.net...

>
> With freedom comes responsibility. This is why adults rush in and take
> pointy things away from toddlers.
>
> What company would hire an unproven rookie for a mid-or-upper management
> position with great responsibility?
>
> Whether we like it or not, the business world does this on a regular basis
> when "Computer Programmer" is the job title. Is it any wonder that IT
> departments
> operate in "crisis mode" so much?
>
> This - more than any other reason - is why the "straight jacket" languages
> are
> preferable in business. (To the detriment of the Art of Computer Science
> in my opinion.)

Very true. The prevalent business model is to promote your best
engineers (software and hardware) into management positions. In most
companies, there is no other path for promotions. The result is the worst
managers managing the worst engineers. This is one of the main reasons that
I'm self employed.

Michael Coughlin

unread,
Aug 30, 2001, 2:54:19 AM8/30/01
to
Kaz Kylheku wrote:
>
> In article <3B8C20A6...@ne.mediaone.net>, Michael
> Coughlin wrote:

> > I've cross posted this to comp.lang.forth since Forth
> >programmers will want to read and comment on it. You are
> >right. Forth programs are "pretty notorious for being
> >hard to maintain". This is not the fault of the Forth
> >language. It is the fault of Forth programmers and the
> >people who hire them.
>
> You are generalizing about Forth programmers, and
> crossposting to comp.lang.forth. That makes you a troll.
>
> I found Erann Gat's account of the various past projects
> involving Lisp quite interesting. Now I think this is going
> to devolve into some kind of stupid flamewar between two
> comp.lang.* newsgroups.

I also found the account of the project involving Forth and
Lisp to be very interesting. I would like to know more about why
a Lisp programmer would say a Forth program was hard to
maintain. I think Lisp programs would also be hard to maintain.
How does a Lisp programmer make his code easier to maintain than
a Forth programmer?

The original post had some intriguing statements about a
Forth program on a NASA space probe. It was developed on an
Apple II computer with a very old version of Forth. Lisp was
used to modify the original program to correct a hardware
problem. I am very curious as to why Lisp was used when Forth
systems have excellent methods for modifying and correcting
Forth code built right in. Old Forth code from the days of the
Apple II can be maintained with new Forth systems running on the
latest computers. What was the advantage of using Lisp?

Are questions like this trolls?


> > Forth could be very easy to read and maintain if Forth
> >programmers would realize it takes much extra effort to
> >comment and document it properly. And by that I mean write
> >so the code can be read by managers (even if they didn't
> >want to). When I suggest such things to Forth programmers,
> >they reject the idea for reasons that I will not repeat
> >here.

> Which Forth programmers, where? Are they a sufficiently
> large, unbiased, random sample of Forth programmers from
> which some statistical inferences can be made about the
> entire population of Forth programmers?

Nope, my random sample is completely unscientific and
statistically invalid. I just go around to people who have
software projects that could benefit from using Forth and tell
them they should use Forth. Usually they don't know anything
about Forth. When they do, they almost always say Forth is
impossible to maintain. I don't meet any current users of Forth
this way, since the number of people who do use Forth is much
smaller that the number of people who would use it if they knew
what it was and how it could be maintained. I meet more users of
Lisp than Forth in this random way since I live near a large
educational institution that teaches Lisp.

Michael Coughlin

unread,
Aug 30, 2001, 2:56:24 AM8/30/01
to
Forth is code. A code is not supposed to be read. Its as
simple as that. If I say C = 1/2 x A x B, you woun't know what I
mean. If I say the area of a triangle is 1/2 x A x B, or one
half the altitude times the base, you might remember your lesson
from grade school.

The first time I saw the "Hellow World" program in K&R's C
book, I didn't understand it. Then I read the text and found out
it was a program to print out "Hellow World". Once I knew that,
understanding the rest was easy.

Having Forth code well factored with short definitions and
informative names is a good thing. But it is not the first thing
you have to know. You also have to know what is being computed,
how it is being computed, why it is not being computed some
other way, and so on. When you start a program you usually don't
write such things down since that information is either not
decided yet, or fresh in your mind. But I say it should be
written down, and the sooner the better.

> > Having to go back & analyse the entire app to try to
> > 'regain the mindset' to attempt to find out what the
> > heck is happening is not a wonderful economic strategy.
>
> Might not look like that, but fixing an app in one point
> without a real understanding what is happening (and that's
> something no comment can help you) is going to ruin many
> program. Not because they are badly written, or badly
> documented, but because the mere idea that poking
> around half-witted is flawed.

Why can't the comments give you a real understanding about
what is happening? Do you think comments are just for little
parts of the code? Comments should cover everything the next
programmer needs to know, from what is on the stack at any time
to the whole purpose of the program. I don't believe there
should be a separate write-up for a program. It all should be in
the comments. Separate write-ups get lost faster than source
listings.


> Readability has two sides: the one of the writer to
> express himself clearly, and the literacy of the reader.
> As a minority language, literacy of the reader is often
> poor (not only doesn't he understand the language, but also
> has difficulties with the style). Also, the concept of
> readable Forth programs is alien to less experienced
> writers, who just adopt the style of other programming
> languages.

Ok, lets find ways to show new and inexperienced Forth
programmers readable code. If they don't see it, they can't
learn to write it. I'd also love to show all those people who
tell me Forth is a write only language Forth code that they can
read.

Michael Coughlin

unread,
Aug 30, 2001, 2:57:04 AM8/30/01
to

I agree with this. Now the problem is what to do with the
people who have seen Forth in the past and decided that it is
useless because it is unreadable and unmaintainable. Can you
think of a way to show them what good Forth code should look
like?

Incidentally I think Forth code can be made to be clear with
ordinary comments without the complication of generating HTML
and/or PDF manuals. But if your new system gets people to see
Forth code that can be maintained, then that would be a very
good thing.

Bernd Paysan

unread,
Aug 29, 2001, 12:12:09 PM8/29/01
to
Stephen Pelc wrote:
> When we looked at literate programming tools some years
> ago, the problem was that the source for the compiler and
> the documentation could get out of step. In our system there
> is only ever one file, and the documentation is contained
> within formal comments.

I think the "poor man's literate programming tools" for Forth always
provided that (making e.g. \end{verbatim} a comment seeking for
\begin{verbatim}). However, having used a normal literate programming
tool (noweb), my experience is that the work to avoid documentation and
source decoupling is just to set up a make file.

> Again, documentation and maintainability are NOT a language
> issue.

As I wrote, readability for minority languages can be an issue if both
writer and reader don't use the language well. This has nothing to do
with the language, just that you find more people not very fluent in the
language (which makes it less readable to them).

Michael Coughlin

unread,
Aug 30, 2001, 3:09:07 AM8/30/01
to
Kurt B. Kaiser wrote:
>
> Michael Coughlin wrote:
> > I've cross posted this to comp.lang.forth since Forth
> > programmers will want to read and comment on it. You are
> > right. Forth programs are "pretty notorious for being
> > hard to maintain". This is not the fault of the Forth
> > language.
>
> Troll!!
>
> Actually, it _is_ the fault of the Forth language. The
> parameters for the functions come in anonymously and
> also must be accessed using stack manipulation commands.
> This can result in incomprehensible code in the hands of
> a novice. These anonymous parameters are also the key to
> legibility in properly written Forth. I've struggled with
> this for years. It seems the answer lies in factoring.
> Forth is a very sharp tool and should labelled, "experts
> only."

Sure factoring is important. But what do you mean by
"anonymous parameters" ? Make them unanonymous. Label them with
stack comments. Lots of stack comments. Or just a few stack
comments that only tell you exactly what you need to know.
Saying Forth can only be used by experts is not a complement to
Forth. But then again you could say the same thing about writing
technical English -- it should also only be done by experts.
Writing in English can result in incomprehensible prose in the
hands of a novice. When an uninitiated computerist says Forth is
a write only language he is saying he only sees Forth code
written by non-experts. The code might run fast, give the right
answer, and use little memory. But the programmer was not expert
enough to do the whole job.

Yes, that whole story is really strange.

> > Forth could be very easy to read and maintain if Forth
> > programmers would realize it takes much extra effort to
> > comment and document it properly. And by that I mean
> > write so the code can be read by managers (even if they
> > didn't want to).
>
> > When I
> > suggest such things to Forth programmers, they reject the
> > idea for reasons that I will not repeat here.
>
> Why not?
>
> <snip>

You snipped out too much.

> > I would be interested to know how Lisp programmers
> > write code that other programmers can read. When I look
> > at Lisp it makes no sense to me, particularly the parts
> > with all the parentheses.
>
> If so, I doubt you have spent more than two hours making a
> fair effort to learn Lisp. Any language can be used to
> write terrible code, vs. the obfuscated code contests.
> IMO, well written Lisp is the most legible of all programming
> languages. I've seen descriptions of satellite communication
> systems presented in conference viewfoils using Lisp which
> were more effective than block diagrams. The design just
> jumped off the page at you!

If I ever saw any code like that, I'd save it. Have you seen
any Forth code like that? Or do you think there is an advantage
in readability to Lisp?


> Lisp is always developed with an editor which indents the
> code to display its structure. The parentheses tend to
> 'disappear' when you read the code; you are only concerned
> with perhaps two sets at a time, about the same as C code,
> and for the same reasons.
>
> > Forth code does make sense, but I still can't know
> > what a Forth program does when things that are obvious
> > to the original programmer are not written down.
>
> This is always true, and in any language. "Written down"
> includes descriptive choices for names of data and
> functions. If these choices are done well and
> the code is properly factored, only minimal comments are
> necessary, usually to describe the top level design.
>
> Try writing code using two character names and no comments.
> Even better, lose the source and work from the disassembly!
> (I had lunch with an engineering manager who did exactly
> that on an instrument which was in production. They had
> to disassemble the ROM.)

You've written some things that should be done and some
things that should never be done, and its not clear which is
which. I like minmalist systems, small programs, tight code.
When I manage to write a particularly sneaky routine, I find my
co-workers can't figure out what I've done. I think there is
some sort of a mathematical law here. The smaller you make your
code the bigger you have to make your comments. So minimal code
needs maximal comments.

Gary Chanson

unread,
Aug 30, 2001, 3:34:39 AM8/30/01
to

"Michael Coughlin" <m-cou...@ne.mediaone.net> wrote in message
news:3B8DE20E...@ne.mediaone.net...

>
> Nope, my random sample is completely unscientific and
> statistically invalid. I just go around to people who have
> software projects that could benefit from using Forth and tell
> them they should use Forth. Usually they don't know anything
> about Forth. When they do, they almost always say Forth is
> impossible to maintain. I don't meet any current users of Forth
> this way, since the number of people who do use Forth is much
> smaller that the number of people who would use it if they knew
> what it was and how it could be maintained. I meet more users of
> Lisp than Forth in this random way since I live near a large
> educational institution that teaches Lisp.

My experience is quite different. When I've suggested Forth to
prospective clients, their responses mostly fall into two groups. One group
has no interest in any language other then what they have already chosen
(typically C or C++). The second group is aware of Forth, has considered
it, and rejected it for valid reasons (most often the difficulty of finding
experienced Forth programmers). Also, a few are willing to consider using
Forth. I don't recall any giving maintenance problems as their concern
(except from the point of view of programmer availability).

Andreas Klimas

unread,
Aug 30, 2001, 4:39:14 AM8/30/01
to
Michael Coughlin

> You've written some things that should be done and some
> things that should never be done, and its not clear which is
> which. I like minmalist systems, small programs, tight code.
> When I manage to write a particularly sneaky routine, I find my
> co-workers can't figure out what I've done. I think there is
> some sort of a mathematical law here. The smaller you make your
> code the bigger you have to make your comments. So minimal code
> needs maximal comments.

are you sure ?
if you have factored well you only have small definitions whith
meaningfull names. so a reader of a program has only to read
these names and should know what is going on.

I find the little stack comments ( -- ) useful. I only write
documentation to tell the reason for a special selected solution.
an overall designdokumentation fits well in RationalRose.

I have coworkers who are good engineers. they don't write comments
either. I naver had troubles to understand their code. I think
it's much more difficult to find the right name than coding the
few words.

--
Andreas Klimas

Stephen Pelc

unread,
Aug 30, 2001, 5:34:32 AM8/30/01
to comp.lang.lisp, comp.lang.forth
On Thu, 30 Aug 2001 06:57:04 GMT, Michael Coughlin
<m-cou...@ne.mediaone.net> wrote:
> I agree with this. Now the problem is what to do with the
>people who have seen Forth in the past and decided that it is
>useless because it is unreadable and unmaintainable. Can you
>think of a way to show them what good Forth code should look
>like?
Free downloads of the evaluation version of VFX Forth for
Windows are available from our web site. DOCGEN is included
and the VFX Forth manual is *entirely* produced by DOCGEN.

Bernd Paysan

unread,
Aug 30, 2001, 7:51:46 AM8/30/01
to
Michael Coughlin wrote:
> Forth is code. A code is not supposed to be read. Its as
> simple as that. If I say C = 1/2 x A x B, you woun't know what I
> mean. If I say the area of a triangle is 1/2 x A x B, or one
> half the altitude times the base, you might remember your lesson
> from grade school.

That's because the variable names A, B, and C are meaningless names, not
because the formula is unreadable by itself. I can understand somehow
why one uses A and B for base and height (though b and h would be more
obvious), but C for area is completely off. Why don't you write
area=1/2*base*height? There are few languages around that limit you to
one-letter variables, and even then, there are probably better
suggestions than A, B, and C.

> The first time I saw the "Hellow World" program in K&R's C
> book, I didn't understand it. Then I read the text and found out
> it was a program to print out "Hellow World". Once I knew that,
> understanding the rest was easy.

The first time I opened my Chinese tutorial, there were just unreadable
glyphs. Only by reading the German text on the next side, I found out
that these glyphs are supposed to mean "This is a table" "That is a
chair" "There's a book on the table" and such like. Our Chinese teacher
also told us how to pronounce those glyphs.

Chinese glyphs however are *meant* to be read. They are just different
from German or English text. Forth is also different from English text,
though it uses the same basic alphabet.

Code *is* the language to communicate with the computer. It *is* meant
to be read, not just to be written. If you don't have that mindset,
every code you write will always be write-only, no matter what language
you write for (probably including your comments ;-).

I also think that

% gforth
: hello ." Hello World!" cr ;
hello Hello World!
ok

probably is easier to understand at the first try than

% vi
i#include <stdio.h>

int main(int argc, char ** argv)
{
printf("Hello World!\n");
return 0;
}<Esc>
:whello.c
:q
% cc hello.c
% ./a.out
Hello World!

because there are so many things that have to be explained in the latter
example, which simply aren't there in the Forth example (and I
sidestepped the issue that early C compilers didn't include the linking
process, so you didn't have an a.out linked to libc after cc hello.c).

> Why can't the comments give you a real understanding about
> what is happening? Do you think comments are just for little
> parts of the code? Comments should cover everything the next
> programmer needs to know, from what is on the stack at any time
> to the whole purpose of the program. I don't believe there
> should be a separate write-up for a program. It all should be in
> the comments. Separate write-ups get lost faster than source
> listings.

Yes, but even then, you have to read the complete write-up (separate or
comments) to understand all of the code before you can educatedly mess
around with the code (otherwise it's just uneducated messing, which is
evil). Changing one particular piece of code will likely have
side-effects. The code is called from different places, and if you just
fix it so that one place it's called from changes behaviour, you'll
unintentedly change the behaviour of the other callers, too. My coworker
puts comments about side-effects into his code, but mostly those
side-effects he has noticed in the past (because the changes failed).
Commenting for the past is better than doing nothing, but commenting for
the future would be nice. Predictions however are difficult, especially
those into the future.

I also think that comments in most languages are not arranged in a
narratively logical flow. That's why e.g. Knuth decided to allow
literate programming to rearrange the source flow so that it finally
fits into the explanation flow. So if you don't use a full-blown
literate programming tool, you'll probably won't get very far with
writing conclusive text as documentation. In Forth, it works a bit
better, because you can use the bottom-up writing as a narrative
guide-line.

> Ok, lets find ways to show new and inexperienced Forth
> programmers readable code. If they don't see it, they can't
> learn to write it. I'd also love to show all those people who
> tell me Forth is a write only language Forth code that they can
> read.

This is probably similar to the difficulty to show all the people (who
claim that Chinese is a write-only language) that they are able to read
the glyphs. Most people can't even read German sentences, though they
know the alphabet! Come on, you *have* to learn a language to be able to
read it! You can say "I don't know zil about Forth, but it's a write
only language. Show me any code you like, and I'll be unable to read
it". This sounds like Ratbert in a Dilbert strip. It's ultimatively
true, because the unreadability is a result of the unwillingness to
learn to read.

Accepting code as "unreadable" and requiring to write everything again
in English (or whatever language you choose to comment in) means using a
language that is *less* suited for coding computer programs to carry all
the meaningful informations. English wasn't designed as programming
language.

To learn a new language, however, I agree that it is useful to have a
detailed transcription in your native tongue, the less advanced the
reader is, the more advanced the transcription must be. That's what I do
on my educational material like the one-screener or the web server for
Forth. However, not all code I write is meant to be educational material
for novices; you carefully have to choose code that can be used for
education. And you still have to make assumptions about the knowledge of
your target audience.

cLIeNUX user

unread,
Aug 30, 2001, 10:14:28 AM8/30/01
to
humb...@smart.net
>Michael Coughlin
>
>either. I naver had troubles to understand their code. I think
>it's much more difficult to find the right name than coding the
>few words.

Very true.

Rick Hohensee
www.
cLIeNUX
.com
humb...@smart.net


>
>--
>Andreas Klimas

Elizabeth D. Rather

unread,
Aug 30, 2001, 1:15:45 PM8/30/01
to
Michael Coughlin wrote:

> I also found the account of the project involving Forth and
> Lisp to be very interesting. I would like to know more about why
> a Lisp programmer would say a Forth program was hard to
> maintain. I think Lisp programs would also be hard to maintain.
> How does a Lisp programmer make his code easier to maintain than
> a Forth programmer?
>
> The original post had some intriguing statements about a
> Forth program on a NASA space probe. It was developed on an
> Apple II computer with a very old version of Forth. Lisp was
> used to modify the original program to correct a hardware
> problem. I am very curious as to why Lisp was used when Forth
> systems have excellent methods for modifying and correcting
> Forth code built right in. Old Forth code from the days of the
> Apple II can be maintained with new Forth systems running on the
> latest computers. What was the advantage of using Lisp?

Almost certainly there was no Apple II running the original host
Forth available. Also, the guy was obviously a Lisp heavy who
didn't know any Forth, so he did what came naturally: use the
tools you have and know.

Kurt B. Kaiser

unread,
Aug 30, 2001, 1:23:24 PM8/30/01
to
Michael Coughlin wrote:
> Sure factoring is important. But what do you mean by
> "anonymous parameters" ? Make them unanonymous. Label them with
> stack comments. Lots of stack comments. Or just a few stack
> comments that only tell you exactly what you need to know.

Forth passes parameters on the stack, functions ("words") access them
implicitly through the airity of the words inside the active word, which may or
may not consume the data on the stack. If data is buried on the stack, then
it's necessary to reposition it using stack manipulation words like rot or
over. The programmer has to track the stack configuation in his head.

I cringe when I see Forth functions with a cloud of dup's, overs, nips, and
drops.

If by "stack comments" you mean "stack notation", that describes the type of
the data, but not its semantics. It is of course possible to add additional
comments describing the data processed by the function, but that is not
enforced by the language and I rarely see it done. Also, these comments are
obsolete as soon as the function begins to process the stack.

The anonymous parameter problem can be fixed by using locals. However, there is
no standard way to do this, so it seems most people don't use them.

The better way currently is never to use functions with an arity greater than
three, and to have the calling function put the data on the stack without using
stack manipulation words. This should not be a problem. I've seen an analysis
of Lisp functions (Queinnec, "Lisp in Small Pieces", p. 239) showing an arity
of three covers over 80% of the rather complex functions in that book.

By not using locals Forth simplifies the implementation of the interpreter and
the internal representation of the data, but IMHO the trade-off is that the
legibility of complex functions is reduced in three ways: First, you miss the
semantic information conveyed _at point of use_ by a properly chosen parameter
names. Second, you often have to dig the data out of the stack. Third, there
is no way to express the semantics of intermediate results. Also, in the
implementations of locals that I've seen the result of a function is still
anonymous.

This was a deliberate choice by Chuck Moore when he designed Forth: Don't write
complex functions and try hard to minimize stack manipulation! An experienced
Forth developer can look at his source and understand exactly what is going to
happen in memory at runtime, and where to look in memory to find any particular
entity. That's unique!

I suppose you could argue that if you use locals you're no longer programming
in Forth.

The problem comes when someone tries to program in Forth as if it was C or
Lisp. It isn't. It has to be programmed more like an RPN calculator, with
tightly factored functions to compensate for the anonymous parameters which are
referenced by their position on the stack.

I'm sure all this has been covered many times before, and I'm sure I have not
contributed anything new. But writing it down does help me clarify my own
thoughts.

David Douthitt

unread,
Aug 30, 2001, 1:56:29 PM8/30/01
to
Bernd Paysan wrote:

> Code *is* the language to communicate with the computer. It *is* meant
> to be read, not just to be written. If you don't have that mindset,
> every code you write will always be write-only, no matter what language
> you write for (probably including your comments ;-).

Not really. The only language that I know of that was "meant to be
read" was COBOL. The example previously given:

c = 1/2 * A * B

-or-

area=1/2*base*height

-becomes-

MULTIPLY BASE BY HEIGHT BY .5 GIVING AREA.

...of course, modern COBOL will now recognize the previous two forms.
However, I would add this: mathematical notation has no precedent for
'*' as multiplication; so a true "designed to be read" form would be:

C = 1/2 A B

..but computers would have a fit.

> Yes, but even then, you have to read the complete write-up (separate or
> comments) to understand all of the code before you can educatedly mess
> around with the code (otherwise it's just uneducated messing, which is
> evil).

Using meaningful names, as you suggested, along with many other
techniques can help avoid this.

> Changing one particular piece of code will likely have
> side-effects.

That's where things like data hiding and other things come into play.

> The code is called from different places, and if you just
> fix it so that one place it's called from changes behaviour, you'll
> unintentedly change the behaviour of the other callers, too.

Data-hiding.

> My coworker
> puts comments about side-effects into his code, but mostly those
> side-effects he has noticed in the past (because the changes failed).

Side-effects are to be avoided at all costs.

> Commenting for the past is better than doing nothing, but commenting for
> the future would be nice.

Commenting is one of the most important things one can do.

> You can say "I don't know zil about Forth, but it's a write
> only language. Show me any code you like, and I'll be unable to read
> it". This sounds like Ratbert in a Dilbert strip. It's ultimatively
> true, because the unreadability is a result of the unwillingness to
> learn to read.

One can write incomprehensible code or comprehensible code. This
doesn't change the fact that if you don't know the language, you can't
understand it.

If you don't think C is "write-only" then one should examine winners
from the Obfuscated C Contest. You can make any language "write-only"
if you want to.

> Accepting code as "unreadable" and requiring to write everything again
> in English (or whatever language you choose to comment in) means using a
> language that is *less* suited for coding computer programs to carry all
> the meaningful informations. English wasn't designed as programming
> language.

Code should be readable AND explained by well-written comments. One of
my favorite things to do with new code is write everything in the
comments first (a sort of pseudocode) then convert the steps to code.

English wasn't designed as a programming language, but programming
languages weren't designed for expository and explanatory writing
either.

Not only this - suppose you are writing Forth code, or COBOL code, or C
code somewhere where English is NOT the native tongue. Shouldn't you
have German comments in code written in Germany?

David Douthitt

unread,
Aug 30, 2001, 2:08:50 PM8/30/01
to
"Kurt B. Kaiser" wrote:
>
> Michael Coughlin wrote:

> > Forth programs are "pretty notorious for being hard to
> > maintain". This is not the fault of the Forth language.

> Actually, it _is_ the fault of the Forth language. The parameters for the


> functions come in anonymously and also must be accessed using stack
> manipulation commands.

That's where comments come in. Also, some FORTHs access the stack (or
can) using local names for the different arguments.

> This can result in incomprehensible code in the hands of
> a novice.

So can any language.

> > You
> > indicate the reason very clearly when you state "Forth
> > programmers are almost as hard to find as Lisp programmers", so
> > when an old Forth program needs to be updated, all heck breaks
> > loose, since there is usually nobody around who knows how to
> > program in Forth.
>
> Or Lisp, Eiffel, Ada, Cobol, ML, Assembler, or anything else besides C and VB.
> But they aren't hard to find.

Programmers in other languages may be hard to find (with the exceptions
you noted) but COBOL Programmers are everywhere. The school I went to
still turns out a hundred or so every year.

> > I would be interested to know how Lisp programmers write
> > code that other programmers can read. When I look at Lisp it
> > makes no sense to me, particularly the parts with all the
> > parentheses.

This hearkens to someone else's statement - if you don't know the
language, of course the code is incomprehensible. With the appropriate
knowledge and comments, you should be able to understand it. If you
don't know Smalltalk, is it going to be readable? What about APL, LISP,
or Forth?

Unless you know the language, it'll be incomprehensible.

> If so, I doubt you have spent more than two hours making a fair effort to learn
> Lisp. Any language can be used to write terrible code, vs. the obfuscated code
> contests.

Well said.

> IMO, well written Lisp is the most legible of all programming languages.

I'm surprised you would say that. Consider:

PERFORM SATELLITE-ANALYSIS.
DISPLAY RESULTS.
MULTIPLY RESULTS BY SOME-CONSTANT GIVING NEW-RESULTS.

> I've seen descriptions of satellite communication systems presented
> in conference viewfoils using Lisp which were more effective than block
> diagrams. The design just jumped off the page at you!

At YOU, a seasoned LISP-reader. Would a LISP neophyte say the same?

> > Forth code does make sense, but I still can't know
> > what a Forth program does when things that are obvious to the
> > original programmer are not written down.
>
> This is always true, and in any language. "Written down" includes descriptive
> choices for names of data and functions. If these choices are done well and
> the code is properly factored, only minimal comments are necessary, usually to
> describe the top level design.

Again, well said.

David Douthitt

unread,
Aug 30, 2001, 2:16:46 PM8/30/01
to
"Kurt B. Kaiser" wrote:

> The problem comes when someone tries to program in Forth as if it was C or
> Lisp. It isn't.

I agree with this entirely. In fact, as one who enjoys LISP, Forth,
Smalltalk, AND C, it's important that you recognize the style of each
language, and program that way. You can't write LISP programs the way
you write C programs, and you can't write Smalltalk like LISP.

However, I do find that the "factoring" inherent in some languages,
Forth especially, translates well. Instead of C functions lasting for
page after page after page, if you stick to less then one screenful
(similar to Forth functions) then everything improves (as long as you
use good names).

My (limited) experience with LISP and Smalltalk tells me that the
factoring idea is there as well, and lambda definitions (LISP) and
methods (Smalltalk) tend to be much smaller than C functions typically
are.

Julian Fondren

unread,
Aug 30, 2001, 4:14:09 PM8/30/01
to
Michael Coughlin <m-cou...@ne.mediaone.net> wrote in message news:<3B8DE28E...@ne.mediaone.net>...

(snip)

> Forth is code. A code is not supposed to be read. Its as

OK. You name your words @#$@% @#$@#$ 101991(significant, invisble
whitespace)a and so on, if you want. I usually like my code to
be readable, in the sense that I can read its sentences if I know
the words. That's what a vocabulary is all about, right? Words
in Forth are just a bit heavier than words in other languages.

> simple as that. If I say C = 1/2 x A x B, you woun't know what I
> mean. If I say the area of a triangle is 1/2 x A x B, or one
> half the altitude times the base, you might remember your lesson
> from grade school.

Right. "1/2 x A x B" is just as unreadable as "one-half the
altitude times the base", if you know what neither symbol nor
word means. This is vocabulary, which goes back to my first
comment.



> The first time I saw the "Hellow World" program in K&R's C
> book, I didn't understand it. Then I read the text and found out
> it was a program to print out "Hellow World". Once I knew that,
> understanding the rest was easy.

printf("Hello, world!\n"); is somewhat suspicious, but OK.

display-text-to-screen: Hello, world!

might've been recognized faster.

> Having Forth code well factored with short definitions and
> informative names is a good thing. But it is not the first thing
> you have to know. You also have to know what is being computed,
> how it is being computed, why it is not being computed some
> other way, and so on. When you start a program you usually don't
> write such things down since that information is either not
> decided yet, or fresh in your mind. But I say it should be
> written down, and the sooner the better.

Yes, that's called the stack comment. I usually put stack comments
and word-based information in my shadow blocks, and a short description
of what the block is for, but I don't talk too much about the
interactions between the words. That's what the code is for. After
you know the words, you can read the code.

(snip)



> Why can't the comments give you a real understanding about
> what is happening? Do you think comments are just for little
> parts of the code? Comments should cover everything the next
> programmer needs to know, from what is on the stack at any time
> to the whole purpose of the program. I don't believe there
> should be a separate write-up for a program. It all should be in
> the comments. Separate write-ups get lost faster than source
> listings.

"everything the programmer needs to know"? Well, obviously you've
an implicit subset in contradiction to your words, since I don't
think it's *possible* to put everything a programmer needs to know
in a comment. How's the programmer going to read the comment?
So right off the bat you're writing for a certain sort of person.
Maybe this person is you, and you're leaving little reminders to
keep you from getting lost. Maybe this person is your manager,
and you're painstaking translating code to English. Maybe this
person is a maintenance programmer, and you're being explicit about
dependencies and interactions between words. Your manager doesn't
need to know this last part, probably, but it'd be a great help
to the maintenance programmer.

I understand your problem with seperate write-ups, or seperate
documentation. Documentation tends to become seperated physically
or logically from source code, and putting it all intermixed with
the source code is a tricky way of fighting this. What *I* don't
like is having to hunt through information I don't need to find
code, which I *do* need. It makes the code hard to read, it makes
the code seem more complex than it is, it fragments my conception
of the code. It's like the simple comparison between a block of
code and a book of code. One you can hold completely in your mind
with little trouble, and deal with it with little trouble. The
other might be more easily burned and rewritten. If it has good
documentation, you can just make the needed change. If it has
pages of comments between each word, you're going to have some
labour involved.

I personally think that the ultimate answer to this question, to
the question of code appearance, of code comments and documentation,
is a special editor that deals with both, displaying both as each
reader wants. This could also eliminate all the traditional wars
over code indentation and formatting. You don't have any -- it's
all automatic when the editor displays code to you.

I just use blocks, and shadow blocks.

(snip)

> Ok, lets find ways to show new and inexperienced Forth
> programmers readable code. If they don't see it, they can't
> learn to write it. I'd also love to show all those people who
> tell me Forth is a write only language Forth code that they can
> read.

Forth, Inc. has some wonderful examples of readable Forth.

Gary Chanson

unread,
Aug 30, 2001, 5:17:23 PM8/30/01
to

"Julian Fondren" <clever...@hotmail.com> wrote in message
news:76ea4fd3.01083...@posting.google.com...

>
> I personally think that the ultimate answer to this question, to
> the question of code appearance, of code comments and documentation,
> is a special editor that deals with both, displaying both as each
> reader wants. This could also eliminate all the traditional wars
> over code indentation and formatting. You don't have any -- it's
> all automatic when the editor displays code to you.
>
> I just use blocks, and shadow blocks.

Text files which hyperlinks to documentation (as well as source of the
referenced function) works far better. My preference is to implement the
hyperlinks as a separate database that is automatically generated (at least
in relation to the source).

Albert van der Horst

unread,
Aug 30, 2001, 12:54:31 PM8/30/01
to
In article <3b8ce4ce....@192.168.0.1>,

Stephen Pelc <s...@mpeltd.demon.co.uk> wrote:
>On Tue, 28 Aug 2001 22:56:52 GMT, Michael Coughlin
><m-cou...@ne.mediaone.net> wrote:
>> Forth could be very easy to read and maintain if Forth
>>programmers would realize it takes much extra effort to comment
>>and document it properly. And by that I mean write so the code
>>can be read by managers (even if they didn't want to).
>You could easily remove "Forth" from this and substitute
>the name of some other language. Regardless of language,
>writing for maintenance is a matter of management and
>corporate culture.
>
>Over the last three years we have switched over to a tool
>chain (Forth) which extracts documentation as formal
>comments from the source code and then generates HTML
>and/or PDF manuals. The effect of this has been to
>the documentation as the code is written.

I used and use the same technique in creating and maintaining ciforth.
In fact ciforth started out as fig-forth and I maintained the
documentation up to date through all modifications, improving the
automation of the documentation on the way.

I think it is a good method. However. There is still a need for
overview documentation that should be added at the appropriate level.
A dead simple example. In all glossary descriptions you use ``sc''
(string constant) for an address, length pair to mean that it contains
printable characters. One (or all) of these glossary descriptions is
not the appropriate place to explain this kind of legend information.

Charles Moore (provocatively) has stated that the "overview"
documentation (in case the glossary) should be sufficient, and that
at the lower level you should not need more than a few stack
reminders. I have in fact no trouble with that. I am convinced that
Chuck writes documentation in parallel, like all productive
programmers I have ever met. That is the point that matters.
Write the information down while you are aware of it. Be it in
separate files, the same file or parallel screens. That comes
secondary.

I presume MPE (with its commercial background) agrees
that there are levels up, that cannot be reasonably added to
the code.

In the generic assembler file of ciforth each word's definition is
preceeded by a formal comment containing:
1. name
2. wordlist
3. stack effect
4. portability (ISO, FIG, F83)
5. Description
6. Sample code with the required outcome. Several of them
7. See also. Related words. Several of them.

The wordlist is used to order the documentation in chapters.
The sample code is used to generate the test code.
The see also is used to generate references in texinfo or
html.

make testlina
goes a long way towards ensuring that I didn't break anything.

The descriptions go in the reference section of the manual,
but there are other sections needed as well.

>When we looked at literate programming tools some years
>ago, the problem was that the source for the compiler and
>the documentation could get out of step. In our system there
>is only ever one file, and the documentation is contained
>within formal comments.

One of my favorite gripes with programming tools is the following:
if I have chosen a wrong name at the start I am stuck with it.
Improving names is one of the most important things to do in
a design process. The relevance of these tools for cross platform
parallel processing, inhomogeneous, real time systems is zill.
Now that was my last job. I could use some help indeed.
That was supplied by good old traditional Unix tools.

>Again, documentation and maintainability are NOT a language
>issue.

Not per se. Fully agreed.

>Stephen
Albert
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
To suffer is the prerogative of the strong. The weak -- perish.
alb...@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst

cLIeNUX user

unread,
Aug 30, 2001, 9:13:39 PM8/30/01
to
humb...@smart.net

>Michael Coughlin wrote:
>> Sure factoring is important. But what do you mean by
>> "anonymous parameters" ? Make them unanonymous. Label them with
>> stack comments. Lots of stack comments. Or just a few stack
>> comments that only tell you exactly what you need to know.
>
>Forth passes parameters on the stack, functions ("words") access them
>implicitly through the airity of the words inside the active word, which may or
>may not consume the data on the stack. If data is buried on the stack, then
>it's necessary to reposition it using stack manipulation words like rot or
>over. The programmer has to track the stack configuation in his head.
>
>I cringe when I see Forth functions with a cloud of dup's, overs, nips, and
>drops.
>

What do you do when you see x86 code that's 25% MOV's? For a real visceral
churn, write a Forth in C and look at the Gcc-produced assembly.

>entity. That's unique!
>
>I suppose you could argue that if you use locals you're no longer programming
>in Forth.

I've argued that. The problem is, commodity hardware likes locals a bunch.
Stacks are arrays really, on register machines. So I'm writing assemblers
now.

>
>The problem comes when someone tries to program in Forth as if it was C or
>Lisp. It isn't. It has to be programmed more like an RPN calculator, with
>tightly factored functions to compensate for the anonymous parameters which are
>referenced by their position on the stack.
>
>I'm sure all this has been covered many times before, and I'm sure I have not
>contributed anything new. But writing it down does help me clarify my own
>thoughts.
>

You can name things in stack comments more easily than in e.g. C
declarations, but yes you have a point.

Conversely, there's a tendency for locals to have names like A, B, C...
anyway, which argues for no names at all. Plan 9 code is like that.
Someday they'll get to Forth even at Bell Labs :o)

Rick Hohensee

Julian Fondren

unread,
Aug 30, 2001, 11:06:00 PM8/30/01
to
David Douthitt <ss...@mailbag.com> wrote in message news:<3B8E7E4D...@mailbag.com>...

(snip)

> c = 1/2 * A * B
>
> -or-
>
> area=1/2*base*height
>
> -becomes-
>
> MULTIPLY BASE BY HEIGHT BY .5 GIVING AREA.

and none of these is readable if you don't understand 'multiply', or '*'.
Certainly you can look up 'multiply'. You can also look up '*' in your
compiler documentation, or a mathematics book. These are /equally/
readable, but by default different subsets of the human race will come
newly to them ready and able to understand them.

> ...of course, modern COBOL will now recognize the previous two forms.
> However, I would add this: mathematical notation has no precedent for
> '*' as multiplication; so a true "designed to be read" form would be:
>
> C = 1/2 A B

That's funny, I'd have much more trouble reading this last version than
any of the previous three, if you hadn't implied the notation.



> ..but computers would have a fit.

Computers? Forth could read that.

(snip)

Erann Gat

unread,
Aug 30, 2001, 11:46:37 PM8/30/01
to
Michael Coughlin <m-cou...@ne.mediaone.net> wrote in message news:<3B8C20A6...@ne.mediaone.net>...

> Erann Gat wrote:
> > Forth code in general is pretty notorious for being hard
> > to maintain,

[snip]

> I've cross posted this to comp.lang.forth since Forth
> programmers will want to read and comment on it. You are right.

> Forth programs are "pretty notorious for being hard to

> maintain". This is not the fault of the Forth language. It is
> the fault of Forth programmers and the people who hire them. You


> indicate the reason very clearly when you state "Forth
> programmers are almost as hard to find as Lisp programmers", so
> when an old Forth program needs to be updated, all heck breaks
> loose, since there is usually nobody around who knows how to
> program in Forth.

I think there's more to it than that. Forth functions don't have
named argument lists, and no clear delineation of block structure.
(At least this was the case at the time. I haven't used Forth in many
years; maybe things are different now.) In other languages you can at
least tell how many arguments you're supposed to pass to a function
just by looking at the code. While I acknowledge that it is possible
to write maintainable Forth I believe it requires more conscious
effort on the part of the programmer than in other languages.

> This particular problem with a Forth program
> was solved by someone who programmed in Lisp. Perhaps being a
> user of Lisp indicates an interest in a variety of languages so
> you got the job that the other programmers who only knew popular
> languages wouldn't touch.

I got the job by being the only one foolish enough to insist that I
could do it within the time and budget constraints. It was actually
quite a struggle to get the support. No one believed it could be
done. ("Let's get this straight, son. The team who built the thing
is telling me they can't do it at all, and you're telling me you can
do it in three months by building a new compiler? What have you been
smoking?")

> I would be interested to know how Lisp programmers write
> code that other programmers can read. When I look at Lisp it
> makes no sense to me, particularly the parts with all the
> parentheses.

This is a pretty blatant troll. I'll answer in the manner in which it
was written, though it doesn't really reflect my true feelings: I
wonder how Forth programmers write code that other programmers can
read. When I look at Forth it makes no sense to me, particularly
since it has no punctuation.

Erann Gat
g...@flownet.com

Bernd Paysan

unread,
Aug 31, 2001, 4:29:56 AM8/31/01
to
David Douthitt wrote:
> Not really. The only language that I know of that was "meant to be
> read" was COBOL. The example previously given:

I think the only language not meant to be read is binary. All the ASCII
formats (or even OKAD with it's internal disassembler) are meant to be
read; otherwise the translation process from a human alphabet to a
directly executable format would not make sense.

COBOL was meant to be read by people who think that only English text is
readable.

> Not only this - suppose you are writing Forth code, or COBOL code, or C
> code somewhere where English is NOT the native tongue. Shouldn't you
> have German comments in code written in Germany?

I'm working for an international company (though it is small). We have a
department in Italy, and we don't like them to comment their code (or
their schematics) in Italian, either. I have (or have had, fluctuation
is high) from most Europe. The customers are all around over the world.
English as lingua franca is used for all documentation.

Those people who say xxx (or Forth) is unreadable imply that the comment
should repeat the information of the code in a "readable" language. I
don't like unnecessary redundancy. Comments should not repeat the
information in the code, they should add information that isn't in the
code (or is not that easy to extract, like stack effects). I consider
the name of a word a comment. Documentation should say why and how to
use and such like, not just detailed how it is implemented; that's
already in the code.

Andreas Klimas

unread,
Aug 31, 2001, 5:26:30 AM8/31/01
to
Bernd Paysan wrote:
>
> David Douthitt wrote:
> > Not really. The only language that I know of that was "meant to be
> > read" was COBOL. The example previously given:

[snip]


> Those people who say xxx (or Forth) is unreadable imply that the comment
> should repeat the information of the code in a "readable" language. I
> don't like unnecessary redundancy. Comments should not repeat the
> information in the code, they should add information that isn't in the
> code (or is not that easy to extract, like stack effects). I consider
> the name of a word a comment. Documentation should say why and how to
> use and such like, not just detailed how it is implemented; that's
> already in the code.

I totaly agree.

if you think that you should document the code, don't.
recode the source to be readable. little functions with
meaningfull names are readable like a book.

--
Andreas Klimas

Stephen Pelc

unread,
Aug 31, 2001, 5:47:51 AM8/31/01
to comp.lang.lisp, comp.lang.forth
On Thu, 30 Aug 2001 16:54:31 GMT, alb...@spenarnc.xs4all.nl (Albert
van der Horst) wrote:
>I think it is a good method. However. There is still a need for
>overview documentation that should be added at the appropriate level.
...

>I presume MPE (with its commercial background) agrees
>that there are levels up, that cannot be reasonably added to
>the code.
That is why DOCGEN allows you to define section numbering and to
change the output file whenever you want to. These make organising
the documentation much easier.

>In the generic assembler file of ciforth each word's definition is
>preceeded by a formal comment containing:
>1. name
>2. wordlist
>3. stack effect
>4. portability (ISO, FIG, F83)
>5. Description
>6. Sample code with the required outcome. Several of them
>7. See also. Related words. Several of them.

For safety critical systems, DOCGEN/SC copes with nearly all of this,
including the generation of test files. The output is documentation
to US FDA standard. Our client produces anaesthetic ventilators for
use in operating theatres, so it really does matter. One of the
good side effects is that when code is reused, the documentation
is also reused. The final documentation is about 1500 pages
produced in about two minutes, most of which is consumed by
having to run the TeX and PDF tools.

Stephen Pelc

unread,
Aug 31, 2001, 5:59:05 AM8/31/01
to comp.lang.forth
On Thu, 30 Aug 2001 17:23:24 GMT, "Kurt B. Kaiser" <k...@shore.net>
wrote:

>I cringe when I see Forth functions with a cloud of dup's, overs, nips, and
>drops.
So do most good Forth programmers.

>If by "stack comments" you mean "stack notation", that describes the type of
>the data, but not its semantics. It is of course possible to add additional
>comments describing the data processed by the function, but that is not
>enforced by the language and I rarely see it done. Also, these comments are
>obsolete as soon as the function begins to process the stack.

Judging by the amount of code I've read in several languages,
commenting is completely optional in any language! The Linux
kernel sources are a mine of zero documentation. Just remember
the old caveat "If it was hard to write, it should be hard to
read". Roedy Green's essay on how to write unmaintainable code
shows how it should be done in any language, including the
fashionable ones.

James Hague

unread,
Aug 31, 2001, 12:14:26 PM8/31/01
to
Kurt B. Kaiser wrote:
>
> Forth passes parameters on the stack, functions ("words") access them
> implicitly through the airity of the words inside the active word, which
may or
> may not consume the data on the stack. If data is buried on the stack,
then
> it's necessary to reposition it using stack manipulation words like rot or
> over. The programmer has to track the stack configuation in his head.

And the easy advice is "Don't write functions which involve lots of stack
juggling." Data flows neatly through a beautiful Forth program.

Realistically, though, it is easy to run into problems where you have to do
lots of error-prone stack juggling, the kind of code where you have to sit
down and convince yourself on paper that you understand what is going on.
Try writing Ackermann's function in Forth without locals, for example. And
that's a trivial function to write in most any other language.

James


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

Elizabeth D. Rather

unread,
Aug 31, 2001, 1:44:44 PM8/31/01
to
Erann Gat wrote:

> > I've cross posted this to comp.lang.forth since Forth
> > programmers will want to read and comment on it. You are right.
> > Forth programs are "pretty notorious for being hard to
> > maintain". This is not the fault of the Forth language. It is
> > the fault of Forth programmers and the people who hire them. You
> > indicate the reason very clearly when you state "Forth
> > programmers are almost as hard to find as Lisp programmers", so
> > when an old Forth program needs to be updated, all heck breaks
> > loose, since there is usually nobody around who knows how to
> > program in Forth.
>
> I think there's more to it than that. Forth functions don't have
> named argument lists, and no clear delineation of block structure.
> (At least this was the case at the time. I haven't used Forth in many
> years; maybe things are different now.) In other languages you can at
> least tell how many arguments you're supposed to pass to a function
> just by looking at the code. While I acknowledge that it is possible
> to write maintainable Forth I believe it requires more conscious
> effort on the part of the programmer than in other languages.

It is customary in Forth to follow the name of each new definition
by a "stack comment" showing the number, order, and types of
stack arguments into and out of that defintion. ANS Forth (1994)
gave models for this (and recommended notation) which is widely
followed. Responsible Forth programmers (and in my experience
most are) regard these comments as just as mandatory as argument
lists in other languages, even though most compilers don't enforce
the requirement. It is also recommended (and common) practice
to add a comment as to intended usage.

> > I would be interested to know how Lisp programmers write
> > code that other programmers can read. When I look at Lisp it
> > makes no sense to me, particularly the parts with all the
> > parentheses.
>
> This is a pretty blatant troll. I'll answer in the manner in which it
> was written, though it doesn't really reflect my true feelings: I
> wonder how Forth programmers write code that other programmers can
> read. When I look at Forth it makes no sense to me, particularly
> since it has no punctuation.

The point being, that "readability" of any language requires some
familiarity with that language.

Bill Zimmerly

unread,
Aug 31, 2001, 2:27:53 PM8/31/01
to
"Elizabeth D. Rather" <era...@forth.com> wrote in message
news:3B8FCD31...@forth.com...

>
> The point being, that "readability" of any language requires some
> familiarity with that language.
>
> Cheers,
> Elizabeth

Profoundly true.

It would be pretty silly for me to say that "Hebrew" is an unreadable
language.....

....just because I personally can't read it!! :)

Why do seemingly intelligent people say such idiotic things like "____ is an
unreadable language"????

--
- Bill Zimmerly, http://www.zimmerly.com
"Reasonable people adapt themselves to the world. Unreasonable people
attempt to adapt the world to themselves. All progress, therefore, depends
on unreasonable people." - George Bernard Shaw

cLIeNUX user

unread,
Aug 31, 2001, 3:55:34 PM8/31/01
to
humb...@smart.net

>"Elizabeth D. Rather" <era...@forth.com> wrote in message
>news:3B8FCD31...@forth.com...
>>
>
>Why do seemingly intelligent people say such idiotic things like "____ is an
>unreadable language"????
>

The other one that just kills me is the incessant noise you hear that
small superb designs don't scale. Not when handed to idiots they don't.

Rick Hohensee
www.
cLIeNUX
.com
humb...@smart.net

>--

Knud Werner

unread,
Aug 31, 2001, 4:53:39 PM8/31/01
to
"Elizabeth D. Rather" wrote:

> It is customary in Forth to follow the name of each new definition
> by a "stack comment" showing the number, order, and types of
> stack arguments into and out of that defintion. ANS Forth (1994)
> gave models for this (and recommended notation) which is widely
> followed. Responsible Forth programmers (and in my experience
> most are) regard these comments as just as mandatory as argument
> lists in other languages, even though most compilers don't enforce
> the requirement. It is also recommended (and common) practice
> to add a comment as to intended usage.
<snip>

> The point being, that "readability" of any language requires some
> familiarity with that language.

As it seems to me, most programmers - and this might be independent
of the language used - have an imperfect understanding of readabilty
and it's importance in software engineering. IMHO many programmers
understand readabilty as "feed to the compiler without errors" and
take different attitudes about warnings or complains ;-)

I personally consider code being well written if it is short, efficient
and factored. Efficient implies correct and effective. Such code might
not be the most easiest to write, but seems to be the most easiest to
read.
The point being, that the intended audience for my code are humans,
either myself (fixing some stupid but well hidden bugs of mine several
month after launching) or the other programmers maintaining or
developing it.

I believe that code which is short, efficient and factored - in one
word:
human-readable - is much easier to maintain and develop than utterly
complex
nests of goto's, but I'm accustomed to see much more of the latter, and
that seems not to depend on the language used.

I think Forth is at least as well prepared to produce readable code as
any other of the dozen or so languages I'm more or less familiar with,
but I also think that's it's all in the hand of the programmer himself,
ie. the maintainabilty - and therefore the total cost - of software
depends
NOT on the language, but how it's used.

Regards, Knud

Thomas F. Burdick

unread,
Aug 31, 2001, 5:01:13 PM8/31/01
to
"Bill Zimmerly" <bi...@zimmerly.com> writes:

> It would be pretty silly for me to say that "Hebrew" is an unreadable
> language.....
>
> ....just because I personally can't read it!! :)
>
> Why do seemingly intelligent people say such idiotic things like "____ is an
> unreadable language"????

Why is a statement like "Perl is an unreadable language" idiotic?
Your comparison to a human language that one doesn't know, makes no
sense. Intelligent people who claim a language is unreadable will
presumably *know* the language (otherwise that "intelligent" bit would
be pretty suspect). Languages optimize for different things. Perl,
which seems to optimize for the output of a monkey given a typewriter
being a valid program, I find unreadable. Common Lisp, which
optimizes for expressiveness, I generally find to be readable. You
can certainly write unreadable code in Lisp, and it's sort-of possible
to write readable Perl, but I don't think that detracts from the
usefullness of the generalization.

Elizabeth D. Rather

unread,
Aug 31, 2001, 5:27:34 PM8/31/01
to
"Thomas F. Burdick" wrote:

> "Bill Zimmerly" <bi...@zimmerly.com> writes:
>
> > It would be pretty silly for me to say that "Hebrew" is an unreadable
> > language.....
> >
> > ....just because I personally can't read it!! :)
> >
> > Why do seemingly intelligent people say such idiotic things like "____ is an
> > unreadable language"????
>
> Why is a statement like "Perl is an unreadable language" idiotic?
> Your comparison to a human language that one doesn't know, makes no
> sense. Intelligent people who claim a language is unreadable will
> presumably *know* the language (otherwise that "intelligent" bit would
> be pretty suspect).

Bill is doubtless a little defensive because we Forth folks are all too
accustomed to hearing people who know _nothing_ about Forth say,
"Oh, Forth, I saw some Forth code once and it was totally unreadable."
Insofar as Lisp is also a minority language, don't you sometimes get
the same thing?

> Languages optimize for different things. Perl,
> which seems to optimize for the output of a monkey given a typewriter
> being a valid program, I find unreadable. Common Lisp, which
> optimizes for expressiveness, I generally find to be readable. You
> can certainly write unreadable code in Lisp, and it's sort-of possible
> to write readable Perl, but I don't think that detracts from the
> usefullness of the generalization.

Forth optimizes for modularity and interactivity. The golden path
to readable Forth is clear names for the modules.

Jerry Avins

unread,
Aug 31, 2001, 6:20:22 PM8/31/01
to
David Douthitt wrote:
>
...

>
> C = 1/2 A B
>
...

Is that C = 1/(2 A B) ? If so, I don't get it. Try using RPN; it's not
ambiguous.

Jerry
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------

Guido Draheim

unread,
Aug 31, 2001, 6:29:25 PM8/31/01
to
"Elizabeth D. Rather" wrote:
>
> "Thomas F. Burdick" wrote:
>
> > "Bill Zimmerly" <bi...@zimmerly.com> writes:
> >
> > > It would be pretty silly for me to say that "Hebrew" is an unreadable
> > > language.....
> > >
> > > ....just because I personally can't read it!! :)
> > >
> > > Why do seemingly intelligent people say such idiotic things like "____ is an
> > > unreadable language"????
> >
> > Why is a statement like "Perl is an unreadable language" idiotic?
> > Your comparison to a human language that one doesn't know, makes no
> > sense. Intelligent people who claim a language is unreadable will
> > presumably *know* the language (otherwise that "intelligent" bit would
> > be pretty suspect).
>
> Bill is doubtless a little defensive because we Forth folks are all too
> accustomed to hearing people who know _nothing_ about Forth say,
> "Oh, Forth, I saw some Forth code once and it was totally unreadable."
> Insofar as Lisp is also a minority language, don't you sometimes get
> the same thing?
>
I don't hear that forth is "unreadable" but "unpredictable"[1] - in
most modern languages there is a generic block/scope system and quite
some calls/definitions/controlstructs require to use it - so even
that you do not know a certain control-expression (like try/catch)
you still get an idea about the flow of control and all the data items
that are involved. Now this is all different with forth - data items
on the stack might be textually-invisibly modified, the words can parse
ahead and just build label-branch defs in the background, possibly
using all kinds of table-lookups. So - if there are no indentations
or stack-comments then the casual reader will not know anything of
what is going on. In a way one could call it "basic syntax" that is
missing from forth - either know all the words in a sentence or be
left to read a series of forthglyphs that look nice but just that.

(btw, there are ways out of this but they are left to the discipline
of the developer being non-creative with the usual behaviour of names).

-- guido
[1] may be an exxageration of "known to constantly do unexpected things
behind my back (i.e. in contrast to what one can see written there)".

Jerry Avins

unread,
Aug 31, 2001, 6:37:46 PM8/31/01
to
Michael Coughlin wrote:
>
> Kurt B. Kaiser wrote:
> >
> > Michael Coughlin wrote:
> > > I've cross posted this to comp.lang.forth since Forth
> > > programmers will want to read and comment on it. You are
> > > right. Forth programs are "pretty notorious for being
> > > hard to maintain". This is not the fault of the Forth
> > > language.
> >
> > Troll!!

> >
> > Actually, it _is_ the fault of the Forth language. The
> > parameters for the functions come in anonymously and
> > also must be accessed using stack manipulation commands.
> > This can result in incomprehensible code in the hands of
> > a novice. These anonymous parameters are also the key to
> > legibility in properly written Forth. I've struggled with
> > this for years. It seems the answer lies in factoring.
> > Forth is a very sharp tool and should labelled, "experts
> > only."

>
> Sure factoring is important. But what do you mean by
> "anonymous parameters" ?

Every definition has a stack-effect comment, no? (If no, for shame!)
When the word is used, good comments reinforce the stack picture.

> Make them unanonymous. Label them with
> stack comments. Lots of stack comments. Or just a few stack
> comments that only tell you exactly what you need to know.

> Saying Forth can only be used by experts is not a complement to
> Forth. But then again you could say the same thing about writing
> technical English -- it should also only be done by experts.
> Writing in English can result in incomprehensible prose in the
> hands of a novice. When an uninitiated computerist says Forth is
> a write only language he is saying he only sees Forth code
> written by non-experts.

Not necessarily. Just as likely, the reader is illiterate in Forth, but
ego prevents knowing it.

> The code might run fast, give the right
> answer, and use little memory. But the programmer was not expert
> enough to do the whole job.
>
...
>
> --
> Michael Coughlin m-cou...@ne.mediaone.net Cambridge, MA USA

Erann Gat

unread,
Sep 1, 2001, 12:55:47 AM9/1/01
to
"Elizabeth D. Rather" <era...@forth.com> wrote in message news:<3B8FCD31...@forth.com>...

So we agree.

> > > I would be interested to know how Lisp programmers write
> > > code that other programmers can read. When I look at Lisp it
> > > makes no sense to me, particularly the parts with all the
> > > parentheses.
> >
> > This is a pretty blatant troll. I'll answer in the manner in which it
> > was written, though it doesn't really reflect my true feelings: I
> > wonder how Forth programmers write code that other programmers can
> > read. When I look at Forth it makes no sense to me, particularly
> > since it has no punctuation.
>
> The point being, that "readability" of any language requires some
> familiarity with that language.

Right. That said, I don't think that all languages are equally
readable. Compare:

Lisp:
(if (foo)
(print "baz")
(print "bar"))

C:
if (foo()) {
printf("baz");
} else {
printf("bar");
}

Forth: (forgive me if I get the details wrong here, my Forth is
rusty)
foo if "bar" print else "baz" print then

Python:
if foo():
print "baz"
else:
print "bar"

I think Python has a clear edge in readbility. Lisp is a liitle bit
weird because of the implied else and the fact that the parens seem to
be in weird places to the uninitated. The C is mostly decipherable.
Notice by the way that the C has exactly as many parens as the Lisp,
but vastly more total punctuation. The Forth seems pretty cryptic by
comparison. What's that 'then' doing by itself off at the end?
Postfix is very unintuitive to most people because it has no analog in
natural language. You can say "a plus b" to mirror infix, or "the sum
of a and b" to mirror prefix, but "a and b, the sum of those things"
sounds awfully contrived.

E.

Bruce Hoult

unread,
Aug 31, 2001, 1:35:41 PM8/31/01
to
In article <1f4c5c5c.01083...@posting.google.com>,
g...@flownet.com (Erann Gat) wrote:

> > The point being, that "readability" of any language requires some
> > familiarity with that language.

Not necessarily. I've several times developed an algorithm in Dylan and
then as an experiment given the source code to someone who has never
seen Dylan (but knows, say, C or Java well) without even commenting on
what language the code is in. No one has ever had any problems with it.
OTOH, I don't do this with stupid people :-)


> Right. That said, I don't think that all languages are equally
> readable. Compare:
>
> Lisp:
> (if (foo)
> (print "baz")
> (print "bar"))
>
> C:
> if (foo()) {
> printf("baz");
> } else {
> printf("bar");
> }

Bearing in mind that in both cases you can factor out the common "print"
to good advantage:

(print (if (foo) "baz" "bar"))

printf(foo() ? "baz" : "bar")


> Forth: (forgive me if I get the details wrong here, my Forth is
> rusty)
> foo if "bar" print else "baz" print then

I think PostScript is better:

foo
[(baz) print]
[(bar) print]
ifelse

... or obvious variations, such as...

foo [(baz)][(bar)] ifelse print


> Python:
> if foo():
> print "baz"
> else:
> print "bar"
>
> I think Python has a clear edge in readbility.

It's readable, but I think *far* too dangerous to allow to live. The
bugs caused by misplaced semicllons and parens are legion. Editing
accidents that leave indentation mangled are far more likely to happen,
and thee is no redundancy so nothing can warn you about it.


> Lisp is a liitle bit
> weird because of the implied else and the fact that the parens seem to
> be in weird places to the uninitated. The C is mostly decipherable.
> Notice by the way that the C has exactly as many parens as the Lisp,
> but vastly more total punctuation.

I like Dylan better than C:

if (foo())


print "baz"
else
print "bar"

end

(Or, of course, a factored version)

It would be even better IMHO if it used a "then" keyword instead of
parens like C, but even so it's nice and less error-prone to not have to
have all the {}

-- Bruce

Marcel Hendrix

unread,
Sep 1, 2001, 4:15:00 AM9/1/01
to

E. wrote:

> Forth: (forgive me if I get the details wrong here, my Forth is rusty)
> foo if "bar" print else "baz" print then

As a phrase, most people would write:

foo IF s" bar" ELSE s" baz" ENDIF type

or

foo IF s" bar"
ELSE s" baz"
ENDIF type

-marcel

Andreas Klimas

unread,
Sep 1, 2001, 8:19:00 AM9/1/01
to

may I give a Smalltalk example here

self foo
ifTrue: [Transcript nextPutAll: 'baz']
ifFalse: [Transcript nextPutAll: 'bar']

but in normal case, in Smalltalk you would refaktor to

outputString
^self foo
ifTrue: ['baz']
ifFalse: ['bar']

Transcript nextPutAll: self outputString

--
Andreas Klimas

Cliff Crawford

unread,
Sep 1, 2001, 8:54:15 AM9/1/01
to
* Erann Gat <g...@flownet.com> menulis:
| ... The Forth seems pretty cryptic by

| comparison. What's that 'then' doing by itself off at the end?
| Postfix is very unintuitive to most people because it has no analog in
| natural language. You can say "a plus b" to mirror infix, or "the sum
| of a and b" to mirror prefix, but "a and b, the sum of those things"
| sounds awfully contrived.

Actually, natural languages which have SOV (Subject-Object-Verb) word
order are just as common (if not more so!) than SVO languages. Speakers
of these languages would find it more natural to say "a b plus" or "a b
add".


--
Cliff Crawford :: http://www.sowrong.org/
"Sheila can keep the balloons away." -- Thomas

Jerry Avins

unread,
Sep 1, 2001, 1:50:58 PM9/1/01
to
Erann Gat wrote:
>
...

>
> Forth: (forgive me if I get the details wrong here, my Forth is
> rusty)
> foo if "bar" print else "baz" print then
>
Only a bit of rust, but let's polish it"

foo if "bar" else "baz" then print
>
> ... The Forth seems pretty cryptic by


> comparison. What's that 'then' doing by itself off at the end?

Does "then" still seem misplaced?

...

It really is a matter of knowing the language. Etiquette is a perfectly
good word both in French and in English. However, the two meanings
differ greatly. The meaning of "then" in Forth is altogether different
from it's meaning in, say, BASIC, even though both meanings have their
root in English. The meaning most programmers expect is consequence:

IF the moon is made of green cheese, THEN I'm a monkey's uncle. Laugh.

Forth, being simpler, omits the "con", and uses "then" merely to
indicate sequence:

IF the moon is made of green cheese, I'm a monkey's uncle. THEN laugh.

THEN in Forth is similar to CONTINUE in Fortran. Strangeness is a
consequence of unfamiliarity.

Teemu Kalvas

unread,
Sep 1, 2001, 2:22:34 PM9/1/01
to
cj...@nospam.cornell.edu (Cliff Crawford) writes:

> * Erann Gat <g...@flownet.com> menulis:
> | ... The Forth seems pretty cryptic by
> | comparison. What's that 'then' doing by itself off at the end?
> | Postfix is very unintuitive to most people because it has no analog in
> | natural language. You can say "a plus b" to mirror infix, or "the sum
> | of a and b" to mirror prefix, but "a and b, the sum of those things"
> | sounds awfully contrived.
>
> Actually, natural languages which have SOV (Subject-Object-Verb) word
> order are just as common (if not more so!) than SVO languages. Speakers
> of these languages would find it more natural to say "a b plus" or "a b
> add".

According to David Crystal (The Cambridge Encyclopedia of Language,
Cambridge University Press 1987, p. 98) the three most common
transitive phrase orders are SOV, SVO and VSO in that order. Together
they make up about 90% of the languages of the world. There are
numerous and important borderline cases, like Latin which can use any
of the six variations depending on the needs and likes of the speaker,
and Chinese (I'm on a weak branch here: I don't know any Chinese and
am just forwarding from linguistics literature) which is sort of SOV
now and SVO then.

However: I do not think that the grammar of a programmer's native
language has much to do in his taste for grammars of programming
languages. A programmer will know mathematics, and algebra looks
pretty much the same all over the world. I would hazard an uninformed
guess (based on a sample of one mind only: mine) that people think
about mathematics and natural languages in completely different ways,
and think about programming like they think about mathematics, not
like they think about natural languages. Programming is in the end
about rigour, which natural language is not about, much to the
detriment of lawyers, engineers and scientists everywhere.

So, I do not think that a decision between liking

a b plus
(+ a b)
a + b;

is based on the programmer's first language grammar.

Actually now that I stopped to think about it, I see no reason to make
a judgement of esthetics between pre, post and infix in expressions.
Features that appeal or repel my sense of esthetics in programming
languages tend to have larger scope. Micro-optimizing esthetics is as
much a waste of time as micro-optimizing anything.

--
Teemu Kalvas

Michael L Gassanenko

unread,
Sep 1, 2001, 3:11:22 PM9/1/01
to
Forth is a language with tunable syntax.
I mean, with Forth you can define your own
syntax and use it.

In Lisp there are macros. Do people claim
that Lisp code with macros is unreadable?
Do people claim that macro definitions
are unreadable? (esp., the ` @ ,@ stuff)

Julian Fondren

unread,
Sep 2, 2001, 1:13:47 AM9/2/01
to
cj...@nospam.cornell.edu (Cliff Crawford) wrote in message news:<XT4k7.413520$T97.50...@typhoon.nyroc.rr.com>...

> * Erann Gat <g...@flownet.com> menulis:
> | ... The Forth seems pretty cryptic by
> | comparison. What's that 'then' doing by itself off at the end?
> | Postfix is very unintuitive to most people because it has no analog in
> | natural language. You can say "a plus b" to mirror infix, or "the sum
> | of a and b" to mirror prefix, but "a and b, the sum of those things"
> | sounds awfully contrived.
>
> Actually, natural languages which have SOV (Subject-Object-Verb) word
> order are just as common (if not more so!) than SVO languages. Speakers
> of these languages would find it more natural to say "a b plus" or "a b
> add".

A few days ago I saw a commercial, in which a man walks out of a building
saying, "rain, stop" as he does so. The rain stops. He goes to cross
a street and says, "traffic, yield" and all the cars stop for him to pass.
This goes on and the commercial reveals this "subject, verb" to be the
syntax for car's voice control ("CD, play"). This is a commercial shown
to Americans, so apparently /someone/ thinks that the verb at the end
isn't too unnatural, at least for commands.

As to the far above, the IF THEN syntax of Forth has been talked about
to death. I think best representation is

<statement> IF <true-act> ELSE <false-act> THEN <continue>

Anyway, it has become 'natural' enough to me that I resist the teensy
effort required to have IF ENDIF instead. That people worry about this
word or the default RPN arithmetic of Forth still amazes me -- it sounds
like people would rather shoot down Forth on trivialities than expend
effort in learning about Forth. Maybe it's just that these people are
neophobes. I don't understand them at all.

Bart Lateur

unread,
Sep 2, 2001, 6:06:54 AM9/2/01
to
Thomas F. Burdick wrote:

>> Why do seemingly intelligent people say such idiotic things like "____ is an
>> unreadable language"????
>
>Why is a statement like "Perl is an unreadable language" idiotic?

>Languages optimize for different things. Perl,
>which seems to optimize for the output of a monkey given a typewriter
>being a valid program, I find unreadable.

Your statement is exactly the kind of idiotic statement that the whole
thread is about.

Perl is by design no more unreadable than Lisp, which seems to be your
pet language.

--
Bart.

Bruce McFarling

unread,
Sep 2, 2001, 2:44:50 AM9/2/01
to
On 31 Aug 2001 21:55:47 -0700, g...@flownet.com (Erann Gat) wrote:

>Forth: (forgive me if I get the details wrong here, my Forth is
>rusty)
>foo if "bar" print else "baz" print then

>The Forth seems pretty cryptic by comparison. What's that 'then'

>doing by itself off at the end?

Try presenting the others unstructured, or presenting the Forth
structured. You convey the structure (to the uninitiated) in others
with layout, but not with Forth. Say

foo if
"bar" print
else
"baz" print
then

and even if the then at the end is clearly not what you are expecting,
it IS fairly clearly the end of structure word to someone used to
structured languages in general.

(
----------
Virtually,

Bruce McFarling, Newcastle,
ec...@cc.newcastle.edu.au
)

Ken Peek

unread,
Sep 2, 2001, 10:12:48 AM9/2/01
to
Yep! Macros should be used ONLY when it makes the code MORE readable. This is
a rare condition indeed. I have seen code with over use of macros, and wanted
to hunt down the originator of that code and slap them until they quit wiggling!

Use macros for non-portable things like I/O port reading and writing. This will
allow for only one place in the code that needs to be changed to move an I/O
address.

Otherwise, each programmer should be forced to write a 50000 word essay on WHY
they NEED the macro before they are allowed to use it in their code!

"Michael L Gassanenko" <m_l...@yahoo.com> wrote in message
news:b5ecdf44.01090...@posting.google.com...

Erik Naggum

unread,
Sep 2, 2001, 11:21:02 AM9/2/01
to
* Erann Gat

> The Forth seems pretty cryptic by comparison. What's that 'then' doing
> by itself off at the end?

Pardon me, but when you learn a language, you learn a language, and when
you know a language, you know a language. It really is this trivial.

If you neither learn it nor know it, what business do you have commenting
on it at all? Do you think languages are designed for its non-users? Do
you think anyone _cares_ what non-users think about their languages? You
behave just like those immature tourists who visit foreign countries and
laugh at street names, signs in shop windows and newspaper headlines.
Imagine someone calling German "pretty cryptic" and "what's that verb
doing by itself off at the end?" Germans have no problem with it, so
what _is_ the big deal to you?

> Postfix is very unintuitive to most people because it has no analog in
> natural language. You can say "a plus b" to mirror infix, or "the sum
> of a and b" to mirror prefix, but "a and b, the sum of those things"
> sounds awfully contrived.

Just because you never figured out how to use RPN calculators does not
mean you have any right to make universal statements like "unintuitive"
and "unreadable" or "cryptic". Some of us find infix unnatural and both
prefix and postfix equally easy to deal with. Some of us are simply able
to learn things quickly becase we can accept what we get on its own terms
and premises. If you cannot do that, do not blame what you have not been
able to learn and internalize because of a childish desire to ridicule
things before you understand them.

The real question when it comes to using a language is whether you are
able to _think_ in it. If you cannot _think_ in the language, you are
bound to run into so many problems that it is entirely irrelevant which
language you are not thinking in.

I find it rather curious that you should wake up from a long absence and
start bad-mouthing not only Common Lisp, but Forth and a bunch of other
languages, too. Do you seriously believe this is smart? Do you actually
believe every language should be for everybody, that are no differences
among people that manifest themselves in how they prefer to think and
write when they want to express their problem-solving abilities? Do you
think there are no problems that lend themselves to particular languages?
All of this flies in the face of the genesis and evolution of languages,
so all you do with your inflammatory nonsense is to look like a moron in
_several_ language communities. What is this good for, Erann Gat?

///

Kaz Kylheku

unread,
Sep 2, 2001, 11:36:52 AM9/2/01
to
In article <tp4fj1m...@corp.supernews.com>, Ken Peek wrote:
>Yep! Macros should be used ONLY when it makes the code MORE readable. This is
>a rare condition indeed. I have seen code with over use of macros, and wanted
>to hunt down the originator of that code and slap them until they quit wiggling!
>
>Use macros for non-portable things like I/O port reading and writing. This will
>allow for only one place in the code that needs to be changed to move an I/O
>address.

You must be writing from the comp.lang.forth camp. In Lisp, macros are used
to create new sublanguages.

Even if the macros are hard to read, if the language they create greatly
simplifies some programming tasks, those macros are justifiable.

You will often find that what a few thousand lines of ```cryptic''
macros accomplish would require hundreds of thousands of lines in some
other programming languages, if indeed it could be done at all.

>Otherwise, each programmer should be forced to write a 50000 word essay on WHY
>they NEED the macro before they are allowed to use it in their code!

When you create a new sublanguage, it is certainly useful to document
its syntax and semantics! And of course, not every programming problem
deserves its own sublanguage.

I don't think that mature programmers need to write long essays justifying
to morons what they do.

Kaz Kylheku

unread,
Sep 2, 2001, 11:43:05 AM9/2/01
to
In article <tp4fj1m...@corp.supernews.com>, Ken Peek wrote:
>Yep! Macros should be used ONLY when it makes the code MORE readable. This is
>a rare condition indeed. I have seen code with over use of macros, and wanted
>to hunt down the originator of that code and slap them until they quit wiggling!
>
>Use macros for non-portable things like I/O port reading and writing. This will
>allow for only one place in the code that needs to be changed to move an I/O
>address.

You must be writing from the comp.lang.forth camp. In Lisp, macros are used
to create new sublanguages.

Even if the macros are hard to read, if the language they create greatly
simplifies some programming tasks, those macros are justifiable.

You will often find that what a few thousand lines of ```cryptic''
macros accomplish would require hundreds of thousands of lines in some
other programming languages, if indeed it could be done at all.

>Otherwise, each programmer should be forced to write a 50000 word essay on WHY


>they NEED the macro before they are allowed to use it in their code!

When you create a new sublanguage, it is certainly useful to document


its syntax and semantics! And of course, not every programming problem

deserves its own sublanguage. Documentation will allow other people to
use the sublanguage without having to decipher it from the implementation.

I don't think that mature programmers can be forced to write unnecessarily
long essays justifying to morons what they do. If you make up such rules,
then you will simply lose good programmers, and be left with those who will
do anything they are told, no matter how unreasonable, to hang on to their job.

Ken Peek

unread,
Sep 2, 2001, 4:26:16 PM9/2/01
to
Ahh--

I see! So you a a TROLL!!!

Don't you have anything better to do? News groups are for sharing ideas, and
getting help on things-- You are obviously an adolescent, at least mentally,
and have nothing better to do than post to news groups to see if you can stir up
trouble.

YOU sir, are not just a troll, but you are also an ASS...

My news reader has a nice filter built into it for chumps like you-- welcome to
my "Blocked Senders List"...

"Kaz Kylheku" <k...@ashi.footprints.net> wrote in message
news:dssk7.130336$B37.2...@news1.rdc1.bc.home.com...

Bernd Paysan

unread,
Sep 1, 2001, 5:59:42 PM9/1/01
to
James Hague wrote:
> Try writing Ackermann's function in Forth without locals, for example.

Ackermann converts nicely to Forth:

: ack ( m n -- ack )
over 0= IF 1+ nip EXIT THEN
dup 0= IF drop 1- 1 recurse EXIT THEN
>r dup 1- swap r> 1- recurse recurse ;

Tail recursion (recurse+EXIT converts to a goto) would be nice to
optimize it.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

Bernd Paysan

unread,
Sep 1, 2001, 5:53:35 PM9/1/01
to
Teemu Kalvas wrote:
> and Chinese (I'm on a weak branch here: I don't know any Chinese and
> am just forwarding from linguistics literature) which is sort of SOV
> now and SVO then.

Chinese is pretty strict SVO, and it must, because there's little other
indication whether a word is verb or not other than the position within
the sentence. However, using terms like "subject", "verb" or "object" is
a bit alien to Chinese, because after all, it's a concatenative language
(like Forth), where you can put words together quite freely, and they'll
make sense, though (what sense depends on the order and somewhat on the
guesswork of the listener).

Kaz Kylheku

unread,
Sep 2, 2001, 5:05:09 PM9/2/01
to
In article <tp55fbb...@corp.supernews.com>, Ken Peek wrote:
>Ahh--
>
>I see! So you a a TROLL!!!
>
>Don't you have anything better to do? News groups are for sharing ideas, and
>getting help on things-- You are obviously an adolescent, at least mentally,
>and have nothing better to do than post to news groups to see if you can stir up
>trouble.

You made the ridiculous assertion that a programmer be required to write
a 50,000 word essay to justify the use of a single macro. Criticizing
such a ridiculous assertion does not make me a troll. In fact, it is that
original assertion which is the true flamebait.

Please say something intelligent to remove my suspicion that you are
suffering from some irrational phobia of macros. Is there a *technical*
reason why a macro should be accompanied by 50,000 lines of explanation
and justification?

>YOU sir, are not just a troll, but you are also an ASS...

Note that the distinction usually goes to the first one to use the word.

William Tanksley

unread,
Sep 2, 2001, 6:46:28 PM9/2/01
to
On Sun, 02 Sep 2001 15:43:05 GMT, Kaz Kylheku wrote:
>In article <tp4fj1m...@corp.supernews.com>, Ken Peek wrote:
>>Yep! Macros should be used ONLY when it makes the code MORE readable. This is
>>a rare condition indeed. I have seen code with over use of macros, and wanted
>>to hunt down the originator of that code and slap them until they quit wiggling!

>You must be writing from the comp.lang.forth camp.

No! Forth is even more prone to use macros than is Lisp (and that's one
of Lisp's greatest strengths). Lisp talks about metaprogramming (and, to
be fair, uses it a LOT), but the most-used metaprogramming language in the
world is more similar to Forth than Lisp.

I don't want to sound like I'm slamming Lisp; Lisp is extremely cool, and
has many more features than its justly-famed metaprogramming support. But
Forth is at least as good for metaprogramming, and I'd say more.

>In Lisp, macros are used to create new sublanguages.

Well said.

>Even if the macros are hard to read, if the language they create greatly
>simplifies some programming tasks, those macros are justifiable.

More than simplifying programming tasks, the goal should be to make the
terminology of the problem domain simple to express. Ideally, a person
who understands the problem and solution but not Lisp (or Forth) should be
able to read over the part of the code which expresses the problem and
solution.

>I don't think that mature programmers can be forced to write unnecessarily
>long essays justifying to morons what they do. If you make up such rules,
>then you will simply lose good programmers, and be left with those who
>will do anything they are told, no matter how unreasonable, to hang on to
>their job.

I think the no-macros philosophy is a leftover from C. Their macros
really ARE poisonous. (Although this is not entirely fair: even in C
macros are useful, and only extremism forbids them.)

--
-William "Billy" Tanksley

Bernd Paysan

unread,
Sep 2, 2001, 5:44:44 PM9/2/01
to
Kaz Kylheku wrote:
> You must be writing from the comp.lang.forth camp. In Lisp, macros are used
> to create new sublanguages.

Can't be. In Forth, compiler extensions (immediate words, postpone, and
create-does>, parsing words) are used to create new sublanguages. We do
with some hundret lines what other people can only do by inventing a new
language, and writing a complete compiler (ok, except those who use Lisp
;-).

I think trolling like this comes from the traditional language camp,
where compiler extensions are not possible. Language extensions must be
documented with much more care than normal code, though.

Coby Beck

unread,
Sep 2, 2001, 7:11:28 PM9/2/01
to

"Kaz Kylheku" <k...@ashi.footprints.net> wrote in message
news:dssk7.130336$B37.2...@news1.rdc1.bc.home.com...
> In article <tp4fj1m...@corp.supernews.com>, Ken Peek wrote:
> >Yep! Macros should be used ONLY when it makes the code MORE readable.
This is
> >a rare condition indeed. I have seen code with over use of macros, and
wanted
> >to hunt down the originator of that code and slap them until they quit
wiggling!
> >
> >Use macros for non-portable things like I/O port reading and writing.
This will
> >allow for only one place in the code that needs to be changed to move an
I/O
> >address.
>
> You must be writing from the comp.lang.forth camp. In Lisp, macros are
used
> to create new sublanguages.
>

Sure they are, but Lisp macros are used for lots of things! This includes
things that bring the benefit of more readable code (such as creating
sub-languages : ). Things like with-open-file just hide the nuts and bolts
of opening and closing files so you can focus on the meaningful bits (as
coder and as reader!)

Coby

--
(remove #\space "coby . beck @ opentechgroup . com")


Erann Gat

unread,
Sep 2, 2001, 7:27:56 PM9/2/01
to
Erik Naggum <er...@naggum.net> wrote in message news:<32084328...@naggum.net>...

> * Erann Gat
> > The Forth seems pretty cryptic by comparison. What's that 'then' doing
> > by itself off at the end?
>
> Pardon me, but when you learn a language, you learn a language, and when
> you know a language, you know a language. It really is this trivial.

The question at hand was why Forth is *perceived* by some people as
being hard to maintain. I didn't mean to say that Forth *was*
objectively cryptic. I was merely engaging in (admittedly poorly
informed) speculation about why some people might find it cryptic.

> If you neither learn it nor know it, what business do you have commenting
> on it at all?

I believe that people have the right to make statements about things
even if they aren't authorities. But just to set the record straight:
I haven't used Forth in many years. I cannot comment on Forth
authoritatively. Nothing that I say about it should be taken as
anything other than poorly informed opinion. OK?

BTW, since my last posting I've learned that there are natural
languages that map onto Forth better than English, so I'll amend my
earlier statement: Postfix might be less intuitive for English
speakers than prefix or infix because it doesn't map as easily onto
English grammar.

E.

Erik Naggum

unread,
Sep 2, 2001, 7:37:40 PM9/2/01
to
* Erik Naggum

> If you neither learn it nor know it, what business do you have commenting
> on it at all?

* Erann Gat


> I believe that people have the right to make statements about things even
> if they aren't authorities.

Fine with me, but you are not arguing against what I said, which was not
about "authority", but about learning and knowing a language before you
speak about it. Again, you shirk away from what I say to argue for your
own arguments in a void. I wonder who you think you are folling.

Your comments all turn out to be shallow, prejudiced, and _personal_
experiences, with absolutely no claim to universalizability. An old
saying among statisticians is that "from a single data point, you can
extrapolate in any direction". You do that. It is, frankly, annoying.

///

Kaz Kylheku

unread,
Sep 2, 2001, 8:15:55 PM9/2/01
to
In article <1f4c5c5c.01083...@posting.google.com>, Erann Gat wrote:
>"Elizabeth D. Rather" <era...@forth.com> wrote in message news:<3B8FCD31...@forth.com>...

Clarity is a complicated function over a writer, a language and a reader.
These three elements interact in a complex way. Behind any message
there is a body of invisible information: the language itself, its
idioms, a shared body of knowledge between the reader and writer.

Arguments in these types of debates about which language is clearer tend
assume that the the reader should have to do no work, that the writer
cannot find a way to use the language to convey clearly, or that the
message must have an ``obvious'' meaning in the absence of the
any hidden information.

Statements like ``the Forth seems pretty cryptic'' simply say that,
in the writer's view, the communication has broken down somewhere.
That breakdown could be due to the writer, the language or the reader,
or in all three to varying degrees. It's impossible to tell where,
because the dependence of clarity on the reader makes the observation
entirely subjective. It could be that another reader will find the
constuct perfectly transparent, because that reader will find in the
message some common idiom, or some triggers which instantly connect
with something familiar and so on.

To eliminate that subjective element, an expert reader is required.
One who knows the language inside out: and not only the language but its
surrounding culture and idioms. When such a reader decides that a program
is unreadable, that seems to shift the blame to the writer. Or perhaps
to the language. When can the language be blamed on poor clarity? Perhaps
when an expert writes something that is intended to be clear, yet an
expert reader finds it unclear. But even then, perhaps the lack of
clarity can be blamed on the complexity of the message. Only if two
experts cannot achieve clarity in communicating a trivial message to
each other can one tentatively conclude that the language itself is
getting in the way of communication.

So I can agree with you that the Forth looks difficult to *me*,
but I have no doubt that if I spent a few weeks using Forth, I'd
be able read it without effort.

> What's that 'then' doing by itself off at the end?
>Postfix is very unintuitive to most people because it has no analog in
>natural language.

Sure it does, topicalization: movement of syntactic units to the front
of a clause. Speak like Yoda, you soon will! :)

The word ``then'' sometimes finds itself at the end of a clause.
``You don't want the soup or the salad? What will you order, then?''

Thomas F. Burdick

unread,
Sep 2, 2001, 9:56:21 PM9/2/01
to
Bart Lateur <bart....@skynet.be> writes:

Gee, thanks for quoting the whole context:

> Common Lisp, which optimizes for expressiveness, I generally find to
> be readable. You can certainly write unreadable code in Lisp, and
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> it's sort-of possible to write readable Perl, but I don't think that
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> detracts from the usefullness of the generalization.

So, do you really think that language designers can *not* make choices
to make their language more readable or less readable? Now *that*
would be an idiotic statement. I'll not put it in your mouth if you
don't actually believe it; but if you don't, how else can you make the
above assertion: "Perl is by design no more unreadable than Lisp" ?
That needs an aweful lot of justification.

Michael L Gassanenko

unread,
Sep 2, 2001, 11:42:29 PM9/2/01
to
"Ken Peek" <Ken....@SpiritSongDesigns.comNOSPAM> wrote in message news:<tp4fj1m...@corp.supernews.com>...

> Yep! Macros should be used ONLY when it makes the code MORE readable. This is
> a rare condition indeed. I have seen code with over use of macros, and wanted
> to hunt down the originator of that code and slap them until they quit wiggling!
>

Well, I believe you. But a statement like "I hate/love macros"
is nothing more than a flame bait.

What charged you with negative emotions could not be just macros;
what property the code written with macros had?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I repeat:
Can you please explain, what was so bad in the code written
with macros? It cannot be just macros themselves.

> Use macros for non-portable things like I/O port reading and writing. This will
> allow for only one place in the code that needs to be changed to move an I/O
> address.

Constants are often used in such circumstances (at least, in Forth and C):

(define iobase 12345)
(define port0 (+ iobase 0))
(define port1 (+ iobase 1))

One of possible uses of macros in C++ is:

#define SUPER TheNameOfSomeClass

OTOH, some people use to declare "super" in class's namespace...


As to new languages, I used Forth and C macro-tools to have
both compilers load some .h file. (That file contained some
declaration needed by both C code and Forth code; such approach
allowed to avoid the problem of synchronization of C and Forth
declarations. Yes, spaces (Forth words are usually delimited by spaces)
were required in some places where they
would not be needed in just C++.)

You see, I have just named two more possible uses of macros:
1) compensation of language weaknesses
2) interaction between two languages, that is, sharing code
by two compilers (e.g. Forth and C++).

>
> Otherwise, each programmer should be forced to write a 50000 word essay on WHY
> they NEED the macro before they are allowed to use it in their code!
>
> "Michael L Gassanenko" <m_l...@yahoo.com> wrote in message
> news:b5ecdf44.01090...@posting.google.com...
> > Forth is a language with tunable syntax.
> > I mean, with Forth you can define your own
> > syntax and use it.
> >
> > In Lisp there are macros. Do people claim
> > that Lisp code with macros is unreadable?
> > Do people claim that macro definitions
> > are unreadable? (esp., the ` @ ,@ stuff)

regards, M.G.

--
I knew a person who was allergic to BASIC. At least that person
was indeed allergic, and BASIC was indeed used in that room.
(No, that person was not allergic *only* to BASIC,
but this [almost?] never happens with allergy).

Erann Gat

unread,
Sep 3, 2001, 3:10:55 AM9/3/01
to
Erik Naggum <er...@naggum.net> wrote in message news:<32084626...@naggum.net>...

> * Erik Naggum
> > If you neither learn it nor know it, what business do you have commenting
> > on it at all?
>
> * Erann Gat
> > I believe that people have the right to make statements about things even
> > if they aren't authorities.
>
> Fine with me, but you are not arguing against what I said, which was not
> about "authority", but about learning and knowing a language before you
> speak about it.

Wow, three non-sequiturs in one sentence. That's got to be some kind
of record.

1. You're right, I wasn't arguing against what you said. So?

2. Fine. I believe people have a right to talk about things about
which they know absolutely nothing. I believe people have a right to
talk about anything they want to. So?

3. I wasn't actually talking about the language, so everything you
said is irrelevant. I was talking about people's perception of the
language, which is not the same thing.

E.

Michael L Gassanenko

unread,
Sep 3, 2001, 3:24:06 AM9/3/01
to
"Kurt B. Kaiser" <k...@shore.net> wrote in message news:<3B8D14E1...@shore.net>...
> IMO, well written Lisp is the most legible of all programming
> languages. I've seen descriptions of satellite communication systems presented
> in conference viewfoils using Lisp which were more effective than block
> diagrams. The design just jumped off the page at you!

Ability to use a word that is defined below contributes a lot
to Scheme (Lisp) readability.

DEFERred words do not compensate the lack of forward referencing.
(You do by hands what the compiler could/should do.)

William Tanksley

unread,
Sep 3, 2001, 3:38:11 AM9/3/01
to

:-)

That's postfix, but it's not Forth. Forth has no syntactic units; as
such, it's an entirely different genre of computer language. Lisp and C
and APL are closer to each other than any of them are to Forth.

Since Forth is such a different language, it's reasonable to note that
some things are harder to express in Forth than they are in any other
traditional language: for instance, it's hard to manipulate a function
together with its parameters, because functions aren't syntactically tied
to their parameters in Forth. It's also neccesary to note that many
things are dramatically easier in Forth: for instance, it's trivial to
refactor a function simply by cutting and pasting, and it's trivial to
build a reader macro which has full Turing-complete power, yet doesn't
interfere with any of the rest of the language.

I'm of the opinion that Forthlike languages have a LOT to offer language
design, but they simply haven't been studied at all yet. The first paper
I saw on the topic I saw only recently, at
http://www.latrobe.edu.au/www/philosophy/phimvt/j00syn.html (I liked it so
much I started an egroup about it).

--
-William "Billy" Tanksley

Marcel Hendrix

unread,
Sep 3, 2001, 3:51:48 AM9/3/01
to
"Michael L Gassanenko" <m_l...@yahoo.com> wrote in message news:b5ecdf44.01090...@posting.google.com...
[..]

> Ability to use a word that is defined below contributes a lot
> to Scheme (Lisp) readability.

> DEFERred words do not compensate the lack of forward referencing.
> (You do by hands what the compiler could/should do.)

Hmm, I never missed this feature. Does having it influence one's style?

Some Forths (CHForth?) define unknown words as stubs that print an error
message when run (to make the compiler continue and catch more bugs). The
compiler could be modified to revector such words when a real definition
is given later on. I don't like this, perhaps irrationally. The first thing
I'd do after a compile is check for such forwards to see if all were caught.
(running the application is no guarantee all paths with stubs in it will be
exercised immediately). Maybe Coos Haak can comment?

-marcel

Bruce R. McFarling

unread,
Sep 3, 2001, 7:46:28 AM9/3/01
to
On Mon, 3 Sep 2001 09:51:48 +0200, "Marcel Hendrix" <m...@iae.nl>
wrote:

I would only want it if it was within some defined modular structure,
and if the unknown word first utilised in that module had to be
defined by the end of the module or else generate the kind of

? shazzzlebom

error that we all know and love (BTW: note the erronious extra z in
shazzlebom above).

With that to keep it tame, I can see how it could help readability.
Really, though, it could be replaced by a pretty printer that knew how
to rotate definitions within a section and sections within a file.

Gary Chanson

unread,
Sep 3, 2001, 6:55:59 AM9/3/01
to

"Marcel Hendrix" <m...@iae.nl> wrote in message
news:3b9336dd$0$219$4d4e...@read-nat.news.nl.uu.net...

I have a mechanism like this in Quest32. If FORWARD-REFERNECES is
enabled, unknown words are tracked and linked when defined. If you try to
SAVE the program, discard the symbol table, or execute an incomplete
reference, an error message is displayed. The test can, of course, also be
explicitly invoked.

The biggest problem I had to solve was displaying an appropriate error
message that points the programmer to the first instance of an incomplete
reference (probably a typo!).

--

-GJC
-gcha...@shore.net

-Abolish Public Schools.


Julian Fondren

unread,
Sep 3, 2001, 9:07:37 AM9/3/01
to
m_l...@yahoo.com (Michael L Gassanenko) wrote in message news:<b5ecdf44.01090...@posting.google.com>...

(snip)

> Ability to use a word that is defined below contributes a lot
> to Scheme (Lisp) readability.

How do you figure? When I programmed with Scheme, I ordered my
code in much the same way I order Forth today. When I didn't
do this, I didn't order my code at all, and it was hardly more
readable. I suppose that I could've put a 'main' sort of
definition up at the top of the file, but this is little benefit
to this. I'd do better to put the rest of the definitions in
another file and (use-modules) them.

> DEFERred words do not compensate the lack of forward referencing.
> (You do by hands what the compiler could/should do.)

It's trivial to have the this done for you -- that such as a
feature has not been widely implemented probably has much to
do with the rare use of DEFER and the therefore pointless
overhead of the feature.

It's odd to see this from someone I thought a CLF regular...

Anton Ertl

unread,
Sep 3, 2001, 9:53:42 AM9/3/01
to
In article <98fae5ec.01082...@posting.google.com>,
dona...@hotmail.com (Don) writes:
>My experience is based on the following scenario which I suspect is
>shared by many others.
>1. A product is designed by myself and/or others.
>2. It is installed & commissioned & we don't see it again for ages
>beyond possible annual service checks. We go & do a million & one
>other things, a small portion of which is actually writing code.
>3. 5 years later it requires changes or decides to do something
>bizarre.
>4. At 2am in the morning when the line stops someone has to bounce out
>& implement & test the changes/fix.
>
>Having to go back & analyse the entire app to try to 'regain the
>mindset' to attempt to find out what the heck is happening is not a
>wonderful economic strategy.

It may well be, because trying to change the program without
understanding it well enough certainly leads to disaster. Typically,
though, I only have to regain the mindset for only a part of the
program.

Now, wrt your scenario above, I maintain and work with Forth code
written by me and others more than five years ago, and I find most of
the code pretty maintainable. However, some of it is hard to
understand (and consequently, to maintain), mostly because of
programming style issues (long definitions, lack of stack comments and
descriptive comments).

Since I am also posting this to c.l.lisp, I also have a Lisp story to
tell: The largest Lisp program I ever wrote was the original version
of prims2x/vmgen, which I wrote in Elisp, because of its text
processing capabilities. After a few years, I rewrote it in Forth,
mainly because of changes in the case handling of the Elisp functions
the program used (in one Emacs version it was unpredictable what case
the output would have).

Concerning maintainability, the Elisp version was hard to adapt to
changing needs; I attribute this to the design and style of the
program: I tried to keep to a functional style, but apparently did so
in the wrong way, and changes typically required passing stuff across
a number of functions and the additional data could not be just tacked
on existing data, so it required additional parameters. You can
attribute this to my inexperience in Lisp (or maybe just a bad design
decision in general), but if I was after a flamewar, I would attribute
it to Lisp:-).

The Forth version uses about a dozen global variables for these tasks,
and was easier to maintain for a long time (contrary to established
wisdom about global variables). But of course in the end I wanted to
do a change for which the global variables proved to be a problem, and
now the Forth version is quite messy. I believe that the original
functional approach would not have survived that change at all, though.

Crossposted to clf, cll.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html

Anton Ertl

unread,
Sep 3, 2001, 10:00:21 AM9/3/01
to
In article <1f4c5c5c.01083...@posting.google.com>,

g...@flownet.com (Erann Gat) writes:
>foo if "bar" print else "baz" print then
...

> The Forth seems pretty cryptic by
>comparison. What's that 'then' doing by itself off at the end?

That's a FAQ, of course, and the answer is:

5.4. Why does THEN finish an IF structure?

Some people find the way THEN is used in Forth unnatural, others do
not.

According to Webster's New Encyclopedic Dictionary, "then" (adv.) has
the following meanings:

2b: following next after in order ... 3d: as a necessary
consequence (if you were there, then you saw them).

Forth's THEN has the meaning 2b, whereas THEN in Pascal and other pro-
gramming languages has the meaning 3d.

If you don't like to use THEN in this way, you can easily define ENDIF
as a replacement:

______________________________________________________________________
: ENDIF POSTPONE THEN ; IMMEDIATE
______________________________________________________________________

See my .sig for answers to other c.l.f FAQs.

Followups to clf.

Kurt B. Kaiser

unread,
Sep 3, 2001, 2:05:12 PM9/3/01
to
Kaz Kylheku wrote:
> Sure it does, topicalization: movement of syntactic units to the front
> of a clause. Speak like Yoda, you soon will! :)

EXTERIOR: DAGOBAH--DAY

With Yoda strapped to his back, Luke climbs up one of the many thick vines
that grow in the swamp until he reaches the Dagobah statistics lab.
Panting heavily, he continues his exercises--grepping, installing new
packages, logging in as root, and writing replacements for two-year-old
shell scripts in Python.

YODA: Code! Yes. A programmer's strength flows from code
maintainability, but beware of Perl. Terse syntax... more than one
way to do it... default variables. The dark side of code
maintainability are they. Easily they flow, quick to join you when
code you write. If once you start down the dark path, forever will
it dominate your destiny, consume you it will.

LUKE: Is Perl better than Python?

YODA: No... no... no. Quicker, easier, more seductive.

LUKE: But how will I know why Python is better than Perl?

YODA: You will know. When your code you try to read six months from now.

-- Lorrie Wood

Hmmm. Harumph.

--
K u r t B. K a i s e r
k b k @@ s h o r e .. n e t
------------------------------

William Tanksley

unread,
Sep 3, 2001, 2:35:18 PM9/3/01
to
On Sat, 01 Sep 2001 05:35:41 +1200, Bruce Hoult wrote:
>g...@flownet.com (Erann Gat) wrote:

>> > The point being, that "readability" of any language requires some
>> > familiarity with that language.

>Not necessarily. I've several times developed an algorithm in Dylan and
>then as an experiment given the source code to someone who has never
>seen Dylan (but knows, say, C or Java well) without even commenting on
>what language the code is in. No one has ever had any problems with it.
>OTOH, I don't do this with stupid people :-)

True. Languages *can* be designed to be readable by non-programmers who
have specific training. I've handed in working Python code as the
response to a pseudocode assignment (I left out some function definitions,
so they couldn't run it, but I had written them and tested the whole
thing), and I have no doubt that someone familiar with pseudocode but not
python would imagine that it was actually pseudocode.

The trick is to choose what specific training you want your proofreader to
have. With Forth, you want them to be trained in the problem (and
wsolution) area, not in reading pseudocode. Like Lisp, Forth is all about
building micro-languages in which the problem can be expressed naturally.
Unlike most modern languages, Forth's flow of execution is purely
left-to-right, ensuring that you don't have to introduce the proofreader
to thre concept of argument evaluation and function calls.

>> Right. That said, I don't think that all languages are equally
>> readable. Compare:

>> Lisp:
>> C:

A terrible example. Who cares about such trivial things? No domain
expert is going to; only an undergrad could care. And why should I care
whether my code can be read by an undergrad?

>I think PostScript is better:
>foo
> [(baz) print]
> [(bar) print]
>ifelse

It's great, until either block gets at all complicated. I actually prefer
the PS style, but practically, it has a lot of problems.

>> Python:
>> if foo():
>> print "baz"
>> else:
>> print "bar"
>> I think Python has a clear edge in readbility.

>It's readable, but I think *far* too dangerous to allow to live. The
>bugs caused by misplaced semicllons and parens are legion.

Where on earth did you hear this? Did you just make it up today? Python
has no mandatory semicolons, and the colons are mandatory and absolutely
redundant (so it's impossible to leave them out and not get a syntax error
pointing to the problem). And what's this about parens? I can't even
imagine what class of problems you're talking about.

>Editing accidents that leave indentation mangled are far more likely to
>happen, and thee is no redundancy so nothing can warn you about it.

Absolutely false. Mangling indentation is possible, although I've never
done it nor talked to any Python programmer who has, but there is LOTS of
redundancy for the compiler to catch. There are even tabchackers which
make sure you're not using tabs in any possibly confusing ways
(officially, tabs are discouraged because different editors see them
differently; however, there are some simple rules which make them
unambiguous).

>-- Bruce

--
-William "Billy" Tanksley

Thomas F. Burdick

unread,
Sep 3, 2001, 3:00:18 PM9/3/01
to
an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:

> Concerning maintainability, the Elisp version was hard to adapt to
> changing needs; I attribute this to the design and style of the
> program: I tried to keep to a functional style, but apparently did so
> in the wrong way, and changes typically required passing stuff across
> a number of functions and the additional data could not be just tacked
> on existing data, so it required additional parameters. You can
> attribute this to my inexperience in Lisp (or maybe just a bad design
> decision in general), but if I was after a flamewar, I would attribute
> it to Lisp:-).
>
> The Forth version uses about a dozen global variables for these tasks,
> and was easier to maintain for a long time (contrary to established
> wisdom about global variables). But of course in the end I wanted to
> do a change for which the global variables proved to be a problem, and
> now the Forth version is quite messy. I believe that the original
> functional approach would not have survived that change at all, though.

If global variables are used to maintain global state, I don't see any
problem with them. Like almost every other programming tool with a
bad reputation, their infamy comes from misuse. FWIW, it sounds like
you just wanted to use global (or maybe buffer-local) variables in the
Elisp version -- something that's done all the time.

John A. Peters

unread,
Sep 3, 2001, 3:21:48 PM9/3/01
to
WOW! (positive flames) This idea sounds super great. I had tried to
write something like that below when I was Disk Librarian of SVFIG in
the 80ies.
I would like to use the "TOOL CHAIN (FORTH)" on some of the Forth's
that I use like Win32Forth. Is it a commercial product or an
extension to Forth or what? please expound more.

jape...@pacbell.net

Stephen Pelc wrote:
<snip snip>
> Over the last three years we have switched over to a tool
> chain (Forth) which extracts documentation as formal
> comments from the source code and then generates HTML
> and/or PDF manuals. The effect of this has been to
> encourage our own programmers and our clients to write
> the documentation as the code is written.
>
> When we looked at literate programming tools some years
> ago, the problem was that the source for the compiler and
> the documentation could get out of step. In our system there
> is only ever one file, and the documentation is contained
> within formal comments.
>
> Stephen

Marcel Hendrix

unread,
Sep 3, 2001, 3:49:50 PM9/3/01
to
(#57972) Bernd Paysan <bernd....@gmx.de> writes Re: Maintaining Minority Languages

> Ackermann converts nicely to Forth:

> : ack ( m n -- ack )
> over 0= IF 1+ nip EXIT THEN
> dup 0= IF drop 1- 1 recurse EXIT THEN
> >r dup 1- swap r> 1- recurse recurse ;

> Tail recursion (recurse+EXIT converts to a goto) would be nice to
> optimize it.

Note the reversed stack effect.

: ack ( n1 n2 -- n ) RECURSIVE
DUP 0= IF DROP 1+ EXIT ENDIF
OVER 0= IF NIP 1 SWAP 1- ack EXIT ENDIF
SWAP 1- OVER ack
SWAP 1- ack ;

\ run ack(3,8) and print result from stack
: MAIN ( n -- )
CR TIMER-RESET
." Ack(3," DUP 1 U.R ." ): " ( n) 3 ack 1 U.R
"," EMIT SPACE .ELAPSED ;

( 269 ms on P54C 166 MHz, 34 ms on Athlon 900 MHz )

$004B4178 : ack
$004B417E test [esp], -1 d#
$004B4185 jne $004B4198 offset
$004B418B add esp, 4 b#
$004B418E inc [esp]
$004B4191 ;
$004B4198 test 4 [esp], -1 d#
$004B41A0 jne $004B41CA offset
$004B41A6 pop ebx
$004B41A7 add esp, 4 b#
$004B41AA push ebx
$004B41AB mov ebx, [esp]
$004B41AE mov eax, 1 d#
$004B41B3 mov [esp], eax
$004B41B6 dec ebx
$004B41B7 push ebx
$004B41B8 jmp ack+6 offset
$004B41BD ;
$004B41C4 nop
$004B41C5 jmp $004B41EB offset
$004B41CA pop ebx
$004B41CB mov ecx, [esp]
$004B41CE dec ecx
$004B41CF mov [esp], ebx
$004B41D2 push ecx
$004B41D3 push ebx
$004B41D4 call ack offset
$004B41D9 mov ecx, [esp]
$004B41DC mov ebx, 4 [esp]
$004B41E0 add esp, 8 b#
$004B41E3 dec ebx
$004B41E4 push ecx
$004B41E5 push ebx
$004B41E6 jmp ack+6 offset
$004B41EB ;

Your version is about 348 ms on the P54C, with iForth.

-marcel

Bruce Hoult

unread,
Sep 3, 2001, 4:16:33 AM9/3/01
to
In article <slrn9p7jb5....@dolphin.openprojects.net>,
wtan...@bigfoot.com wrote:

> >I think PostScript is better:
> >foo
> > [(baz) print]
> > [(bar) print]
> >ifelse
>
> It's great, until either block gets at all complicated. I actually
> prefer the PS style, but practically, it has a lot of problems.

Such as?


> >> Python:
> >> if foo():
> >> print "baz"
> >> else:
> >> print "bar"
> >> I think Python has a clear edge in readbility.
>
> >It's readable, but I think *far* too dangerous to allow to live. The
> >bugs caused by misplaced semicllons and parens are legion.
>
> Where on earth did you hear this? Did you just make it up today? Python
> has no mandatory semicolons, and the colons are mandatory and absolutely
> redundant (so it's impossible to leave them out and not get a syntax
> error pointing to the problem). And what's this about parens? I
> can't even imagine what class of problems you're talking about.

I'm talking about *other* languages.

Python has a serious dangling else problem with no redundancy that I can
see. If Python used, for example, some sort of "endif" then the
indentation would be redundant (as in other languages), but without it
it's not.


> >Editing accidents that leave indentation mangled are far more likely to
> >happen, and thee is no redundancy so nothing can warn you about it.
>
> Absolutely false. Mangling indentation is possible, although I've never
> done it nor talked to any Python programmer who has

Well no one is going to admit it, are they? They'll make the mistake,
and then track down the bug and go "Geez I'm bone-headed, what a
beginner mistake to make" and they'll never mention it to anyone else,
thinking that no one else is making the same error. When all along
people *will* be making the mistake because the language is worse
designed than it needs to be.

-- Bruce

Kaz Kylheku

unread,
Sep 3, 2001, 4:48:20 PM9/3/01
to
In article <bruce-EC56FC....@news.akl.ihug.co.nz>, Bruce Hoult wrote:
>Python has a serious dangling else problem with no redundancy that I can
>see. If Python used, for example, some sort of "endif" then the
>indentation would be redundant (as in other languages), but without it
>it's not.

How can Python have a dangling else problem, when the nesting level of
every statement is deducible from its indentation?

if foo
if bar
this
else
that

The indendation clearly indicates that the else goes with the innermost
if. If you change the indentation like this, it will go with
the outer if:

if foo
if bar
this
else
that

Or not? What facts am I missing?

>> >Editing accidents that leave indentation mangled are far more likely to
>> >happen, and thee is no redundancy so nothing can warn you about it.
>>
>> Absolutely false. Mangling indentation is possible, although I've never
>> done it nor talked to any Python programmer who has
>
>Well no one is going to admit it, are they? They'll make the mistake,
>and then track down the bug and go "Geez I'm bone-headed, what a

Careless editing mistakes can cause damage to a program in any language.
The risk of a careless edit is minimized by using a version control
system. Or at least maintaining backups of your working sources.

Coos Haak

unread,
Sep 3, 2001, 5:30:47 PM9/3/01
to

Marcel Hendrix <m...@iae.nl> schreef in berichtnieuws
3b9336dd$0$219$4d4e...@read-nat.news.nl.uu.net...
I still do use this feature, but nearly only when compiling a bad designed
program (my programs or some examples found here).
After compilation I look in the error.log file to lookup if there were
forward references. So it's more or less a development tool.
I got some complaints from users of CHForth.
I think hard about removing it, adding a enabling flag (see Gary's answer)
is perhaps too confusing, yet another state to remember ;-(

Coos

Bruce Hoult

unread,
Sep 3, 2001, 5:54:16 AM9/3/01
to
In article <o0Sk7.133928$B37.3...@news1.rdc1.bc.home.com>,
k...@ashi.footprints.net wrote:

> In article <bruce-EC56FC....@news.akl.ihug.co.nz>, Bruce Hoult
> wrote:
> >Python has a serious dangling else problem with no redundancy that I can
> >see. If Python used, for example, some sort of "endif" then the
> >indentation would be redundant (as in other languages), but without it
> >it's not.
>
> How can Python have a dangling else problem, when the nesting level of
> every statement is deducible from its indentation?

No, it is not deducible from its indentation, it is *defined* by its
indentation. And indentation is a very fragile thing.

if foo
if bar
this
else
that

theother <= here
somemore

There are three different levels to which the line marked "<= here" can
be indented without causing a compile error. That's dangerous.


> Careless editing mistakes can cause damage to a program in any language.

And careless driving can cause a smash in any car. That doesn't mean
that it's a *good* idea to drive with bald tyres and no brakes.


Twenty years ago I thought I was a pretty hot programmer who never made
mistakes. Now I'm a much better programmer and I don't take *anything*
for granted that I don't absolutely have to, and I make use of every aid
to catching dumb mistakes that I can. Redundancy is the prime tool.
Program structure is specified *both* with syntactical tokens *and* with
indenting, and I prefer to use languages where you can explicitly say
"end foo" and the compiler checks that it is really "foo" that you
should be ending at that point. I declare variables to be of particular
types, and then expect that the machine will tell me (whether at
compile- or run-time) if I try to use them in ways inappropriate to that
type. I use languages that *always* check array bounds, either at
runtime or by my *proving* to the compiler that they will always be
within bounds.

Your philosophy may differ.

-- Bruce

Kaz Kylheku

unread,
Sep 3, 2001, 7:43:52 PM9/3/01
to
In article <bruce-7D918E....@news.akl.ihug.co.nz>, Bruce Hoult wrote:
>In article <o0Sk7.133928$B37.3...@news1.rdc1.bc.home.com>,
>k...@ashi.footprints.net wrote:
>
>> In article <bruce-EC56FC....@news.akl.ihug.co.nz>, Bruce Hoult
>> wrote:
>> >Python has a serious dangling else problem with no redundancy that I can
>> >see. If Python used, for example, some sort of "endif" then the
>> >indentation would be redundant (as in other languages), but without it
>> >it's not.
>>
>> How can Python have a dangling else problem, when the nesting level of
>> every statement is deducible from its indentation?
>
>No, it is not deducible from its indentation, it is *defined* by its
>indentation. And indentation is a very fragile thing.

In what way? Do little green trolls visit your hard disk at night
and fiddle with whitespace?

> if foo
> if bar
> this
> else
> that
> theother <= here
> somemore
>
>There are three different levels to which the line marked "<= here" can
>be indented without causing a compile error. That's dangerous.

I still don't see the alleged dangling else ambiguity. That a program
can be easily edited to create a program with a different meaning is
obvious, but I was hoping that you could provide some information to
support your claim that Python has a dangling else.

>> Careless editing mistakes can cause damage to a program in any language.
>
>And careless driving can cause a smash in any car. That doesn't mean
>that it's a *good* idea to drive with bald tyres and no brakes.

Note that ill-conceived car analogies don't cut it in an erudite forum
such as the comp.lang.lisp newsgroup. Call me stupid, but I don't see
a clear-cut isomorphism between driving and programming, and between
indentation-sensitivity and bald tires.

Programmers use indentation even in programming languages where it
is not required. By reading and writing programs that obey certain
indentation rules, we get used to reading the indentation. So if there is
some mistake caused by a construct having a different meaning from what
is suggested by its indentation, that mistake can be difficult to spot.

The rationale behind making indentation significant appears sound: it
eliminates the potential for writing a program whose indentation
suggests a different program, thereby eliminating a class of
programming errors.

Note that I have no experience with Python or any other language which
treats indentation in a similar way. If I ever acquire as much experience
with Python as you have, I will be able to properly evaluate the alleged
risks caused by its whitespace sensitivity, and be in a much better position
to debate them.

I was only curious about the dangling else.

William Tanksley

unread,
Sep 3, 2001, 8:27:32 PM9/3/01
to
On Mon, 03 Sep 2001 20:16:33 +1200, Bruce Hoult wrote:
>wtan...@bigfoot.com wrote:

>> >I think PostScript is better:
>> >foo
>> > [(baz) print]
>> > [(bar) print]
>> >ifelse

>> It's great, until either block gets at all complicated. I actually
>> prefer the PS style, but practically, it has a lot of problems.

>Such as?

Such as trying to read code where the block structure is nested or long.
It's not polite to place the parameters too far away from the functions
which need them, even though the language (PS and Forth) allow it.

Consider it: the block appears with no warning, with no way to tell how
it's doing to be used. Anything can happen inside the block. Then
another block comes, again without preliminary explanation. Again, this
block can be arbitrarily long and contain anything. Finally you get your
'ifelse' which is supposed to explain what the blocks are for (unless, of
course, the ifelse is factored into another word).

Again, I'm a Forth and Postscript fan, and for a number of theoretical
reasons I prefer PS blocks to Forth IFs. But you can't deny the problems!

>> >> I think Python has a clear edge in readbility.
>> >It's readable, but I think *far* too dangerous to allow to live. The
>> >bugs caused by misplaced semicllons and parens are legion.

>> Where on earth did you hear this? Did you just make it up today? Python
>> has no mandatory semicolons, and the colons are mandatory and absolutely
>> redundant (so it's impossible to leave them out and not get a syntax
>> error pointing to the problem). And what's this about parens? I
>> can't even imagine what class of problems you're talking about.

>Python has a serious dangling else problem with no redundancy that I can


>see. If Python used, for example, some sort of "endif" then the
>indentation would be redundant (as in other languages), but without it
>it's not.

And in the other languages, the 'endif' isn't redundant. There are no
languages I know of which use both indentation and delimiters. You get to
choose which thing you want to delimit your blocks: either a glyph which
requires you to read the code to see, or a complete indentation structure
which merely requires a glance.

>> >Editing accidents that leave indentation mangled are far more likely to
>> >happen, and thee is no redundancy so nothing can warn you about it.

>> Absolutely false. Mangling indentation is possible, although I've never
>> done it nor talked to any Python programmer who has

>Well no one is going to admit it, are they? They'll make the mistake,
>and then track down the bug and go "Geez I'm bone-headed, what a
>beginner mistake to make" and they'll never mention it to anyone else,
>thinking that no one else is making the same error. When all along
>people *will* be making the mistake because the language is worse
>designed than it needs to be.

An interesting hypothesis. Can you confirm it, or is it inherently
unconfirmable? Perhaps I can't speak for other Python programmers, but as
for myself, I've never had an indentation-related bug. Never once. The
question has come up before on comp.lang.python, and there are perhaps two
replies which claim that they have found an indentation bug in their code.
In my memory, nobody has ever claimed to find an indentation bug in
someone else's code (and, again, we've searched for such things).

The problem is that indentation is such an /obvious/ feature of a program;
it's immediately visible. Indentation mistakes are /not/ subtle. This is
why C's if/if/else problem is so severe: people assume that the
indentation tells the whole story, when in reality the else always matches
the inner if.

In Python, the indentation always /does/ tell the entire story.

William Tanksley

unread,
Sep 3, 2001, 8:34:43 PM9/3/01
to
On Mon, 03 Sep 2001 21:54:16 +1200, Bruce Hoult wrote:
>k...@ashi.footprints.net wrote:

>type. I use languages that *always* check array bounds, either at
>runtime or by my *proving* to the compiler that they will always be
>within bounds.
>Your philosophy may differ.

Or his methods may differ. As do mine; as do the methods of most of the
people in the two NGs to which your comments are posted. Lisp, unlike
Forth, can be statically typechecked; however, as a matter of convention,
it isn't. By your argument, then, we're all foolhardy souls, certain in
our hubris that we never make mistakes.

No.

We test and embed our tests in the code, we write short definitions, we
prove our algorithms... We do all kinds of things to ensure our code
works. When we do use strict typechecking compilers, we continue to do
pretty much the same things. You should, too.

Michael Coughlin

unread,
Sep 3, 2001, 9:04:58 PM9/3/01
to
Bernd Paysan wrote:
>
> Michael Coughlin wrote:
> > Forth is code. A code is not supposed to be read.
> > Its as simple as that. If I say C = 1/2 x A x B, you
> > woun't know what I mean. If I say the area of a triangle
> > is 1/2 x A x B, or one half the altitude times the base,
> > you might remember your lesson from grade school.
>
> That's because the variable names A, B, and C are
> meaningless names, not because the formula is unreadable
> by itself. I can understand somehow why one uses A and B
> for base and height (though b and h would be more
> obvious), but C for area is completely off. Why don't
> you write area=1/2*base*height? There are few languages
> around that limit you to one-letter variables, and even
> then, there are probably better suggestions than A, B,
> and C.

You see part of my point, and not the other. Of course the
variable names A, B, and C are meaningless names. That's why I
picked them. I also claim that the formula C = 1/2 x A x B is
also meaningless by itself. It doesn't make any difference what
letters you use or what symbols you use to signify
multiplication. It is only when you can associate those letters
with the idea of finding the area of a triangle that the formula
can have any meaning.

Its the same with computer programs. You have to know what
you are going to compute before you can read and understand a
program's source code. I have spent countless hours going over
somebody's source and asking "What was he trying to do?" I'll
never forget one particular example. I spent a day or two
looking over a program and figured out everything except for one
puzzling section. At last I realized that section was
numerically evaluating an integral. There was a bug in it
somewhere. So I just cut out that whole thing and rewrote it
using a much better and clearer method. Problem solved. I also
included comments stating the obvious facts about numerical
integration, what method I used, what textbook I looked it up
in, and so on. If another programmer came along later and didn't
like my method, he could change it right away, without puzzling
over it for days.

We've got a whole swarm of messages on comp.lang.forth about
which cryptic computer language constructs are easy and hard to
read. People are getting angry at each other. And they are
missing the whole point of commenting source code. You have to
write down uncoded things like "Compute the Area of a Triangle",
or "Numerically Evaluate the Value of an Integral", or even
"Compute the Areas of Triangles to Numerically Evaluate the
Value of an Integral".

Naturally there is a lot more to writing good programs. But
I've found all the problems I had learning to program went away
with experience and practice, except for the one above.

--
Michael Coughlin m-cou...@ne.mediaone.net Cambridge, MA USA

Bruce Hoult

unread,
Sep 3, 2001, 9:29:12 AM9/3/01
to
In article <slrn9p87vj....@dolphin.openprojects.net>,
wtan...@bigfoot.com wrote:

> On Mon, 03 Sep 2001 20:16:33 +1200, Bruce Hoult wrote:
> >wtan...@bigfoot.com wrote:
>
> >> >I think PostScript is better:
> >> >foo
> >> > [(baz) print]
> >> > [(bar) print]
> >> >ifelse
>
> >> It's great, until either block gets at all complicated. I actually
> >> prefer the PS style, but practically, it has a lot of problems.
>
> >Such as?
>
> Such as trying to read code where the block structure is nested or long.
> It's not polite to place the parameters too far away from the functions
> which need them, even though the language (PS and Forth) allow it.
>
> Consider it: the block appears with no warning, with no way to tell how
> it's doing to be used. Anything can happen inside the block. Then
> another block comes, again without preliminary explanation. Again, this
> block can be arbitrarily long and contain anything. Finally you get your
> 'ifelse' which is supposed to explain what the blocks are for (unless, of
> course, the ifelse is factored into another word).

The boolean expression sitting in front of it tend to be a bit of a
clue, but yes, it's certainly more error-prone than most languages and
the only real way to avoid it is to only write quite short blocks.


> >Python has a serious dangling else problem with no redundancy that I can
> >see. If Python used, for example, some sort of "endif" then the
> >indentation would be redundant (as in other languages), but without it
> >it's not.
>
> And in the other languages, the 'endif' isn't redundant. There are no
> languages I know of which use both indentation and delimiters. You get
> to choose which thing you want to delimit your blocks: either a glyph
> which requires you to read the code to see, or a complete indentation
> structure which merely requires a glance.

There are no languages which require it, but there are plenty of tools
which work with the redundancy, generally by calculating and displaying
the logical indentation from a given program structure. This ranges all
the way from Think Pascal in which the programmer has no choice but to
allow the editor to format the code, to emacs modes which indent when
you press tab or semicolon or other "electric" keys, to batch
reformatters (emacs again and pretty-printers).

I don't know how many times I've gotten to the end of a function in Lisp
or C or anything else supported by an emacs mode and found that I've
either hit the left margin before I've finished the function, or else
that I've finished the function but am still indented a bit. Ineitably
it's some simple typo, and fairly often one that the compile would
quickly catch. But not always, and you get to see the problem right
away.


> >Well no one is going to admit it, are they? They'll make the mistake,
> >and then track down the bug and go "Geez I'm bone-headed, what a
> >beginner mistake to make" and they'll never mention it to anyone else,
> >thinking that no one else is making the same error. When all along
> >people *will* be making the mistake because the language is worse
> >designed than it needs to be.
>
> An interesting hypothesis. Can you confirm it, or is it inherently
> unconfirmable?

Unrefutable, I'd say :-) I know that I make that sort of error all the
time in other languages, so I don't see why I wouldn't in Python. But
then maybe I'm just a worse than average programmer and the rest of you
are Gods? Certainly I know I have limitations and I know that I need
ways to try to allow for them, and having both tokens and indentation to
show structure helps me do that, as do type declarations and checks and
array bounds declarations and checks.

-- Bruce

Bruce Hoult

unread,
Sep 3, 2001, 9:57:18 AM9/3/01
to
In article <slrn9p88d2....@dolphin.openprojects.net>,
wtan...@bigfoot.com wrote:

> On Mon, 03 Sep 2001 21:54:16 +1200, Bruce Hoult wrote:
> >k...@ashi.footprints.net wrote:
>
> >type. I use languages that *always* check array bounds, either at
> >runtime or by my *proving* to the compiler that they will always be
> >within bounds.
> >Your philosophy may differ.
>
> Or his methods may differ. As do mine; as do the methods of most of the
> people in the two NGs to which your comments are posted. Lisp, unlike
> Forth, can be statically typechecked; however, as a matter of convention,
> it isn't.

Not statically, no, but it *is* totally typechecked. Like PostScript
but unlike Forth.


> By your argument, then, we're all foolhardy souls, certain in
> our hubris that we never make mistakes.
>
> No.
>
> We test and embed our tests in the code, we write short definitions, we
> prove our algorithms... We do all kinds of things to ensure our code
> works. When we do use strict typechecking compilers, we continue to do
> pretty much the same things. You should, too.

I do. And that's why by the time my code gets to the customer there are
almost *never* any bugs. It's a point of pride with me that the QA
people don't find anything wrong. I know most people at the places I
work don't care, and I guess that's why I get called in as a consultant
to fix their messes.

Take the ICFP contest, for example. OK, last year my team didn't
*quite* get the raytracer finished, with cones and CSG not completed,
but everything we *did* do worked fine. This year I got my SML/NG
optimizer done, was fearlessly tweaking it up to the last five minutes,
and submitted it in the last seconds (entry #249, the last entry
accepted). It proved to be bug-free, robust, pretty fast, and a pretty
good optimizer and ended up in the prize money.

And it seems appropriate to point out that no dynamically-typed language
has *ever* previously finished in the money in the ICFP contest, and
certainly nothing from the Lisp family. It's not from lack of trying --
this year there were five teams that submitted entries using Common Lisp
and six teams that used Scheme. None appear to have made the top couple
of dozen places.

Why is that, for a language that is so good at rapid development of
complex algorithms?

-- Bruce

Michael L Gassanenko

unread,
Sep 3, 2001, 11:02:37 PM9/3/01
to
nos...@ecbm.at.cc.newcastle.edu.au (Bruce R. McFarling) wrote in message news:<3b936cb6...@news.newcastle.edu.au>...

> On Mon, 3 Sep 2001 09:51:48 +0200, "Marcel Hendrix" <m...@iae.nl>
> wrote:
>
> >"Michael L Gassanenko" <m_l...@yahoo.com> wrote in message news:b5ecdf44.01090...@posting.google.com...
> >[..]
> >> Ability to use a word that is defined below contributes a lot
> >> to Scheme (Lisp) readability.
>
> >> DEFERred words do not compensate the lack of forward referencing.
> >> (You do by hands what the compiler could/should do.)
> >
> >Hmm, I never missed this feature.

Me too. Or did not realize that.

> > Does having it influence one's style?

No, I do not think so. It's an instrument having which
may be to advantage or disadvantage.

How it may be used to advantage:

You have a one-screen definition that expresses
the main idea. Then, you provide the details.

I have seen a Scheme program written like that. (I do not
remember what it was.)

When I write Forth programs on paper, I usually
first write the main routine then provide the details.
(Well, debugging indeed cannot be performed in this order,
but it's a different issue.)
When I type in the programs written on the paper,
I rearrange the code so that the details go first.

There is also a rule that Forth programs should be read
from the end. (Because the main idea word follows the details.)

Unfortunately, for big programs this rule does not work well.
Probably, because in the end go wrappers.
Or because there are many "main ideas".
Or because these ideas have to interfere somehow.

> >
> >Some Forths (CHForth?) define unknown words as stubs that print an error
> >message when run (to make the compiler continue and catch more bugs). The
> >compiler could be modified to revector such words when a real definition
> >is given later on. I don't like this, perhaps irrationally. The first thing
> >I'd do after a compile is check for such forwards to see if all were caught.
> >(running the application is no guarantee all paths with stubs in it will be
> >exercised immediately). Maybe Coos Haak can comment?

I used a cross-compiler with forward references...
Well, it was not what I would like to have.
Instead of "undefined" it reported unresolved references,
and I wanted to disable that feature. (Here I agree with Coos Haak.)

>
> I would only want it if it was within some defined modular structure,
> and if the unknown word first utilised in that module had to be
> defined by the end of the module or else generate the kind of
>
> ? shazzzlebom
>
> error that we all know and love (BTW: note the erronious extra z in
> shazzlebom above).

I think of something like this:

\ =======================================================
\ sample code: FOO BAR
\ shows the use of forward references
uses: how should done
uses: this be
uses: that

: FOO how this should be done ;
: BAR how that should be done ;

\ =======================================================
\ verbs

: be ... ;
: done ... ;
: should ... ;

\ =======================================================
\ pronouns

: this ... ;
: that ... ;

\ =======================================================
\ the only adverb

: how ... ;

\ =======================================================

As to some modular structure... well, with DEFERred words
we do not miss it.

>
> With that to keep it tame, I can see how it could help readability.
> Really, though, it could be replaced by a pretty printer that knew how
> to rotate definitions within a section and sections within a file.

IMO, there are two problems that may be solved by such

forward references:

1) to arrange the code within a single file in the way
that loks most natural

2) to place code in files according to how the words
are related and not in which order they must be loaded.

Example.
There is a real program, a cross-compiler. There are some
DEFERred words introduced solely for the purpose of forward
referencing, and some files split to avoid forward references.

regards, MLG

It is loading more messages.
0 new messages