HDTenEightyP/NetNews huggingface dataset:
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date: 26 Jan 93 19:13:27 GMT
Organization: AIAI, University of Edinburgh, Scotland

In article <1993Jan20.181244.8680@netlabs.com> lwall@netlabs.com (Larry Wall) writes:

>The obvious answer is almost TOO obvious.  People prefer "horrible" languages.

Some do; others don't.  I think it's a mistake to think one side or
the other must be wrong.  That is: there's more than one good way
to do programming languages.

>I believe in the waterbed theory of linguistics.  If you push down
>here, it pops up there.  The design of Lisp pushed down so hard on the
>morphology that it bulges out everywhere else.  Lisp is your classical
>Turing Tarpit.  If expressivity only measures what's possible, Lisp is
>wonderful.  If it measures what's easy to say and understand, Lisp gets
>a big yawn from most folks. 

One thing this leaves out is that many people find Lisp more readable
and easier to understand than other programming languages.
From: vachon@gel.ulaval.ca (Pierre Vachon)
Newsgroups: comp.lang.lisp
Subject: CPU time question
Date: 21 Jan 93 19:32:19 GMT
Organization: Universite Laval


Hi,

If someone could explain this, I would be grateful:

When I run something in Sun Common Lisp 4.0.2 that *should* take all
the available CPU time, I find (via the perfmeter) that it only uses
about 70%. However, if I volutarily run the same job in the debugger
(that is, at the "->" prompt), the perfmeter now rises to it's full
100%!  The same is true if the program is compiled...

If you think you know why, I'd love to know...

Thanks!

Pierre Vachon
vachon@gel.ulaval.ca
Newsgroups: comp.lang.lisp
From: bbirch@hemel.bull.co.uk (Bill Birch)
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Organization: Bull HN UK
Date: Wed, 27 Jan 93 18:23:01 GMT

A modern fairy tale:

Once upon a time I used to use macro-processors like GPM and UNIX's
m4. I used to generate test scripts for testing X.25 and 
Z80 assembler with them. These are good tools for creating ad-hoc
mini-languages.

Then somebody suggested I look  at the Lisp syntax, because
is was just as adaptable (read feature-less) as m4. I did 
and was immediately hooked, because Lisp has structure, unlike
macro-processors.

Since then I have used Lisp syntax to create mini-languages for a variety of 
purposes including: An assembler for Finite-state machines for
a PABX configuration; for storing interactive video overlay sequences; 
a language for specifying call-processing state tables; and etc...
All these have been serious industrial applications. 

I particularly like being able to parse mini-langauages in a single 
statement: READ. I prefer it to FORTH syntax which I did experiment
with in a protocol testing language. The structure is more obvious
in Lisp. 

So as far as I am concerned, the Lisp syntax is absolutely vital, it 
is what attracted me to the langauage in the first place. But 
then my use of languages is driven by real need rather than by
the impositions of University lecturers :-)

[I enjoyed that!]

Bill



--
 Bill Birch             	|	B.Birch@uk03.bull.co.uk
 Bull Info. Sys. Ltd.   	|       Bull Tel: 773 4770
 Maxted Road,         		|	Bull Mail: HM14 UK03 
 Hemel Hempstead,        	|	Tel: +44 442 884770
 HERTS, HP2 7DZ, U.K.         	|	Fax: +44 442 884570
                Aviate, Navigate, Communicate...
Newsgroups: comp.lang.lisp
From: bbirch@hemel.bull.co.uk (Bill Birch)
Subject: Re: Why Isn't Lisp a Mainstream Language?
Organization: Bull HN UK
Date: Thu, 21 Jan 93 16:07:02 GMT

But surely Lisp IS a mainstream language!  It has survived the test 
of time. Whatever happened to ALGOL, et. al.? Just because a
language is not used by Joe Programmer doesn't mean that
it is dead. After all, Joe Programmer probably used Lisp
at College. He may use Lisp concepts in his 'C' programs.

By analogy, Buddy Holly is not a "mainstream" artist these
days, but his influence on other artists is there. 
 
Bill
--
 Bill Birch             	|	B.Birch@uk03.bull.co.uk
 Bull Info. Sys. Ltd.   	|       Bull Tel: 773 4770
 Maxted Road,         		|	Bull Mail: HM14 UK03 
 Hemel Hempstead,        	|	Tel: +44 442 884770
 HERTS, HP2 7DZ, U.K.         	|	Fax: +44 442 884570
                Aviate, Navigate, Communicate...
