A small survey (if you have couple of minutes)

25 views
Skip to first unread message

Richard Krush

unread,
Aug 25, 2001, 11:02:00 PM8/25/01
to
Hello!

Please excuse me if this type of articles are not welcome here, but I
would like to ask you one question which gives me troubles in my
"intrahead" debates about whether to invest more time in learning LISP
or just continue with C or another popular language.

I know that LISP is very successfuly used in a few complex industrial
programs (and if believe the list on www.lisp.org, many more I've never
head of) as well as several userland applications such as EMACS. I also
know LISP can be used as THE most powerful scripting language instead
of shell scipting or even Perl/Python.

What I would like to know is what uses do you (meaning people who post
in this group or read it) use LISP for?

Thank you for your time,
rk

Erann Gat

unread,
Aug 26, 2001, 2:27:00 AM8/26/01
to
rich...@gmx.net (Richard Krush) wrote in message news:<slrn9ogpo9.2...@localhost.localnet>...
> Hello!

Hi Richard!

> Please excuse me if this type of articles are not welcome here, but I
> would like to ask you one question which gives me troubles in my
> "intrahead" debates about whether to invest more time in learning LISP
> or just continue with C or another popular language.

No apologies needed. This is a perfectly fine article.

> I know that LISP is very successfuly used in a few complex industrial
> programs (and if believe the list on www.lisp.org, many more I've never
> head of) as well as several userland applications such as EMACS. I also
> know LISP can be used as THE most powerful scripting language instead
> of shell scipting or even Perl/Python.
>
> What I would like to know is what uses do you (meaning people who post
> in this group or read it) use LISP for?

Lisp was the third programming language I learned, after Basic and
Pascal. I first used it in 1981 on an Apple II, and I've been
programming in it ever since. In college I used it for just about
everything, including my CS class assignments. My colleagues worked
in Pascal mostly (this was when C was just beginning to get popular,
and Bjarne Stroustrup had not yet invented C with objects, which would
later become C++). They would work on a typical assignment for days
and turn in code printouts that were many inches thick. I would work
for an hour or two and turn in code that only took up a few pages.
(And I got A's.)

From 1988 to about 1992 I used Lisp to program a series of research
robots that eventually led to the Sojourner Rover on the Mars
Pathfinder mission. (Sojourner itself was programmed in C.) The
robots themselves did not run Lisp, their processors were too small
(8-bit processors with only a few k of RAM). Instead I used Lisp to
write a compiler for a custom-designed robot programming language that
compiled to machine code for the robot's processors. Writing the
compiler took only a couple of weeks (and would have only taken a
couple of days if I'd actually known what I was doing).

In 1993 I used Lisp to program a robot for the AAAI mobile robot
contest. I started working on the code for the contest on the flight
to the conference. The total time I spent coding was three (very
intense) days. I took a first and a second place, competing against
teams of programmers working for weeks or months in C.

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 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.)

From 1995 to about 1998 I was part of a team using Lisp to program an
autonomous spacecraft (a project called Remote Agent which flew on a
spacecraft called DS1). At one point part of the team tried to
re-implement their part of the software in C++. After a year the
effort was declared a failure and they went back to Lisp.

In 2000 as an excercise I wrote a fully functional Web server in Lisp.
It took me about a month. It includes GET and POST methods, file
upload capability, user authentication, in short, just about
everything (except documentation).

I've written cryptography code, and robot and spacecraft simulators in
Lisp.

In short, I've used Lisp to do just about everything.

Erann Gat
g...@flownet.com

Eric Moss

unread,
Aug 26, 2001, 1:02:49 PM8/26/01
to
Erann Gat wrote:
> [... lots of cool lisp projects ...]

We should get this published--everything from white papers to graffiti
artists blanketing the urban centers. :)

Seriously, there are a few pages here and there mentioning apps being
programmed in lisp, but not in great enough quantity or specificity to
convince a manager that LISP is the right tool. LISP is a good language
for all the "standard" projects as well, but it's tough to pitch that
idea when all we can point to is an autonomous art program or vague
references to "hard scientific problems".

