A small survey (if you have couple of minutes)

25 views

Richard Krush

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

rk

Erann Gat

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

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

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.

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

rk

Erann Gat

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

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.

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

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

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

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

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

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

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

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

--
Bart.

Bruce McFarling

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

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

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

Erik Naggum

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

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

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

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

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

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

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

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

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