Newsgroups: comp.lang.lisp
From: kpc@pluto.arc.nasa.gov (k p c)
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Originator: kpc@zog.arc.nasa.gov
Reply-To: kpc@ptolemy.arc.nasa.gov
Organization: NASA Ames Research Center AI Research and Aero Branches;
	Sterling.
	<19930122162651.0.SWM@SUMMER.SCRC.Symbolics.COM>
	<dfs.727723285@noonian> <1jpi0sINN47q@elroy.jpl.nasa.gov>
	<dfs.727732459@kehleyr>
Date: Fri, 22 Jan 1993 22:20:48 GMT

there are technical solutions to that problem, aren't there?  i recall
there being something called presto that would eliminate parts of lisp
that weren't being used.
-- 
i'm open to comparing research career notes with other cogsci/cogneuro people.
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date: 27 Jan 93 13:32:00 GMT
Organization: AIAI, University of Edinburgh, Scotland

In article <dfs.727757157@kehleyr> dfs@doe.carleton.ca (David F. Skoll) writes:

>Providing lots of special-purpose functions which cannot be removed at
>run-time is bad news.  I have no problems with lots of special-purpose
>functions, but you shouldn't be forced to have them all, whether you
>need them or not.  The CL standard makes no provisions for excluding
>some functions from a run-time environment. 

But why does the _standard_ (or other language definition) have to
do this?  

>Absolutely.  But if you don't want to use a certain C function, you don't
>link it in.  Your programs have no overhead for unused functionality.
>If Common Lisp had some mechanism for this, then my criticism would not
>be valid.

The C language has no mechanism for this.  It's the linkers that do
it.

So, the right question is: is there something about the language
that rules out implementation strategies that omit unneeded code?
And the answer is "yes".  Almost anything could be called, eg by

   (apply (read) (read))

So implementation either have to provide a way for the user to
say that only the functions that are directly called will be
called or else provide a way to load in functions when needed.
The latter approach has been around for a long time in the
form of "autoloading".

However, such tricks won't work very well if programs tend to
require most of CL, perhaps because CL is so intertwined.  This
is a standard criticism of CL.  ERROR requires FORMAT, etc.
But how true is it?  Well, I think there's evidence that it's
sufficiently true to be a problem.  On the other hand, why 
should it be fatal.  What if, for instance, CL is packaged as
a shared library (as in WCL)?  It's a fairly big shared library,
but then so is X.

-- jd
Newsgroups: comp.lang.lisp
From: jimc@tekcae.cax.tek.com (Jim Carden)
Newsgroups: comp.lang.lisp
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date: 22 Jan 93 01:07:19 GMT
Organization: Tektronix, Inc., Beaverton,  OR.

In article <1993Jan21.230642.18561@netlabs.com> lwall@netlabs.com (Larry Wall) writes:
>In article <19930120191159.1.SWM@SUMMER.SCRC.Symbolics.COM> SWM@stony-brook.scrc.symbolics.com (Scott McKay) writes:
>: In what way is Lisp "bland ... all the way through"?
>
>There's little visual distinctiveness to distinguish mentally
>distinctive constructs.

Written by the designer of Perl. Well, Perl certainly cannot be accused of being bland.

To each his own, I guess. I cannot disagree more with almost everything Larry Wall
has written on this subject. As far as syntax goes, LISP and Perl are about as far apart
as they can be (and I hope LISP does not budge).

Newsgroups: comp.lang.lisp
From: lynch@ils.nwu.edu (Richard Lynch)
Subject: Lisp image size (was Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?))
Followup-To: comp.lang.lisp
Organization: ILS
Date: Mon, 25 Jan 1993 18:07:04 GMT

In article <dfs.727729181@crusher>, dfs@doe.carleton.ca (David F. Skoll)
wrote:
> Actually, it wouldn't be too bad in C (if you can ignore the
> fixnum/bignum problems :-)) I agree that Lisp has many built-in
> conveniences.  Maybe too many - we have Allegro Common Lisp on our Sun
> network, and the image is 11MB long.  That's a huge overhead, and
                            ^^^^
> anyone supporting the full Common Lisp spec probably couldn't do it in
> much less.