Right now I am re-writing a medium (>>50,000 lines) Objective-C
commercial application in Common Lisp. As a metric, one particular
directory (~1600 lines of zero-white-space and zero-comment ObjC)
compresses to ~800 lines of lisp with two blank lines between every
function. Many classes are lists and sets, written in plain C for
"portability". They simply go away, as does so much code that is merely
bookkeeping support for the class hierarchy.

If and when this thing is complete I will provide a blurb about the
results (size, performance, cross-platform issues, etc.) I think it
would be good if everyone did something similar. I bet the results would
be rather formidable.


Eric

Richard Krush

unread,
Aug 26, 2001, 6:10:36 PM8/26/01
to
On Sun, 26 Aug 2001 12:02:49 -0500, Eric Moss wrote:
> Erann Gat wrote:
> > [... lots of cool lisp projects ...]
>
> We should get this published--everything from white papers to graffiti
> artists blanketing the urban centers. :)
>
> Seriously, there are a few pages here and there mentioning apps being
> programmed in lisp, but not in great enough quantity or specificity to
> convince a manager that LISP is the right tool. LISP is a good language
> for all the "standard" projects as well, but it's tough to pitch that
> idea when all we can point to is an autonomous art program or vague
> references to "hard scientific problems".
>

I was thinking about that, if this thread grows a bit, it would be very
beneficial to publish it on some well-known LISP page, such as
Association of LISP Users [1] or Cliki [2]. The first reply by Erann
Gat is already a pretty good advocate for LISP, if more such biographies
would follow, I'm sure it will be enough to convince many people and
companies to try LISP.

[1] http://www.lisp.org http://www.alu.org
[2] http://ww.telent.net/cliki/index

> Right now I am re-writing a medium (>>50,000 lines) Objective-C
> commercial application in Common Lisp. As a metric, one particular
> directory (~1600 lines of zero-white-space and zero-comment ObjC)
> compresses to ~800 lines of lisp with two blank lines between every
> function. Many classes are lists and sets, written in plain C for
> "portability". They simply go away, as does so much code that is merely
> bookkeeping support for the class hierarchy.
>
> If and when this thing is complete I will provide a blurb about the
> results (size, performance, cross-platform issues, etc.) I think it
> would be good if everyone did something similar. I bet the results would
> be rather formidable.
>

I agree here, not only will people see the power of LISP, but they will
also be able to compare it with the "popular" languages.

Thank you for your reply,
rk

Erann Gat

unread,
Aug 27, 2001, 2:39:29 AM8/27/01
to
rich...@gmx.net (Richard Krush) wrote in message news:<slrn9oit1u.3...@localhost.localnet>...

> On Sun, 26 Aug 2001 12:02:49 -0500, Eric Moss wrote:
> > Erann Gat wrote:
> > > [... lots of cool lisp projects ...]
> >
> > We should get this published--everything from white papers to graffiti
> > artists blanketing the urban centers. :)
> >
> > Seriously, there are a few pages here and there mentioning apps being
> > programmed in lisp, but not in great enough quantity or specificity to
> > convince a manager that LISP is the right tool. LISP is a good language
> > for all the "standard" projects as well, but it's tough to pitch that
> > idea when all we can point to is an autonomous art program or vague
> > references to "hard scientific problems".
> >
>
> I was thinking about that, if this thread grows a bit, it would be very
> beneficial to publish it on some well-known LISP page, such as
> Association of LISP Users [1] or Cliki [2]. The first reply by Erann
> Gat is already a pretty good advocate for LISP, if more such biographies
> would follow, I'm sure it will be enough to convince many people and
> companies to try LISP.

