A small survey (if you have couple of minutes)
Richard Krush
Please excuse me if this type of articles are not welcome here, but I
would like to ask you one question which gives me troubles in my
"intrahead" debates about whether to invest more time in learning LISP
or just continue with C or another popular language.
I know that LISP is very successfuly used in a few complex industrial
programs (and if believe the list on www.lisp.org, many more I've never
head of) as well as several userland applications such as EMACS. I also
know LISP can be used as THE most powerful scripting language instead
of shell scipting or even Perl/Python.
What I would like to know is what uses do you (meaning people who post
in this group or read it) use LISP for?
Thank you for your time,
rk
Erann Gat
> Hello!
Hi Richard!
> Please excuse me if this type of articles are not welcome here, but I
> would like to ask you one question which gives me troubles in my
> "intrahead" debates about whether to invest more time in learning LISP
> or just continue with C or another popular language.
No apologies needed. This is a perfectly fine article.
> I know that LISP is very successfuly used in a few complex industrial
> programs (and if believe the list on www.lisp.org, many more I've never
> head of) as well as several userland applications such as EMACS. I also
> know LISP can be used as THE most powerful scripting language instead
> of shell scipting or even Perl/Python.
>
> What I would like to know is what uses do you (meaning people who post
> in this group or read it) use LISP for?
Lisp was the third programming language I learned, after Basic and
Pascal. I first used it in 1981 on an Apple II, and I've been
programming in it ever since. In college I used it for just about
everything, including my CS class assignments. My colleagues worked
in Pascal mostly (this was when C was just beginning to get popular,
and Bjarne Stroustrup had not yet invented C with objects, which would
later become C++). They would work on a typical assignment for days
and turn in code printouts that were many inches thick. I would work
for an hour or two and turn in code that only took up a few pages.
(And I got A's.)
From 1988 to about 1992 I used Lisp to program a series of research
robots that eventually led to the Sojourner Rover on the Mars
Pathfinder mission. (Sojourner itself was programmed in C.) The
robots themselves did not run Lisp, their processors were too small
(8-bit processors with only a few k of RAM). Instead I used Lisp to
write a compiler for a custom-designed robot programming language that
compiled to machine code for the robot's processors. Writing the
compiler took only a couple of weeks (and would have only taken a
couple of days if I'd actually known what I was doing).
In 1993 I used Lisp to program a robot for the AAAI mobile robot
contest. I started working on the code for the contest on the flight
to the conference. The total time I spent coding was three (very
intense) days. I took a first and a second place, competing against
teams of programmers working for weeks or months in C.
In 1994 I used Lisp to produce a code patch for an instrument on the
Galileo spacecraft in orbit around Jupiter. The instrument (a
magnetometer) was programmed in Forth, and had developed a bad memory
byte (out of a total 4k bytes of memory). It was estimated that to
patch the Forth code (which is notoriously difficult to maintain)
would take so long that it was not feasable. I wrote a customized
Forth development environment in Lisp that was used to produce a code
patch. The total time it took to produce the development environment
and the code patch was three months. (The resulting patch is flying
today. It's the only thing this development environment was ever used
for.)
From 1995 to about 1998 I was part of a team using Lisp to program an
autonomous spacecraft (a project called Remote Agent which flew on a
spacecraft called DS1). At one point part of the team tried to
re-implement their part of the software in C++. After a year the
effort was declared a failure and they went back to Lisp.
In 2000 as an excercise I wrote a fully functional Web server in Lisp.
It took me about a month. It includes GET and POST methods, file
upload capability, user authentication, in short, just about
everything (except documentation).
I've written cryptography code, and robot and spacecraft simulators in
Lisp.
In short, I've used Lisp to do just about everything.
Erann Gat
g...@flownet.com
Eric Moss
> [... 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
> Erann Gat wrote:
> > [... lots of cool lisp projects ...]
>
> We should get this published--everything from white papers to graffiti
> artists blanketing the urban centers. :)
>
> Seriously, there are a few pages here and there mentioning apps being
> programmed in lisp, but not in great enough quantity or specificity to
> convince a manager that LISP is the right tool. LISP is a good language
> for all the "standard" projects as well, but it's tough to pitch that
> idea when all we can point to is an autonomous art program or vague
> references to "hard scientific problems".
>
I was thinking about that, if this thread grows a bit, it would be very
beneficial to publish it on some well-known LISP page, such as
Association of LISP Users [1] or Cliki [2]. The first reply by Erann
Gat is already a pretty good advocate for LISP, if more such biographies
would follow, I'm sure it will be enough to convince many people and
companies to try LISP.
[1] http://www.lisp.org http://www.alu.org
[2] http://ww.telent.net/cliki/index
> Right now I am re-writing a medium (>>50,000 lines) Objective-C
> commercial application in Common Lisp. As a metric, one particular
> directory (~1600 lines of zero-white-space and zero-comment ObjC)
> compresses to ~800 lines of lisp with two blank lines between every
> function. Many classes are lists and sets, written in plain C for
> "portability". They simply go away, as does so much code that is merely
> bookkeeping support for the class hierarchy.
>
> If and when this thing is complete I will provide a blurb about the
> results (size, performance, cross-platform issues, etc.) I think it
> would be good if everyone did something similar. I bet the results would
> be rather formidable.
>
I agree here, not only will people see the power of LISP, but they will
also be able to compare it with the "popular" languages.
Thank you for your reply,
rk
Erann Gat
> 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
> BTW, if anyone out there thinks I'm wrong and that the only thing
> standing between them and having their company using Lisp is a few
> success stories, let me know. I'll be happy to provide some. (And if
Why should anyone spend months or years evangelizing Lisp to try to
get their company to rewrite its software in it, when they could just
spend that time rewriting it themselves? If Lisp ever takes over the
world, it's likely to be by a stealth attack from within rather than a
missile attack from without. The evangelist grows a reputation as a
pest, and could get laid off or fired at any random time. The person
who does the work himself grows a reputation as the ultimate company
geek and key employee.
Even better might be to write new apps in Lisp as soon as their need
becomes clear, while the company is still trying to decide how to fill
that need, or even before the need crystalizes enough to become clear.
Once you have enough Lisp apps in daily use by your coworkers, Lisp
will have become one of your company's main programming languages.
The key phrase in the above is "will have become". Trying for Lisp to
get its foot in the door is the wrong approach in most cases. It's
better for it to introduce itself from within, as if it had always
been there.
Tim Bradshaw
> 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
> 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
wrote about numerous interesting space-related projects, including:
"[..]
In 1994 I used Lisp to produce a code patch for an instrument on the
Galileo spacecraft in orbit around Jupiter. The instrument (a
magnetometer) was programmed in Forth, and had developed a bad memory
byte (out of a total 4k bytes of memory). It was estimated that to
patch the Forth code (which is notoriously difficult to maintain)
would take so long that it was not feasable."
I do not understand this. Why was this Forth source code so hard to maintain?
"I wrote a customized Forth development environment in Lisp that was used to
produce a code patch. The total time it took to produce the development
environment and the code patch was three months. (The resulting patch
is flying today. It's the only thing this development environment was ever used
for.)
[..]"
So was your one-off Forth system superior to the one used earlier?
Thanks for the interesting post,
Colin Paul Gloster
Eric Moss
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
> 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
"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
>
> "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
> 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
> 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
>
> I would love to quietly just do something in lisp, but for those in a
> big corporation, it's not possible without managerial support. We don't
> have control over what apps will go on our machines--centralized
> sysadmins do, and they often deny requests from our managers. I fought
> for 6 months just to get a *newer version* of Python so I could update a
> few scripts. To get Allegro or Lispworks on a machine, not only do I
> need 3 levels of management to agree, I have to spend my own money on
> it, and then they would demand ownership of what I paid for--then they
> wouldn't support it. They won't let CMUCL on a machine because it's not
> commercially supported, but won't spring $800 to get Lispworks, which
> is. They won't provide any support at all until I have a full, working
> version DONE and interoperating with apps that took 50 people 10 years
> to write.
>
Well, you're cleaerly living in hell, and if it's as nasty as you say
you should get out. Sure, some (not all) large companies are crap in
this way, but the solution is still not to stand around bitching.
Quite apart from anything else if the organisation you work for is as
bad as you describe their just waiting for someone else to eat them
alive... (Of course the middle of a recession may not be the best
time to mmove, I know.)
>
> PS. If we weren't so independent-minded (maybe BECAUSE we are?), I'd say
> a bunch of us should come up with a business plan, get funding, and
> start our own company. Not that I'm a big fan of companies, but that's
> how the existing economic system forces us to play.
>
So long as the business plan isn't 'we'll do cool things in Lisp'.
Too many people seem to think that, or an equivalent, the most recent
being 'we'll do cool things on the web', is enough.
--tim
Tim Bradshaw
>
> 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
"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
"Sandeep Koranne" <sandeep...@nospam.philips.com> wrote
> > 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
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
> 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
> 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
> 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
<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).
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
> 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
> > 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
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
> 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
"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
> 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