"Tony Tanzillo" <·············@worldnet.att.net> wrote:
> A non-programmer (which is what most VB users are) can make use
> of intelligent editing features that put the information they
> need at their fingertips.
What would you think if someone demanded that the technical operation
of chemical factories should be optimized towards being "user-friendly"
for some arbitrary guy who happened to walk in from the street? Wouldn't
you consider such a state of mind insane? At least I'd do so, and I don't
see the suggestion that powerful programming languages and programming
tools should be optimized towards users without a decent education about
program design and implementation at all differently.
Now I don't have anything against people who want to play around with
programmable software, but I consider their interests, and the kind of
programming which they are likely to find appealing, comparable to a
chemical toolbox with which some children (and perhaps also some adults)
like to play with - it's just entertainment, and shouldn't be confused
with the needs of serious work (not implying the latter couldn't - or
shouldn't - also be enjoyable, but it demands much more background).
> A novice can actually watch a program execute, by seeing
> visually observing program logic flow.
As instructive as program visualization may be, unless people learn to
use sophisticated abstraction techniques (which implies differentiation
between a specification and some implementation - something they won't
learn by low-level debugging), they shouln't pretend to be qualified as
professional programmers. Working through some books about logic, problem
analysis, and program semantics will be a much better investment than an
arbitrarily friendly debugger. A basic understanding of programming logic
(rather than the execution of some particular program) may be helped by
going through some carefully selected examples, but that much can as
well be done "on paper" (nothing against software support for teaching,
but use specialized systems for that task, not the tools meant to be used
day in day out by experts). Beyond such simple steps, I'd want much more
expressive tools than single-stepping, which usually means that one
either has to derive the information from reading the program, or from
problem-specific utilities, which can be naturally built along with the
"main" source code. For a few remaining low-level debugging tasks, it
doesn't appear to make sense to waste lots of effort in graphical user
interfaces which are supposed to be "intuitive" to a novice, instead
of providing necessary hooks into the system for competent programmers.
Besides, all this "intuitive GUI" stuff does only get into the way if
one wants to perform a task automatically, solving it once and for all,
freeing one's thought and time for more insteresting problems.
-- Marc Wachowitz <··@ipx2.rz.uni-mannheim.de>
>
> What would you think if someone demanded that the technical operation
> of chemical factories should be optimized towards being "user-friendly"
> for some arbitrary guy who happened to walk in from the street? Wouldn't
> you consider such a state of mind insane?
You mean, you're not going to use the old nuclear power plant, or
'controlling the glide path of a space shuttle or aircraft' scenario?
Not all programming (actually only a small percentage of same)
qualifies as mission-critical. The problem you have, is that
you're out-of-touch with what the masses are doing with computers
these days.
Get out of the computer science department, and have a look at
the world around you. Programming is not just for 'professional
programmers' any more,
I understand that you might have a hard time accepting that,
but that is the reality.
> Now I don't have anything against people who want to play around with
> programmable software, but I consider their interests, and the kind of
> programming which they are likely to find appealing, comparable to a
> chemical toolbox with which some children (and perhaps also some adults)
> like to play with - it's just entertainment, and shouldn't be confused
> with the needs of serious work (not implying the latter couldn't - or
> shouldn't - also be enjoyable, but it demands much more background).
So, you're belittling the type of programming that these 'unqualified'
individual do, as a means of self-aggrandizement? So, the millions of
AutoCAD users, and millions of VB users are just 'playing around' (with
a very dangerous weapon)?
> As instructive as program visualization may be, unless people learn to
> use sophisticated abstraction techniques (which implies differentiation
> between a specification and some implementation - something they won't
> learn by low-level debugging), they shouln't pretend to be qualified as
> professional programmers. Working through some books about logic, problem
> analysis, and program semantics will be a much better investment than an
> arbitrarily friendly debugger.
You are obviously in very bad shape. I'm not sure where you spend your
time, but I have gone as far as I will to explain that the people I'm
referring to are not, and do not want to become professional programmers.
They don't give a damn about theory of software design or program
semantics. They don't care if their code is "elegant" or not, or
even if it is grossly-inefficient. The only thing that matters to
these people, is that it works, and it doesn't take them forever
to write.
You seem to view programming as if were an art, that should only be
practiced by some elite group of individuals. It's also clear from
your comments that to you, programming is the end, rather than just
a means to it.
I feel very sorry for you. Your point of view is hopelessly jaded to
the point where you seem to have convinced yourself that a bug in a
software program is going to ultimately lead to the destruction of
all life on the planet. What a pathetic shame.
Now, if you'll excuse me, I'm going to go blow up New Jersey
with a few lines of badly-written HTML.
* Tony Tanzillo wrote:
> Not all programming (actually only a small percentage of same)
> qualifies as mission-critical. The problem you have, is that
> you're out-of-touch with what the masses are doing with computers
> these days.
But a great deal of programming qualifies as `this costs money if it
breaks', and a reasonable chunk of programs which cost money if they
break are large enough that you have to be reasonably serious about
getting them right -- just hacking isn't any good unless you're a
genius.
> They don't give a damn about theory of software design or program
> semantics. They don't care if their code is "elegant" or not, or
> even if it is grossly-inefficient. The only thing that matters to
> these people, is that it works, and it doesn't take them forever
> to write.
I'd like not to give a damn about any of these things either. But I'm
forced into it by my own limitations as a programmer. I want to be
able to be write reasonable-sized systems, and be involved in quite
large systems. And I'm just not bright enough to do that without
being concerned with all this boring stuff like abstraction and
efficiency and design and engineering.
And Common Lisp is a good match for those concerns (not as good as it
should be of course).
--tim
Tim Bradshaw wheezed these wise words:
> And Common Lisp is a good match for those concerns (not as good as it
> should be of course).
Nothing ever is. ;) We're always striving for something better, and if
we think we've found it, another generation of programmers may find
something we've not thought of. This pushes us forward.
BTW, is this ng for Common Lisp only, or can we also talk about other
Lisps? Could a non-CL Lisp like AutoLisp also push us forward?
--
Please note: my email address is munged; You can never browse enough
"There are no limits." -- ad copy for Hellraiser
From: Craig Brozefsky
Subject: Re: Is there a debugger or similar for Common Lisp?
Date:
Message-ID: <l5pvnn48dv.fsf@onshore.com>
"Tony Tanzillo" <·············@worldnet.att.net> writes:
> You seem to view programming as if were an art, that should only be
> practiced by some elite group of individuals. It's also clear from
> your comments that to you, programming is the end, rather than just
> a means to it.
Writing is a means for a sales person to get their message out to a
prospective client. Writing is also an art form with a well developed
aesthetic sense. For one it is an means, for another it is an ends in
itself.
Why is it that his viewing of programming as an art seems to
automatically make you assume that he thinks it should only be
practices by an elite few? There is not a logical connection between
the two. A highly developed aesthetic does not automatically lead to
elitism and seperatist notions. Why do you think the two are linked?
--
Craig Brozefsky ·····@onshore.com
onShore Inc. http://www.onshore.com/~craig
Development Team p_priority=PFUN+(p_work/4)+(2*p_cash)
I hear my inside, the mechanized hum of another world - Steely Dan
Tony Tanzillo wheezed these wise words:
> Not all programming (actually only a small percentage of same)
> qualifies as mission-critical. The problem you have, is that
> you're out-of-touch with what the masses are doing with computers
> these days.
I call this the "One size fits all" argument (OSFA for short). One
size of solution applies or none at all. Fortunately, we can choose
tools that fit the size of the problem. Ideally, this should include
Lisp-based tools, but in practice, not every problem demands a $3000
tool. There are, however, less expensive Lisp tools. One of them costs
as little as $300 (currently available for only one platform, alas),
and others for only a little more.
OSFA can work against the freely available tools, as they don't
_necessarily_ include the same quality of support as the commercial
tools. For markets where support is seen as a critical issue, any
tools without guanteed support will likely be ignored.
Whether or not Lisp suffers because of this is debatable. Lisp
survives. Lisp's image may suffer, amoung non-Lispers, but this isn't
bad enough to kill the commercial Lisps, nor commercial use of Lisp.
So it's easy for some of us to believe that OSFA is reasonable.
Perhaps it's only those of us with problems that don't fit so well
that are unhappy? I think that this is why Lisps like AutoLisp exist.
When a tool doesn't fit, somebody - in this case AutoDesk - makes it
fit. Lisp is flexible enough to allow this. The result might not be
Common Lisp, but that's not always the ideal goal. CL is only one way
of Lisp, and there have been - and I hope will be - more.
This is Lisp's great strength; there need be no limits but those
limits that we ourselves create.here need be no limits but those that
we ourselves create. A Lisp like AutoLisp doesn't threaten CL. It only
threatens the idea that CL is the final word. Insisting that all Lisps
should be CL may be one of those limits. Insisting that all Lispers do
things in the same way may be another.
Could this be why some Lispers prefer a GUI debugger, and others
prefer a different style of debugging tool? I think so.
--
Please note: my email address is munged; You can never browse enough
"There are no limits." -- ad copy for Hellraiser
···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin Rodgers) writes:
> tools that fit the size of the problem. Ideally, this should include
> Lisp-based tools, but in practice, not every problem demands a $3000
companies are willingly spending zillions of dollars upgrading their
office applications to the newest incompatible standard from Redmond,
forcing them to throw away the pc's they bought less than two years
ago, and forcing them to waste man-year after man-year configuring
these machines. And don't tell me they get any more productivity
out of it!
Compared to that waste of money, the price of an lisp environment
- even the $3000 ones - is nothing.
--
Espen Vestre
From: Kent M Pitman
Subject: Re: Is there a debugger or similar for Common Lisp?
Date:
Message-ID: <sfw3ek9ogi9.fsf@world.std.com>
···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin Rodgers) writes:
> A Lisp like AutoLisp doesn't threaten CL. It only threatens the idea
> that CL is the final word.
Dunno even who would have put out such an idea.
It is no accident that standard X3.226/1994 (commonly called ANSI CL)
is a standard for Common Lisp and not for Lisp.
It is no accident that standard ISO/IEC 13816:1997(E) is a standard
for a dialect of Lisp called ISLISP, not a standard for Lisp.
Indeed, the ISO secretariat accidentally retitled the ISO standard to
be for Lisp and it caused an international uproar.
It's a convention that (I think) is nowhere written down but that was
requested (again, I think) by John McCarthy: that LISP not be a
language but a language family. No single dialect will call itself
just "Lisp". Lisp dialects may differ substantially and for good
reason, just as languages in the Algol family (arguably spanning
everything from Algol to Pascal to PL/1 and some even say C) differ
and for good reason. (The Algol family was just smart enough not to
name all their languages the same so it's not as easy to spot their
wide diversity by looking at similarly named languages and then
comparing them.)
> Insisting that all Lisps should be CL may be one of those
> limits. Insisting that all Lispers do things in the same way may be
> another. Could this be why some Lispers prefer a GUI debugger, and
> others prefer a different style of debugging tool? I think so.
I allege (and mostly because a few years back I think I heard it from
a senior AutoCAD employee) that AutoLISP doesn't survive due to any of
its features, it survives because there is no penalty for using it.
It is welcomed by the facility it customizes. That's great, but it's
not a fact that one can "learn from" and pack up and deploy in other
areas. One can't say "Fine, we'll build a LISP that is welcomed by
XXX" where XXX is any other system. e.g., suppose I want to customize
Microsoft Word or whatever. Well, eventually one will be able to do
that but by using CORBA or OLE or something. We can make Lisp support
CORBA or OLE interfaces, but we can't make Word want to call out to
our interfaces. As they choose to permit external advice, we can
offer such advice. AutoLisp is lucky (as is Emacs Lisp) to have been
welcomed by the developer. But it's not an aspect of its language
features that makes it a win in the end--it's an aspect of its ability
to deliver better end product on an already desired platform. No
amount of fancy debugging tool would make AutoLISP a win if it didn't
ultimately do the custom stuff AutoCAD needs. And a fancy debugger is
not what stands between Common Lisp and cool customization of
Microsoft Word. Moreover, if CL (or a subset) had been embraced by
AutoCAD instead of AutoLISP, no harm would have befallen the facility.
The language definition is simply not what is determining success.
It's cool to have a great debugger and over time better debuggers will
no doubt arise. But Common Lisp has, by its nature, served a
different community than AutoLISP. And the community that it serves
isn't clamoring for debuggers at the top of their list for the most
part. So we try to focus on the things they do want, which is
language and system building and integration. They want linkable
libraries as product files of compilation, better access to foreign
function and data integration, database interfaces, OLE and CORBA
integration, etc. They want multiprocessing, interprocess
communication, networking. These are the people who pay our (the CL
vendors') bills and they (the CL customers) will forgive us some lack
of debugger whizzies if at the end of the day they can deploy
applications that connect to the cold-cruel-world that is not
specifically embracing any Lisp, but that is rather willing to embrace
languages in general that provide db hooks, OLE hooks, CORBA hooks,
TCP/IP transport, HTTP service, etc.
And in the end nothing keeps us from coming back and doing the whizzy
debugger, too. But Common Lisp's bread and butter isn't 10-line
customization scripts--it's 10,000 and 100,000 line programs that do
very complex things. And if we spent our time improving the glamor of
the debugger rather than solving the reported problems of actual
customers--which are typically not "debugger featurefulness", THAT
would be the death of Common Lisp. Moreover, AutoLISP, even with its
fancy debugger, would not stand alone (absent AutoCAD) as a practical
solution to those 10,000 and 100,000 line programs.
We (the CL community) could make the changes faster, of course, but
not compatibly. And CL comes out of a desire on the part of some
users to stabilize language development, so stability/compatibility
really matter. Dylan is an example of what happens when you make a
list of all the things that need to change in Lisp and you make them
happen regardless of compatibility. Dylan's got its place, and I'm
not knocking it--it's pretty cool in many ways. But some people will
value the stability of CL and some will value the responsiveness of
Dylan. Again, different markets with different needs and different
ways of establishing a value for things.
Anything more I have to say on this matter is in my Parenthetically
Speaking article "Lambda, the Ultimate Political Party", at
http://world.std.com/~pitman/PS/Lambda.html
Kent M Pitman wheezed these wise words:
> > A Lisp like AutoLisp doesn't threaten CL. It only threatens the idea
> > that CL is the final word.
>
> Dunno even who would have put out such an idea.
See what I mean? The idea is so silly that there are worse threats to
it, like the truth. ;)
> > Insisting that all Lisps should be CL may be one of those
> > limits. Insisting that all Lispers do things in the same way may be
> > another. Could this be why some Lispers prefer a GUI debugger, and
> > others prefer a different style of debugging tool? I think so.
>
> I allege (and mostly because a few years back I think I heard it from
> a senior AutoCAD employee) that AutoLISP doesn't survive due to any of
> its features, it survives because there is no penalty for using it.
This is why I love the justification, "Because I _can_." If it could
not be used, there'd be nothing to discuss. Not that this stops people
from trying to convince those doing a thing that it can't be done.
> No amount of fancy debugging tool would make AutoLISP a win if it didn't
> ultimately do the custom stuff AutoCAD needs.
The fact that AutoLisp has not only survived but been so heavily used
says a lot. With so much code invested in it, AutoLisp is unlikely to
die quickly.
> And a fancy debugger is not what stands between Common Lisp and cool
> customization of Microsoft Word.
I've never suggested that this was the case. A "fancy debugger" has
its own appeal - utility.
> Moreover, if CL (or a subset) had been embraced by
> AutoCAD instead of AutoLISP, no harm would have befallen the facility.
> The language definition is simply not what is determining success.
This is what I've always thought. Sometimes, programmers are rightly
more concerned about issues other than language standards.
> It's cool to have a great debugger and over time better debuggers will
> no doubt arise. But Common Lisp has, by its nature, served a
> different community than AutoLISP.
I've been saying this myself. Different communities, different tools,
even when they may both be called Lisp. This is what I say Common Lisp
(often abbreviated to CL) when I mean Common Lisp.
> And the community that it serves
> isn't clamoring for debuggers at the top of their list for the most
> part. So we try to focus on the things they do want, which is
> language and system building and integration. They want linkable
> libraries as product files of compilation, better access to foreign
> function and data integration, database interfaces, OLE and CORBA
> integration, etc. They want multiprocessing, interprocess
> communication, networking. These are the people who pay our (the CL
> vendors') bills and they (the CL customers) will forgive us some lack
> of debugger whizzies if at the end of the day they can deploy
> applications that connect to the cold-cruel-world that is not
> specifically embracing any Lisp, but that is rather willing to embrace
> languages in general that provide db hooks, OLE hooks, CORBA hooks,
> TCP/IP transport, HTTP service, etc.
Agreed. I've been saying this myself. Altho it's also true that there
are people who have rather preconceived ideas of what a "good" IDE
looks like, and so when they see a tool that uses a listener, they
miss something important.
This may also be true with debuggers. I've lived without "source
level" debuggers for years, and not missed them. However, I can see
why other programmes refuse to give them up. I can also see why a Lisp
programmer might be reluctant to give up feature of Lisp.
> We (the CL community) could make the changes faster, of course, but
> not compatibly. And CL comes out of a desire on the part of some
> users to stabilize language development, so stability/compatibility
> really matter. Dylan is an example of what happens when you make a
> list of all the things that need to change in Lisp and you make them
> happen regardless of compatibility. Dylan's got its place, and I'm
> not knocking it--it's pretty cool in many ways. But some people will
> value the stability of CL and some will value the responsiveness of
> Dylan. Again, different markets with different needs and different
> ways of establishing a value for things.
This is also why VB exists. As you said, responsiveness. It's easy to
dismiss VB as only used by novices, but I'm not convinced by this. Nor
am I convinced by any of the anti-Lisp arguments, which are equally
unfair. Lisp has a lot of history, and this can be an asset when you
want stability. Cobol also has this...but never mind.
Sometimes we want something else, like responsiveness. Sometimes,
we're concerned more about issues other than language standards. we
have greater concerns for issues other than language standards. This
is perhaps why we get new ideas, new languages, and new standards.
When the answer to a question like Tony's is, "We don't do that in
Common Lisp", we're not saying that CL can't do this thing, or that a
Lisp (other than AutoLisp, in this case) won't ever do it.
If a programmer really can't live without a source level debugger,
then the message could be, "Don't use Lisp". Perhaps something else
will do. I'm not concerned about source level debuggers, but I'm not
shrugging my shoulders and saying, "That's your problem."
As I've paid for a CL system, and I can ask for the features that
interest me, but which are not currently supplied. Perhaps somebody
will listen. Not everyone can wait, and those people should choose
something else. Either a different CL, or system for another language.
Perhaps even write code to add a feature to an existing system, but as
that takes time, this is really advice for programmers who _can_ wait.
Do what you can...and do it because you _can_. :-)
--
Please note: my email address is munged; You can never browse enough
"There are no limits." -- ad copy for Hellraiser
In article <···············@world.std.com>, Kent M Pitman
<······@world.std.com> wrote:
> debugger, too. But Common Lisp's bread and butter isn't 10-line
> customization scripts--it's 10,000 and 100,000 line programs that do
> very complex things.
Kent, you are giving an interesting number and you are
mentioning the word "complex". I would be interested
in your thoughts about current application areas of
Common Lisp.
Who is using Common Lisp for developing commercial applications?
Why are companies choosing Common Lisp? How does a company
internally decide to use CL and why? If for example a networking
company would have to develop a control software for
large networks, how would the development team stumble across
Common Lisp? Are there some important capabilities that are currently
not offered by other tools? Is it still the AI heritage?
Is it "extreme OOP"? Is it "managing complexity"?
Is it "small team productivity"?
Since we are organizing the next Lisp User Group Meeting (February
next year), we think we then can get some answers from Lisp users.
> so stability/compatibility really matter.
Agreed!
--
http://www.lavielle.com/~joswig/
From: Kent M Pitman
Subject: Re: Is there a debugger or similar for Common Lisp?
Date:
Message-ID: <sfwk9djo7bj.fsf@world.std.com>
······@lavielle.com (Rainer Joswig) writes:
> In article <···············@world.std.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> > debugger, too. But Common Lisp's bread and butter isn't 10-line
> > customization scripts--it's 10,000 and 100,000 line programs that do
> > very complex things.
>
> Kent, you are giving an interesting number and you are
> mentioning the word "complex". I would be interested
> in your thoughts about current application areas of
> Common Lisp.
Common Lisp as a dialect arose because institutions with a large
investment in Lisp (primarily ARPA, actually, but also some
commercial entitites) were tired of the semantics of Lisp changing
daily and they wanted to be able to invest in something which was
both powerful and stable. My understanding is that they had proposed
Interlisp because it appeared to have the largest installed base,
and this caused the myriad Maclisp-variants to declare that they
differed in only-gratuitous ways which if solidified would constitute
a larger installed base than Interlisp. CL was the result, and
Interlisp was killed.
ARPA is pretty much the antithesis of the home hobbyist or the
simple scripting language, so it's not surprised it doesn't serve
that community. In order to serve those other communities, I think
some aggreessive subsetting would be in order. The CL design
committee didn't deny the importance of subsets; instead, we decided
our expertise was in the specification of the many common facilities
that Maclisp variants all had but that differed gratuitously in
interface. So we standardized those interfaces in order to beat
back the much petty bickering over small issues that were sapping
the strength of the CL community. Having this large base of standard
componentware DID succeed in this regard. I still have listings
of my own programs from way-back-when and they all started with a
LOT of pages of code I wrote over and over for nearly every system
in order to build up to a standard base to begin my domain-ware;
and in CL, I can omit that long prologue.
Although a general purpose language, I think CL continues to benefit
from its long association with the AI community and its focus on
features that accomodate rapid change and lack of specificity.
Quite honestly, I think just about everyone on earth including probably
every Lisp programmer has sought to eliminate their need for Lisp
because it's such a hassle being told you're not using a commodity
language. I know I have; I bet you have. But I don't stay with
Lisp because I'm at a Lisp company--I stay at a Lisp company because
I can't cope with a world without Lisp--at least until someone offers
a credible alternative. The fact is that other languages don't offer
all the features that Lisp does. Sometimes that's ok, so people use
C just because it's socially simpler in many environments. But
sometimes that's not ok, and you really need what Lisp can offer,
and there is no substitute.
As I said, Lisp is very general purpose and personally, since I have a
half dozen dialects of Lisp always at my fingertips, I never resort to
the other languages. But the places where I would feel compelled to
use Lisp are places involving "mixed/heterogeneous data" (i.e., not
just columns of fixed format floats, for which COBOL might suffice),
situations involving rapidly changing problem descriptions, situations
involving the need for fast turnaround between design and market or
rapid response to user demands. Why is this? Because features like
"loading new programs into a running Lisp to repair it without
restarting" (i.e., LOAD), "dynamic redefinition of functions, classes,
and methods from the console", CHANGE-CLASS under program control,
constructing and compiling programs while a program is running,
introspection (functions like FIND-SYMBOL, BOUNDP, FBOUNDP that
inspect data state; variables like *FEATURES* and functions like
FIND-PACKAGE that prod at system state; FIND-RESTART that inspect
dynamic control state) are things not offered in other languages.
They are things that specifically accomodate change, patching,
adaptability, etc. And when they are needed, static languages offer
no substitute. Also, multiple inheritance gives modular and flexible
recombination of tools without recompilation, whether in a
running image or between loads of images. Smalltalk is one of view
languages offering many of these features, but Smalltalk forces a
more rigorous and less flexible world model because of its insistence
on single (rather than multiple) inheritance.
> Who is using Common Lisp for developing commercial applications?
I'm not a sales person, but probably couldn't tell you even if I was.
This info tends to be proprietary except as individual vendors choose
to make noise. Many who use Lisp consider the choice a strategic
advantage they may not wish to herald.
> Why are companies choosing Common Lisp? How does a company
> internally decide to use CL and why?
Not sure how they do. I recommend at least watching for
characteristics like those I mentioned above, though there may be
many other reasons as well.
> If for example a networking
> company would have to develop a control software for
> large networks, how would the development team stumble across
> Common Lisp?
I'm going to pass on this question, which is really about advertising.
It's not that I don't care about ads, but I don't get to make the
decisions about what ads Harlequin places or doesn't place and why,
and I'd like not to second-guess the folks that do.
> Are there some important capabilities that are currently
> not offered by other tools? Is it still the AI heritage?
See above. Yes, I think the AI heritage is that trying to accomodate
cognitive models (including learning, which has redefinition/relinking
at its heart, and change of representation (growing new slots, etc.))
encouraged good features in Lisp. Many other languages accomodate
knowledge (statically); Lisp accomodates knowledge acquisition,
modeling, manipulation, etc. (dynamically).
> Is it "extreme OOP"?
It's more like common sense and avoiding the modern tendancy to conclude
mathematical definitions of OOP, like that a language without encapsulation
can't be OO. Something is OO if it's "linked" together, with appropriate
abstraction walls at the links, and if the links can be snapped to new values.
Lisp was OO before CLOS. It was OO when it figured out that redefining
a function dynamically was just a matter of consing a new function,
and then snapping the link from the name F from the old definition to the
new one; i.e., that it wasnn't about overwriting code vectors (mysterious)
but that it was just about
(setf (symbol-function 'F) new-definition)
and nothing more. That is the essence of what allows LOAD to work and what
allows interactivity to work and what allows people to understand Lisp in modular
chunks that mirror their own understanding. I'm not saying there's no value
in encapsulation and other things, but I'm saying that it's wrong to overlook
the simpler virtues of Lisp. Other languages just look at the indirection through
F's function cell as an extra memory cycle that is wasted and needs to be
optimized out, but all they EVER gain from it is O(1) speedup (i.e.,
computationally not significant) and what they lose in the process is the
power to redefine.
> Is it "managing complexity"?
I think more like "avoiding complexity". Imagine the complexity of a system
which does not acknowledge that change is a primitive thing and so tries to
statically type everything even in the presence of knowledge that shapes and
types of things will change. Whatever results is going to be baroque becuase
the truth is that there's a bug in the idea that static typing is appropriate.
> Is it "small team productivity"?
I think this is true but historically not a selling point. Experience shows
we don't gather group support from a team of programmers with the sales pitch
"Use Lisp and some of you can be fired"
It works better to talk about "empowerment", "flexibility", etc. Sometimes
that's the same as productivity--sometimes not.
> Since we are organizing the next Lisp User Group Meeting (February
> next year), we think we then can get some answers from Lisp users.
Hadn't heard about this. In the US? Where's it going to be? Sounds like it's
coming up pretty fast--I don't think you have time for papers... And my February
is already mostly booked... If it's really in Feb, I probably can't come.
I might suggest more notice... Sigh.
In article <···············@world.std.com>, Kent M Pitman
<······@world.std.com> wrote:
> > Since we are organizing the next Lisp User Group Meeting (February
> > next year), we think we then can get some answers from Lisp users.
>
> Hadn't heard about this.
Sigh. ;-)
> In the US? Where's it going to be?
Munich, early next year at OOP 98. See:
http://www.lisp.de/lugm/lugm98.html
Sounds like it's
> coming up pretty fast--I don't think you have time for papers... And my
February
> is already mostly booked... If it's really in Feb, I probably can't come.
> I might suggest more notice...
I have posted a a message about this some time ago. You may
have missed it. We will provide more information, soon.
Rainer Joswig
--
http://www.lavielle.com/~joswig/