Does anyone have any idea if there is any significant
Lisp work being done in the UK? I know of a few in the
defence arena, but very little in the commercial domain.
The reason I ask is to gauge how much effort I should
invest in trying to remain a Lisp programmer, before
giving it up as a lost cause in the UK and moving on to
the more mundane world of C/C++.
Thanks for any info,
Guy Footring
Symbolics Ltd.
In article <··········@marble.Britain.EU.net> ···@BLACKWATER.symbolics.co.uk (Guy) writes:
From: ···@BLACKWATER.symbolics.co.uk (Guy)
Newsgroups: comp.lang.lisp
Date: 6 Apr 1994 09:25:50 GMT
Organization: Symbolics Ltd.
Does anyone have any idea if there is any significant
Lisp work being done in the UK? I know of a few in the
defence arena, but very little in the commercial domain.
The funny thing is, my first thought was to suggest that the people best
placed to answer such a question would be Lisp vendors...
The reason I ask is to gauge how much effort I should
invest in trying to remain a Lisp programmer, before
giving it up as a lost cause in the UK and moving on to
the more mundane world of C/C++.
Planning on moving job, perhaps? Now, at least...
Thanks for any info,
Guy Footring
Symbolics Ltd.
--
--------------------------------------------------------------------------
Robert Inder HCRC, 2, Buccleuch Place, Edinburgh EH8 9LW Scotland
--------------------------------------------------------------------------
Imminent death of the Net predicted due to Mosaic traffic overload...
For details, see http://www-server12.nat-enq.com:www12/news18/article354426
In article <···················@compton.cogsci.ed.ac.uk>,
Robert Inder <······@cogsci.ed.ac.uk> wrote:
>
>In article <··········@marble.Britain.EU.net> ···@BLACKWATER.symbolics.co.uk (Guy) writes:
>
> Does anyone have any idea if there is any significant
> Lisp work being done in the UK? I know of a few in the
> defence arena, but very little in the commercial domain.
>
I work freelance, and in my permie days was fortunate enough to work on
a project using Lisp and CLOS. Every now and then I see the odd permie
ads for people in the Herts/Cambs area for Lisp folks, normally for AI-
type work.
BT are doing AI/Expert Systems work with CLOS/Lisp (using the Harlequin
LispWorks env. I believe) for NW Management/Planning systems (I have been
approached for contract work with them nearly every April for the last 3
years :-) ) . There is also some company in Essex (whose name I couldn't
extract from an agency :-( ) who were about to start developing some sort
of AI system for a telecoms client around a year ago.
> The reason I ask is to gauge how much effort I should invest in trying
> to remain a Lisp programmer, before giving it up as a lost cause in the
> UK and moving on to the more mundane world of C/C++.
The Lisp/CLOS work I did was under the auspices of an ESPRIT project in
1990, where the requirement was for a platform that could support Lisp
(I also did quite a bit of Objective-C work as well) . I haven't written
one line of those since that project, and have been in the 'mundane' world
of C++ since.
I may not be anywhere near as good now with the above as I was, but I
certainly don't let my knowledge slide below a 'baseline' (where I can
pick up the CLtL, Sonya Keene, AMOP books and get 'fully operational'
again in 2-3 weeks) . I suggest you do the same.
> Thanks for any info,
No problem.
Regards,
Steven Perryman
···@bnr.co.uk
Can someone tell me the dates, etc of the Lisp and Functional
programming Conference or where to find the required information?
If it's been announced on the net, I seem to have missed it.
Jeff Dalton,
AI Applications Institute, ········@ed.ac.uk
Edinburgh University.
In article <··········@cogsci.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
>Can someone tell me the dates, etc of the Lisp and Functional
>programming Conference or where to find the required information?
June 27-29 at Walt Disney World in Florida. The contact is Robert R.
Kessler, ·······@cons.cs.utah.edu.
>If it's been announced on the net, I seem to have missed it.
I saw something a week or so ago that announced an FTPable preliminary
program. I don't remember the location, though, but I'm sure Kessler will
be able to point you to it.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar
Guy (···@BLACKWATER.symbolics.co.uk) wrote:
: Does anyone have any idea if there is any significant
: Lisp work being done in the UK? I know of a few in the
: defence arena, but very little in the commercial domain.
: The reason I ask is to gauge how much effort I should
: invest in trying to remain a Lisp programmer, before
: giving it up as a lost cause in the UK and moving on to
: the more mundane world of C/C++.
If you are thinking of moving job, the best thing to do would
be to send your CV to agencies which specialise in that area.
I've been away from the UK for some time, but I seem to recall
that the John Ford agency had a fair amount of Lisp work on their
books. You can get their number from any of the usual UK trade
magazines.
BTW, since you are currently at Symbolics, then presumably your
customers are probably the people who are doing this kind of work.
hope this helps,
john c.
In article <··········@marble.Britain.EU.net> <···@BLACKWATER.symbolics.co.uk> writes:
>Does anyone have any idea if there is any significant
>Lisp work being done in the UK? I know of a few in the
>defence arena, but very little in the commercial domain.
>
>The reason I ask is to gauge how much effort I should
>invest in trying to remain a Lisp programmer, before
>giving it up as a lost cause in the UK and moving on to
>the more mundane world of C/C++.
>
>Thanks for any info,
>Guy Footring
>Symbolics Ltd.
I'm afraid the future belongs to C++. You have to understand that
computing has changed dramatically in the last 15 years. Back in the
days when computers cost $100K, ran like slugs, and 256kB of main
memory was considered large, Lisp made sense. It allowed programmers
to quickly develop complex programs, trading development time and
programmer sanity for a certain penalty in execution time and memory
utilization.
Today personal computers cost $5K, run 60 times faster, and 16MB is
common. Consequently, it is necessary to use a lower-level language
like C++ in order to eke out the last bit of hardware efficiency, even
if that means extra work and aggravation for the programmer. With
such phenomenal improvements in hardware costs and performance, simple
economics dictate the shift from Lisp to C++. Why do diehard Lisp
hackers find this so difficult to grasp?
--
_____________________________________________________________________
__ __ __ __ __ __ __ __ __ __ __
|__| |__| |__| |__| |__| |__| |__| |__| |__| |__| |__| |
Steven Vere ····@netcom.com
Boulder Creek, California
__ __ __ __ __ __ __ __ __ __ __
|__| |__| |__| |__| |__| |__| |__| |__| |__| |__| |__| |
_____________________________________________________________________
>>>>> "NotQuite" == Steven Vere <····@netcom.com> writes:
In article <··············@netcom.com> ····@netcom.com (Steven Vere) writes:
NotQuite> Consequently, it is necessary to use a lower-level language
NotQutie> like C++ in order to eke out the last bit of hardware efficiency,
NotQuite> even if that means extra work and aggravation for the programmer.
NotQuite> With such phenomenal improvements in hardware costs and
NotQuite> performance, simple economics dictate the shift from Lisp to
NotQuite> C++. Why do diehard Lisp hackers find this so difficult to
NotQuite> grasp? --
Excuse me for sticking my head in the sand but if computers are
so fast and generous with the memory, isn't it the perfect time to be
using LISP?
A more plausible reason for C++'s popularity is that mass-market
applications are fairly cut and dried. C keeps the apparently large
number of hopelessly-clueless-factory-programmers employed.
Marcus Daniels
In article <····················@tdb.ee.pdx.edu> ······@ee.pdx.edu (Marcus Daniels) writes:
A more plausible reason for C++'s popularity is . . .
I always thought that this was one of those situations where general
stupidity suffices as a plausible explanation. Seriously, *many* of
the C++ programs that I see that actually do anything interesting are
larger than lisp executables, kill their performance with (among other
things) ad hoc memory `management' and are *much* harder to maintain.
On the other hand C/C++ are no worse than any other assemblers . . . .
--
Rick Busdiecker <···@lehman.com> and <···@cmu.edu>
Lehman Brothers Please do not send electronic junk mail!
388 Greenwich Street
New York, NY 10013 ``I hate quotations.'' - Ralph Waldo Emerson
In article <··············@netcom.com> ····@netcom.com (Steven Vere) writes:
> I'm afraid the future belongs to C++. You have to understand that
>computing has changed dramatically in the last 15 years. Back in the
>days when computers cost $100K, ran like slugs, and 256kB of main
>memory was considered large, Lisp made sense. It allowed programmers
>to quickly develop complex programs, trading development time and
>programmer sanity for a certain penalty in execution time and memory
>utilization.
> Today personal computers cost $5K, run 60 times faster, and 16MB is
>common. Consequently, it is necessary to use a lower-level language
>like C++ in order to eke out the last bit of hardware efficiency, even
>if that means extra work and aggravation for the programmer. With
>such phenomenal improvements in hardware costs and performance, simple
>economics dictate the shift from Lisp to C++. Why do diehard Lisp
>hackers find this so difficult to grasp?
The only thing wrong with this argument is that it isn't true. I have
'looked over the shoulders' of several large C++ systems, and I believe
that the equivalent Lisp program would have been/is faster/smaller than
the corresponding C++ program.
The approach to C++ memory management taught in C++ texts and used in
most applications is reference counting. Due to some C++-specific
brain damage which costs a bundle due to excess copying on every
overloaded assignment, plus the overhead of reference counting v. GC,
some C++ programs probably run 5X slower than their Lisp counterparts.
Joel Bartlett amazed the people at DEC when he speeded up a major C++
CAD program by 5X by replacing ref counting with a copying GC.
A large govt-funded project which will remain anonymous got the bright
idea to recode a very large AI system which ran on a number of networked
Lisp machines into C++ 'so that it would run faster'. The Lisp code
ran at 1/3 real time at that time ('89??). It is now 1994 and the project
has yet to achieve 1/10 of the functionality of the Lisp code. If they
had simply sat on their hands for a couple of years, and then purchased
new hardware, they would be up and running 100% and in real-time by now.
(My own guess was that a little tuning on the network code and some extra
memory would have achieved 100% of real-time in 1989, as well.)
In every case I've seen where 'Lisp is slow', it is invariably cockpit
error and/or incredibly bad algorithms (e.g., linear searching) that are
the fault, not the language implementation. The world has been fed a
crock of shit about the speed of C++, and they ate it.
The issues that govern performance of large programs are not the same as
those that govern performance of small programs. Lisp systems have always
been tuned for large systems and large benchmarks. You can't decide to
run your 256 Mbyte scheduling system on a particular piece of HW or language
based on the performance of the TAK benchmark, which runs entirely within
the CPU chip on modern machines.
The best thing that every happened to Lisp was C++. Its manual is almost
as large as the Common Lisp manual, and it's implementations now require
just as much memory. You can now go to your boss and say with a straight
face that you can save memory and gain speed by switching from C++ to Lisp.
Make a small change at the base of the C++ hierarchy, and watch in
horror as the entire system collapses in a mass of compilation,
linking and new bugs.
>>>>> "Henry" == Henry G Baker <······@netcom.com> writes:
In article <················@netcom.com> ······@netcom.com (Henry G. Baker) writes:
Henry> Make a small change at the base of the C++ hierarchy, and watch
Henry> in horror as the entire system collapses in a mass of
Henry> compilation, linking and new bugs.
Even with loosely bound Objective C and dynamic linking
the words `linker hell' ring true.
From: Kirk Rader
Subject: Re: Commercial Lisp Work in UK??
Date:
Message-ID: <CoGqpE.95J@triple-i.com>
In article <················@netcom.com> ······@netcom.com (Henry G. Baker) writes:
[...]
>The approach to C++ memory management taught in C++ texts and used in
>most applications is reference counting. Due to some C++-specific
>brain damage which costs a bundle due to excess copying on every
>overloaded assignment, plus the overhead of reference counting v. GC,
>some C++ programs probably run 5X slower than their Lisp counterparts.
>Joel Bartlett amazed the people at DEC when he speeded up a major C++
>CAD program by 5X by replacing ref counting with a copying GC.
>
>A large govt-funded project which will remain anonymous got the bright
>idea to recode a very large AI system which ran on a number of networked
>Lisp machines into C++ 'so that it would run faster'. The Lisp code
>ran at 1/3 real time at that time ('89??). It is now 1994 and the project
>has yet to achieve 1/10 of the functionality of the Lisp code. If they
>had simply sat on their hands for a couple of years, and then purchased
>new hardware, they would be up and running 100% and in real-time by now.
>
>(My own guess was that a little tuning on the network code and some extra
>memory would have achieved 100% of real-time in 1989, as well.)
>
>In every case I've seen where 'Lisp is slow', it is invariably cockpit
>error and/or incredibly bad algorithms (e.g., linear searching) that are
>the fault, not the language implementation. The world has been fed a
>crock of shit about the speed of C++, and they ate it.
>
>The issues that govern performance of large programs are not the same as
>those that govern performance of small programs. Lisp systems have always
>been tuned for large systems and large benchmarks. You can't decide to
>run your 256 Mbyte scheduling system on a particular piece of HW or language
>based on the performance of the TAK benchmark, which runs entirely within
>the CPU chip on modern machines.
>
>The best thing that every happened to Lisp was C++. Its manual is almost
>as large as the Common Lisp manual, and it's implementations now require
>just as much memory. You can now go to your boss and say with a straight
>face that you can save memory and gain speed by switching from C++ to Lisp.
>
>Make a small change at the base of the C++ hierarchy, and watch in
>horror as the entire system collapses in a mass of compilation,
>linking and new bugs.
At the risk of throwing gasoline on an already raging flamewar, I must
say that it seems to me that anyone who says "language X is better
than language Y" (or "platform X is better than platform Y", or
"programming paradigm X is better than programming paradigm Y", etc.
etc.) is betraying a rather parochial bias. I have worked with a wide
variety of languages, operating systems, and platforms on everything
from real-time embedded systems (hardware control, data collection and
analysis) to high-level applications (knowledge- and model-based
expert systems, high-end computer graphics.) I am familiar with
professional software development in assembler, C, C++, and lisp (for
an example of my lisp experience, I am a former Symbolics Graphics
Division employee and a current Triple-I Digitial Media Group
employee, the latter being the group which was formed to continue work
on the projects originally developed by SGD after it went out of
business.) My own feeling is that all popular programming languages
have their strengths and their weaknesses, and it is only sensible to
use the tool best fitted to the particular task. The posting, above,
criticizes C++ as a language because many applications'
memory-management are implemented using less-than-ideal techniques,
but proceeds to exonerate lisp's putative inefficiencies on the
grounds of those same sort of common programming mistakes. I know
from personal experience that it is in fact possible to create
well-written programs in either C++ or lisp, and that for some
application domains the one makes life easier while in other
application domains the other will have the advantage.
For example, note that "real time" does not mean the same thing as
"fast". It does mean that every operation will complete in not more
than a predictable amount of time, so that a program monitoring and/or
controlling a piece of hardware can be guaranteed able to service all
of the physical events it is designed to interact with (of course the
predicated amount of time must also be short enough to keep up with
the hardware, hence the usual elliding of the concepts "real-time" and
"fast".) While in most actual lisp implementations it is possible to
code around the problems for such predictability caused by its
memory-management and other run-time strategies, my feeling is that it
is much easier to achieve that kind of behavior in C/C++. On the
other hand, knowledge-based and simulation systems are made much more
difficult to implement without a lisp-like language's features. As
for converting existing lisp applications to C/C++, I agree that it is
seldom a worth-while undertaking. If the code really benefits from
lisp's features, it will simply require reimplementing the missing
parts of the lisp run-time system in the supposedly-faster target
language (the example of coding a garbage-collector in C++ is a
perfect illustration, in my view, not of what is wrong with C++ per
se, but what is wrong with the idea that the use of any particular
language will in and of itself confer speed or other advantages over
the use of another language.) If an application just frankly doesn't
take advantage of lisp's rich memory-management and other run-time
parapernalia (and in my experience many don't) and continuous
real-time response is a requirement, then it probably will be easier
to implement cleanly and efficiently in C/C++ where the run-time
behavior is much more under the programmer's control.
A C++ fanatic might counter "Make a small change at the base of the
C++ hierarchy, and watch in horror as the entire system collapses in a
mass of compilation, linking and new bugs" with "Make a small change
just about anywhere in a set CLOS generic functions and watch in
horror as the entire system collapses in a mass of
method-recombination, GC-ing, and new bugs." The fact is they would
both be right. Making changes in a program causes the system to need
to adjust the rest of the application to those changes and risks
introducing bugs. I believe it to be a myth that C++ is more (or,
from the other point of view, less) prone to that sort of problem than
lisp, however.
In the end, for the vast majority of programs that need neither the
rock-solid real-time behavior most easily achievable in
assembler/C/C++ nor the semantic bells-and-whistles provided by lisp,
it is pretty much a wash according to objective criteria which
language is "better", and programmers should use the tools with which
they are most comfortable while keeping well aware of the possible
pitfalls that those particular tools may have in wait, whatever system
they end up using. And they all have pitfalls, just different ones.
Now, actual implementations of particular languages is a different
matter. The greater market acceptance of C/C++ (whether you agree
that it is rational or not) has made the variety and general quality
of choices of developments systems much better for it than for lisp,
and at substantially lower prices for commercial packages. This in
itself frequently is the determining factor in a choice of what
language to use, regardless of the fittedness of a given language to a
given set of requirements. C'est la guerre.
Kirk
------------------------------------------------------------
Kirk Rader ····@triple-i.com
In article <··········@triple-i.com> ····@triple-i.com (Kirk Rader) writes:
grounds of those same sort of common programming mistakes. I know
from personal experience that it is in fact possible to create
well-written programs in either C++ or lisp, and that for some
application domains the one makes life easier while in other
application domains the other will have the advantage.
Almost everyone agrees with this as stated. The great debate is,
Which application domains are better dealt with in which language?
What percentage of the programming industry would be better off
programming in Language X rather than Language Y?
A C++ fanatic might counter "Make a small change at the base of the
C++ hierarchy, and watch in horror as the entire system collapses in a
mass of compilation, linking and new bugs" with "Make a small change
just about anywhere in a set CLOS generic functions and watch in
horror as the entire system collapses in a mass of
method-recombination, GC-ing, and new bugs." The fact is they would
both be right. Making changes in a program causes the system to need
to adjust the rest of the application to those changes and risks
introducing bugs. I believe it to be a myth that C++ is more (or,
from the other point of view, less) prone to that sort of problem than
lisp, however.
Once again, almost everyone agrees that =some= degree of program
change creates work and risks introducing bugs. The issue is, To what
degree does the programming language reduce the work and the risk?
What degree of change does the language facilitate rather than resist?
Your examples are also fallacious. =Every= language will show strain
at the leading edge of its capabilities. The question is, Where is
that leading edge? For some languages (e.g., assembler), the leading
edge is register allocation and stack management; such a language
doesn't even try to support inheritance. For other languages, heap
management and multiple inheritance are the leading edge at which many
programmers give up; such a language wouldn't even attempt to support
method combination. And then some languages have mastered both heap
management and multiple inheritance, and even deal bravely (and
reasonably, in 99% of the cases) with method combination, despite the
technical challenges.
In the end, for the vast majority of programs that need neither the
rock-solid real-time behavior most easily achievable in
assembler/C/C++ nor the semantic bells-and-whistles provided by lisp,
it is pretty much a wash according to objective criteria which
language is "better", and programmers should use the tools with which
they are most comfortable while keeping well aware of the possible
pitfalls that those particular tools may have in wait, whatever system
they end up using. And they all have pitfalls, just different ones.
Many people =on both sides= would disagree with your "a wash"
characterization. The argument about programming language in these
cases is usually about efficiency, image size, and perhaps safety (by
various definitions); the degree of productivity difference may be
debated, but the existence of such a difference usually isn't.
--
Lawrence G. Mayka
AT&T Bell Laboratories
···@ieain.att.com
Standard disclaimer.
From: Kirk Rader
Subject: Re: Commercial Lisp Work in UK??
Date:
Message-ID: <Coq3tE.Io6@triple-i.com>
In article <·················@polaris.ih.att.com> you write:
>In article <··········@triple-i.com> ····@triple-i.com (Kirk Rader) writes:
>
> grounds of those same sort of common programming mistakes. I know
> from personal experience that it is in fact possible to create
> well-written programs in either C++ or lisp, and that for some
> application domains the one makes life easier while in other
> application domains the other will have the advantage.
>
>Almost everyone agrees with this as stated. The great debate is,
>Which application domains are better dealt with in which language?
>What percentage of the programming industry would be better off
>programming in Language X rather than Language Y?
I thought I made my views on that clear: real-time applications (and
by implication, those not necessarily "real time" in the traditional
sense but ones requiring a high degree of high speed, continuous
throughput) are better implemented in a C-like language, applications
which can sacrifice that degree of programmer-control over resource
utilization and run-time behavior and which can benefit from a
lisp-like language's built-in memory-management system and richer
semantics are better implemented in a lisp-like language. Please take
special note of the "and can benefit..." phrase. I feel that the set
of application domains which actually receive significant benefit from
lisp's richer run-time and semantic features is limited. On the other
hand, I believe that the set of application domains that actually
suffer from using lisp, whether the "superior" features of lisp are
made use of or not, is also limited. I have no numerical data on
which to estimate actual percentages, but my view (based on experience
in both the lisp and C/C++ programming worlds) is that a minority of
the programming industry would actually benefit from programming in
any particular kind of language, and for the majority of the
programming industry the choice of language is fairly irrelevant,
other than from considerations such as a base of existing code,
experience of the programmers themselves, etc.
>
> A C++ fanatic might counter "Make a small change at the base of the
> C++ hierarchy, and watch in horror as the entire system collapses in a
> mass of compilation, linking and new bugs" with "Make a small change
> just about anywhere in a set CLOS generic functions and watch in
> horror as the entire system collapses in a mass of
> method-recombination, GC-ing, and new bugs." The fact is they would
> both be right. Making changes in a program causes the system to need
> to adjust the rest of the application to those changes and risks
> introducing bugs. I believe it to be a myth that C++ is more (or,
> from the other point of view, less) prone to that sort of problem than
> lisp, however.
>
>Once again, almost everyone agrees that =some= degree of program
>change creates work and risks introducing bugs. The issue is, To what
>degree does the programming language reduce the work and the risk?
>What degree of change does the language facilitate rather than resist?
>
>Your examples are also fallacious. =Every= language will show strain
>at the leading edge of its capabilities. The question is, Where is
>that leading edge? For some languages (e.g., assembler), the leading
>edge is register allocation and stack management; such a language
>doesn't even try to support inheritance. For other languages, heap
>management and multiple inheritance are the leading edge at which many
>programmers give up; such a language wouldn't even attempt to support
>method combination. And then some languages have mastered both heap
>management and multiple inheritance, and even deal bravely (and
>reasonably, in 99% of the cases) with method combination, despite the
>technical challenges.
Fallacious in what way? I guess our experiences have simply led us to
different conclusions as to how "reasonably" method combination, as
well as a number of other issues with run-time impact, are handled in
most real-world lisp implementations. In the extremely large graphics
applications I work on, written originally in Zetalisp and Flavors on
the Symbolics Lisp Machine and ported over the last couple of years to
Unix-based commercial Common Lisps with CLOS, we have had to develop
any number of what I would consider fairly gross hacks to work around
inefficiencies in generic function dispatch, method combination,
closure compilation / application, the consing of theoretically
unnecessary garbage in both integer (eliminating "accidental" bignums)
and floating point ("unboxed floats") arithmetic, etc. etc.
Many applications simply do not make use of lisp's features "at the
leading edge of its capabilities" either because they are irrelevant
to the task the program is meant to carry out or they impose too great
a run-time cost. Those are the applications for which lisp is either
no better or a worse choice than C++.
>
> In the end, for the vast majority of programs that need neither the
> rock-solid real-time behavior most easily achievable in
> assembler/C/C++ nor the semantic bells-and-whistles provided by lisp,
> it is pretty much a wash according to objective criteria which
> language is "better", and programmers should use the tools with which
> they are most comfortable while keeping well aware of the possible
> pitfalls that those particular tools may have in wait, whatever system
> they end up using. And they all have pitfalls, just different ones.
>
>Many people =on both sides= would disagree with your "a wash"
>characterization. The argument about programming language in these
>cases is usually about efficiency, image size, and perhaps safety (by
>various definitions); the degree of productivity difference may be
>debated, but the existence of such a difference usually isn't.
The difference in productivity usually isn't debated by those who
assume that using lisp automatically makes one more productive. My
experience has been, however, that lisp only makes one more productive
when working in application domains for which lisp is well-suited.
When working in application domains where the features of lisp are not
exploited, or where the cost of exploiting them in terms of run-time
performance is too high, then lisp's "advantages" become at best
irrelevant idionsyncracies (the class of applications for which I
would say the choice of language is "a wash") or at worst
disadvantages that hinder, not enhance, productivity due to the effort
required in working around them.
>--
> Lawrence G. Mayka
> AT&T Bell Laboratories
> ···@ieain.att.com
>
>Standard disclaimer.
------------------------------------------------------------
Kirk Rader ····@triple-i.com
In article <··········@triple-i.com> ····@triple-i.com (Kirk Rader) writes:
> Please take
>special note of the "and can benefit..." phrase. I feel that the set
>of application domains which actually receive significant benefit from
>lisp's richer run-time and semantic features is limited. On the other
>hand, I believe that the set of application domains that actually
>suffer from using lisp, whether the "superior" features of lisp are
>made use of or not, is also limited.
I find that the cases where I benefit from a language are not
confined to cases where the application benefits.
>> The argument about programming language in these
>>cases is usually about efficiency, image size, and perhaps safety (by
>>various definitions); the degree of productivity difference may be
>>debated, but the existence of such a difference usually isn't.
>
>The difference in productivity usually isn't debated by those who
>assume that using lisp automatically makes one more productive. My
>experience has been, however, that lisp only makes one more productive
>when working in application domains for which lisp is well-suited.
I find that Lisp makes me more productive except in cases where
Lisp is significantly ill-suited.
In article <··········@triple-i.com> ····@triple-i.com (Kirk Rader) writes:
>
>At the risk of throwing gasoline on an already raging flamewar, I must
>say that it seems to me that anyone who says "language X is better
>than language Y" (or "platform X is better than platform Y", or
>"programming paradigm X is better than programming paradigm Y", etc.
>etc.) is betraying a rather parochial bias.
Not necessarily. Some languages are better than others.
On the other hand, I agree with this:
> [...] My own feeling is that all popular programming languages
>have their strengths and their weaknesses, and it is only sensible to
>use the tool best fitted to the particular task.
But not this:
>A C++ fanatic might counter "Make a small change at the base of the
>C++ hierarchy, and watch in horror as the entire system collapses in a
>mass of compilation, linking and new bugs" with "Make a small change
>just about anywhere in a set CLOS generic functions and watch in
>horror as the entire system collapses in a mass of
>method-recombination, GC-ing, and new bugs." The fact is they would
>both be right.
No they wouldn't. Small changes just about anywhere don't have
that effect in CLOS.
In article <··············@netcom.com>, Steven Vere <····@netcom.com> wrote:
> Today personal computers cost $5K, run 60 times faster, and 16MB is
>common. Consequently, it is necessary to use a lower-level language
>like C++ in order to eke out the last bit of hardware efficiency, even
>if that means extra work and aggravation for the programmer. With
>such phenomenal improvements in hardware costs and performance, simple
>economics dictate the shift from Lisp to C++. Why do diehard Lisp
>hackers find this so difficult to grasp?
You forgot the (PROCLAIM '(IRONY 3)); many widely available usenet readers
don't have inference engines that can derive this.
There are certain applications where you do need every cycle and byte from
the hardware you're running on. In these cases, the best way out is to
write a compiler in CL/CLOS, and compile into C.
Simon
In article <··········@bigblue.oit.unc.edu>
···@tipper.oit.unc.edu "Simon E Spero" writes:
> There are certain applications where you do need every cycle and byte from
> the hardware you're running on. In these cases, the best way out is to
> write a compiler in CL/CLOS, and compile into C.
That's been my favourite solution ever since I tried it in Basic. I like
it even more in Lisp.
--
Martin Rodgers
In article ···@netcom.com, ····@netcom.com (Steven Vere) writes:
>In article <··········@marble.Britain.EU.net> <···@BLACKWATER.symbolics.co.uk> writes:
>>Does anyone have any idea if there is any significant
>>Lisp work being done in the UK? I know of a few in the
>>defence arena, but very little in the commercial domain.
>>
>>The reason I ask is to gauge how much effort I should
>>invest in trying to remain a Lisp programmer, before
>>giving it up as a lost cause in the UK and moving on to
>>the more mundane world of C/C++.
>>
>>Thanks for any info,
>>Guy Footring
>>Symbolics Ltd.
>
> I'm afraid the future belongs to C++. You have to understand that
>computing has changed dramatically in the last 15 years. Back in the
>days when computers cost $100K, ran like slugs, and 256kB of main
>memory was considered large, Lisp made sense. It allowed programmers
>to quickly develop complex programs, trading development time and
>programmer sanity for a certain penalty in execution time and memory
>utilization.
> Today personal computers cost $5K, run 60 times faster, and 16MB is
>common. Consequently, it is necessary to use a lower-level language
>like C++ in order to eke out the last bit of hardware efficiency, even
>if that means extra work and aggravation for the programmer. With
>such phenomenal improvements in hardware costs and performance, simple
>economics dictate the shift from Lisp to C++. Why do diehard Lisp
>hackers find this so difficult to grasp?
Funny ... using your arguments, I would have said exactly the opposite
was true <smile>!
In the days when you *did* need to have small programs to eke out the
last iota of performance, and computers did not interpret Lisp quickly,
C or C++ would make more sense. Whereas, on todays machines, where
interpreters can be run quite fast, and plenty of memory is available
for objects, etc., Lisp can do the same things they did 15 years ago
*much* faster. Code can be developed much faster too in development
environments like Symbolics' Lisp.
I guess this is a classic example of taking the same facts and drawing
conclusions differently, based on the biases one has! Personally, I
would love to be able to get back to programming on a Symbolics 3600 or
3640 again if I could justify it as a job <grin>. I would not do it for
the reason Guy identifies, but I would love to be able to.
Z
--
-------------------------------------------------------------------------
| Syed Zaeem Hosain P. O. Box 610097 (408) 441-7021 |
| Z Consulting Group San Jose, CA 95161 ···@zcon.com |
-------------------------------------------------------------------------
In article <······················@zcon.com> ···@zcon.com (Syed Zaeem Hosain) writes:
In the days when you *did* need to have small programs to eke out the
last iota of performance, and computers did not interpret Lisp quickly,
C or C++ would make more sense. Whereas, on todays machines, where
interpreters can be run quite fast, and plenty of memory is available
for objects, etc., Lisp can do the same things they did 15 years ago
*much* faster. Code can be developed much faster too in development
environments like Symbolics' Lisp.
As an update:
The situation is even better, technologically speaking, than you
think. Nowadays, most commercial Common Lisp implementations compile
to machine instructions, and make good use of any appropriate
(optional) type declarations, so that even the more pathological
benchmarks may show only a x2 speed difference between Common Lisp and
C. And powerful development environments, arguably of Genera caliber,
are available from healthy, profitable vendors.
--
Lawrence G. Mayka
AT&T Bell Laboratories
···@ieain.att.com
Standard disclaimer.
In article <·················@polaris.ih.att.com> ···@polaris.ih.att.com (Lawrence G. Mayka) writes:
Newsgroups: comp.lang.lisp
Path: info-server.bbn.com!noc.near.net!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!cs.utexas.edu!swrinde!ihnp4.ucsd.edu!pacbell.com!att-out!nntpa!nntpa.cb.att.com!lgm
From: ···@polaris.ih.att.com (Lawrence G. Mayka)
Sender: ····@nntpa.cb.att.com (Netnews Administration)
Nntp-Posting-Host: polaris.ih.att.com
Organization: AT&T Bell Laboratories, Naperville, Illinois, USA
References: <··············@netcom.com> <······················@zcon.com>
Date: Sat, 16 Apr 1994 21:31:22 GMT
Lines: 25
In article <······················@zcon.com> ···@zcon.com (Syed Zaeem Hosain) writes:
...
The situation is even better, technologically speaking, than you
think. Nowadays, most commercial Common Lisp implementations compile
to machine instructions, and make good use of any appropriate
(optional) type declarations, so that even the more pathological
benchmarks may show only a x2 speed difference between Common Lisp and
C. And powerful development environments, arguably of Genera caliber,
are available from healthy, profitable vendors.
Do you have data to support this x2, or is this just another rumor? I have
a trouble imagining the kind of pathological benchmark you are referring
to, that i could write relatively easily in both Lisp and C. However, i do
have 2 examples of real Lisp and C programs that are comparable. Here,
Lisp is as fast or faster than the C.
k
--
Ken Anderson
Internet: ·········@bbn.com
BBN STC Work Phone: 617-873-3160
10 Moulton St. Home Phone: 617-643-0157
Mail Stop 6/4c FAX: 617-873-3776
Cambridge MA 02138
USA
In article <······················@wheaton.bbn.com> ········@wheaton.bbn.com (Ken Anderson) writes:
In article <·················@polaris.ih.att.com> ···@polaris.ih.att.com (Lawrence G. Mayka) writes:
The situation is even better, technologically speaking, than you
think. Nowadays, most commercial Common Lisp implementations compile
to machine instructions, and make good use of any appropriate
(optional) type declarations, so that even the more pathological
benchmarks may show only a x2 speed difference between Common Lisp and
C. And powerful development environments, arguably of Genera caliber,
are available from healthy, profitable vendors.
Do you have data to support this x2, or is this just another rumor? I have
a trouble imagining the kind of pathological benchmark you are referring
to, that i could write relatively easily in both Lisp and C. However, i do
have 2 examples of real Lisp and C programs that are comparable. Here,
Lisp is as fast or faster than the C.
The pathological benchmark I was thinking of is the Dhrystone 2.0,
which (once upon a time) was the most widely used benchmark for
comparing both processors and compilers. The industry has dropped it
in the last five years in favor of more realistic programs.
--
Lawrence G. Mayka
AT&T Bell Laboratories
···@ieain.att.com
Standard disclaimer.
In article <······················@zcon.com> ···@zcon.com writes:
>In the days when you *did* need to have small programs to eke out the
>last iota of performance, and computers did not interpret Lisp quickly,
>C or C++ would make more sense. Whereas, on todays machines, where
>interpreters can be run quite fast [...]
Interpreters?
It's well worth compiling Lisp, BTW. It can get from 10 to 30
times faster.
In article ···@cogsci.ed.ac.uk, ····@aiai.ed.ac.uk (Jeff Dalton) writes:
>In article <······················@zcon.com> ···@zcon.com writes:
>
>>In the days when you *did* need to have small programs to eke out the
>>last iota of performance, and computers did not interpret Lisp quickly,
>>C or C++ would make more sense. Whereas, on todays machines, where
>>interpreters can be run quite fast [...]
>
>Interpreters?
>
>It's well worth compiling Lisp, BTW. It can get from 10 to 30
>times faster.
Yes, of course, agreed. I was thinking of development environments,
with partial compilation and partial interpretation, whatever. Sorta
like the difference between evaluating a lisp file in Symbolics zemacs,
lets say, as opposed to compiling the function prior to execution.
Z
--
-------------------------------------------------------------------------
| Syed Zaeem Hosain P. O. Box 610097 (408) 441-7021 |
| Z Consulting Group San Jose, CA 95161 ···@zcon.com |
-------------------------------------------------------------------------
In article <······················@zcon.com> ···@zcon.com (Syed Zaeem Hosain) writes:
In article ···@cogsci.ed.ac.uk, ····@aiai.ed.ac.uk (Jeff Dalton) writes:
>In article <······················@zcon.com> ···@zcon.com writes:
>
>>In the days when you *did* need to have small programs to eke out the
>>last iota of performance, and computers did not interpret Lisp quickly,
>>C or C++ would make more sense. Whereas, on todays machines, where
>>interpreters can be run quite fast [...]
>
>Interpreters?
>
>It's well worth compiling Lisp, BTW. It can get from 10 to 30
>times faster.
Yes, of course, agreed. I was thinking of development environments,
with partial compilation and partial interpretation, whatever. Sorta
like the difference between evaluating a lisp file in Symbolics zemacs,
lets say, as opposed to compiling the function prior to execution.
Another friendly update:
Modern Common Lisp development environments support incremental,
one-function-at-a-time native-code compilation directly from an editor
buffer; hence the interpreter is no longer necessary in that case.
The main use of the interpreter nowadays is as a top-level form
evaluator (i.e., a Lisp listener).
--
Lawrence G. Mayka
AT&T Bell Laboratories
···@ieain.att.com
Standard disclaimer.
In article <··········@cogsci.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
Interpreters?
It's well worth compiling Lisp, BTW. It can get from 10 to 30
times faster.
I kind of doubt that 30 is an upper bound . . . .
--
Rick Busdiecker <···@lehman.com> and <···@cmu.edu>
Lehman Brothers Please do not send electronic junk mail!
388 Greenwich Street
New York, NY 10013 ``I hate quotations.'' - Ralph Waldo Emerson
In article <··············@netcom.com> ····@netcom.com (Steven Vere) writes:
>
> I'm afraid the future belongs to C++. You have to understand that
>computing has changed dramatically in the last 15 years. Back in the
>days when computers cost $100K, ran like slugs, and 256kB of main
>memory was considered large, Lisp made sense. It allowed programmers
>to quickly develop complex programs, trading development time and
>programmer sanity for a certain penalty in execution time and memory
>utilization.
> Today personal computers cost $5K, run 60 times faster, and 16MB is
>common. Consequently, it is necessary to use a lower-level language
>like C++ in order to eke out the last bit of hardware efficiency, even
>if that means extra work and aggravation for the programmer. With
>such phenomenal improvements in hardware costs and performance, simple
>economics dictate the shift from Lisp to C++. Why do diehard Lisp
>hackers find this so difficult to grasp?
Actually, I have more trouble grasping how you reached the conclusion.
If hardware has improved in efficiency (which it certainly has), wouldn't
that suggest that it's less important for programmers to spend extra
time in getting the last bit of efficiency out of their products?
As a result of advances in hardware, it is now possible to run large
Lisp programs on a PC with little performance penalty.
Regardless of hardware advances, Lisp is still the most productive
"real" programming language by a wide margin. Admittely, with the
advent of new OO languages such as C++, and their associated development
environments (Borland BC4.0, MSVCPP), the gap has been narrowed
somewhat; however, and experienced Lisp programmer can still turn
out prototypes of complex systems in a fraction of the time it would
take to write it in C++ or Ada.
I agree that the future belongs to C++, but not for the reasons
you stated.
Pete.
·····@pentagon-gw.army.mil (Pete Grant) writes:
>In article <··············@netcom.com> ····@netcom.com (Steven Vere) writes:
>>
>> I'm afraid the future belongs to C++. You have to understand that
>>computing has changed dramatically in the last 15 years. Back in the
>>days when computers cost $100K, ran like slugs, and 256kB of main
>>memory was considered large, Lisp made sense. It allowed programmers
>>to quickly develop complex programs, trading development time and
>>programmer sanity for a certain penalty in execution time and memory
>>utilization.
>> Today personal computers cost $5K, run 60 times faster, and 16MB is
>>common. Consequently, it is necessary to use a lower-level language
>>like C++ in order to eke out the last bit of hardware efficiency, even
>>if that means extra work and aggravation for the programmer. With
>>such phenomenal improvements in hardware costs and performance, simple
>>economics dictate the shift from Lisp to C++. Why do diehard Lisp
>>hackers find this so difficult to grasp?
>Actually, I have more trouble grasping how you reached the conclusion.
>If hardware has improved in efficiency (which it certainly has), wouldn't
>that suggest that it's less important for programmers to spend extra
>time in getting the last bit of efficiency out of their products?
>As a result of advances in hardware, it is now possible to run large
>Lisp programs on a PC with little performance penalty.
One point that comes in mind is that modern RISC architectures needs
more compilcated compilers. Almost all of them needs special
instruction sheduling schemes and from what I have seen, todays Lisp
compilers are not too good at it. It sounds reasonable to me that the
best optimizing compiler for a given RISC chip is produced by the
vendor of the chip. As we all know, that are C and Fortran compilers.
So, it may be true that modern computers make the difference between
Lisp and lower-level languages bigger. But who cares if your Lisp
application is fast enough?
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@wavehh.hanse.de>,Voice+4940-5221829,Fax.-5228536
Waldstrasse 200, 22846 Norderstedt, Germany. German language accepted.
From: Jeff Dalton
Subject: Re: Modern RISC's compilers (was Re: Commercial Lisp Work in UK??)
Date:
Message-ID: <Cotns5.973@cogsci.ed.ac.uk>
In article <······················@wavehh.hanse.de> ········@wavehh.hanse.de (Martin Cracauer) writes:
>One point that comes in mind is that modern RISC architectures needs
>more compilcated compilers. Almost all of them needs special
>instruction sheduling schemes and from what I have seen, todays Lisp
>compilers are not too good at it.
What have you seen?
> It sounds reasonable to me that the
>best optimizing compiler for a given RISC chip is produced by the
>vendor of the chip. As we all know, that are C and Fortran compilers.
Sure, it's reasonable; but is it always true?
>So, it may be true that modern computers make the difference between
>Lisp and lower-level languages bigger.
I haven't seen any evidence that this is actually the case.
From article <··············@netcom.com>, by ····@netcom.com (Steven Vere):
> In article <··········@marble.Britain.EU.net> <···@BLACKWATER.symbolics.co.uk> writes:
>>Does anyone have any idea if there is any significant
>>Lisp work being done in the UK? I know of a few in the
>>defence arena, but very little in the commercial domain.
[stuff deleted]
> I'm afraid the future belongs to C++. You have to understand that
> computing has changed dramatically in the last 15 years. Back in the
> days when computers cost $100K, ran like slugs, and 256kB of main
> memory was considered large, Lisp made sense. It allowed programmers
> to quickly develop complex programs, trading development time and
> programmer sanity for a certain penalty in execution time and memory
> utilization.
> Today personal computers cost $5K, run 60 times faster, and 16MB is
> common. Consequently, it is necessary to use a lower-level language
> like C++ in order to eke out the last bit of hardware efficiency, even
> if that means extra work and aggravation for the programmer. With
> such phenomenal improvements in hardware costs and performance, simple
> economics dictate the shift from Lisp to C++. Why do diehard Lisp
> hackers find this so difficult to grasp?
> --
I'm not sure your argument makes sense. You say that when machines were
slow and memory was expensive, it made more sense to run slow, memory-
hungry programs than it does now machines are fast and memory is cheap.
I guess die-hard LISP hackers are too stupid to appreciate the subtlety
of this!
--
Peter Jackson, Dept of Electrical & Computer Eng, Clarkson University
"Opinions expressed are not those of my employer or any other organization"
In article <·····················@news.clarkson.edu>,
Peter Jackson,CH237A,, <·······@sandman.ece.clarkson.edu> wrote:
>From article <··············@netcom.com>, by ····@netcom.com (Steven Vere):
>> In article <··········@marble.Britain.EU.net> <···@BLACKWATER.symbolics.co.uk> writes:
>>>Does anyone have any idea if there is any significant
>>>Lisp work being done in the UK? I know of a few in the
>>>defence arena, but very little in the commercial domain.
>
>[stuff deleted]
>
>> I'm afraid the future belongs to C++. You have to understand that
>> computing has changed dramatically in the last 15 years. Back in the
>> days when computers cost $100K, ran like slugs, and 256kB of main
>> memory was considered large, Lisp made sense. It allowed programmers
>> to quickly develop complex programs, trading development time and
>> programmer sanity for a certain penalty in execution time and memory
>> utilization.
>> Today personal computers cost $5K, run 60 times faster, and 16MB is
>> common. Consequently, it is necessary to use a lower-level language
>> like C++ in order to eke out the last bit of hardware efficiency, even
>> if that means extra work and aggravation for the programmer. With
>> such phenomenal improvements in hardware costs and performance, simple
>> economics dictate the shift from Lisp to C++. Why do diehard Lisp
>> hackers find this so difficult to grasp?
>> --
>
>I'm not sure your argument makes sense. You say that when machines were
>slow and memory was expensive, it made more sense to run slow, memory-
>hungry programs than it does now machines are fast and memory is cheap.
>I guess die-hard LISP hackers are too stupid to appreciate the subtlety
^^^^^^
>of this!
Ouch! That's pretty harsh...
I'm amazed at the number of people who missed the sarcasm in Steve's
posting. I laughed so hard at his message that my stomach hurt...
Mike
In article <··········@usenet.rpi.edu>
······@fornax.cs.rpi.edu "Michael James" writes:
> I'm amazed at the number of people who missed the sarcasm in Steve's
> posting. I laughed so hard at his message that my stomach hurt...
I couldn't resist a smile. Some people have to see a smiley before
they recognise that something is not entirely as it looks, tho in
this case it seemed pretty obvious to me.
--
Martin Rodgers