Hello!
Please excuse me if this type of articles are not welcome here, but I
would like to ask you one question which gives me troubles in my
"intrahead" debates about whether to invest more time in learning LISP
or just continue with C or another popular language.
I know that LISP is very successfuly used in a few complex industrial
programs (and if believe the list on www.lisp.org, many more I've never
head of) as well as several userland applications such as EMACS. I also
know LISP can be used as THE most powerful scripting language instead
of shell scipting or even Perl/Python.
What I would like to know is what uses do you (meaning people who post
in this group or read it) use LISP for?
Thank you for your time,
rk
·········@gmx.net (Richard Krush) wrote in message news:<·························@localhost.localnet>...
> Hello!
Hi Richard!
> Please excuse me if this type of articles are not welcome here, but I
> would like to ask you one question which gives me troubles in my
> "intrahead" debates about whether to invest more time in learning LISP
> or just continue with C or another popular language.
No apologies needed. This is a perfectly fine article.
> I know that LISP is very successfuly used in a few complex industrial
> programs (and if believe the list on www.lisp.org, many more I've never
> head of) as well as several userland applications such as EMACS. I also
> know LISP can be used as THE most powerful scripting language instead
> of shell scipting or even Perl/Python.
>
> What I would like to know is what uses do you (meaning people who post
> in this group or read it) use LISP for?
Lisp was the third programming language I learned, after Basic and
Pascal. I first used it in 1981 on an Apple II, and I've been
programming in it ever since. In college I used it for just about
everything, including my CS class assignments. My colleagues worked
in Pascal mostly (this was when C was just beginning to get popular,
and Bjarne Stroustrup had not yet invented C with objects, which would
later become C++). They would work on a typical assignment for days
and turn in code printouts that were many inches thick. I would work
for an hour or two and turn in code that only took up a few pages.
(And I got A's.)
From 1988 to about 1992 I used Lisp to program a series of research
robots that eventually led to the Sojourner Rover on the Mars
Pathfinder mission. (Sojourner itself was programmed in C.) The
robots themselves did not run Lisp, their processors were too small
(8-bit processors with only a few k of RAM). Instead I used Lisp to
write a compiler for a custom-designed robot programming language that
compiled to machine code for the robot's processors. Writing the
compiler took only a couple of weeks (and would have only taken a
couple of days if I'd actually known what I was doing).
In 1993 I used Lisp to program a robot for the AAAI mobile robot
contest. I started working on the code for the contest on the flight
to the conference. The total time I spent coding was three (very
intense) days. I took a first and a second place, competing against
teams of programmers working for weeks or months in C.
In 1994 I used Lisp to produce a code patch for an instrument on the
Galileo spacecraft in orbit around Jupiter. The instrument (a
magnetometer) was programmed in Forth, and had developed a bad memory
byte (out of a total 4k bytes of memory). It was estimated that to
patch the Forth code (which is notoriously difficult to maintain)
would take so long that it was not feasable. I wrote a customized
Forth development environment in Lisp that was used to produce a code
patch. The total time it took to produce the development environment
and the code patch was three months. (The resulting patch is flying
today. It's the only thing this development environment was ever used
for.)
From 1995 to about 1998 I was part of a team using Lisp to program an
autonomous spacecraft (a project called Remote Agent which flew on a
spacecraft called DS1). At one point part of the team tried to
re-implement their part of the software in C++. After a year the
effort was declared a failure and they went back to Lisp.
In 2000 as an excercise I wrote a fully functional Web server in Lisp.
It took me about a month. It includes GET and POST methods, file
upload capability, user authentication, in short, just about
everything (except documentation).
I've written cryptography code, and robot and spacecraft simulators in
Lisp.
In short, I've used Lisp to do just about everything.
Erann Gat
···@flownet.com
From: Eric Moss
Subject: Re: A small survey (if you have couple of minutes)
Date:
Message-ID: <3B892BB9.7AF0DF0A@alltel.net>
Erann Gat wrote:
> [... lots of cool lisp projects ...]
We should get this published--everything from white papers to graffiti
artists blanketing the urban centers. :)
Seriously, there are a few pages here and there mentioning apps being
programmed in lisp, but not in great enough quantity or specificity to
convince a manager that LISP is the right tool. LISP is a good language
for all the "standard" projects as well, but it's tough to pitch that
idea when all we can point to is an autonomous art program or vague
references to "hard scientific problems".
Right now I am re-writing a medium (>>50,000 lines) Objective-C
commercial application in Common Lisp. As a metric, one particular
directory (~1600 lines of zero-white-space and zero-comment ObjC)
compresses to ~800 lines of lisp with two blank lines between every
function. Many classes are lists and sets, written in plain C for
"portability". They simply go away, as does so much code that is merely
bookkeeping support for the class hierarchy.
If and when this thing is complete I will provide a blurb about the
results (size, performance, cross-platform issues, etc.) I think it
would be good if everyone did something similar. I bet the results would
be rather formidable.
Eric
On Sun, 26 Aug 2001 12:02:49 -0500, Eric Moss wrote:
> Erann Gat wrote:
> > [... lots of cool lisp projects ...]
>
> We should get this published--everything from white papers to graffiti
> artists blanketing the urban centers. :)
>
> Seriously, there are a few pages here and there mentioning apps being
> programmed in lisp, but not in great enough quantity or specificity to
> convince a manager that LISP is the right tool. LISP is a good language
> for all the "standard" projects as well, but it's tough to pitch that
> idea when all we can point to is an autonomous art program or vague
> references to "hard scientific problems".
>
I was thinking about that, if this thread grows a bit, it would be very
beneficial to publish it on some well-known LISP page, such as
Association of LISP Users [1] or Cliki [2]. The first reply by Erann
Gat is already a pretty good advocate for LISP, if more such biographies
would follow, I'm sure it will be enough to convince many people and
companies to try LISP.
[1] http://www.lisp.org http://www.alu.org
[2] http://ww.telent.net/cliki/index
> Right now I am re-writing a medium (>>50,000 lines) Objective-C
> commercial application in Common Lisp. As a metric, one particular
> directory (~1600 lines of zero-white-space and zero-comment ObjC)
> compresses to ~800 lines of lisp with two blank lines between every
> function. Many classes are lists and sets, written in plain C for
> "portability". They simply go away, as does so much code that is merely
> bookkeeping support for the class hierarchy.
>
> If and when this thing is complete I will provide a blurb about the
> results (size, performance, cross-platform issues, etc.) I think it
> would be good if everyone did something similar. I bet the results would
> be rather formidable.
>
I agree here, not only will people see the power of LISP, but they will
also be able to compare it with the "popular" languages.
Thank you for your reply,
rk
·········@gmx.net (Richard Krush) wrote in message news:<·························@localhost.localnet>...
> On Sun, 26 Aug 2001 12:02:49 -0500, Eric Moss wrote:
> > Erann Gat wrote:
> > > [... lots of cool lisp projects ...]
> >
> > We should get this published--everything from white papers to graffiti
> > artists blanketing the urban centers. :)
> >
> > Seriously, there are a few pages here and there mentioning apps being
> > programmed in lisp, but not in great enough quantity or specificity to
> > convince a manager that LISP is the right tool. LISP is a good language
> > for all the "standard" projects as well, but it's tough to pitch that
> > idea when all we can point to is an autonomous art program or vague
> > references to "hard scientific problems".
> >
>
> I was thinking about that, if this thread grows a bit, it would be very
> beneficial to publish it on some well-known LISP page, such as
> Association of LISP Users [1] or Cliki [2]. The first reply by Erann
> Gat is already a pretty good advocate for LISP, if more such biographies
> would follow, I'm sure it will be enough to convince many people and
> companies to try LISP.
Well, I certainly hope you're right, but I'm afraid I don't share your
optimism. The reason companies don't use Lisp is not that there
aren't enough published success stories. The reason companies don't
use Lisp is that a lot of companies *did* try Lisp in the AI boom of
the 1980's and they all went out of business. Perhaps the same thing
will happen to Java with the dotcom bust, but I wouldn't bet on it.
Sun has shown a lot of marketing savvy. Lisp might do well to borrow
a page from their script: whenever Java fails at something they
reposition it to be something else. Remember, Java wasn't always the
server-side Web programming language. It started out as a language
for programming cell phones and copying machines. When it failed at
that Sun repositioned it to be the write-once-run-anywhere language
that would evenutally replace Windows on the desktop. When it failed
at that it was repositioned where it is today, as a server side Web
programming language. When people start to realize it has failed at
that no doubt Sun will reposition it somewhere else.
The problem with Lisp is that it has never been repositioned since it
"failed" as an AI language. I put failed in quotes because it's not
clear that Lisp really failed, but that's irrelevant. In the world of
business, perception is truth. I mean that quite literally. Dollars
have more value than rubles *only* because everyone *thinks* that
dollars have more value than rubles. And because everyone thinks it,
it's actually true. It's the same with programming languages.
Because enough people think that Java is a good language for Web
programming, it actually is. Not from the programmer's point of view,
of course, Java largely sucks. But from a *business* point of view
Java is perfectly fine because Java programmers are a commodity. You
let *them* deal with the sucky aspects of Java. And if one of them
starts to rock the boat by pointing out how Java sucks and Lisp is
better you fire him because he's not a team player. (Lispers are
actually notoriously bad team players precisely because Lisp is such a
great programming language. It tends to attract independent thinkers
because it lets them be much more productive then they could otherwise
be. If there's anyone out there who can figure out how to turn this
into a successful business model he could become fabulously wealthy.)
BTW, if anyone out there thinks I'm wrong and that the only thing
standing between them and having their company using Lisp is a few
success stories, let me know. I'll be happy to provide some. (And if
anyone out there thinks the only thing standing between them and
having their company use Lisp is the availability of Lisp programmers
I'd be happy to provide one or two of those as well.)
Erann
···@flownet.com
···@flownet.com (Erann Gat) wrote in message news:<····························@posting.google.com>...
> BTW, if anyone out there thinks I'm wrong and that the only thing
> standing between them and having their company using Lisp is a few
> success stories, let me know. I'll be happy to provide some. (And if
Why should anyone spend months or years evangelizing Lisp to try to
get their company to rewrite its software in it, when they could just
spend that time rewriting it themselves? If Lisp ever takes over the
world, it's likely to be by a stealth attack from within rather than a
missile attack from without. The evangelist grows a reputation as a
pest, and could get laid off or fired at any random time. The person
who does the work himself grows a reputation as the ultimate company
geek and key employee.
Even better might be to write new apps in Lisp as soon as their need
becomes clear, while the company is still trying to decide how to fill
that need, or even before the need crystalizes enough to become clear.
Once you have enough Lisp apps in daily use by your coworkers, Lisp
will have become one of your company's main programming languages.
The key phrase in the above is "will have become". Trying for Lisp to
get its foot in the door is the wrong approach in most cases. It's
better for it to introduce itself from within, as if it had always
been there.
··········@mailandnews.com (Software Scavenger) writes:
> Why should anyone spend months or years evangelizing Lisp to try to
> get their company to rewrite its software in it, when they could just
> spend that time rewriting it themselves?
Oh, easy. It's much, much easier to stand around bitching about how,
if only the company did x, then it would make huge money and
everything would be better and so on and so forth, than actually to
sit down and quietly do x. It's especially good to do this when you
are fairly sure that x will not get done, or you can raise convincing
objections to getting it done ('the software is too expensive', 'the
lisp vendors do not support elaborate-protocol-of-the-week', 'loop is
too hard to read', 'my elbow hurts') to avoid your bluff ever being
called.
You have only to read c.l.l for a few weeks to see about 95% of the
posters doing this.
From: Eric Moss
Subject: Re: A small survey (if you have couple of minutes)
Date:
Message-ID: <3B8A714E.F26756@alltel.net>
Tim Bradshaw wrote:
>
> ··········@mailandnews.com (Software Scavenger) writes:
>
> > Why should anyone spend months or years evangelizing Lisp to try to
> > get their company to rewrite its software in it, when they could just
> > spend that time rewriting it themselves?
>
> Oh, easy. It's much, much easier to stand around bitching about how,
> if only the company did x, then it would make huge money and
> everything would be better and so on and so forth, than actually to
> sit down and quietly do x. It's especially good to do this when you
> are fairly sure that x will not get done, or you can raise convincing
> objections to getting it done ('the software is too expensive', 'the
> lisp vendors do not support elaborate-protocol-of-the-week', 'loop is
> too hard to read', 'my elbow hurts') to avoid your bluff ever being
> called.
>
> You have only to read c.l.l for a few weeks to see about 95% of the
> posters doing this.
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,
"Eric Moss" <········@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
From: Eric Moss
Subject: Re: A small survey (if you have couple of minutes)
Date:
Message-ID: <3B8AB17A.B6B6F6B5@alltel.net>
Marc Battyani wrote:
>
> "Eric Moss" <········@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
"Marc Battyani" <·············@fractalconcept.com> wrote in message
·······················································@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.
"Sandeep Koranne" <···············@nospam.philips.com> wrote
>
> "Marc Battyani" <·············@fractalconcept.com> wrote in message
> >
> > I had the same problems when I was a research engineer in a Phillips
> > research lab.
> > So I quitted and started my own (small!) company. Now I program in Lisp
> and
> > VHDL and I can do all the electronics I want.
> I hate to correct you, but not all of NatLab is like that.
> PS: NatLab is the name of Philips Research Labs in Eindhoven, The
> Netherlands.
Why do you think I'm talking about NatLab ?
I didn't give the Lab name nor the year .
> I have been programming in Harlequin LispWorks here in NatLab and have
> already made some
> nice EDA applications that are in use :) runs on Sun Solaris, HP-UX, Linux
> and Windows, uses CAPI.
Great!
> Its unfair to taint the name of the whole lab just because of your one
> (isolated) experience.
I don't see where I tainted a whole lab. I said "I had the same problems",
"I" meaning me not the whole lab....
As it's rather off topic, we should switch to e-mail if you want to discuss
more about this.
Marc
Eric Moss <········@alltel.net> writes:
>
> I would love to quietly just do something in lisp, but for those in a
> big corporation, it's not possible without managerial support. We don't
> have control over what apps will go on our machines--centralized
> sysadmins do, and they often deny requests from our managers. I fought
> for 6 months just to get a *newer version* of Python so I could update a
> few scripts. To get Allegro or Lispworks on a machine, not only do I
> need 3 levels of management to agree, I have to spend my own money on
> it, and then they would demand ownership of what I paid for--then they
> wouldn't support it. They won't let CMUCL on a machine because it's not
> commercially supported, but won't spring $800 to get Lispworks, which
> is. They won't provide any support at all until I have a full, working
> version DONE and interoperating with apps that took 50 people 10 years
> to write.
>
Well, you're cleaerly living in hell, and if it's as nasty as you say
you should get out. Sure, some (not all) large companies are crap in
this way, but the solution is still not to stand around bitching.
Quite apart from anything else if the organisation you work for is as
bad as you describe their just waiting for someone else to eat them
alive... (Of course the middle of a recession may not be the best
time to mmove, I know.)
>
> PS. If we weren't so independent-minded (maybe BECAUSE we are?), I'd say
> a bunch of us should come up with a business plan, get funding, and
> start our own company. Not that I'm a big fan of companies, but that's
> how the existing economic system forces us to play.
>
So long as the business plan isn't 'we'll do cool things in Lisp'.
Too many people seem to think that, or an equivalent, the most recent
being 'we'll do cool things on the web', is enough.
--tim
Eric Moss <········@alltel.net> writes:
>
> I would love to quietly just do something in lisp, but for those in a
> big corporation, it's not possible without managerial support. We don't
> have control over what apps will go on our machines--centralized
> sysadmins do, and they often deny requests from our managers. I fought
> for 6 months just to get a *newer version* of Python so I could update a
> few scripts. To get Allegro or Lispworks on a machine, not only do I
> need 3 levels of management to agree, I have to spend my own money on
> it, and then they would demand ownership of what I paid for--then they
> wouldn't support it. They won't let CMUCL on a machine because it's not
> commercially supported, but won't spring $800 to get Lispworks, which
> is. They won't provide any support at all until I have a full, working
> version DONE and interoperating with apps that took 50 people 10 years
> to write.
>
Well, you're clearly living in hell, and if it's as nasty as you say
you should get out. Sure, some (not all) large companies are crap in
this way, but the solution is still not to stand around bitching.
Quite apart from anything else if the organisation you work for is as
bad as you describe they're just waiting for someone else to eat them
alive... (Of course the middle of a recession may not be the best
time to mmove, I know.)
>
> PS. If we weren't so independent-minded (maybe BECAUSE we are?), I'd say
> a bunch of us should come up with a business plan, get funding, and
> start our own company. Not that I'm a big fan of companies, but that's
> how the existing economic system forces us to play.
>
So long as the business plan isn't 'we'll do cool things in Lisp'.
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
··········@mailandnews.com (Software Scavenger) writes:
> ···@flownet.com (Erann Gat) wrote in message news:<····························@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
·············@fast.no
On 26 Aug 2001 23:39:29 -0700, ···@flownet.com (Erann Gat) wrote:
> BTW, if anyone out there thinks I'm wrong and that the only thing
> standing between them and having their company using Lisp is a few
> success stories, let me know. I'll be happy to provide some. (And if
I don't think that, and I don't currently need to sell Lisp to any company.
But since I am interested in how Lisp is used, I would appreciate it if you
could provide those stories anyway.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
Paolo Amoroso <·······@mclink.it> wrote in message news:<····························@4ax.com>...
> On 26 Aug 2001 23:39:29 -0700, ···@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.
In article <····························@posting.google.com>, Erann Gat
wrote about numerous interesting space-related projects, including:
"[..]
In 1994 I used Lisp to produce a code patch for an instrument on the
Galileo spacecraft in orbit around Jupiter. The instrument (a
magnetometer) was programmed in Forth, and had developed a bad memory
byte (out of a total 4k bytes of memory). It was estimated that to
patch the Forth code (which is notoriously difficult to maintain)
would take so long that it was not feasable."
I do not understand this. Why was this Forth source code so hard to maintain?
"I wrote a customized Forth development environment in Lisp that was used to
produce a code patch. The total time it took to produce the development
environment and the code patch was three months. (The resulting patch
is flying today. It's the only thing this development environment was ever used
for.)
[..]"
So was your one-off Forth system superior to the one used earlier?
Thanks for the interesting post,
Colin Paul Gloster
··················@ACM.org (Colin Paul Gloster) wrote in message news:<·································@camac.dcu.ie>...
> In article <····························@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.
From: Michael Coughlin
Subject: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3B8C20A6.C36A5912@ne.mediaone.net>
Erann Gat wrote:
>
> ··················@ACM.org (Colin Paul Gloster) wrote in
> message
> news:<·································@camac.dcu.ie>...
> > In article > <····························@posting.google.com>,
> > Erann Gat wrote about numerous interesting space-related
> > projects, including:
> >
> > "[..]
> >
> > In 1994 I used Lisp to produce a code patch for an
> > instrument on the Galileo spacecraft in orbit around
> > Jupiter. The instrument (a magnetometer) was programmed
> > in Forth, and had developed a bad memory byte (out of a
> > total 4k bytes of memory). It was estimated that to
> > patch the Forth code (which is notoriously difficult to
> > maintain) would take so long that it was not feasable."
> >
> > I do not understand this. Why was this Forth source
> > code so hard to maintain?
>
> Forth code in general is pretty notorious for being hard
> to maintain, and this forth code in particular was hard to
> maintain because it was generated by a development
> environment that ran only on an Apple II, which was about
> 15 years obsolete by the time this problem arose.
> Also, Forth programmers are almost as hard to find as Lisp
> programmers.
>
> > "I wrote a customized Forth development environment in
> > Lisp that was used to produce a code patch. The total
> > time it took to produce the development environment
> > and the code patch was three months. (The resulting patch
> > is flying today. It's the only thing this development
> > environment was ever used for.)
> >
> > [..]"
> >
> > So was your one-off Forth system superior to the one
> > used earlier?
>
> I never actually got to use the original system (since as
> noted above it only ran on an Apple II, which I did not
> have at my disposal) so I can't say. My system was not a
> complete implementation of Forth, just enough to recompile
> the code that ran on the instrument. On the other hand,
> my system let you write Forth in Lisp sytax, which means
> you could use Lisp macros to write Forth. That's something
> I'm fairly certain the original system didn't let you do.
I've cross posted this to comp.lang.forth since Forth
programmers will want to read and comment on it. You are right.
Forth programs are "pretty notorious for being hard to
maintain". This is not the fault of the Forth language. It is
the fault of Forth programmers and the people who hire them. You
indicate the reason very clearly when you state "Forth
programmers are almost as hard to find as Lisp programmers", so
when an old Forth program needs to be updated, all heck breaks
loose, since there is usually nobody around who knows how to
program in Forth. This particular problem with a Forth program
was solved by someone who programmed in Lisp. Perhaps being a
user of Lisp indicates an interest in a variety of languages so
you got the job that the other programmers who only knew popular
languages wouldn't touch.
Forth could be very easy to read and maintain if Forth
programmers would realize it takes much extra effort to comment
and document it properly. And by that I mean write so the code
can be read by managers (even if they didn't want to). When I
suggest such things to Forth programmers, they reject the idea
for reasons that I will not repeat here. I want managers to use
Forth and not shudder in terror when it is mentioned.
I would be interested to know how Lisp programmers write
code that other programmers can read. When I look at Lisp it
makes no sense to me, particularly the parts with all the
parentheses. Forth code does make sense, but I still can't know
what a Forth program does when things that are obvious to the
original programmer are not written down.
--
Michael Coughlin ··········@ne.mediaone.net Cambridge, MA USA
From: Elizabeth D. Rather
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3B8C342C.546482E4@forth.com>
Michael Coughlin wrote:
> Erann Gat wrote:
> > > I do not understand this. Why was this Forth source
> > > code so hard to maintain?
> >
> > Forth code in general is pretty notorious for being hard
> > to maintain, and this forth code in particular was hard to
> > maintain because it was generated by a development
> > environment that ran only on an Apple II, which was about
> > 15 years obsolete by the time this problem arose.
> > Also, Forth programmers are almost as hard to find as Lisp
> > programmers.
> >
> > > [..]"
> > >
>
> I've cross posted this to comp.lang.forth since Forth
> programmers will want to read and comment on it. You are right.
> Forth programs are "pretty notorious for being hard to
> maintain". This is not the fault of the Forth language. It is
> the fault of Forth programmers and the people who hire them. You
> indicate the reason very clearly when you state "Forth
> programmers are almost as hard to find as Lisp programmers", so
> when an old Forth program needs to be updated, all heck breaks
> loose, since there is usually nobody around who knows how to
> program in Forth. This particular problem with a Forth program
> was solved by someone who programmed in Lisp. Perhaps being a
> user of Lisp indicates an interest in a variety of languages so
> you got the job that the other programmers who only knew popular
> languages wouldn't touch.
Having been writing and maintaining Forth programs (and supporting
customers doing the same) for 30 years, I must say it's definitely
_not_ been our experience that Forth is hard to maintain. For
example, we have a current customer in San Francisco running
a very complex Forth database application originally written in
1977 on a PDP-11. It's since been ported to several newer
architectures and modified a lot, all by engineers who were not
involved in the original project.
Also, nowadays, Forth programmers aren't hard to find: just ask
your favorite search engine for "Forth". But they may not live
next door...
> Forth could be very easy to read and maintain if Forth
> programmers would realize it takes much extra effort to comment
> and document it properly. And by that I mean write so the code
> can be read by managers (even if they didn't want to). When I
> suggest such things to Forth programmers, they reject the idea
> for reasons that I will not repeat here. I want managers to use
> Forth and not shudder in terror when it is mentioned.
It is perfectly possible to write Forth code that can be read
and maintained by anyone familiar with Forth (managers
included). It's pretty hard to write code, particularly complex
code, in any language that can be maintained by someone
unfamiliar with that language, beyond the simplest management
of configuration constants and the like. Do you folks write
Lisp in such a way that a person who has never learned Lisp
can maintain it?
> I would be interested to know how Lisp programmers write
> code that other programmers can read. When I look at Lisp it
> makes no sense to me, particularly the parts with all the
> parentheses. Forth code does make sense, but I still can't know
> what a Forth program does when things that are obvious to the
> original programmer are not written down.
Yes, programmers should certainly document what they're
doing and why, even for themselves (folks do forget things).
But that's not a need peculiar to any language more than any
other.
Cheers,
Elizabeth
--
================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
================================================
In article <·················@ne.mediaone.net>, Michael Coughlin wrote:
> I've cross posted this to comp.lang.forth since Forth
>programmers will want to read and comment on it. You are right.
>Forth programs are "pretty notorious for being hard to
>maintain". This is not the fault of the Forth language. It is
>the fault of Forth programmers and the people who hire them. You
You are generalizing about Forth programmers, and crossposting
to comp.lang.forth. That makes you a troll.
I found Erann Gat's account of the various past projects involving Lisp
quite interesting. Now I think this is going to devolve into some kind
of stupid flamewar between two comp.lang.* newsgroups.
> Forth could be very easy to read and maintain if Forth
>programmers would realize it takes much extra effort to comment
>and document it properly. And by that I mean write so the code
>can be read by managers (even if they didn't want to). When I
>suggest such things to Forth programmers, they reject the idea
>for reasons that I will not repeat here.
Which Forth programmers, where? Are they a sufficiently large,
unbiased, random sample of Forth programmers from which some
statistical inferences can be made about the entire population
of Forth programmers?
From: Michael Coughlin
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3B8DE20E.F684E481@ne.mediaone.net>
Kaz Kylheku wrote:
>
> In article <·················@ne.mediaone.net>, Michael
> Coughlin wrote:
> > I've cross posted this to comp.lang.forth since Forth
> >programmers will want to read and comment on it. You are
> >right. Forth programs are "pretty notorious for being
> >hard to maintain". This is not the fault of the Forth
> >language. It is the fault of Forth programmers and the
> >people who hire them.
>
> You are generalizing about Forth programmers, and
> crossposting to comp.lang.forth. That makes you a troll.
>
> I found Erann Gat's account of the various past projects
> involving Lisp quite interesting. Now I think this is going
> to devolve into some kind of stupid flamewar between two
> comp.lang.* newsgroups.
I also found the account of the project involving Forth and
Lisp to be very interesting. I would like to know more about why
a Lisp programmer would say a Forth program was hard to
maintain. I think Lisp programs would also be hard to maintain.
How does a Lisp programmer make his code easier to maintain than
a Forth programmer?
The original post had some intriguing statements about a
Forth program on a NASA space probe. It was developed on an
Apple II computer with a very old version of Forth. Lisp was
used to modify the original program to correct a hardware
problem. I am very curious as to why Lisp was used when Forth
systems have excellent methods for modifying and correcting
Forth code built right in. Old Forth code from the days of the
Apple II can be maintained with new Forth systems running on the
latest computers. What was the advantage of using Lisp?
Are questions like this trolls?
> > Forth could be very easy to read and maintain if Forth
> >programmers would realize it takes much extra effort to
> >comment and document it properly. And by that I mean write
> >so the code can be read by managers (even if they didn't
> >want to). When I suggest such things to Forth programmers,
> >they reject the idea for reasons that I will not repeat
> >here.
> Which Forth programmers, where? Are they a sufficiently
> large, unbiased, random sample of Forth programmers from
> which some statistical inferences can be made about the
> entire population of Forth programmers?
Nope, my random sample is completely unscientific and
statistically invalid. I just go around to people who have
software projects that could benefit from using Forth and tell
them they should use Forth. Usually they don't know anything
about Forth. When they do, they almost always say Forth is
impossible to maintain. I don't meet any current users of Forth
this way, since the number of people who do use Forth is much
smaller that the number of people who would use it if they knew
what it was and how it could be maintained. I meet more users of
Lisp than Forth in this random way since I live near a large
educational institution that teaches Lisp.
--
Michael Coughlin ··········@ne.mediaone.net Cambridge, MA USA
From: Gary Chanson
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <l3mj7.39$v6.4697@news.shore.net>
"Michael Coughlin" <··········@ne.mediaone.net> wrote in message
······················@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
·········@shore.net
-Abolish Public Schools.
From: Elizabeth D. Rather
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3B8E74E5.D04A373F@forth.com>
Michael Coughlin wrote:
> I also found the account of the project involving Forth and
> Lisp to be very interesting. I would like to know more about why
> a Lisp programmer would say a Forth program was hard to
> maintain. I think Lisp programs would also be hard to maintain.
> How does a Lisp programmer make his code easier to maintain than
> a Forth programmer?
>
> The original post had some intriguing statements about a
> Forth program on a NASA space probe. It was developed on an
> Apple II computer with a very old version of Forth. Lisp was
> used to modify the original program to correct a hardware
> problem. I am very curious as to why Lisp was used when Forth
> systems have excellent methods for modifying and correcting
> Forth code built right in. Old Forth code from the days of the
> Apple II can be maintained with new Forth systems running on the
> latest computers. What was the advantage of using Lisp?
Almost certainly there was no Apple II running the original host
Forth available. Also, the guy was obviously a Lisp heavy who
didn't know any Forth, so he did what came naturally: use the
tools you have and know.
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."
================================================
From: Stephen Pelc
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3b8ce4ce.403072938@192.168.0.1>
On Tue, 28 Aug 2001 22:56:52 GMT, Michael Coughlin
<··········@ne.mediaone.net> wrote:
> Forth could be very easy to read and maintain if Forth
>programmers would realize it takes much extra effort to comment
>and document it properly. And by that I mean write so the code
>can be read by managers (even if they didn't want to).
You could easily remove "Forth" from this and substitute
the name of some other language. Regardless of language,
writing for maintenance is a matter of management and
corporate culture.
Over the last three years we have switched over to a tool
chain (Forth) which extracts documentation as formal
comments from the source code and then generates HTML
and/or PDF manuals. The effect of this has been to
encourage our own programmers and our clients to write
the documentation as the code is written.
When we looked at literate programming tools some years
ago, the problem was that the source for the compiler and
the documentation could get out of step. In our system there
is only ever one file, and the documentation is contained
within formal comments.
Again, documentation and maintainability are NOT a language
issue.
Stephen
--
Stephen Pelc, ···@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
From: Bernd Paysan
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3B8D1459.4A42374C@mikron.de>
Stephen Pelc wrote:
> When we looked at literate programming tools some years
> ago, the problem was that the source for the compiler and
> the documentation could get out of step. In our system there
> is only ever one file, and the documentation is contained
> within formal comments.
I think the "poor man's literate programming tools" for Forth always
provided that (making e.g. \end{verbatim} a comment seeking for
\begin{verbatim}). However, having used a normal literate programming
tool (noweb), my experience is that the work to avoid documentation and
source decoupling is just to set up a make file.
> Again, documentation and maintainability are NOT a language
> issue.
As I wrote, readability for minority languages can be an issue if both
writer and reader don't use the language well. This has nothing to do
with the language, just that you find more people not very fluent in the
language (which makes it less readable to them).
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
From: Michael Coughlin
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3B8DE2B5.6CCFA6F6@ne.mediaone.net>
Stephen Pelc wrote:
>
> On Tue, 28 Aug 2001 22:56:52 GMT, Michael Coughlin
> <··········@ne.mediaone.net> wrote:
> > Forth could be very easy to read and maintain if Forth
> >programmers would realize it takes much extra effort to
> >comment and document it properly. And by that I mean write
> >so the code can be read by managers (even if they didn't
> >want to).
> You could easily remove "Forth" from this and substitute
> the name of some other language. Regardless of language,
> writing for maintenance is a matter of management and
> corporate culture.
>
> Over the last three years we have switched over to a tool
> chain (Forth) which extracts documentation as formal
> comments from the source code and then generates HTML
> and/or PDF manuals. The effect of this has been to
> encourage our own programmers and our clients to write
> the documentation as the code is written.
>
> When we looked at literate programming tools some years
> ago, the problem was that the source for the compiler and
> the documentation could get out of step. In our system there
> is only ever one file, and the documentation is contained
> within formal comments.
>
> Again, documentation and maintainability are NOT a language
> issue.
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.
--
Michael Coughlin ··········@ne.mediaone.net Cambridge, MA USA
From: Stephen Pelc
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3b8e0837.477674259@192.168.0.1>
On Thu, 30 Aug 2001 06:57:04 GMT, Michael Coughlin
<··········@ne.mediaone.net> wrote:
> I agree with this. Now the problem is what to do with the
>people who have seen Forth in the past and decided that it is
>useless because it is unreadable and unmaintainable. Can you
>think of a way to show them what good Forth code should look
>like?
Free downloads of the evaluation version of VFX Forth for
Windows are available from our web site. DOCGEN is included
and the VFX Forth manual is *entirely* produced by DOCGEN.
Stephen
--
Stephen Pelc, ···@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
From: Albert van der Horst
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <GIw4Av.MJw.1.spenarn@spenarnc.xs4all.nl>
In article <··················@192.168.0.1>,
Stephen Pelc <···@mpeltd.demon.co.uk> wrote:
>On Tue, 28 Aug 2001 22:56:52 GMT, Michael Coughlin
><··········@ne.mediaone.net> wrote:
>> Forth could be very easy to read and maintain if Forth
>>programmers would realize it takes much extra effort to comment
>>and document it properly. And by that I mean write so the code
>>can be read by managers (even if they didn't want to).
>You could easily remove "Forth" from this and substitute
>the name of some other language. Regardless of language,
>writing for maintenance is a matter of management and
>corporate culture.
>
>Over the last three years we have switched over to a tool
>chain (Forth) which extracts documentation as formal
>comments from the source code and then generates HTML
>and/or PDF manuals. The effect of this has been to
>the documentation as the code is written.
I used and use the same technique in creating and maintaining ciforth.
In fact ciforth started out as fig-forth and I maintained the
documentation up to date through all modifications, improving the
automation of the documentation on the way.
I think it is a good method. However. There is still a need for
overview documentation that should be added at the appropriate level.
A dead simple example. In all glossary descriptions you use ``sc''
(string constant) for an address, length pair to mean that it contains
printable characters. One (or all) of these glossary descriptions is
not the appropriate place to explain this kind of legend information.
Charles Moore (provocatively) has stated that the "overview"
documentation (in case the glossary) should be sufficient, and that
at the lower level you should not need more than a few stack
reminders. I have in fact no trouble with that. I am convinced that
Chuck writes documentation in parallel, like all productive
programmers I have ever met. That is the point that matters.
Write the information down while you are aware of it. Be it in
separate files, the same file or parallel screens. That comes
secondary.
I presume MPE (with its commercial background) agrees
that there are levels up, that cannot be reasonably added to
the code.
In the generic assembler file of ciforth each word's definition is
preceeded by a formal comment containing:
1. name
2. wordlist
3. stack effect
4. portability (ISO, FIG, F83)
5. Description
6. Sample code with the required outcome. Several of them
7. See also. Related words. Several of them.
The wordlist is used to order the documentation in chapters.
The sample code is used to generate the test code.
The see also is used to generate references in texinfo or
html.
make testlina
goes a long way towards ensuring that I didn't break anything.
The descriptions go in the reference section of the manual,
but there are other sections needed as well.
>When we looked at literate programming tools some years
>ago, the problem was that the source for the compiler and
>the documentation could get out of step. In our system there
>is only ever one file, and the documentation is contained
>within formal comments.
One of my favorite gripes with programming tools is the following:
if I have chosen a wrong name at the start I am stuck with it.
Improving names is one of the most important things to do in
a design process. The relevance of these tools for cross platform
parallel processing, inhomogeneous, real time systems is zill.
Now that was my last job. I could use some help indeed.
That was supplied by good old traditional Unix tools.
>Again, documentation and maintainability are NOT a language
>issue.
Not per se. Fully agreed.
>Stephen
Albert
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
To suffer is the prerogative of the strong. The weak -- perish.
······@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
From: Stephen Pelc
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3b8f5b46.564412542@192.168.0.1>
On Thu, 30 Aug 2001 16:54:31 GMT, ······@spenarnc.xs4all.nl (Albert
van der Horst) wrote:
>I think it is a good method. However. There is still a need for
>overview documentation that should be added at the appropriate level.
...
>I presume MPE (with its commercial background) agrees
>that there are levels up, that cannot be reasonably added to
>the code.
That is why DOCGEN allows you to define section numbering and to
change the output file whenever you want to. These make organising
the documentation much easier.
>In the generic assembler file of ciforth each word's definition is
>preceeded by a formal comment containing:
>1. name
>2. wordlist
>3. stack effect
>4. portability (ISO, FIG, F83)
>5. Description
>6. Sample code with the required outcome. Several of them
>7. See also. Related words. Several of them.
For safety critical systems, DOCGEN/SC copes with nearly all of this,
including the generation of test files. The output is documentation
to US FDA standard. Our client produces anaesthetic ventilators for
use in operating theatres, so it really does matter. One of the
good side effects is that when code is reused, the documentation
is also reused. The final documentation is about 1500 pages
produced in about two minutes, most of which is consumed by
having to run the TeX and PDF tools.
Stephen
--
Stephen Pelc, ···@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
WOW! (positive flames) This idea sounds super great. I had tried to
write something like that below when I was Disk Librarian of SVFIG in
the 80ies.
I would like to use the "TOOL CHAIN (FORTH)" on some of the Forth's
that I use like Win32Forth. Is it a commercial product or an
extension to Forth or what? please expound more.
········@pacbell.net
Stephen Pelc wrote:
<snip snip>
> Over the last three years we have switched over to a tool
> chain (Forth) which extracts documentation as formal
> comments from the source code and then generates HTML
> and/or PDF manuals. The effect of this has been to
> encourage our own programmers and our clients to write
> the documentation as the code is written.
>
> When we looked at literate programming tools some years
> ago, the problem was that the source for the compiler and
> the documentation could get out of step. In our system there
> is only ever one file, and the documentation is contained
> within formal comments.
>
> Stephen
From: Stephen Pelc
Subject: Re: Documenting Forth with a Tool Chain - Was Maintaining Minority Languages
Date:
Message-ID: <3b9a9de3.92322162@192.168.0.1>
On 3 Sep 2001 12:21:48 -0700, ········@pacbell.net (John A. Peters)
wrote:
>WOW! (positive flames) This idea sounds super great. I had tried to
>write something like that below when I was Disk Librarian of SVFIG in
>the 80ies.
>I would like to use the "TOOL CHAIN (FORTH)" on some of the Forth's
>that I use like Win32Forth. Is it a commercial product or an
>extension to Forth or what? please expound more.
>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.
It is a commercial product.
DOCGEN is provided as part of all versions of MPE's VFX Forth
for Windows, including the evaluation version. DOCGEN is able
to process any Forth source code in text files. If you use
the phrase:
S" <filename>" PARSED
DOCGEN will not try to compile the file, but will just extract
the DOCGEN comments. This allows DOCGEN to be used with Forth
source code "foreign" to VFX Forth, such as embedded system
Forth or even xxxForth from a non-MPE source.
Stephen
--
Stephen Pelc, ···@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
Michael Coughlin <··········@ne.mediaone.net> wrote in message news:<·················@ne.mediaone.net>...
> Erann Gat wrote:
> > Forth code in general is pretty notorious for being hard
> > to maintain,
[snip]
> I've cross posted this to comp.lang.forth since Forth
> programmers will want to read and comment on it. You are right.
> Forth programs are "pretty notorious for being hard to
> maintain". This is not the fault of the Forth language. It is
> the fault of Forth programmers and the people who hire them. You
> indicate the reason very clearly when you state "Forth
> programmers are almost as hard to find as Lisp programmers", so
> when an old Forth program needs to be updated, all heck breaks
> loose, since there is usually nobody around who knows how to
> program in Forth.
I think there's more to it than that. Forth functions don't have
named argument lists, and no clear delineation of block structure.
(At least this was the case at the time. I haven't used Forth in many
years; maybe things are different now.) In other languages you can at
least tell how many arguments you're supposed to pass to a function
just by looking at the code. While I acknowledge that it is possible
to write maintainable Forth I believe it requires more conscious
effort on the part of the programmer than in other languages.
> This particular problem with a Forth program
> was solved by someone who programmed in Lisp. Perhaps being a
> user of Lisp indicates an interest in a variety of languages so
> you got the job that the other programmers who only knew popular
> languages wouldn't touch.
I got the job by being the only one foolish enough to insist that I
could do it within the time and budget constraints. It was actually
quite a struggle to get the support. No one believed it could be
done. ("Let's get this straight, son. The team who built the thing
is telling me they can't do it at all, and you're telling me you can
do it in three months by building a new compiler? What have you been
smoking?")
> I would be interested to know how Lisp programmers write
> code that other programmers can read. When I look at Lisp it
> makes no sense to me, particularly the parts with all the
> parentheses.
This is a pretty blatant troll. I'll answer in the manner in which it
was written, though it doesn't really reflect my true feelings: I
wonder how Forth programmers write code that other programmers can
read. When I look at Forth it makes no sense to me, particularly
since it has no punctuation.
Erann Gat
···@flownet.com
From: Elizabeth D. Rather
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3B8FCD31.47AA01D8@forth.com>
Erann Gat wrote:
> > I've cross posted this to comp.lang.forth since Forth
> > programmers will want to read and comment on it. You are right.
> > Forth programs are "pretty notorious for being hard to
> > maintain". This is not the fault of the Forth language. It is
> > the fault of Forth programmers and the people who hire them. You
> > indicate the reason very clearly when you state "Forth
> > programmers are almost as hard to find as Lisp programmers", so
> > when an old Forth program needs to be updated, all heck breaks
> > loose, since there is usually nobody around who knows how to
> > program in Forth.
>
> I think there's more to it than that. Forth functions don't have
> named argument lists, and no clear delineation of block structure.
> (At least this was the case at the time. I haven't used Forth in many
> years; maybe things are different now.) In other languages you can at
> least tell how many arguments you're supposed to pass to a function
> just by looking at the code. While I acknowledge that it is possible
> to write maintainable Forth I believe it requires more conscious
> effort on the part of the programmer than in other languages.
It is customary in Forth to follow the name of each new definition
by a "stack comment" showing the number, order, and types of
stack arguments into and out of that defintion. ANS Forth (1994)
gave models for this (and recommended notation) which is widely
followed. Responsible Forth programmers (and in my experience
most are) regard these comments as just as mandatory as argument
lists in other languages, even though most compilers don't enforce
the requirement. It is also recommended (and common) practice
to add a comment as to intended usage.
> > I would be interested to know how Lisp programmers write
> > code that other programmers can read. When I look at Lisp it
> > makes no sense to me, particularly the parts with all the
> > parentheses.
>
> This is a pretty blatant troll. I'll answer in the manner in which it
> was written, though it doesn't really reflect my true feelings: I
> wonder how Forth programmers write code that other programmers can
> read. When I look at Forth it makes no sense to me, particularly
> since it has no punctuation.
The point being, that "readability" of any language requires some
familiarity with that language.
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."
================================================
From: Bill Zimmerly
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <JGQj7.595$ck.27267@sjc-read.news.verio.net>
"Elizabeth D. Rather" <·······@forth.com> wrote in message
······················@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
From: Thomas F. Burdick
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <xcvsne854h2.fsf@apocalypse.OCF.Berkeley.EDU>
"Bill Zimmerly" <····@zimmerly.com> writes:
> It would be pretty silly for me to say that "Hebrew" is an unreadable
> language.....
>
> ....just because I personally can't read it!! :)
>
> Why do seemingly intelligent people say such idiotic things like "____ is an
> unreadable language"????
Why is a statement like "Perl is an unreadable language" idiotic?
Your comparison to a human language that one doesn't know, makes no
sense. Intelligent people who claim a language is unreadable will
presumably *know* the language (otherwise that "intelligent" bit would
be pretty suspect). Languages optimize for different things. Perl,
which seems to optimize for the output of a monkey given a typewriter
being a valid program, I find unreadable. Common Lisp, which
optimizes for expressiveness, I generally find to be readable. You
can certainly write unreadable code in Lisp, and it's sort-of possible
to write readable Perl, but I don't think that detracts from the
usefullness of the generalization.
From: Elizabeth D. Rather
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3B90016C.565BBEF9@forth.com>
"Thomas F. Burdick" wrote:
> "Bill Zimmerly" <····@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.
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."
================================================
From: Guido Draheim
Subject: unreadable? (Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes)))
Date:
Message-ID: <3B900FC5.428B5954@gmx.de>
"Elizabeth D. Rather" wrote:
>
> "Thomas F. Burdick" wrote:
>
> > "Bill Zimmerly" <····@zimmerly.com> writes:
> >
> > > It would be pretty silly for me to say that "Hebrew" is an unreadable
> > > language.....
> > >
> > > ....just because I personally can't read it!! :)
> > >
> > > Why do seemingly intelligent people say such idiotic things like "____ is an
> > > unreadable language"????
> >
> > Why is a statement like "Perl is an unreadable language" idiotic?
> > Your comparison to a human language that one doesn't know, makes no
> > sense. Intelligent people who claim a language is unreadable will
> > presumably *know* the language (otherwise that "intelligent" bit would
> > be pretty suspect).
>
> Bill is doubtless a little defensive because we Forth folks are all too
> accustomed to hearing people who know _nothing_ about Forth say,
> "Oh, Forth, I saw some Forth code once and it was totally unreadable."
> Insofar as Lisp is also a minority language, don't you sometimes get
> the same thing?
>
I don't hear that forth is "unreadable" but "unpredictable"[1] - in
most modern languages there is a generic block/scope system and quite
some calls/definitions/controlstructs require to use it - so even
that you do not know a certain control-expression (like try/catch)
you still get an idea about the flow of control and all the data items
that are involved. Now this is all different with forth - data items
on the stack might be textually-invisibly modified, the words can parse
ahead and just build label-branch defs in the background, possibly
using all kinds of table-lookups. So - if there are no indentations
or stack-comments then the casual reader will not know anything of
what is going on. In a way one could call it "basic syntax" that is
missing from forth - either know all the words in a sentence or be
left to read a series of forthglyphs that look nice but just that.
(btw, there are ways out of this but they are left to the discipline
of the developer being non-creative with the usual behaviour of names).
-- guido
[1] may be an exxageration of "known to constantly do unexpected things
behind my back (i.e. in contrast to what one can see written there)".
From: Michael L Gassanenko
Subject: Re: unreadable? (Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes)))
Date:
Message-ID: <b5ecdf44.0109011111.6515de9e@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)
From: Ken Peek
Subject: Re: unreadable? (Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes)))
Date:
Message-ID: <tp4fj1mt1f45cc@corp.supernews.com>
Yep! Macros should be used ONLY when it makes the code MORE readable. This is
a rare condition indeed. I have seen code with over use of macros, and wanted
to hunt down the originator of that code and slap them until they quit wiggling!
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" <······@yahoo.com> wrote in message
·································@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)
From: Kaz Kylheku
Subject: Re: unreadable? (Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes)))
Date:
Message-ID: <omsk7.130300$B37.2911678@news1.rdc1.bc.home.com>
In article <··············@corp.supernews.com>, Ken Peek wrote:
>Yep! Macros should be used ONLY when it makes the code MORE readable. This is
>a rare condition indeed. I have seen code with over use of macros, and wanted
>to hunt down the originator of that code and slap them until they quit wiggling!
>
>Use macros for non-portable things like I/O port reading and writing. This will
>allow for only one place in the code that needs to be changed to move an I/O
>address.
You must be writing from the comp.lang.forth camp. In Lisp, macros are used
to create new sublanguages.
Even if the macros are hard to read, if the language they create greatly
simplifies some programming tasks, those macros are justifiable.
You will often find that what a few thousand lines of ```cryptic''
macros accomplish would require hundreds of thousands of lines in some
other programming languages, if indeed it could be done at all.
>Otherwise, each programmer should be forced to write a 50000 word essay on WHY
>they NEED the macro before they are allowed to use it in their code!
When you create a new sublanguage, it is certainly useful to document
its syntax and semantics! And of course, not every programming problem
deserves its own sublanguage.
I don't think that mature programmers need to write long essays justifying
to morons what they do.
From: Kaz Kylheku
Subject: Re: unreadable? (Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes)))
Date:
Message-ID: <dssk7.130336$B37.2911954@news1.rdc1.bc.home.com>
In article <··············@corp.supernews.com>, Ken Peek wrote:
>Yep! Macros should be used ONLY when it makes the code MORE readable. This is
>a rare condition indeed. I have seen code with over use of macros, and wanted
>to hunt down the originator of that code and slap them until they quit wiggling!
>
>Use macros for non-portable things like I/O port reading and writing. This will
>allow for only one place in the code that needs to be changed to move an I/O
>address.
You must be writing from the comp.lang.forth camp. In Lisp, macros are used
to create new sublanguages.
Even if the macros are hard to read, if the language they create greatly
simplifies some programming tasks, those macros are justifiable.
You will often find that what a few thousand lines of ```cryptic''
macros accomplish would require hundreds of thousands of lines in some
other programming languages, if indeed it could be done at all.
>Otherwise, each programmer should be forced to write a 50000 word essay on WHY
>they NEED the macro before they are allowed to use it in their code!
When you create a new sublanguage, it is certainly useful to document
its syntax and semantics! And of course, not every programming problem
deserves its own sublanguage. Documentation will allow other people to
use the sublanguage without having to decipher it from the implementation.
I don't think that mature programmers can be forced to write unnecessarily
long essays justifying to morons what they do. If you make up such rules,
then you will simply lose good programmers, and be left with those who will
do anything they are told, no matter how unreasonable, to hang on to their job.
From: Ken Peek
Subject: Re: unreadable? (Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes)))
Date:
Message-ID: <tp55fbble8p768@corp.supernews.com>
Ahh--
I see! So you a a TROLL!!!
Don't you have anything better to do? News groups are for sharing ideas, and
getting help on things-- You are obviously an adolescent, at least mentally,
and have nothing better to do than post to news groups to see if you can stir up
trouble.
YOU sir, are not just a troll, but you are also an ASS...
My news reader has a nice filter built into it for chumps like you-- welcome to
my "Blocked Senders List"...
"Kaz Kylheku" <···@ashi.footprints.net> wrote in message
·····························@news1.rdc1.bc.home.com...
> In article <··············@corp.supernews.com>, Ken Peek wrote:
> >Yep! Macros should be used ONLY when it makes the code MORE readable. This
is
> >a rare condition indeed. I have seen code with over use of macros, and
wanted
> >to hunt down the originator of that code and slap them until they quit
wiggling!
> >
> >Use macros for non-portable things like I/O port reading and writing. This
will
> >allow for only one place in the code that needs to be changed to move an I/O
> >address.
>
> You must be writing from the comp.lang.forth camp. In Lisp, macros are used
> to create new sublanguages.
>
> Even if the macros are hard to read, if the language they create greatly
> simplifies some programming tasks, those macros are justifiable.
>
> You will often find that what a few thousand lines of ```cryptic''
> macros accomplish would require hundreds of thousands of lines in some
> other programming languages, if indeed it could be done at all.
>
> >Otherwise, each programmer should be forced to write a 50000 word essay on
WHY
> >they NEED the macro before they are allowed to use it in their code!
>
> When you create a new sublanguage, it is certainly useful to document
> its syntax and semantics! And of course, not every programming problem
> deserves its own sublanguage. Documentation will allow other people to
> use the sublanguage without having to decipher it from the implementation.
>
> I don't think that mature programmers can be forced to write unnecessarily
> long essays justifying to morons what they do. If you make up such rules,
> then you will simply lose good programmers, and be left with those who will
> do anything they are told, no matter how unreasonable, to hang on to their
job.
From: Kaz Kylheku
Subject: Re: unreadable? (Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes)))
Date:
Message-ID: <9axk7.130935$B37.2931639@news1.rdc1.bc.home.com>
In article <··············@corp.supernews.com>, Ken Peek wrote:
>Ahh--
>
>I see! So you a a TROLL!!!
>
>Don't you have anything better to do? News groups are for sharing ideas, and
>getting help on things-- You are obviously an adolescent, at least mentally,
>and have nothing better to do than post to news groups to see if you can stir up
>trouble.
You made the ridiculous assertion that a programmer be required to write
a 50,000 word essay to justify the use of a single macro. Criticizing
such a ridiculous assertion does not make me a troll. In fact, it is that
original assertion which is the true flamebait.
Please say something intelligent to remove my suspicion that you are
suffering from some irrational phobia of macros. Is there a *technical*
reason why a macro should be accompanied by 50,000 lines of explanation
and justification?
>YOU sir, are not just a troll, but you are also an ASS...
Note that the distinction usually goes to the first one to use the word.
From: William Tanksley
Subject: Re: unreadable? (Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes)))
Date:
Message-ID: <slrn9p5dm2.j55.wtanksle@dolphin.openprojects.net>
On Sun, 02 Sep 2001 15:43:05 GMT, Kaz Kylheku wrote:
>In article <··············@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
From: Coby Beck
Subject: Re: unreadable? (Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes)))
Date:
Message-ID: <A0zk7.32828$8c3.5749503@typhoon.tampabay.rr.com>
"Kaz Kylheku" <···@ashi.footprints.net> wrote in message
·····························@news1.rdc1.bc.home.com...
> In article <··············@corp.supernews.com>, Ken Peek wrote:
> >Yep! Macros should be used ONLY when it makes the code MORE readable.
This is
> >a rare condition indeed. I have seen code with over use of macros, and
wanted
> >to hunt down the originator of that code and slap them until they quit
wiggling!
> >
> >Use macros for non-portable things like I/O port reading and writing.
This will
> >allow for only one place in the code that needs to be changed to move an
I/O
> >address.
>
> You must be writing from the comp.lang.forth camp. In Lisp, macros are
used
> to create new sublanguages.
>
Sure they are, but Lisp macros are used for lots of things! This includes
things that bring the benefit of more readable code (such as creating
sub-languages : ). Things like with-open-file just hide the nuts and bolts
of opening and closing files so you can focus on the meaningful bits (as
coder and as reader!)
Coby
--
(remove #\space "coby . beck @ opentechgroup . com")
From: Bernd Paysan
Subject: Re: unreadable? (Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes)))
Date:
Message-ID: <3B92A84C.7D0A7B3@gmx.de>
Kaz Kylheku wrote:
> You must be writing from the comp.lang.forth camp. In Lisp, macros are used
> to create new sublanguages.
Can't be. In Forth, compiler extensions (immediate words, postpone, and
create-does>, parsing words) are used to create new sublanguages. We do
with some hundret lines what other people can only do by inventing a new
language, and writing a complete compiler (ok, except those who use Lisp
;-).
I think trolling like this comes from the traditional language camp,
where compiler extensions are not possible. Language extensions must be
documented with much more care than normal code, though.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
From: Elizabeth D. Rather
Subject: Re: unreadable? (Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes)))
Date:
Message-ID: <3B95182E.FE9990DF@forth.com>
Kaz Kylheku wrote:
> In article <··············@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.
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."
================================================
From: Michael L Gassanenko
Subject: Re: unreadable? (Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes)))
Date:
Message-ID: <b5ecdf44.0109021942.15cb69a@posting.google.com>
"Ken Peek" <········@SpiritSongDesigns.comNOSPAM> wrote in message news:<··············@corp.supernews.com>...
> Yep! Macros should be used ONLY when it makes the code MORE readable. This is
> a rare condition indeed. I have seen code with over use of macros, and wanted
> to hunt down the originator of that code and slap them until they quit wiggling!
>
Well, I believe you. But a statement like "I hate/love macros"
is nothing more than a flame bait.
What charged you with negative emotions could not be just macros;
what property the code written with macros had?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I repeat:
Can you please explain, what was so bad in the code written
with macros? It cannot be just macros themselves.
> Use macros for non-portable things like I/O port reading and writing. This will
> allow for only one place in the code that needs to be changed to move an I/O
> address.
Constants are often used in such circumstances (at least, in Forth and C):
(define iobase 12345)
(define port0 (+ iobase 0))
(define port1 (+ iobase 1))
One of possible uses of macros in C++ is:
#define SUPER TheNameOfSomeClass
OTOH, some people use to declare "super" in class's namespace...
As to new languages, I used Forth and C macro-tools to have
both compilers load some .h file. (That file contained some
declaration needed by both C code and Forth code; such approach
allowed to avoid the problem of synchronization of C and Forth
declarations. Yes, spaces (Forth words are usually delimited by spaces)
were required in some places where they
would not be needed in just C++.)
You see, I have just named two more possible uses of macros:
1) compensation of language weaknesses
2) interaction between two languages, that is, sharing code
by two compilers (e.g. Forth and C++).
>
> Otherwise, each programmer should be forced to write a 50000 word essay on WHY
> they NEED the macro before they are allowed to use it in their code!
>
> "Michael L Gassanenko" <······@yahoo.com> wrote in message
> ·································@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).
From: Anton Ertl
Subject: Re: unreadable? (Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes)))
Date:
Message-ID: <9n7mnb$m4h$1@news.tuwien.ac.at>
In article <·················@gmx.de>,
Guido Draheim <·············@gmx.de> writes:
>I don't hear that forth is "unreadable" but "unpredictable"[1] - in
>most modern languages there is a generic block/scope system and quite
>some calls/definitions/controlstructs require to use it - so even
>that you do not know a certain control-expression (like try/catch)
>you still get an idea about the flow of control and all the data items
>that are involved. Now this is all different with forth - data items
>on the stack might be textually-invisibly modified, the words can parse
>ahead and just build label-branch defs in the background, possibly
>using all kinds of table-lookups. So - if there are no indentations
>or stack-comments then the casual reader will not know anything of
>what is going on.
Yes, Forth does not make it impossible to write unreadable or
unpredictable programs, but then, which language does? Do any of the
languages you call "modern" force people to use indentation, or are
they readable without indentation? In my experience, no programming
language is readable without indentation (just try "M-x
fundamental-mode RET M-x M-< M-> M-x fill-region-as-paragraph RET" in
Emacs on any program in a "modern" language).
As for the dangerous practices you mention, they are rarely used, and
for a reason. However, there are practices that are moderately common
that are dangerous, too, e.g., the STATE-smartness you have no
scruples to use, or the use of EVALUATE-based macros propagated by Wil
Baden. Actually, the only one I know of who parses ahead and uses
table lookups to build label branches is also Wil Baden/Neil Bawd.
Maybe you should just stay away from his stuff.
It is actually pretty easy to use Forth in a predictable way, which is
something I cannot say about Perl, because there the problems are
built into the commonly-used primitives, which is not the case in
Forth.
Followups to comp.lang.forth.
- 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
From: Bill Zimmerly
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <Ymql7.731$ck.33438@sjc-read.news.verio.net>
"Elizabeth D. Rather" <·······@forth.com> wrote in message
······················@forth.com...
> "Thomas F. Burdick" wrote:
>
> > "Bill Zimmerly" <····@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?
Bingo. :) You're clarification is correct. Thank you, Elizabeth.
--
- 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
From: Bill Zimmerly
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <Yuql7.732$ck.33417@sjc-read.news.verio.net>
"Bill Zimmerly" <····@zimmerly.com> wrote in message
·······················@sjc-read.news.verio.net...
> [Snip]
> Bingo. :) You're clarification is correct. Thank you, Elizabeth.
Ooops, "You're" should have been "Your". Shame on me ... Forth programmers
should be good at word-weaving! :)
--
- 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
From: Bart Lateur
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <k014ptsv0qbkoh13k21n7ljnprg2dqdt94@4ax.com>
Thomas F. Burdick wrote:
>> Why do seemingly intelligent people say such idiotic things like "____ is an
>> unreadable language"????
>
>Why is a statement like "Perl is an unreadable language" idiotic?
>Languages optimize for different things. Perl,
>which seems to optimize for the output of a monkey given a typewriter
>being a valid program, I find unreadable.
Your statement is exactly the kind of idiotic statement that the whole
thread is about.
Perl is by design no more unreadable than Lisp, which seems to be your
pet language.
--
Bart.
From: Thomas F. Burdick
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <xcvr8tpdol6.fsf@conquest.OCF.Berkeley.EDU>
Bart Lateur <···········@skynet.be> writes:
> Thomas F. Burdick wrote:
>
> >> Why do seemingly intelligent people say such idiotic things like "____ is an
> >> unreadable language"????
> >
> >Why is a statement like "Perl is an unreadable language" idiotic?
> >Languages optimize for different things. Perl,
> >which seems to optimize for the output of a monkey given a typewriter
> >being a valid program, I find unreadable.
>
> Your statement is exactly the kind of idiotic statement that the whole
> thread is about.
>
> Perl is by design no more unreadable than Lisp, which seems to be your
> pet language.
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.
From: cLIeNUX user
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <tovqtmm8ap8qa6@corp.supernews.com>
········@smart.net
>"Elizabeth D. Rather" <·······@forth.com> wrote in message
>······················@forth.com...
>>
>
>Why do seemingly intelligent people say such idiotic things like "____ is an
>unreadable language"????
>
The other one that just kills me is the incessant noise you hear that
small superb designs don't scale. Not when handed to idiots they don't.
Rick Hohensee
www.
cLIeNUX
.com
········@smart.net
>--
>- 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
>
>
>
"Elizabeth D. Rather" <·······@forth.com> wrote in message news:<·················@forth.com>...
> Erann Gat wrote:
>
> > > I've cross posted this to comp.lang.forth since Forth
> > > programmers will want to read and comment on it. You are right.
> > > Forth programs are "pretty notorious for being hard to
> > > maintain". This is not the fault of the Forth language. It is
> > > the fault of Forth programmers and the people who hire them. You
> > > indicate the reason very clearly when you state "Forth
> > > programmers are almost as hard to find as Lisp programmers", so
> > > when an old Forth program needs to be updated, all heck breaks
> > > loose, since there is usually nobody around who knows how to
> > > program in Forth.
> >
> > I think there's more to it than that. Forth functions don't have
> > named argument lists, and no clear delineation of block structure.
> > (At least this was the case at the time. I haven't used Forth in many
> > years; maybe things are different now.) In other languages you can at
> > least tell how many arguments you're supposed to pass to a function
> > just by looking at the code. While I acknowledge that it is possible
> > to write maintainable Forth I believe it requires more conscious
> > effort on the part of the programmer than in other languages.
>
> It is customary in Forth to follow the name of each new definition
> by a "stack comment" showing the number, order, and types of
> stack arguments into and out of that defintion. ANS Forth (1994)
> gave models for this (and recommended notation) which is widely
> followed. Responsible Forth programmers (and in my experience
> most are) regard these comments as just as mandatory as argument
> lists in other languages, even though most compilers don't enforce
> the requirement. It is also recommended (and common) practice
> to add a comment as to intended usage.
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.
In article <····························@posting.google.com>,
···@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
On Sat, 01 Sep 2001 05:35:41 +1200, Bruce Hoult wrote:
>···@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
In article <·······················@dolphin.openprojects.net>,
·········@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
In article <···························@news.akl.ihug.co.nz>, Bruce Hoult wrote:
>Python has a serious dangling else problem with no redundancy that I can
>see. If Python used, for example, some sort of "endif" then the
>indentation would be redundant (as in other languages), but without it
>it's not.
How can Python have a dangling else problem, when the nesting level of
every statement is deducible from its indentation?
if foo
if bar
this
else
that
The indendation clearly indicates that the else goes with the innermost
if. If you change the indentation like this, it will go with
the outer if:
if foo
if bar
this
else
that
Or not? What facts am I missing?
>> >Editing accidents that leave indentation mangled are far more likely to
>> >happen, and thee is no redundancy so nothing can warn you about it.
>>
>> Absolutely false. Mangling indentation is possible, although I've never
>> done it nor talked to any Python programmer who has
>
>Well no one is going to admit it, are they? They'll make the mistake,
>and then track down the bug and go "Geez I'm bone-headed, what a
Careless editing mistakes can cause damage to a program in any language.
The risk of a careless edit is minimized by using a version control
system. Or at least maintaining backups of your working sources.
In article <························@news1.rdc1.bc.home.com>,
···@ashi.footprints.net wrote:
> In article <···························@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
In article <···························@news.akl.ihug.co.nz>, Bruce Hoult wrote:
>In article <························@news1.rdc1.bc.home.com>,
>···@ashi.footprints.net wrote:
>
>> In article <···························@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.
From: Bob Bane
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3B94FF12.27B2BDEA@removeme.gst.com>
Kaz Kylheku wrote:
>
> In article <···························@news.akl.ihug.co.nz>, Bruce Hoult wrote:
> >In article <························@news1.rdc1.bc.home.com>,
> >···@ashi.footprints.net wrote:
> >
> > [snip]
> >
> >> 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?
>
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.
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
On Tue, 04 Sep 2001 12:19:30 -0400, Bob Bane wrote:
>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
From: Greg Menke
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <m3k7ze4uld.fsf@europa.pienet>
> >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
On 4 Sep 2001, Greg Menke wrote:
[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.
From: Greg Menke
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <m3sne14zdi.fsf@europa.pienet>
> > 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
On 05 Sep 2001 08:04:57 -0400, Greg Menke wrote:
>> > 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.
By your theories, it appears that the entire Python community has simply
been lucky. But luck on that scale is more than coincidence.
>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.
May I assume that among the "customer's needs" for which this code is
being tweaked to fit sits the need for the code to /compile/? If that's
true, then even the most unwilling modifier will IMMEDIATELY see the
result of a bad whitespace change -- it will either result in a
compilation error, or a HUGE, obvious text change.
>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.
When the compiler checks for whitespace -- very well. When it doesn't,
VERY poorly. Look at all the C and Perl code my company's hardware dept
maintains; it's beyond horrible. Compare the Python code; it looks better
than some of our SW engineers' C code. Why? Because indentation is more
than cosmetic, it's functional.
>Gregm
--
-William "Billy" Tanksley
From: Samuel A. Falvo II
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <slrn9pth9s.je6.kc5tja@dolphin.openprojects.net>
On Tue, 11 Sep 2001 20:21:34 GMT, William Tanksley wrote:
>>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.
>
>When the compiler checks for whitespace -- very well. When it doesn't,
>VERY poorly. Look at all the C and Perl code my company's hardware dept
>maintains; it's beyond horrible. Compare the Python code; it looks better
>than some of our SW engineers' C code. Why? Because indentation is more
>than cosmetic, it's functional.
Moreover, as far as how well code can last in that sort of environment,
let's not forget major software implementations that are designed around
Python. Infoseek anyone? How about Zope, which is easily going on five
years old. Fnorb, one of the first CORBA ORBs for Python, is written almost
exclusively in Python itself, even to this day. And of course, the standard
Python modules that ship with the language itself. Providing such services
as high-level network services (FTP, SMTP, web serving, etc), many are
written and maintained in Python itself. No problems to date.
Python code is absolutely, positively no harder to maintain or to write or
to debug than any other programming language. If (editorial) YOU have
problems with maintaining or understanding a Python program, then I'm sorry,
you just plain don't know the language, no matter how much so-called
'experience' you have with it.
--
KC5TJA/6, DM13, QRP-L #1447
Samuel A. Falvo II
Oceanside, CA
From: Janis Dzerins
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <87r8tcc1n3.fsf@asaka.latnet.lv>
······@dolphin.openprojects.net (Samuel A. Falvo II) writes:
> Python code is absolutely, positively no harder to maintain or to
> write or to debug than any other programming language.
This I don't agree with. In all other languages I program I let my
editor do the indenting. Now in Python -- I must do it myself! So it
*is* harder to write, and therefore might even be harder to maintain.
--
Janis Dzerins
If million people say a stupid thing it's still a stupid thing.
From: Steinar Knutsen
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <9nngfq$9lp$1@snipp.uninett.no>
In article <··············@asaka.latnet.lv>,
Janis Dzerins <·····@latnet.lv> wrote:
>······@dolphin.openprojects.net (Samuel A. Falvo II) writes:
>
>> Python code is absolutely, positively no harder to maintain or to
>> write or to debug than any other programming language.
>
>This I don't agree with. In all other languages I program I let my
>editor do the indenting. Now in Python -- I must do it myself! So it
>*is* harder to write, and therefore might even be harder to maintain.
I promised to myself to don't get involved here, but here goes: Any decent
language sensitive editor for programming Python only requires you to close
blocks with a quick tap at the backspace key (or similar), indenting when
opening blocks is automatic. When editing old code, the editor figures out the
correct indenting from the surrounding code. How is this more effort than
programming other languages?
As for maintainability and white space: I write C++ for a living. I have seen
bugs from missing curly brackets, sometimes in my own source, sometimes in
other people's source, pass silently though the compiler or generate highly
misleading error messages. I have used Python since the 1.3-days, but never
ever seen errors from faulty indentation not being caught by Python and being
easily fixed at once. This is of course, only experience, not formal proof.
YMMV, obviously.
--
Steinar
From: Samuel A. Falvo II
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <slrn9pvt5n.lsf.kc5tja@dolphin.openprojects.net>
On 12 Sep 2001 11:21:30 GMT, Steinar Knutsen wrote:
>misleading error messages. I have used Python since the 1.3-days, but never
>ever seen errors from faulty indentation not being caught by Python and being
>easily fixed at once. This is of course, only experience, not formal proof.
>YMMV, obviously.
Check out the following URL:
http://wwwipd.ira.uka.de/~prechelt/Biblio/jccpprt_computer2000.pdf
for a paper which compares a number of popular programming languages with
respect to programming an application. You'll find that Python not only
competes with, but actually exceeds, the maintainability and productivity of
other programming languages, with a time to completion and program size
easily one half that of C or C++ (and presumably, Forth for reasons of not
having an extensive string and collections management library/vocabulary).
It's even performance competitive to boot.
I've written a C unit testing program in Python that took me nearly 20
minutes to write. The equivalent program in Forth would have taken me an
estimated 1.5 hours to 2 hours (30 minutes to write the core of the program,
and the remainder to make up for Forth's lack of list processing and string
manipulation features).
--
KC5TJA/6, DM13, QRP-L #1447
Samuel A. Falvo II
Oceanside, CA
From: Elizabeth D. Rather
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3BA00092.EA7C9A66@forth.com>
"Samuel A. Falvo II" wrote:
> Check out the following URL:
>
> http://wwwipd.ira.uka.de/~prechelt/Biblio/jccpprt_computer2000.pdf
>
> for a paper which compares a number of popular programming languages with
> respect to programming an application. You'll find that Python not only
> competes with, but actually exceeds, the maintainability and productivity of
> other programming languages, with a time to completion and program size
> easily one half that of C or C++ (and presumably, Forth for reasons of not
> having an extensive string and collections management library/vocabulary).
> It's even performance competitive to boot.
>
> I've written a C unit testing program in Python that took me nearly 20
> minutes to write. The equivalent program in Forth would have taken me an
> estimated 1.5 hours to 2 hours (30 minutes to write the core of the program,
> and the remainder to make up for Forth's lack of list processing and string
> manipulation features).
Surely it depends on what kind of applications you write? As has been
noted elsewhere, by me and others (most recently, Bill Zimmerly, I think
in this mammoth thread) those of us who use Forth regularly have our
"back pockets" full of extra tools that we use regularly. If we did a lot
of string & list processing, we'd have lots of useful words for that. As
it happens, SwiftForth has a lot more string-oriented extras than SwiftX,
because Windows programming needs a lot more than embedded systems,
which only rarely deal with strings and lists.
When we worked on ANS Forth, a lot of the new material (e.g. FILES,
EXCEPTIONS) came out of the "back pockets" of the people in the group,
as well as the many folks who wrote in with suggestions. We included
only a small fraction of the suggested additions, because there was also
pressure to keep the language "lean" (and some folks were upset with the size
of the total wordset already).
Comparing the wordsets of standard Forth with standard anything-else
can be informative, but doesn't capture the real-world experience of
experienced Forth programmers, or even programmers who start with
a full-featured commercial product as opposed to a bare ANS Forth.
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."
================================================
From: Samuel A. Falvo II
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <slrn9q28d0.mpn.kc5tja@dolphin.openprojects.net>
On Thu, 13 Sep 2001 00:40:49 GMT, Elizabeth D. Rather wrote:
>> minutes to write. The equivalent program in Forth would have taken me an
>> estimated 1.5 hours to 2 hours (30 minutes to write the core of the program,
>> and the remainder to make up for Forth's lack of list processing and string
>> manipulation features).
>
>Surely it depends on what kind of applications you write? As has been
>noted elsewhere, by me and others (most recently, Bill Zimmerly, I think
>in this mammoth thread) those of us who use Forth regularly have our
>"back pockets" full of extra tools that we use regularly. If we did a lot
Which I do not, hence my giving a realistic estimate of how long it'd take
me to develop the code in Forth. My time estimation is not a negative
directed towards Forth in any way; it's a realistic estimate of my abilities.
However, given a choice of having to write all those primitives myself
versus using a language that I'm equally familiar with AND already has a
rich collection of string and list manipulation functionality, which do you
think I'm going to go for?
>of string & list processing, we'd have lots of useful words for that. As
>it happens, SwiftForth has a lot more string-oriented extras than SwiftX,
>because Windows programming needs a lot more than embedded systems,
>which only rarely deal with strings and lists.
Well, I don't use Windows; I use Linux. And even so, each Forth is
different in this respect, and you may as well use your own string package,
as that's really the only way to ensure portability across platforms.
>Comparing the wordsets of standard Forth with standard anything-else
>can be informative, but doesn't capture the real-world experience of
>experienced Forth programmers, or even programmers who start with
>a full-featured commercial product as opposed to a bare ANS Forth.
I thought it was apparent from the context of the discussion that it would
have taken *me* up to two hours to write the application (still darn good
turn-around time if you ask me, all things considered!). My experiences
with Forth are hardly a reflection of the general Forth programming
community's experiences.
--
KC5TJA/6, DM13, QRP-L #1447
Samuel A. Falvo II
Oceanside, CA
From: Samuel A. Falvo II
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <slrn9pvsm0.lsf.kc5tja@dolphin.openprojects.net>
On 12 Sep 2001 10:24:32 +0300, Janis Dzerins wrote:
>This I don't agree with. In all other languages I program I let my
>editor do the indenting. Now in Python -- I must do it myself! So it
This only proves to me that you've never worked with Python in any serious
capacity. Every single editor I know of, save WordPad and Notepad, has the
ability to maintain automatic indentation. I have used a number of editors,
from VI to Emacs/Jed and everything in between, and have =never= had a
problem reading or maintaining a Python program.
Never.
--
KC5TJA/6, DM13, QRP-L #1447
Samuel A. Falvo II
Oceanside, CA
From: Kaz Kylheku
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <abUn7.5535$jY.88557@news1.rdc1.bc.home.com>
In article <·····················@dolphin.openprojects.net>, Samuel
A. Falvo II wrote:
>On 12 Sep 2001 10:24:32 +0300, Janis Dzerins wrote:
>>This I don't agree with. In all other languages I program I let my
>>editor do the indenting. Now in Python -- I must do it myself! So it
>
>This only proves to me that you've never worked with Python in any serious
>capacity.
You don't need to work with Python to realize that a text editor could
easily be programmed to recognize a Python selection or iteration
construct, and kick off a new indentation level in preparation
of the entry of subordinate statements.
Comments like that prove only a basic lack of thought.
From: Samuel A. Falvo II
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <slrn9q28h0.mpn.kc5tja@dolphin.openprojects.net>
On Thu, 13 Sep 2001 01:43:34 GMT, Kaz Kylheku wrote:
>You don't need to work with Python to realize that a text editor could
>easily be programmed to recognize a Python selection or iteration
>construct, and kick off a new indentation level in preparation
>of the entry of subordinate statements.
>
>Comments like that prove only a basic lack of thought.
Umm...huh? I think your response is sorely misdirected. It is not I who is
not in favor of Python's block handling; I, for one, prefer it over
explicitly delimited languages like C. I think you need to re-read not only
the message which I was replying, but also my response, a little more
carefully.
--
KC5TJA/6, DM13, QRP-L #1447
Samuel A. Falvo II
Oceanside, CA
From: Kaz Kylheku
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <5D9o7.7820$jY.150680@news1.rdc1.bc.home.com>
In article <·····················@dolphin.openprojects.net>, Samuel
A. Falvo II wrote:
>On Thu, 13 Sep 2001 01:43:34 GMT, Kaz Kylheku wrote:
>>You don't need to work with Python to realize that a text editor could
>>easily be programmed to recognize a Python selection or iteration
>>construct, and kick off a new indentation level in preparation
>>of the entry of subordinate statements.
>>
>>Comments like that prove only a basic lack of thought.
>
>Umm...huh? I think your response is sorely misdirected. It is not I who is
Nope; I'm talking about the same comment that you are, made by one Janis
Dzerins <·····@latnet.lv>. I simply don't agree with your analysis that
his comment arises from lack of experience with Python, because no such
experience is required to realize how an editor could automatically
indent it.
From: Samuel A. Falvo II
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <slrn9q2jlr.n26.kc5tja@dolphin.openprojects.net>
On Thu, 13 Sep 2001 21:33:53 GMT, Kaz Kylheku wrote:
>Nope; I'm talking about the same comment that you are, made by one Janis
Ahh...*whew!*
--
KC5TJA/6, DM13, QRP-L #1447
Samuel A. Falvo II
Oceanside, CA
From: Dorai Sitaram
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <9n2sjh$6pf$1@news.gte.com>
In article <························@news1.rdc1.bc.home.com>,
Kaz Kylheku <···@ashi.footprints.net> wrote:
>In article <···························@news.akl.ihug.co.nz>, Bruce Hoult wrote:
>>In article <························@news1.rdc1.bc.home.com>,
>>···@ashi.footprints.net wrote:
>>
>>> In article <···························@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
On Mon, 03 Sep 2001 21:54:16 +1200, Bruce Hoult wrote:
>···@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
--
-William "Billy" Tanksley
In article <·······················@dolphin.openprojects.net>,
·········@bigfoot.com wrote:
> On Mon, 03 Sep 2001 21:54:16 +1200, Bruce Hoult wrote:
> >···@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
From: Wade Humeniuk
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <9n3k0d$5dm$1@news3.cadvision.com>
> 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?
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
"Wade Humeniuk" <········@cadvision.com> wrote in message news:<············@news3.cadvision.com>...
>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
From: Marco Antoniotti
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <y6cvgixvkqy.fsf@octagon.mrl.nyu.edu>
"Wade Humeniuk" <········@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'.
Marco Antoniotti <·······@cs.nyu.edu> wrote in message news:<···············@octagon.mrl.nyu.edu>...
> 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
Well, to me it looks pretty good compared to, say, the ACM contests
which consist of "solve as many of these ten problems as possible in
four hours" (or something like that...).
How much time would you prefer? A week? Two? While that might be
interesting, it would be a sure recipe for getting virtually no
entries (or at least none from employable people).
72 hours seems pretty good to me. If that time includes a weekend
then it requires only one day off work (or less).
> 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.
I don't think this attribute varies with choice of language. Even
Perl programmers lay claim to laziness.
-- Bruce
From: Nils Goesche
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <lksne27vn7.fsf@pc022.bln.elmeg.de>
Bruce Hoult <·····@hoult.org> writes:
> 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?
You don't know the people who submitted those entries. They were
competing with people from INRIA and similar organizations. I was one
of those people who submitted a Common Lisp entry (Team ``Watt'',
#193). I did that just for fun, and now it is a little annoying that,
for the second time now, people use the fact that it is not a good
entry to put down Common Lisp.
I am an embedded systems programmer; most of the time I write C and
even Assembler. I use high level languages like OCaml or Lisp
occasionally for writing development or testing tools that don't run
on the embedded system itself (and for everything else I write for
fun). I had used OCaml and not Common Lisp for over a year. But
about two weeks before the contest I changed my mind and decided to
return to Common Lisp. This contest was a nice opportunity to fresh
up my rusty Lisp. Almost every function/macro I used I had to look up
in the Lisp spec before I could use it. Sometimes I couldn't for the
life of me remember the name of some builtin function and read Common
Lisp The Language until I found it.
Moreover, I had never in my life written anything like an optimizer.
I was put off by the strange time restriction and spent most of the
time thinking of strange data structures that would be valid all the
time so I could dump them in the signal handler for SIGALRM (of course
I first had to read all the parts of the CMUCL manual for how to
establish UNIX signal handlers and protecting my data structures
against those signals without losing a signal -- again because I had
very little experience with CMUCL).
Afterwards I realized that this was only to avoid entries like the
Python entry from last year that needed over three days for only one
picture. In the first round, the time limits given were so high that
I apparently could have ignored them completely. But all the time, I
thought I was supposed to parse in a 20 MB file and optimize and dump
it in three seconds.
I didn't spend more than about six hours on the problem during the
first two days because: 1) This was supposed to be fun and not work 2)
I thought implementing those optimizations was totally trivial, so I
would start writing them Sunday morning. I was wrong about 2) :-),
and so I only finished some pretty trivial optimizations, mostly
whitespace and some redundancy elimination.
Nevertheless, without much work, I made it and submitted a working
(though not very good) program. It even survived the first
elimination round, and one fancy macrolet was great fun to write.
This is all I wanted; of course I didn't expect to _win_ anything,
using a language I had forgotten so much about, and working all alone
on a kind of problem I had never encountered before, competing with, I
didn't check this year, but last year there were teams of several
people from INRIA who write great compilers and optimizers in their
very own language ALL THE TIME, and even them only made SECOND PRICE
last year!
So, I hope it is clear that, at least in my case, it was _not_ Common
Lisp's fault that I scored badly, but only mine. Next year I'll do
better :-)
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
From: Wade Humeniuk
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <9n82l9$k2a$1@news3.cadvision.com>
> > Why is that, for a language that is so good at rapid development of
> > complex algorithms?
>
> You don't know the people who submitted those entries. They were
> competing with people from INRIA and similar organizations. I was one
> of those people who submitted a Common Lisp entry (Team ``Watt'',
> #193). I did that just for fun, and now it is a little annoying that,
> for the second time now, people use the fact that it is not a good
> entry to put down Common Lisp.
...
> This is all I wanted; of course I didn't expect to _win_ anything,
> using a language I had forgotten so much about, and working all alone
> on a kind of problem I had never encountered before, competing with, I
> didn't check this year, but last year there were teams of several
> people from INRIA who write great compilers and optimizers in their
> very own language ALL THE TIME, and even them only made SECOND PRICE
> last year!
>
> So, I hope it is clear that, at least in my case, it was _not_ Common
> Lisp's fault that I scored badly, but only mine. Next year I'll do
> better :-)
Yes, the most important part of being able to write a competitive optimizer
in that competition is knowing how to solve the problem not the
effectiveness of the programming language. Its a little sad that so much
empahsis is put on what language the competitors used to solve the problem.
However with that aside it would be great to see an entry in CL win it.
It sounds like you were quite bold putting out your entry with so many
hurdles in front of you. Congratulations.
Wade
From: Nils Goesche
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <lku1ygb6x8.fsf@pc022.bln.elmeg.de>
"Wade Humeniuk" <········@cadvision.com> writes:
> "Nils Goesche" <······@cartan.de> writes:
> > So, I hope it is clear that, at least in my case, it was _not_ Common
> > Lisp's fault that I scored badly, but only mine. Next year I'll do
> > better :-)
>
> Yes, the most important part of being able to write a competitive optimizer
> in that competition is knowing how to solve the problem not the
> effectiveness of the programming language. Its a little sad that so much
> empahsis is put on what language the competitors used to solve the problem.
> However with that aside it would be great to see an entry in CL win it.
>
> It sounds like you were quite bold putting out your entry with so many
> hurdles in front of you. Congratulations.
Thanks very much :-) To everyone: Taking part in the contest was
great fun, and if more Common Lisp entries were there, one of them
might score better than mine. The fact that OCaml entries did so well
during past years ICFP's did quite a lot for OCaml's good reputation
and I don't doubt that if some of the CL Guru's here took part it
would do good for Lisp's reputation, too. BTW: They didn't have CMUCL
installed but installed it when I asked them to. You might as well
deliver a statically linked binary if you prefer working with a
commercial Lisp.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
"Wade Humeniuk" <········@cadvision.com> wrote in message news:<············@news3.cadvision.com>...
> > So, I hope it is clear that, at least in my case, it was _not_ Common
> > Lisp's fault that I scored badly, but only mine. Next year I'll do
> > better :-)
>
> Yes, the most important part of being able to write a competitive optimizer
> in that competition is knowing how to solve the problem not the
> effectiveness of the programming language. Its a little sad that so much
> empahsis is put on what language the competitors used to solve the problem.
Well actually I think that half the fun is the anticipation when you
download that task specification and you wonder exactly what field
you've never previously looked at you're going to have to learn about
in the next three days.
The winning Haskell Carrots certainly appear to have known some
applicable theory -- their write-up reads like an academic paper --
but we came pretty close to pipping them with simple brute force in a
fast Lisp dialect, using only whatever theory we were able to invent
for ourselves in 72 hours.
> However with that aside it would be great to see an entry in CL win it.
I would love to see CL win it. Well, come 2nd to Dylan preferably :-)
-- Bruce
From: Wade Humeniuk
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <9n833a$k9e$1@news3.cadvision.com>
Would you mind posting your code? I would interested in seeing it.
Wade
Nils Goesche <······@cartan.de> wrote in message news:<··············@pc022.bln.elmeg.de>...
> Bruce Hoult <·····@hoult.org> writes:
>
> > 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?
>
> You don't know the people who submitted those entries. They were
> competing with people from INRIA and similar organizations.
And so was I, a dairy farmer's son living in a small island nation in
the South Pacific. I program CGIs and accounting programs for a
living in C++ and Java. I haven't studied in a University in the last
17 years and have never published an academic paper in my life.
My friends and I managed to put together three different entries using
three different strategies that managed 13th, 8th and 2nd places. In
that inferior language, Dylan, too.
The people at INRIA or wherever (since Camls R Us were running it this
year, not competing) are pretty good, but they're not Gods.
> I was one
> of those people who submitted a Common Lisp entry (Team ``Watt'',
> #193). I did that just for fun, and now it is a little annoying that,
> for the second time now, people use the fact that it is not a good
> entry to put down Common Lisp.
Hey, nothing personal intended! Half the OCaml entries weren't very
good either. And most of the C ones :-)
The question is why has there *never* been a good Lisp entry?
> Moreover, I had never in my life written anything like an optimizer.
Ditto. And last year was the first time I've ever done 3D graphics
programming. That's half the fun of it!
> I was put off by the strange time restriction and spent most of the
> time thinking of strange data structures that would be valid all the
> time so I could dump them in the signal handler for SIGALRM (of course
> I first had to read all the parts of the CMUCL manual for how to
> establish UNIX signal handlers and protecting my data structures
> against those signals without losing a signal -- again because I had
> very little experience with CMUCL).
Waaay overkill. We just threw calls to a "check-timeout()" function
in a few places. It called the system time function, compared it to
the limit, and threw an exception if necessary.
> But all the time, I
> thought I was supposed to parse in a 20 MB file and optimize and dump
> it in three seconds.
Strange, because they *specified* that input files would never be
bigger than 5 MB and you'd never have less time than 3 minutes. But
our speed-demon (Dylan Lightning) entry never spent more than 2.4
seconds on even the biggest files and *still* managed 13th place.
> So, I hope it is clear that, at least in my case, it was _not_ Common
> Lisp's fault that I scored badly, but only mine.
Of course. But I still ask "Where are the good Common Lisp entries?"
I'm really pleased to get Dylan into the top placings, but honestly I
wouldn't mind one bit if there were a few CL entries up there as well,
since they''re so similar. Just to keep those Hindley-Milner types
from thinking they've got a birthright to win the ICFP contest.
> Next year I'll do better :-)
Yep. Us too, I hope. We did better this year than last year.
-- Bruce
From: Jochen Schmidt
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <9neg1u$ssp$1@rznews2.rrze.uni-erlangen.de>
1) This year was the first time Common Lisp teams participated
at all. I and a few others had a CL team too but we decided
on the end not to publish our entry because we thought a bad
CL entry would be even worse than no CL entry.
2) Don't underestimate the benefit you got by already participating
on the contest - as you realized by yourself you have done
better _this_ year than last year - can you give this right,
the right to learn from mistakes, to others too?
3) Most problems we faced was of communication nature - I was unable
to access our Yahoo account for hours!!! (We used yahoo for file
sharing).
4) I don't know what monkey has bitten you, but why the f%&$k do you sound
so insulted? (see your statement on "a inferior language like Dylan")
5) Is it some childish kind of revenge to point with the finger
on CL and whine "Hey look you've done worse than we haaa ha!"
Am _I_ pointing at _you_ yelling "Hey where are the _applications_
written in Dylan!" ?
ciao,
Jochen
--
http://www.dataheaven.de
From: Wade Humeniuk
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <9nenp0$toc$1@news3.cadvision.com>
> 4) I don't know what monkey has bitten you, but why the f%&$k do you sound
> so insulted? (see your statement on "a inferior language like Dylan")
> 5) Is it some childish kind of revenge to point with the finger
> on CL and whine "Hey look you've done worse than we haaa ha!"
> Am _I_ pointing at _you_ yelling "Hey where are the _applications_
> written in Dylan!" ?
I am sure Bruce is not doing that. He has already said as much.
Wade
Jochen Schmidt <···@dataheaven.de> wrote in message news:<············@rznews2.rrze.uni-erlangen.de>...
> 1) This year was the first time Common Lisp teams participated
> at all. I and a few others had a CL team too but we decided
> on the end not to publish our entry because we thought a bad
> CL entry would be even worse than no CL entry.
I guess opinions differ :-) I'd rather see CL teams showing their
face than deciding a priori they weren't good enough. You *never*
know in advance how good the opposition is going to be, or what the
ultimate limits on performance are going to be or how close you are to
them.
That's half the fun of it.
> 2) Don't underestimate the benefit you got by already participating
> on the contest - as you realized by yourself you have done
> better _this_ year than last year - can you give this right,
> the right to learn from mistakes, to others too?
Certainly
Here, totally gratis, are some of the lessons we learned last year:
- make sure you have some sort of lexer/parser generator available,
otherwise you may spend half the contest doing something that the
other teams spent five minutes on.
- make sure you know how to do *fast* slurping in/out of data files.
Our Ray Tracer submission turned out to take longer to write out the
bitmap image to a file than the 1st or 2nd place programs took in
total. *After* the contest I spent 5 minutes and got it 1000 times
faster. That's not the only reason we didn't do well last year -- we
simply didn't get CSG done -- but it would have been enough to knock
us out of the top placings *anyway*.
- implement your own automated test tools *early*. Last year a little
utility that could compare two image files and output either a
numerical measure of the difference or an image showing them was
useful. This year you really needed your own utility to check if two
files were semantically the same -- using the judge's web page all the
time simple didn't cut it. Even if you automated its use via the web.
This year I didn't write our own validator until the 2nd day with the
result that we submitted a "lightning" entry with a stupid bug because
we didn't try all the test cases after a last-minute change. If it
wasn't for that we might have gotten the "Judges' Prize" as well,
since our bugfixed "Dylan Lightning" finished 13th vs Erlightning's
16th place.
I believe that teams and programming languages don't *win* this
contest, they *lose* it. Winning doesn't show that you have the best
language. It shows that you don't have any weak points (or, at least,
none that showed up this year...) OCaml doesn't suddenly suck because
they didn't win this year. Several OCaml teams did well (including
3rd place) and it's still a good language with a great implementation.
So, when you enter ICFP, what really happens is that you get your nose
rubbed in the parts of your language an/or implementation that aren't
up to scratch compared to others. You don't get that effect if
*everyone* is using the same language.
> 3) Most problems we faced was of communication nature - I was unable
> to access our Yahoo account for hours!!! (We used yahoo for file
> sharing).
Strategic mistake :-)
We were a distributed team and used IRC for chatting and a cvs server
for code sharing. Worked great, but it certainly would be possible
for a network meltdown to screw us up.
> 4) I don't know what monkey has bitten you, but why the f%&$k do you sound
> so insulted? (see your statement on "a inferior language like Dylan")
Ahhh ... I guess that was some sort of preemptive self-deprecatory
defense mechanism, as I usually have gotten insulted and abused when I
pop up here and imply that someone with a lot of Dylan experience but
not a lot of CL experience somehow has nothing useful to say here.
*Especially* I I'm so rash as to state or imply that Dylan is a member
of the "Lisp Family", or is similar to CLOS, of if I say that I
actually quite like Scheme (as far as it goes, which isn't far...).
My apologies if I was over-sensitive
.
> 5) Is it some childish kind of revenge to point with the finger
> on CL and whine "Hey look you've done worse than we haaa ha!"
> Am _I_ pointing at _you_ yelling "Hey where are the _applications_
> written in Dylan!" ?
Absolutely not. I *want* to see CL entries there and doing well. I
*want* to see languages such as Dylan and CL accepted in the
mainstream world so that management and/or clients don't look at me as
if I'm a madman when I suggest their use.
I myself happen to think that Dylan is a little bit better than CL.
You probably think the reverse. That's fine with me -- the
differences between the two are in my opinion about 1% as large as the
differences between either of them and C++ or Java. If the newspaper
tomorrow was full of CL jobs then I'd be overjoyed and take one of
them in an instant.
As for "where are the applications in Dylan?", I suspect the answer to
that is much the same as the answer to "where are the applications in
CL?". Basically, typical management has never heard of it and
technical people haven't yet pushed it enough because most of *them*
have never head of it either, or else have some mistaken impression
that it is slow, only for "AI", or "has two many brackets". Oh, and
the good old "how do we find 20 experienced Dylan programmers by next
month?" or "who maintains your code if you get run over by a bus
tomorrow?".
Just getting it known out there that our languages exist and are
practical is difficult and important. I'm trying to do my bit. The
Dylan Hackers write-up web page has been accessed by nearly two
thousand people in the last couple of days. That's got to be quite a
few sets of eyeballs that have never previously even heard of Dylan --
and I even snuck some source code in there.
-- Bruce
In article <············@rznews2.rrze.uni-erlangen.de>, Jochen Schmidt wrote:
>1) This year was the first time Common Lisp teams participated
> at all. I and a few others had a CL team too but we decided
> on the end not to publish our entry because we thought a bad
> CL entry would be even worse than no CL entry.
Why worry that writing a bad program will somehow reflect badly on the
programming language you are using? Consider that hordes of C and C++
programmers write undefined, or otherwise incorect or unnecessarily
nonportable crap on a daily basis and don't care at all. You aren't
acting in the role of an ambassador for Lisp when you participate in
this programming contest. Some people will use your success or failure to
make some invalid inferences about the programming language. Their
inferences, if published, can be debunked in due time. Do not allow
the anticipation of failure and these subsequent arguments to deter you.
From: Nils Goesche
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <lk8zfnczl5.fsf@pc022.bln.elmeg.de>
·····@hoult.org (Bruce Hoult) writes:
> Nils Goesche <······@cartan.de> wrote in message news:<··············@pc022.bln.elmeg.de>...
> > But all the time, I
> > thought I was supposed to parse in a 20 MB file and optimize and dump
> > it in three seconds.
>
> Strange, because they *specified* that input files would never be
> bigger than 5 MB and you'd never have less time than 3 minutes. But
IIRC, this 5 MB limit wasn't in the first versions of the task
description. They said `a few MB', so I generated some 20 MB test
files with very deep, highly recursive (very artificial) content. It
was hard to avoid swapping on those :-)
> Of course. But I still ask "Where are the good Common Lisp
> entries?" I'm really pleased to get Dylan into the top placings,
> but honestly I wouldn't mind one bit if there were a few CL entries
> up there as well, since they''re so similar. Just to keep those
> Hindley-Milner types from thinking they've got a birthright to win
> the ICFP contest.
Exactly :) Well, there seems to be some kind of a `typing hype' among
theoretical computer scientists. I am sure they'll get over that at
some time. Not so long ago, they insisted that everybody use a pure
functional language, but apparently nowadays it is acceptable to use
the impure OCaml. Maybe they'll look at CL again when the static
typing hype is over as well.
Did you look at the winning Haskell entry? IMHO it looked much more
complicated than it had to just because they used Haskell. They
obviously knew most about these kinds of algorithms and would have won
in pretty much any programming language they had chosen to implement
this. In CL too, of course.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Nils Goesche <······@cartan.de> wrote in message news:<··············@pc022.bln.elmeg.de>...
> Did you look at the winning Haskell entry? IMHO it looked much more
> complicated than it had to just because they used Haskell. They
> obviously knew most about these kinds of algorithms and would have won
> in pretty much any programming language they had chosen to implement
> this. In CL too, of course.
Actually, using Haskell nearly undid them. If I'd run Dylan Hacker
iteratively with wider bounds until runnin gout of time then it would
have come first. That I *didn't* do that wasn't because I didn't have
time but was a deliberate decision based on my (incorrect) accessment
of the judging criteria. I had such a loop during testing (when I was
choosing my fixed pruning parameters) and took it out.
Also see what, e.g. Tom Rokicki did after the contest with Dynamic
Programming in C++.
Rokicki's time from his own tests on a Celeron 450, vs Haskell and
Dylan on the judges' PIII 1.0 GHz..
Rokicki Haskell Dylan
Input file Save Time Save Time Save Time
000-example 884 5.73s 877 170s 884 0.8s
003-third-step 1480 24.4s 1401 170s 1429 16s
004-random 3021 6h 41m 11.21s 2493 170s 2136 88s
005-icfp2000 7736 2h 42m 28.4s 7121 590s 7711 85s
103-rreturns 6247 16m 19.84s 5683 890s 5869 43s
201-suite 7274 13m 46.15s 7208 60 m 7157 50s
202-hand-again 1009 15.03s 942 60 m 958 12s
All of Rokicki's are for *optimal* results, not approximations. No
heuristics. No pruning. Just brute force.
It's impossible from this to say how Rokicki would have done if he'd
stopped at the time limit for random and icfp2000 but it's probably
pretty good (and his program that you can download *does* have the
ability to stop at a time limit.
But it's clear that on all the others he kicks butt compared to the
Haskell program -- both in speed and in level of optimization.
-- Bruce
From: Stephen J. Bevan
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <m3g09vkqtv.fsf@yahoo.com>
Nils Goesche <······@cartan.de> writes:
> Did you look at the winning Haskell entry? IMHO it looked much more
> complicated than it had to just because they used Haskell. They
> obviously knew most about these kinds of algorithms and would have won
> in pretty much any programming language they had chosen to implement
> this. In CL too, of course.
If that's the case, how about re-writing the Haskell solution in CL
and see how it matches up to the original Hasekell?
From: Nils Goesche
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <lkzo83ar71.fsf@pc022.bln.elmeg.de>
·············@yahoo.com (Stephen J. Bevan) writes:
> Nils Goesche <······@cartan.de> writes:
> > Did you look at the winning Haskell entry? IMHO it looked much more
> > complicated than it had to just because they used Haskell. They
> > obviously knew most about these kinds of algorithms and would have won
> > in pretty much any programming language they had chosen to implement
> > this. In CL too, of course.
>
> If that's the case, how about re-writing the Haskell solution in CL
> and see how it matches up to the original Hasekell?
I guess it will be shorter and faster, but I don't want to use the
little spare time I have to prove it :-)
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
From: James Hague
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3b9ce128$1_2@corp.newsgroups.com>
Bruce Hoult 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.
An entry written in dynamically-typed J won the Judge's Prize in 1998.
James
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
On Mon, 03 Sep 2001 20:16:33 +1200, Bruce Hoult wrote:
>·········@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.
>-- Bruce
--
-William "Billy" Tanksley
In article <·······················@dolphin.openprojects.net>,
·········@bigfoot.com wrote:
> On Mon, 03 Sep 2001 20:16:33 +1200, Bruce Hoult wrote:
> >·········@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
On Tue, 04 Sep 2001 01:29:12 +1200, Bruce Hoult wrote:
>·········@bigfoot.com wrote:
>> On Mon, 03 Sep 2001 20:16:33 +1200, Bruce Hoult wrote:
>> >·········@bigfoot.com 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.
>> 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.
In other words, they throw away all the indentation information and use
only the syntactic information.
>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).
All of these are possible in Python as well -- you just can't throw away
the information about indentation. Instead, you use it.
>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.
Are you under the impression that Python is any different? The difference
is that in Python, the indentation ALWAYS shows your errors; it doesn't
show them only when your editor happens to support your language.
>> >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 :-)
Another word for "unfalsifiable." No amount of contrary information will
ever change your mind about that theory; you simply state that the source
is lying to save his own ego, and the contrary evidence vanishes.
All scientific theories are falsifiable. Yours isn't. Ergo...
>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.
Because both you and the compiler can see your error.
>-- Bruce
--
-William "Billy" Tanksley
From: David Douthitt
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3B96957E.E40E848E@mailbag.com>
William Tanksley wrote:
> Perhaps I can't speak for other Python programmers, but as
> for myself, I've never had an indentation-related bug. Never once.
That's rather amazing. Over and over and over I've heard from former
Python programmers who said they were constantly making indentation
mistakes, and getting things lined up wrong.
In the example previously noted:
if XXXX
foo
else
foo2
foo3
Now suppose that "foo3" was REALLY supposed to occur OUTSIDE the if
statement; there is a BUG in the above code if indentation is
significant. This also points out the "dangling else" someone else
mentioned.
This, from what I've heard, is THE #1 complaint against Python - and why
many former Python programmers now write in Ruby.
> The problem is that indentation is such an /obvious/ feature of a program;
> it's immediately visible. Indentation mistakes are /not/ subtle.
The one above is.
> 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.
As it should. Also, if the matching {} () are a problem, just use vi's
% command and you're shown instantly the other matching end.
The point is that in C (or most other languages) the scope of the IF
statement is explicitly defined:
C:
if (X) {
foo
}
else {
foo2
}
foo3
FORTH:
X IF
FOO
ELSE
FOO2
FI FOO3
(k)sh:
if X ; do
foo
else
foo2
fi
foo3
LISP:
(cond (X) (foo) (foo2)) (foo3)
...hope I got that right...
The point is that the Boundaries of the IF statement (or cond) are all
explicitly defined with some sort of visible marker which is not
affected by whitespace manipulation. One could pretty print any of
these code snippets, and they'd still work; rearrange the Python code
and I wonder if it would still work?
On Wed, 05 Sep 2001 17:13:34 -0400, David Douthitt wrote:
>William Tanksley wrote:
>> Perhaps I can't speak for other Python programmers, but as
>> for myself, I've never had an indentation-related bug. Never once.
>That's rather amazing. Over and over and over I've heard from former
>Python programmers who said they were constantly making indentation
>mistakes, and getting things lined up wrong.
Perhaps we move in different circles. Where do you meet these people?
>In the example previously noted:
> if XXXX
> foo
> else
> foo2
> foo3
>Now suppose that "foo3" was REALLY supposed to occur OUTSIDE the if
>statement; there is a BUG in the above code if indentation is significant.
Let's suppose that. Now look at the code you typed. Is there anything
hiding? Is there any way you could miss that foo3 is actually a part of
the else block? The mistake can occur, as it can in any language;
however, because the block delimiters are obvious and completely
unmistakable for the delimiters of any other block, the mistake is also
obvious.
The previous poster spoke of redundancy, and redundancy is good. What
isn't good is using obscure messages to convey meaning which is also
conveyed by non-obscure messages. To be specific, a single } is obscure,
while a level of indentation isn't obscure.
>This, from what I've heard, is THE #1 complaint against Python
I've heard it from one or two people who have tried Python, and none who
have used it regularly. Everyone else I've heard is speculating based on
ignorance.
>- and why many former Python programmers now write in Ruby.
Many current Ruby programmers write in Python. More programmers code in
Python than code in Ruby. More programmers claim to enjoy Python than
claim to enjoy Ruby. None of these statistics matter.
BTW, Ruby solves many problems Python has, not only the non-problem of
indentation.
>> The problem is that indentation is such an /obvious/ feature of a program;
>> it's immediately visible. Indentation mistakes are /not/ subtle.
>The one above is.
Can you think of a reason why a person reading your example would think
that foo3 isn't in the else block?
>The point is that in C (or most other languages) the scope of the IF
>statement is explicitly defined:
As it is in Python.
>affected by whitespace manipulation. One could pretty print any of
>these code snippets, and they'd still work; rearrange the Python code
>and I wonder if it would still work?
If you start out with working Python code, you can safely reformat to
produce working Python code which does the same thing. You can't use the
same parser you used to prettyprint C, but that's not a unique weakness --
you can't do that with Smalltalk either.
--
-William "Billy" Tanksley
From: David Douthitt
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3B9D1441.15CBEC35@mailbag.com>
William Tanksley wrote:
>
> On Wed, 05 Sep 2001 17:13:34 -0400, David Douthitt wrote:
> >William Tanksley wrote:
> >> Perhaps I can't speak for other Python programmers, but as
> >> for myself, I've never had an indentation-related bug. Never once.
>
> >That's rather amazing. Over and over and over I've heard from former
> >Python programmers who said they were constantly making indentation
> >mistakes, and getting things lined up wrong.
>
> Perhaps we move in different circles. Where do you meet these people?
On the Ruby list :)
> >In the example previously noted:
> > if XXXX
> > foo
> > else
> > foo2
> > foo3
>
> >Now suppose that "foo3" was REALLY supposed to occur OUTSIDE the if
> >statement; there is a BUG in the above code if indentation is significant.
>
> Let's suppose that. Now look at the code you typed. Is there anything
> hiding? Is there any way you could miss that foo3 is actually a part of
> the else block? The mistake can occur, as it can in any language;
> however, because the block delimiters are obvious and completely
> unmistakable for the delimiters of any other block, the mistake is also
> obvious.
Not necessarily obvious. To a typical C program, the code
if XXXX
foo
else
foo2
foo3
Would do something completely different than it would in Python: in C
(and in most other languages) foo3 is not a part of the else statement;
in Python, it is.
> Many current Ruby programmers write in Python. More programmers code in
> Python than code in Ruby.
Not in Japan :)
> Can you think of a reason why a person reading your example would think
> that foo3 isn't in the else block?
Yes. In C and many languages, foo3 would be OUTSIDE of the block.
> >The point is that in C (or most other languages) the scope of the IF
> >statement is explicitly defined:
>
> As it is in Python.
To me explicit (in this context) means: "defined in an obvious manner by
a visible graphic character or wording." Python does not qualify.
C has the ; character to end statements, and the {} to define blocks;
FORTH has IF ... ELSE ... THEN; COBOL has IF ... ELSE (and ENDIF in
COBOL-85); Smalltalk has ifTrue and ifFalse.
Python has
From: Greg Jandl
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <Paan7.208$mz2.40349@news7.onvoy.net>
On Mon, 10 Sep 2001 15:28:01 -0400, David Douthitt <·····@mailbag.com> wrote:
>William Tanksley wrote:
>>
>> On Wed, 05 Sep 2001 17:13:34 -0400, David Douthitt wrote:
>> >William Tanksley wrote:
>> >> Perhaps I can't speak for other Python programmers, but as
>> >> for myself, I've never had an indentation-related bug. Never once.
>>
>> >That's rather amazing. Over and over and over I've heard from former
>> >Python programmers who said they were constantly making indentation
>> >mistakes, and getting things lined up wrong.
>>
>> Perhaps we move in different circles. Where do you meet these people?
>
>On the Ruby list :)
Now there's a surprise.
>
>> >In the example previously noted:
>> > if XXXX
>> > foo
>> > else
>> > foo2
>> > foo3
>>
>> >Now suppose that "foo3" was REALLY supposed to occur OUTSIDE the if
>> >statement; there is a BUG in the above code if indentation is significant.
>>
>> Let's suppose that. Now look at the code you typed. Is there anything
>> hiding? Is there any way you could miss that foo3 is actually a part of
>> the else block? The mistake can occur, as it can in any language;
>> however, because the block delimiters are obvious and completely
>> unmistakable for the delimiters of any other block, the mistake is also
>> obvious.
>
>Not necessarily obvious. To a typical C program, the code
>
>if XXXX
> foo
>else
> foo2
> foo3
But Python is not C. What you are saying is: "If I interpret your
Python code as C code, the behavior of the code is different than what
I expect."
>
>Would do something completely different than it would in Python: in C
>(and in most other languages) foo3 is not a part of the else statement;
>in Python, it is.
That is a silly argument. A C compiler would choke on Forth or Lisp
source. Does that make the Forth or Lisp code incorrect in some way?
>
>> Many current Ruby programmers write in Python. More programmers code in
>> Python than code in Ruby.
>
>Not in Japan :)
>
>> Can you think of a reason why a person reading your example would think
>> that foo3 isn't in the else block?
>
>Yes. In C and many languages, foo3 would be OUTSIDE of the block.
Again, if you start from a false premiss ("All languages are C"), your
conclusion is likely to be incorrect as well.
>
>> >The point is that in C (or most other languages) the scope of the IF
>> >statement is explicitly defined:
>>
>> As it is in Python.
>
>To me explicit (in this context) means: "defined in an obvious manner by
>a visible graphic character or wording." Python does not qualify.
'When I use a word,' Humpty Dumpty said, in a rather scornful tone,'
it means just what I choose it to mean, neither more nor less.'
<sigh>
Don't go sitting on any walls, dude.
If you warp your definitions sufficiently, you can make a set contain
exactly what you want it to, but you prove nothing.
>
>C has the ; character to end statements, and the {} to define blocks;
>FORTH has IF ... ELSE ... THEN; COBOL has IF ... ELSE (and ENDIF in
>COBOL-85); Smalltalk has ifTrue and ifFalse.
>
>Python has
Exactly. Ask any artist; space is vital in defining form. Python uses
that fact, which comes naturally to anyone who can tell a doorway from
a wall.
IMHO, of course.
--
Gj
On Mon, 10 Sep 2001 15:28:01 -0400, David Douthitt wrote:
>William Tanksley wrote:
>> On Wed, 05 Sep 2001 17:13:34 -0400, David Douthitt wrote:
>> >William Tanksley wrote:
>> >In the example previously noted:
>> > if XXXX
>> > foo
>> > else
>> > foo2
>> > foo3
>> >Now suppose that "foo3" was REALLY supposed to occur OUTSIDE the if
>> >statement; there is a BUG in the above code if indentation is significant.
>> Let's suppose that. Now look at the code you typed. Is there anything
>> hiding? Is there any way you could miss that foo3 is actually a part of
>> the else block? The mistake can occur, as it can in any language;
>> however, because the block delimiters are obvious and completely
>> unmistakable for the delimiters of any other block, the mistake is also
>> obvious.
>Not necessarily obvious.
Untrue. foo3 is _obviously_ a part of foo2's block; it's positioned
there. Even a C programmer could tell you that (although the C programmer
wouldn't assume that foo3 would in fact execute as part of foo2's block
without checking something else, something less obvious).
>To a typical C program, the code
>if XXXX
> foo
>else
> foo2
> foo3
>Would do something completely different than it would in Python: in C (and
>in most other languages) foo3 is not a part of the else statement; in
>Python, it is.
I assume your point is that Python isn't C. True. Neither is Ruby, nor
Oberon. The following code in Oberon:
IF XXXX THEN
foo
ELSE
foo2;
foo3
END
Will do something entirely different than it would have done in C. This
shouldn't come as a suprise to any programmer.
What does constantly come as a surprise to programmers is the fact that in
your example, foo3 isn't part of foo2's block. It *looks* like it is; all
immediately visible evidence indicates that it is. In conventional C
there's no visible evidence to indicate otherwise -- the braces aren't
even present. If someone's chosen to tread the path of safety over
simplictiy, there would be braces -- but in the nest of braces, parens,
brackets, and so on, who's to notice that one gets misplaced?
>> Many current Ruby programmers write in Python. More programmers code in
>> Python than code in Ruby.
>Not in Japan :)
I know Ruby is more popular in Japan than in the US -- but is the
disparity THAT extreme?
>> Can you think of a reason why a person reading your example would think
>> that foo3 isn't in the else block?
>Yes. In C and many languages, foo3 would be OUTSIDE of the block.
In other words, a person expecting to be reading C, and ignoring all the
evidence to the contrary, would be surprised by that. I honestly don't
see why; I think that if they ignore all the other things Python does
different than C they'll ignore that as well. It's like ignoring the fact
that Oberon's case sensitive.
>> >The point is that in C (or most other languages) the scope of the IF
>> >statement is explicitly defined:
>> As it is in Python.
>To me explicit (in this context) means: "defined in an obvious manner by
>a visible graphic character or wording." Python does not qualify.
Exactly how is an indentation invisible? It's the most visible thing you
can get! Rather than having a single character which is usually skipped
over when proofreading, you have the location of the entire block changed.
>C has the ; character to end statements, and the {} to define blocks;
>FORTH has IF ... ELSE ... THEN; COBOL has IF ... ELSE (and ENDIF in
>COBOL-85); Smalltalk has ifTrue and ifFalse.
>Python has
(and here the post ends.)
No, Python has
indentation, not absence of all meaning.
Indentation is very significant in all code; that's
why Fortran is so painful for many computer scientists,
because Fortran forces them to not use indentation.
--
-William "Billy" Tanksley
From: Raymond Toy
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <4nsndtv2tn.fsf@rtp.ericsson.se>
>>>>> "William" == William Tanksley <········@dolphin.openprojects.net> writes:
William> No, Python has
William> indentation, not absence of all meaning.
William> Indentation is very significant in all code; that's
William> why Fortran is so painful for many computer scientists,
William> because Fortran forces them to not use indentation.
Really? All of my Fortran code has appropriate indentation.
Ray
On 11 Sep 2001 17:24:04 -0400, Raymond Toy wrote:
>>>>>> "William" == William Tanksley <········@dolphin.openprojects.net> writes:
> William> No, Python has
> William> indentation, not absence of all meaning.
> William> Indentation is very significant in all code; that's
> William> why Fortran is so painful for many computer scientists,
> William> because Fortran forces them to not use indentation.
>Really? All of my Fortran code has appropriate indentation.
You're using a better dialect than I was taught, then. Congrats.
>Ray
--
-William "Billy" Tanksley
From: Tim Bradshaw
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <ey3pu8w23cu.fsf@cley.com>
* William Tanksley wrote:
> You're using a better dialect than I was taught, then. Congrats.
I'm not aware of any FORTRAN dialects that forbid indentation. There
may be some, older than FORTRAN 66, but that's 35 years ago now.
There *are* (or were, in FORTRAN 77, I don't know anything newer),
restrictions about things that had to go in the first 6 columns, such
as comment chars, labels and line-continuation thingies, but other
than that I think the language doesn't care. Actually the worst thing
about it is that it is more-or-less completely insensitive to
whitespace as far as I remember: I think there's a famous bug that was
a result of this.
Of course a lot of old FORTRAN code probably uses indentation fairly
scarcely...
--tim
From: Raymond Toy
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <4nofogvb5g.fsf@rtp.ericsson.se>
>>>>> "Tim" == Tim Bradshaw <···@cley.com> writes:
Tim> * William Tanksley wrote:
>> You're using a better dialect than I was taught, then. Congrats.
Tim> I'm not aware of any FORTRAN dialects that forbid indentation. There
Tim> may be some, older than FORTRAN 66, but that's 35 years ago now.
Tim> There *are* (or were, in FORTRAN 77, I don't know anything newer),
Tim> restrictions about things that had to go in the first 6 columns, such
Tim> as comment chars, labels and line-continuation thingies, but other
Tim> than that I think the language doesn't care. Actually the worst thing
Tim> about it is that it is more-or-less completely insensitive to
Tim> whitespace as far as I remember: I think there's a famous bug that was
Yep. I think I used a Fortran 66 compiler long time ago, but the only
way Fortran 77 limited indentation was the fact the all lines were at
most 72 characters with 6 used up for line numbers and continuations.
And the only place whitespace that was significant was in Hollerith
strings. Thus, this would be perfectly legal Fortran:
I F(A var .LT. b VAR ) t H e N
....
En d I f
Ray
From: Philip Lijnzaad
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <u7lmjk21rb.fsf@sol6.ebi.ac.uk>
> I think there's a famous bug that was
> a result of this.
yup: one of the pioneer or mariner missions was lost around Jupiter, due to
this. Some routine used for calculating/applying course corrections had the
statement
DO I= 1. 3
.
.
.
CONTINUE
this was parsed as DOI = 1.3 (assignment) rather than as
DO I=1, 3
.
.
.
CONTINUE
which would be an iteration over three elements. But this not only due
to whitespace insensitivity, I daresay.
Philip
--
Real programs don't eat cache (Malay)
-----------------------------------------------------------------------------
Philip Lijnzaad, ········@ebi.ac.uk \ European Bioinformatics Institute,rm A2-08
+44 (0)1223 49 4639 / Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) \ Cambridgeshire CB10 1SD, GREAT BRITAIN
From: Raymond Toy
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <4nk7z4vb3s.fsf@rtp.ericsson.se>
>>>>> "Philip" == Philip Lijnzaad <········@ebi.ac.uk> writes:
>> I think there's a famous bug that was
>> a result of this.
Philip> yup: one of the pioneer or mariner missions was lost around Jupiter, due to
Philip> this. Some routine used for calculating/applying course corrections had the
Philip> statement
Philip> DO I= 1. 3
Philip> .
Philip> .
Philip> .
Philip> CONTINUE
Philip> this was parsed as DOI = 1.3 (assignment) rather than as
Philip> DO I=1, 3
Philip> .
Philip> .
Philip> .
Philip> CONTINUE
Philip> which would be an iteration over three elements. But this not only due
Philip> to whitespace insensitivity, I daresay.
You forgot the statement number that is a part of the do
statement. :-)
Ray
From: Leonard Zettel
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3BA00389.341A5434@acm.org>
Tim Bradshaw wrote:
>
> * William Tanksley wrote:
>
> > You're using a better dialect than I was taught, then. Congrats.
>
> I'm not aware of any FORTRAN dialects that forbid indentation. There
> may be some, older than FORTRAN 66, but that's 35 years ago now.
> There *are* (or were, in FORTRAN 77, I don't know anything newer),
> restrictions about things that had to go in the first 6 columns, such
> as comment chars, labels and line-continuation thingies, but other
> than that I think the language doesn't care. Actually the worst thing
> about it is that it is more-or-less completely insensitive to
> whitespace as far as I remember: I think there's a famous bug that was
> a result of this.
>
Not more-or-less, but COMPLETELY insensitive to white space in columns
7 to 72.
END and E N D are treated exactly the same.
-LenZ-
> Of course a lot of old FORTRAN code probably uses indentation fairly
> scarcely...
>
> --tim
From: Samuel A. Falvo II
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <slrn9ptgqp.je6.kc5tja@dolphin.openprojects.net>
On Tue, 11 Sep 2001 20:43:28 GMT, William Tanksley wrote:
>different than C they'll ignore that as well. It's like ignoring the fact
>that Oberon's case sensitive.
Not to interject, but this isn't 100% true. The keywords of the language
are certainly case sensitive -- they're always in uppercase. However,
variable names and procedure/function names are =not= case sensitive, though
in linker files, they do retain their case.
--
KC5TJA/6, DM13, QRP-L #1447
Samuel A. Falvo II
Oceanside, CA
From: Bruce R. McFarling
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3b96ecfd.953664@news.newcastle.edu.au>
On Wed, 05 Sep 2001 17:13:34 -0400, David Douthitt <·····@mailbag.com>
wrote:
>FORTH:
>X IF
> FOO
>ELSE
> FOO2
>FI FOO3
>...hope I got that right...
It could be, with a ": FI THEN ; IMMEDIATE" somewhere before it, but
standard Forth is
X IF
FOO
ELSE
FOO2
THEN FOO3
From: Geoff Summerhayes
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <tpf315i7li3ob5@corp.supernews.com>
"Bruce R. McFarling" <······@ecbm.at.cc.newcastle.edu.au> wrote in
message ····················@news.newcastle.edu.au...
> On Wed, 05 Sep 2001 17:13:34 -0400, David Douthitt <·····@mailbag.com>
> wrote:
>
> >FORTH:
>
> >X IF
> > FOO
> >ELSE
> > FOO2
> >FI FOO3
>
> >...hope I got that right...
>
> It could be, with a ": FI THEN ; IMMEDIATE" somewhere before it, but
> standard Forth is
>
> X IF
> FOO
> ELSE
> FOO2
> THEN FOO3
>
<nitpick>
: FI POSTPONE THEN ; IMMEDIATE
</nitpick>
From: Jerry Avins
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3B97F76F.4170CAFA@ieee.org>
Geoff Summerhayes wrote:
>
> "Bruce R. McFarling" <······@ecbm.at.cc.newcastle.edu.au> wrote in
> message ····················@news.newcastle.edu.au...
> > On Wed, 05 Sep 2001 17:13:34 -0400, David Douthitt <·····@mailbag.com>
> > wrote:
> >
> > >FORTH:
> >
> > >X IF
> > > FOO
> > >ELSE
> > > FOO2
> > >FI FOO3
> >
> > >...hope I got that right...
> >
> > It could be, with a ": FI THEN ; IMMEDIATE" somewhere before it, but
> > standard Forth is
> >
> > X IF
> > FOO
> > ELSE
> > FOO2
> > THEN FOO3
> >
>
> <nitpick>
>
> : FI POSTPONE THEN ; IMMEDIATE
>
> </nitpick>
Maybe so, but my Forth compilers also nitpick. Conformity offers decided
advantages to communication. However ... (see sig)
Jerry
--
Ritual often serves to instill the belief that conformity is a privilege.
-------------------------------------------------------------------------
From: Bruce R. McFarling
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3b989317.28822912@news.newcastle.edu.au>
On Thu, 6 Sep 2001 10:53:53 -0400, "Geoff Summerhayes"
<·············@hNoOtSmPaAiMl.com> wrote:
><nitpick>
>: FI POSTPONE THEN ; IMMEDIATE
></nitpick>
Yeah, that. Must have postponed the proofreading instead.
In article <·················@mailbag.com>, David Douthitt wrote:
>William Tanksley wrote:
>
>> Perhaps I can't speak for other Python programmers, but as
>> for myself, I've never had an indentation-related bug. Never once.
>
>That's rather amazing. Over and over and over I've heard from former
>Python programmers who said they were constantly making indentation
>mistakes, and getting things lined up wrong.
Clearly, these people did not have the computing maturity to use a text
editor properly.
Note that a sample of *ex* python programmers is biased. The *ex* users
of anything will likely have bad things to say about it. Just ask
anyone's ex-girlfriend. ;)
>In the example previously noted:
>
> if XXXX
> foo
> else
> foo2
> foo3
>
>Now suppose that "foo3" was REALLY supposed to occur OUTSIDE the if
>statement; there is a BUG in the above code if indentation is
>significant.
We can only guess about the intent of the code. It's possible that
it is intended that foo3 be inside the else clause, or that it be
outside of the if construct completely.
Without knowing anything about the surrounding program, the evidence
appears to favor the first interpretation: the indentation of the
statement suggests that the programmer wanted foo2 and foo3 to be treated
as a unit.
If that is the intent, then there is no bug in the code if
indentation is significant in this language. But there is
a bug if indentation is *not* significant!
There are two possible intents, and two possible choices
of indentation sensitivity. That leads to four combination,
two of which are erroneous.
All of which means that you haven't done due diligence in
applying your intellect to the argument.
>> The problem is that indentation is such an /obvious/ feature of a program;
>> it's immediately visible. Indentation mistakes are /not/ subtle.
>
>The one above is.
Subtlety is subjective. I don't see it as subtle. Given indentation
sensitivity, the code has a single, unambiguous meaning, whether or
not that is the intended meaning. Nobody can possibly read a different
meaning into it. That is not subtle at all.
What I see as subtle subtle is the possibility of having two indicators
of structure that can contradict each other, and one of them is
used exclusively by the machine, and the other is relied upon by the
programmer.
Python makes the bold decision: take the notation which programmers in
various languages actually use to express nesting, and make it the sole
determiner of nesting.
>> 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.
>
>As it should. Also, if the matching {} () are a problem, just use vi's
>% command and you're shown instantly the other matching end.
>
>The point is that in C (or most other languages) the scope of the IF
>statement is explicitly defined:
>
>C:
>
>if (X) {
> foo
> }
>else {
> foo2
> }
The braces are not required in C. By itself, if statement does not
introduce a new scope at all, so ``scope of the if statement''
is a meaningless phrase in the context of C.
>The point is that the Boundaries of the IF statement (or cond) are all
>explicitly defined with some sort of visible marker which is not
>affected by whitespace manipulation.
That is not true, in the case of C. The grammar for the if statement
does not have any explicit termination marker. It goes something like this:
if (expression) statement optional-else-clause
So whatever terminates the statement terminates the first clause.
Some statements have a terminating semicolon; others do not.
Then if the next token is an else, the else clause is parsed
an associated with the if statement. The else clause is, again,
terminated by whatever terminates its embedded statement.
It's true that the Algol-like languages like the POSIX shell language
have somewhat superior solution, with their explicit termination
markers like endif or fi.
>One could pretty print any of
>these code snippets, and they'd still work; rearrange the Python code
>and I wonder if it would still work?
If you can rearrange non-whitespace characters, then you can screw
up code in any language. Who is to say that a moron who butchers
source code will confine himself to only whitespace alterations?
Also note that Python code doesn't require such reformatting to
restore a proper indentation style, since it has proper indentation.
Why would you care whether Python code can be affected by an operation
that is not applicable to it?
For any source language, there exists a set of possible transformations
which preserve the meaning, and a set which alters the meaning.
In Python, some of the meaning-altering transformations happen
to be whitespace-only transformations.
But other languages have whitespace sensitivities too. You cannot
randomly insert or delete whitespace in a C program without
changing its meaning, or introducing an error. Consider:
#define x (y) z
#define x(y) z
There are many other examples of C whitespace-sensitivity.
In Lisp, you could delete whitespace between two symbols, or
insert whitespace in the middle of a symbol:
(foobar) <-> (foo bar)
So the moron code butcher can confine himself to insertions or deletions
of whitespace, and yet change the meaning of programs in C and Lisp.
Since languages other than Python have various whitespace sensitivities,
it's irrational to pick on Python.
From: Bruce McFarling
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3b9d6ae7.569436@seagoon.newcastle.edu.au>
On Mon, 10 Sep 2001 22:51:44 GMT, ···@ashi.footprints.net (Kaz
Kylheku) wrote:
>Clearly, these people did not have the computing maturity to use a text
>editor properly.
Quite so. The system makes things easier for programmers, except for
those programmers who have trouble using the system properly.
>Note that a sample of *ex* python programmers is biased. The *ex* users
>of anything will likely have bad things to say about it.
A sample of current programmers is also biased ... especially in
languages that few are forced to use by dictated. They are not so
disatisfied that they switch languages.
(
----------
Virtually,
Bruce McFarling, Newcastle,
····@cc.newcastle.edu.au
)
From: Jerry Avins
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3B9E0AE4.4DD31D74@ieee.org>
Kaz Kylheku wrote:
>
...
>
> In Python, some of the meaning-altering transformations happen
> to be whitespace-only transformations.
>
> But other languages have whitespace sensitivities too. You cannot
> randomly insert or delete whitespace in a C program without
> changing its meaning, or introducing an error. Consider:
>
> #define x (y) z
> #define x(y) z
>
> There are many other examples of C whitespace-sensitivity.
>
> In Lisp, you could delete whitespace between two symbols, or
> insert whitespace in the middle of a symbol:
>
> (foobar) <-> (foo bar)
>
> So the moron code butcher can confine himself to insertions or deletions
> of whitespace, and yet change the meaning of programs in C and Lisp.
>
> Since languages other than Python have various whitespace sensitivities,
> it's irrational to pick on Python.
That is artificial. You made a number of good points earlier, but I
think you overreached here. It's clear that Douthitt wrote about changes
in the kind and amount of whitespace. Nowhere did he discuss or imply
insertion of whitespace where none had been before, or the complete
elimination of a block of whitespace of any kind. (I once used a markup
language that gives special significance to a line consisting of a
single newline, but space-newline is a no-op. Horrible!)
Jerry
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
From: Kaz Kylheku
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <a2qn7.183$jY.14604@news1.rdc1.bc.home.com>
In article <·················@ieee.org>, Jerry Avins wrote:
>Kaz Kylheku wrote:
>>
> ...
>>
>> In Python, some of the meaning-altering transformations happen
>> to be whitespace-only transformations.
>>
>> But other languages have whitespace sensitivities too. You cannot
>> randomly insert or delete whitespace in a C program without
>> changing its meaning, or introducing an error. Consider:
>>
>> #define x (y) z
>> #define x(y) z
>>
>> There are many other examples of C whitespace-sensitivity.
>>
>> In Lisp, you could delete whitespace between two symbols, or
>> insert whitespace in the middle of a symbol:
>>
>> (foobar) <-> (foo bar)
>>
>> So the moron code butcher can confine himself to insertions or deletions
>> of whitespace, and yet change the meaning of programs in C and Lisp.
>>
>> Since languages other than Python have various whitespace sensitivities,
>> it's irrational to pick on Python.
>
>That is artificial. You made a number of good points earlier, but I
>think you overreached here. It's clear that Douthitt wrote about changes
>in the kind and amount of whitespace. Nowhere did he discuss or imply
>insertion of whitespace where none had been before, or the complete
If I change
x
to
x
then I'm inserting whitespace where none had been before.
>elimination of a block of whitespace of any kind.
I see; so essentially our code butcher has to be carefully selective to
only make the kinds of damage that specifically affect Python programs.
Of course, that is perfectly consistent with our Masked Midnight Mangler
being the shared hallucination of a few rabid Python detractors.
When people are irrationaly against something, they tend to conjure
up some kind of Great Evil, and then ascribe to it various imaginary
attributes. Then they try pass onto others their faith in the same Great
Evil. For Python detractors, the Great Evil is the overwhelming risk
caused by indentation sensitivity, which somehow leads to the inevitable
destruction of every program. The Great Evil is carried out by
imaginary agencies whose existence is taken for granted, such
as gremlins that make specific types of whitespace changes in
source files when nobody is looking.
From: Jerry Avins
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3B9E6843.ACC6E255@ieee.org>
Kaz Kylheku wrote:
>
> In article <·················@ieee.org>, Jerry Avins wrote:
> >Kaz Kylheku wrote:
> >>
> > ...
> >>
> >> In Python, some of the meaning-altering transformations happen
> >> to be whitespace-only transformations.
> >>
> >> But other languages have whitespace sensitivities too. You cannot
> >> randomly insert or delete whitespace in a C program without
> >> changing its meaning, or introducing an error. Consider:
> >>
> >> #define x (y) z
> >> #define x(y) z
> >>
> >> There are many other examples of C whitespace-sensitivity.
> >>
> >> In Lisp, you could delete whitespace between two symbols, or
> >> insert whitespace in the middle of a symbol:
> >>
> >> (foobar) <-> (foo bar)
> >>
> >> So the moron code butcher can confine himself to insertions or deletions
> >> of whitespace, and yet change the meaning of programs in C and Lisp.
> >>
> >> Since languages other than Python have various whitespace sensitivities,
> >> it's irrational to pick on Python.
> >
> >That is artificial. You made a number of good points earlier, but I
> >think you overreached here. It's clear that Douthitt wrote about changes
> >in the kind and amount of whitespace. Nowhere did he discuss or imply
> >insertion of whitespace where none had been before, or the complete
>
> If I change
>
> x
>
> to
> x
>
> then I'm inserting whitespace where none had been before.
>
> >elimination of a block of whitespace of any kind.
>
> I see; so essentially our code butcher has to be carefully selective to
> only make the kinds of damage that specifically affect Python programs.
> Of course, that is perfectly consistent with our Masked Midnight Mangler
> being the shared hallucination of a few rabid Python detractors.
>
> When people are irrationaly against something, they tend to conjure
> up some kind of Great Evil, and then ascribe to it various imaginary
> attributes. Then they try pass onto others their faith in the same Great
> Evil. For Python detractors, the Great Evil is the overwhelming risk
> caused by indentation sensitivity, which somehow leads to the inevitable
> destruction of every program. The Great Evil is carried out by
> imaginary agencies whose existence is taken for granted, such
> as gremlins that make specific types of whitespace changes in
> source files when nobody is looking.
You're too defensive. I have little to protest about Python, and none of
it concerns whitespace or the way blocks are delimited. When you
deliberately blur the distinction between
x
x
and
xx ,
or between whitespace and white space, you dilute and weaken your
arguments I am in sympathy with. I won't bother to elucidate the
differences, because I have no reason to believe you would read
seriously.
Jerry
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
From: Tim Bradshaw
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <ey33d5tn8bl.fsf@cley.com>
* Kaz Kylheku wrote:
> Since languages other than Python have various whitespace sensitivities,
> it's irrational to pick on Python.
This is misleading in the extreme I think. There's a large conceptual
difference between languages which require one-or-more whitespace
characters to delimit various things and languages which are sensitive
to the precise number of whitespace characters.
--tim
From: Kaz Kylheku
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <e3qn7.184$jY.14604@news1.rdc1.bc.home.com>
In article <···············@cley.com>, Tim Bradshaw wrote:
>* Kaz Kylheku wrote:
>
>> Since languages other than Python have various whitespace sensitivities,
>> it's irrational to pick on Python.
>
>This is misleading in the extreme I think. There's a large conceptual
>difference between languages which require one-or-more whitespace
>characters to delimit various things and languages which are sensitive
>to the precise number of whitespace characters.
Yet in both, a program can succumb to a careless edit involving only
whitespace.
From: Tim Bradshaw
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <ey3r8tdlnh5.fsf@cley.com>
* Kaz Kylheku wrote:
> Yet in both, a program can succumb to a careless edit involving only
> whitespace.
Yes, or indeed an edit which deletes or inserts any random character
in the program source: programming languages are vulnerable to that.
The difference is that in most other languages there is a single bit
of information associated with whitespace - either it's there, or it
is not. In Python there are many bits of information, which need to
be preserved - you need to know how much whitespace.
It's strange, but I had nothing against python until I read your
responses to recent articles. I do now.
--tim
From: Kaz Kylheku
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <Dltn7.420$jY.20040@news1.rdc1.bc.home.com>
In article <···············@cley.com>, Tim Bradshaw wrote:
>* Kaz Kylheku wrote:
>
>> Yet in both, a program can succumb to a careless edit involving only
>> whitespace.
>
>Yes, or indeed an edit which deletes or inserts any random character
>in the program source: programming languages are vulnerable to that.
>The difference is that in most other languages there is a single bit
>of information associated with whitespace - either it's there, or it
>is not. In Python there are many bits of information, which need to
>be preserved - you need to know how much whitespace.
So what is the argument then? That it's easier to recover one erased
bit than a plurality of erased bits? Or that the larger swaths of
whitespace in Python source are bigger targets for destruction? :)
>It's strange, but I had nothing against python until I read your
>responses to recent articles. I do now.
Oops! :) I guess it doesn't matter; I suppose that I contributed
in a useful way if someone was able to see something differently.
Anyway, just to show that I can see things both ways, I offer this
pragmatist argument *against* indentation-sensitivity: such sensitivity
makes it less convenient to inspect the differences between two versions
of a program using conventional diff tools, reducing the effectiveness
of such tools for the purposes of code review.
Whenever I make a new version of some source file, before I commit the
change to the version control system, I view the diff. Usually, I view
a diff that ignores whitespace, because this makes the relevant changes
stand out, and ignores trivial changes in indentation. Subtle changes
can be seen ``through'' the irrelevant whitespace changes.
Doing this carries some risk that I will not see a whitespace change that
affects the meaning of the program. However, in most languages, such a
whitespace change will usually occur only accidentally. Plus perhaps the
tool can be tuned to not ignore these types of changes to eliminate or
minimize that risk. GNU diff, for example, can be told to ignore
differences in the *amount* of whitespace, but not differences in the
presence or absence of a swath of whitespace. (This harkens back to your
point about there being a big conceptual difference between different
amounts of whitespace, or the presence or absence of it). With this
feature, I can spot the difference between (foobar) and (foo bar), yet
ignore indentation.
In Python, meaning-altering whitespace changes occur as a matter
of normal programming. Therefore, working with Python, I won't be able
to view diffs with whitespace changes ignored, because the risk of
failing to review a critical whitespace change is too great. This leads to
lengthier, more cumbersome diffs, which do not show relevant detail. For
example, if a block of code is indented over, and a subtle change is
also done in that block, that subtle change won't stand out in the diff;
the diff will show the entire block as having been replaced with new text.
So I mitigate one risk, but another one springs in its place.
From: John Paul Wallington
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <87g09tpkul.fsf@bundalo.shootybangbang.com>
Kaz Kylheku wrote:
> In Python, meaning-altering whitespace changes occur as a matter of
> normal programming.
This is the crux. It may squeal if syntax is bust, but insidious
meaning-altering changes occur as a matter of normal programming.
--
John Paul Wallington
I want the presidency so bad I can already taste the hors d'oeuvres.
On 11 Sep 2001 20:51:14 +0100, John Paul Wallington wrote:
>Kaz Kylheku wrote:
>> In Python, meaning-altering whitespace changes occur as a matter of
>> normal programming.
>This is the crux. It may squeal if syntax is bust, but insidious
>meaning-altering changes occur as a matter of normal programming.
And this is a function of normal programming, not of Python. By the
definition of programming.
With that said, I'll say that I don't have a diff program for Python; I
depend on general-purpose diff programs. They work well enough (they note
the change in whitespace as a diff, and they also note any changes in the
text). I can certainly agree that more value would be added by a diff
program which knew about Python's whitespace rules, but apparently not
enough additional value to stir me up to writing such a beast.
>John Paul Wallington
--
-William "Billy" Tanksley
From: ········@acm.org
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <ZFxp7.6088$386.1159938@news20.bellglobal.com>
········@dolphin.openprojects.net (William Tanksley) writes:
> On 11 Sep 2001 20:51:14 +0100, John Paul Wallington wrote:
> >Kaz Kylheku wrote:
> >> In Python, meaning-altering whitespace changes occur as a matter of
> >> normal programming.
>
> >This is the crux. It may squeal if syntax is bust, but insidious
> >meaning-altering changes occur as a matter of normal programming.
>
> And this is a function of normal programming, not of Python. By the
> definition of programming.
> With that said, I'll say that I don't have a diff program for
> Python; I depend on general-purpose diff programs. They work well
> enough (they note the change in whitespace as a diff, and they also
> note any changes in the text). I can certainly agree that more
> value would be added by a diff program which knew about Python's
> whitespace rules, but apparently not enough additional value to stir
> me up to writing such a beast.
.. And if I were concerned about this, I'd probably start by using
"diff -b" for starters, as that tries to be a tad FORTRAN-like (to
borrow from an article elsewhere in the thread :-)) in _ignoring_
leading and trailing whitespace...
--
(concatenate 'string "cbbrowne" ·@ntlug.org")
http://www.cbbrowne.com/info/linuxdistributions.html
We are Pentium of Borg. Division is futile. You will be approximated.
(seen in someone's .signature)
On 11 Sep 2001 17:08:06 +0100, Tim Bradshaw wrote:
>It's strange, but I had nothing against python until I read your responses
>to recent articles. I do now.
You're kidding, right?
>--tim
--
-William "Billy" Tanksley
From: Reini Urban
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3b99feb7.1007485998@news.tu-graz.ac.at>
Bruce Hoult wrote:
>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.
interesting.
from my own experiences with various languages I also came to the
conclusion "that dylan is the most readable language to me."
This happened with my FFI survey, where I "rated" a language how easily
and "elegantly" it can embrace foreign data, functions, calling
conventions, types and memory layout.
"elegantly: fitting naturally into its own formal language costume"
python and haskell are also okay, but they have some practical problems
for me. java is much too verbose in this regard, most lisps between too
simplifying and a little bit too verbose and "too magical".
"magical: forced to know some internals. depending on internals."
at http://xarch.tu-graz.ac.at/autocad/lisp/ffis.html#dylan_ffi is some
code for aesthetic comparisons.
the forth approach (minotaur) presented there is only usable for non-gc
languages, so very elegant, unreadable, and overly simplifying.
a sample from http://www.equi4.com/minotaur/minotaur.html
"In both cases, the result is the topmost integer popped off the Forth
stack, or zero if the stack is empty ("None" in Python). An example of
the first call sequence is 'print minotaur.doit("123 456 +")'. The
template in the second format is used to describe each of the following
arguments. The number of characters in this string must match the number
of remaining arguments. Each character indicates an action:
i push the next arg as an integer on the Forth data stack
c push the next arg as a (char*) string pointer on the data stack
s push two values: a (char*) string pointer, then the string
length
p push the next argument as object pointer on the data stack
r push as object ptr, but also increment its refcount
(Python/Tcl)
e evaluate the next string as Forth
x execute the Forth word indicated by the next integer arg"
--
Reini Urban
http://tv.mur.at/film/
From: Marcel Hendrix
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <9mq5e4$1i1$1@news.IAEhv.nl>
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
From: Bill Zimmerly
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <EAql7.733$ck.33003@sjc-read.news.verio.net>
"Marcel Hendrix" <···@iaehv.iae.nl> wrote in message
·················@news.IAEhv.nl...
>
> 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
My preferred style is vertical....
: bar/baz ( -- )
foo
if
s" bar"
else
s" baz"
then ;
(Hoping that this survives the way newsreaders alter text! :)
--
- 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
From: Andreas Klimas
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3B90D203.808E6F33@k-r.de>
Erann Gat wrote:
>
> "Elizabeth D. Rather" <·······@forth.com> wrote in message news:<·················@forth.com>...
> > Erann Gat wrote:
> >
> > > > I've cross posted this to comp.lang.forth since Forth
> > > > programmers will want to read and comment on it. You are right.
> > > > Forth programs are "pretty notorious for being hard to
> > > > maintain". This is not the fault of the Forth language. It is
> > > > the fault of Forth programmers and the people who hire them. You
> > > > indicate the reason very clearly when you state "Forth
> > > > programmers are almost as hard to find as Lisp programmers", so
> > > > when an old Forth program needs to be updated, all heck breaks
> > > > loose, since there is usually nobody around who knows how to
> > > > program in Forth.
> > >
> > > I think there's more to it than that. Forth functions don't have
> > > named argument lists, and no clear delineation of block structure.
> > > (At least this was the case at the time. I haven't used Forth in many
> > > years; maybe things are different now.) In other languages you can at
> > > least tell how many arguments you're supposed to pass to a function
> > > just by looking at the code. While I acknowledge that it is possible
> > > to write maintainable Forth I believe it requires more conscious
> > > effort on the part of the programmer than in other languages.
> >
> > It is customary in Forth to follow the name of each new definition
> > by a "stack comment" showing the number, order, and types of
> > stack arguments into and out of that defintion. ANS Forth (1994)
> > gave models for this (and recommended notation) which is widely
> > followed. Responsible Forth programmers (and in my experience
> > most are) regard these comments as just as mandatory as argument
> > lists in other languages, even though most compilers don't enforce
> > the requirement. It is also recommended (and common) practice
> > to add a comment as to intended usage.
>
> 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"
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
* Erann Gat <···@flownet.com> menulis:
| ... The Forth seems pretty cryptic by
| comparison. What's that 'then' doing by itself off at the end?
| Postfix is very unintuitive to most people because it has no analog in
| natural language. You can say "a plus b" to mirror infix, or "the sum
| of a and b" to mirror prefix, but "a and b, the sum of those things"
| sounds awfully contrived.
Actually, natural languages which have SOV (Subject-Object-Verb) word
order are just as common (if not more so!) than SVO languages. Speakers
of these languages would find it more natural to say "a b plus" or "a b
add".
--
Cliff Crawford :: http://www.sowrong.org/
"Sheila can keep the balloons away." -- Thomas
From: Teemu Kalvas
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <87heum4vpx.fsf@gobi.s2.org>
·····@nospam.cornell.edu (Cliff Crawford) writes:
> * Erann Gat <···@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
From: Bernd Paysan
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3B9158DF.FB10E979@gmx.de>
Teemu Kalvas wrote:
> and Chinese (I'm on a weak branch here: I don't know any Chinese and
> am just forwarding from linguistics literature) which is sort of SOV
> now and SVO then.
Chinese is pretty strict SVO, and it must, because there's little other
indication whether a word is verb or not other than the position within
the sentence. However, using terms like "subject", "verb" or "object" is
a bit alien to Chinese, because after all, it's a concatenative language
(like Forth), where you can put words together quite freely, and they'll
make sense, though (what sense depends on the order and somewhat on the
guesswork of the listener).
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
·····@nospam.cornell.edu (Cliff Crawford) wrote in message news:<·························@typhoon.nyroc.rr.com>...
> * Erann Gat <···@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.
From: Bill Zimmerly
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <DJql7.734$ck.33335@sjc-read.news.verio.net>
"Julian Fondren" <············@hotmail.com> wrote in message
·································@posting.google.com...
> [Snip]
> 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.
I enjoy writing on my computer by talking into the microphone using the
"Kurzweil VoicePad".
If either I or the program makes a mistake with a word, I can say
"delete-that" or "take-three" to change the word that was just entered.
The "subject, verb" order seems to me to be the most natural way of
communicating. Especially when after-the-fact editing is necessary.
Simplicity rules! :)
--
- 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
From: Jerry Avins
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3B96CDA4.9C86D758@ieee.org>
Bill Zimmerly wrote:
>
...
>
> The "subject, verb" order seems to me to be the most natural way of
> communicating. Especially when after-the-fact editing is necessary.
>
About Face
Forward March
Eyes Right
Present Arms
There seems to be some flexibility.
Jerry
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
From: Bruce R. McFarling
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3b96ed90.1100800@news.newcastle.edu.au>
On Wed, 05 Sep 2001 21:13:08 -0400, Jerry Avins <···@ieee.org> wrote:
>Bill Zimmerly wrote:
>>
> ...
>>
>> The "subject, verb" order seems to me to be the most natural way of
>> communicating. Especially when after-the-fact editing is necessary.
About Face -- adverb verb, no subject
Forward March -- adverb verb, no subject
Eyes Right -- no verb at all, no subject
Present Arms -- verb object, no subject
Clearly, the most natural for ordering people (or things) around is:
{subject implicit} adverb verb object adjective
>There seems to be some flexibility.
"Computer, plot a course to Rigel 12."
Obviously the presentation should match StarTrek Next Generation
Computerspeak. It makes it much easier to put the training film
together.
From: Kent M Pitman
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <sfwpu95xb5j.fsf@world.std.com>
[ replying to comp.lang.lisp only
http://world.std.com/~pitman/pfaq/cross-posting.html ]
······@ecbm.at.cc.newcastle.edu.au (Bruce R. McFarling) writes:
> On Wed, 05 Sep 2001 21:13:08 -0400, Jerry Avins <···@ieee.org> wrote:
>
> >Bill Zimmerly wrote:
> >>
> > ...
> >>
> >> The "subject, verb" order seems to me to be the most natural way of
> >> communicating. Especially when after-the-fact editing is necessary.
>
> About Face -- adverb verb, no subject
> Forward March -- adverb verb, no subject
> Eyes Right -- no verb at all, no subject
> Present Arms -- verb object, no subject
Actually, if you look to US Army FM22-5 (or whatever they're replaced
it with since I was in JROTC umpteen years ago), it is not useful to do
this analysis. Military marching commands have only two parts, which are
not noun/verb/subject/etc. They are "preparatory command" (About, Forward,
Eyes, and Present in the above though those same words could take on other
functions in other situations) and "command of execution (Face, March,
Right, and Present). Indeed, had you said "Right FACE", Right would have
been a preparatory command, not a command of execution. But the point is that
its English part of speech is irrelevant. You could make up any set of words
such as "Frotz FRIZZLE" and teach it to a military person and they would
accept it as legitimate. What makes the preparatory command what it is
is that (a) it is perfix, and that (b) it is said in a drawn out tone to get
the attention of people and to reduce the set of possible next words by a
sufficient amount that when the next word is said crisply it can be executed
with reasonable enough efficiency that there isn't a deciphering delay and
that all troops will operate as a unit. In that sense, the prefix command
is closer to a hash code than a part of speech...
Btw, Square Dancing calls work likewise.
From: David Douthitt
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3B9696C0.4E12CB2A@mailbag.com>
Julian Fondren wrote:
> 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.
OR is it "object, method" :-) Maybe the Real World is written in
Smalltalk....
From: Jerry Avins
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3B912002.89AA9880@ieee.org>
Erann Gat wrote:
>
...
>
> Forth: (forgive me if I get the details wrong here, my Forth is
> rusty)
> foo if "bar" print else "baz" print then
>
Only a bit of rust, but let's polish it"
foo if "bar" else "baz" then print
>
> ... The Forth seems pretty cryptic by
> comparison. What's that 'then' doing by itself off at the end?
Does "then" still seem misplaced?
...
It really is a matter of knowing the language. Etiquette is a perfectly
good word both in French and in English. However, the two meanings
differ greatly. The meaning of "then" in Forth is altogether different
from it's meaning in, say, BASIC, even though both meanings have their
root in English. The meaning most programmers expect is consequence:
IF the moon is made of green cheese, THEN I'm a monkey's uncle. Laugh.
Forth, being simpler, omits the "con", and uses "then" merely to
indicate sequence:
IF the moon is made of green cheese, I'm a monkey's uncle. THEN laugh.
THEN in Forth is similar to CONTINUE in Fortran. Strangeness is a
consequence of unfamiliarity.
Jerry
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
From: Bruce McFarling
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3b91d4dc.21063398@seagoon.newcastle.edu.au>
On 31 Aug 2001 21:55:47 -0700, ···@flownet.com (Erann Gat) wrote:
>Forth: (forgive me if I get the details wrong here, my Forth is
>rusty)
>foo if "bar" print else "baz" print then
>The Forth seems pretty cryptic by comparison. What's that 'then'
>doing by itself off at the end?
Try presenting the others unstructured, or presenting the Forth
structured. You convey the structure (to the uninitiated) in others
with layout, but not with Forth. Say
foo if
"bar" print
else
"baz" print
then
and even if the then at the end is clearly not what you are expecting,
it IS fairly clearly the end of structure word to someone used to
structured languages in general.
(
----------
Virtually,
Bruce McFarling, Newcastle,
····@cc.newcastle.edu.au
)
From: Erik Naggum
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3208432857653037@naggum.net>
* Erann Gat
> The Forth seems pretty cryptic by comparison. What's that 'then' doing
> by itself off at the end?
Pardon me, but when you learn a language, you learn a language, and when
you know a language, you know a language. It really is this trivial.
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?
///
Erik Naggum <····@naggum.net> wrote in message news:<················@naggum.net>...
> * Erann Gat
> > The Forth seems pretty cryptic by comparison. What's that 'then' doing
> > by itself off at the end?
>
> Pardon me, but when you learn a language, you learn a language, and when
> you know a language, you know a language. It really is this trivial.
The question at hand was why Forth is *perceived* by some people as
being hard to maintain. I didn't mean to say that Forth *was*
objectively cryptic. I was merely engaging in (admittedly poorly
informed) speculation about why some people might find it cryptic.
> If you neither learn it nor know it, what business do you have commenting
> on it at all?
I believe that people have the right to make statements about things
even if they aren't authorities. But just to set the record straight:
I haven't used Forth in many years. I cannot comment on Forth
authoritatively. Nothing that I say about it should be taken as
anything other than poorly informed opinion. OK?
BTW, since my last posting I've learned that there are natural
languages that map onto Forth better than English, so I'll amend my
earlier statement: Postfix might be less intuitive for English
speakers than prefix or infix because it doesn't map as easily onto
English grammar.
E.
From: Erik Naggum
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3208462658937033@naggum.net>
* Erik Naggum
> If you neither learn it nor know it, what business do you have commenting
> on it at all?
* Erann Gat
> I believe that people have the right to make statements about things even
> if they aren't authorities.
Fine with me, but you are not arguing against what I said, which was not
about "authority", but about learning and knowing a language before you
speak about it. 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.
///
Erik Naggum <····@naggum.net> wrote in message news:<················@naggum.net>...
> * Erik Naggum
> > If you neither learn it nor know it, what business do you have commenting
> > on it at all?
>
> * Erann Gat
> > I believe that people have the right to make statements about things even
> > if they aren't authorities.
>
> Fine with me, but you are not arguing against what I said, which was not
> about "authority", but about learning and knowing a language before you
> speak about it.
Wow, three non-sequiturs in one sentence. That's got to be some kind
of record.
1. You're right, I wasn't arguing against what you said. So?
2. Fine. I believe people have a right to talk about things about
which they know absolutely nothing. I believe people have a right to
talk about anything they want to. So?
3. I wasn't actually talking about the language, so everything you
said is irrelevant. I was talking about people's perception of the
language, which is not the same thing.
E.
From: Colin Paul Gloster
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <slrn9pc7mh.t7j.Colin_Paul_Gloster@camac.dcu.ie>
In article ·····················@naggum.net , Erik Naggum wrote:
"[..]
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
································@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?"))
From: David Douthitt
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3B9697DC.802340E0@mailbag.com>
Erann Gat wrote:
> 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.
Hard to maintain doesn't equal cryptic: people still write APL code;
much of it is maintainable, I'm sure.
Of course, if you demand that your programming language be completely
readable, then you should be using COBOL (which I, for one, don't
dislike as much as most people!).
PERFORM LONG-RUNNING-ROUTINE.
IF EXCHANGE-RATE GREATER THAN LIMIT
DISPLAY ERROR.
Of course, COBOL (at least of ages past) had the problem of scope - one
couldn't have a if-then inside of a if-else-then without an unseemly:
ELSE
NEXT SENTENCE.
...but anyway.
From: Elizabeth D. Rather
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3B96AC1C.2E716879@forth.com>
David Douthitt wrote:
> Of course, if you demand that your programming language be completely
> readable, then you should be using COBOL (which I, for one, don't
> dislike as much as most people!).
>
> PERFORM LONG-RUNNING-ROUTINE.
> IF EXCHANGE-RATE GREATER THAN LIMIT
> DISPLAY ERROR.
Aaaargh, you bring back unhappy memories of the year I spent in a COBOL
shop. The problem is, nobody I knew wrote it like that. It was more like:
PERFORM LNG-RN-RTN7.
IF EX-RT-TMP GREATER THAN EX-LMT-HI
...
..and you couldn't make heads or tails of it.
Let's hear it for the folks in this thread who were praising clear
naming conventions!
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."
================================================
In article <····························@posting.google.com>, Erann Gat wrote:
>"Elizabeth D. Rather" <·······@forth.com> wrote in message news:<·················@forth.com>...
>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.
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?''
On Mon, 03 Sep 2001 00:15:55 GMT, Kaz Kylheku wrote:
>In article <····························@posting.google.com>, Erann Gat wrote:
>>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! :)
:-)
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
From: Kurt B. Kaiser
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3B93C5C9.F292D9B2@shore.net>
Kaz Kylheku wrote:
> Sure it does, topicalization: movement of syntactic units to the front
> of a clause. Speak like Yoda, you soon will! :)
EXTERIOR: DAGOBAH--DAY
With Yoda strapped to his back, Luke climbs up one of the many thick vines
that grow in the swamp until he reaches the Dagobah statistics lab.
Panting heavily, he continues his exercises--grepping, installing new
packages, logging in as root, and writing replacements for two-year-old
shell scripts in Python.
YODA: Code! Yes. A programmer's strength flows from code
maintainability, but beware of Perl. Terse syntax... more than one
way to do it... default variables. The dark side of code
maintainability are they. Easily they flow, quick to join you when
code you write. If once you start down the dark path, forever will
it dominate your destiny, consume you it will.
LUKE: Is Perl better than Python?
YODA: No... no... no. Quicker, easier, more seductive.
LUKE: But how will I know why Python is better than Perl?
YODA: You will know. When your code you try to read six months from now.
-- Lorrie Wood
Hmmm. Harumph.
--
K u r t B. K a i s e r
k b k @@ s h o r e .. n e t
------------------------------
···@ashi.footprints.net (Kaz Kylheku) wrote in message news:<························@news1.rdc1.bc.home.com>...
[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.
From: Bruce McFarling
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3b947b99.23710839@seagoon.newcastle.edu.au>
On 3 Sep 2001 22:03:20 -0700, ···@flownet.com (Erann Gat) wrote:
>> 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,
····@cc.newcastle.edu.au
)
From: Neil Bawd
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <B7BA3694.1E1C9%neilbawd@earthlink.net>
Long ago I read that a word in a programming language should be What it
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 ········@earthlink.net
)
From: Anton Ertl
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <9n02dl$cpe$2@news.tuwien.ac.at>
In article <····························@posting.google.com>,
···@flownet.com (Erann Gat) writes:
>foo if "bar" print else "baz" print then
...
> The Forth seems pretty cryptic by
>comparison. What's that 'then' doing by itself off at the end?
That's a FAQ, of course, and the answer is:
5.4. Why does THEN finish an IF structure?
Some people find the way THEN is used in Forth unnatural, others do
not.
According to Webster's New Encyclopedic Dictionary, "then" (adv.) has
the following meanings:
2b: following next after in order ... 3d: as a necessary
consequence (if you were there, then you saw them).
Forth's THEN has the meaning 2b, whereas THEN in Pascal and other pro-
gramming languages has the meaning 3d.
If you don't like to use THEN in this way, you can easily define ENDIF
as a replacement:
______________________________________________________________________
: ENDIF POSTPONE THEN ; IMMEDIATE
______________________________________________________________________
See my .sig for answers to other c.l.f FAQs.
Followups to clf.
- 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
From: Elizabeth D. Rather
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3B951686.244B6B72@forth.com>
Erann Gat wrote:
> >...
> Forth: (forgive me if I get the details wrong here, my Forth is
> rusty)
> foo if "bar" print else "baz" print then
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."
================================================
From: Fred Warren
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <B5el7.543$gF3.92574881@twister1.starband.net>
Erann Gat wrote:
> 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
From: Marco Antoniotti
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <y6csne1vkjy.fsf@octagon.mrl.nyu.edu>
Fred Warren <·······@efn.org> writes:
> Erann Gat wrote:
>
> > 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.
Except that
1 - Lispers don't see the parenthesis
2 - the Lisp, C, and Forth version still work.
3 - the Python (tllotbafir) version does not work anymore
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'.
From: Erik Winkels
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <87k7zdlkla.fsf@xs4all.nl>
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Fred Warren <·······@efn.org> writes:
>>
>> Let's take a look at these four examples with the whitespace
>> removed, after all, the compiler __does not care__.
What silly games these are. What is the point of this?
This is just a Dick Size War that'll end in "my daddy is stronger than
yours" and references to sixty years ago.
>> 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.
To me the Lisp version is the easiest to read and that is the only
thing this thread illustrates: if one is familiar with a language
it'll probably be pretty understandable. (Gee, what a suprise!)
> 3 - the Python (tllotbafir) version does not work anymore
^^^^^^^^^^
ROT13(tllotbafir) makes even less sense. What does it mean?
Cheers,
Erik.
From: David Douthitt
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3B9699A4.A6E8CD84@mailbag.com>
Fred Warren wrote:
> Lisp, C and such are hard to read, in the sense that you must play the
> "match the parens game"
Not really. In fact, this makes it EASIER to read: if you have to match
a paren or bracket, just use % and instantly you are taken to the
match. These parens and brackets also explicitly define WHERE the
blocks are, and they aren't hidden or assumed.
(c.l.forth reinstated, IMO it's at least as relevant)
Fred Warren <·······@efn.org> wrote :
...
> 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.
>
Several recent languages, maybe, if you just mean
case-insensitivity. Pretty much everything that existed
(or descends from) before the mid'70s is case-insensitive:
FORTRAN (now Fortran), COBOL, PL/1, Pascal, BASIC
as well as LISP and FORTH; for the very good reason that
nearly all computer peripherals then were uppercase only.
(Yeah there were Flexowriters and 2741s/1050s, but few.)
In the early days of Unix, there were incredibly
bletcherous hacks in the tty driver(s) to "support"
mixed case on uppercase-only devices.
Ada is also insensitive, perhaps following the majority.
In all these languages you can now (on bothcase gear)
if you like write keywords, builtins, etc. uppercase
and user identifiers in lowercase. Or vice versa,
for that matter. The GNU Ada compiler gnat has
options to check you are _consistent_ about case.
If you mean having the user select sensitive or not,
that is much rarer.
--
- David.Thompson 1 now at worldnet.att.net
From: Knud Werner
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <3B8FF953.BC7AFCF2@probits.de>
"Elizabeth D. Rather" wrote:
> It is customary in Forth to follow the name of each new definition
> by a "stack comment" showing the number, order, and types of
> stack arguments into and out of that defintion. ANS Forth (1994)
> gave models for this (and recommended notation) which is widely
> followed. Responsible Forth programmers (and in my experience
> most are) regard these comments as just as mandatory as argument
> lists in other languages, even though most compilers don't enforce
> the requirement. It is also recommended (and common) practice
> to add a comment as to intended usage.
<snip>
> The point being, that "readability" of any language requires some
> familiarity with that language.
As it seems to me, most programmers - and this might be independent
of the language used - have an imperfect understanding of readabilty
and it's importance in software engineering. IMHO many programmers
understand readabilty as "feed to the compiler without errors" and
take different attitudes about warnings or complains ;-)
I personally consider code being well written if it is short, efficient
and factored. Efficient implies correct and effective. Such code might
not be the most easiest to write, but seems to be the most easiest to
read.
The point being, that the intended audience for my code are humans,
either myself (fixing some stupid but well hidden bugs of mine several
month after launching) or the other programmers maintaining or
developing it.
I believe that code which is short, efficient and factored - in one
word:
human-readable - is much easier to maintain and develop than utterly
complex
nests of goto's, but I'm accustomed to see much more of the latter, and
that seems not to depend on the language used.
I think Forth is at least as well prepared to produce readable code as
any other of the dozen or so languages I'm more or less familiar with,
but I also think that's it's all in the hand of the programmer himself,
ie. the maintainabilty - and therefore the total cost - of software
depends
NOT on the language, but how it's used.
Regards, Knud
From: Anton Ertl
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <9n0216$cpe$1@news.tuwien.ac.at>
In article <····························@posting.google.com>,
········@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
From: Thomas F. Burdick
Subject: Re: Maintaining Minority Languages ( was Re: A small survey (if you have couple of minutes))
Date:
Message-ID: <xcvelpodrr1.fsf@conquest.OCF.Berkeley.EDU>
·····@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> Concerning maintainability, the Elisp version was hard to adapt to
> changing needs; I attribute this to the design and style of the
> program: I tried to keep to a functional style, but apparently did so
> in the wrong way, and changes typically required passing stuff across
> a number of functions and the additional data could not be just tacked
> on existing data, so it required additional parameters. You can
> attribute this to my inexperience in Lisp (or maybe just a bad design
> decision in general), but if I was after a flamewar, I would attribute
> it to Lisp:-).
>
> The Forth version uses about a dozen global variables for these tasks,
> and was easier to maintain for a long time (contrary to established
> wisdom about global variables). But of course in the end I wanted to
> do a change for which the global variables proved to be a problem, and
> now the Forth version is quite messy. I believe that the original
> functional approach would not have survived that change at all, though.
If global variables are used to maintain global state, I don't see any
problem with them. Like almost every other programming tool with a
bad reputation, their infamy comes from misuse. FWIW, it sounds like
you just wanted to use global (or maybe buffer-local) variables in the
Elisp version -- something that's done all the time.
On 27 Aug 2001 20:34:58 -0700, ···@flownet.com (Erann Gat) wrote:
> ··················@ACM.org (Colin Paul Gloster) wrote in message news:<·································@camac.dcu.ie>...
> > In article <····························@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?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
Paolo Amoroso <·······@mclink.it> wrote in message news:<····························@4ax.com>...
> On 27 Aug 2001 20:34:58 -0700, ···@flownet.com (Erann Gat) wrote:
>
> > ··················@ACM.org (Colin Paul Gloster) wrote in message news:<·································@camac.dcu.ie>...
> > > In article <····························@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.
···@flownet.com (Erann Gat) writes:
> Yep. And the target processor (the one actually in the instrument)
> was (and still is ;-) an 1802 with 4k bytes of RAM, 2k of which were
> data buffer. (There is also a 4k ROM.)
>
Heh. I have fond memories (alas, undocumented) of working soemwhere
where an 1802-based instrument was being considered by the US DoD.
They tried to insist that the code, to meet DoD standards, should be
either in Ada or FORTRAN 77. I think it had 1 or 2k bytes of ROM full
(really, full: adding new functionality meant reducing the size of
old) of very carefully-written assembler at that point and maybe some
hundreds of bytes of RAM. I think they relaxed the constraint...
--tim