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
Stephen Pelc
<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?
Windows are available from our web site. DOCGEN is included
and the VFX Forth manual is *entirely* produced by DOCGEN.
Elizabeth D. Rather
> 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
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
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
> 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
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.
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
> > 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
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
>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
> 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.
> 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
> 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
> "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
>
> "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?
>
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
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
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
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
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
| ... 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
>
...
>
> Forth: (forgive me if I get the details wrong here, my Forth is
> rusty)
> foo if "bar" print else "baz" print then
>
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
> * 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
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
> * Erann Gat <g...@flownet.com> menulis:
> | ... The Forth seems pretty cryptic by
> | comparison. What's that 'then' doing by itself off at the end?
> | Postfix is very unintuitive to most people because it has no analog in
> | natural language. You can say "a plus b" to mirror infix, or "the sum
> | of a and b" to mirror prefix, but "a and b, the sum of those things"
> | sounds awfully contrived.
>
> Actually, natural languages which have SOV (Subject-Object-Verb) word
> order are just as common (if not more so!) than SVO languages. Speakers
> of these languages would find it more natural to say "a b plus" or "a b
> add".
A few days ago I saw a commercial, in which a man walks out of a building
saying, "rain, stop" as he does so. The rain stops. He goes to cross
a street and says, "traffic, yield" and all the cars stop for him to pass.
This goes on and the commercial reveals this "subject, verb" to be the
syntax for car's voice control ("CD, play"). This is a commercial shown
to Americans, so apparently /someone/ thinks that the verb at the end
isn't too unnatural, at least for commands.
As to the far above, the IF THEN syntax of Forth has been talked about
to death. I think best representation is
<statement> IF <true-act> ELSE <false-act> THEN <continue>
Anyway, it has become 'natural' enough to me that I resist the teensy
effort required to have IF ENDIF instead. That people worry about this
word or the default RPN arithmetic of Forth still amazes me -- it sounds
like people would rather shoot down Forth on trivialities than expend
effort in learning about Forth. Maybe it's just that these people are
neophobes. I don't understand them at all.
Bart Lateur
>> Why do seemingly intelligent people say such idiotic things like "____ is an
>> unreadable language"????
>
>Why is a statement like "Perl is an unreadable language" idiotic?
>Languages optimize for different things. Perl,
>which seems to optimize for the output of a monkey given a typewriter
>being a valid program, I find unreadable.
Your statement is exactly the kind of idiotic statement that the whole
thread is about.
Perl is by design no more unreadable than Lisp, which seems to be your
pet language.
--
Bart.
Bruce McFarling
>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
a rare condition indeed. I have seen code with over use of macros, and wanted
to hunt down the originator of that code and slap them until they quit wiggling!
Use macros for non-portable things like I/O port reading and writing. This will
allow for only one place in the code that needs to be changed to move an I/O
address.
Otherwise, each programmer should be forced to write a 50000 word essay on WHY
they NEED the macro before they are allowed to use it in their code!
"Michael L Gassanenko" <m_l...@yahoo.com> wrote in message
news:b5ecdf44.01090...@posting.google.com...
Erik Naggum
> 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
>Yep! Macros should be used ONLY when it makes the code MORE readable. This is
>a rare condition indeed. I have seen code with over use of macros, and wanted
>to hunt down the originator of that code and slap them until they quit wiggling!
>
>Use macros for non-portable things like I/O port reading and writing. This will
>allow for only one place in the code that needs to be changed to move an I/O
>address.
You must be writing from the comp.lang.forth camp. In Lisp, macros are used
to create new sublanguages.
Even if the macros are hard to read, if the language they create greatly
simplifies some programming tasks, those macros are justifiable.
You will often find that what a few thousand lines of ```cryptic''
macros accomplish would require hundreds of thousands of lines in some
other programming languages, if indeed it could be done at all.
>Otherwise, each programmer should be forced to write a 50000 word essay on WHY
>they NEED the macro before they are allowed to use it in their code!
When you create a new sublanguage, it is certainly useful to document
its syntax and semantics! And of course, not every programming problem
deserves its own sublanguage.
I don't think that mature programmers need to write long essays justifying
to morons what they do.
Kaz Kylheku
>a rare condition indeed. I have seen code with over use of macros, and wanted
>to hunt down the originator of that code and slap them until they quit wiggling!
>
>Use macros for non-portable things like I/O port reading and writing. This will
>allow for only one place in the code that needs to be changed to move an I/O
>address.
You must be writing from the comp.lang.forth camp. In Lisp, macros are used
to create new sublanguages.
Even if the macros are hard to read, if the language they create greatly
simplifies some programming tasks, those macros are justifiable.
You will often find that what a few thousand lines of ```cryptic''
macros accomplish would require hundreds of thousands of lines in some
other programming languages, if indeed it could be done at all.
>Otherwise, each programmer should be forced to write a 50000 word essay on WHY
>they NEED the macro before they are allowed to use it in their code!
When you create a new sublanguage, it is certainly useful to document
its syntax and semantics! And of course, not every programming problem
deserves its own sublanguage. Documentation will allow other people to
use the sublanguage without having to decipher it from the implementation.
I don't think that mature programmers can be forced to write unnecessarily
long essays justifying to morons what they do. If you make up such rules,
then you will simply lose good programmers, and be left with those who will
do anything they are told, no matter how unreasonable, to hang on to their job.
Ken Peek
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
> 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
>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
>In article <tp4fj1m...@corp.supernews.com>, Ken Peek wrote:
>>Yep! Macros should be used ONLY when it makes the code MORE readable. This is
>>a rare condition indeed. I have seen code with over use of macros, and wanted
>>to hunt down the originator of that code and slap them until they quit wiggling!
>You must be writing from the comp.lang.forth camp.
No! Forth is even more prone to use macros than is Lisp (and that's one
of Lisp's greatest strengths). Lisp talks about metaprogramming (and, to
be fair, uses it a LOT), but the most-used metaprogramming language in the
world is more similar to Forth than Lisp.
I don't want to sound like I'm slamming Lisp; Lisp is extremely cool, and
has many more features than its justly-famed metaprogramming support. But
Forth is at least as good for metaprogramming, and I'd say more.
>In Lisp, macros are used to create new sublanguages.
Well said.
>Even if the macros are hard to read, if the language they create greatly
>simplifies some programming tasks, those macros are justifiable.
More than simplifying programming tasks, the goal should be to make the
terminology of the problem domain simple to express. Ideally, a person
who understands the problem and solution but not Lisp (or Forth) should be
able to read over the part of the code which expresses the problem and
solution.
>I don't think that mature programmers can be forced to write unnecessarily
>long essays justifying to morons what they do. If you make up such rules,
>then you will simply lose good programmers, and be left with those who
>will do anything they are told, no matter how unreasonable, to hang on to
>their job.
I think the no-macros philosophy is a leftover from C. Their macros
really ARE poisonous. (Although this is not entirely fair: even in C
macros are useful, and only extremism forbids them.)
--
-William "Billy" Tanksley
Bernd Paysan
> You must be writing from the comp.lang.forth camp. In Lisp, macros are used
> to create new sublanguages.
Can't be. In Forth, compiler extensions (immediate words, postpone, and
create-does>, parsing words) are used to create new sublanguages. We do
with some hundret lines what other people can only do by inventing a new
language, and writing a complete compiler (ok, except those who use Lisp
;-).
I think trolling like this comes from the traditional language camp,
where compiler extensions are not possible. Language extensions must be
documented with much more care than normal code, though.
Coby Beck
"Kaz Kylheku" <k...@ashi.footprints.net> wrote in message
news:dssk7.130336$B37.2...@news1.rdc1.bc.home.com...
> >Yep! Macros should be used ONLY when it makes the code MORE readable.
This is
> >a rare condition indeed. I have seen code with over use of macros, and
wanted
> >to hunt down the originator of that code and slap them until they quit
wiggling!
> >
> >Use macros for non-portable things like I/O port reading and writing.
This will
> >allow for only one place in the code that needs to be changed to move an
I/O
> >address.
>
> You must be writing from the comp.lang.forth camp. In Lisp, macros are
used
> to create new sublanguages.
>
Sure they are, but Lisp macros are used for lots of things! This includes
things that bring the benefit of more readable code (such as creating
sub-languages : ). Things like with-open-file just hide the nuts and bolts
of opening and closing files so you can focus on the meaningful bits (as
coder and as reader!)
Coby
--
(remove #\space "coby . beck @ opentechgroup . com")
Erann Gat
> * Erann Gat
> > The Forth seems pretty cryptic by comparison. What's that 'then' doing
> > by itself off at the end?
>
> Pardon me, but when you learn a language, you learn a language, and when
> you know a language, you know a language. It really is this trivial.
The question at hand was why Forth is *perceived* by some people as
being hard to maintain. I didn't mean to say that Forth *was*
objectively cryptic. I was merely engaging in (admittedly poorly
informed) speculation about why some people might find it cryptic.
> If you neither learn it nor know it, what business do you have commenting
> on it at all?
I believe that people have the right to make statements about things
even if they aren't authorities. But just to set the record straight:
I haven't used Forth in many years. I cannot comment on Forth
authoritatively. Nothing that I say about it should be taken as
anything other than poorly informed opinion. OK?
BTW, since my last posting I've learned that there are natural
languages that map onto Forth better than English, so I'll amend my
earlier statement: Postfix might be less intuitive for English
speakers than prefix or infix because it doesn't map as easily onto
English grammar.
E.
Erik Naggum
> If you neither learn it nor know it, what business do you have commenting
> on it at all?
* Erann Gat
> I believe that people have the right to make statements about things even
> if they aren't authorities.
Fine with me, but you are not arguing against what I said, which was not
about "authority", but about learning and knowing a language before you
speak about it. Again, you shirk away from what I say to argue for your
own arguments in a void. I wonder who you think you are folling.
Your comments all turn out to be shallow, prejudiced, and _personal_
experiences, with absolutely no claim to universalizability. An old
saying among statisticians is that "from a single data point, you can
extrapolate in any direction". You do that. It is, frankly, annoying.
///
Kaz Kylheku
>"Elizabeth D. Rather" <era...@forth.com> wrote in message news:<3B8FCD31...@forth.com>...
Clarity is a complicated function over a writer, a language and a reader.
These three elements interact in a complex way. Behind any message
there is a body of invisible information: the language itself, its
idioms, a shared body of knowledge between the reader and writer.
Arguments in these types of debates about which language is clearer tend
assume that the the reader should have to do no work, that the writer
cannot find a way to use the language to convey clearly, or that the
message must have an ``obvious'' meaning in the absence of the
any hidden information.
Statements like ``the Forth seems pretty cryptic'' simply say that,
in the writer's view, the communication has broken down somewhere.
That breakdown could be due to the writer, the language or the reader,
or in all three to varying degrees. It's impossible to tell where,
because the dependence of clarity on the reader makes the observation
entirely subjective. It could be that another reader will find the
constuct perfectly transparent, because that reader will find in the
message some common idiom, or some triggers which instantly connect
with something familiar and so on.
To eliminate that subjective element, an expert reader is required.
One who knows the language inside out: and not only the language but its
surrounding culture and idioms. When such a reader decides that a program
is unreadable, that seems to shift the blame to the writer. Or perhaps
to the language. When can the language be blamed on poor clarity? Perhaps
when an expert writes something that is intended to be clear, yet an
expert reader finds it unclear. But even then, perhaps the lack of
clarity can be blamed on the complexity of the message. Only if two
experts cannot achieve clarity in communicating a trivial message to
each other can one tentatively conclude that the language itself is
getting in the way of communication.
So I can agree with you that the Forth looks difficult to *me*,
but I have no doubt that if I spent a few weeks using Forth, I'd
be able read it without effort.
> What's that 'then' doing by itself off at the end?
>Postfix is very unintuitive to most people because it has no analog in
>natural language.
Sure it does, topicalization: movement of syntactic units to the front
of a clause. Speak like Yoda, you soon will! :)
The word ``then'' sometimes finds itself at the end of a clause.
``You don't want the soup or the salad? What will you order, then?''
Thomas F. Burdick
Gee, thanks for quoting the whole context:
> Common Lisp, which optimizes for expressiveness, I generally find to
> be readable. You can certainly write unreadable code in Lisp, and
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> it's sort-of possible to write readable Perl, but I don't think that
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> detracts from the usefullness of the generalization.
So, do you really think that language designers can *not* make choices
to make their language more readable or less readable? Now *that*
would be an idiotic statement. I'll not put it in your mouth if you
don't actually believe it; but if you don't, how else can you make the
above assertion: "Perl is by design no more unreadable than Lisp" ?
That needs an aweful lot of justification.
Michael L Gassanenko
> Yep! Macros should be used ONLY when it makes the code MORE readable. This is
> a rare condition indeed. I have seen code with over use of macros, and wanted
> to hunt down the originator of that code and slap them until they quit wiggling!
>
Well, I believe you. But a statement like "I hate/love macros"
is nothing more than a flame bait.
What charged you with negative emotions could not be just macros;
what property the code written with macros had?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I repeat:
Can you please explain, what was so bad in the code written
with macros? It cannot be just macros themselves.
> Use macros for non-portable things like I/O port reading and writing. This will
> allow for only one place in the code that needs to be changed to move an I/O
> address.
Constants are often used in such circumstances (at least, in Forth and C):
(define iobase 12345)
(define port0 (+ iobase 0))
(define port1 (+ iobase 1))
One of possible uses of macros in C++ is:
#define SUPER TheNameOfSomeClass
OTOH, some people use to declare "super" in class's namespace...
As to new languages, I used Forth and C macro-tools to have
both compilers load some .h file. (That file contained some
declaration needed by both C code and Forth code; such approach
allowed to avoid the problem of synchronization of C and Forth
declarations. Yes, spaces (Forth words are usually delimited by spaces)
were required in some places where they
would not be needed in just C++.)
You see, I have just named two more possible uses of macros:
1) compensation of language weaknesses
2) interaction between two languages, that is, sharing code
by two compilers (e.g. Forth and C++).
>
> Otherwise, each programmer should be forced to write a 50000 word essay on WHY
> they NEED the macro before they are allowed to use it in their code!
>
> "Michael L Gassanenko" <m_l...@yahoo.com> wrote in message
> news:b5ecdf44.01090...@posting.google.com...
> > Forth is a language with tunable syntax.
> > I mean, with Forth you can define your own
> > syntax and use it.
> >
> > In Lisp there are macros. Do people claim
> > that Lisp code with macros is unreadable?
> > Do people claim that macro definitions
> > are unreadable? (esp., the ` @ ,@ stuff)
regards, M.G.
--
I knew a person who was allergic to BASIC. At least that person
was indeed allergic, and BASIC was indeed used in that room.
(No, that person was not allergic *only* to BASIC,
but this [almost?] never happens with allergy).
Erann Gat
> * Erik Naggum
> > If you neither learn it nor know it, what business do you have commenting
> > on it at all?
>
> * Erann Gat
> > I believe that people have the right to make statements about things even
> > if they aren't authorities.
>
> Fine with me, but you are not arguing against what I said, which was not
> about "authority", but about learning and knowing a language before you
> speak about it.
Wow, three non-sequiturs in one sentence. That's got to be some kind
of record.
1. You're right, I wasn't arguing against what you said. So?
2. Fine. I believe people have a right to talk about things about
which they know absolutely nothing. I believe people have a right to
talk about anything they want to. So?
3. I wasn't actually talking about the language, so everything you
said is irrelevant. I was talking about people's perception of the
language, which is not the same thing.
E.
William Tanksley
:-)
That's postfix, but it's not Forth. Forth has no syntactic units; as
such, it's an entirely different genre of computer language. Lisp and C
and APL are closer to each other than any of them are to Forth.
Since Forth is such a different language, it's reasonable to note that
some things are harder to express in Forth than they are in any other
traditional language: for instance, it's hard to manipulate a function
together with its parameters, because functions aren't syntactically tied
to their parameters in Forth. It's also neccesary to note that many
things are dramatically easier in Forth: for instance, it's trivial to
refactor a function simply by cutting and pasting, and it's trivial to
build a reader macro which has full Turing-complete power, yet doesn't
interfere with any of the rest of the language.
I'm of the opinion that Forthlike languages have a LOT to offer language
design, but they simply haven't been studied at all yet. The first paper
I saw on the topic I saw only recently, at
http://www.latrobe.edu.au/www/philosophy/phimvt/j00syn.html (I liked it so
much I started an egroup about it).
--
-William "Billy" Tanksley
Anton Ertl
dona...@hotmail.com (Don) writes:
>My experience is based on the following scenario which I suspect is
>shared by many others.
>1. A product is designed by myself and/or others.
>2. It is installed & commissioned & we don't see it again for ages
>beyond possible annual service checks. We go & do a million & one
>other things, a small portion of which is actually writing code.
>3. 5 years later it requires changes or decides to do something
>bizarre.
>4. At 2am in the morning when the line stops someone has to bounce out
>& implement & test the changes/fix.
>
>Having to go back & analyse the entire app to try to 'regain the
>mindset' to attempt to find out what the heck is happening is not a
>wonderful economic strategy.
It may well be, because trying to change the program without
understanding it well enough certainly leads to disaster. Typically,
though, I only have to regain the mindset for only a part of the
program.
Now, wrt your scenario above, I maintain and work with Forth code
written by me and others more than five years ago, and I find most of
the code pretty maintainable. However, some of it is hard to
understand (and consequently, to maintain), mostly because of
programming style issues (long definitions, lack of stack comments and
descriptive comments).
Since I am also posting this to c.l.lisp, I also have a Lisp story to
tell: The largest Lisp program I ever wrote was the original version
of prims2x/vmgen, which I wrote in Elisp, because of its text
processing capabilities. After a few years, I rewrote it in Forth,
mainly because of changes in the case handling of the Elisp functions
the program used (in one Emacs version it was unpredictable what case
the output would have).
Concerning maintainability, the Elisp version was hard to adapt to
changing needs; I attribute this to the design and style of the
program: I tried to keep to a functional style, but apparently did so
in the wrong way, and changes typically required passing stuff across
a number of functions and the additional data could not be just tacked
on existing data, so it required additional parameters. You can
attribute this to my inexperience in Lisp (or maybe just a bad design
decision in general), but if I was after a flamewar, I would attribute
it to Lisp:-).
The Forth version uses about a dozen global variables for these tasks,
and was easier to maintain for a long time (contrary to established
wisdom about global variables). But of course in the end I wanted to
do a change for which the global variables proved to be a problem, and
now the Forth version is quite messy. I believe that the original
functional approach would not have survived that change at all, though.
Crossposted to clf, cll.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
Anton Ertl
> The Forth seems pretty cryptic by
That's a FAQ, of course, and the answer is:
5.4. Why does THEN finish an IF structure?
Some people find the way THEN is used in Forth unnatural, others do
not.
According to Webster's New Encyclopedic Dictionary, "then" (adv.) has
the following meanings:
2b: following next after in order ... 3d: as a necessary
consequence (if you were there, then you saw them).
Forth's THEN has the meaning 2b, whereas THEN in Pascal and other pro-
gramming languages has the meaning 3d.
If you don't like to use THEN in this way, you can easily define ENDIF
as a replacement:
______________________________________________________________________
: ENDIF POSTPONE THEN ; IMMEDIATE
______________________________________________________________________
See my .sig for answers to other c.l.f FAQs.
Followups to clf.
Kurt B. Kaiser
> Sure it does, topicalization: movement of syntactic units to the front
> of a clause. Speak like Yoda, you soon will! :)
EXTERIOR: DAGOBAH--DAY
With Yoda strapped to his back, Luke climbs up one of the many thick vines
that grow in the swamp until he reaches the Dagobah statistics lab.
Panting heavily, he continues his exercises--grepping, installing new
packages, logging in as root, and writing replacements for two-year-old
shell scripts in Python.
YODA: Code! Yes. A programmer's strength flows from code
maintainability, but beware of Perl. Terse syntax... more than one
way to do it... default variables. The dark side of code
maintainability are they. Easily they flow, quick to join you when
code you write. If once you start down the dark path, forever will
it dominate your destiny, consume you it will.
LUKE: Is Perl better than Python?
YODA: No... no... no. Quicker, easier, more seductive.
LUKE: But how will I know why Python is better than Perl?
YODA: You will know. When your code you try to read six months from now.
-- Lorrie Wood
Hmmm. Harumph.
--
K u r t B. K a i s e r
k b k @@ s h o r e .. n e t
------------------------------
William Tanksley
>g...@flownet.com (Erann Gat) wrote:
>> > The point being, that "readability" of any language requires some
>> > familiarity with that language.
>Not necessarily. I've several times developed an algorithm in Dylan and
>then as an experiment given the source code to someone who has never
>seen Dylan (but knows, say, C or Java well) without even commenting on
>what language the code is in. No one has ever had any problems with it.
>OTOH, I don't do this with stupid people :-)
True. Languages *can* be designed to be readable by non-programmers who
have specific training. I've handed in working Python code as the
response to a pseudocode assignment (I left out some function definitions,
so they couldn't run it, but I had written them and tested the whole
thing), and I have no doubt that someone familiar with pseudocode but not
python would imagine that it was actually pseudocode.
The trick is to choose what specific training you want your proofreader to
have. With Forth, you want them to be trained in the problem (and
wsolution) area, not in reading pseudocode. Like Lisp, Forth is all about
building micro-languages in which the problem can be expressed naturally.
Unlike most modern languages, Forth's flow of execution is purely
left-to-right, ensuring that you don't have to introduce the proofreader
to thre concept of argument evaluation and function calls.
>> Right. That said, I don't think that all languages are equally
>> readable. Compare:
>> Lisp:
>> C:
A terrible example. Who cares about such trivial things? No domain
expert is going to; only an undergrad could care. And why should I care
whether my code can be read by an undergrad?
>I think PostScript is better:
>foo
> [(baz) print]
> [(bar) print]
>ifelse
It's great, until either block gets at all complicated. I actually prefer
the PS style, but practically, it has a lot of problems.
>> Python:
>> if foo():
>> print "baz"
>> else:
>> print "bar"
>> I think Python has a clear edge in readbility.
>It's readable, but I think *far* too dangerous to allow to live. The
>bugs caused by misplaced semicllons and parens are legion.
Where on earth did you hear this? Did you just make it up today? Python
has no mandatory semicolons, and the colons are mandatory and absolutely
redundant (so it's impossible to leave them out and not get a syntax error
pointing to the problem). And what's this about parens? I can't even
imagine what class of problems you're talking about.
>Editing accidents that leave indentation mangled are far more likely to
>happen, and thee is no redundancy so nothing can warn you about it.
Absolutely false. Mangling indentation is possible, although I've never
done it nor talked to any Python programmer who has, but there is LOTS of
redundancy for the compiler to catch. There are even tabchackers which
make sure you're not using tabs in any possibly confusing ways
(officially, tabs are discouraged because different editors see them
differently; however, there are some simple rules which make them
unambiguous).
>-- Bruce
--
-William "Billy" Tanksley
Thomas F. Burdick
> Concerning maintainability, the Elisp version was hard to adapt to
> changing needs; I attribute this to the design and style of the
> program: I tried to keep to a functional style, but apparently did so
> in the wrong way, and changes typically required passing stuff across
> a number of functions and the additional data could not be just tacked
> on existing data, so it required additional parameters. You can
> attribute this to my inexperience in Lisp (or maybe just a bad design
> decision in general), but if I was after a flamewar, I would attribute
> it to Lisp:-).
>
> The Forth version uses about a dozen global variables for these tasks,
> and was easier to maintain for a long time (contrary to established
> wisdom about global variables). But of course in the end I wanted to
> do a change for which the global variables proved to be a problem, and
> now the Forth version is quite messy. I believe that the original
> functional approach would not have survived that change at all, though.
If global variables are used to maintain global state, I don't see any
problem with them. Like almost every other programming tool with a
bad reputation, their infamy comes from misuse. FWIW, it sounds like
you just wanted to use global (or maybe buffer-local) variables in the
Elisp version -- something that's done all the time.
John A. Peters
write something like that below when I was Disk Librarian of SVFIG in
the 80ies.
I would like to use the "TOOL CHAIN (FORTH)" on some of the Forth's
that I use like Win32Forth. Is it a commercial product or an
extension to Forth or what? please expound more.
Stephen Pelc wrote:
<snip snip>
> Over the last three years we have switched over to a tool
> chain (Forth) which extracts documentation as formal
> comments from the source code and then generates HTML
> and/or PDF manuals. The effect of this has been to
> encourage our own programmers and our clients to write
> the documentation as the code is written.
>
> When we looked at literate programming tools some years
> ago, the problem was that the source for the compiler and
> the documentation could get out of step. In our system there
> is only ever one file, and the documentation is contained
> within formal comments.
>
> Stephen
Bruce Hoult
wtan...@bigfoot.com wrote:
> >I think PostScript is better:
> >foo
> > [(baz) print]
> > [(bar) print]
> >ifelse
>
> It's great, until either block gets at all complicated. I actually
> prefer the PS style, but practically, it has a lot of problems.
Such as?
> >> Python:
> >> if foo():
> >> print "baz"
> >> else:
> >> print "bar"
> >> I think Python has a clear edge in readbility.
>
> >It's readable, but I think *far* too dangerous to allow to live. The
> >bugs caused by misplaced semicllons and parens are legion.
>
> Where on earth did you hear this? Did you just make it up today? Python
> has no mandatory semicolons, and the colons are mandatory and absolutely
> redundant (so it's impossible to leave them out and not get a syntax
> error pointing to the problem). And what's this about parens? I
> can't even imagine what class of problems you're talking about.
I'm talking about *other* languages.
Python has a serious dangling else problem with no redundancy that I can
see. If Python used, for example, some sort of "endif" then the
indentation would be redundant (as in other languages), but without it
it's not.
> >Editing accidents that leave indentation mangled are far more likely to
> >happen, and thee is no redundancy so nothing can warn you about it.
>
> Absolutely false. Mangling indentation is possible, although I've never
> done it nor talked to any Python programmer who has
Well no one is going to admit it, are they? They'll make the mistake,
and then track down the bug and go "Geez I'm bone-headed, what a
beginner mistake to make" and they'll never mention it to anyone else,
thinking that no one else is making the same error. When all along
people *will* be making the mistake because the language is worse
designed than it needs to be.
-- Bruce
Kaz Kylheku
>Python has a serious dangling else problem with no redundancy that I can
>see. If Python used, for example, some sort of "endif" then the
>indentation would be redundant (as in other languages), but without it
>it's not.
How can Python have a dangling else problem, when the nesting level of
every statement is deducible from its indentation?
if foo
if bar
this
else
that
The indendation clearly indicates that the else goes with the innermost
if. If you change the indentation like this, it will go with
the outer if:
if foo
if bar
this
else
that
Or not? What facts am I missing?
>> >Editing accidents that leave indentation mangled are far more likely to
>> >happen, and thee is no redundancy so nothing can warn you about it.
>>
>> Absolutely false. Mangling indentation is possible, although I've never
>> done it nor talked to any Python programmer who has
>
>Well no one is going to admit it, are they? They'll make the mistake,
>and then track down the bug and go "Geez I'm bone-headed, what a
Careless editing mistakes can cause damage to a program in any language.
The risk of a careless edit is minimized by using a version control
system. Or at least maintaining backups of your working sources.
Bruce Hoult
k...@ashi.footprints.net wrote:
> In article <bruce-EC56FC....@news.akl.ihug.co.nz>, Bruce Hoult
> wrote:
> >Python has a serious dangling else problem with no redundancy that I can
> >see. If Python used, for example, some sort of "endif" then the
> >indentation would be redundant (as in other languages), but without it
> >it's not.
>
> How can Python have a dangling else problem, when the nesting level of
> every statement is deducible from its indentation?
No, it is not deducible from its indentation, it is *defined* by its
indentation. And indentation is a very fragile thing.
if foo
if bar
this
else
that
theother <= here
somemore
There are three different levels to which the line marked "<= here" can
be indented without causing a compile error. That's dangerous.
> Careless editing mistakes can cause damage to a program in any language.
And careless driving can cause a smash in any car. That doesn't mean
that it's a *good* idea to drive with bald tyres and no brakes.
Twenty years ago I thought I was a pretty hot programmer who never made
mistakes. Now I'm a much better programmer and I don't take *anything*
for granted that I don't absolutely have to, and I make use of every aid
to catching dumb mistakes that I can. Redundancy is the prime tool.
Program structure is specified *both* with syntactical tokens *and* with
indenting, and I prefer to use languages where you can explicitly say
"end foo" and the compiler checks that it is really "foo" that you
should be ending at that point. I declare variables to be of particular
types, and then expect that the machine will tell me (whether at
compile- or run-time) if I try to use them in ways inappropriate to that
type. I use languages that *always* check array bounds, either at
runtime or by my *proving* to the compiler that they will always be
within bounds.
Your philosophy may differ.
-- Bruce
Kaz Kylheku
>In article <o0Sk7.133928$B37.3...@news1.rdc1.bc.home.com>,
>k...@ashi.footprints.net wrote:
>
>> In article <bruce-EC56FC....@news.akl.ihug.co.nz>, Bruce Hoult
>> wrote:
>> >Python has a serious dangling else problem with no redundancy that I can
>> >see. If Python used, for example, some sort of "endif" then the
>> >indentation would be redundant (as in other languages), but without it
>> >it's not.
>>
>> How can Python have a dangling else problem, when the nesting level of
>> every statement is deducible from its indentation?
>
>No, it is not deducible from its indentation, it is *defined* by its
>indentation. And indentation is a very fragile thing.
In what way? Do little green trolls visit your hard disk at night
and fiddle with whitespace?
> if foo
> if bar
> this
> else
> that
> theother <= here
> somemore
>
>There are three different levels to which the line marked "<= here" can
>be indented without causing a compile error. That's dangerous.
I still don't see the alleged dangling else ambiguity. That a program
can be easily edited to create a program with a different meaning is
obvious, but I was hoping that you could provide some information to
support your claim that Python has a dangling else.
>> Careless editing mistakes can cause damage to a program in any language.
>
>And careless driving can cause a smash in any car. That doesn't mean
>that it's a *good* idea to drive with bald tyres and no brakes.
Note that ill-conceived car analogies don't cut it in an erudite forum
such as the comp.lang.lisp newsgroup. Call me stupid, but I don't see
a clear-cut isomorphism between driving and programming, and between
indentation-sensitivity and bald tires.
Programmers use indentation even in programming languages where it
is not required. By reading and writing programs that obey certain
indentation rules, we get used to reading the indentation. So if there is
some mistake caused by a construct having a different meaning from what
is suggested by its indentation, that mistake can be difficult to spot.
The rationale behind making indentation significant appears sound: it
eliminates the potential for writing a program whose indentation
suggests a different program, thereby eliminating a class of
programming errors.
Note that I have no experience with Python or any other language which
treats indentation in a similar way. If I ever acquire as much experience
with Python as you have, I will be able to properly evaluate the alleged
risks caused by its whitespace sensitivity, and be in a much better position
to debate them.
I was only curious about the dangling else.
William Tanksley
>wtan...@bigfoot.com wrote:
>> >I think PostScript is better:
>> >foo
>> > [(baz) print]
>> > [(bar) print]
>> >ifelse
>> It's great, until either block gets at all complicated. I actually
>> prefer the PS style, but practically, it has a lot of problems.
>Such as?
Such as trying to read code where the block structure is nested or long.
It's not polite to place the parameters too far away from the functions
which need them, even though the language (PS and Forth) allow it.
Consider it: the block appears with no warning, with no way to tell how
it's doing to be used. Anything can happen inside the block. Then
another block comes, again without preliminary explanation. Again, this
block can be arbitrarily long and contain anything. Finally you get your
'ifelse' which is supposed to explain what the blocks are for (unless, of
course, the ifelse is factored into another word).
Again, I'm a Forth and Postscript fan, and for a number of theoretical
reasons I prefer PS blocks to Forth IFs. But you can't deny the problems!
>> >> I think Python has a clear edge in readbility.
>> >It's readable, but I think *far* too dangerous to allow to live. The
>> >bugs caused by misplaced semicllons and parens are legion.
>> Where on earth did you hear this? Did you just make it up today? Python
>> has no mandatory semicolons, and the colons are mandatory and absolutely
>> redundant (so it's impossible to leave them out and not get a syntax
>> error pointing to the problem). And what's this about parens? I
>> can't even imagine what class of problems you're talking about.
>Python has a serious dangling else problem with no redundancy that I can
>see. If Python used, for example, some sort of "endif" then the
>indentation would be redundant (as in other languages), but without it
>it's not.
And in the other languages, the 'endif' isn't redundant. There are no
languages I know of which use both indentation and delimiters. You get to
choose which thing you want to delimit your blocks: either a glyph which
requires you to read the code to see, or a complete indentation structure
which merely requires a glance.
>> >Editing accidents that leave indentation mangled are far more likely to
>> >happen, and thee is no redundancy so nothing can warn you about it.
>> Absolutely false. Mangling indentation is possible, although I've never
>> done it nor talked to any Python programmer who has
>Well no one is going to admit it, are they? They'll make the mistake,
>and then track down the bug and go "Geez I'm bone-headed, what a
>beginner mistake to make" and they'll never mention it to anyone else,
>thinking that no one else is making the same error. When all along
>people *will* be making the mistake because the language is worse
>designed than it needs to be.
An interesting hypothesis. Can you confirm it, or is it inherently
unconfirmable? Perhaps I can't speak for other Python programmers, but as
for myself, I've never had an indentation-related bug. Never once. The
question has come up before on comp.lang.python, and there are perhaps two
replies which claim that they have found an indentation bug in their code.
In my memory, nobody has ever claimed to find an indentation bug in
someone else's code (and, again, we've searched for such things).
The problem is that indentation is such an /obvious/ feature of a program;
it's immediately visible. Indentation mistakes are /not/ subtle. This is
why C's if/if/else problem is so severe: people assume that the
indentation tells the whole story, when in reality the else always matches
the inner if.
In Python, the indentation always /does/ tell the entire story.
William Tanksley
>k...@ashi.footprints.net wrote:
>type. I use languages that *always* check array bounds, either at
>runtime or by my *proving* to the compiler that they will always be
>within bounds.
>Your philosophy may differ.
Or his methods may differ. As do mine; as do the methods of most of the
people in the two NGs to which your comments are posted. Lisp, unlike
Forth, can be statically typechecked; however, as a matter of convention,
it isn't. By your argument, then, we're all foolhardy souls, certain in
our hubris that we never make mistakes.
No.
We test and embed our tests in the code, we write short definitions, we
prove our algorithms... We do all kinds of things to ensure our code
works. When we do use strict typechecking compilers, we continue to do
pretty much the same things. You should, too.
Bruce Hoult
wtan...@bigfoot.com wrote:
> On Mon, 03 Sep 2001 20:16:33 +1200, Bruce Hoult wrote:
> >wtan...@bigfoot.com wrote:
>
> >> >I think PostScript is better:
> >> >foo
> >> > [(baz) print]
> >> > [(bar) print]
> >> >ifelse
>
> >> It's great, until either block gets at all complicated. I actually
> >> prefer the PS style, but practically, it has a lot of problems.
>
> >Such as?
>
> Such as trying to read code where the block structure is nested or long.
> It's not polite to place the parameters too far away from the functions
> which need them, even though the language (PS and Forth) allow it.
>
> Consider it: the block appears with no warning, with no way to tell how
> it's doing to be used. Anything can happen inside the block. Then
> another block comes, again without preliminary explanation. Again, this
> block can be arbitrarily long and contain anything. Finally you get your
> 'ifelse' which is supposed to explain what the blocks are for (unless, of
> course, the ifelse is factored into another word).
The boolean expression sitting in front of it tend to be a bit of a
clue, but yes, it's certainly more error-prone than most languages and
the only real way to avoid it is to only write quite short blocks.
> >Python has a serious dangling else problem with no redundancy that I can
> >see. If Python used, for example, some sort of "endif" then the
> >indentation would be redundant (as in other languages), but without it
> >it's not.
>
> And in the other languages, the 'endif' isn't redundant. There are no
> languages I know of which use both indentation and delimiters. You get
> to choose which thing you want to delimit your blocks: either a glyph
> which requires you to read the code to see, or a complete indentation
> structure which merely requires a glance.
There are no languages which require it, but there are plenty of tools
which work with the redundancy, generally by calculating and displaying
the logical indentation from a given program structure. This ranges all
the way from Think Pascal in which the programmer has no choice but to
allow the editor to format the code, to emacs modes which indent when
you press tab or semicolon or other "electric" keys, to batch
reformatters (emacs again and pretty-printers).
I don't know how many times I've gotten to the end of a function in Lisp
or C or anything else supported by an emacs mode and found that I've
either hit the left margin before I've finished the function, or else
that I've finished the function but am still indented a bit. Ineitably
it's some simple typo, and fairly often one that the compile would
quickly catch. But not always, and you get to see the problem right
away.
> >Well no one is going to admit it, are they? They'll make the mistake,
> >and then track down the bug and go "Geez I'm bone-headed, what a
> >beginner mistake to make" and they'll never mention it to anyone else,
> >thinking that no one else is making the same error. When all along
> >people *will* be making the mistake because the language is worse
> >designed than it needs to be.
>
> An interesting hypothesis. Can you confirm it, or is it inherently
> unconfirmable?
Unrefutable, I'd say :-) I know that I make that sort of error all the
time in other languages, so I don't see why I wouldn't in Python. But
then maybe I'm just a worse than average programmer and the rest of you
are Gods? Certainly I know I have limitations and I know that I need
ways to try to allow for them, and having both tokens and indentation to
show structure helps me do that, as do type declarations and checks and
array bounds declarations and checks.
-- Bruce
Bruce Hoult
wtan...@bigfoot.com wrote:
> On Mon, 03 Sep 2001 21:54:16 +1200, Bruce Hoult wrote:
> >k...@ashi.footprints.net wrote:
>
> >type. I use languages that *always* check array bounds, either at
> >runtime or by my *proving* to the compiler that they will always be
> >within bounds.
> >Your philosophy may differ.
>
> Or his methods may differ. As do mine; as do the methods of most of the
> people in the two NGs to which your comments are posted. Lisp, unlike
> Forth, can be statically typechecked; however, as a matter of convention,
> it isn't.
Not statically, no, but it *is* totally typechecked. Like PostScript
but unlike Forth.
> By your argument, then, we're all foolhardy souls, certain in
> our hubris that we never make mistakes.
>
> No.
>
> We test and embed our tests in the code, we write short definitions, we
> prove our algorithms... We do all kinds of things to ensure our code
> works. When we do use strict typechecking compilers, we continue to do
> pretty much the same things. You should, too.
I do. And that's why by the time my code gets to the customer there are
almost *never* any bugs. It's a point of pride with me that the QA
people don't find anything wrong. I know most people at the places I
work don't care, and I guess that's why I get called in as a consultant
to fix their messes.
Take the ICFP contest, for example. OK, last year my team didn't
*quite* get the raytracer finished, with cones and CSG not completed,
but everything we *did* do worked fine. This year I got my SML/NG
optimizer done, was fearlessly tweaking it up to the last five minutes,
and submitted it in the last seconds (entry #249, the last entry
accepted). It proved to be bug-free, robust, pretty fast, and a pretty
good optimizer and ended up in the prize money.
And it seems appropriate to point out that no dynamically-typed language
has *ever* previously finished in the money in the ICFP contest, and
certainly nothing from the Lisp family. It's not from lack of trying --
this year there were five teams that submitted entries using Common Lisp
and six teams that used Scheme. None appear to have made the top couple
of dozen places.
Why is that, for a language that is so good at rapid development of
complex algorithms?
-- Bruce
Erann Gat
[Many well made and valid points deleted]
> >Postfix is very unintuitive to most people because it has no analog in
> >natural language.
>
> Sure it does, topicalization: movement of syntactic units to the front
> of a clause. Speak like Yoda, you soon will! :)
Hm, shouldn't that be: You Yoda like soon will speak? ;-)
> The word ``then'' sometimes finds itself at the end of a clause.
> ``You don't want the soup or the salad? What will you order, then?''
Interesting, I hadn't thought of that. Another example: If I can't
get what I want I'll have to settle for less than that then.
I this now more must ponder. Hmmm. This interesting is. The
possibilities many to be seem.
E.
Bruce McFarling
>> Sure it does, topicalization: movement of syntactic units to the front
>> of a clause. Speak like Yoda, you soon will! :)
>Hm, shouldn't that be: You Yoda like soon will speak? ;-)
Speak like Yoda, soon you will. For this, trust me, you should.
(
----------
Virtually,
Bruce McFarling, Newcastle,
ec...@cc.newcastle.edu.au
)
Neil Bawd
does, How it does it, or Syntax indication, with preference in that order.
Sometimes an appropriate What-it-does can't be found, particularly when the
word is syntactic.
I think that THEN is the best of a few choices for What-it-does. ENDIF is
syntactic, and is as bad as FI .
(
--
Wil Baden Costa Mesa, California Per neil...@earthlink.net
)
Dorai Sitaram
Kaz Kylheku <k...@ashi.footprints.net> wrote:
>In article <bruce-7D918E....@news.akl.ihug.co.nz>, Bruce Hoult wrote:
>>In article <o0Sk7.133928$B37.3...@news1.rdc1.bc.home.com>,
>>k...@ashi.footprints.net wrote:
>>
>>> In article <bruce-EC56FC....@news.akl.ihug.co.nz>, Bruce Hoult
>>> wrote:
>>> >Python has a serious dangling else problem with no redundancy that I can
>>> >see. If Python used, for example, some sort of "endif" then the
>>> >indentation would be redundant (as in other languages), but without it
>>> >it's not.
>>>
>>> How can Python have a dangling else problem, when the nesting level of
>>> every statement is deducible from its indentation?
>>
>>No, it is not deducible from its indentation, it is *defined* by its
>>indentation. And indentation is a very fragile thing.
>
>In what way? Do little green trolls visit your hard disk at night
>and fiddle with whitespace?
Perhaps one can recycle the customary argument against
case-sensitivity that many people here (Pitman et alia)
have used. Indentation has no easy translation into
speech. How does one communicate indentation over the
telephone (voice), without it encroaching unduly and
intrusively into the rest, more substantive part,
of the communication?
It is possible to use case to make a written program
clearer to humans, and so it is with indentation. But
making them affect the correctness of the program from
the machine's point of view will exact a price in terms
of "speakability". Perhaps that price is small to
some, but it is there.
--d
Bob Bane
>
> In article <bruce-7D918E....@news.akl.ihug.co.nz>, Bruce Hoult wrote:
> >In article <o0Sk7.133928$B37.3...@news1.rdc1.bc.home.com>,
> >k...@ashi.footprints.net wrote:
> >
> >
> >> How can Python have a dangling else problem, when the nesting level of
> >> every statement is deducible from its indentation?
> >
> >No, it is not deducible from its indentation, it is *defined* by its
> >indentation. And indentation is a very fragile thing.
>
> In what way? Do little green trolls visit your hard disk at night
> and fiddle with whitespace?
>
channels like Usenet. Code is used to communicate both with compilers
and with other programmers. Indentation can get changed by different
styles of quoting, excursions into and out of variable-width fonts, or
conversion between tabs and spaces.
When this happens to code in langauges with syntactic redundancy, you
can recover - that's what C-M-q in emacs is for. With Python code,
you're hosed.
--
Remove obvious stuff to e-mail me.
Bob Bane
Elizabeth D. Rather
> >...
> Forth: (forgive me if I get the details wrong here, my Forth is
> rusty)
> foo if "bar" print else "baz" print then
For the record, the correct rendering in Forth would be:
foo if ." bar" else ." baz" then
The name ." for a word that prints the string that follows (terminated
by a trailing " ) is based on the extremely widespread use of the dot
or period to indicate output, a naming convention that one picks up
very early in one's Forth career.
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."
================================================
Elizabeth D. Rather
> In article <tp4fj1m...@corp.supernews.com>, Ken Peek wrote:
> >Yep! Macros should be used ONLY when it makes the code MORE readable. This is
> >a rare condition indeed. I have seen code with over use of macros, and wanted
> >to hunt down the originator of that code and slap them until they quit wiggling!
> >
> >Use macros for non-portable things like I/O port reading and writing. This will
> >allow for only one place in the code that needs to be changed to move an I/O
> >address.
>
> You must be writing from the comp.lang.forth camp. In Lisp, macros are used
> to create new sublanguages.
>
> Even if the macros are hard to read, if the language they create greatly
> simplifies some programming tasks, those macros are justifiable.
>
> You will often find that what a few thousand lines of ```cryptic''
> macros accomplish would require hundreds of thousands of lines in some
> other programming languages, if indeed it could be done at all.
Actually, Forth is heavily based on this philosophy, with the distinction that
what we create in Forth are "words" or functions that are called, as opposed
to macros, which are expanded in place when referenced. Forth is highly
optimized for this kind of modularity, with absolutely minimal overhead on
calling functions (in many cases, literally only the CALL ... RET instructions,
with no added code required for calling sequences, saving/restoring registers,
etc.). In consequence, there's a lot more shared code in Forth, and programs
are extremely small.
> 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 certainly agree, this is equally true from the Forth perspective.
William Tanksley
>Kaz Kylheku wrote:
>> In what way? Do little green trolls visit your hard disk at night
>> and fiddle with whitespace?
>No, but arbitrary weird stuff can happen when code gets transmitted via
>channels like Usenet. Code is used to communicate both with compilers
>and with other programmers. Indentation can get changed by different
>styles of quoting, excursions into and out of variable-width fonts, or
>conversion between tabs and spaces.
Visit comp.lang.python and see how often this is a problem. (Never.)
There are no whitespace-eating nanoviruses, and by the time the Greys
invent and introduce them, Python will have evolved defences.
(To be fair, whitespace has been a problem on Slashdot, but then people
shouldn't be posting code on Slashdot anyhow; that's not what it's for.)
Open your mind. Try the new things. You may like them and you may
dislike them, but at least your mind will be cleared of the falsehoods
people have invented.
>Bob Bane
--
-William "Billy" Tanksley
Greg Menke
> >No, but arbitrary weird stuff can happen when code gets transmitted via
> >channels like Usenet. Code is used to communicate both with compilers
> >and with other programmers. Indentation can get changed by different
> >styles of quoting, excursions into and out of variable-width fonts, or
> >conversion between tabs and spaces.
>
> Visit comp.lang.python and see how often this is a problem. (Never.)
> There are no whitespace-eating nanoviruses, and by the time the Greys
> invent and introduce them, Python will have evolved defences.
Maybe not for new code, but what about something that gets kicked
around for a few years going from one editor to another with all the
consequent confusion of tabs and spaces? Maybe also between something
that respects tabs and spaces to something that only converts when you
retype a line.
I recall huge indenting problems in C and Clipper back in my DOS days
when moving code between just 2 or 3 editors. The editor I used
(brief) had Clipper (and IIRC C) reformatting built in, which was a
lifesaver with all the nasty dBase III code to update. Likewise,
C-M-Backslash in Emacs now. A big Python routine could be rendered
into garbage with a single keystroke using tools like this.
Personally, I like the whitespace block delimiting in Python, but I'm
dubious wrt its robustness over time.
Gregm
Bijan Parsia
[snip]
> Maybe not for new code, but what about something that gets kicked
> around for a few years going from one editor to another with all the
> consequent confusion of tabs and spaces?
Really really....really...it hasn't be a problem, AFAICT.
IIRC, the only time you're in danger is if you mix tabs and spaces, and
even then it's quite straightforward to manage it.
[snip]
> Personally, I like the whitespace block delimiting in Python, but I'm
> dubious wrt its robustness over time.
But is your dubioiusness even *prima facie* well founded? The Python
libraries are fairly large globules of code, much of which has been
evolved over >5 years, often with different people contributing, from
different platforms (there's a robuts Mac Python community, for example).
No *doubt* that a certain kind of care is called for which glyph delimited
languages/tools need not honor, so there's the possibility of skanking
python code if you use them.
But, really really, as long as all your tools and your practices are
*minimally* Python sensitive, I'd be *enormously* surprised if you'd have
real problems, even in the scenario you put forth.
I think it's fair to say that the whitespace "problem" is right up there
with the "parens" problem....i.e., not a problem :)
(I'm sure that there are *some* combinations of tools and persons for
which these are genuine problems...e.g., someone who has a deep seated
fear of parentheses or feels compelled to zap whitespace on a regular
basis. I'm perfectly comfortable telling these folks to avoid Lisp or
Python, respectively, like the plague. :))
Cheers,
Bijan Parsia.
Wade Humeniuk
> *quite* get the raytracer finished, with cones and CSG not completed,
> but everything we *did* do worked fine. This year I got my SML/NG
> optimizer done, was fearlessly tweaking it up to the last five minutes,
> and submitted it in the last seconds (entry #249, the last entry
> accepted). It proved to be bug-free, robust, pretty fast, and a pretty
> good optimizer and ended up in the prize money.
>
> And it seems appropriate to point out that no dynamically-typed language
> has *ever* previously finished in the money in the ICFP contest, and
> certainly nothing from the Lisp family. It's not from lack of trying --
> this year there were five teams that submitted entries using Common Lisp
> and six teams that used Scheme. None appear to have made the top couple
> of dozen places.
>
> Why is that, for a language that is so good at rapid development of
> complex algorithms?
Way to go Bruce! I see it was in Dylan.
Most of the CL entries seemed to error out of the competition. Why did you
use Dylan and not CL? I assume its because you are more comfortable with
Dylan.
There is nothing wrong with the language.
Next year perhaps, this year I was on vacation at the time and could not
participate.
Wade
Fred Warren
> 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"
>
Let's take a look at these four examples with the whitespace removed, after
all, the compiler __does not care__.
Lisp: (if (foo) (print "baz") (print "bar"))
C: if (foo()) {printf("baz"); } else {printf("bar");}
Forth: foo if ." bar" else ." baz" then
Python: if foo(): print "baz" else: print "bar"
Lisp, C and such are hard to read, in the sense that you must play the
"match the parens game" Python is more readable, until you inform someone
what ." does.
Actually, when I code in forth, I only uppercase ANS words, so the above
becomes:
Forth: foo IF ." bar" ELSE ." baz" THEN
Which we can do, because most forths have the option of being case
insensitive. Which I might add, is something you can not do in most other
languages.
When you code like this, it will help when someone unfamiliar with your
code has to read it. Anything in uppercase, you will already know what it
does. You can filter out : ; ." ! @ and such, which makes it quick to
identify the code you need to learn.
--Fred
Bruce Hoult
>Way to go Bruce! I see it was in Dylan.
Yes it was. And thanks.
>Most of the CL entries seemed to error out of the competition.
>Why did you use Dylan and not CL? I assume its because you are
>more comfortable with Dylan.
It's certainly true that at the moment I am more "comfortable" with
Dylan than with CL, but that's the result of a decision I made several
years ago that Dylan was on the whole the better language. Given the
semantic closeness of the two, if someone said to me today that they
wanted me to work on some system written in CL then I'm sure I'd be up
to speed with CL very quickly.
As for why I think Dylan is better than CL... they are very very
similar in terms of power. Dylan explicitly leaves out or simplifies
several things in CL: pattern-based macros (still Turing-complete,
though) instead of full procedural macros, no eval, no MOP, ... But
it also has a lot of improvements, from trivial but nice little things
such as "let" declarations not requiring extra levels of nesting, to
syntactic sugar for things such as array access, and on to a much
better framework for communicating to the compiler which parts of the
program can be made more static in order to get performance.
For example, in this contest Dylan allowed us to very quickly use a
full OO interface for the "attributes" (bold, italic, underlined,
fontsize, colour...) type, with generic functions for setting and
getting various attributes (no different to CLOS). Later on when this
proved to be a bottleneck it was possible to reimplement the
attributes class to be stored as a plain unboxed integer with
operations such as setting the bold attribute compiling down to a
single machine code OR instruction, with no changes required in the
client code.
>Next year perhaps, this year I was on vacation at the time and could
>not participate.
I'd recommend it. They have challenging tasks, and 72 hours is long
enough to get your teeth into some meat, but not so long that it's
hard to find the time if you really want to -- and because it's done
over the internet you don't have to travel anywhere.
I'd just got back to New Zealand from the US a couple of days
beforehand, which meant that I was still a bit jetlagged, but made it
easy to be awake at 3 am when the contest task was announced :-)
-- Bruce
Greg Menke
> > Maybe not for new code, but what about something that gets kicked
> > around for a few years going from one editor to another with all the
> > consequent confusion of tabs and spaces?
>
> Really really....really...it hasn't be a problem, AFAICT.
>
> IIRC, the only time you're in danger is if you mix tabs and spaces, and
> even then it's quite straightforward to manage it.
Well then you're lucky. But I'm talking about some imperfectly
understood, imperfectly modified big pile of code that is continually
tweaked to keep in line with some customer's needs. The modifications
being done by 10's of people with widely varying competence and
interest over a number of years, often unwillingly and using any old
editor from Notepad up to Emacs and including, heaven help us, vi.
I'm only saying that the whitespace blocking is susceptible to this
problem, and I wonder how well code can last in an enviornment such as
above.
> But is your dubioiusness even *prima facie* well founded? The Python
> libraries are fairly large globules of code, much of which has been
> evolved over >5 years, often with different people contributing,
> from different platforms (there's a robuts Mac Python community, for
> example).
I've no doubt the Python libraries will be exemplars of how to manage
Python over the long term. I'm talking about the 10,000 line huge
functions in the 500,000 line file that the original author never
modularized and 10 people since have fiddled with but never really
fixed or understood.
>
> (I'm sure that there are *some* combinations of tools and persons for
> which these are genuine problems...e.g., someone who has a deep seated
> fear of parentheses or feels compelled to zap whitespace on a regular
> basis. I'm perfectly comfortable telling these folks to avoid Lisp or
> Python, respectively, like the plague. :))
The problem is "these" people will use those tools. And what happens
to Python code that has had spaces hacked around until it works? Its
never been pristine and the first editor that uses a different regime
of spaces & tabs could well make a mess. When you inherit nasty,
legacy code, often the first thing that needs doing is zapping the
whitespace to get the indenting straightned out. Its not as big a
deal with code written using modern, auto-indenting editors, but can
well be with older code.
I'd also suggest that those people who fear parentheses <should> be
the ones experimenting with Lisp. With just a little application,
they'll become quite comfortable.
But we should stop this thread anyhow, its offtopic here.
Gregm
Colin Paul Gloster
"[..]
Fine with me, but you are not arguing against what I said, [..]
about learning and knowing a language before you
speak about it. Again, you shirk away from what I say to argue for your
own arguments in a void. I wonder who you think you are folling.
Your comments all turn out to be shallow, prejudiced, and _personal_
experiences, with absolutely no claim to universalizability. [..]"
He had written a partial (and sufficiently complete for the task at hand)
Forth environment; and he told us in
news:1f4c5c5c.0108...@posting.google.com that the team which
came up with the original Forth would not be able to fix the problem at all.
("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?"))
Marco Antoniotti
"Wade Humeniuk" <hume...@cadvision.com> writes:
> Bruce wrote:
>
> > And it seems appropriate to point out that no dynamically-typed language
> > has *ever* previously finished in the money in the ICFP contest, and
> > certainly nothing from the Lisp family. It's not from lack of trying --
> > this year there were five teams that submitted entries using Common Lisp
> > and six teams that used Scheme. None appear to have made the top couple
> > of dozen places.
> >
> > Why is that, for a language that is so good at rapid development of
> > complex algorithms?
Personally I do not think that the ICFP context is a good measure of
the power of a language, even as a "RAD" one.
The time constraints are way too low and you must remember that really
good CL programmer (like me, thanks :) ) are extremely lazy. I have
had the solution in mind for a rather complex problem for about three
weeks now, and so far, despite the infrastructure I have built in the
past year, I have written more or less 40 lines of it.
As per you comments on Dylan (Wade, not Bruce), I tend to agree. But
Dylan made a huge mistake by splitting off CL. Most of what is in
Dylan could and should have been achieved within CL IMHO.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.