Lisp considered unfinished
Dave Yost
David Neves <ne...@ils.nwu.edu> wrote:
>In article <hbaker-0206...@192.0.2.1>, hba...@netcom.com (Henry
>Baker) wrote:
>
>: From the anonymous reviews of a recent NSF proposal in which Lisp was
>: mentioned, but only as an incidental tool:
>:
>: "The LISP environment is really getting out of date as a viable system
>: environment. Let us not pursue this line of research any more."
>
>Amazing. Anything should be allowed as an incidental tool. A researcher
>has to pick the best language for his or her group. Groups put a lot of
>effort in developing a good tool set for the language they work with. For
>an external reviewer to base his/her decision on an incidental tool is
>stepping out of bounds. Faulting a dynamic language is being particularly
>insensitive to prototyping needs of research. The reviewer is probably
>someone who still views Lisp as the Lisp 1.5 that some programming
>language texts cover.
Denial.
I think Lisp implementers should take this as a wake-up call.
There are other warnings.
* Lucid went out of business
* CMUCL was abandoned, and the people are working on Dylan
* MCL was abandoned for 2 years before being revived
* The GARNET project has left lisp behind and has gone to C++.
It's now 3 times faster, and more people are interested in it.
Surely there are many others.
As far as I can tell, ANSI lisp is being treated as a huge
plateau, as if there is nothing interesting left to do, or
as if any further changes would be too hard to negotiate.
What about speed? size? C/C++ interoperability?
These issues have been untreated emergencies for some years now.
Dave Yost
@ .com
Philip Jackson
: In article <neves-02069...@neves.ils.nwu.edu>,
: David Neves <ne...@ils.nwu.edu> wrote:
: >In article <hbaker-0206...@192.0.2.1>, hba...@netcom.com (Henry
: >Baker) wrote:
: >
: >: From the anonymous reviews of a recent NSF proposal in which Lisp was
: >: mentioned, but only as an incidental tool:
: >:
: >: "The LISP environment is really getting out of date as a viable system
: >: environment. Let us not pursue this line of research any more."
: >
: >Amazing. Anything should be allowed as an incidental tool. A researcher
: >has to pick the best language for his or her group. Groups put a lot of
: >effort in developing a good tool set for the language they work with. For
: >an external reviewer to base his/her decision on an incidental tool is
: >stepping out of bounds. Faulting a dynamic language is being particularly
: >insensitive to prototyping needs of research. The reviewer is probably
: >someone who still views Lisp as the Lisp 1.5 that some programming
: >language texts cover.
Since the reviewer was anonymous it is particularly hard to draw conclusions
about whether they view Lisp as Lisp 1.5, or to verify such conclusions.
Possibly the anonymous reviewer had a very clear understanding of the
current state of Lisp, but was concerned about the issues of viability that
Yost mentions.
The sentence quoted is interesting because it seems to mix two concepts:
"Lisp as a viable system environment" and "Lisp as a line of research".
(Of course, the quoted sentence may really be talking about something else
as a line of research, but it brings to mind the idea that Lisp itself
has been developed as a "research language" -- a language for doing
research about AI and other topics, and an environment for doing research
about the design of powerful programming languages.)
Possibly the reason Lisp is in the state is in today is that historically
these concepts have always been mixed, and perhaps not well balanced.
This has led to a language with the perceived efficiency and space
problems that Yost mentions.
: Denial.
: I think Lisp implementers should take this as a wake-up call.
: There are other warnings.
: * Lucid went out of business
: * CMUCL was abandoned, and the people are working on Dylan
: * MCL was abandoned for 2 years before being revived
: * The GARNET project has left lisp behind and has gone to C++.
: It's now 3 times faster, and more people are interested in it.
: Surely there are many others.
: As far as I can tell, ANSI lisp is being treated as a huge
: plateau, as if there is nothing interesting left to do, or
: as if any further changes would be too hard to negotiate.
: What about speed? size? C/C++ interoperability?
: These issues have been untreated emergencies for some years now.
: Dave Yost
Perhaps the solution is to separate the concepts, not mix them, and
focus development of Lisp along three parallel paths:
1) Lisp as a viable system development platform. A subset of CLOS
that can be implemented with small memory requirements, compiles just as
efficiently as C, yet retains more value than C or C++ in terms of
productivity and built-in language constructs. This could be very
attractive to current systems developers. It might even resemble
Lisp 1.5 ;)
2) Lisp as a language for research projects. Perhaps the full CLOS as
we know it, or perhaps CLOS extended along lines that support particular
topics in AI research.
3) Lisp as a language for research about programming languages.
Phil Jackson
Dave Dyer
I have to agree with Dave Yost; In many respects, modern C/C++/Visual
Basic development environments rival or exceed the best lisp has to
offer. The underlying language is still crap, but the gloss on top of
it demos really well; and truthfully, goes a long way toward improving
productivity.
Despite many millions that went into Symbolics, LMI, TI and Xerox
(both directly and to their customers) there is not *ONE* really well
known "lisp" success story to point to; and on the flip side,
everybody knows how much was invested in those companies, and where
they are now.
The remaining lisp vendors are locked into survival mode, and don't have
the resources or inclination to undertake anything revolutionary. The
supply of new blood from the universities is thin - all the up-and-coming
wizards are into networks and multimedia.
In short, lisp is well on its way back to where it always was; as an
amusing backwater of the computer industry; of interest only to a few
academics trying to do things that are completely impractical anyway.
--
---
My home page: ftp://ftp.netcom.com/pub/dd/ddyer/home.html
or try http://www.triple-i.com/~ddyer/home.html
Erik Naggum
| Saying "but we've got it right" to each other 1e6 more times isn't
| going to convince anyone new.
but it might convince a person or two to try it out and bring some ideas
back to the other cavemen.
if it weren't for the fact that numerous excellent Lisp systems exist for
my SPARCstation, I would probably have sold the machine and gone fishing
instead of suffering C++ and the general cluelessness of the PC industry.
every week or so, another student at the Department of Informatics at the U
of Oslo shows interest in Emacs Lisp and Lisp programming because some of
us keep posting neat functions in Lisp. there are those who are attracted
to the elegance of Lisp even though there is little paid work to get using
it. come to think of it, this is how many of our best programmers approach
_programming_, not just programming languages.
besides, I couldn't have worked with C++ for a year without Emacs Lisp to
help me write in that language.
#<Erik 3011416721>
--
NETSCAPISM /net-'sca-,pi-z*m/ n (1995): habitual diversion of the mind to
purely imaginative activity or entertainment as an escape from the
realization that the Internet was built by and for someone else.
Martin Brundage
[...]
>In short, lisp is well on its way back to where it always was; as an
>amusing backwater of the computer industry; of interest only to a few
>academics trying to do things that are completely impractical anyway.
How about rapid prototyping? It seems unlikely that C++ will ever meet that
need. C and C++ seem to be more accidents of history than anything else. Does
it ever seem strange to you that nearly everybody is writing apps, both large
and small, in a portable assembler language? Hardware is decreasing in cost
exponentially but software costs (probably) rise. Where do you think the
industry is going to find additional productivity? Delphi?
--
Marty
mar...@ix.netcom.com
Dave Dyer
agreeing with and amplifying the idea that our side isn't winning.
The argument you are making are well known to me, and frequently made
by me; but the fact remains that many $ were spent in persuit of
lisp's supposed virtues, and the wave is visibly receeding.
Saying "but we've got it right" to each other 1e6 more times isn't
going to convince anyone new.
--
Barry Margolin
>Despite many millions that went into Symbolics, LMI, TI and Xerox
>(both directly and to their customers) there is not *ONE* really well
>known "lisp" success story to point to; and on the flip side,
>everybody knows how much was invested in those companies, and where
>they are now.
I believe that quite a bit of the space station code was being developed in
Lisp. At least it was a few years ago; that may have changed.
Another Lisp success story was Desert Storm. Much of the logistics was
done using Symbolics Lisp.
Part of the problem is that Lisp is best suited to large, dynamic
applications like these. For such applications, the overhead that's often
associated with Lisp is not noticeable, while the power and flexibility of
Lisp is incredibly helpful. But before programmers can use Lisp for large
applications they need to get their feet wet on small ones, and Lisp
usually isn't the appropriate language for little applications (the 5MB
"hello world" binary is the usual example). Using Lisp for a little
application is like using a jack hammer when you just need a screwdriver;
but using C for a large application is like trying to break up a sidewalk
with a screwdriver and hammern.
--
Barry Margolin
BBN Planet Corporation, Cambridge, MA
barmar@{bbnplanet.com,near.net,nic.near.net}
Phone (617) 873-3126 - Fax (617) 873-5124
Oliver Laumann
> Don't doubt that I'm on lisp's side, just as you all are. I'm just
> agreeing with and amplifying the idea that our side isn't winning.
I don't believe C/C++ will `win' in the sense that Lisp as an
implementation language will be displaced by C or C++.
Instead, we will see an increasing number of `hybrid' applications
that are written in a mixture of Lisp (or actually a dialect thereof,
such as Scheme) and C or C++.
And it's about time; Emacs has been around for many years, and it
works and has been successful.
We should probably invest more energy in improving language
_integration_ rather than fighting C++ or attempting to develop the
`ultimate' programming language (see the recent thread on the ``Grand
Challenge in Programming Languages'' in comp.lang.functional).
Dave Yost
Lisp is considered too hard for most programmers,
too elegant, too complex, too formal, etc.
A Vice President of a major computer industry company
said this (more or less) to me just the other day.
I think this problem could be solved by
the right book, targeted directly at C programmers.
Lisp is as great as it is because there are many, many
things about Lisp that don't come easily to a C programmer.
Most of them I think are ramifications of the fact that
Lisp is a dynamic environment.
Perhaps someone could do a survey people who still
remember what they went through to transition from C to
Lisp and collect a list of things they found difficult
or hard to get used to.
Dave Yost
@ .com
Dave Yost
>the resources or inclination to undertake anything revolutionary.
This appears not to apply to Harlequin at all.
The revolutionary thing they're undertaking is to develop Dylan.
Dave Yost
@ .com
Patrick Logan
: Lisp is considered too hard for most programmers,
Guess what, from what I've seen during twelve years in the industry,
*programming* is too hard for most programmers.
I am not kidding. Any language. Most can't do it very well,
and I'm tired of dealing with those who can't.
--
Patrick...@ccm.jf.intel.com
Intel/Personal Conferencing
"Form follows function." -Le Corbusier
Luigi Semenzato
We Lisp users are fighting more than a battle between
technologies: it is a struggle of giant viruses that take hold
of our brains and grow within us in irreversible symbiosis.
How often have you asked yourself `is Lisp really that good
or have I been zombified by using it this long?' How often
have you seen someone talk about Prolog with the same inspired
expression you use when you describe some Lisp feature, and
you thought `how can he be so blind?'
Given enough time, people will like even something like C++.
By then, their thinking processes will be so enmeshed with
C++ that not liking C++ would mean not liking their own brain.
I know this happens and it worries me because I am afraid
it's something I cannot rationalize. For instance, I see
people more and more often put C and C++ in the same ballpark.
How can they be so blind? To me C is a small language, with
serious limitations but a precise rationale: easy to learn,
and, within that rationale, quite consistent. C++ on the
other hand feels like the result of carrying that same
rationale into a realm where it no longer makes sense.
But I have programmed in C a lot more than C++. So what
do I know?
I say this because that's how people on the other side see us.
To them we look just as blind as they to us. This is the
fundamental obstacle. It's not object orientation or image
size or programming environment. It's whatever you learn first.
So the only way to make Lisp succeed is to work with Lisp
haters. Learn their language, write good code in it, keep
telling them how much easier this would be in Lisp, sneak
a Scheme interpreter in through the back door. I think we'll
make it. ---Luigi
Dave Yost
Patrick Logan <pdl...@ornews.intel.com> wrote:
>Dave Yost (yo...@Yost.com) wrote:
>
>: Lisp is considered too hard for most programmers,
>
>Guess what, from what I've seen during twelve years in the industry,
>*programming* is too hard for most programmers.
:-) There is truth in what you say.
>I am not kidding. Any language. Most can't do it very well,
>and I'm tired of dealing with those who can't.
There is another side to this story, though.
There are programmers that are so smart and so fast,
that they have little regard for leaving something
clean and readable behind for themselves or others
to develop further. Would you say that programming
is too hard for such a person?
Maybe we should shame all programmers into taking on lisp,
as a test of mental strength, and if they can't hack it
maybe they'll give up and try another line of work.
Hey, maybe management! ;-)
Dave
clar...@iexist.flw.att.com
I agree with the warnings sent by Dave Dyer and most
comments thereafter. However, I think one number is off:
at least one language costs a lot more money to develop than this...
In article <ddyerD9...@netcom.com>, dd...@netcom.com (Dave Dyer) writes:
|> Despite many millions that went into Symbolics, LMI, TI and Xerox
|> (both directly and to their customers) there is not *ONE* really well
|> known "lisp" success story to point to; and on the flip side,
|> everybody knows how much was invested in those companies, and where
|> they are now.
--
----------------
Olivier Clarisse "Languages are not unlike living organisms
Member of Technical Staff can they adapt and improve to survive?"
AT&T Bell Laboratories
Jamie Hamilton
On 6 Jun 1995, Dave Yost wrote:
> Here's another problem that needs solving:
>
> Lisp is considered too hard for most programmers,
> too elegant, too complex, too formal, etc.
> A Vice President of a major computer industry company
> said this (more or less) to me just the other day.
>
Lisp too hard? Have you ever seen the tortured code that even mediocre
C++ programmers puzzle through to get the job done? People who can learn
C++ would (and do) find Lisp a breeze. They would learn it if they knew
they would make more money, and that's all there is to it. Sometimes I
think we should band together and place a large want ad in every major
market:
Programmer's Wanted, $100/hr.
Knowledge of Lisp, C++ required.
Whenever anyone calls up, you just tell them that their Lisp experience
is inadequate. At least it would increase book sales.
Let's face it. Lisp had plenty of interest and venture capital in the
mid-80s. Overall, the companies that emphasized Lisp just didn't deliver.
If Lisp is unpopular, it's not Their fault. It's Our fault.
Clint Hyde
Hubble Telescope planner: written on TI Explorers in late 80s. (no it
wasn't used to design the mirror)
SwissAir: their flight scheduling (?) program, also written on TI
Explorers (I bump into these folks when I try to buy used hardware
sometimes, as they can outbid me).
Chicago Board of Trade: futures trading program, on TI microExplorers.
I don't know where any of them are now.
-- clint
Geoffrey Clements
> In article <3r289d$j...@ornews.intel.com>,
> Patrick Logan <pdl...@ornews.intel.com> wrote:
> >Dave Yost (yo...@Yost.com) wrote:
> >
> >: Lisp is considered too hard for most programmers,
> >
> >Guess what, from what I've seen during twelve years in the industry,
> >*programming* is too hard for most programmers.
>
> :-) There is truth in what you say.
>
I'd say.
I've programmed in a few different langauges and worked with a bunch of
different programmers. I find that too many of those programmers used the
"try stuff until it works" debugging method. They try something. OK that
doesn't work. They try something else. Ok that doesn't work. So they try
something else. That works. Bug fixed. This makes a huge mess of a piece
of software because it turns a relatively straight forward piece of code,
that may have not covered every contingency, into a patchwork of partial
fixes.
I absolutely hate coming onto a project and seeing code like this. In most
cases I end up rewritting huge protions of the code. I usually finish
before someone who is just fixing things because I turn the messy
patchwork into clean simple code and they just fight the patchwork.
> >I am not kidding. Any language. Most can't do it very well,
> >and I'm tired of dealing with those who can't.
>
Me too.
> There is another side to this story, though.
> There are programmers that are so smart and so fast,
> that they have little regard for leaving something
> clean and readable behind for themselves or others
> to develop further. Would you say that programming
> is too hard for such a person?
>
The reason someone is fast is because they are smart. They think about why
a piece of code is not working and then fix it. This way they only have to
fix the problem once. This makes them fast. They don't use clever hacks
because they are too hard to understand in a glance. They don't use fancy
constructs because they are too hard to understand in a glance. They use
the simplest code that solves the problem.
I don't find programming in any one language harder than any other. I find
programming in a particular implementation harder than another. I also
find that some problems take longer to solve in one langauge than another.
I find having to deal with all of the details of memory management in C to
be a pain in the butt. Sometimes I feel like I'm writing the same code
over and over. On the other hand trying to poke around in the internals of
the OS from Lisp is a pain in the butt. (Some Lisps are better at this
than others but doing it in C is easier. At least I find it so.)
> Maybe we should shame all programmers into taking on lisp,
> as a test of mental strength, and if they can't hack it
> maybe they'll give up and try another line of work.
> Hey, maybe management! ;-)
>
Actually I found learning Lisp a lot easier than C++. Not because learning
the syntax of C++ is difficult but because it took me a while to really
get the mindset for working with objects. (Just compiling C code with your
C++ compiler doesn't count as programming in C++) Someone told me to go
program in Smalltalk for a while and objects will fall into place. I
didn't listen and so it I had to struggle longer than neccesary.
I've found Lisp one of the easier languages to work with. Some of the
reason is the excellent environment that comes with Macintosh Common Lisp
and some of it is because I don't find myself programming details as much
as much as I do in C.
> Dave
--
geoff Geoffrey P. Clements
Senior Software Engineer Mac Software Guy
Kodak Electronic Printing Systems KEPS, Inc.
gcle...@keps.com Voice: (508) 670-6812
David B. Lamkins
If you believe Harlequin's own promotional materials, the sale of development
systems is not their primary business. To them, Lisp seems to be a tool that
supports other aspects of their business (large custom systems) -- the fact
that they can sell some copies is probably icing on the cake, assuming that
support costs don't become prohibitive...
Dave
http://www.teleport.com/~dlamkins
---
CPU Cycles: Use them now, while you still have them.
David B. Lamkins
>(was: Lisp considered unfinished)
>
>We Lisp users are fighting more than a battle between
>technologies: it is a struggle of giant viruses that take hold
>of our brains and grow within us in irreversible symbiosis.
>
>How often have you asked yourself `is Lisp really that good
>or have I been zombified by using it this long?' How often
>
>Given enough time, people will like even something like C++.
>By then, their thinking processes will be so enmeshed with
>C++ that not liking C++ would mean not liking their own brain.
Yes, there's a strong leaning toward one's favorite language, and
yes it does color one's perceptions of other languages, particularly
those that are a sufficient "distance", cognitively, from familiar
territory.
What's really frustrating is that the cross-pollination of ideas is
so pathetically slow, mostly because people's natural tendency is to
block out anything far from their self-perceived norm... That's why
C++ users absolutely fawn over new clever ways of writing data structures
like (to quote an example from a magazine that crossed my desk today)
"arrays of arrays" -- a big yawn to Lispers. On the other side, I'd
kill for a really natural interface to the underlying OS, or a GUI
framework as robust as those taken for granted by C++ users.
Even languages as conceptually close as Common Lisp and Scheme suffer
from the cognitive gap. And as a Lisper, how well do you think Dylan's
infix syntax (an idea being reborn for the Nth time in a Lispy language)
will fare with die-hard Lispers?
>I say this because that's how people on the other side see us.
>To them we look just as blind as they to us. This is the
>fundamental obstacle. It's not object orientation or image
>size or programming environment. It's whatever you learn first.
>
>So the only way to make Lisp succeed is to work with Lisp
>haters. Learn their language, write good code in it, keep
>telling them how much easier this would be in Lisp, sneak
>a Scheme interpreter in through the back door. I think we'll
>make it. ---Luigi
I don't think Lisp will fade away. It hasn't so far. Neither has
FORTRAN or COBOL. I think it may be a mistake to compare Lisp to
the commercial languague du jour. These things go in cycles. How
long ago was it that you could find a thriving Pascal marketplace?
The real question, IMO, is whether Lisp can survive as a viable
business for the remaining vendors. To do this, we need to talk
more about our own use of Lisp in revenue-producing products.
Bradford Miller
<dlam...@teleport.com> wrote:
> What's really frustrating is that the cross-pollination of ideas is
> so pathetically slow, mostly because people's natural tendency is to
> block out anything far from their self-perceived norm... That's why
> C++ users absolutely fawn over new clever ways of writing data structures
> like (to quote an example from a magazine that crossed my desk today)
> "arrays of arrays" -- a big yawn to Lispers. On the other side, I'd
> kill for a really natural interface to the underlying OS, or a GUI
> framework as robust as those taken for granted by C++ users.
Don't look at it as something frustrating, look at it as a career opportunity.
Yes, you can take those 20 year old results from Lisp, and republish them
as "new" C++ results! Academic careers are made in this fashion (hint: you
don't have to be the author of the original result, just able to read it
and translate to the language de jour).
Look, for instance, at all the "numerical methods for C" type books that
are republications of code written originally in Fortran in the 60s....
Here's the trick to maintain academic honesty while seeming completely original:
write a TR with full references to the lisp literature, then write your paper
for whatever C++ conference you like, but only reference your TR. Nobody will
ever bother getting the TR but other university types, and WHO CARES, you're
after the real job in industry that pays 6 figures, not a publish or perish
rathole that barely covers rent. Of course, even if you want to go in that
direction, there's only about 45 years of lisp results waiting to be
republished in C++ journals.
Remember that nobody reads anything that isn't "in their language", be it
computer programming or political spectrum. There's millions of ideas most
people will never bother trying to adapt to their own technology, because
they can't be bothered to learn to look under the surface syntax.
That's the secret to good research methodology, btw, think of how the same
problem might have come up in a different area, then see how they solved it.
Bruce O'Neel
> success stories:
>
> Hubble Telescope planner: written on TI Explorers in late 80s. (no it
> wasn't used to design the mirror)
>
To the best of my knowledge:
The program's called spike and it runs on more than one commercial lisp
system. It was used for scheduling on the Japanese X-RAY ASCA mission (an
X-RAY telescope) and will also be used for the US XTE mission (another
X-RAY telescope).
bruce
John Doner
Barry Margolin <bar...@nic.near.net> wrote:
>But before programmers can use Lisp for large
>applications they need to get their feet wet on small ones, and Lisp
>usually isn't the appropriate language for little applications (the 5MB
>"hello world" binary is the usual example).
Hear, hear. I would like to add the perspective of a professor who
would like to teach Lisp dialects to students of math and computer
science, but who has trouble making it work. An important part of
the problem is the size and complexity of the environment within
which the learner must learn. Since students' computers are apt to
be small, maybe slow, this is a big obstacle. So is cost. (Gambit
scheme solves the cost problem, maybe the size problem, and part of
the complexity problem, so I do use that.) But there are other
serious obstacles.
The first is comprehensibility. In the case of Lisp, there is the
sheer size of the language. It prevents all but a few from ever
getting a feeling that they have really mastered it; in fact, it
leaves most with the sense that they have only scratched the
surface. Scheme is much better here.
Then there is the problem of abstractions. Lambda, one of the key
things that makes Lisp & friends so nifty (you can make functions
on the fly, have functions returning other functions, create
closures, etc.) is a DIFFICULT CONCEPT. Look folks, we have
trouble teaching them what ordinary mathematical functions are, let
alone functions of higher type (a.k.a functionals or operators).
(Actually, I have hopes that teaching a Lisp dialect will help
students learn mathematical concepts! So I'm not objecting to
abstractions, I'm only pointing out that for the beginning
programmer they're a source of difficulty and complexity that must
be addressed.)
Another aspect of comprehensibility: In my view, most people reach
an understanding of how a programming language "works" by
constructing a mental model of the computer and how it executes the
statements of the language. C is close to an assembly language, so
the mental models (which change as learning occurs) reach a good
approximation of reality in a relatively short time, and thus serve
as reliable predictors of what a particular piece of code is going
to do. The reality of Lisp implementations is relatively
complicated, and the mental model must also be more complicated. I
spend some effort explaining "how it all works" to students, but
however useful this may be, it does add an extra layer of
complexity.
There is the problem of efficiency. I don't mean whether the
compiler can generate fast code. The problem is seeing whether one
has written good code or not. It is hard to tell. I have a friend
who maintains a large Lisp program written years ago by others.
Often, he comments on what poor code is there, and he improves it.
But the original coders were hardly Lisp neophytes; why didn't they
see how bad the stuff they were writing really was?
Program size: as Barry notes, even "hello world" can be huge. How
important do you suppose it is that student programmers and other
learners be able to create small programs that they can pass around
to friends? Some don't care but many do. If I write a piece of
Lisp code for some simple string manipulation, I may find it very
useful myself, but I might actually be embarrassed to offer the
complete stand-alone application to anyone unfamiliar with Lisp.
Accessibility: Good C compilers are available, are cheap, and fit
on relatively small student-owned machines. Having your own system
on your own machine is a big plus for anyone learning a language.
It isn't a requirement, but it helps.
Debugging: Most Lisps have pretty serviceable debugging tools. But
what if your code breaks something at a low level? It's pretty
easy to tell what piece of C source some assembly code corresponds
to, but not so for Lisp. And there are other difficult situations:
I've been scratching my head for a while over one where the
compiler chokes on code produced by several layers of interacting
macros. It is bewildering trying to figure out where this code
originally came from!
John Doner
John Doner
Barry Margolin <bar...@nic.near.net> wrote:
>But before programmers can use Lisp for large
>applications they need to get their feet wet on small ones, and Lisp
>usually isn't the appropriate language for little applications (the 5MB
>"hello world" binary is the usual example).
Hear, hear. I would like to add the perspective of a professor who
would like to teach Lisp dialects to students of math and computer
science, but who has trouble making it work. An important part of
the problem is the size and complexity of the environment within
which the learner must learn. Since students' computers are apt to
be small, maybe slow, this is a big obstacle. So is cost. (Gambit
scheme solves the cost problem, maybe the size problem, and part of
the complexity problem, so I do use that.) But there are other
serious obstacles.
The first is comprehensibility. In the case of Lisp, there is the
sheer size of the language. It prevents all but a few from ever
getting a feeling that they have really mastered it; in fact, it
leaves most with the sense that they have only scratched the
surface.
Then there is the problem of abstractions. Lambda, one of the key
things that makes Lisp & friends so nifty (you can make functions
on the fly, have functions returning other functions, create
closures, etc.) is a DIFFICULT CONCEPT. Look folks, we have
trouble teaching them what ordinary mathematical functions are, let
alone functions of higher type (a.k.a functionals or operators).
(Actually, I have hopes that teaching a Lisp dialect will help
students learn mathematical concepts! So I'm not objecting to
abstractions, I'm only pointing out that for the beginning
programmer they're a source of difficulty and complexity that must
be addressed.)
Yet another comprehensibility issue: I believe that most people
reach an understanding of how a programming language "works" by
constructing a mental model of the computer and how it responds to
language constructs. This model changes as learning occurs. In
the case of C, the language is close to the hardware, and it is
relatively easier to arrive at a mental model that is a serviceable
approximation to reality. But the reality of Lisp implementations
is much more complicated, and calls for a more complicated mental
model. So students spend more time blundering around, wondering
why things happen the way they do. I spend some time explaining
"how it all works", but there's little doubt that this adds to the
perceived complexity of the whole experience.
55437-olivier clarisse(haim)463
In article <hbaker-0706...@192.0.2.1>, hba...@netcom.com (Henry Baker) writes:
[...]
|> Remember garbage collection? Remember interpreters and incremental
|> debugging? Remember incremental compilers? Remember incremental loading?
|> (I could go on for _days_.)
|>
|> People complain about 5 Megabyte 'hello world' programs. Have you ever
|> measured the size of a RISC 'hello world' program that runs on a GUI
|> interface these days, with X-Windows (or equivalent), etc., etc.? You
|> might be shocked and amazed.
|>
|> The 8 Mbyte main memories required to run Lisp Machine Lisp grossed everyone
|> out in 1980. But look at what it takes to run MS Windows these days!
|> 16 Mbytes! So it isn't the _language_ that cost all of the memory, but
|> the _functionality_. And I'll bet that Lisp was at least an order of
|> magnitude more efficient in its use of that memory than MS Windows is.
|>
Way to go! You're right on target. I remember the 7Bytes lisp images
on Xerox Dandelions 11 years ago containing all the functionality
of todays MS Windows including + most of its applications and a lot more
(including the ability to crash). These had ethernet, TCP/IP, FTP, WISYWIG
text editors, PostScript printing (actually called Interpress?).
So who needed to invent CORBA (today) when you could distribute objects
(agents) on a network of Lisp machines 10 year ago, plus you could use
TeleRaid and friends to remotely debug OO software distributed across
the network. I really thought these concepts would take over the
world of computing... And yes they did. I have seen every single successful
software vendor steal these concepts one by one, canibalize them and
make them so huge ever since.
Heck, Xerox invented fast windows on CPUs that probably were
20 times slower than the Pentium and at a time when having a 20MBytes hard
drive was a luxury! And look what happened to X windows and MS Windows.
When I look at the computer on my desk with 10 years of evolution behind it,
I see:
"Monster inside"
Written all over it!
Q: How can an industry go so wrong?
A: With lots more money, zero sense of Ethics and zero Knowledge
of its own history.
"That was me speaking, Not It."
Henry Baker
gcle...@keps.com (Geoffrey Clements) wrote:
> In article <3r3995$1...@Yost.com>, yo...@Yost.com (Dave Yost) wrote:
>
> > In article <3r289d$j...@ornews.intel.com>,
> > Patrick Logan <pdl...@ornews.intel.com> wrote:
> > >Dave Yost (yo...@Yost.com) wrote:
> > >
> > >: Lisp is considered too hard for most programmers,
> > >
> > >Guess what, from what I've seen during twelve years in the industry,
> > >*programming* is too hard for most programmers.
> I've programmed in a few different langauges and worked with a bunch of
> different programmers. I find that too many of those programmers used the
> "try stuff until it works" debugging method. They try something. OK that
> doesn't work. They try something else. Ok that doesn't work. So they try
> something else. That works. Bug fixed. This makes a huge mess of a piece
> of software because it turns a relatively straight forward piece of code,
> that may have not covered every contingency, into a patchwork of partial
> fixes.
>
> I absolutely hate coming onto a project and seeing code like this. In most
> cases I end up rewritting huge protions of the code. I usually finish
> before someone who is just fixing things because I turn the messy
> patchwork into clean simple code and they just fight the patchwork.
>
> > >I am not kidding. Any language. Most can't do it very well,
> > >and I'm tired of dealing with those who can't.
>
> Me too.
>
> > There is another side to this story, though.
> > There are programmers that are so smart and so fast,
> > that they have little regard for leaving something
> > clean and readable behind for themselves or others
> > to develop further. Would you say that programming
> > is too hard for such a person?
What? You don't like program development by debugging a blank sheet of
paper (or a blank screen)? Neither did many of the people that saw Lisp
in the late 1970's and early 1980's. Such development didn't follow
established practise, it didn't conform to the 'waterfall' model, etc.,
it didn't use 'static typing', etc.
So where are we today? People _love_ development by debugging blank
screens, so the newest tools for 'Visual Cxx' support this mode. This
mode has become almost classical, now that it has the fashionable name
of 'fast prototyping'. So the bullshit reasons why people didn't like
Lisp are just plain _wrong_, because nearly every one of these ideas is
heavily used today.
No, I think the real reason why people don't like Lisp is that people
(especially researchers at large companies and large universities) don't
like to admit that they were wrong, and that some snot-nosed kids got it
right the first time, perhaps decades before they did. Therefore, after
5-10 years and a blizzard of technical papers, they change the names of
things and start touting the same things that Lisp had first.
Remember garbage collection? Remember interpreters and incremental
debugging? Remember incremental compilers? Remember incremental loading?
(I could go on for _days_.)
People complain about 5 Megabyte 'hello world' programs. Have you ever
measured the size of a RISC 'hello world' program that runs on a GUI
interface these days, with X-Windows (or equivalent), etc., etc.? You
might be shocked and amazed.
The 8 Mbyte main memories required to run Lisp Machine Lisp grossed everyone
out in 1980. But look at what it takes to run MS Windows these days!
16 Mbytes! So it isn't the _language_ that cost all of the memory, but
the _functionality_. And I'll bet that Lisp was at least an order of
magnitude more efficient in its use of that memory than MS Windows is.
--
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
Robert Futrelle
>In article <3r0v3d$b...@tools.near.net>,
>Barry Margolin <bar...@nic.near.net> wrote:
>>But before programmers can use Lisp for large
>>applications they need to get their feet wet on small ones, and Lisp
>>usually isn't the appropriate language for little applications (the 5MB
>>"hello world" binary is the usual example).
I am a professor who has taught lisp to students and it works.
>
>Hear, hear. I would like to add the perspective of a professor who
>would like to teach Lisp dialects to students of math and computer
>science, but who has trouble making it work. An important part of
>the problem is the size and complexity of the environment within
>which the learner must learn. Since students' computers are apt to
>be small, maybe slow, this is a big obstacle. So is cost. (Gambit
>scheme solves the cost problem, maybe the size problem, and part of
>the complexity problem, so I do use that.) But there are other
>serious obstacles.
MCL isn't very big. It will fit easily onto all the machines
in our Mac labs. The very fact that the listener is there makes
the environment trivial. Type in whaterver and it compiles and
executes and gives you an answer (defs are added to the running
environment).
>The first is comprehensibility. In the case of Lisp, there is the
>sheer size of the language. It prevents all but a few from ever
>getting a feeling that they have really mastered it; in fact, it
>leaves most with the sense that they have only scratched the
>surface. Scheme is much better here.
The language is only as big as you make it. If the sample code you
give the students to guide them in their work only includes a handful
of functions, growing to 40 or so, then why should they be confused.
Don't just hand them Steele and say, this is it. There are numerous
texts that only teach a core set of functionality.
>Then there is the problem of abstractions. Lambda, one of the key
>things that makes Lisp & friends so nifty (you can make functions
>on the fly, have functions returning other functions, create
>closures, etc.) is a DIFFICULT CONCEPT. Look folks, we have
>trouble teaching them what ordinary mathematical functions are, let
>alone functions of higher type (a.k.a functionals or operators).
>(Actually, I have hopes that teaching a Lisp dialect will help
>students learn mathematical concepts! So I'm not objecting to
>abstractions, I'm only pointing out that for the beginning
>programmer they're a source of difficulty and complexity that must
>be addressed.)
Lambdas are a separate topic from returning functions, creating
closures and the like. They can and should be treated separately.
You don't give "beginning" programmers exercises that involve these
things.
>Another aspect of comprehensibility: In my view, most people reach
>an understanding of how a programming language "works" by
>constructing a mental model of the computer and how it executes the
>statements of the language. C is close to an assembly language, so
>the mental models (which change as learning occurs) reach a good
>approximation of reality in a relatively short time, and thus serve
>as reliable predictors of what a particular piece of code is going
>to do. The reality of Lisp implementations is relatively
>complicated, and the mental model must also be more complicated. I
>spend some effort explaining "how it all works" to students, but
>however useful this may be, it does add an extra layer of
>complexity.
The reality you speak of really isn't there. Modern CPUs and compilers
do exotic things to your code. What about conditionals and case
statements? -- they certainly compile to odd things with gotos and
worse at the assembler level. Is that the model you want.
Lisp has an elegant and simple model. Arguments are evaluated and then
functions are applied to them and the value returned. Data and function forms
have the identical syntax. Could things be simpler? As far as mental
models go, this takes a lot off my mind.
>There is the problem of efficiency. I don't mean whether the
>compiler can generate fast code. The problem is seeing whether one
>has written good code or not. It is hard to tell. I have a friend
>who maintains a large Lisp program written years ago by others.
>Often, he comments on what poor code is there, and he improves it.
>But the original coders were hardly Lisp neophytes; why didn't they
>see how bad the stuff they were writing really was?
Since the beginning of programming, people have been commenting
on the poor quality of code that they are given to change/maintain.
This has _nothing_ to do with Lisp. As for what is good style,
the same rule applies as applies to writing prose -- you have to
read good things in order to learn how to write good things.
(Peter Norvig makes that remark explicitly in his Paradigms book
and I seconded in in my AI Magazine review.)
>Program size: as Barry notes, even "hello world" can be huge. How
>important do you suppose it is that student programmers and other
>learners be able to create small programs that they can pass around
>to friends? Some don't care but many do. If I write a piece of
>Lisp code for some simple string manipulation, I may find it very
>useful myself, but I might actually be embarrassed to offer the
>complete stand-alone application to anyone unfamiliar with Lisp.
Students, like professors, when it comes to programming, are more
interested in source code than in compiled applications. The source
code for "hello world" in Lisp is (princ "hello world"). They
can give that to their friends and their friends can compile it.
>Accessibility: Good C compilers are available, are cheap, and fit
>on relatively small student-owned machines. Having your own system
>on your own machine is a big plus for anyone learning a language.
>It isn't a requirement, but it helps.
Digitool is now offering MCL 3.0 orderable directly from them
with student pricing. It's not $39.95, but you get a lot for
your money.
>
>Debugging: Most Lisps have pretty serviceable debugging tools. But
>what if your code breaks something at a low level? It's pretty
>easy to tell what piece of C source some assembly code corresponds
>to, but not so for Lisp. And there are other difficult situations:
>I've been scratching my head for a while over one where the
>compiler chokes on code produced by several layers of interacting
>macros. It is bewildering trying to figure out where this code
>originally came from!
Lisp doesn't tend to break on "low-level" things because there
are reliable parts of the Lisp system that handle pointers and memory
allocation for you. If you write several layers of interacting
macros, you could be making trouble for yourself. See Paul Graham's
book On Lisp for discussions of how you can hang yourself writing
macros.
>John Doner
Bob Futrelle
--
Prof. Robert P. Futrelle | Biological Knowledge Lab, College of CS
Office: (617)-373-2076 | Northeastern University, 161CN
Fax: (617)-373-5121 | 360 Huntington Ave.
futr...@ccs.neu.edu | Boston, MA 02115
David B. Lamkins
[...]
>Accessibility: Good C compilers are available, are cheap, and fit
>on relatively small student-owned machines. Having your own system
>on your own machine is a big plus for anyone learning a language.
>It isn't a requirement, but it helps.
cost(Lisp environment) < cost(C environment) : usually true.
size(Lisp environment) < size(C environment) : debatable.
On my Mac, MCL 2.0 takes up 5.7 MB, fully loaded. Symantec THINK C++ 7.0
takes up 15.5 MB of disk, fully loaded. MCL will run comfortably in 3-5 MB
of physical memory. THINK C++ requires 8-12 MB.
At work, the ratios are similar when comparing ALC/Windows 2.0 and MS VC++ 2.1.
>Debugging: Most Lisps have pretty serviceable debugging tools. But
>what if your code breaks something at a low level? It's pretty
>easy to tell what piece of C source some assembly code corresponds
>to, but not so for Lisp.
This may be an issue of familiarity with language implementation issues, as
suggested earlier in your post (not quoted here). A Lisp disassembly, at
lower optimization levels, tends to name a lot of primitive operations that
pretty clearly indicate what's going on.
> And there are other difficult situations:
>I've been scratching my head for a while over one where the
>compiler chokes on code produced by several layers of interacting
>macros. It is bewildering trying to figure out where this code
>originally came from!
How about macroexpand-1?
David B. Lamkins
>>on relatively small student-owned machines. Having your own system
>>on your own machine is a big plus for anyone learning a language.
>>It isn't a requirement, but it helps.
>
>
>size(Lisp environment) < size(C environment) : debatable.
Of course, the inequalities go the wrong way in my original message...
I meant to say:
cost(Lisp environment) > cost(C environment) : usually true.
size(Lisp environment) > size(C environment) : debatable.
>
>On my Mac, MCL 2.0 takes up 5.7 MB, fully loaded. Symantec THINK C++ 7.0
>takes up 15.5 MB of disk, fully loaded. MCL will run comfortably in 3-5 MB
>of physical memory. THINK C++ requires 8-12 MB.
>
>At work, the ratios are similar when comparing ALC/Windows 2.0 and MS VC++ 2.1.
Dave
Dave Yost
Robert Futrelle <futr...@ccs.neu.edu> wrote:
>In article <3r5ads$6...@news.aero.org> do...@aero.org (John Doner) writes:
>>How important do you suppose it is that student programmers and other
>>learners be able to create small programs that they can pass around
>>to friends? Some don't care but many do. If I write a piece of
>>Lisp code for some simple string manipulation, I may find it very
>>useful myself, but I might actually be embarrassed to offer the
>>complete stand-alone application to anyone unfamiliar with Lisp.
>
>Students, like professors, when it comes to programming, are more
>interested in source code than in compiled applications. The source
>code for "hello world" in Lisp is (princ "hello world"). They
>can give that to their friends and their friends can compile it.
I think the point here is that a language/environment
is much more fun and interesting if it makes it easy
to generate a complete, polished, runnable thingy
for the platform that isn't unduly large and that
is easy to modify or integrate into other code.
On the Mac, for example, this would mean that you could
give someone a tiny double-clickable application that put
up a "Hello, folks of World!" window. This can't be done
on MCL because there is no shared runtime. Is there yet
a lisp implementation that facilitates this?
The best is to be able to have your cake and eat it too--
i.e. give out a file that is both a compiled app and a
repository for its source code.
The best example of this I've seen is a thing called an
AppleScript "applet" on the Mac. When you double-click
it, it runs. When you drag it onto the Script Editor
application, the source code is revealed and you can
mess with it. Of course, the AppleScript runtime
library is not carried with the applet, so it's tiny.
There's now an even better development environment for
AppleScript called FaceSpan on the Mac that melds a UI
builder with an AppleScript programming environment.
It can produce an applet with a significant UI.
Lisp is definitely behind in this area, at least on the Mac.
Dave
Rich Parker
>How about rapid prototyping? It seems unlikely that C++ will ever meet that
>need.
I beg to differ. Visual C++ (for Windows) and Symantec C++ (for Mac) both offer
quite rapid prototyping environments. The amount of code that you have to write
to get a user interface up and running is really minimal (if any). That's
usually the biggest job in most any application. The computational
algorithms needed to complete the job are going to be pretty much the same in
any environment.
-rich-
Rich Parker
>Don't doubt that I'm on lisp's side, just as you all are. I'm just
>agreeing with and amplifying the idea that our side isn't winning.
>by me; but the fact remains that many $ were spent in persuit of
>lisp's supposed virtues, and the wave is visibly receeding.
>
>Saying "but we've got it right" to each other 1e6 more times isn't
>going to convince anyone new.
I absolutely agree. I _love_ MCL and am looking forward to seeing v3.0,
but it's going to take a back seat to C++ or Smalltalk environments
_unless_ it features a small footprint in compiled apps and has a good
application framework and interface builder capability.
-rich-
Rich Parker
>MCL isn't very big. It will fit easily onto all the machines
>in our Mac labs. The very fact that the listener is there makes
>the environment trivial. Type in whaterver and it compiles and
>executes and gives you an answer (defs are added to the running
>environment).
I absolutely agree. MCL is really tops when it comes to ease of use and
friendliness. I ran all of Norvig's (Paradigms of Artificial Intelligence
Programming, Peter Norvig, Morgan Kauffman publishers) from within the MCL
environment and learned a lot about many of the gnarly features of closures
and functions returning functions, etc.
>The language is only as big as you make it. If the sample code you
>give the students to guide them in their work only includes a handful
>of functions, growing to 40 or so, then why should they be confused.
>Don't just hand them Steele and say, this is it. There are numerous
>texts that only teach a core set of functionality.
Absolutely agree. You can't hand a student CLtL2 and expect them to learn
Lisp. A book like Norvig's is ideal for teaching Lisp.
-rich-
Rich Parker
>On my Mac, MCL 2.0 takes up 5.7 MB, fully loaded. Symantec THINK C++ 7.0
>takes up 15.5 MB of disk, fully loaded. MCL will run comfortably in 3-5 MB
>of physical memory. THINK C++ requires 8-12 MB.
I am also a user of Symantec C++/VA/TCL, but the main issue of difference
between that and the MCL environment is the size of compiled applications.
A decent C++/TCL-based application can be about 800Kb in size. MCL apps
tend to be 3- to 4-times that size. That's the main problem, IMO.
-rich-
Barry Margolin
>In article <ddyerD9...@netcom.com>, Dave Dyer <dd...@netcom.com> wrote:
>>
>>The remaining lisp vendors are locked into survival mode, and don't have
>>the resources or inclination to undertake anything revolutionary.
>
>This appears not to apply to Harlequin at all.
>The revolutionary thing they're undertaking is to develop Dylan.
Harlequin also does other stuff besides Lisp and Dylan. I suspect the
electronic publishing side of the company is carrying the language side.
Also, if the electronic publishing software is written in CL, it justifies
the language side even if LispWorks isn't making money on its own. This is
sort of the opposite of Lucid's situation: the Lisp business lives or dies
based on the success of the rest of the company.
Franz seems to be the only big player where Lisp is the main business.
--
Barry Margolin
BBN Planet Corporation, Cambridge, MA
barmar@{bbnplanet.com,near.net,nic.near.net}
Phone (617) 873-3126 - Fax (617) 873-5124
Philip Jackson
: Here's another problem that needs solving:
: Lisp is considered too hard for most programmers,
: too elegant, too complex, too formal, etc.
: A Vice President of a major computer industry company
: said this (more or less) to me just the other day.
: I think this problem could be solved by
: the right book, targeted directly at C programmers.
Perhaps the target for "ease of programming" should not be C (or C++)
programmers, but Visual Basic... A Lisp environment that was as easy
as Visual Basic, and provided the same level of support for GUI
development, OS access, and integration with other applications,
could be very attractive... and perhaps not too far from where
Lisp already is...
Phil Jackson
William Paul Vrotney
>
> In article <3r3g6a$d...@maureen.teleport.com>, "David B. Lamkins"
> <dlam...@teleport.com> wrote:
>
> > What's really frustrating is that the cross-pollination of ideas is
> > so pathetically slow, mostly because people's natural tendency is to
> > block out anything far from their self-perceived norm... That's why
> > C++ users absolutely fawn over new clever ways of writing data structures
> > like (to quote an example from a magazine that crossed my desk today)
> > "arrays of arrays" -- a big yawn to Lispers. On the other side, I'd
> > kill for a really natural interface to the underlying OS, or a GUI
> > framework as robust as those taken for granted by C++ users.
>
> Don't look at it as something frustrating, look at it as a career opportunity.
> Yes, you can take those 20 year old results from Lisp, and republish them
> as "new" C++ results! Academic careers are made in this fashion (hint: you
> don't have to be the author of the original result, just able to read it
> and translate to the language de jour).
>
Language de jour indeed. Brad makes some interesting points here. If I
know Brad (hi Brad :o)), I think he intends them with a twist of sarcasm
while cutting though to the actual truth. I would like to add another
dimension to the language de jour concept.
It seems like not even a year has passed and here we are again with the
great "Lisp versus C debate", just different debaters. I remember a time
when it was Lisp versus Pascal and before that Lisp versus Algol for
algorithm publications and even a time when it was Lisp versus Fortran
because those were the only two languages way back then. And now it seems
to be Lisp versus C++. And in the future if it turns out to be Lisp versus
x, perhaps Lisp versus Dylan, then perhaps there is a pattern emerging here.
Does Lisp keep getting rediscovered? Could McCarthy have uncovered the last
programming language and the world just hasn't accepted it yet?
PLI advocates thought they had the answer. I remember going to a lecture
way back then where the speaker actually announced, "PLI is the last
programming language you will ever have to learn". I remember the Pascal
advocates though they had the answer with structured programming, "Enforces
program correctness". And now the C++ advocates are more or less implying
that static typed objects is the answer, "The compiler will prevent any
object type errors". Meanwhile little old Lisp just refuses to die. Could
the implementation problems of Lisp just be a "side effect" of our primitive
technologies of the 1900s?
In the language wars Lisp represents elegance. Don't let the world sell
elegance short. It seems to be an enduring substance of the formulae of
science. From time to time when the Lisp versus C debate has reappeared I
have posted this quote which I believe has something to say about the
world's acceptance of Lisp:
"Over the period A.D. 1000-1500 the Hindu-Arab number system co-existed in
western Europe with the Greek and Roman numerals. Oriental science was
brought to the west by Italian merchants who traveled in the East. One of
them was Leonardo of Pisa (Fibonacci, `son of Bonaccio') who wrote a famous
mathematical treatise (in 1202), the "Liber Abaci", which was influential in
introducing Arabic numerals to the West. However, on the whole, people
preferred the Roman numerals with which they were familiar; they had learned
to do sums with them quite rapidly using an abacus (a counting board with
movable counters, still in use in some parts of the world). The public
disliked Hindu-Arab numerals because they were strange and difficult to
read, and the authorities opposed them because they were too easily forged.
In 1299 Florentine merchants were forbidden to use Arabic numerals in
book-keeping; 200 years later Roman numerals had disappeared entirely from
the books of the Medici."
[Numbers and Infinity, E.Sondheimer and A.Rogerson]
Are there parallels here? Could history be repeating itself with Lisp?
--
William P. Vrotney - vro...@netcom.com
William D Clinger
In article <3r5kfn$4...@camelot.ccs.neu.edu> futr...@ccs.neu.edu (Robert Futrelle) writes:
>The language is only as big as you make it. If the sample code you
>give the students to guide them in their work only includes a handful
>of functions, growing to 40 or so, then why should they be confused.
Because they will stumble over the rest of the language as they try
to use the simple core.
As a COBOL programmer, for example, I had to consult a list of more
than 700 reserved words every time I chose the name for a variable.
It was ridiculous.
Common Lisp has about as many reserved words as COBOL. (This is the
effect of CLtL2 p 260.) Unlike COBOL, where the compiler reliably
complains if you misuse a reserved word, the effect of misusing a
reserved word in Common Lisp is implementation-dependent, and you
might not even get a warning message.
Not all Lisps have this large a problem. IEEE Scheme has only 19
reserved words. With the R4RS macro system, Scheme has no reserved
words at all.
But Scheme, Common Lisp, and C++ share the problem of a syntax in
which a high percentage of the plausible-looking expressions are
syntactically legal (and will survive the limited type-checking in
C++). This is a very significant problem for students. It means
you have to teach parts of the language that you don't want students
to use just so they can recognize symptoms of this kind of mistake.
Examples:
(cond (null? x) (write 0) (else (write 1)))
(defun map1 (f x)
(if (null x) '() (cons (f (car x)) (map1 f (cdr x)))))
if (*p++ = *q++ & isalpha(*p));
>Lambdas are a separate topic from returning functions, creating
>closures and the like. They can and should be treated separately.
>You don't give "beginning" programmers exercises that involve these
>things.
I can understand this attitude with regard to Common Lisp, because
you don't want to have to explain to a novice why the definition of
map1 above doesn't work. That example doesn't contain any lambda
expressions, however, so I don't think you should blame lambda for
the problem.
>Lisp has an elegant and simple model. Arguments are evaluated and then
>functions are applied to them and the value returned. Data and function forms
>have the identical syntax. Could things be simpler? As far as mental
>models go, this takes a lot off my mind.
What you say is true for Scheme, though false for Common Lisp (unless
you meant only to say that both data and function forms use Cambridge
Polish).
The real problem, I believe, is that Scheme, Common Lisp, and their ilk
are at a higher level than the programming languages that most people
are used to. In particular, people who are accustomed to understanding
programs by thinking about the sequence of states that they induce
within a von Neumann computer are not going to understand Lisp programs
very well. (Why? Because there is a substantial semantic gap between
Lisp and machine instructions. This gap is bridged by highly
implementation-dependent machinery, the variety of which tends to
confuse novices who think they would understand Lisp if they only knew
"what really goes on at the machine level".)
It is true that people who have a problem with high-level languages
aren't likely to be hotshot C or C++ programmers either, but they can
at least understand small pieces of C and sometimes of C++ by thinking
at a very low level, and that may well be good enough to get them
through an undergraduate CS curriculum and to achieve recognition as
an average C programmer.
I am not saying we should aim the CS curriculum at students who have
trouble with abstraction. What I am saying is that many schools do
precisely that, and it seems a little unfair, having attracted these
students by using low-level languages, to require them to think in a
manner that might make them more productive. It's easier to leave
that kind of education to industry.
In article <3r5ads$6...@news.aero.org> do...@aero.org (John Doner) writes:
>>There is the problem of efficiency. I don't mean whether the
>>compiler can generate fast code. The problem is seeing whether one
>>has written good code or not. It is hard to tell. I have a friend
>>who maintains a large Lisp program written years ago by others.
>>Often, he comments on what poor code is there, and he improves it.
>>But the original coders were hardly Lisp neophytes; why didn't they
>>see how bad the stuff they were writing really was?
Futrelle responds:
>Since the beginning of programming, people have been commenting
>on the poor quality of code that they are given to change/maintain.
>This has _nothing_ to do with Lisp...
I think it does. In languages with an Algol-like syntax, the infix
operators usually take constant time, and the procedure call syntax
is used mainly for non-trivial operations. This makes it easier to
focus one's attention on the time-consuming operations. Since Lisp
uses the procedure call syntax for almost all operations, trivial
or not, it isn't quite so easy to see the time-consuming operations.
To see what I mean, you might ask a group of novice Lisp programmers
why the following Scheme code is inefficient:
(define (replace a b x)
(cond ((= (length x) 0)
'())
((= (length x) 1)
(if (eqv? a (list-ref x 0))
(list b)
(list (list-ref x 0))))
(else
(append (replace a b (list (list-ref x 0)))
(replace a b (cdr x))))))
You might hear about the common subexpressions (length x) or
(list-ref x 0), the use of append instead of cons, and someone might
even suggest a type-dispatch on the first argument so eq? could be
used instead of eqv?, but there's a good chance that no one will
notice the real problem.
I once reduced the running time of a real-world application from
2 hours to 3 seconds by repairing inefficiencies such as this, so
experienced programmers can make this kind of mistake too.
It is worth noting that syntactically familiar operators in C++ do
not necessarily take constant time, since they can be overloaded,
so this particular objection to Lisp's syntax applies also to C++.
Doner observes:
>>Program size: as Barry notes, even "hello world" can be huge. How
>>important do you suppose it is that student programmers and other
>>learners be able to create small programs that they can pass around
>>to friends? Some don't care but many do. If I write a piece of
>>Lisp code for some simple string manipulation, I may find it very
>>useful myself, but I might actually be embarrassed to offer the
>>complete stand-alone application to anyone unfamiliar with Lisp.
It is easy to write an effective selective linker for Scheme, and
I wrote one for MacScheme+Toolsmith in 1985. The situation for
Common Lisp is rather different, because the X3J13 committee made
a semi-conscious decision that selective linking was less important
than the ability to pass symbols (as opposed to procedures) as
arguments to procedures like APPLY. Consequently selective linking
for Common Lisp is impossible in theory and difficult in practice.
This is an area in which Common Lisp deserves its reputation, which
has affected the entire Lisp family by association.
William D Clinger
Martin Cracauer
>The language is only as big as you make it. If the sample code you
>give the students to guide them in their work only includes a handful
>of functions, growing to 40 or so, then why should they be confused.
>Don't just hand them Steele and say, this is it. There are numerous
>texts that only teach a core set of functionality.
I oppose to this view. I couldn't get produtive in Lisp with the
functions mentioned in Winston/Horn and Koschman. Simulating existing
functions by combining simpler ones is a waste of time. The worst
thing was I couldn't understand other people's code because I didn't
know many functions/macros.
It took reading CLtL2 to be productive. With productive I mean a
portable application with acceptable fast I/O and optimized inner
parts and usage of standard CL elements where they exist (to be
readable for others and for me at a later time).
[...]
>Lisp doesn't tend to break on "low-level" things because there
>are reliable parts of the Lisp system that handle pointers and memory
>allocation for you. If you write several layers of interacting
>macros, you could be making trouble for yourself. See Paul Graham's
>book On Lisp for discussions of how you can hang yourself writing
>macros.
For me, Common Lisp systems break relativly often, more often than my
(GNU) C compiler.
This causes me to do my Lisp work on UNIX where I have several
compilers availiable to check them against each other (and against my
unsufficient knowledge of Common Lisp that causes many programs to
fail, too).
The nature of working in Lisp, in an integrated environment where a
crash in a compiler or debugger/inspector/whatever causes all editing
sessions to be terminated, too make the situation worse as in C, where
a chrashing compiler doesn't harm other emacs buffers (of course, that
doesn't apply to Borland C++ :-).
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@wavehh.hanse.de>. No NeXTMail, please.
Norderstedt/Hamburg, Germany. Fax +49 40 522 85 36. This is a
private address. At (netless) work programming in data analysis.
Frank Adrian
: Another aspect of comprehensibility: In my view, most people reach
: an understanding of how a programming language "works" by
: constructing a mental model of the computer and how it executes the
: statements of the language. C is close to an assembly language, so
: the mental models (which change as learning occurs) reach a good
: approximation of reality in a relatively short time, and thus serve
: as reliable predictors of what a particular piece of code is going
: to do. The reality of Lisp implementations is relatively
: complicated, and the mental model must also be more complicated. I
: spend some effort explaining "how it all works" to students, but
: however useful this may be, it does add an extra layer of
: complexity.
I wonder if this is a problem of how people understand or how they are
taught? Operational models are useful. However, I fail to see why an
operational model at the level of registers, memory cells, and increments
is more comprehensible than one at the level of functions, bindings,
and recursion, unless the student's mind has already been polluted by
earlier exposure to these concepts. If programming is to advance beyond
its current (rather pathetic) level, we have to start losing our fas-
cination with the implementation layers.
___________________________________________________________________________
Frank A. Adrian ancar technology Object Analysis,
fra...@europa.com PO Box 1624 Design,
Portland, OR 97207 Implementation,
Voice: (503) 281-0724 and Training...
FAX: (503) 335-8976
55437-olivier clarisse(haim)463
In article <3r76ob$l...@Yost.com>, yo...@Yost.com (Dave Yost) writes:
|> The best is to be able to have your cake and eat it too--
|> i.e. give out a file that is both a compiled app and a
|> repository for its source code.
|>
the Interlisp-D "OS" handled each function as a small object
both compiled and source code. You could also pull up any such
code object in its own editor any time and "mess with it".
You could even *advise* (modify) any system code function.
|> The best example of this I've seen is a thing called an
|> AppleScript "applet" on the Mac. When you double-click
|> it, it runs. When you drag it onto the Script Editor
|> application, the source code is revealed and you can
|> mess with it. Of course, the AppleScript runtime
|> library is not carried with the applet, so it's tiny.
|> There's now an even better development environment for
|> AppleScript called FaceSpan on the Mac that melds a UI
|> builder with an AppleScript programming environment.
|> It can produce an applet with a significant UI.
|>
|> Lisp is definitely behind in this area, at least on the Mac.
|>
And what if MCL *was* the OS on your MAC?
Then every MCL object, function or method would be both a native
"script" (is lisp the 1st scripting language or what?) and would also
inherently run compiled. [Lisp *was* ahead indeed - 10 years ago.]
Patrick Logan
: mar...@ix.netcom.com (Martin Brundage) wrote:
: >How about rapid prototyping? It seems unlikely that C++ will ever meet that
: >need.
: I beg to differ. Visual C++ and Symantec C++ both offer
: quite rapid prototyping environments.
: The computational
: algorithms needed to complete the job are going to be pretty much the same in
: any environment.
I have used both Visual C++ and several Lisp/Smalltalk, etc. environments.
From my experience, in no way is the "computational algorithm" development
the same in all these environments.
The closest experience I have had with a C/C++ environment being close to
a Lisp/Smalltalk environment is Zeta-C for Lisp Machines and ObjectCenter
for Unix. (ObjectCenter is currently available.)
Even so, there is a *big*, *Big*, *BIG* gap between the Lisp/Smalltalk
environments and ObjectCenter.
--
Patrick...@ccm.jf.intel.com
Intel/Personal Conferencing
"Form follows function." -Le Corbusier
Clint Hyde
--> I am posting this followup only to comp.lang.lisp.
--> Common Lisp has about as many reserved words as COBOL. (This is the
not only is this unfair, it's wrong, and I know you know it, sir. CL
has NO reserved words, if you work in your own package. if you try to
SETQ or DEFUN a symbol in the (probably locked) CL package, at least
with Allegro you get an error about the package being locked, and a
proceed option to go ahead and do it anyway. this is certainly all *I*
need, because I ALWAYS work in my own packages (except for short bits of
code or experimental things in early development).
--> effect of CLtL2 p 260.) Unlike COBOL, where the compiler reliably
--> complains if you misuse a reserved word, the effect of misusing a
I'm sure this was not universally true of COBOL compilers.
--> reserved word in Common Lisp is implementation-dependent, and you
--> might not even get a warning message.
does the ANSI std say anything about this?
--> Not all Lisps have this large a problem. IEEE Scheme has only 19
--> reserved words. With the R4RS macro system, Scheme has no reserved
--> words at all.
great. CL has a different focus and history from Scheme. as you know.
-- clint
Clint Hyde
--> For me, Common Lisp systems break relativly often, more often than my
--> (GNU) C compiler.
this is amazing! Lisp never breaks itself for me. nor does it
core-dump because of some problem. my Lisp-code politely goes into the
debugger whereupon I am able to go right to the source-code or the
problem. my C-code breaks when I'm out of practice, and core-dumps
every single time (I know, gdb and dbx prevent some of this, but I'm
even MORE out of practice with them).
--> This causes me to do my Lisp work on UNIX where I have several
--> compilers availiable to check them against each other (and against my
--> unsufficient knowledge of Common Lisp that causes many programs to
--> fail, too).
-->
--> The nature of working in Lisp, in an integrated environment where a
--> crash in a compiler or debugger/inspector/whatever causes all editing
I wonder what Lisp you're talking about here. the only time in the past
where I have had this level of disaster occur was when I had bashed the
window system SO BADLY that I couldn't get to Emacs/ZMACS to save files.
and that hasn't happened for some years.
--> sessions to be terminated, too make the situation worse as in C, where
--> a crashing compiler doesn't harm other emacs buffers.
-- clint
clar...@iexist.flw.att.com
In article <3r7k7a$d...@camelot.ccs.neu.edu>, wi...@ccs.neu.edu (William D Clinger) writes:
[...]
|> Common Lisp has about as many reserved words as COBOL. (This is the
|> effect of CLtL2 p 260.) Unlike COBOL, where the compiler reliably
|> complains if you misuse a reserved word, the effect of misusing a
|> reserved word in Common Lisp is implementation-dependent, and you
|> might not even get a warning message.
|>
(in-package "EMPTY") ;Where Lisp has no reserved work.
Lisp only has as many "reserved words" as you want to include.
I have taught lisp by starting in a package "SMALL" that contained
only 16 imported symbols from COMMON-LISP (similar to "EMPTY" above).
Using SMALL to teach a small subset of important concepts, showing
students how you could rebuild all of Lisp within itself from SMALL,
and then introducing "COMMON-LISP" as a library package.
There are NO more reserved words in Lisp than in any other languages
and there are only ~27 special forms in common-lisp (but you can
eliminate all those you don't need). In CL least you have packages
to organize large software systems into manageable units.
If cond is confusing, don't include it in SMALL, if a function
does not work for weird reasons, don't teach it until students have
learned to produce small elegant functions that do useful things
(there are thousands of examples in CL books).
Robert Elton Maas, 14 yrs LISP exp, unemployed 3.7 years
that's where I'm following this thread even though it's slightly off topic.)
<<How often have you asked yourself `is Lisp really that good or have I
been zombified by using it this long?' ... It's not object orientation
or image size or programming environment. It's whatever you learn
first.>>
I disagree. I learned "Fortran with Format" (what I now call Fortran 1)
and SPS (IBM 1620 assembly language) first. Then we got a disk and had
"Fortran 2d" which was better than the earlier Fortran but I still used
SPS for some tasks. Then I got access to IBM 360 assembly language and
WATFOR. Then I got access to SAIL (a Stanford-modified version of Algol
60) and preferred it to all the previous and used it for about 5 years.
Meanwhile I got access to Stanford LISP 1.6 but didn't use it much for
various reasons. Then I got access to UCI LISP and started really using
it in parallel with SAIL. Then I got access to MacLISP and found it
MUCH better than SAIL or UCI LISP or anything else I had previously
used, and it became my primary programming language whenever possible.
I suffered a temporary detour when I lost TIP access to InterNet and
couldn't connect to MIT-MC to use MacLISP and had to suffer PSL
(Portable Standard LISP) for a few years, but that was still better
than anything else available. Now I've been using Common LISP since
1989, best language I ever used. No, it's not what I learned first, or
I'd still be on the Fortrash trail, using Fortran 77 or whatever they
have now. It's not even the first reasonably good language I used, or
I'd still be using SAIL or MainSAIL now.
Too bad it's no longer possible to earn a living doing rapid
prototyping using LISP. (All the ads I've seen on LISP-JOBS are either
for C/C++ programmers who happen to know a little LISP on the side, or
for A.I. Ph.D. researchers who happen to know LISP. Nothing at all in
the past 3 years for plain vanilla LISP-based applications, sigh.)
<<So the only way to make Lisp succeed is to work with Lisp haters.
Learn their language, write good code in it, keep telling them how much
easier this would be in Lisp, sneak a Scheme interpreter in through the
back door.>>
An alternative idea is to create LISP-based applications that provide
network services such as information retrieval. Customers who submit
service requests by e-mail and get results by e-mail don't care whether
the code was written in LISP or C++ or even LOGO, but after they pass
the word and you get lots of customers, a few might be curious what
language you used to get such fine results, then word of LISP might get
around favourably. (I'm planning to try that myself as soon as I catch
up with some more urgent matters and have some blocks of time to
concentrate on programming again.)
Robert Elton Maas, 14 yrs LISP exp, unemployed 3.7 years
a tiny double-clickable application that put up a "Hello, folks of
World!" window. This can't be done on MCL because there is no shared
runtime.>>
I don't quite see how a shared runtime would help the recipient if that
recipient had NOTHING whatsoever previously on his/her machine having
to do with LISP. What would be needed would be a link-loader that
selected all needed routines from some library and loaded them into the
runnable application being created.
LISP and HyperCard share this problem of ordinarily needing to have the
master application around to run any program, because programs are
documents not applications. The difference between MCL (and older MACL)
and HyperCard is that MCL/MACL are expensive while HyperCard used to be
free for a while. But XLISP is free even now, so if a LISP program can
run in XLISP, then pass the LISP document (source or compiled) plus a
pointer to where XLISP can be found on the net if the recipient doesn't
already have it. Then the recipient should be able to double-click on
the document to start the master XLISP application and run the program,
right?
Unfortunately I've played with XLISP only a little to date, so I don't
yet know how easy it is using XLISP to write a simple put-up-window
"Hello" program (with a button for closing the window and quitting the
program presumably).
P.S. I'm reading this thread on comp.lang.lisp.x, hoping to see some
active discussion of XLISP, but seeing mostly general LISP stuff
cross-posted, including most of this thread (but I put in a token
mention of XLISP, ha ha).
Barry Margolin
>In article <3r7k7a$d...@camelot.ccs.neu.edu> wi...@ccs.neu.edu (William D Clinger) writes:
>--> Common Lisp has about as many reserved words as COBOL. (This is the
>not only is this unfair, it's wrong, and I know you know it, sir. CL
>has NO reserved words, if you work in your own package.
That's true, but it's not easy to work in a package that doesn't :USE
COMMON-LISP. You have to manually declare every CL function or global
variable that you expect to use, or use explicit package qualifiers. If
one of your functions/variables happens to have the same name as a CL
function, and someone later writes code that expects this name to refer to
the CL version, you won't even get an error (except perhaps if the argument
lists are different lengths).
The main use for packages that don't inherit from COMMON-LISP is for the
public interface to a module, not the internal implementation of the
module.
>--> reserved word in Common Lisp is implementation-dependent, and you
>--> might not even get a warning message.
>
>does the ANSI std say anything about this?
It says that the consequences of trying to redefine the Common Lisp symbols
is undefined. It doesn't require that the implementation report it.
Richard A. O'Keefe
>Here's another problem that needs solving:
>Lisp is considered too hard for most programmers,
>too elegant, too complex, too formal, etc.
>A Vice President of a major computer industry company
>said this (more or less) to me just the other day.
Read this and weep:
'If you are like most C programmers, you use C not only for its power
and flexibility but also because the language itself represents an
almost intangible [sic], formal beauty that can be appreciated for
its own sake. In fact, C is often referred to as "elegant" because
of its consistency and purity. ...
The C language is one of the most theoretically consistent
computer languages ever developed.'
Herb Schildt, in 'The Craft of C'.
If C is elegant, then I guess Lisp *is* 'too elegant'. (Mind you, I wonder
how Schildt manages to touch beauty...)
By the way, I bought the book on sale because the cover said it contained a
C interpreter. It doesn't. It contains an interpreter for a toy language
vaguely resembling C, and _unbelievably_, it not only keeps on reparsing all
the time, it keeps on retokenising! This is the kind of elegance that sells
a million books, people!
(Walks away sobbing and looking for a basin.)
--
"The complex-type shall be a simple-type." ISO 10206:1991 (Extended Pascal)
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
Richard Levitte
In article <3r7k7a$d...@camelot.ccs.neu.edu> wi...@ccs.neu.edu (William D Clinger) writes:
--> Common Lisp has about as many reserved words as COBOL. (This is the
not only is this unfair, it's wrong, and I know you know it, sir. CL
has NO reserved words, if you work in your own package. if you try to
No reserved words? Eh, it was a year I hacked CL last time, but back
then there was something called special-forms, and I doubt you can get
closer to reserved words than that. On the other hand I have to agree
with you that comparing the amount of reserved words in COBOL (did I
see the figure 700 somewhere?) to the amount of special forms in CL
is pretty unfair. The latter are easily counted. I think I came down
to 29 last I checked...
--
+--------------------------------------------------------------------+
! Richard Levitte, GNU on VMS hacker ! tel: +46-8-83 12 15 !
! Södra Långgatan 39, II ! fax: none for the moment !
! S-171 49 Solna ! Internet: lev...@e.kth.se !
! SWEDEN ! !
+-<a href="http://www.e.kth.se/~levitte/gnu/gnu.html">GNUish VMS</a>-+
Mike Thome
In article Clint <ch...@bbn.com> writes:
In article wi...@ccs.neu.edu (William D Clinger) writes:
--> Common Lisp has about as many reserved words as COBOL.
not only is this unfair, it's wrong, and I know you know it, sir. CL
has NO reserved words, if you work in your own package. if you try to
No reserved words?
Nope - *no* reserved words...
Eh, it was a year I hacked CL last time, but back
then there was something called special-forms, and I doubt you can get
closer to reserved words than that.
In spite of the name, there is nothing special about the binding of
special-forms to symbols that would make them anything like reserved
words: In all languages I know of, a "reserved word" is a token which
may be used exclusively in the way the language specification defines
(eg. "int", "if" or "return" in C) - you are not allowed to redefine
these, use them as variables, etc. This is not a restriction that
applies to CommonLisp - all symbols may be redefined or rebound to
whatever you want whenever you want: you *do* have to be careful that
you do not change a binding which some other function (or Lisp itself)
depends on - but with care and your own package you can redefine (as I
have at various times) "if", "defmethod" even "setq".
cheers,
-mik
--
Michael Thome (mth...@bbn.com, 617-873-1853)
http://www-openmap.bbn.com/users/mthome/
Harley Davis
No reserved words?
Nope - *no* reserved words...
Eh, it was a year I hacked CL last time, but back
then there was something called special-forms, and I doubt you can get
closer to reserved words than that.
In spite of the name, there is nothing special about the binding of
special-forms to symbols that would make them anything like
reserved words: In all languages I know of, a "reserved word" is a
token which may be used exclusively in the way the language
specification defines (eg. "int", "if" or "return" in C) - you are
not allowed to redefine these, use them as variables, etc. This is
not a restriction that applies to CommonLisp - all symbols may be
redefined or rebound to whatever you want whenever you want: you
*do* have to be careful that you do not change a binding which some
other function (or Lisp itself) depends on - but with care and your
own package you can redefine (as I have at various times) "if",
"defmethod" even "setq".
What happens in Common Lisp if you do this:
(flet ((cond (&rest args) (car args)))
(cond 'im-a-function-now))
If this is an error, then I would call special forms pretty close to
reserved words.
-- Harley Davis
--
------------------------------------------------------------------------------
Harley Davis net: da...@ilog.fr
Ilog S.A. tel: +33 1 46 63 66 66
2 Avenue Galliéni, BP 85 fax: +33 1 46 63 15 82
94253 Gentilly Cedex, France url: http://www.ilog.com/
Mike McDonald
titian=>lisp
CMU Common Lisp 17f, running on titian
Send bug reports and questions to your local CMU CL maintainer, or to
cmucl...@cs.cmu.edu.
Loaded subsystems:
Python 1.0, target SGI
CLOS based on PCL version: September 16 92 PCL (f)
CLX X Library MIT R5.02
* (flet ((cond (&rest args) (car args)))
(cond 'im-a-function-now))
IM-A-FUNCTION-NOW
*
Mike McDonald
mik...@engr.sgi.com
Barry Margolin
>What happens in Common Lisp if you do this:
>
>(flet ((cond (&rest args) (car args)))
> (cond 'im-a-function-now))
>
>If this is an error, then I would call special forms pretty close to
>reserved words.
You can't portably redefine any of the built-in functions, macros, or
special operators using DEFUN, FLET, or LABELS. The reason for disallowing
DEFUN is that other functions in the implementation might depend on
implementation-specific features of their version of the function. The
reason for disallowing FLET and LABELS is that the implementation's macros
in the body could pick up the redefinition, so they might operate
differently.
The people who say that there are no reserved words consistently mention
packages. So while the symbol COMMON-LISP:COND is reserved, COND in
general is not. Thus, you can do:
(defpackage my-package
(:use) ; make it pristine
(:import-from COMMON-LISP FLET CAR &REST)) ; but we need these
(in-package my-package)
(flet ((cond (&rest args) (car args)))
(cond 'im-a-function-now))