Ye Gods!  And we're complaining about the 2.5MB size of MCL!!!
[Yes, it's full Common Lisp spec.]
Newsgroups: comp.lang.lisp
From: lwall@netlabs.com (Larry Wall)
Subject: Re: Lisp vs English (was Re: Why Isn't Lisp a Mainstream Language?)
Organization: NetLabs, Inc.
Date: Thu, 28 Jan 1993 21:04:14 GMT

In article <19930127153328.7.SWM@SUMMER.SCRC.Symbolics.COM> SWM@stony-brook.scrc.symbolics.com (Scott McKay) writes:
: I believe that an important point that is being lost in the shuffle is
: whether or not the language is malleable enough to provide "control
: abstraction" (analogous to the way classes, structures, etc., provide
: data abstraction).  If the language cannot provide good control
: abstraction, then *it's not good enough*.

The question is, of course, good enough for what?

: (Of course, the lack of
: control abstraction does not render a language useless any more than the
: lack of data abstraction does -- it just makes life much more difficult
: than it needs to be, and really, isn't programming is hard enough
: already?)

Depends on what you trade away to get your abstraction.  Abstraction
doesn't come for free.  Abstraction is most appealing to those folks
who are highly intelligent.  By definition, they're in the minority.
Ordinary people tend to avoid abstraction: "Forget that ivory tower
stuff, just get the job done."

People learn to love Lisp from they're instructors, fine.  I'm not
saying we shouldn't try to teach people to do abstraction.  But
let's not expect people to like doing what they don't like to do.
Castigating the Huddled Masses for huddling is a mild form of snobbery.

: In my opinion, almost every modern programming language fails to provide
: control abstraction.  One reason Lisp manages to provide it is that the
: syntax of the language makes it easy to use Lisp as its own meta-
: language.  There are other ways to do this (e.g., add features to the
: language that allow the language to talk about its own parsed
: representation),...

Gee, when you point out the upside of Lisp's narcissism, it's central.
When I point out the downside, you tell me I'm stuck in 1972.

:                    ...but to the best of my knowledge, there aren't any
: languages that do this in any serious way.

Thank goodness.  Simplify here, complexify everywhere else.  TANSTAAFL.

Your turn to have the last word.

Larry Wall
lwall@netlabs.com
Newsgroups: comp.lang.lisp
From: sasmsr@zinfande.unx.sas.com (Mark S. Riggle)
Subject: Re: Why Isn't Lisp a Mainstream Language?
Originator: sasmsr@zinfande.unx.sas.com
Date: Fri, 22 Jan 1993 19:26:20 GMT
Organization: SAS Institute Inc. Cary NC



I think that one aspect of Lisp syntax that can be
confusing to lisp novices is that the first
position of a list is the functional call, EXCEPT
in certain forms. Like the lambda argument list,
'let', 'do' and others, including some user defined
macros.

ie. te consider the following fragments:

  (let
    ((fred (x))
     (sam  (y))))

  (letter
    ((fred (x))
     (sam  (y))))

So syntactically they look the same, but we all
know they are semantically vastly different, except
of course we have made a macro definition for
letter that is the same as say let or let*.

I think it actually takes quite some exposure to
Lisp before this semantic transformation is natural
and automatic to someone.

-- 
=============================================================
Mark Riggle             [Professional Lisp Bigot]
sasmsr@unx.sas.com                   
SAS Institute Inc.,                  
SAS Campus Drive, Cary, NC, 27513     
(919) 677-8000
From: grant@pentagon-gw.army.mil (Pete Grant)
Newsgroups: comp.lang.lisp
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date: 24 Jan 93 03:26:56 GMT
Organization: U.S. Army Artificial Intelligence Center, The Pentagon

In article <C1773p.C6x@dei.unipd.it> gandalf@sabrina.dei.unipd.it (ROBERTO AVANZI) writes:
>In article <1993Jan20.181244.8680@netlabs.com> lwall@netlabs.com (Larry Wall) writes:
>>
>>Please reply in Lisp, not English.  It's so much more expressive...
>>
>>Larry Wall
>>lwall@netlabs.com
>
>: (GETPROP 'LISP 'BEAUTY)
>"MARVELOUS"
>
>: (GETPROP 'PERL 'USEFULNESS)
>"GREAT"
>
>Cheers
>Roberto Avanzi

Cute, but what dialect?  I assume GETPROP <=> GET??

Pete.
From: gat@forsight2.jpl.nasa.gov (Erann Gat)
Newsgroups: comp.lang.lisp
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Date: 22 Jan 1993 19:30:36 GMT
Organization: Jet Propulsion Laboratory
NNTP-Posting-Host: forsight2.jpl.nasa.gov

In article <dfs.727723285@noonian> dfs@doe.carleton.ca (David F. Skoll) writes:
>I've noticed a thread extolling the beauty of Lisp syntax.  While I agree
>that mostly, Lisp syntax is easy to understand and consistent, I wonder
>what sort of mental disease struck the creators for the "format" function.
>Take a look at all the baroque format directives in Common Lisp.  I mean,
>who really needs the number 394829348234982435 formatted in English words??

Someone writing a program to print checks might find ~R to be quite
useful.  (You seem to be complaining about two orthogonal issues, by
the way, the syntax of format strings and their functionality.  The
syntax I will concede is not a model of clarity, but it is not represent-
ative of the rest of the language.)

Erann Gat
gat@aig.jpl.nasa.gov

Newsgroups: comp.lang.lisp
From: john@thelonius.mitre.org (John D. Burger)
Subject: Re: Lisp vs English (was Re: Why Isn't Lisp a Mainstream Language?)
Keywords: Lisp, English, Irrelevancy
Organization: Artificial Intelligence Center, MITRE Corporation, Bedford, MA
Date: Wed, 27 Jan 1993 20:46:33 GMT

This has very little, if anything, to do with this thread, so I'll stop after
this post.  I'm surprised there weren't more replies to my original post, it
was such a perfect flame magnet.  :)

Randy Crawford (crawford@boole.mitre.org) writes:

  The horse ran through the barn, fell.'  No, English isn't entirely
  unstructured or else it'd be unintelligible.  But the number of
  irregularities and contextual dependencies makes it at least context
  sensitive, and fully unrestricted as far as I'm concerned. That's pretty
  unstructured when compared to CFG programming languages

I'm not sure what your garden path sentence was an example of, but it's
certainly parseable, with or without the comma (which, by the way, I believe
would be considered ungrammatical by proscriptive grammarians).  It even has
only one parse.  As far as grammatical complexity is concerned, no one has
proven very convincingly that English, in particular, is syntactically
context-sensitive.  Sorry.  Even if English were trans-context-free, it
needn't be unstructured, by which you mean, I presume, something like
"having few formal requirements".  And I don't know what "unrestricted"
means.  "horse barn ran through the" isn't English, so English has some
restrictions, at least.

  If it isn't relatively unstructured then it's relatively structured. 
  Therefore it ought to be relatively easy to specify rules for parsing it. 
  Yet that's shown itself to be *highly intractable*.  So I consider English
  to be comparatively unstructured.

Getting right all the nooks and crannies of a natural language grammar is
certainly hard.  It hasn't yet been done.  Nonetheless, systems exist that
correctly parse better than 99 percent of, say, the New York Times, or even
harder texts, correctly.  Your may disagree, but I think that's possible
because there's lots of structure there.  Of course, a C (or even Lisp)
compiler correctly parses much closer to 100 percent of its respective
language.  It better.

     If I can't parse your trivially written sentence, and few other English
     speakers can either, then it ain't English, by definition

  `The girl saw the boy on the hill with a telescope.'  Legal English. 
  Trivial.  I can think of at least four ways to parse this.  By your
  definition, I'm illiterate because I can't parse this.
  I prefer to think that your definition of English is flawed.

I'm confused.  You say "I can think of at least four ways to parse this",
then you say "I can't parse this".  Is the problem that there is more than
one parse?  That's certainly true.  Nonetheless, the sentence can be parsed.

As far as my definition of English is concerned, I don't know what other one
there is.  Maybe I missed the announcement of "ANSI English 93".

Rather arbitrarily, I'll stop now.

John Burger                                                 john@mitre.org
Newsgroups: comp.lang.lisp
From: hall@aplcenmp.apl.jhu.edu (Marty Hall)
Subject: Re: Why Isn't Lisp a Mainstream Language?
Organization: AAI Corp AI Lab, JHU P/T CS Faculty
Date: Mon, 25 Jan 1993 20:05:23 GMT

In article <1993Jan22.145226.16629@crd.ge.com> halverson@crd.ge.com 
(Pete Halverson) writes:
[...]
>Personally, when I'm comparing languages, syntax is way down on my list.
[...]
>Why, then, do others make such an issue of Lisp's syntax? 

One reason, in my experience, is the context in which they were introduced
to LISP. I teach AI and AI Programming to MS students at Johns Hopkins. 
Almost without exception, students who come into my classes with a smattering
of LISP background (eg in an undergrad course) are biased against the syntax
*from experience*. They were generally introduced by people who were not
serious LISP programmers and in a context (an AI course) where understanding
the language was not a priority. Few heard anything about LISP style or the
importance of indentation or the ideas of functional programming. Not 
everyone who takes the AI Programming course here turns into a LISP zealot, 
but I do think it is fair to say that few are still troubled by the syntax.

						- Marty
(proclaim '(inline skates))
Newsgroups: comp.lang.lisp
From: emcoop@bnr.ca (hume smith)
Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
Organization: Bell-Northern Research, Ottawa, Canada
	<19930122162651.0.SWM@SUMMER.SCRC.Symbolics.COM>
	<dfs.727723285@noonian> <1jpi0sINN47q@elroy.jpl.nasa.gov>
	<dfs.727732459@kehleyr>
Date: Fri, 22 Jan 1993 21:10:06 GMT

In article <dfs.727732459@kehleyr> dfs@doe.carleton.ca (David F. Skoll) writes:

   And people have been arguing that Lisp is a very good general
   purpose language.  A function that prints English names of numbers
   is a pretty special-purpose function!

hmm...  what makes a general purpose language?  does providing lots of special
functions have anything to with it?

i think you can turn the argument around (classic usenet fashion) and say
that functions that only print numbers in digits is pretty special purpose
too.  especially, functions that read and write floating point in base ten
only (my personal beef - there's no reason it can't be done in other bases!).

i think it's a nice little bonus feature.  when do you ever use most of the
functions in the UNIX C libraries?  isn't it handy the one time in a hundred
you need them - you can keep on truckin' instead of trying to figure out how
to patch around the hole?
--
Hume Smith                                Honour sick and davey cris-cross
hume.smith@acadiau.ca                     McTruloff sentimie
emcoop@bnr.ca                             A parsnip inner pair threes.
From: mlg@siemens.com (Michael Greenberg)
Newsgroups: comp.lang.lisp
Subject: Re: Common Lisp error (Sun)
Date: 22 Jan 93 22:11:04 GMT
Distribution: usa
Organization: Siemens Corporate Research, Princeton (Plainsboro), NJ

rmoises@titan.rdd.lmsc.lockheed.com (Roger Moises) writes:

>1. Is there some glaring incompatibility here that I've missed?

>2. Is there some SunOS parameter that must be changed?

You must either:

- build a new lisp image. Some OS stuff changed that prevents the
same image from running under 4.1.[12] and 4.1.3 

- There is a patch available from Franz which will allow you to build
a single image that will work on 4.1.[123].  You can contact
cl-bugs@franz.com to find out how to get the patch.

-- 
Michael Greenberg                      email: mgreenberg@siemens.siemens.com
Siemens Corporate Research             phone: 609-734-3347
755 College Road East                  fax: 609-734-6565
Princeton, NJ 08540
Newsgroups: comp.lang.ada
From: dag@bellman.control.lth.se (Dag Bruck)
Subject: Comments on Ada vs. C++ panel
Organization: Department of Automatic Control, Lund, Sweden
Date: Thu, 21 Jan 1993 07:41:13 GMT


Last week there was a panel on Ada vs. C++ in Monterey.  Would anyone
who attended post a personal report on comp.lang.ada?

Thanks in advance.

Dag Bruck
--
Department of Automatic Control		E-mail: dag@control.lth.se
Lund Institute of Technology
P. O. Box 118				Phone:	+46 46-104287
S-221 00 Lund, SWEDEN			Fax:    +46 46-138118
Newsgroups: comp.lang.ada
From: vtg@mitre.org (Victor Giddings)
Subject: Re: Why and how do organizations select the OO
Followup-To: comp.lang.ada
Organization: The MITRE Corporation
Date: Mon, 25 Jan 1993 21:44:12 GMT

> In article 1jo805INNfe@emx.cc.utexas.edu, kalakota@emx.cc.utexas.edu (Ravi Kalakota) writes:
>
>	Why and how do organizations select the OO approach to Software Eng.
> 
>... There is an amazing lack of objective, evaluative literature 

Before this goes too far ...

No one PROVED that a word processor is "better" than a typewriter (in fact
some studies suggested that they are equally productive and that quality
remained a subjective matter).  That does not, however, give me ammunition
to take away my secretary's word processor (let alone the courage).  And
there is little debate in industry any more.

>on the selection of methodologies
>in software engineering. We seem to be carried away by the bandwagon effect
>and are not spending enough time understanding the pluses and minuses of
>new methodologies, their effectiveness in various types of application
>development areas and their effect on people. I may sound pessimistic but
>it is definitely time that we understood what external factors impact the
>selection of methodologies and what impact does the selection of a methodology
>have on the effectiveness of the development group. While the technical side
>has progressed and is progressing, the management side is limping along with
>lame theorizing which almost always has no practical value.    


Ultimately, we will probably have to depend on the informed opinion of
experienced practicioners.  Real projects have too many variables to serve
as controlled experiments, even if someone were willing to fund parallel
developments.  


> [much deleted]
Newsgroups: comp.lang.ada