Well, I certainly hope you're right, but I'm afraid I don't share your
optimism. The reason companies don't use Lisp is not that there
aren't enough published success stories. The reason companies don't
use Lisp is that a lot of companies *did* try Lisp in the AI boom of
the 1980's and they all went out of business. Perhaps the same thing
will happen to Java with the dotcom bust, but I wouldn't bet on it.
Sun has shown a lot of marketing savvy. Lisp might do well to borrow
a page from their script: whenever Java fails at something they
reposition it to be something else. Remember, Java wasn't always the
server-side Web programming language. It started out as a language
for programming cell phones and copying machines. When it failed at
that Sun repositioned it to be the write-once-run-anywhere language
that would evenutally replace Windows on the desktop. When it failed
at that it was repositioned where it is today, as a server side Web
programming language. When people start to realize it has failed at
that no doubt Sun will reposition it somewhere else.

The problem with Lisp is that it has never been repositioned since it
"failed" as an AI language. I put failed in quotes because it's not
clear that Lisp really failed, but that's irrelevant. In the world of
business, perception is truth. I mean that quite literally. Dollars
have more value than rubles *only* because everyone *thinks* that
dollars have more value than rubles. And because everyone thinks it,
it's actually true. It's the same with programming languages.
Because enough people think that Java is a good language for Web
programming, it actually is. Not from the programmer's point of view,
of course, Java largely sucks. But from a *business* point of view
Java is perfectly fine because Java programmers are a commodity. You
let *them* deal with the sucky aspects of Java. And if one of them
starts to rock the boat by pointing out how Java sucks and Lisp is
better you fire him because he's not a team player. (Lispers are
actually notoriously bad team players precisely because Lisp is such a
great programming language. It tends to attract independent thinkers
because it lets them be much more productive then they could otherwise
be. If there's anyone out there who can figure out how to turn this
into a successful business model he could become fabulously wealthy.)

BTW, if anyone out there thinks I'm wrong and that the only thing
standing between them and having their company using Lisp is a few
success stories, let me know. I'll be happy to provide some. (And if
anyone out there thinks the only thing standing between them and
having their company use Lisp is the availability of Lisp programmers
I'd be happy to provide one or two of those as well.)

Erann
g...@flownet.com

Software Scavenger

unread,
Aug 27, 2001, 6:25:59 AM8/27/01
to
g...@flownet.com (Erann Gat) wrote in message news:<1f4c5c5c.01082...@posting.google.com>...

> BTW, if anyone out there thinks I'm wrong and that the only thing
> standing between them and having their company using Lisp is a few
> success stories, let me know. I'll be happy to provide some. (And if

Why should anyone spend months or years evangelizing Lisp to try to
get their company to rewrite its software in it, when they could just
spend that time rewriting it themselves? If Lisp ever takes over the
world, it's likely to be by a stealth attack from within rather than a
missile attack from without. The evangelist grows a reputation as a
pest, and could get laid off or fired at any random time. The person
who does the work himself grows a reputation as the ultimate company
geek and key employee.

Even better might be to write new apps in Lisp as soon as their need
becomes clear, while the company is still trying to decide how to fill
that need, or even before the need crystalizes enough to become clear.
Once you have enough Lisp apps in daily use by your coworkers, Lisp
will have become one of your company's main programming languages.

The key phrase in the above is "will have become". Trying for Lisp to
get its foot in the door is the wrong approach in most cases. It's
better for it to introduce itself from within, as if it had always
been there.

Tim Bradshaw

unread,
Aug 27, 2001, 6:36:04 AM8/27/01
to
cubic...@mailandnews.com (Software Scavenger) writes:

> Why should anyone spend months or years evangelizing Lisp to try to
> get their company to rewrite its software in it, when they could just
> spend that time rewriting it themselves?

Oh, easy. It's much, much easier to stand around bitching about how,
if only the company did x, then it would make huge money and
everything would be better and so on and so forth, than actually to
sit down and quietly do x. It's especially good to do this when you
are fairly sure that x will not get done, or you can raise convincing
objections to getting it done ('the software is too expensive', 'the
lisp vendors do not support elaborate-protocol-of-the-week', 'loop is
too hard to read', 'my elbow hurts') to avoid your bluff ever being
called.

You have only to read c.l.l for a few weeks to see about 95% of the
posters doing this.

Raymond Wiker

unread,
Aug 27, 2001, 6:41:40 AM8/27/01
to
cubic...@mailandnews.com (Software Scavenger) writes:

> g...@flownet.com (Erann Gat) wrote in message news:<1f4c5c5c.01082...@posting.google.com>...
>
> > BTW, if anyone out there thinks I'm wrong and that the only thing
> > standing between them and having their company using Lisp is a few
> > success stories, let me know. I'll be happy to provide some. (And if
>
> Why should anyone spend months or years evangelizing Lisp to try to
> get their company to rewrite its software in it, when they could just
> spend that time rewriting it themselves? If Lisp ever takes over the
> world, it's likely to be by a stealth attack from within rather than a
> missile attack from without. The evangelist grows a reputation as a
> pest, and could get laid off or fired at any random time. The person
> who does the work himself grows a reputation as the ultimate company
> geek and key employee.
>
> Even better might be to write new apps in Lisp as soon as their need
> becomes clear, while the company is still trying to decide how to fill
> that need, or even before the need crystalizes enough to become clear.
> Once you have enough Lisp apps in daily use by your coworkers, Lisp
> will have become one of your company's main programming languages.

Alternatively, once there is one or more useful/critical
applications written in Common Lisp (or other non-mainstream (i.e, not
C++ or Java)), there will be a project to rewrite it in a different
language. This will take more time than estimated. The result, if it
works at all, will be more difficult to maintain or extend, and the
blame will be laid on the guy who wrote the original implementation...

--
Raymond Wiker
Raymon...@fast.no

Colin Paul Gloster

unread,
Aug 27, 2001, 9:09:59 AM8/27/01
to
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?

"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?

Thanks for the interesting post,
Colin Paul Gloster

Eric Moss

unread,
Aug 27, 2001, 12:11:58 PM8/27/01
to

I would love to quietly just do something in lisp, but for those in a
big corporation, it's not possible without managerial support. We don't
have control over what apps will go on our machines--centralized
sysadmins do, and they often deny requests from our managers. I fought
for 6 months just to get a *newer version* of Python so I could update a
few scripts. To get Allegro or Lispworks on a machine, not only do I
need 3 levels of management to agree, I have to spend my own money on
it, and then they would demand ownership of what I paid for--then they
wouldn't support it. They won't let CMUCL on a machine because it's not
commercially supported, but won't spring $800 to get Lispworks, which
is. They won't provide any support at all until I have a full, working
version DONE and interoperating with apps that took 50 people 10 years
to write.

That leaves my own time to attempt it. Great--not only do I spend 10-12
hours a day on their slop, but just to get any moral support from other
lispers, I have to give up the rest of my waking hours quietly
attempting the impossible. I just don't have the energy left to rewrite
a million lines of crappy code. That's why it was, and is, easier to
"stand around bitching".

It takes a team to do the software that many of us work on, and a team
needs managerial support. In a (big) company, that just doesn't happen
without the pointy-haired guys buying into a concept. That is why
evangelizing is needed, though not enjoyed.

Eric

PS. If we weren't so independent-minded (maybe BECAUSE we are?), I'd say
a bunch of us should come up with a business plan, get funding, and
start our own company. Not that I'm a big fan of companies, but that's
how the existing economic system forces us to play.


--
US Supreme Court hearing 00-836
GEORGE W. BUSH, Petitioner, v. PALM BEACH COUNTY CANVASSING BOARD

Justice (Scalia?) to Mr. Klock (representing Katherine Harris):

20 and therefore, I guess, whether we win, whether your side,
21 the side you're supporting wins or loses, it doesn't
22 change that, and I guess that's moot, but my question is,

Paolo Amoroso

unread,
Aug 27, 2001, 12:00:43 PM8/27/01
to
On 26 Aug 2001 23:39:29 -0700, g...@flownet.com (Erann Gat) wrote:

> BTW, if anyone out there thinks I'm wrong and that the only thing
> standing between them and having their company using Lisp is a few
> success stories, let me know. I'll be happy to provide some. (And if

I don't think that, and I don't currently need to sell Lisp to any company.
But since I am interested in how Lisp is used, I would appreciate it if you
could provide those stories anyway.


Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]

Marc Battyani

unread,
Aug 27, 2001, 1:15:34 PM8/27/01
to

"Eric Moss" <eric...@alltel.net> wrote

> I would love to quietly just do something in lisp, but for those in a
> big corporation, it's not possible without managerial support. We don't
> have control over what apps will go on our machines--centralized
> sysadmins do, and they often deny requests from our managers. I fought
> for 6 months just to get a *newer version* of Python so I could update a
> few scripts.

>...

I had the same problems when I was a research engineer in a Phillips
research lab.
So I quitted and started my own (small!) company. Now I program in Lisp and
VHDL and I can do all the electronics I want.

> PS. If we weren't so independent-minded (maybe BECAUSE we are?), I'd say
> a bunch of us should come up with a business plan, get funding, and
> start our own company. Not that I'm a big fan of companies, but that's
> how the existing economic system forces us to play.

Why do you need a business plan and funding ?
You just need a few contracts to start.

Marc


Eric Moss

unread,
Aug 27, 2001, 4:45:46 PM8/27/01
to
Marc Battyani wrote:
>
> "Eric Moss" <eric...@alltel.net> wrote
>
> > I would love to quietly just do something in lisp, but for those in a
> > big corporation, it's not possible without managerial support. We don't
> > have control over what apps will go on our machines--centralized
> > sysadmins do, and they often deny requests from our managers. I fought
> > for 6 months just to get a *newer version* of Python so I could update a
> > few scripts.
> >...
>
> I had the same problems when I was a research engineer in a Phillips
> research lab.
> So I quitted and started my own (small!) company. Now I program in Lisp and
> VHDL and I can do all the electronics I want.

You did the right thing by starting your own company (you knew that).
You now have managerial support and company funding (yours).


> > a bunch of us should come up with a business plan, get funding, and
> > start our own company.
>

> Why do you need a business plan and funding ?
> You just need a few contracts to start.
>

I suppose it's not strictly necessary to get formal start-up funding,
but one must still convince the client that it will work well for him.
In my case I am slowly winning a client over to lisp, but he won't pay
for it until it's done--a classic catch-22. If I already had funding,
even in the form of personal savings, it would be a different matter.

Eric

Erann Gat

unread,
Aug 27, 2001, 11:34:58 PM8/27/01
to
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.

E.

Erann Gat

unread,
Aug 27, 2001, 11:59:29 PM8/27/01
to
Paolo Amoroso <amo...@mclink.it> wrote in message news:<lluKO=8tiJ7gC4pAs...@4ax.com>...

> On 26 Aug 2001 23:39:29 -0700, g...@flownet.com (Erann Gat) wrote:
>
> > BTW, if anyone out there thinks I'm wrong and that the only thing
> > standing between them and having their company using Lisp is a few
> > success stories, let me know. I'll be happy to provide some. (And if
>
> I don't think that, and I don't currently need to sell Lisp to any company.
> But since I am interested in how Lisp is used, I would appreciate it if you
> could provide those stories anyway.

Hm, perhaps I should have been a little less subtle. Companies don't
use things, particularly out-of-the-mainstream things, just for the
sake of using them. Nor do they use things because they're cool, or
because someone else thinks they're cool, or even because someone else
did some cool things with them. Companies (at least sane companies)
use things for one of two reasons: either they are experiencing some
kind of problem that they have tried and failed to solve by more
conventional means, or they think they will make more money by trying
something new. But the kind of "success story" that's going to
convince a company that something new is going to solve their problem
or make them more money depends on the kind of problem they are
having, or the kind of business they are in. So when I said I'd be
happy to provide success stories what I meant was not that I had this
little bag of them that I'd write up if someone asked me to, what I
meant was that I'd be happy to learn about companies that were
experiencing problems that they thought Lisp might be able to solve
and "provide a success story", a.k.a. help solve their problem. It
was a thinly disguised attempt to flush potential customers or
employers out of the woodwork, not an offer to regale people with my
anecdotes. (In case you hadn't noticed, I already did that.)

E.

Tim Bradshaw

unread,
Aug 28, 2001, 4:33:51 AM8/28/01
to
Eric Moss <eric...@alltel.net> writes:

>
> I would love to quietly just do something in lisp, but for those in a
> big corporation, it's not possible without managerial support. We don't
> have control over what apps will go on our machines--centralized
> sysadmins do, and they often deny requests from our managers. I fought
> for 6 months just to get a *newer version* of Python so I could update a
> few scripts. To get Allegro or Lispworks on a machine, not only do I
> need 3 levels of management to agree, I have to spend my own money on
> it, and then they would demand ownership of what I paid for--then they
> wouldn't support it. They won't let CMUCL on a machine because it's not
> commercially supported, but won't spring $800 to get Lispworks, which
> is. They won't provide any support at all until I have a full, working
> version DONE and interoperating with apps that took 50 people 10 years
> to write.
>

Well, you're cleaerly living in hell, and if it's as nasty as you say
you should get out. Sure, some (not all) large companies are crap in
this way, but the solution is still not to stand around bitching.
Quite apart from anything else if the organisation you work for is as
bad as you describe their just waiting for someone else to eat them
alive... (Of course the middle of a recession may not be the best
time to mmove, I know.)

>
> PS. If we weren't so independent-minded (maybe BECAUSE we are?), I'd say
> a bunch of us should come up with a business plan, get funding, and
> start our own company. Not that I'm a big fan of companies, but that's
> how the existing economic system forces us to play.
>

So long as the business plan isn't 'we'll do cool things in Lisp'.
Too many people seem to think that, or an equivalent, the most recent
being 'we'll do cool things on the web', is enough.

--tim

Tim Bradshaw

unread,
Aug 28, 2001, 4:47:29 AM8/28/01
to
Eric Moss <eric...@alltel.net> writes:

>
> I would love to quietly just do something in lisp, but for those in a
> big corporation, it's not possible without managerial support. We don't
> have control over what apps will go on our machines--centralized
> sysadmins do, and they often deny requests from our managers. I fought
> for 6 months just to get a *newer version* of Python so I could update a
> few scripts. To get Allegro or Lispworks on a machine, not only do I
> need 3 levels of management to agree, I have to spend my own money on
> it, and then they would demand ownership of what I paid for--then they
> wouldn't support it. They won't let CMUCL on a machine because it's not
> commercially supported, but won't spring $800 to get Lispworks, which
> is. They won't provide any support at all until I have a full, working
> version DONE and interoperating with apps that took 50 people 10 years
> to write.
>

Well, you're clearly living in hell, and if it's as nasty as you say


you should get out. Sure, some (not all) large companies are crap in
this way, but the solution is still not to stand around bitching.
Quite apart from anything else if the organisation you work for is as

bad as you describe they're just waiting for someone else to eat them


alive... (Of course the middle of a recession may not be the best
time to mmove, I know.)

>

> PS. If we weren't so independent-minded (maybe BECAUSE we are?), I'd say
> a bunch of us should come up with a business plan, get funding, and
> start our own company. Not that I'm a big fan of companies, but that's
> how the existing economic system forces us to play.
>

So long as the business plan isn't 'we'll do cool things in Lisp'.

Sandeep Koranne

unread,
Aug 28, 2001, 6:34:49 AM8/28/01
to

"Marc Battyani" <Marc.B...@fractalconcept.com> wrote in message
news:257B1ECE69EB71AC.4A7015B5...@lp.airnews.net...

>
> I had the same problems when I was a research engineer in a Phillips
> research lab.
> So I quitted and started my own (small!) company. Now I program in Lisp
and
> VHDL and I can do all the electronics I want.
>

I hate to correct you, but not all of NatLab is like that.
PS: NatLab is the name of Philips Research Labs in Eindhoven, The
Netherlands.

I have been programming in Harlequin LispWorks here in NatLab and have
already made some
nice EDA applications that are in use :) runs on Sun Solaris, HP-UX, Linux
and Windows, uses CAPI.

Its unfair to taint the name of the whole lab just because of your one
(isolated) experience.

Sandeep.


Marc Battyani

unread,
Aug 28, 2001, 7:35:10 AM8/28/01
to

"Sandeep Koranne" <sandeep...@nospam.philips.com> wrote

>
> "Marc Battyani" <Marc.B...@fractalconcept.com> wrote in message
> >
> > I had the same problems when I was a research engineer in a Phillips
> > research lab.
> > So I quitted and started my own (small!) company. Now I program in Lisp
> and
> > VHDL and I can do all the electronics I want.

> I hate to correct you, but not all of NatLab is like that.
> PS: NatLab is the name of Philips Research Labs in Eindhoven, The
> Netherlands.

Why do you think I'm talking about NatLab ?
I didn't give the Lab name nor the year .

> I have been programming in Harlequin LispWorks here in NatLab and have
> already made some
> nice EDA applications that are in use :) runs on Sun Solaris, HP-UX, Linux
> and Windows, uses CAPI.

Great!

> Its unfair to taint the name of the whole lab just because of your one
> (isolated) experience.

I don't see where I tainted a whole lab. I said "I had the same problems",
"I" meaning me not the whole lab....
As it's rather off topic, we should switch to e-mail if you want to discuss
more about this.

Marc


Michael Coughlin

unread,
Aug 28, 2001, 6:56:52 PM8/28/01
to

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?

Paolo Amoroso

unread,
Aug 29, 2001, 7:45:28 AM8/29/01
to
On 27 Aug 2001 20:34:58 -0700, g...@flownet.com (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

[...]


> 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.

Do you mean that the original Forth code used by the Galileo magnetometer
was developed on an Apple II?

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

Erann Gat

unread,
Aug 29, 2001, 5:11:35 PM8/29/01
to
Paolo Amoroso <amo...@mclink.it> wrote in message news:<ka+MOxt9CX0Cg=3UO6c068=Fq...@4ax.com>...

> On 27 Aug 2001 20:34:58 -0700, g...@flownet.com (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
> [...]
> > 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.
>
> Do you mean that the original Forth code used by the Galileo magnetometer
> was developed on an Apple II?

Yep. And the target processor (the one actually in the instrument)
was (and still is ;-) an 1802 with 4k bytes of RAM, 2k of which were
data buffer. (There is also a 4k ROM.)

E.

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: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).

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

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).

--

-GJC
-gcha...@shore.net

-Abolish Public Schools.


Tim Bradshaw

unread,
Aug 30, 2001, 6:04:32 AM8/30/01
to
g...@flownet.com (Erann Gat) writes:

> Yep. And the target processor (the one actually in the instrument)
> was (and still is ;-) an 1802 with 4k bytes of RAM, 2k of which were
> data buffer. (There is also a 4k ROM.)
>

Heh. I have fond memories (alas, undocumented) of working soemwhere
where an 1802-based instrument was being considered by the US DoD.
They tried to insist that the code, to meet DoD standards, should be
either in Ada or FORTRAN 77. I think it had 1 or 2k bytes of ROM full
(really, full: adding new functionality meant reducing the size of
old) of very carefully-written assembler at that point and maybe some
hundreds of bytes of RAM. I think they relaxed the constraint...

--tim

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.

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.

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

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

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.

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.

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)".

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.

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

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: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).

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

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