There were toy implementation of C available and that didn't seem to hurt
C.
So what really happened with LISP?
Lets get real, and keep history in mind. In the 1980's companies
around the world, but especially in the US, invested hundreds of millions
of dollars in commercial lisp systems. Maybe even billions when you
consider all the salaries of all the people who purchased and worked
with these commercial systems.
Yet today, how many companies with products for sale which were implemented
in LISP actually make use of commercial LISP products? Perhaps some,
but I think that the situation at Macsyma Inc, and Gensym are more typical.
Both companies essentially maintain their own lisp systems in-house. And
for
want of a useful ANDF(architecture neutral distribution format) these
implementations
target C, not assembler. Other companies make use of interpreters in
commercial products.
Why is this?
1. All of the lisp hardware vendors spent tens of millions of dollars
telling the world that special purpose hardware was required, that
using lisp without it was impractical, and that anybody who tried to
do otherwise was some kind of backward turkey bound to lose.
Shops who purchased these machines spent a huge about of money
and put a lot on the line in order to be state of the art.
2. Symbolics spent millions telling people that lisp wasn't portable
between different lisp machine vendors, and anyway who would want
to bother, since most shops know that they already spend so much
time maintaining their code to keep up with new release of Symbolics
operating system that real people will never get real work done
if they try to be portable at the same time.
3. Along comes LUCID, with millions to spend on telling people that
special hardware is not needed, however LISP is too complicated to
be properly implemented in-house by the major hardware and operating
system vendors, and even if you don't think so we will go around you
and help convince your customers that you aren't doing such a good job
as we would do.
-gjc
In article <··························@gjchome.nis.newscorp.com>, "George
J. Carrette" <···@delphi.com> wrote:
> 1. All of the lisp hardware vendors spent tens of millions of dollars
> telling the world that special purpose hardware was required, that
> using lisp without it was impractical, and that anybody who tried to
> do otherwise was some kind of backward turkey bound to lose.
> Shops who purchased these machines spent a huge about of money
> and put a lot on the line in order to be state of the art.
This is too broad a brush-stroke. There were some within Symbolics that
pushed hard for a non-proprietary HW solution. The most vocal was
Howard Cannon, who worked hard to develop an 80x86 capability.
Also, with current large address spaces, large RAMs, large disks, and
very high performance chips, it is easy to look backwards and criticize
'Lisp HW'. Keep in mind that with only 2-8 Mbytes of memory in the early
1980's, these machines had spectacular capabilities and performance. Rather
than 'ride the wave' of Moore's Law, however, they just fell off the surfboard
somewhere about 1986.
In article <·······················@10.0.2.1>, ······@netcom.com (Henry
Baker) wrote:
> Also, with current large address spaces, large RAMs, large disks, and
> very high performance chips, it is easy to look backwards and criticize
> 'Lisp HW'. Keep in mind that with only 2-8 Mbytes of memory in the early
> 1980's, these machines had spectacular capabilities and performance. Rather
> than 'ride the wave' of Moore's Law, however, they just fell off the surfboard
> somewhere about 1986.
Perhaps many of you "old timers" were too close to the forest/trees at the
time, or maybe you just had a different opinion at the time (and some even
now).
However, in 1986, I took a Computer Systems Architecture course (don't
recall the number) as an undergraduate at MIT , and one of the case
studies was basically why Lisp machines were a "Non Winning" solution. In
hindsight, the purpose of these case studies was to give the students
(future engineers) the opportunity to learn from the mistakes made in the
past and avoid repeating them in the future (and, occasionally, learn from
correct decisions). In 1986, the mistake made by the Lisp industry in
stubbornly sticking to proprietary architectures was readily apparent.
At the time, Symbolics had just announced a brand new, lower cost (but
still proprietary) system, and the consensus was that they were basically
wasting time and money on that approach.
--
Jeffrey B. Siegal
Quiotix Corporation
+1 415 782-6012
http://www.quiotix.com
In article <····················@dial-sf1-5.iway.aimnet.com>,
···@quiotix.com (Jeffrey B. Siegal) wrote:
> Perhaps many of you "old timers" were too close to the forest/trees at the
> time, or maybe you just had a different opinion at the time (and some even
> now).
If I'm an 'old timer' now, I'd hate to think what I'll be called in another
10 years!
I like to think I can still see 'trees' where most others can only see
'vectors' and 'arrays'. (e.g., objects v. 'bitmaps') ;-) ;-) ;-)
> However, in 1986, I took a Computer Systems Architecture course (don't
> recall the number) as an undergraduate at MIT , and one of the case
> studies was basically why Lisp machines were a "Non Winning" solution. In
> hindsight, the purpose of these case studies was to give the students
> (future engineers) the opportunity to learn from the mistakes made in the
> past and avoid repeating them in the future (and, occasionally, learn from
> correct decisions). In 1986, the mistake made by the Lisp industry in
> stubbornly sticking to proprietary architectures was readily apparent.
Depends upon what you mean by 'proprietary'. If 'proprietary' = 'low volume',
I'll agree with you, but if 'proprietary' means 'optimized for C', I'll pass.
There was one point where Steve Jobs would have considered putting a Lisp
chip into every single Macintosh, but Symbolics was several years too
late for that. If Symbolics had been ready at the appropriate time, its
'proprietary' chip would have had high volume, which might have changed
the course of computing. If you want to know why Symbolics was late with
their chip, you might ask its board members why they didn't invest in it...
In article <····················@dial-sf1-5.iway.aimnet.com>,
···@quiotix.com (Jeffrey B. Siegal) wrote:
> stubbornly sticking to proprietary architectures was readily apparent.
Sorry, but the word "proprietary" nowadays is at best
meaningless. It has zero content due to misuse
of various marketing guys. Isn't Java proprietary?
How open is Unix? Solaris? AIX? Is the
Intel architecture "open"?
If Symbolics develops an architecture, it is proprietary?
If SUN does the same - it is not?
If Symbolics ships most of the source, it is proprietary?
If SUN does not - it is not?
...
Rainer Joswig - Puzzled
--
http://www.lavielle.com/~joswig/
In article <·································@news.lavielle.com>,
······@lavielle.com (Rainer Joswig) wrote:
> If Symbolics develops an architecture, it is proprietary?
> If SUN does the same - it is not?
> If Symbolics ships most of the source, it is proprietary?
> If SUN does not - it is not?
The point was that it was a mistake _for the Lisp industry_ to stick to
proprietary architectures simply because their volume was too low to
support continuing to invest in developing almost their entire system as
proprietary Lisp-specific architectures. These investments were seen as
negative-return at the time (not by the companies, I guess).
Doing reasonable garbage collection without special hardware was something
that wasn't widely viewed as entirely practical at the time (although I
believe that one Lisp software vendor had delivered a version of their
system that used conventional virtual memory hardware for real-time
garbage collection).
One alternative approach that was considered (in the course) would have
been for Symbolics to develop their own memory management hardware for a
68020-based system (which, BTW, is what SUN did at the time) that would
have provided the necessary write barrier. This would have still been
proprietary, but it would have been less proprietary and it would have
required a smaller negative-return investment.
--
Jeffrey B. Siegal
Quiotix Corporation
+1 415 782-6012
http://www.quiotix.com
In article <····················@dial-sf1-23.iway.aimnet.com>,
···@quiotix.com (Jeffrey B. Siegal) wrote:
> The point was that it was a mistake _for the Lisp industry_ to stick to
> proprietary architectures simply because their volume was too low to
> support continuing to invest in developing almost their entire system as
> proprietary Lisp-specific architectures.
It was tuned for Lisp (and Prolog), but you could
use C, Pascal, Fortran, Ada, too. Is it Lisp specific?
I still don't like the word "proprietary". Why is the SPARC
architecture not proprietary? MIPS? ALPHA?
The word "proprietary" is completely **useless**.
This is business. Everything is proprietary in one way or another,
nobody gives something away without purpose.
> Doing reasonable garbage collection without special hardware was something
> that wasn't widely viewed as entirely practical at the time (although I
> believe that one Lisp software vendor had delivered a version of their
> system that used conventional virtual memory hardware for real-time
> garbage collection).
Another thing is tagging. Symbolics used a 40 bit architecture
for their microprocessor. Believe it or not, but it has
advantages when it comes to Lisp if you want to use
tags. The Ivory already was really fast. Redoing it in a modern
process (see what DEC did to the ARM processor, they
took it from 20-30 to 160 and more Mhz), would be cool. Today�s
technology would make it possible at a cheaper price.
> One alternative approach that was considered (in the course) would have
> been for Symbolics to develop their own memory management hardware for a
> 68020-based system (which, BTW, is what SUN did at the time) that would
> have provided the necessary write barrier. This would have still been
> proprietary, but it would have been less proprietary and it would have
> required a smaller negative-return investment.
The Lisp vendors did not go for mass market. The market niche
went away. The main thing is not "proprietarity". It
is portability, support for (emerging) standards and,
yes, price. SUN still does their own platform, but
they also do support Intel and PowerPC architectures.
And still they only have a limited future. The
desktop is Windows. You need to create ways for people
to understand your software. The Lisp machines
were much to complicated, not very visual (with the exception
of Interlisp) and they were to expensive. They effectively
were research machines.
Sure Symbolics software did run on Windows, Mac and SUN.
But expensive and complicated.
I still don't understand why anybody would call Unix elegant,
user friendly, secure, or even fun to use. The most interesting
market is the mass market. Build a computer/OS that is as easy
to use a television or a toaster. Something that
will not expose its innner workings to users.
Such a thing is the Newton OS. It is the modern
Lisp machine. It is built on many of the original
concepts of the Lisp world (objects, GC, interactive
programming, functions, symbols, images, ...).
The Newton OS 2.0 has gotten very nice ratings
by users and by the press. It is a proof that
you can built an interesting system that
is not foolishly redoing the mistakes of the past.
I'd like to see more of that. More of things
that are not concerned with bits and pointers,
but with user centric design and adaption
to users needs.
And I still think Lisp technology
could make a difference. On the Mac MCL
is such a base for interesting new software.
CL-HTTP is one software foundation. On the PC
we need better Lisp implementations and we will see them.
I hear people are working hard on that.
Short, have market and users in mind. Create interesting
applications. Talk about them. Let people know. Educate them.
Nobody cares whether your web server runs on a Lisp machine
if you have a cool application. Just move fast.
Rainer Joswig
--
http://www.lavielle.com/~joswig/
With a mighty <·································@news.lavielle.com>,
······@lavielle.com wibbled into the void...
> This is business. Everything is proprietary in one way or another,
> nobody gives something away without purpose.
This is true. There no free lunches.
The cost of "free" software is that you must sometimes port it
yourself. When this isn't practical - like when you need something
yesterday - the software just isn't available, however "free" it may
be. Hopefully that's a special case that doesn't occur too often.
My guess is that it's rare enough for a few of us too benefit from the
free software that's available.
Proprietary software, on the other hand, is only available for as long
as the vendor wishes to sell it. I've lost count of the number of
tools that I couldn't use because the software was no longer
available, at _any_ price.
So, I agree that we should take care with the word 'proprietary'. It's
meaning can vary, depending on who uses it, when and why. There's too
much politics associated with it.
> Another thing is tagging. Symbolics used a 40 bit architecture
> for their microprocessor. Believe it or not, but it has
> advantages when it comes to Lisp if you want to use
> tags. The Ivory already was really fast. Redoing it in a modern
> process (see what DEC did to the ARM processor, they
> took it from 20-30 to 160 and more Mhz), would be cool. Today�s
> technology would make it possible at a cheaper price.
The Linn Rekursiv also used a 40 bit architecture, with (I think) 5
bits used for the type info, and up to 32 bits for the data. Since my
info comes mainly from magazine articles about it, some details may be
wrong. It may be a little late to look for a Linn Smart Computing
website.
> The Lisp vendors did not go for mass market. The market niche
> went away. The main thing is not "proprietarity". It
> is portability, support for (emerging) standards and,
> yes, price. SUN still does their own platform, but
> they also do support Intel and PowerPC architectures.
I've been told that the Rekursiv was "killed" by the 486, but I think
that was meant was that commodity CPUs overtook the dedicated
architectures in terms of "bang for your buck". The Symbolics move to
the Alpha seems to support this point of view, but I wouldn't know.
Portability is vital. I've felt this since the early 80s, when I first
discovered that such things were at least dreamed of, even if the
reality tended to be very different.
> And still they only have a limited future. The
> desktop is Windows. You need to create ways for people
> to understand your software. The Lisp machines
> were much to complicated, not very visual (with the exception
> of Interlisp) and they were to expensive. They effectively
> were research machines.
Some people still deny that Windows is the way to go. Well, I wish
they were right, but I'm not convinced that the choice is as simple as
"Unix or Windows". Unix and Windows can both work, and they can both
suck, depending on your experience. I wouldn't be at all suprised if
the same was true for Lisp machines.
> Sure Symbolics software did run on Windows, Mac and SUN.
> But expensive and complicated.
Yes, regardless of the advantages, cost and complexity can be a
"killer". How do you convince someone that they need a card that costs
more than their machine, so they can run your software? I've noticed
that developers can use machines with as much as 10 times the RAM as
the users of their software, which can give the developer a false idea
of how the software will perform "in the field". So, even if you
develop on a Lisp machine but deliver for a more conventional
platform, you may still lose.
> I still don't understand why anybody would call Unix elegant,
> user friendly, secure, or even fun to use. The most interesting
> market is the mass market. Build a computer/OS that is as easy
> to use a television or a toaster. Something that
> will not expose its innner workings to users.
I've noticed that a lot of experienced Windows people will criticise
the MS "Bob" interface for being _too friendly_. You just can't win!
The best thing to do may be to just develop something friendly and
then point out to the techies that it wasn't created for _them_.
Perhaps there should be a warning on the box: "This software may be
too easy to use for experienced users!" <sigh>
Here's my favourite quote about operating systems:
"An operating system is a collection of things that don't fit into a
language. There shouldn't be one." Daniel Ingalls, Byte August 1981
In other words, if you can see it, then it's failing. After all this
time - and it wasn't new even then - this may still seem like a
radical idea. IMHO the spirit of punched cards lives on.
> Such a thing is the Newton OS. It is the modern
> Lisp machine. It is built on many of the original
> concepts of the Lisp world (objects, GC, interactive
> programming, functions, symbols, images, ...).
This is the kind of machine that I want to read about!
> The Newton OS 2.0 has gotten very nice ratings
> by users and by the press. It is a proof that
> you can built an interesting system that
> is not foolishly redoing the mistakes of the past.
I've not read as much as I'd like to, perhaps because I read the wrong
kind of magazines. Do you have a URL for a good overview?
> I'd like to see more of that. More of things
> that are not concerned with bits and pointers,
> but with user centric design and adaption
> to users needs.
Likewise. I've seen very little of that, for any platform. Instead,
most magazines give us endless "how to" articles, which barely
question the OS design, if at all.
> And I still think Lisp technology
> could make a difference. On the Mac MCL
> is such a base for interesting new software.
I recently discovered that the Tera assembler uses Scheme! Now that's
an unlikely combination, but I bet it's a very neat one. A little like
discovering that the connection machines used Lisp. It's too easy to
forget that supercomputing people don't just use Fortran/C/C++, but
sometimes choose a very different kind of tool.
> CL-HTTP is one software foundation. On the PC
> we need better Lisp implementations and we will see them.
I've been saying this for some time...
> I hear people are working hard on that.
Excellent! If the recent developments with Smalltalk are a glimpse of
what direction some Lisps may provide, then it'll be perfect timing.
This is a very positive moment for "alternative" language ideas, so it
could be the point at which Lisp makes another move forward.
> Short, have market and users in mind. Create interesting
> applications. Talk about them. Let people know. Educate them.
> Nobody cares whether your web server runs on a Lisp machine
> if you have a cool application. Just move fast.
Yep, move fast. If this is a positive window for alternatives to
languages like C/C++, then we should exploit it while it lasts.
I don't expect a backlash against Java, but some people think it could
happen. If it does, Lisp might suffer from "guilt by association".
We've had enough of that, in the past. Lisp has been associated with
the past, past failures, past successes, but mostly the _past_.
Now we should show what modern Lisp can do. Even a Lisp design that
began in the early 80s is "modern" compared to what most people
consider to be "state of the art" development languages.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
········@wam.umd.edu (Robert Rodgers) writes:
>So you show this to a C++ guy and you can see their brain going: "Wow,
>Lisp takes my P120 and gives it the performance of a 386SX."
>Not that they don't have a point. a few years ago I remember reading
>about some high performance techniques for Lisp compilation were going
>to be coming down the pike. Does anyone know what happened?
CMUCL compiles many code pieces to overhead-free machine code. And it
does for years. It needs more memory than a simple C program, but the
code runs as fast.
See http://www.cons.org/cracauer/lisp.html
CLOS is another issue.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
···············@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
With a mighty <·····················@wavehh.hanse.de>,
········@wavehh.hanse.de wibbled into the void...
> CMUCL compiles many code pieces to overhead-free machine code. And it
> does for years. It needs more memory than a simple C program, but the
> code runs as fast.
In fact, I'd expect CMUCL to be able to compile code with _fewer_
resources than many C++ compiler environments will demand.
I'd be interested to see a comparison between CMUCL and a C++ compiler
using a typical C++ framework for GUI apps. The test should IMHO be a
measurement of the resources required in order to make changes to
single elements of the interface appearance and behaviour, and then
test the code.
In my experience, ACL/PC can easily beat VC++ for compiling GUI code,
assuming that you're using the full GUI interface building tools
available as standard with these two products. How much more resources
does a compile and link for C++ take, compared to recompiling a single
function in Lisp, while the app is _still running_?
Does CMUCL have similar advantages? I expect so.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
In article <·································@news.lavielle.com>,
······@lavielle.com (Rainer Joswig) wrote:
> I still don't like the word "proprietary". Why is the SPARC
> architecture not proprietary? MIPS? ALPHA?
Let's not get caught up with the word "proprietary." If you like,
substitute "specialized," "Lisp-specific," "low-volume," or even
"roll-your-own."
SPARC, MIPS and ALPHA did not exist in 1986. Sun was relatively low
volume; they used the 68K rather than develop their own architecture (and
they stayed with the 68K for three generations). It was only _after_ they
became much higher volume (much higher than any Lisp machine) did they
decide to move to SPARC.
--
Jeffrey B. Siegal
Quiotix Corporation
+1 415 782-6012
http://www.quiotix.com
From: Daniel Finster
Subject: Re: Why lisp failed in the marketplace
Date:
Message-ID: <E5M0EK.HKF@SDF.LONESTAR.ORG>
In article <····················@dial-sf1-5.iway.aimnet.com>, Jeffrey B. Siegal <···@quiotix.com> wrote:
At the time, Symbolics had just announced a brand new, lower cost (but
still proprietary) system, and the consensus was that they were basically
wasting time and money on that approach.
11 years later, Symbolics Genera is still THE most capable Lisp environment
available anywhere, at any price. Hyper Win!
"Open Systems" are a loss. In practice, they are euphemisms for the
most anti-interoperable systems available: UNIX
They'll take away my LispM when they pry my cold, dead fingers away
from the Proprietary keyboard.
"Computers are never big enough or fast enough. I have no patience at
all with these damned PCs" -- Bill Gosper
On Thu, 13 Feb 1997, Jeffrey B. Siegal wrote:
> In article <·······················@10.0.2.1>, ······@netcom.com (Henry
> Baker) wrote:
> > Also, with current large address spaces, large RAMs, large disks, and
> > very high performance chips, it is easy to look backwards and criticize
> > 'Lisp HW'. Keep in mind that with only 2-8 Mbytes of memory in the early
> > 1980's, these machines had spectacular capabilities and performance. Rather
> > than 'ride the wave' of Moore's Law, however, they just fell off the surfboard
> > somewhere about 1986.
>
> Perhaps many of you "old timers" were too close to the forest/trees at the
> time, or maybe you just had a different opinion at the time (and some even
> now).
>
> However, in 1986, I took a Computer Systems Architecture course (don't
> recall the number) as an undergraduate at MIT , and one of the case
> studies was basically why Lisp machines were a "Non Winning" solution. In
> hindsight, the purpose of these case studies was to give the students
> (future engineers) the opportunity to learn from the mistakes made in the
> past and avoid repeating them in the future (and, occasionally, learn from
> correct decisions). In 1986, the mistake made by the Lisp industry in
> stubbornly sticking to proprietary architectures was readily apparent.
>
> At the time, Symbolics had just announced a brand new, lower cost (but
> still proprietary) system, and the consensus was that they were basically
> wasting time and money on that approach.
[upcoming comments are mix of specific answers and open requests to
anyone in particular.... is there some kinda etiquette for this?]
That explains a lot. I just discovered (sorta) Lisp a coupla weeks
ago.... and was quite surprised at just how ADVANCED the system is!
I wondered why not much visible work has happened since the beginning of
the 80's..... [I found LOTSA online material - and just finished
swallowing CLisp/2 manual [well - GLS's version]]
I mean, the modern GUI is an EXCELLENT example of LISP's success. It's
completely LISP compatible [if ya bother to code LISP to talk to it, that
is], and not a single worthwhile LISP engine for anything other than
XWindows+Motif [ick! Motif!] [pick your GUI - they all seem to hold
true... I've coded for most of them]
(aside: I'm restricted at the moment to Linux+X11+no motif)
So, where do we start to make LISP a visible success?
I'm going to try to do something to help things along. I LIKE lisp. It
makes a good alternate assembly language [grin]. I have LOTS of time on
my hands (and no money... so don't recommend any commercial software,
books, or anything involving money. I don't have any. Just a computer
and lots of time).
Personally, I don't know. If proprietary projects are what caused LISP's
failure -- what other choices are there? I mean, following Common Lisp's
standard is a good place to start [but I'm primarily a VR programmer -
and there's naught for standard VR in LISP].
I'm building a LISP engine... Both compiler/interpreter (actually - it
compiles dynamically dependant on available CPU cycles [sorta]).
I'm building it in C, 'cause I need a good assembly language and I don't
plan on only running it on an x86 processor.
Is there some kind of SIMPLE place for me to start? Someplace
incremental to begin? (such as the original LISP engine).
- NOT written in LISP. I DON'T have a runnable LISP engine!
- well... okay, maybe. Just keep it small....
I need information. I have NO access anywhere except online (am on
welfare basically - not fun). Any pointers would be appreciated.
Know of one of those old 16K LISP engines? Even in PDP-11 Assembly? (or
the like - it's easy enough to read :)
... Just need a starting place. Starting with attempting to be Common
Lisp/2 compatible day one is a bit much. Maybe in a couple of weeks -
but need somewhere to begin...
Oh, and anyone know where VEOS went?
Thanks muchly
- Teunis Peters
PS: In these days EVERYTHING is proprietary. Perhaps LISP's lack of
success was 'cause it didn't talk BASIC or Pascal (languages I have _NO_
thoughts even of planning to support. They're <icky>!!!). They were the
languages de jour of the mid-80's. EVERYONE coded in them if they
wanted to sell to the 'public' (whatever that is).
Ciao!
From: Erik Naggum
Subject: Re: Why lisp failed in the marketplace
Date:
Message-ID: <3065007098547235@naggum.no>
* Teunis Peters
| (aside: I'm restricted at the moment to Linux+X11+no motif)
:
| I have LOTS of time on my hands (and no money... so don't recommend any
| commercial software, books, or anything involving money. I don't have
| any. Just a computer and lots of time).
:
| I'm building a LISP engine... Both compiler/interpreter (actually - it
| compiles dynamically dependant on available CPU cycles [sorta]). I'm
| building it in C, 'cause I need a good assembly language and I don't plan
| on only running it on an x86 processor.
you might wish to ask Franz, Inc, to send you their free personal use
licence to the already completed Allegro Common Lisp environment for Linux.
it will save you about two hundred years of programming time, and it's more
fun to write in Common Lisp than to write your own implementation, anyway.
I think it may need RedHat 4.0, but I don't know how compatible the
different distributions of Linux are.
#\Erik
--
my other car is a cdr
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> you might wish to ask Franz, Inc, to send you their free personal use
> licence to the already completed Allegro Common Lisp environment for Linux.
> it will save you about two hundred years of programming time, and it's more
> fun to write in Common Lisp than to write your own implementation, anyway.
>
> I think it may need RedHat 4.0, but I don't know how compatible the
> different distributions of Linux are.
Make sure you get the patches for Linux ACL 4.3 from ftp.franz.com.
Yesterday I did install CL-HTTP 60.63 on my home Pentium PC (which is
accessible from the Internet, 32 MB RAM, 133 Mhz) with Linux and ACL 4.3.
The Apache server now has been removed.
Now I have CL-HTTP under Symbolics Genera 8.3, Macintosh Common Lisp 4.0
and ACL/Linux 4.3. Talk about portable code. The GUI doesn't matter anymore.
I think I will do some dynamic homepage building.
--
http://www.lavielle.com/~joswig/
In article <·······················@10.0.2.1>, ······@netcom.com (Henry
Baker) wrote:
> In article <··························@gjchome.nis.newscorp.com>, "George
> J. Carrette" <···@delphi.com> wrote:
>
> > 1. All of the lisp hardware vendors spent tens of millions of dollars
> > telling the world that special purpose hardware was required, that
> > using lisp without it was impractical, and that anybody who tried to
> > do otherwise was some kind of backward turkey bound to lose.
> > Shops who purchased these machines spent a huge about of money
> > and put a lot on the line in order to be state of the art.
>
> This is too broad a brush-stroke. There were some within Symbolics that
> pushed hard for a non-proprietary HW solution. The most vocal was
> Howard Cannon, who worked hard to develop an 80x86 capability.
>
> Also, with current large address spaces, large RAMs, large disks, and
> very high performance chips, it is easy to look backwards and criticize
> 'Lisp HW'. Keep in mind that with only 2-8 Mbytes of memory in the early
> 1980's, these machines had spectacular capabilities and performance. Rather
> than 'ride the wave' of Moore's Law, however, they just fell off the surfboard
> somewhere about 1986.
Redoing the Ivory in some modern chip process might be spectacular.
Still, I'm quite happy with MCL right now.
--
http://www.lavielle.com/~joswig/
In article <·································@news.lavielle.com>,
Rainer Joswig <······@lavielle.com> wrote:
>Redoing the Ivory in some modern chip process might be spectacular.
It might, but it would run into the same marketplace issues that the
original Ivory did. Basically, it's virtually impossible for a small
company to succeed with proprietary hardware, since they can't get the
economies of scale that the big guys could. This is also why Thinking
Machines (my former employer) eventually had to give up on being a hardware
vendor: they simply couldn't compete in price wars with Intel and IBM MPP
systems; so they switched to developing software that could be ported to
other MPP's or networks of workstations.
--
Barry Margolin
BBN Corporation, Cambridge, MA
······@bbnplanet.com
(BBN customers, call (800) 632-7638 option 1 for support)
From: William Paul Vrotney
Subject: Re: Why lisp failed in the marketplace
Date:
Message-ID: <vrotneyE5KGu2.Ctr@netcom.com>
In article <··········@tools.bbnplanet.com> ······@tools.bbnplanet.com (Barry Margolin) writes:
>
> It might, but it would run into the same marketplace issues that the
> original Ivory did. Basically, it's virtually impossible for a small
> company to succeed with proprietary hardware, since they can't get the
> economies of scale that the big guys could. This is also why Thinking
> Machines (my former employer) eventually had to give up on being a hardware
> vendor: they simply couldn't compete in price wars with Intel and IBM MPP
> systems; so they switched to developing software that could be ported to
> other MPP's or networks of workstations.
True, but this principle has nothing to do with proprietary or Lisp based
hardware. Motorola might have the same problem if Macs start using Intel as
well.
--
William P. Vrotney - ·······@netcom.com
From: Sin-Yaw Wang
Subject: Re: Why lisp failed in the marketplace
Date:
Message-ID: <330512CF.6458@acm.org>
George J. Carrette wrote:
>
> There were toy implementation of C available and that didn't seem to hurt
> C.
> So what really happened with LISP?
I guess this serves to answer historical interest. Few people really
care about this anymore.
I think fundamentally, Lisp syntax is not natural for human being. It
is elegant for computer or software to process, but not for real
people. From grade school, you are taught 10 = 8 + 2, not 10 = (+ 8
2). From high school, you learn how to prove mathematical theorems
procedually.
Basically, a procedural language is more "natural" than a symbolic one.
When I taught Scheme in school, it takes a good 2 weeks just to get the
recursive part into their heads.
If it is less natural, it is less productive, statistically speaking.
Companies lose using a less productive tool. It is a Darwinian
selective process.
--
Sin-Yaw Wang, ······@acm.org
http://www.concentric.net/~sinyaw/
From: William Paul Vrotney
Subject: Re: Why lisp failed in the marketplace
Date:
Message-ID: <vrotneyE5n3M2.MFE@netcom.com>
In article <·············@acm.org> Sin-Yaw Wang <······@acm.org> writes:
>
> I think fundamentally, Lisp syntax is not natural for human being. It
> is elegant for computer or software to process, but not for real
> people. From grade school, you are taught 10 = 8 + 2, not 10 = (+ 8
> 2). From high school, you learn how to prove mathematical theorems
> procedually.
>
Possibly when you went to college you did learn
g(f(x, y))
did you not?
> Basically, a procedural language is more "natural" than a symbolic one.
You're mixing recipes with sugar. Try again.
> When I taught Scheme in school, it takes a good 2 weeks just to get the
> recursive part into their heads.
>
What's unnatural about that? Recursion is a pretty hairy concept.
> If it is less natural, it is less productive, statistically speaking.
> Companies lose using a less productive tool. It is a Darwinian
> selective process.
>
At one time Roman numerals were considered more natural than Arabic. And
they were, at the time. It takes time for the fittest to survive.
--
William P. Vrotney - ·······@netcom.com
From: Earl & Daniella Harris
Subject: Re: Why lisp failed in the marketplace
Date:
Message-ID: <3305C84E.7EF0@widomaker.com>
Sin-Yaw Wang wrote:
>
> George J. Carrette wrote:
> >
> > There were toy implementation of C available and that didn't seem to hurt
> > C.
> > So what really happened with LISP?
>
> I guess this serves to answer historical interest. Few people really
> care about this anymore.
Well, I care. I guess I'm in the minority.
>
> I think fundamentally, Lisp syntax is not natural for human being. It
> is elegant for computer or software to process, but not for real
> people. From grade school, you are taught 10 = 8 + 2, not 10 = (+ 8
> 2). From high school, you learn how to prove mathematical theorems
> procedually.
I can't believe that Lisp failed in the marketplace because of its
syntax.
How hard is it to learn the syntax? Once you learn it, you never forget
it.
>
> Basically, a procedural language is more "natural" than a symbolic one.
> When I taught Scheme in school, it takes a good 2 weeks just to get the
> recursive part into their heads.
You don't mention why having symbols in a language would turn off the
marketplace.
By symbolic language, I assume you mean functional language. This could
be the root of the problem.
Why is recursion so hard for some people? Do people expect it to
be like a for loop? There are many programmers that have an unrational
fear of recursion.
>
> If it is less natural, it is less productive, statistically speaking.
> Companies lose using a less productive tool. It is a Darwinian
> selective process.
>
> --
> Sin-Yaw Wang, ······@acm.org
> http://www.concentric.net/~sinyaw/
Some would claim that C++ is an unnatural language that makes
programmers
more productive and has succeeded in the marketplace.
People who advocate C++ will admit that the language has a steep
learning curve. So, the language is "less natural." (If you think
understanding Lisp syntax is unnatural, try understanding all the in and
outs
of C++ message passing. Try understanding virtual functions and
templates.)
However, they come back and say that it is worth learning, because
C++ will make you MORE productive.
IMHO, Scheme hasn't succeeded in the marketplace because of marketing.
C++ is not perfect; but it is well-marketed.
Earl Harris Jr.
Earl & Daniella Harris <········@widomaker.com> writes:
>Sin-Yaw Wang wrote:
>>
>> I think fundamentally, Lisp syntax is not natural for human being. It
>> is elegant for computer or software to process, but not for real
>> people. From grade school, you are taught 10 = 8 + 2, not 10 = (+ 8
>> 2). From high school, you learn how to prove mathematical theorems
>> procedually.
>I can't believe that Lisp failed in the marketplace because of its
>syntax.
>How hard is it to learn the syntax? Once you learn it, you never forget
>it.
Yes, true. Once you learn it. The devil is in the details.
>>
>> Basically, a procedural language is more "natural" than a symbolic one.
>> When I taught Scheme in school, it takes a good 2 weeks just to get the
>> recursive part into their heads.
[ comments on a symbolic languages, deleted ]
>Why is recursion so hard for some people? Do people expect it to
>be like a for loop? There are many programmers that have an unrational
>fear of recursion.
Dare we say an "unnatural" fear of recursion?
I think a lot of it depends on a persons background. I can't comment on
how learning about computers, programming and problem solving using a
functional language would affect the way I view them today, because
I learned the completely opposite way. BASIC, Z80 Assembly, FORTRAN,
Pascal, C. I think that I can safely say that I could be productive in
any LANGUAGE that follows this kind of heritage VERY quickly. It is
VERY easy to write BASIC in FORTRAN, and Pascal in C. I'm not saying it
is good code, but it is simple, and it is practical.
Every "pseudo-code" I've seen looks, roughly, like Pascal.
From this kind of background, from this kind of knowledge base, Lisp
and Scheme are almost unapproachable casually. I don't know Ada, but I
am pretty confident I could get the gist of an algorithm written in
Ada. Heck, even the details. Without ever seeing Ada except maybe in a
magazine article.
The whole reason that I am involved in the Lisp/Scheme family of
languages at all today, is SPECIFICALLY because they are/were
unapproachable. Lisp is one of those languages that I never "got". I
could not look at a Lisp program and have any reasonable chance of
figuring out what it did. The parens could be distracting, the words
were complete greek (almost literally), and the layout was confusing.
I consider myself rather computer savvy, and it irked me that there
was a computer "thing" that I didn't "get". So, I made a concerted
effort to figure it out. It took a basic CS book to be my rosetta
stone, as it was talking about stuff I knew (CS concepts) in a
language I didn't (Scheme). For me, that was the breakthrough.
(Simply Scheme was the book, BTW)
Scheme and Lisp aren't particularly difficult to learn, if you throw
your preconceptions out at the door. And I imagine that they would
be wonderful for a first exposure to computing. It would, minimally,
give students a better foundation to base their programming skills on
no matter what language they choose in the future.
BUT, they ARE "different" from the typical bread and butter languages
of today. And the languages that one programs in influences how we
think about algorithms and problem solving. And when people approach a
problem, they use their past experiences to evaluate and solve the
problem.
So, if you throw a C programmer a block of Lisp Code, they almost
immediatly go into abort mode. Very little of their past experiences
translate well so the Lisp Code is immediately more "unreadable". Then
they pile on the preconcieved notions about Lisp, and the situations
just get worse. They give up. "I can't read this, this is Lisp." They
won't say that about Pascal. They won't say that about Basic. They'll
struggle through it and figure it out. Because half of the lines are
the same as C, and the constructs use the same verbs.
If you've ever read "The Little Lisp/Schemer" you'll notice that they
don't even mention the iterative constructs. All they ever use is
recursion. You wouldn't even know that Scheme had a (do ...) in it.
When you already have one language under your belt, you're going to
try find the similarities in the new one you're learning. So, I would
think if someone is learning functional Scheme, then "yes", they would
consider recursion the "for" loop.
I cannot comment on whether Lisp is less natural than Pascal, as I
learned the "other way" first. However, I will say that I think folks
with extensive, and exclusive, experience in one form versus the
other, they will have to make a major cognitive leap to pick up the
other form.
There is a lot of Baby Duck syndrome in computer languages. You know
and prefer what you learn first. Editors, computers, Moms Cooking,
deodorants, and girlfriends.
C/C++ have a LOT of mindshare/ad-space. Every "4GL" on the planet is a
trumped up BASIC. And there are a lot of Baby Ducks out their quacking
their way into their local Crown Books looking for something "technical"
about computers and programming. Blammo - they're infected for life.
The problem with marketing Lisp and Scheme is twofold.
One: the ads will be just as buzzword compliant as any other language
being marketed today, "So why switch?".
Two: The elegant, high level nature of the languages do not
communicate well on paper. They must be experienced. To be
experienced, you need to make that leap. That leap can be
difficult, particularly if you're just "playing with it."
Notice also, today, that the languages aren't being marketed as much
as the environments. Borland is not selling Object Pascal, they're
selling "Delphi - Fast, efficient RAD. Easy DB access, blah blah
blah". The C++ vendors throw in a couple of bullet points to note that
they're sorta kinda keeping up with the moving target standard, and,
oh by the way, "check out These Features" and "But wait, there's more!"
The vendors are trying to out "Ronco" each other.
You'll note that no where on these boxes does it mention "We provide
all of these features to make your life in C++ Hell that fraction more
pleasant, though hardly redeeming."
So I think it is fair to say that Lisp is not "natural". You can say
that about anything, actually. I mean, really, how's your Russian? (I
tried it, there isn't a whole lot that is "natural" in Russian :-)
:-))
It is sad that in a time when the general purpose machines available to
Joe Sixpack have anough oomph and resources to truly take advantage of
a full blown, in your face, Lisp Machine-esque envrironment, that the
bandwagon is so stuffed full of snake oil salesman, that the jewels are
difficult to find. And what's worse, most folks aren't willing to seek
them out.
--
Will Hartung - Rancho Santa Margarita. It's a dry heat. ······@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck
From: Erik Naggum
Subject: Re: Why lisp failed in the marketplace
Date:
Message-ID: <3065048088243385@naggum.no>
* Will Hartung
| It is sad that in a time when the general purpose machines available to
| Joe Sixpack have anough oomph and resources to truly take advantage of a
| full blown, in your face, Lisp Machine-esque envrironment, that the
| bandwagon is so stuffed full of snake oil salesman, that the jewels are
| difficult to find. And what's worse, most folks aren't willing to seek
| them out.
what makes _me_ sad is the focus on "most folks" and "Joe Sixpack".
why are we even _thinking_ about home computer equipment when we wish to
attract professional programmers?
in _every_ field I know, the difference between the professional and the
mass market is so large that Joe Blow wouldn't believe the two could
coexist. more often than not, you can't even get the professional quality
unless you sign a major agreement with the vendor -- such is the investment
on both sides of the table. the commitment for over-the-counter sales to
some anonymous customer is _negligible_. consumers are protected by laws
because of this, while professionals are protected by signed agreements
they are expected to understand. the software industry should surely be no
different. (except, of course, that software consumers are denied every
consumer right they have had recognized in any other field.)
Microsoft and its ilk has done a marvelous job at marketing their software
in the mass market so that non-professional programmers pick them up and
non-programmers who decide where the money should be wasted will get a warm
fuzzy feeling from certain brand names. I mean, they _must_ recognize that
nothing else they buy for their company is advertised in the newspapers
that morning and they aren't swayed by consumer ads when they buy office or
plant equipment, are they? so _why_ do they swallow this nonsense from the
mass-marketing guys hook, line, and sinker?
they don't make poles long enough for me want to touch Microsoft products,
and I don't want any mass-marketed game-playing device or Windows appliance
_near_ my desk or on my network. this is my _workbench_, dammit, it's not
a pretty box to impress people with graphics and sounds. when I work at
this system up to 12 hours a day, I'm profoundly uninterested in what user
interface a novice user would prefer.
I'm reminded of the response to how people of little or no imagination were
complaining about science fiction and incredibly expensive space programs:
"the meek can _have_ the earth -- we have other plans".
no, this is not elitist, like some would like to believe in order to avoid
thinking about the issues. this is just calling attention to the line
between amateurs and professionals, between consumers and producers, that
is already there in _every_ field. I want people to wake up to this
difference and _reject_ the consumer ads when they look for professional
tools. if it's marketed to tens of millions of people, it is _not_ for the
professional programmer, and not for you. if its main selling point is
novice-friendliness, ignore it unless you _are_ a novice. (and if you are
a novice trying to sell your services in a professional market, get the
hell out of the way.)
#\Erik
--
my other car is a cdr
With a mighty <················@naggum.no>,
····@naggum.no wibbled into the void...
> no, this is not elitist, like some would like to believe in order to avoid
> thinking about the issues. this is just calling attention to the line
> between amateurs and professionals, between consumers and producers, that
> is already there in _every_ field. I want people to wake up to this
> difference and _reject_ the consumer ads when they look for professional
> tools. if it's marketed to tens of millions of people, it is _not_ for the
> professional programmer, and not for you. if its main selling point is
> novice-friendliness, ignore it unless you _are_ a novice. (and if you are
> a novice trying to sell your services in a professional market, get the
> hell out of the way.)
I think that we agree about most of what you've said, but there are a
few points that I'd like to add.
The problem is that most people _are_ novices, and if you only write
software for the experts, then your market will be very small. What
most of us see as the computer industry (and I'm including the
workstation market) is only the size it is today because of the
success of small machines sold to to "small" users. A lot of those
users are now corporate users.
I don't expect these plebs to "get the hell out of the way", as you
put it. I expect them to steamroller over anyone who gets in _their_
way, and that includes you and me. Those consumer adverts that trouble
you are a symptom of this. It's happening.
Of course, a few of us will be fortunate enough to never have to use
consumer products. There's a word for such people, and here's a
definition (from the Collins English Gem Dictionary): n. the choice or
select body; the pick of the best part of society; aristocracy.
I'm not denying that there's a difference between amateurs and
professionals. I just don't believe that Lisp should be denied to
anyone based on their _existing_ (lack of) skills. Ignorance can be
corrected - it's only stupidity that will be a problem, and if we can
write software of a high enough quality, should that not give us a
competeitive edge over those who are less skilled?
If evolution _is_ possible, based on the survival of the fittest, then
this should be enough for us. On the other hand, if survival has
little to do with being the "fittest" (whatever that may mean), then
perhaps we are just an elite, using Lisp simply because we can.
However, there's another way of looking at it. We could be interfering
with "evolution" just as much as anyone else, when we choose Lisp. If
so few people recognise the value of Lisp, then we're expressing our
personal preferences by using Lisp. If that has no effect on the
masses of consumers, it could be that we're either writing the wrong
kind of software (apps that consumers don't want), or that there's
another bias, working against software written in Lisp and causing
such apps to "fails" (perhaps nothing more a C++ bigot trashing an app
written in Lisp, in a so-called "review").
So, do we have evolvution by natural selection or by selective
breeding based on the preferences of an elite? The "elite" could be
us, but I could just as easily be refering to the elite who decide
which tools their company will use/create/sell/etc. Perhaps the only
difference is the amount of power that we wield, i.e the number of
programmers/users that we directly influence/effect whenever we make a
choice.
Bill Gates wields a great deal of this power, and his choice has been
- in the past - Basic. Assuming that he made the choice to adopt C and
then C++ as the _other_ main development tool at MS, we might pause to
wonder how different history might have been if he'd been a fan of
Lisp, instead of Basic. Alas, we'll never know.
I'm not sure that it's too late to undo the damage that has been done
by Gates and MS, but I'm not yet ready to give up. Perhaps I have a
vested interest, in that I like being employed. That's why I'm keen to
find a way to use Lisp as part of my job. I have a much better chance
of doing this than most programmers in my position, as I know what
Lisp is capable of and I have an employer who is capable of
appreciating it.
There may not be many programmees like me, but its hard to tell. You
won't see any of my software on the shelves in a shop! Still, it's not
all doom and gloom. We're there...and looking for a Lisp that gives us
the same platform support that VB and VC++ already provide. _That's_
what Joe Sixpack wants, even when he wants to use Lisp.
Of course, if you think that Lisp shouldn't be used to write consumer
software, then just say so. There's no need to slag off such people
for being what they are. We'll understand you without the politics.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
From: Erik Naggum
Subject: Re: Why lisp failed in the marketplace
Date:
Message-ID: <3065132899827911@naggum.no>
* Cyber Surfer
| The problem is that most people _are_ novices, and if you only write
| software for the experts, then your market will be very small.
_all_ professional markets are small. I expect every professional to be an
expert in his field. novices should go to school. experts have graduated
and passed the equivalent of bar exams and review boards.
| Of course, a few of us will be fortunate enough to never have to use
| consumer products.
what are you talking about? are you a professional in every field of your
life? I only have time for one profession and dabbling in a few others.
I'm positively _delighted_ that I can buy consumer products so cheaply and
so conveniently, but -- get this -- I'm not in the business of making
microwave ovens or wine glasses or books or speakers, but I _do_ expect
those who _are_ to have professional tools, so I can buy consumer goods
inexpensively with moderately high quality. I don't _want_ Joe Blows'
Homemade Microwave Oven, OK?
I want "programmer" to be a professional title, with all the expectations
that come with it.
| I just don't believe that Lisp should be denied to anyone based on their
| _existing_ (lack of) skills.
to ask a rhetorical question first: why not? I'm moderately skilled in the
legal, medical, and veterinary professions, and I can discuss any issue I
might want to understand more fully with professionals and students in
these fields, but I hope I would be prosecuted if were to sell any such
services to the general public. in contrast, any goddamn idiot can call
himself a programmer.
I believe in professions. I really _like_ being able to trust my lawyer,
my doctor, and my cat's vet. for that matter, I really _like_ to trust
whoever approves the quality of the food I buy, too. but can I _trust_
somebody who calls himself a "programmer"?
I don't want to deny Lisp to anybody. you can buy a pack of scalpel blades
and lots of medical equipment at well-stocked drugstores if not directly
from the importer or vendor, but you don't become a doctor because you can
buy his tools! neither does a surgeon get his tools from K-Mart.
| Of course, if you think that Lisp shouldn't be used to write consumer
| software, then just say so. There's no need to slag off such people
| for being what they are. We'll understand you without the politics.
christ! please try to listen to what I say, will you? I want quality
languages to be used to write software _everywhere_, I just don't buy your
bogus argument that if the consumer can't use those languages himself, then
nobody else should be allowed to write in them, either. (at least that's
the message I'm getting from you, and you have been repeating it for many
months, now.)
tell you what. I receive some cast-away meat from dissections at my nearby
veterinary school, and I have absolutely no problem with filling my fridge
with dead animal parts. I enjoy studying the interior design of animals
while I feed my cat with the meat. if you wade through my garbage, you'd
find whole ribs, an assortment of bones, lots of animal skin, an occasional
hoof, and a large number of used scalpel blades. I really hope you
wouldn't come to me with a sick dog because of it, but that's the way many
people approach programmers.
the fact that I can buy scalpel blades wholesale and that I can buy a whole
lot of medical equipment and chemical compounds that could be used to kill
people and leave very little trace of it if I were so inclined, suggests to
me that I'm not in any way _denied_ access to the tools of the medical
profession. this is how I want things to be for programming, too, but I
want people who build our future society to be skilled at their work.
what makes me nervous about the future is that unskilled people who are as
likely to kill or maim information as to heal it are entrusted with our
past (i.e., accurate records), with critical information for decisions that
affect lives and careers, and with all kinds of other information too
difficult or too voluminous to let people handle directly. our society is
totally dependent on the accuracy of its information. we entrust that
accuracy to unskilled labor and household-grade tools. that would be like
doing open heart surgery on your living-room table with only kitches
utensils. (I use the proper medical equipment on the dead animals I get,
because kitchen utensils aren't fit for the job at all.)
I'm considering having my cat sterilized. I have almost all the equipment
I need to do the procedure at home, I know vaguely what to do, and I'm sure
I could have her sterilized safely and painlessly given some other cats to
experiment on first. however, I have only one cat, I don't think killing a
lot of cats just to let me learn something somebody else already knows is a
good idea, and I love this little animal, so I'm going to let a vet handle
it. I think companies should think about their information with equal
care, and leave the job to real professionals. unfortunately, Microsoft is
trying to tell us that we should all sterilize our pets (or fix the heart
problems of our parents) at home, with Microsoft kitchen utensils, which we
know break at any inkling of pressure. I happen to think that _many_ more
lives would depend on accurate information and fully operational and
functional software systems than could ever be lost if we let quacks loose
on the world, because people who wanted to live would have the brains to
_demand_ the necessary means to ascertain the quality of those who could
mess with their health, but they obviously _don't_ have the brains to even
accept that programmers need to be accredited professionals.
#\Erik
--
my other car is a cdr
With a mighty <················@netcom.com>,
······@netcom.com wibbled into the void...
> The whole reason that I am involved in the Lisp/Scheme family of
> languages at all today, is SPECIFICALLY because they are/were
> unapproachable. Lisp is one of those languages that I never "got". I
> could not look at a Lisp program and have any reasonable chance of
> figuring out what it did. The parens could be distracting, the words
> were complete greek (almost literally), and the layout was confusing.
Was this before you read a Lisp tutorial? I learned Basic from a
manual, which probably didn't help my coding style - I learned a lot
of that from a book that used PL/I and Fortran code. I later added to
this when I learned Forth, APL, Lisp, and a few other languages. I've
never learned PL/I or Fortran, as the book I mentioned about didn't
teach those languages. (Can you guess which book that was?)
> Scheme and Lisp aren't particularly difficult to learn, if you throw
> your preconceptions out at the door. And I imagine that they would
> be wonderful for a first exposure to computing. It would, minimally,
> give students a better foundation to base their programming skills on
> no matter what language they choose in the future.
Yes, a book that starts from absolute basics can help, esp if you're
prepared to go back to the basics and forget all the things that you
_think_ you know about programming.
> BUT, they ARE "different" from the typical bread and butter languages
> of today. And the languages that one programs in influences how we
> think about algorithms and problem solving. And when people approach a
> problem, they use their past experiences to evaluate and solve the
> problem.
That's why I enjoy learning new programming languages. I can learn to
look at problems in new ways, and then see how much of my existing
experience might apply. It's hard work, but rewarding.
> So, if you throw a C programmer a block of Lisp Code, they almost
> immediatly go into abort mode. Very little of their past experiences
> translate well so the Lisp Code is immediately more "unreadable". Then
> they pile on the preconcieved notions about Lisp, and the situations
> just get worse. They give up. "I can't read this, this is Lisp." They
> won't say that about Pascal. They won't say that about Basic. They'll
> struggle through it and figure it out. Because half of the lines are
> the same as C, and the constructs use the same verbs.
As I said, it's hard work. Those of us who take to Lisp like a duck to
water can easily forget just how hard it is for everyone else. I've
never been afraid of abstractions - just the opposite, in fact - but I
may be one of the exceptions. C is very simple to understand because
it looks so much like assembly language. It's very close to the
machine level, with few abstractions beyond what the concept of a CPU
demands from a programmer.
Attacks on Lisp from C/C++ programmers tend to focus on the features
that distinguish Lisp from C, and which are simply enough for a C/C++
programmer to _think_ that they understand them. Garbage collection is
a perfect example. A C programmer won't like the idea of the language
doing things behind their backs, like moving objects about. It won't
matter that this can help an app perform _better_, as it's outside the
experience of the C programmer, and it'll make them uncomfortable.
Some of them might even feel the same way about VM!
> If you've ever read "The Little Lisp/Schemer" you'll notice that they
> don't even mention the iterative constructs. All they ever use is
> recursion. You wouldn't even know that Scheme had a (do ...) in it.
> When you already have one language under your belt, you're going to
> try find the similarities in the new one you're learning. So, I would
> think if someone is learning functional Scheme, then "yes", they would
> consider recursion the "for" loop.
If there was a "Scheme for C++ Programmers", I'd hope that it would
show how tail recursion in C can be optimised into a "while" loop.
That should help make a C/C++ programmer feel more comfortable.
A few words, or even pages, on code transformation would also help.
> I cannot comment on whether Lisp is less natural than Pascal, as I
> learned the "other way" first. However, I will say that I think folks
> with extensive, and exclusive, experience in one form versus the
> other, they will have to make a major cognitive leap to pick up the
> other form.
A number of educational institutions teach programming using Lisp or a
more functional language (Haskell, SML, Hope, etc). Perhaps a student
from one of the places could comment. I too learned programming using
an imperative style, but I had no trouble adapting. I could just be an
exception, of course.
> There is a lot of Baby Duck syndrome in computer languages. You know
> and prefer what you learn first. Editors, computers, Moms Cooking,
> deodorants, and girlfriends.
<grin> This is very true. Also, some people will strongly resist
change or new ideas (that is, ideas that are new to _them_).
> C/C++ have a LOT of mindshare/ad-space. Every "4GL" on the planet is a
> trumped up BASIC. And there are a lot of Baby Ducks out their quacking
> their way into their local Crown Books looking for something "technical"
> about computers and programming. Blammo - they're infected for life.
Yeah, imagine if somebody had put Lisp on the Altair, before Basic.
A whole empire might've been built using Lisp, instead of toy
languages. Curiously, some people MS are trying to correct this error,
by applying functional ideas to VRML scripting. I wish them luck!
> The problem with marketing Lisp and Scheme is twofold.
>
> One: the ads will be just as buzzword compliant as any other language
> being marketed today, "So why switch?".
Any change that requires effort without a quick reward will be
unpopular. Moving to Lisp from C requires a lot of effort, which means
that the reward will be slow. We know that it'll be worth it, but
that's because we've made that change already.
We live in a world of bean counters, where the cost is everything,
and the value means nothing at all. Hence the popularity of C/C++.
> Two: The elegant, high level nature of the languages do not
> communicate well on paper. They must be experienced. To be
> experienced, you need to make that leap. That leap can be
> difficult, particularly if you're just "playing with it."
I'm not so sure about this. I doubt it because _I_ was able to
understand it, just by reading about it. However, I can understand a
lot of things by just reading about them, while other programmers may
need a little more. I agree that experience can certainly help form a
deep understanding.
> Notice also, today, that the languages aren't being marketed as much
> as the environments. Borland is not selling Object Pascal, they're
> selling "Delphi - Fast, efficient RAD. Easy DB access, blah blah
> blah". The C++ vendors throw in a couple of bullet points to note that
> they're sorta kinda keeping up with the moving target standard, and,
> oh by the way, "check out These Features" and "But wait, there's more!"
> The vendors are trying to out "Ronco" each other.
Yes, I've noticed this, too. Environments like VB and Delphi have a
lot too teach C++ people, not just Lisp hackers. The language alone
isn't enough anymore, at least not for platforms like Windows.
> It is sad that in a time when the general purpose machines available to
> Joe Sixpack have anough oomph and resources to truly take advantage of
> a full blown, in your face, Lisp Machine-esque envrironment, that the
> bandwagon is so stuffed full of snake oil salesman, that the jewels are
> difficult to find. And what's worse, most folks aren't willing to seek
> them out.
Most folks are ignorant. Fortunately, they're not stupid. If there
were a few mainstream apps written in Lisp, and everyone _knew_ they
were written in Lisp, and they outperformed anything not written in
Lisp, then it _might_ begin to change. The only reason that I doubt
this is that I expect there to be just as much BS. It's not enough for
Lisp to be better than C++, it's necessary to do it on C++ ground,
and to be _undeniably_ better.
I've often seen AI apps given as examples of Lisp apps, which doesn't
exactly help dispel the image that Lisp is only good for AI. Bizarre
tho it may be, some people see AI as something to avoid. I guess
they've not noticed AI techniques creeping into the "real world".
Right now, most people won't even know that Lisp is still _used_,
never mind capable of beating C++. That's how bad the problem is.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
On Wed, 19 Feb 1997 03:00:34 GMT, ········@csclub.uwaterloo.ca (Paul
Prescod) wrote:
>But until you pick up a Lisp or Scheme book it really does look like Greek:
>car, cdr, lambda, "if" with no visually obvious else or then. I'm not
>sure what to do about that at this point. Does it make sense to define the
>semantics of a programming language and its syntax separately, so we could
>have an alternate Scheme encoding that looked like ML without the patterns or
>Dylan?
That's my approach with ARGOT. Since I'm throwing Scheme compatability
out the window anyway, we do without car and cdr (first and rest for
me, thanks!) and the syntax is left politely unspecified. I'm using
fun and proc rather than lambda, BTW, with the caveat that things
defined as proc have specific evaluation order whereas fun's are
purely functional. The compiler/interpreter reads in objects and spews
out objects. The current syntax module uses parentheses, purely
because I want to learn Lisp syntax (I love a challenge) and because
it was easy to write the parser!
>It really seems like a waste to invent a whole new programming language to
>make Scheme's and Lisp's syntaxes more approachable for Joe Programmer.
Exactly.
> Paul Prescod
ABW
--
"Simply drag your mother in law's cellphone number from the
Address Book to the Laser Satellite icon, and the Targeting
Wizard will locate her. Then follow the onscreen prompts for
gigawattage and dispersion pattern..."
(Windows for Early Warning and Defence User's manual P385)
Alaric B. Williams Internet : ······@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>
In article <················@netcom.com>,
Will Hartung <······@netcom.com> wrote:
>A lot of this is based upon, I believe, first impressions. At a
>glance, Lisp looks so different to someone experienced in a more
>conventional language, they immediately make it more difficult because
>it LOOKs like its more difficult.
I agree that this is just a first impressions thing. The syntax is not
really very difficult. But programmers will naturally gravitate towards
languages that are close to what they know. Now that I know Scheme, I'll
probably learn CL when I get a chance. But I still have no interest in
braving Mount APL. On the other hand, if I knew J, I would probably tackle
APL when I had an opportunity.
The parenthesis make Lisp-family functional languages seem more divergent
than they have to. Perhaps new languages should be specified with the
syntax and semantics more distinct so that people can experiment a little
more.
>I appreciate Eriks point about not WANTING more Joe Programmers
>jumping in the pool. Since Lisp is a little more unconventional, less
>mainstream, only truly motivated people focus on it, so one could
>almost say that what Lisp programmers ARE available are better at what
>they do, because they WANT to be where they are, and need to work at
>it.
If all of the Joe Programmers who ignore Lisps were people I felt were
incompetent or stupid, I wouldn't care. But many of them are smart and
knowledgable. It is often the smartest people who say either: "I am
smart enough that I can code in any language, so I will use whatever is
most convenient (i.e. whatever is installed, has the best platform
support, has already been purchased by management, ...)" or "I am smart
enough that I do not trust anyone else to manage my memory, or fix up
my tail recursions as well as I do."
Paul Prescod
--Cyberdog-AltBoundary-000AF0D2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Fri, Feb 21, 1997 5:24 PM, Paul Prescod
<···············@csclub.uwaterloo.ca> wrote:
>If all of the Joe Programmers who ignore Lisps were people I felt
>were
>incompetent or stupid, I wouldn't care. But many of them are smart
>and
>knowledgable. It is often the smartest people who say either: "I am
>smart enough that I can code in any language, so I will use
>whatever is
>most convenient (i.e. whatever is installed, has the best platform
>support, has already been purchased by management, ...)" or "I am
>smart
>enough that I do not trust anyone else to manage my memory, or fix
>up
>my tail recursions as well as I do."
>
Interesting... and highly reminiscent of the arguments made
by assembly-language programmers resisting the change to C
some 10-12 years ago.
BTW, (to inject at least a little bit of useful information
into this thread), there's a new book which discusses algorithms
for automatic dynamic memory management: "Garbage Collection"
by Jones & Lins, Wiley, 1996, ISBN 0 471 94148 4. Well worth a
careful read whether or not you believe that you can do better
using hand-coded memory managment.
Dave
--Cyberdog-AltBoundary-000AF0D2
Content-Type: multipart/mixed; boundary="Cyberdog-MixedBoundary-000AF0D2"
Content-Transfer-Encoding: 7bit
--Cyberdog-MixedBoundary-000AF0D2
Content-Type: text/enriched; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<X-FONTSIZE><PARAM>12</PARAM><FIXED><FONTFAMILY><PARAM>Courier</PARAM>O=
n Fri, Feb 21, 1997 5:24 PM, </FONTFAMILY></FIXED></X-FONTSIZE>
--Cyberdog-MixedBoundary-000AF0D2
Content-Type: application/X-url
Content-Transfer-Encoding: base64
Content-Description: Paul Prescod
bWFpbHRvOnBhcHJlc2NvQGNzY2x1Yi51d2F0ZXJsb28uY2E=
--Cyberdog-MixedBoundary-000AF0D2
Content-Type: text/enriched; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<X-FONTSIZE><PARAM>12</PARAM><FIXED><FONTFAMILY><PARAM>Courier</PARAM>
wrote: </FONTFAMILY></FIXED></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><=
FIXED><FONTFAMILY><PARAM>Courier</PARAM>
</FONTFAMILY></FIXED></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FIXED><=
FONTFAMILY><PARAM>Courier</PARAM>>If all of the Joe Programmers who
ignore Lisps were people I felt
>were
>incompetent or stupid, I wouldn't care. But many of them are smart
>and
>knowledgable. It is often the smartest people who say either: "I am
>smart enough that I can code in any language, so I will use
>whatever is
>most convenient (i.e. whatever is installed, has the best platform
>support, has already been purchased by management, ...)" or "I am
>smart
>enough that I do not trust anyone else to manage my memory, or fix
>up
>my tail recursions as well as I do."
></FONTFAMILY></FIXED></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FIXED>=
<FONTFAMILY><PARAM>Courier</PARAM>
Interesting... and highly reminiscent of the arguments made
by assembly-language programmers resisting the change to C
some 10-12 years ago.
BTW, (to inject at least a little bit of useful information
into this thread), there's a new book which discusses algorithms
for automatic dynamic memory management: "Garbage Collection"
by Jones & Lins, Wiley, 1996, ISBN 0 471 94148 4. Well worth a
careful read whether or not you believe that you can do better
using hand-coded memory managment.
Dave
</FONTFAMILY></FIXED></X-FONTSIZE>
--Cyberdog-MixedBoundary-000AF0D2--
--Cyberdog-AltBoundary-000AF0D2--
From: Erik Naggum
Subject: Re: Why lisp failed in the marketplace
Date:
Message-ID: <3065006619145978@naggum.no>
* Sin-Yaw Wang
| I think fundamentally, Lisp syntax is not natural for human being.
I think, fundamentally, human beings differ a great deal in very many
respects. some find infix natural. others find that infix is not so
natural as to be worth their cost (such as very complex syntaxes). these
may not be the majority, but there are enough of them to keep Hewlett-
Packard's calculator division alive and well.
| From grade school, you are taught 10 = 8 + 2, not 10 = (+ 8 2). From
| high school, you learn how to prove mathematical theorems procedually.
how much of what you learned in grade and high school do you use as an
argument against other seemingly contradictory developments? what you
learn first is only evidence that you can't learn everything at once. the
order chosen today should not be considered proof of a particular order as
being more natural than others.
| If it is less natural, it is less productive, statistically speaking.
on the face of it, the reverse seems to be true. if what is natural to the
_untrained_ is a measure of anything, all of society should have been
_less_ productive than living off what can be gathered and hunted.
I think education, learning, training is _precisely_ what is natural for a
human being, and much of what we learn goes to disprove earlier teachings,
especially if we make unwarranted assumptions from those earlier teachings.
| Companies lose using a less productive tool. It is a Darwinian selective
| process.
I always wondered how large companies came to be. thank you for this lead.
I did some research on Darwin's theories of natural selection, and here's
what I found: millions of years ago, much smaller companies than today gave
birth to many small companies, some of them mutants that were better fit
for survival in the intensely competitive underbrush of the ancient world.
the natural selection favored companies that could breed early and mutate
faster, but some species of companies had found a stable breeding cycle and
grew to very large sizes and lived for a very long time. these were the
elephantine companies. to this day, Wall Street, their secret breeding
ground, will honor their age-old breeding rituals that have completely lost
their meaning in the modern world, but they were probably beneficial to the
early elephantines. contrary to popular belief, Darwinian selection is not
just an historic process -- the smaller company species still mutate and
develop in new directions, but even though they do so much faster than the
elephantines, it is difficult to spot it when it happens. if you watch a
company carefully, you might be so lucky to find that it eats more pizza
and take-out food right before it spawns a new company.
much research has gone into the Darwinian selective process as it applies
to companies. of popular interest are Sir Richard Attenborough's excellent
TV series (on PBS) that documents the slow, but steady migration and growth
of companies. Dr. Richard Dawkins has written several books, including The
Blind Stockbroker and The Selfish Meme that both argue strongly for natural
selection and against creationism that says that companies were created out
of nothing by a higher intelligence. however, there are also critics of
Darwin's work on The Origin of the Companies. Erich von Danicken contends
that today's companies are the result of protocompanies planted on earth by
the split-infinitive voyages of Star Trek, The Previous Generation.
now, they don't teach these things in high schools, do they? this goes to
show something, I'm sure.
#\Erik
--
my other car is a cdr
I am only an egg, but I think that just about everyone in this discussion
is making a questionable presupposition: that effects have causes in the
world of business. Several people (with very different opinions about
the original question!) have made analogies about "survival of the fittest."
Do I have to remind everyone about Microsoft?
The people who live by owning the means of production -- that is, by
stealing other people's labor -- need to promote the myth that financial
success is the deserved result of really smart decision-making.
But much more often, it's the result of plain dumb luck, being in the
right place at the right time, such as for example getting a contract
from IBM to develop the operating system for what will later turn out
to be (also for no very good reason) the most successful computer
architecture.
I don't mean to go to the opposite extreme and suggest that decisions
have no consequences. Certainly it's possible to shoot oneself in the
foot. But there is no iron law of consequences; otherwise Microsoft
(again) would have died when they adamantly insisted for some time
that the Internet was irrelevant. They overcame that wrong decision
through the inertia of power.
Lisp, on the other hand, has always suffered from an inertia of
perceived weirdness. That guy in this thread who doesn't like
infix is all too representative of the rest of the world.
Again, I'm not arguing that Symbolics did everything right, or that
other choices couldn't have been more successful -- but my guess is
that different decisions wouldn't have had *much* effect.
··@anarres.CS.Berkeley.EDU (Brian Harvey) writes:
> Several people (with very different opinions about the original
> question!) have made analogies about "survival of the fittest."
>
> Do I have to remind everyone about Microsoft?
As much as "survival of the fittest" is really "survival of that which
fits", I'd have to say that Microsoft certainly fits in perfectly in
today's marketplace -- they produce things that almost work and spend
a lot of money advertising to the right people.
--
(domestic pets only, the antidote for overdose, milk.)
·····@ifi.uio.no * Lars Ingebrigtsen
With a mighty <··········@agate.berkeley.edu>,
··@anarres.CS.Berkeley.EDU wibbled into the void...
> I am only an egg, but I think that just about everyone in this discussion
> is making a questionable presupposition: that effects have causes in the
> world of business. Several people (with very different opinions about
> the original question!) have made analogies about "survival of the fittest."
>
> Do I have to remind everyone about Microsoft?
I've often made this point. MS may suck, but they also succeed.
> The people who live by owning the means of production -- that is, by
> stealing other people's labor -- need to promote the myth that financial
> success is the deserved result of really smart decision-making.
Err, I wouldn't use the word 'stealing', but I _think_ I see what
you're saying.
> But much more often, it's the result of plain dumb luck, being in the
> right place at the right time, such as for example getting a contract
> from IBM to develop the operating system for what will later turn out
> to be (also for no very good reason) the most successful computer
> architecture.
Some might say that this isn't luck, but good business sense putting
you in the right place at the right time. Let's not underestimate
their acheivements _before_ IBM gave them the biggest break that a
young computer company could hope for. Unfortunately, on the technical
front, it was all downhill from then on.
Still, let's not forget some IBM's other mistakes, before and after.
If they'd waited a little longer, they could've used the 68K, giving
Macs and PCs a common CPU. I'm assuming that would've been a Good
Thing, like allowing the Mac OS and software to migrate to the PC
hardware, thus changing history.
There are so many missed opportunities like this that I'd say that
some of it is certainly chance, but only if you have no vision and let
yourself be swayed by every little gust of wind. Perhaps this is what
"good business sense" does to an industry. A little more vision
could've made a hell of a difference, but we'll never know.
There are visionary ideas still waiting to be picked up by the
commercial world. The simple idea of interactive computing still meets
a degree of resistance, even now. Never mind the equally radical idea
of making it _easy to use_...You'd expect _that_ to sell a few boxes.
> I don't mean to go to the opposite extreme and suggest that decisions
> have no consequences. Certainly it's possible to shoot oneself in the
> foot. But there is no iron law of consequences; otherwise Microsoft
> (again) would have died when they adamantly insisted for some time
> that the Internet was irrelevant. They overcame that wrong decision
> through the inertia of power.
That was too short a period of time. It takes a long time for a giant
like MS to die. What we'll probably find is that sometime parts of MS
will die, but they'll continue by changing direction and fucusing on
their remaining strengths. Just look at IBM.
> Lisp, on the other hand, has always suffered from an inertia of
> perceived weirdness. That guy in this thread who doesn't like
> infix is all too representative of the rest of the world.
Do yo know where the word 'weird' comes from? The Way of the Weird
isn't as feared as it used to be, but the old meaning of the word has
been long forgotten, while the belief system that inspired it has
gained a significant degree of respectability.
If the establishment won't embrace Lisp in the same way, at least we
too might gain some degree of respectability. Perhaps the Dylan people
have the right idea, by using a name that doesn't have the old and
possibly negative associations for most people.
Lisp _is_ the Way of the Weird, in programming terms. Imagine a group
of Lisp hackers, once a year gathering at a ring of stone lambdas.
Most people might not understand why we do it, but do we have enough
respect for the establishment to protect our right to practice our
beliefs? I think so. Like the druids, we may have (relatively) small
numbers, but we're still here, and I expect we'll be here when long
after C++ is just a footnote in history.
BTW, did you mean that disliking infix is "all too representative of
the rest of the world", of the exact opposite? Infix addicts can use a
Lisp-like language such as Dylan.
> Again, I'm not arguing that Symbolics did everything right, or that
> other choices couldn't have been more successful -- but my guess is
> that different decisions wouldn't have had *much* effect.
This is certainly debatable - look at us, we're debating it! ;-)
I don't think that we should blame Symbolics for everything that is
"wrong" with Lisp. Perhaps the infix/postfis issue is more
significant? Some ideas are too radical for most people, either
because they're ahead of their time, or because not enough people want
these kind of features.
What most people want is simply software that does what they want -
they don't want to know about the internals. Almost all software today
reveals _something_ about the thinking of the people who created the
software, instead of the thinking of the people who'll use it.
In other words, Xerox PARC got it both right _and_ wrong. An OS is the
wrong thing, but we'll need something that allows us to distribute
code to users in a manner that doesn't require the user to become a
programmer. This is something an OS with a GUI can do very well. For
pure research, you don't need an OS. In the "real world", most people
insist that you need one. So it goes.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
Cyber Surfer wrote:
> Infix addicts can use a Lisp-like language such as Dylan.
Or Java.
I find the sudden popularity of Java very amusing -- its praises being
sung by the same people who would laugh if you suggested they use Lisp.
It really is all marketing, guys. Not just "selling" -- but designing
technologies to fill needs that people actually have and know they
have. Lisp was not the answer to very many people's question.
So look what Gosling did: he found an key application (applets) which
required a safe language with certain security features. Since existing
safe languages generally suffered from excessively large implementations
or other deficiencies in the context of creating applets, there was a
need for a new language. Gosling filled the need without introducing
any unnecessary incompatibility (e.g., in the syntax) with something a
lot of people already knew. The applet market (not having previously
existed) was one that, fortunately, would tolerate *necessary*
incompatibility.
And I think it's going to work. I gather people are already using Java
for a lot more than applets. Java is going to educate the market about
the value of a safe, GCed language. Will people then turn to Lisp?
Probably not Lisp as we know it, but hey, whaddya want? This is surely
progress already.
Also, I think people are just now coming to feel that they actually have
spare CPU cycles to spend on things like GC. At 150 SPECmarks, you have
to be doing some pretty serious crunching to notice 20% overhead. If
you're just operating a GUI, you'll never feel that bite.
> > Again, I'm not arguing that Symbolics did everything right, or that
> > other choices couldn't have been more successful -- but my guess is
> > that different decisions wouldn't have had *much* effect.
>
> This is certainly debatable - look at us, we're debating it! ;-)
Again, I think you have to look at it from the marketing angle. Lisp
had a key application too: AI. When AI was thoroughly oversold and came
to be perceived as a failure, Lisp went with it.
Personally, I think AI will yet rise from the ashes. I suppose it might
bring Lisp back as well.
Here's another ray of hope. One of the reasons we love Lisp is that
it's a dynamic environment, right? If you look at what has driven the
relational database revolution in the course of the last decade or so --
why relational databases have become so popular as to displace
practically everything else -- it turns out, as near as I can tell, to
be the fact that a relational database is a dynamic environment which
can be used interactively. What other reason would it be? Certainly
not performance! The relational model is simple and elegant but is a
classic Procrustean bed; you have to organize your data its way, not the
way you would normally go about it. Really, the relational database is
clearly inferior to the old network database it supplanted in every way
except one: a relational database lets you reorganize your data at any
time, while reorganizing a network database is a daunting task.
("Network" here describes the structure of the database, and is not a
reference to LANs or WANs or such.)
Well, people in this NG may not care much about databases, but the point
is, the market can be sold on dynamic environments, with their
corresponding overhead, if they solve a severe enough problem.
-- Scott
With a mighty <·················@zeta-soft.com>,
····@zeta-soft.com uttered these wise words...
> And I think it's going to work. I gather people are already using Java
> for a lot more than applets. Java is going to educate the market about
> the value of a safe, GCed language. Will people then turn to Lisp?
> Probably not Lisp as we know it, but hey, whaddya want? This is surely
> progress already.
I agree. While I have no intention of using Java myself, I'm glad it's
there, so I can point to it and say, "Apart from the browser stuff, I
can do all that in Lisp. In fact, I've been _doing_ it in Lisp..."
This is why I also welcome Dylan. If an implementation like DylanWorks
can do all the things that C++ currently does - _without_ any special
effort from the programmer - then who knows? Perhaps the general
perception of Lisp as something that died out years ago will change.
Someone recently asked me if there was a problem in the software I was
using to read his posting, and if that was because it was written in
Lisp. (He doesn't seem to think much of Lisp.) Someone else pointed
out that _he_ was reading our posts using GNUS. ;-)
> Also, I think people are just now coming to feel that they actually have
> spare CPU cycles to spend on things like GC. At 150 SPECmarks, you have
> to be doing some pretty serious crunching to notice 20% overhead. If
> you're just operating a GUI, you'll never feel that bite.
This is true. Yet there are programmers who insist that "taking
control" is necessary. I wonder if they realise that their disk usuage
might also be more "efficient" if they also managed that themselves?
How many of us need to use surface indexing, today?
> Again, I think you have to look at it from the marketing angle. Lisp
> had a key application too: AI. When AI was thoroughly oversold and came
> to be perceived as a failure, Lisp went with it.
I like to stress "real world" uses of AI, rather than the traditional
kinds of AI, as most people perceive it as having nothing to do with
them. This seems very odd to me, considering how useful AI can be for
data processing. Um, data mining? Blackboards?
Would it be fair for me to refer to cruise missiles as a real world
application of AI? It's one that few people will have failed to have
heard of, and yet guiding a missile at street level at high speed
could easily be described as AI. It also sounds pretty damn "real
world" to me. Then there's the funding of AI...
Altho I've misplaced the URL now, I've seen a Scheme to C compiler
with an export licence that classed it as munitions. Curious. ;)
> Personally, I think AI will yet rise from the ashes. I suppose it might
> bring Lisp back as well.
I don't think AI has ever been dead. It's only been perceived as dead
by those who don't like it. (Goodness knows why!) Are some apps
relabeled as non-AI, as soon as they prove to be useful?
> Here's another ray of hope. One of the reasons we love Lisp is that
> it's a dynamic environment, right? If you look at what has driven the
> relational database revolution in the course of the last decade or so --
> why relational databases have become so popular as to displace
> practically everything else -- it turns out, as near as I can tell, to
> be the fact that a relational database is a dynamic environment which
> can be used interactively. What other reason would it be? Certainly
> not performance! The relational model is simple and elegant but is a
I've been pondering this myself for a while now. I watch a colleage
work with databases using Visual Basic and Excel, and I can't see
anything that he does that couldn't be done in Lisp, just as well if
not better. Of course, I don't have any experience with databases, so
I don't get those jobs, so I can't test this. Instead, I get given the
jobs that require C++.
To be fair, I'm more experienced with C++ than he is, just as he's
more experienced with VB than I am. I'm just not sure that saying, "I
could do that in Lisp", would be enough. For a start, I'm only in the
office one day a week, so this could be an acedemic point. It would be
better if a Lisp programmer were in a position where such database
jobs could be offered to them, and they could then say, "Hey! I can do
that (in Lisp)", or even, "All done, and I did it much faster/better
because I used Lisp."
> classic Procrustean bed; you have to organize your data its way, not the
> way you would normally go about it. Really, the relational database is
> clearly inferior to the old network database it supplanted in every way
> except one: a relational database lets you reorganize your data at any
> time, while reorganizing a network database is a daunting task.
> ("Network" here describes the structure of the database, and is not a
> reference to LANs or WANs or such.)
Well, you may have to work with what you're given. Some of us are
given relational database to work with, because that's what our
clients use. I'm not sure that reverse engineering somebody's database
in Lisp is always going to be a good idea. There are certainly special
cases where it'll work, tho.
> Well, people in this NG may not care much about databases, but the point
> is, the market can be sold on dynamic environments, with their
> corresponding overhead, if they solve a severe enough problem.
I'm working with very small databases right now, but that's only
because I've chosen to use a database format for some tabular data,
and because one of the tools I'm using works with databases. If I used
"Lisp files" (a series of sexprs in a file), then I'd lose all the
leaverage these tools give me. However, I seriously considered it.
Perhaps the idea of having to pay for Lisp tools is what makes me
hesitate, while the non-Lisp tools are given to me for "free", as
we're using them already. That's another kind of leaverage, of the
financial kind. I wonder how much DylanWorks will cost...?
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
Cyber Surfer (············@nospam.wildcard.demon.co.uk) wrote:
> I'm not sure that reverse engineering somebody's database
> in Lisp is always going to be a good idea.
Certainly not, if the "database" happens to deserve that name, rather
than merely being some kind of dbase-like collection of files. Some
systems are easily approaching or exceeding 2**32 records per file, with
a lot of such files being used by an integrated application, using a
complicated transaction logic. You could hardly keep that in memory on
typical workstations, or try to manage it with Joe Average's home grown
file organization ;-) However, I'd certainly prefer to use some really
expressive programming language for such applications, being sufficiently
powerful to let database access be an integrated part of the general
programming language. Lisp would be an excellent vehicle for the purpose,
getting rid of those ugly database languages embedded in crippled 4GLs,
which let you access large amounts of data, but make it hard to program
anything more complicated than a personal diary (imagine such a system
with nearly 20000 modules in several variants, and you may begin to
understand why I'm associating horror with such garbage as SQL and its
relatives ;-).
-- Marc Wachowitz <··@ipx2.rz.uni-mannheim.de>
With a mighty <··········@trumpet.uni-mannheim.de>,
··@ipx2.rz.uni-mannheim.de uttered these wise words...
> Cyber Surfer (············@nospam.wildcard.demon.co.uk) wrote:
> > I'm not sure that reverse engineering somebody's database
> > in Lisp is always going to be a good idea.
>
> Certainly not, if the "database" happens to deserve that name, rather
> than merely being some kind of dbase-like collection of files. Some
> systems are easily approaching or exceeding 2**32 records per file, with
> a lot of such files being used by an integrated application, using a
> complicated transaction logic. You could hardly keep that in memory on
> typical workstations, or try to manage it with Joe Average's home grown
Most of the databases that I've seen are much smaller and simple than
that, and some of them might easily be stored in the workspace of a
Lisp system - except that most people don't use Lisp, and don't even
consider this style of data storage. Joe Average is likely to use an
app like Access, _esp_ if it's included in an office package.
> file organization ;-) However, I'd certainly prefer to use some really
> expressive programming language for such applications, being sufficiently
> powerful to let database access be an integrated part of the general
> programming language. Lisp would be an excellent vehicle for the purpose,
> getting rid of those ugly database languages embedded in crippled 4GLs,
> which let you access large amounts of data, but make it hard to program
> anything more complicated than a personal diary (imagine such a system
> with nearly 20000 modules in several variants, and you may begin to
> understand why I'm associating horror with such garbage as SQL and its
> relatives ;-).
I fear that SQL is here to stay. There are just too many people using
it, it's too easy to learn and use, and the alternatives aren't well
known. Even _I'm_ not convinced that you need Lisp for anything, as
you put it, more complicated than a personal diary, but you wouldn't
need to convince me - I'd use Lisp anyway, just _because I can_.
Alas, this may be why so many other people use VB. Lisp will need a
hell of an edge over VB/SQL before it'll steal a significant part of
that market. That'll require a hard sell, which appears to be
completely absent from all the Lisp marketing that I've seen. You'd be
selling Lisp to people who don't understand it, who think Lisp is
dead, who may even think that Lisp _should be_ dead, along with COBOL
and Fortran, and other "dead" languages. It'll be hard, very hard.
You'd have a better chance if you just write your database code in
Lisp, anddon't tell anyone until _after_ your apps have undeniably
proved themselves to be superior to the orthodox tools. I'd start by
using SQL from within Lisp, and building superior SQL tools that way.
At least that would make your code more attractive to any supporters
of the orthodox database tools. After that, you could work on a more
natural Lisp style for your tools, and your critics will have less
ammo to use against you.
I'm trying to be positive, but I expect it to be a tough battle.
You'll have to prove that Lisp isn't as crap as COBOL, dispite being
so "old". We know that Lisp is every bit as "modern" as C++ and VB,
but how many non-Lisp people will believe you? They're not the only
ones you'll be fighting, but also the marketing people selling C++,
VB, Access, etc. Their voices will be louder than yours, which is why
I think you'll need some pretty damn impressive code to help amplify
_your_ voice.
Where I work, all the database work is done by another programmer, in
VB and Access. If this is something you're doing, I hope you succeed.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
FWIW, we have a high performance database server that uses a Lisp dialect
as the scripting language. We're not selling it as a tool, though. Instead,
we're using the technology to build data mining applications for verticle
markets. The easiest way to describe it might be to say that it's like SQL
Server, except the stored procedures are in Lisp. This would be incorrect,
however, because the data model refects the Lisp approach, with the ability
to treat code as data, rather than the relational model, where code and
data are strictly segregated.
Marc Wachowitz <··@ipx2.rz.uni-mannheim.de> wrote in article
> [snip]
>
> However, I'd certainly prefer to use some really
> expressive programming language for such applications, being sufficiently
> powerful to let database access be an integrated part of the general
> programming language. Lisp would be an excellent vehicle for the purpose,
> getting rid of those ugly database languages embedded in crippled 4GLs,
> which let you access large amounts of data, but make it hard to program
> anything more complicated than a personal diary (imagine such a system
> with nearly 20000 modules in several variants, and you may begin to
> understand why I'm associating horror with such garbage as SQL and its
> relatives ;-).
>
> -- Marc Wachowitz <··@ipx2.rz.uni-mannheim.de>
>
>I've been pondering this myself for a while now. I watch a colleage
>work with databases using Visual Basic and Excel, and I can't see
>anything that he does that couldn't be done in Lisp, just as well if
>not better. Of course, I don't have any experience with databases, so
>I don't get those jobs, so I can't test this. Instead, I get given the
>jobs that require C++.
The problem is that the language field so so disjoint; languages are
always designed with a theme in mind.
- VB is good because it integrates almost seamlessly with the GUI.
- C is good for low level coding (only everyone's forgotten that!)
- Eiffel is good for programming in the large, as is Ada
- BASIC is easy to learn [bad habits from?]
- LOGO is good at teaching people to think
- Machine code is good for precise processor control
- Functional languages are generally designed to exploit functional
programming paradigms, rather than any of the above 3.
- LISP and derivatives are good for experimental stuff... that sounds
a bit insulting; let it be said that it's easy to implement new
paradigms in LISPs. That's great for research, but it's great for
other things as well. Let's not start a flamewar :-)
Now, out of those, I prefer LISP - because it's theme is to accomodate
themes. Yet this is also a downside; few of the "standards" are really
broad in scope - they specialise instead. Scheme is designed with
similar goals to functional languages, as far as I can see (not having
spoken to the designers myself!); I get the impression CL is more for
programming in the large.
So what would be really cool (IMHO) is an enhanced Scheme library
(forget minimalism, this is the marketplace ;-) or revised LISP
standard which is designed with /all/ of the above goals in mind, and
a few more. This will undoubtedly involve tradeoffs - but I'd rather
have a language that's fairly good in many respects than only
marvelous in one or two, since most non-trivial applications contain
several different types of code!
ABW
--
"Plug and Play support: WfEWAD will autodetect any installed
Nuclear Arsenals, Laser Satellites, Battlefield Control Networks,
Radar Installations, Fighter Squadrons, and other WfEWAD compliant
devices, including the new Macrosoft Unnatural Keyboard, with
full support for the now-famous Big Red Buttom(tm)."
(Windows for Early Warning and Defence User's manual P26)
Alaric B. Williams Internet : ······@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>
From: Thant Tessman
Subject: Re: Why lisp failed in the marketplace
Date:
Message-ID: <332DB361.41C6@acm.org>
Alaric B. Williams wrote:
> [...] So what would be really cool (IMHO) is an enhanced
> Scheme library (forget minimalism, this is the marketplace ;-)
> or revised LISP standard which is designed with /all/ of the
> above goals in mind, and a few more. [...]
It's called "Dylan".
-thant
--
"Behold, my brother Esau is a hairy man, but I am a smooth man." Genesis
27:11
With a mighty <················@news.demon.co.uk>,
······@abwillms.demon.co.uk uttered these wise words...
> - VB is good because it integrates almost seamlessly with the GUI.
This goes way beyond mere GUI features. OLE automation could be very
tasty, tho I've yet to use it myself. I've mainly seen other people
using it. Nite that Perl5 for Win32 supports it.
> - C is good for low level coding (only everyone's forgotten that!)
Yeah, we don't all write device drivers.
> - Functional languages are generally designed to exploit functional
> programming paradigms, rather than any of the above 3.
I got into FP via Lisp. I like it a lot, but I keep forgetting bits of
ML, Haskell, or whatever. I have the same problem with C++.
Meanwhile, I have no trouble with Lisp. At worst, I can check a
reference, and I'm off again, at full speed. With FP languages, I've
seen too little example code, read too few tutorials, and just not had
the time to digest it all.
If I could commit to a single language, like SML, then I'm sure this
problem could disappear. After all, it worked with Lisp!
Please note that I'm speaking mainly as a Windows developer. The Unix
market may be completely different, for all I know. I'm not even a
typical Windows developer, as I prefer Lisp to C++/VB/Delphi. So,
everything in this post should have a very big IMHO attached to it. A
more typical (clueless?) developer might just look at you blankly and
wonder what planet we're all living on.
> - LISP and derivatives are good for experimental stuff... that sounds
> a bit insulting; let it be said that it's easy to implement new
> paradigms in LISPs. That's great for research, but it's great for
> other things as well. Let's not start a flamewar :-)
Rapid development. This is another area where VB scores very high.
Lisp can beat VB on the bigger, more complex, jobs. Lisp also scores
higher on general tool building, but VB fights back with masses of
cheap specialist tools, i.e. networking or graphing.
If we wrote a couple of hundred similar tools for Lisp, then...who
knows? At least a few Lisp programmers might be able to compete with
the hords of VB users.
> Now, out of those, I prefer LISP - because it's theme is to accomodate
> themes. Yet this is also a downside; few of the "standards" are really
> broad in scope - they specialise instead. Scheme is designed with
> similar goals to functional languages, as far as I can see (not having
> spoken to the designers myself!); I get the impression CL is more for
> programming in the large.
Yep, very large. CL suffers when the app is small and simple. That's
where VB (or TCL/Tk) is more likely to win. Of course, you might just
use Lisp _because you can_, and ignore everyone who thinks you're mad!
The fact that you _can_ is what should really count. It's just
unfortunate that there are (marketing?) people who will disagree. This
is why I'm looking for a Lisp that can do all the things that VB/VC++
can do, in terms of supporting OCX/OLE etc, and at a price that's
competitive with VC++, which is what I'm _supposed_ to use.
Then, when a new vesion of VC++ is needed, I can say, "Don't bother
with that, just give me a copy of <X> and I can do far more." What
will <X> be? Hmm. It could be DylanWorks, but it certainly won't be
LispWorks or ACL/PC. They either cost too much, or do too little.
Plus, MS expect us to use VC++/VB, which will be enough to force some
people to use the MS development tools. I'm lucky that I can choose my
tools, so long as they do the job, and I pay for them myself...
> So what would be really cool (IMHO) is an enhanced Scheme library
> (forget minimalism, this is the marketplace ;-) or revised LISP
> standard which is designed with /all/ of the above goals in mind, and
> a few more. This will undoubtedly involve tradeoffs - but I'd rather
> have a language that's fairly good in many respects than only
> marvelous in one or two, since most non-trivial applications contain
> several different types of code!
That's what I've been saying for some time: Compete! By "compete", I
mean deliver code in _exactly_ the same way, in .OBJ files (or .o
files, if you're using Unix) or .EXE/.DLL files, support features like
OCX/OLE, resource files, native OS multi-threading, etc. This may mean
making compromises, but that's what the C++ people do all the time,
and if it's hurting them, then very few people have noticed.
If Harlequin can do this (or most of it) with DylanWorks, then that's
what I'll buy. While I'd love to buy ACL/PC (probably the "Standard"
version, as I can just about afford that), I'd prefer to wait and see
what DylanWorks looks like, and how much it'll cost. The LispWorks and
MLWorks prices suggest that DylanWorks will be reasonablely priced,
but we'll see.
Remember friends, I'm not suggesting changes to existing Lisp
dialects. Dylan is a (relatively) _new_ dialect of Lisp. If you
prefer to continue using traditional CL or Scheme systems, I won't
want to stop you. I'm simply looking for something closer to Lisp than
Java, while satisfying the same (non-Internet) market. Dylan is a hell
of a lot closer to what I'm looking for.
On the other hand, if a vendor can produce a Lisp system that competes
_directly_ with VC++, then I'll be very interested!
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
On Tue, 18 Mar 1997 09:39:38 -0000,
············@nospam.wildcard.demon.co.uk (Cyber Surfer) wrote:
>With a mighty <················@news.demon.co.uk>,
>······@abwillms.demon.co.uk uttered these wise words...
Wise? Cool!
>> - VB is good because it integrates almost seamlessly with the GUI.
>
>This goes way beyond mere GUI features. OLE automation could be very
>tasty, tho I've yet to use it myself. I've mainly seen other people
>using it. Nite that Perl5 for Win32 supports it.
I've never seen the OLE automation interface, but isn't it more of a
library thing (with syntactic language extensions) than a core thing?
I mean, the GUI is pretty fundamental in VB, but the data access is
kinda tacked on.
>> - C is good for low level coding (only everyone's forgotten that!)
>Yeah, we don't all write device drivers.
Instead, we write word processors in the /style/ of device drivers :-)
>I got into FP via Lisp. I like it a lot, but I keep forgetting bits of
>ML, Haskell, or whatever. I have the same problem with C++.
Me Too!
>> - LISP and derivatives are good for experimental stuff... that sounds
>> a bit insulting; let it be said that it's easy to implement new
>> paradigms in LISPs. That's great for research, but it's great for
>> other things as well. Let's not start a flamewar :-)
Let me also word it thus: Once research yields a useful new
programming tool, we don't need to ditch the language to use it!
>Rapid development. This is another area where VB scores very high.
>Lisp can beat VB on the bigger, more complex, jobs. Lisp also scores
>higher on general tool building, but VB fights back with masses of
>cheap specialist tools, i.e. networking or graphing.
Sounds similar to the reasons PCs beat Macs to the market share!
"Why Macs failed in the marketplace"...
>If we wrote a couple of hundred similar tools for Lisp, then...who
>knows? At least a few Lisp programmers might be able to compete with
>the hords of VB users.
A Lisp->VB compiler with a foreign function interface... and the
execution speed of a wounded snail dragging a naval destroyer...
OR
A VBX/OCX interface for a Windows LISP? I guess they already support
DLLs...
>> I get the impression CL is more for
>> programming in the large.
>Yep, very large. CL suffers when the app is small and simple. That's
>where VB (or TCL/Tk) is more likely to win. Of course, you might just
>use Lisp _because you can_, and ignore everyone who thinks you're mad!
That's the spirit :-)
>The fact that you _can_ is what should really count. It's just
>unfortunate that there are (marketing?) people who will disagree. This
>is why I'm looking for a Lisp that can do all the things that VB/VC++
>can do, in terms of supporting OCX/OLE etc, and at a price that's
>competitive with VC++, which is what I'm _supposed_ to use.
In the long term, I expect that this kind of goal can be reached by
compiling to a common calling convention or something. An advanced
object file format could define functional definitions, procedural
call hooks to procedures that evaluate these definitions, logical
statements about these definitions, etc. Thus logical, procedural, and
functional code could be compiled to this format and linked (somehow)
into a procedural binary. Since the paradigms are seamless, and
invisible after compilation, the management have on reason to restrict
one's tool usage other than that somebody else may have to read the
code someday; but in such an environment, us wierdo-language
programmers will be out of the closet, so that isn't such a problem...
>Remember friends, I'm not suggesting changes to existing Lisp
>dialects. Dylan is a (relatively) _new_ dialect of Lisp. If you
>prefer to continue using traditional CL or Scheme systems, I won't
>want to stop you. I'm simply looking for something closer to Lisp than
>Java, while satisfying the same (non-Internet) market. Dylan is a hell
>of a lot closer to what I'm looking for.
Hmmm, I've heard nothing but praise of Dylan. Time to take a peek
IMHO...
ABW
--
"Plug and Play support: WfEWAD will autodetect any installed
Nuclear Arsenals, Laser Satellites, Battlefield Control Networks,
Radar Installations, Fighter Squadrons, and other WfEWAD compliant
devices, including the new Macrosoft Unnatural Keyboard, with
full support for the now-famous Big Red Buttom(tm)."
(Windows for Early Warning and Defence User's manual P26)
Alaric B. Williams Internet : ······@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>
With a mighty <···············@news.demon.co.uk>,
······@abwillms.demon.co.uk uttered these wise words...
> >With a mighty <················@news.demon.co.uk>,
> >······@abwillms.demon.co.uk uttered these wise words...
>
> Wise? Cool!
It's an in-joke. See uk.media.radio.radcliffe for enlightenment.
> I've never seen the OLE automation interface, but isn't it more of a
> library thing (with syntactic language extensions) than a core thing?
> I mean, the GUI is pretty fundamental in VB, but the data access is
> kinda tacked on.
OLE is one of those OO "smart document" type things, only it's done
using C++ and (IMHO) very badly. Well, that's MS for you.
> >> - C is good for low level coding (only everyone's forgotten that!)
> >Yeah, we don't all write device drivers.
>
> Instead, we write word processors in the /style/ of device drivers :-)
Ouch. That's way too close to the truth. ;)
> A Lisp->VB compiler with a foreign function interface... and the
> execution speed of a wounded snail dragging a naval destroyer...
A Lisp that could work as an ActiveX script engine might be more
interesting. Some people are already doing this. I'm hoping that my
favourite editor will soon support ActiveX scripting, so that I can
extend it in Scheme.
> OR
>
> A VBX/OCX interface for a Windows LISP? I guess they already support
> DLLs...
Forget VBX, that's 16bit only. Lisp in an OCX? Has that been done yet?
I remember Conscious Computing asking for beta testers, but I've heard
nothing since then.
> In the long term, I expect that this kind of goal can be reached by
> compiling to a common calling convention or something. An advanced
> object file format could define functional definitions, procedural
> call hooks to procedures that evaluate these definitions, logical
> statements about these definitions, etc. Thus logical, procedural, and
> functional code could be compiled to this format and linked (somehow)
> into a procedural binary. Since the paradigms are seamless, and
> invisible after compilation, the management have on reason to restrict
> one's tool usage other than that somebody else may have to read the
> code someday; but in such an environment, us wierdo-language
> programmers will be out of the closet, so that isn't such a problem...
Umm, Dylan? ;) Perhaps it's time to rethink the whole object code
format thing, but I doubt that the C++ people will be ready for it. On
the other hand, some of the Java people might be interested. I sense
some material for a major flamewar, lasting years. Let's hope that
when something like this does happen, something constructive comes out
of it. We could all use it, I think.
> Hmmm, I've heard nothing but praise of Dylan. Time to take a peek
> IMHO...
Check the comp.lang.dylan newsgroup, where Harlequin have just posted
a statement. As expected, the release date for DylanWorks is later
this year. It sounds pretty damn impressive!
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
On Thu, 20 Mar 1997 07:12:40 -0000,
············@nospam.wildcard.demon.co.uk (Cyber Surfer) wrote:
>> >> - C is good for low level coding (only everyone's forgotten that!)
>> >Yeah, we don't all write device drivers.
>>
>> Instead, we write word processors in the /style/ of device drivers :-)
>
>Ouch. That's way too close to the truth. ;)
I thought it sounded kinda sagely.
>> A VBX/OCX interface for a Windows LISP? I guess they already support
>> DLLs...
>Forget VBX, that's 16bit only.
Backwards compatability, there's probably still VBXs out there to be
used.
> Lisp in an OCX? Has that been done yet?
>I remember Conscious Computing asking for beta testers, but I've heard
>nothing since then.
I doubt it'd be /too/ hard, but I'm not really a Windows guru.
>> In the long term, I expect that this kind of goal can be reached by
>> compiling to a common calling convention or something.
[...]
>> but in such an environment, us wierdo-language
>> programmers will be out of the closet, so that isn't such a problem...
>Umm, Dylan? ;) Perhaps it's time to rethink the whole object code
>format thing, but I doubt that the C++ people will be ready for it. On
>the other hand, some of the Java people might be interested. I sense
>some material for a major flamewar, lasting years. Let's hope that
>when something like this does happen, something constructive comes out
>of it. We could all use it, I think.
Uhuh :-/
>> Hmmm, I've heard nothing but praise of Dylan. Time to take a peek
>> IMHO...
>
>Check the comp.lang.dylan newsgroup, where Harlequin have just posted
>a statement. As expected, the release date for DylanWorks is later
>this year. It sounds pretty damn impressive!
Brilliant, thanx!
ABW
--
"Plug and Play support: WfEWAD will autodetect any installed
Nuclear Arsenals, Laser Satellites, Battlefield Control Networks,
Radar Installations, Fighter Squadrons, and other WfEWAD compliant
devices, including the new Macrosoft Unnatural Keyboard, with
full support for the now-famous Big Red Buttom(tm)."
(Windows for Early Warning and Defence User's manual P26)
Alaric B. Williams Internet : ······@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>
I note that Lucent's Inferno system is programmed in a language called Limbo.
Now Limbo is a combination of
- C syntax
- with just a dash of Pascal
- Occam-like channels
- Algol-68-ish types and type checking
- and Lisp.
For any type T, "list of T" is a type with operations like cons (spelled ::),
hd, tl, length.
Ok, so Limbo has compile-time strong typing (well, fairly firm, it's
structure equivalence rather than name equivalence, in order to handle
run-time loading issues). Apart from that, the main thing that it is
lacking is
closures.
Java is also missing closures, and Javascript, which uses run-time type
checking, is also missing closures. I think the reason for this is that
they've all started from C and worked up rather than starting from Lisp
and working down, and genuinely don't understand how crippled a language
without decent closures looks. (The old arguments against nested
functions in C have no validity in Limbo.)
Limbo is very carefully restricted so that plain old reference counting
works as a garbage collection method, and they even _promise_ immediate
reclamation when the last reference goes out of scope.
But basically, Limbo is astonishingly like what you'd get if a crazed
C programmer read a couple of books about CSP and Lisp implementation,
understood _some_ of what he was missing, and went for it.
Time will tell, but with *all* the mobile computing languages I know
(Java, Javascript, Limbo, Oberon) incorporating ideas from Lisp, I
don't think Lisp has failed in the marketplace of _ideas_.
--
Will maintain COBOL for money.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
In article <············@goanna.cs.rmit.edu.au>, ··@goanna.cs.rmit.edu.au
(Richard A. O'Keefe) wrote:
> I note that Lucent's Inferno system is programmed in a language called Limbo.
> But basically, Limbo is astonishingly like what you'd get if a crazed
> C programmer read a couple of books about CSP and Lisp implementation,
> understood _some_ of what he was missing, and went for it.
For some reason, Lucent has done something like 'watermarking' to their
pdf documentation that you download. This 'watermarking' has several
effects:
* it blows the pdf files up by a factor of >10X
* it slows down your download times by a similar factor
* it slows down your print times by a similar factor
* it looks ugly as heck when you print it
A few complaints to Lucent about this paranoia should be in order.
Does Lucent seriously believe that someone will try to 'hack' the Inferno
documentation?
My guess is that the irritation that this stuff causes people when they
try to find out about the language will turn them off before they even
get far enough to read the documentation.
To give you a flavor of what I am talking about, a 12-page document may
take 3 Mbytes of pdf, with _no_ pictures!
In article <··········@agate.berkeley.edu>, ··@anarres.CS.Berkeley.EDU
(Brian Harvey) wrote:
> But there is no iron law of consequences; otherwise Microsoft
> (again) would have died when they adamantly insisted for some time
> that the Internet was irrelevant. They overcame that wrong decision
> through the inertia of power.
It is funny how it is possible to draw opposite conclusions from the same
sequence of events. I see this as an example of how Microsoft has made
_good_ decisions.
My take is that Microsoft showed great flexability in being able to both
recognize their mistake and change course very quickly once the did.
Certainly they did so in much less time than it took for IBM to realize
that PC's weren't irrelevant (and with much less negative impact on the
bottom line, so far).
> Again, I'm not arguing that Symbolics did everything right, or that
> other choices couldn't have been more successful -- but my guess is
> that different decisions wouldn't have had *much* effect.
Certainly spending less developing specialized (okay, I'll stop writing
"proprietary") hardware would have had a big positive effect on their
bottom line. As Symbolics (along with the rest of the Lisp industry)
spiraled down into the financial toilet, they took many years of work by
many very smart people with them.
--
Jeffrey B. Siegal
Quiotix Corporation
+1 415 782-6012
http://www.quiotix.com
With a mighty <················@naggum.no>,
····@naggum.no wibbled into the void...
> I think, fundamentally, human beings differ a great deal in very many
> respects. some find infix natural. others find that infix is not so
> natural as to be worth their cost (such as very complex syntaxes). these
> may not be the majority, but there are enough of them to keep Hewlett-
> Packard's calculator division alive and well.
Yep, I've met many people who find postfix more natural than infix,
and yes, at least a few of them used HP calculators. While my first
language was Basic, I quickly turned to Forth and found it much
easier, partly because of the use of RPN. I've never been comfortable
with infix. I was playing with the idea of something like Lisp's
prefix notation just before discovering Forth, so if I'd had the
chance to discuss this with a more knowledgable programmer, then I
might have moved from Basic to Lisp, instead of Basic->Forth->APL->
Fortran->assembly->Pascal->C->Lisp. I've probably forgotten a few
languages, but that's most of them.
My real problem wasn't so much infix, as precedence. I coped with C by
using a lot of parentheses. Curiously, after using a Lisp-ware editor
(in ACL/PC), I miss the support for matching parentheses when I edit C
code in a "dumb" editor. I've yet to find this feature in an editor
for a C++ IDE, dispite the desparate need for all kinds of matching.
> I always wondered how large companies came to be. thank you for this lead.
> I did some research on Darwin's theories of natural selection, and here's
> what I found: millions of years ago, much smaller companies than today gave
> birth to many small companies, some of them mutants that were better fit
> for survival in the intensely competitive underbrush of the ancient world.
> the natural selection favored companies that could breed early and mutate
> faster, but some species of companies had found a stable breeding cycle and
> grew to very large sizes and lived for a very long time. these were the
> elephantine companies. to this day, Wall Street, their secret breeding
> ground, will honor their age-old breeding rituals that have completely lost
> their meaning in the modern world, but they were probably beneficial to the
> early elephantines. contrary to popular belief, Darwinian selection is not
> just an historic process -- the smaller company species still mutate and
> develop in new directions, but even though they do so much faster than the
> elephantines, it is difficult to spot it when it happens. if you watch a
> company carefully, you might be so lucky to find that it eats more pizza
> and take-out food right before it spawns a new company.
I'm not even sure that natural selection applies here. If the
operation of a company required no choice by a human, then Darwinian
selection might take place. Alas, humans like to interfere with these
things, often believing that they understand how something works, and
deciding that _this_ must be done, while _that_ must not.
As you might guess, my favourite dog "breeds" are the ones that
breeders have had little chance to abuse, i.e. not breeds at all, but
dogs that are as close as possible to a wolf, and yet still be
relatively "domesticated". I do not appreciate long floppy ears, or
some of the other dog fashions that I'm told can actually be very
unhealthy for the dog.
In other words, I like healthy wolf-like dogs, rather than fashion
accessories. Of course, this is just my personal feeling, and it's
probably all wrong. Most dog owners appear to be unconcerned about
such things, judging by their choice of breed.
My feelings about programming languages are not that different.
Precedence strikes me as being an artificial idea bolted onto
programming languages in order to assist scientists write software.
This is a fair use, but not all modern software is for crunching
numbers. It would be neat if some languages could reflect the non-
numerical interests of the programmers who use them.
> much research has gone into the Darwinian selective process as it applies
> to companies. of popular interest are Sir Richard Attenborough's excellent
> TV series (on PBS) that documents the slow, but steady migration and growth
> of companies. Dr. Richard Dawkins has written several books, including The
> Blind Stockbroker and The Selfish Meme that both argue strongly for natural
> selection and against creationism that says that companies were created out
> of nothing by a higher intelligence. however, there are also critics of
> Darwin's work on The Origin of the Companies. Erich von Danicken contends
> that today's companies are the result of protocompanies planted on earth by
> the split-infinitive voyages of Star Trek, The Previous Generation.
<giggle>
> now, they don't teach these things in high schools, do they? this goes to
> show something, I'm sure.
Perhaps the result of people who think they "know" better interfering
in the educational process? Hold on to that copy of The Blind
Stockbroker, as it may be valuable when the Real Programmers have
burned most of them. I'm keeping mine in a fireproof vault...
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
On Sat, 15 Feb 1997 19:20:15 -0000, ············@wildcard.demon.co.uk
(Cyber Surfer) wrote:
>My real problem wasn't so much infix, as precedence. I coped with C by
>using a lot of parentheses. Curiously, after using a Lisp-ware editor
>(in ACL/PC), I miss the support for matching parentheses when I edit C
>code in a "dumb" editor. I've yet to find this feature in an editor
>for a C++ IDE, dispite the desparate need for all kinds of matching.
If you've a PC, try the free DJGPP compiler and the RHIDE IDE. Based
on Borland's IDE, with syntax highlighting and three kinds of brace
mathcing - (), {}, []!
ABW
ABW
--
"Simply drag your mother in law's cellphone number from the
Address Book to the Laser Satellite icon, and the Targeting
Wizard will locate her. Then follow the onscreen prompts for
gigawattage and dispersion pattern..."
(Windows for Early Warning and Defence User's manual P385)
Alaric B. Williams Internet : ······@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>
With a mighty <···············@news.demon.co.uk>,
······@abwillms.demon.co.uk wibbled into the void...
> If you've a PC, try the free DJGPP compiler and the RHIDE IDE. Based
> on Borland's IDE, with syntax highlighting and three kinds of brace
> mathcing - (), {}, []!
Thanks, but right now all my C++ development is done in MS Developer
Studio and VC++. Perhaps if RHIDE can read the same docs as Developer
Studio, it might be more interesting, but I can't change the compiler.
Eventually, I'll get around to reinstalling GNU C/C++. I've only just
upgraded NT, and there's a whole list of software to reinstall.
Anyway, thanks. I'll take a look at RHIDE when I can.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
In article <·············@acm.org>, ······@acm.org wrote:
> I think fundamentally, Lisp syntax is not natural for human being. It
> is elegant for computer or software to process, but not for real
> people. From grade school, you are taught 10 = 8 + 2, not 10 = (+ 8
> 2).
There's nothing wrong with 2+2, but when you get 13 different operators
and 15 different preference levels, most people's (except those of the dorks on
standards committees) eyes glaze over. If you also have _functional arguments_,
then infix notation completely breaks down. Parentheses, when accompanied
by an editor that understands pretty-printing, are extremely easy to parse,
both by machine and by eye.
> From high school, you learn how to prove mathematical theorems procedually.
I'm sorry, but most mathematics is recursive. I'm afraid you've been taught
math by someone whose brain has been fried by Basic and/or Fortran.
> Basically, a procedural language is more "natural" than a symbolic one.
> When I taught Scheme in school, it takes a good 2 weeks just to get the
> recursive part into their heads.
I've taught students both from 'iterative' and 'recursive' languages. Believe
me, recursive is better. Except for 10% who had already fried their brains
on microcomputer Basics, most students found recursive to be easier.
> If it is less natural, it is less productive, statistically speaking.
> Companies lose using a less productive tool. It is a Darwinian
> selective process.
It's more of an _inverse_ Darwinian process. The most productive programmers
die out, because managers and companies can't establish fiefdoms and empires
with only 1 or 2 programmers.
Lisp would kill Microsoft, because then what would people need upgrades
and software support for?
Henry Baker (······@netcom.com) wrote:
: In article <·············@acm.org>, ······@acm.org wrote:
: > I think fundamentally, Lisp syntax is not natural for human being. It
: > is elegant for computer or software to process, but not for real
: > people. From grade school, you are taught 10 = 8 + 2, not 10 = (+ 8
: > 2).
: There's nothing wrong with 2+2, but when you get 13 different operators
: and 15 different preference levels, most people's (except those of the dorks on
: standards committees) eyes glaze over. If you also have _functional arguments_,
: then infix notation completely breaks down. Parentheses, when accompanied
: by an editor that understands pretty-printing, are extremely easy to parse,
: both by machine and by eye.
: > From high school, you learn how to prove mathematical theorems procedually.
: I'm sorry, but most mathematics is recursive. I'm afraid you've been taught
: math by someone whose brain has been fried by Basic and/or Fortran.
: > Basically, a procedural language is more "natural" than a symbolic one.
: > When I taught Scheme in school, it takes a good 2 weeks just to get the
: > recursive part into their heads.
: I've taught students both from 'iterative' and 'recursive' languages. Believe
: me, recursive is better. Except for 10% who had already fried their brains
: on microcomputer Basics, most students found recursive to be easier.
: > If it is less natural, it is less productive, statistically speaking.
: > Companies lose using a less productive tool. It is a Darwinian
: > selective process.
: It's more of an _inverse_ Darwinian process. The most productive programmers
: die out, because managers and companies can't establish fiefdoms and empires
: with only 1 or 2 programmers.
: Lisp would kill Microsoft, because then what would people need upgrades
: and software support for?
On Thu, 20 Feb 1997, Patrick Giagnocavo wrote:
> Will Hartung wrote:
> <and so did many many other people>
>
> I now know why Lisp failed in the marketplace:
>
> All these really good programmers sat around arguing over infix
> notation, parens, metaobject protocols, deep and shallow binding etc.
It's only a hobby :) (at least these discussions would seem so :)
> While the other programmers working in C and C++ actually designed
> toolkits and stuff that actually -worked-, sorta.
I wish <g>
> I posted recently asking questions about a Lisp <--> X Windows
> interface. One response, showing one other person was interested enough
> to reply. No-one else apparently was interested enough or was using it.
I don't know.
Okay, open challenge from me:
--- How ABOUT some kind of GUI interface standard for Lisp. ---
- Shouldn't be Motif/Windows dependant
[or any calls that are - SHOULD BE DOCUMENTED, so developers without
either can still build support (like me)]
- Has to be farely portable (say - incorporating Java's GUI might be
a solution :)
- Hardware dependancy is irrelevent. (X is sorta good for this)
- 3D would probably be a good idea (my game - no worries - but consider
OpenGL [which HAS public documentation])
- complexity is a nonproblem. That's what macros are for <big grin>.
- making it an extension package is probably the best interface way.
[say - isn't XIT/CLUE/whatever any good? I can't run them]
- has to be extensible. Otherwise it isn't Lisp.
- No silly limits (like 32K lists [hi Bill Gates])
Any takers? (If not, I'll do it myself :)
> CMU CL has recently been ported to the Linux and FreeBSD platforms.
> This means that now a lot of the real tricky stuff concerning x86
> assembler output has been solved.
Doesn't seem threading is covered..... (my pet peeve... and it would
affect WinNT too.... but not Win95 or any of its other cousins)
[I don't have any Win32 OS's, so I can't answer your challenge - sorry]
> Put up or shut up time! Are you going to flap your jaws, or roll up
> your sleeves and actually do something?
I want to do something. This a good way to start? (or is it just more
useless noise).
Perhaps I should come up with a GUI standard of my own, then post it...
hmm.... [I need one - text-based interfaces are almost useless to me]
Ciao, all!
- Teunis
From: Martin Cracauer
Subject: CMUCL on Win32 (Re: Why lisp failed in the marketplace (real reason))
Date:
Message-ID: <1997Feb20.112543.2462@wavehh.hanse.de>
Patrick Giagnocavo <·····@earthlink.net> writes:
>OK wise guys, here is a challenge for you:
>CMU CL has recently been ported to the Linux and FreeBSD platforms.
>This means that now a lot of the real tricky stuff concerning x86
>assembler output has been solved.
>Which one of you blathering Lisp weenies (not to name any names mind
>you) has the guts to try compiling this under the Cygnus/GNU toolkit
>that implements a lot of posix functionality under Win32? A bunch of you
>have stated that you are doing things under Windows anyways, right?
I already tried this.
The latest Beta versions of GNU-Win32 miss functionality to access the
saved state of CPU registers in a signal handler (that is: the state
the registers had before the signal was received). We need this for
the garbage collector.
I'm not going to meet the GNU-Win32 community to discuss this issue at
length for a platform I don't use.
But maybe you can offer some help in that you hunt down a solution for
this and send the result to ·········@cons.org?
>Such a programming environment would be free for any purpose; but the
>license for CMUCL if I remember correctly is more of a BSD style
>license, making it easier to use in commercial/proprietary code. Gui
>code would have to wait until later of course, but at least it would be
>a start; interface to TCPIP and you could run on NT and display the X
>windows part of the gui on any X box.
"Any X box" could be a Windows Box also. There are very usable X11
servers for Windows and the client libraries run anyway. I expect a
free X11 server for Windows in short (didn't the Xfree folks already
release such a beast for OS/2?).
>The non-gui code would obviously be source code compatible across all
>supported CMU CL platforms; you know, SPARC, UltraSPARC, SGI's, Linux,
>FreeBSD, (Alpha?), PA-RISC, PowerPC/AIX.
>Put up or shut up time! Are you going to flap your jaws, or roll up
>your sleeves and actually do something?
Some question back, Patrick :-)
If you contribute knowledge (or work to get knowledge) about
GNU-Win32, I will contribute CMUCL rebuild experience.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
···············@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
From: Alaric B. Williams
Subject: Re: Why lisp failed in the marketplace (real reason)
Date:
Message-ID: <330ca7de.1119950@news.demon.co.uk>
On Thu, 20 Feb 1997 00:43:26 -0700, Patrick Giagnocavo
<·····@earthlink.net> wrote:
>Put up or shut up time! Are you going to flap your jaws, or roll up
>your sleeves and actually do something?
Hip hip, hooray! At last!
My goal in life is to develop an OS, and something LISPy is central to
that. It'll take me a while, as in a few years, but it should be worth
it.
Anyone else doing anything interesting and new?
ABW
--
"Simply drag your mother in law's cellphone number from the
Address Book to the Laser Satellite icon, and the Targeting
Wizard will locate her. Then follow the onscreen prompts for
gigawattage and dispersion pattern..."
(Windows for Early Warning and Defence User's manual P385)
Alaric B. Williams Internet : ······@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>
Sin-Yaw Wang <······@acm.com> writes:
>Why do we argue if this syntax is natural or not? This is silly. Go
>find a good sample of software engineers and ask them, "Is Lisp syntax
>and recursive thinking natural to you?"
Result may be different depending on what you find: "a good sample of
software engineers" or "a sample of good software engineers". Go figure.
From: William Clodius
Subject: Re: Why lisp failed in the marketplace
Date:
Message-ID: <330DBFA6.58E@lanl.gov>
Richard A. O'Keefe wrote:
>
> <snip> a language which is harder to write in
> the first place may be more productive in the long run because it makes
> future re-use easier. <snip>
This phrase is awfully close in semantics to "a language which is harder
to write in the first place may be more productive in the long run
because it encourages future re-use"
Fortran IV anyone? It probably did have more reuse than any other
language, at least partly because of its writability problems.
--
William B. Clodius Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815
PO Box 1663, MS-C323 Group office: (505)-667-5776
Los Alamos, NM 87545 Email: ········@lanl.gov
>I wrote
>> a language which is harder to write in
>> the first place may be more productive in the long run because it makes
>> future re-use easier. <snip>
William Clodius <········@lanl.gov> writes:
>This phrase is awfully close in semantics to "a language which is harder
>to write in the first place may be more productive in the long run
>because it encourages future re-use"
>Fortran IV anyone? It probably did have more reuse than any other
>language, at least partly because of its writability problems.
Actually, it is rather _remote_ in semantics. "making re-use easier"
(in the sense of "making it possible to re-use almost without effort")
is very different from "encouraging re-use" (in the sense of "having
something _worth_ reusing").
In strict point of fact, Fortran IV code tended to be rather hard to
re-use. Fortran 77 was better, and Fortran 90 looks like being better
still.
The point I had in mind was that for code to be re-usable, it needs to
adapt to the re-use context without source code changes. As an example,
Fortran code tended to be hard to port because what could be REAL on
one machine had to be DOUBLE PRECISION on another. This was so much the
case that people wrote special tools to do the conversion, and adopted
special commenting conventions to guide the tools. (I have seen the
sources of a number of statistics packages.) Fortran 90 has fixed this:
you say
INTEGER FPK
PARAMETER (FPK = SELECTED_REAL_KIND(...what you need...))
REAL(KIND=FPK) X = 1.0_FPK
and the compiler will select the right type for you. Another problem
was fixed array sizes. Again, Fortran 90 fixes that. But C and C++ still
have compile-time fixed array sizes, while Lisp has run-time array sizes.
Then there are the "Fortran" libraries (like the Harwell library used to
be) that "require some assembly". Trying to get some of the Harwell
codes running on a B6700 was a real nightmare.
There is no question that there is a great deal of Fortran code of value
that well *repays* re-use. But being *worth* re-using and being *easy*
to re-use are very different things.
--
limits on the scope of cooperation are often due to the inability
to recognise the identity or the acts of the other playes. --R.Axelrod
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
Richard A. O'Keefe wrote:
> To end on an educational point: anyone who thinks that recursion is
> specially hard (compared with other CS concepts like, ok, lexical scoping)
> and that Lisp and Scheme are no good is the worst possible person to
> teach Scheme. Worse even than someone who doesn't even know Scheme.
I am not sure about this one. I like teachers who think the concept is
hard. They tend to explain it better than those who think it is easy. I
guess I was not a brignt student. Genius professors frequently do not
teach well.
My students came back to me, long after they have graduated, to tell me
that I taught well. Now, this one I have envidence to prove it.
--
Sin-Yaw Wang, ······@acm.org
http://www.concentric.net/~sinyaw/
Sin-Yaw Wang wrote:
>
> Richard A. O'Keefe wrote:
> > To end on an educational point: anyone who thinks that recursion is
> > specially hard (compared with other CS concepts like, ok, lexical scoping)
> > and that Lisp and Scheme are no good is the worst possible person to
> > teach Scheme. Worse even than someone who doesn't even know Scheme.
>
> I am not sure about this one. I like teachers who think the concept is
> hard. They tend to explain it better than those who think it is easy. I
> guess I was not a brignt student. Genius professors frequently do not
> teach well.
The problem with "genius" professsors is not due to their finding the material
too easy, it is either:
1. they are bored by the material, and would either rather be at
another place in the course or worse, another place entirely
2. they lack an appreciation of the "learning curve" through which
the students must pass
The first puts quality at risk regardless of the task at hand. When I teach I
try to always be "in the moment", and always imagine the current topic as being
the most important/interesting. I try to code the same way. A poorly-designed
component will later prove to be the weak link in your system (either through
performance, reuse, modifiability, etc.). It's just plain easier to do it right
the first time. If I blow off a lecture topic in anticipation of upcoming
material, I waste much more time later answering questions that would not have
been asked had I done the job properly.
In my (albeit limited) experience the second point just isn't an issue if the
instructor understands the material and is enthusiastic about the process of
*teaching*.
--
Paul G. Schaaf, Jr.
Smalltalk Consultant
Versant Object Technology
···········@acm.org
Sin-Yaw Wang <······@acm.org> writes:
>I am not sure about this one. I like teachers who think the concept is
>hard. They tend to explain it better than those who think it is easy.
Clearly you and I come from different planets.
I know a number of bright children who have been put off mathematics
for life because their teachers told them it was hard.
I am _angry_ about that.
Last year I was co-supervisor of a Masters student looking at the question
"how can we tell whether our choice of first-year programming language is
working?" One of the points he made was that the educational literature
is clear that a great many things contribute to learning, and one of the
major ones is the attitude of the teacher.
A teacher who thinks that a concept is hard is one who hasn't understood
it yet. What you want is a teacher who knows that the concept is _easy_,
and who also knows _how to explain it_ to people who don't know it yet.
A teacher who thinks the concept is hard cannot do that, because he doesn't
know the clarifying explanation himself yet.
>I guess I was not a brignt student.
>Genius professors frequently do not teach well.
The only teachers I ever learned anything from were the ones who were
convinced that their subject was enjoyable and wanted to help me enjoy
it too. (_Not_ "enjoy the lectures". Enjoy the _subject_.)
Your statement that "genius professors frequently do not teach well"
is rather beside the point. *Several* things are needed:
- the teacher has to understand the concept,
to the point where the teacher thinks it is easy.
(If you do not think it is easy, you will not believe that
all your students can learn it, and this is a self-fulfilling
prophecy.)
- the teacher has to understand the students.
Different people have different learning styles, and what is
vital for one will be insulting to another. You need to know
what the _difference_ between your knowledge and the students'
knowledge is if you are going to reduce that difference.
- the teacher has to understand teaching in general.
- the teacher has to understand _how to teach this concept_.
Now "genius professors" are typically hired because of their knowledge
of the _subject_, without any reference to teaching skills whatsoever.
I don't qualify as a genius. But I was hired on the basis of my knowledge.
I have *no* "educational" qualifications. The *only* training I've had in
teaching was a one week introductory course I was actually given in my
second year here, and it basically told me enough about the problems to
worry me without actually telling me anything about the solutions.
Just because someone who _does_ understand the subject but has no teaching
skills doesn't teach well, you cannot conclude that someone who knows _less_
about the subject would be better.
>My students came back to me, long after they have graduated, to tell me
>that I taught well. Now, this one I have envidence to prove it.
Well, I've got a stack of evaluation sheets that say the same about me.
You know what this means? It means that the ones my style _doesn't_ suit
drop out.
Frankly, anyone who appeals to "testimonials" like this doesn't understand
the first thing about evidence. It's like the testimonials you see in
magazines for quack medicines. (You know, right between the horoscope and
the psychic.) The people who die from the quack medicine aren't in any
position to write letters. To evaluate one's teaching properly, one needs
to interview the people who drop out or transfer to another class or fail
to show up at the exam or who just don't fill out evaluation forms. I did
this last year. Most instructive. You end up wondering if they actually
came to your lectures or went somewhere else by mistake, because they
describe events that never happened, missed things that did, ...
Now if in fact you taught Scheme (as you seemed to say before),
and if in fact you taught _well_, then presumably these students
all like Scheme and understand recursion thoroughly.
--
limits on the scope of cooperation are often due to the inability
to recognise the identity or the acts of the other playes. --R.Axelrod
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
In comp.lang.scheme Richard A. O'Keefe <··@goanna.cs.rmit.edu.au> wrote:
> Proposition 2 is hopelessly vague. Natural compared with what?
> And to whom? What you find natural depends almost entirely on
> what you have previously been taught. There's an interesting
> footnote in Yourdon's "The decline and fall of the American
> programmer". Let me quote from p41.
> Equally important was the discovery that the actual
> performance of the programmers had no significant
> correlation with years of programming experience
> or scores on standard programming aptitude tests.
> ...
> [Footnote 1 In all these studies, little correlation
> has been fouind between performance and years of
> experience in the field. Acutally productivity is
> better correlated with the number of programming
> languages that the person knows.]
It might be interesting to see how good the correlation actually is and
to speculate on the cause. Is this true because the better programmers
learn as many languages as possible or because the people who know lots
of different languages know more different approaches to solutions or
is there some other reason?
I'm just happy I can point to piles of code that I've written in something
like two dozen different languages. (I added two languages to my CV list
last year, I'll add perhaps five this year.)
> Here's the inference:
> - a programmer who knows so few languages that s/he has strong
> feelings about the "naturalness" of a construct is likely to
> be amongst the _least_ productive programmers.
One of the things that has been bothering me about this whole exchange
is the fact that it's more important to have a language which can
most "naturally" express the problem than it is to have a language that
feels natural to the programmer. That will effect the outcome far more
profoundly than whether or not the programmer knows the language well.
> Frankly, I would expect anyone who talks about "engineers" in this
> context to be aware of the many results that show that productivity
> is influenced by many things in addition to programming language,
> and by some of them more strongly.
You may be referring to Dr. Brooks' classic "There is no Silver Bullet"
where he argues persuasively that there is no change in technology that
can produce an order of magnitude improvement in programmer productivity.
That paper leads me to the other thing that bothers me about this
exchange. Some people are promoting the idea that the choice of one
language over another can have orders of magnitude effects on the
productivity of those working on the project. You often see statements,
and not just on these newsgroups, like "When I code in Language
Jellygargle I get things done ten times as fast as I do when I code in
C." (For some reason, C or C++ are always the language being used as
the benchmark.) The thing is, I believe that the choice of higher-level
language is incidental ("accidental" is the word used in Brooks' paper)
to the real difficulties faced by the programmer.
The reason that there really is no "Silver Bullet" is because all of the
incidental difficulties put together don't make up 90% of all the
difficulties with any given project and you can only get an order-of-
magnitude improvement in productivity if the difficulties you eliminate
make up AT LEAST 90% of the difficulties there are.
The only way to do touch the essential difficulties of programming is to
reduce the complexity of programming and the only way to touch that by
changing programming languages is by choosing a language that is more
specific to the problem to be solved. For example, you can be orders of
magnitude more efficient coding database applications in a database
language (like XBase) than you can be when coding them in a
general-purpose programming langauge like LISP or Scheme.
Of course, I once read an article (in BYTE, of all places) that talked
about a style of programming called "fractal" which could be used to
turn some general-purpose programming languages (FORTH, LISP and LISP
variants, among others) into what amounts to special-purpose programming
languages. However, that requires a significant up-front investment
that means that your first project (the one where you're developing the
tools) isn't any more productive than normal.
--
Jonathan Guthrie (········@brokersys.com)
Information Broker Systems +281-895-8101 http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX 77014, USA
We sell Internet access and commercial Web space. We also are general
network consultants in the greater Houston area.
With a mighty <············@news.hal-pc.org>,
········@brokersys.com wibbled into the void...
> The only way to do touch the essential difficulties of programming is to
> reduce the complexity of programming and the only way to touch that by
> changing programming languages is by choosing a language that is more
> specific to the problem to be solved. For example, you can be orders of
> magnitude more efficient coding database applications in a database
> language (like XBase) than you can be when coding them in a
> general-purpose programming langauge like LISP or Scheme.
I remember reading somewhere that the number of error made by
programmers had been found to be proportional to the number of lines
of code. This implies that we should strive to reduce the number of
lines needed to write an app. Languages like XBase are one way of
doing this, but I'm not fond of creating a "new" language, and
throwing away all the tools available for an existing language.
This leads to many of the arguments in favour of using C++, but we can
also justify using Lisp in the same way. I like the idea of building
on existing experiernce and tools. It's just unfortunate that most
people I know turn to C++ and Basic, or worse, custom 4GL languages.
Still, these tools get the job done, which is all that most people
seem to want. It's just not _my_ way, and never has been.
> Of course, I once read an article (in BYTE, of all places) that talked
> about a style of programming called "fractal" which could be used to
> turn some general-purpose programming languages (FORTH, LISP and LISP
> variants, among others) into what amounts to special-purpose programming
> languages. However, that requires a significant up-front investment
> that means that your first project (the one where you're developing the
> tools) isn't any more productive than normal.
Some people call it "meta programming". I don't think that it always
requires a "significant up-front investment", as you put it. Small but
very useful meta languages can be created with great ease in Lisp,
Forth, Prolog, and also many functional languages. I wouldn't expect
anyone writing for Byte (including Dick Pountain) to be good at
explaining this! For a start, magazines have very limited space for
such things, and while Byte is better than most mags, it's nowhere
near as good as a book. SICP is a perfect example of how to teach
these advanced ideas - enough material for 3 programming courses!
I think that the "significant up-front investment" is in _learning_
how to do meta programming, not the cost of actually using it. If
there's resistance to these ideas, and I think that there is, it may
because of associations with negative experiences in the past, but it
could also be the "real programmers don't eat quiche" problem.
We should show people that "eating quiche" is worth more than the
silly macho posturing. In other words, a real (i.e. Lisp) programmer
has nothing to prove, because their code does it for them, by working,
by being delivered on time, etc.
So, why am I not writing database apps in Lisp? It could be because a
VB programmer is already doing all the database work, while I get the
CGI jobs. That's why I'm now considering Amzi Prolog. Meta programming
can help CGI (ISAPI) apps just as easily as client-end database apps.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
In comp.lang.scheme Cyber Surfer <············@wildcard.demon.co.uk> wrote:
> With a mighty <············@news.hal-pc.org>,
> ········@brokersys.com wibbled into the void...
> > The only way to do touch the essential difficulties of programming is to
> > reduce the complexity of programming and the only way to touch that by
> > changing programming languages is by choosing a language that is more
> > specific to the problem to be solved. For example, you can be orders of
> > magnitude more efficient coding database applications in a database
> > language (like XBase) than you can be when coding them in a
> > general-purpose programming langauge like LISP or Scheme.
> I remember reading somewhere that the number of error made by
> programmers had been found to be proportional to the number of lines
> of code. This implies that we should strive to reduce the number of
> lines needed to write an app. Languages like XBase are one way of
> doing this, but I'm not fond of creating a "new" language, and
> throwing away all the tools available for an existing language.
I don't think I made myself clear. (In fact, from your response, I'm
sure of it.) The whole point behind the fractal style of programming
is to EXTEND the base language such that it includes all of the features
of a more specific language. Using the example of databases and Scheme
or LISP, what you wind up with is a Scheme or LISP that knows how to
do databasish stuff.
Although you can do this in a so-called "Object Oriented" language, the
languages in question can do it in a cleaner fashion. That is because
the natural way to extend a language is with function calls and LISP and
its variants are built around function calls and things that look like
them. In C++ (unless you do lots of operator overloading, which has its
own dangers) your "extensions" look different from the base language
whereas in LISP, it looks the same.
You don't lose anything but the time it took to build the library and
make it general enough for reuse.
> > Of course, I once read an article (in BYTE, of all places) that talked
> > about a style of programming called "fractal" which could be used to
> > turn some general-purpose programming languages (FORTH, LISP and LISP
> > variants, among others) into what amounts to special-purpose programming
> > languages. However, that requires a significant up-front investment
> > that means that your first project (the one where you're developing the
> > tools) isn't any more productive than normal.
> Some people call it "meta programming". I don't think that it always
> requires a "significant up-front investment", as you put it. Small but
> very useful meta languages can be created with great ease in Lisp,
> Forth, Prolog, and also many functional languages. I wouldn't expect
> anyone writing for Byte (including Dick Pountain) to be good at
> explaining this!
<SNIPPED>
> I think that the "significant up-front investment" is in _learning_
> how to do meta programming, not the cost of actually using it. If
> there's resistance to these ideas, and I think that there is, it may
> because of associations with negative experiences in the past, but it
> could also be the "real programmers don't eat quiche" problem.
The article in question (which appeared several years ago) was intended
as an introduction to Scheme. As I recall, it was written by two authors,
one of which was a certain Guy Steele (a name you may recognize.) I would
argue that, in terms of database programming at least, a significant
investment in time is going to be necessary because building a working DBMS
worth of the name is a nontrivial exercise. (Of course, you could always
try to find bindings to a currently existing DBMS. That would save a lot
of time. Speaking of which, anybody got any Scheme code to work with
Postgres95?)
I can't think of any examples of producing the library worth doing that
would not involve a significant effort simply to produce the basic
functionality, or are you speaking of time spent beyond that to turn it
from a "program" into an "extension to the language?" In fact, Brooks
estimates that producing a reusable library from a working program
requires three times as much effort as building the program itself. A
lot of that effort is in non-coding areas such as documentation, but
if LISP and its variants reduce the rest of it significantly, that
would be a point in their favor.
Unfortunately, I don't have enough experience in programming in these
languages to know whether the "generalization" effort is reduced or not.
--
Jonathan Guthrie (········@brokersys.com)
Information Broker Systems +281-895-8101 http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX 77014, USA
We sell Internet access and commercial Web space. We also are general
network consultants in the greater Houston area.
With a mighty <············@news.hal-pc.org>,
········@brokersys.com wibbled into the void...
> I don't think I made myself clear. (In fact, from your response, I'm
> sure of it.) The whole point behind the fractal style of programming
> is to EXTEND the base language such that it includes all of the features
> of a more specific language. Using the example of databases and Scheme
> or LISP, what you wind up with is a Scheme or LISP that knows how to
> do databasish stuff.
I don't have my post anymore, but I thought that's what I was saying.
Perhaps I didn't make myself clear, either. ;)
> Although you can do this in a so-called "Object Oriented" language, the
> languages in question can do it in a cleaner fashion. That is because
> the natural way to extend a language is with function calls and LISP and
> its variants are built around function calls and things that look like
> them. In C++ (unless you do lots of operator overloading, which has its
> own dangers) your "extensions" look different from the base language
> whereas in LISP, it looks the same.
This is why I mentioned "meta programming".
> The article in question (which appeared several years ago) was intended
> as an introduction to Scheme. As I recall, it was written by two authors,
> one of which was a certain Guy Steele (a name you may recognize.) I would
> argue that, in terms of database programming at least, a significant
> investment in time is going to be necessary because building a working DBMS
> worth of the name is a nontrivial exercise. (Of course, you could always
> try to find bindings to a currently existing DBMS. That would save a lot
> of time. Speaking of which, anybody got any Scheme code to work with
> Postgres95?)
I'm not interested in building a DBMS, as most of the work has been
done for me. All I have to do is create bindings for the ODBC
functions, then wrap them up in a few higher level macros and
functions. If you don't have something like ODBC, then you may indeed
have more work to do.
> I can't think of any examples of producing the library worth doing that
> would not involve a significant effort simply to produce the basic
> functionality, or are you speaking of time spent beyond that to turn it
> from a "program" into an "extension to the language?" In fact, Brooks
> estimates that producing a reusable library from a working program
> requires three times as much effort as building the program itself. A
> lot of that effort is in non-coding areas such as documentation, but
> if LISP and its variants reduce the rest of it significantly, that
> would be a point in their favor.
I've been reading about languages with database support for years,
including Lisp and Prolog. However, only these two seem capable
of support that makes the database access seemless. Apparently, at
least one Prolog can do it.
Take a look at the ODBC API for Windows and see how easy it would be
to build tools in Lisp that use it. With trivial effort, you can
extend the language enough to go beyond what xBase languages offer.
> Unfortunately, I don't have enough experience in programming in these
> languages to know whether the "generalization" effort is reduced or not.
I've used an xBase language, and seen tools that adds similar features
to VB, and the code for database apps that use them. I'm confident
that such things can be done in Lisp with little effort. However, an
API such as ODBC is vital. Without it, you won't have the leverage.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
In article <············@news.hal-pc.org>,
Jonathan Guthrie <········@brokersys.com> wrote:
>Although you can do this in a so-called "Object Oriented" language, the
>languages in question can do it in a cleaner fashion. That is because
>the natural way to extend a language is with function calls and LISP and
>its variants are built around function calls and things that look like
>them. In C++ (unless you do lots of operator overloading, which has its
>own dangers) your "extensions" look different from the base language
>whereas in LISP, it looks the same.
You make it sound like this was an afterthought in C++, where it was
actually central to the language design. I would not argue with you if
you said that it was a *failure* in C++, but clearly C++ was designed so
that you could extend it in ways that looked "natural" as if they were
built-in.
I have heard people slam languages in the Pascal/Modula family for not
attempting this (as if there were not enough things to slam Pascal/Modula
about!), but I am not yet convinced it really matters. By analogy: we have
argued that despite the fact that prefix will look non-obvious to most
people raised on infix mathematics, the learning curve to jump from infix
to prefix is small. Similarly, the leap from:
matrix1 = matrix2 + matrix3;
to
matrix1.add( matrix2, matrix3)
is pretty small. I can understand the perfectionist argument that if
builtins can be manipulated with a particular syntax then extensions should
be manipulable with the same syntax, but sugar is sugar -- I don't consider
it a serious argument against a language. I don't think that the equivalent
Scheme built-in vs. extension are that much closer:
(define int1 (+ int2 int3))
(define matrix1 (matrix+ matrix2 matrix3))
You still have to learn the name and semantics of the "matrix+" operator.
That's the time consuming part (in any language), not checking whether the
syntax is infix or prefix, functional or operator-based. I suspect that the
real reason that Scheme and Lisp are nicely extensible languages are because
the *semantics* are more regular (e.g. "Who is responsible for this object?",
"When does this get destroyed?", "Is this a copy or the original object?").
Paul Prescod
In article <············@news.hal-pc.org>, Jonathan Guthrie
<········@brokersys.com> wrote:
> In comp.lang.scheme Richard A. O'Keefe <··@goanna.cs.rmit.edu.au> wrote:
> You may be referring to Dr. Brooks' classic "There is no Silver Bullet"
> where he argues persuasively that there is no change in technology that
> can produce an order of magnitude improvement in programmer productivity.
Is this article on the web? Does anyone have a URL? Thx.
> The only way to do touch the essential difficulties of programming is to
> reduce the complexity of programming and the only way to touch that by
> changing programming languages is by choosing a language that is more
> specific to the problem to be solved. For example, you can be orders of
> magnitude more efficient coding database applications in a database
> language (like XBase) than you can be when coding them in a
> general-purpose programming langauge like LISP or Scheme.
I've heard this argument before, and it is amazing to me that no one wants
to challenge it. Yes, it is true that if I want to add one column of numbers,
it is more 'productive' to use Excel (a spreadsheet program) than to use Lisp
(but not by much). What boggles my mind, though, are these _huge_ Excel
macro packages that must have taken 10X to 100X times as long to program
in Excel as in Lisp, and run 100X to 1000X slower than Lisp. If you want
an example, go to the FCC web page ftp.fcc.gov, and download their software
for keeping track of the Spectrum auctions.
I have had to use 'database' languages before, and the hassle of learning
all the gratuitously different syntax severely reduced my productivity. And
even when I got it to work, it still ran dreadfully slowly. I have also
downloaded fairly large databases into an ASCII format and then loaded them into
a Lisp machine using a simple reader program. Although it took a lot of
machine cycles to get the thing parsed and 'into' the machine, it ran like
a bat out of hell during queries. So even the most common examples of this
'special purpose language' argument do not hold water when examined closely.
> Of course, I once read an article (in BYTE, of all places) that talked
> about a style of programming called "fractal" which could be used to
> turn some general-purpose programming languages (FORTH, LISP and LISP
> variants, among others) into what amounts to special-purpose programming
> languages. However, that requires a significant up-front investment
> that means that your first project (the one where you're developing the
> tools) isn't any more productive than normal.
Perhaps you are talking about 'wide-spectrum' languages that are usable
all the way from bit-diddling to 'specifications'??
Henry Baker <······@netcom.com> wrote:
+---------------
| > You may be referring to Dr. Brooks' classic "There is no Silver Bullet"
| > where he argues persuasively that there is no change in technology that
| > can produce an order of magnitude improvement in programmer productivity.
|
| Is this article on the web? Does anyone have a URL?
+---------------
Probably not, because Addison-Wesley is still making money off of it. ;-}
However, I recommend doing as I did Sunday afternoon and springing for the
$23 bucks to buy Brooks's "The Mythical Man-Month, 20th Anniversary Edition
with Four New Chapters" [at Computer Literacy, for those in SiValley].
He & the publisher chose to reprint the original 1975 text unrevised (except
for some typos) as Chapters 1-15 (comprising a little over half of the new
book). Chapter 16 contains the 1986 "No Silver Bullet" article, Chapter 17
is "'No Silver Bullet' Refired" (written 9 years later), Ch. 18 is a
"catalog" of the bald statements/propositions of "The Mythical Man-Month"
with the explanation/stories stripped off (for reference), and last but
not least, Ch. 19 is a 20-yr retrospective, updating his opinions on "TMMM"
to 1995.
IMHO, well worth the price for "NSB" and "NSBR" alone!
-Rob
-----
Rob Warnock, 7L-551 ····@sgi.com
Silicon Graphics, Inc. http://reality.sgi.com/rpw3/
2011 N. Shoreline Blvd. Phone: 415-933-1673 FAX: 415-933-0979
Mountain View, CA 94043 PP-ASEL-IA
(Sorry about the new subject, I just couldn't resist.)
In comp.lang.scheme Henry Baker <······@netcom.com> wrote:
> In article <············@news.hal-pc.org>, Jonathan Guthrie
> <········@brokersys.com> wrote:
> > In comp.lang.scheme Richard A. O'Keefe <··@goanna.cs.rmit.edu.au> wrote:
> > You may be referring to Dr. Brooks' classic "There is no Silver Bullet"
> > where he argues persuasively that there is no change in technology that
> > can produce an order of magnitude improvement in programmer productivity.
> Is this article on the web? Does anyone have a URL? Thx.
If you can afford it, the 20th Anniversary Edition of TMMM is the best way
to get this. (If you can't afford it, read it in the library. ISBN and
related info by email to my site.)
> > The only way to do touch the essential difficulties of programming is to
> > reduce the complexity of programming and the only way to touch that by
> > changing programming languages is by choosing a language that is more
> > specific to the problem to be solved. For example, you can be orders of
> > magnitude more efficient coding database applications in a database
> > language (like XBase) than you can be when coding them in a
> > general-purpose programming langauge like LISP or Scheme.
> I've heard this argument before, and it is amazing to me that no one
> wants to challenge it. Yes, it is true that if I want to add one
> column of numbers, it is more 'productive' to use Excel (a spreadsheet
> program) than to use Lisp (but not by much). What boggles my mind,
> though, are these _huge_ Excel macro packages that must have taken
> 10X to 100X times as long to program in Excel as in Lisp, and run
> 100X to 1000X slower than Lisp.
Actually, I would expect that adding a column of numbers is easier to do
in Lisp, IF you already know how to add a column of numbers in Lisp. The
real advantage of the specialized tool lies in what happens for much
bigger tasks. You can, for example, do spreadsheet-like stuff (I keep
track of the telephone-line utilization and account counts, and suchlike
in Lotus) a lot faster in a spreadsheet than it would take to implement,
in any Lisp, those aspects of a spreadsheet that you need for each
special case.
As for the macro packages, I'm sure that you find them less useful than
the equivalent Lisp libraries. However, people who don't know from
programming and who, furthermore, don't WANT to know from programming
(and will tell you so with great vigor, if you were to be so foolish as
to ask) find them a lot more useful than anything for Lisp. You're just
not in the target audience.
> I have had to use 'database' languages before, and the hassle of learning
> all the gratuitously different syntax severely reduced my productivity.
> And even when I got it to work, it still ran dreadfully slowly. I have
> also downloaded fairly large databases into an ASCII format and then
> loaded them into a Lisp machine using a simple reader program. Although
> it took a lot of machine cycles to get the thing parsed and 'into' the
> machine, it ran like a bat out of hell during queries. So even the most
> common examples of this 'special purpose language' argument do not hold
> water when examined closely.
The assumption is made that the programmers are familiar with the tools.
You wouldn't like it if I compared expert C programmers with beginning
Lisp coders, and concluded that Lisp is hell to code in, would you?
When you say "fairly large databases" just how big are you talking about?
It sounds like you had a "database" that consisted of a single table which
you loaded into main store and ran your "queries" off of that. If that is
the case, the database in question qualifies as "miniscule," NOT "fairly
large." Tools like xBase are suitable for small to medium-sized database
jobs (a half-dozen "simultaneous" transactions on databases of perhaps
1000-1,000,000 records in 10-20 tables, YMMV) and do real well at that
sort of job. The performance is almost entirely dependant on the skill
of the programmer in that sort of situation. For bigger databases, you
need heavier-duty tools. Mainframes spend their time doing lots of
manipulation of 10e9 record databases consisting of dozens of tools and
they can handle hundreds of transactions per minute with multi-level
commitment and transaction logging/rollback and all that fun stuff
so beloved of dba's.
If I were to try that in Lisp (I'm not likely to, as that sort of thing
isn't what I do) I would begin by reinventing the dbms, not the best way
to be productive. Perhaps a better way to approach that problem would
be to use your Lisp program as the front end for a database server. I
may be trying this, later. (Then again, I may not. I am a beginner in
Scheme, and I don't know Lisp at all. I would be fighting an uphill
battle trying to do what I describe just like you were when you were
forced to use xBase of PAL or whatever.)
> > Of course, I once read an article (in BYTE, of all places) that talked
> > about a style of programming called "fractal" which could be used to
> > turn some general-purpose programming languages (FORTH, LISP and LISP
> > variants, among others) into what amounts to special-purpose programming
> > languages.
> Perhaps you are talking about 'wide-spectrum' languages that are usable
> all the way from bit-diddling to 'specifications'??
No, the languages in question are those for which it is possible to easily
extend that language in a way that is consistent with the base language.
As an example, it is not possible to easily extend C in this fashion
because you can't add new (or override old) operators without rewriting
your compiler, so you have to make your extensions in function libraries.
Since, in C, function libraries look different from the base language,
there is an obvious dividing line between the old language and the
extension. On the other hand, Scheme is built from function calls (and
things that look like function calls) so it is easy to add features that
look Scheme language primitives. (FORTH is similar, but one uses
commands rather than function calls to implement the new functionality.)
Many of the so-called "object-oriented languages" are intended to be used
for implementing this sort of programming style and generally achieve it
with a moderate amount of success.
It is very difficult to create a language that works well across a broad
range of application types.
--
Jonathan Guthrie (········@brokersys.com)
Information Broker Systems +281-895-8101 http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX 77014, USA
We sell Internet access and commercial Web space. We also are general
network consultants in the greater Houston area.
From: ······@sprintmail.com
Subject: Re: GodziLisp vs the xBase monster
Date:
Message-ID: <857498669.29725@dejanews.com>
In article <············@news.hal-pc.org>,
Jonathan Guthrie <········@brokersys.com> wrote:
>
> (Sorry about the new subject, I just couldn't resist.)
>
> Perhaps a better way to approach that problem would
> be to use your Lisp program as the front end for a database server. I
> may be trying this, later.
You may want to take a look at the Common Lisp Business Toolkit:
http://www.infinet.com/~btobin/lispteam.html
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Sin-Yaw Wang wrote:
> I think fundamentally, Lisp syntax is not natural for human being. It
> is elegant for computer or software to process, but not for real
> people. From grade school, you are taught 10 = 8 + 2, not 10 = (+ 8
> 2). From high school, you learn how to prove mathematical theorems
> procedually.
I've got to give the knee-jerk response of a linguist here. Just
because you learned as a kid a language that does things one particular
way doesn't make every other way of doing it unnatural or inhuman.
*You* expect sentences to go Subject Verb Object -- essentially infix
notation. This isn't inherently "natural". There are a bunch of
languages whose syntax works this way (e.g., English, French, Chinese).
But there are an equally large group of languages that use the "postfix
notation" of Subject Object Verb (e.g., Japanese, Korean, Hindi), a
respectable number that use "prefix notation", Verb Subject Object
(e.g., Gaelic, Hebrew), a few that use the other three possible orders,
and a whole bunch that let you mix words up any way you want as long as
you mark everything with a prefix or suffix (kind of like the keyword
arguments of Common Lisp).
My HP calculator works like Japanese -- get all the characters on the
stage, *then* say what to do with them. Lisp, Prolog (if you don't go
messing with "op"), and randomly chosen subsets of most other languages
do the opposite. I'm not sure how much difference the mirror-image
reversal makes: I find that my brain slips into much the same state
when I'm reading a Subject-Object-Verb natural language as when I'm
reading Scheme code.
If you honestly can't stand either prefix or postfix notation, if you'd
honestly rather use infix notation, I can understand and respect that.
But please don't justify your preference as being the one true way that
the human mind works. That way lies ethnocentrism and worse.
-- Kevin
Kevin Russell
University of Manitoba
"You say poTAYto, I say ... um, poTAYto. OK, bad example."
On Wed, 19 Feb 1997 19:11:53 GMT, ········@wam.umd.edu (Robert
Rodgers) wrote:
>I found Lisp very *difficult* to parse. From what I've been told by
>people who can actually read lisp without difficulty, it took them a
>good two years or so before they had this skill polished.
Well it took /me/ a couple of days, reading SICP. And I'm relatively
uneducated. One A level, a few GCSEs, no degree.
ABW
--
"Simply drag your mother in law's cellphone number from the
Address Book to the Laser Satellite icon, and the Targeting
Wizard will locate her. Then follow the onscreen prompts for
gigawattage and dispersion pattern..."
(Windows for Early Warning and Defence User's manual P385)
Alaric B. Williams Internet : ······@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>
········@wam.umd.edu (Robert Rodgers) writes:
>I found Japanese to be very natural & easy when I took 4 years of it.
>Very little effort required to structure sentences&c.
Four years?
>I found Lisp very *difficult* to parse. From what I've been told by
>people who can actually read lisp without difficulty, it took them a
>good two years or so before they had this skill polished.
This sounds very odd. It took _me_ about two weeks, and I've never met
*anyone* with good Lisp skills who took even *one* year let alone two.
>Contrast
>this with the rapidity with which a C++ or C programmer can (and is
>*expected to*) be able to read C++ or C (from past experience, this is
>"expected" within a few weeks of starting a C class, and reading
>fluency in less than two semesters).
I'm sorry, but this _has_ to be a lie. We teach C and C++ here.
C++ is a _huge_ language (bigger than Ada). It is a very syntaxful
language, with much overloading of tokens. And the end of two semesters
of C, students _still_ haven't grasped all the things that "static" means
in C, and as for learning more than a tiny fraction of C++ in two semesters,
FORGET IT. You are also conveniently forgetting that by the time they
meet C, many people these days have already been taught an essentially
similar language in high school, such as Basic or Pascal.
Let's face it, how many people actually remember the full table of C
operators and their precedence, and routinely get it right? Honestly?
>That people *can* and *do* learn to read lisp naturally isn't an
>argument that it complies well with what human language processing
>handles naturally -- people also can and do learn to read equations,
>notations and such that are pages long and extrordinarily complex.
>This isn't "natural" reading.
You are tilting at straw men. It is the *opponents* of Lisp who
talk about "naturalness". The *friends* of Lisp point out that
what is natural is no more and no less than "what you are used to".
I hate it when people waffle on about "human language processing"
when they obviously haven't a _clue_ about what human language processing
actually involves or is capable of. Face it: by any reasonable
measure, C and C++ are EXTREMELY UNNATURAL. Only COBOL programmers can
claim to have a language which resembles any human language in any
material way.
What the friends of Lisp claim is not that it is *natural* but that it
is *easy*.
>The difference between Lisp and most every infix language is far and
>away completely different from the sort of differences we see in human
>languages. How many human languages are structured the way lisp is
>(you don't get *large* stacks of operands / operators, you get small
>ones, usually seperated into clauses).
How many human languages are structured the way C and C++ are?
NONE. Before you say *one* more thing about human languages, find us
just _one_ language that resembles C or C++.
>Visual locality was another annoying factor in lisp.
What is so annoying about having visual locality?
It is true that Lisp separates things less than C or C++,
but why is that a defect?
--
limits on the scope of cooperation are often due to the inability
to recognise the identity or the acts of the other playes. --R.Axelrod
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
Richard A. O'Keefe wrote:
>
> ········@wam.umd.edu (Robert Rodgers) writes:
> >I found Lisp very *difficult* to parse. From what I've been told by
> >people who can actually read lisp without difficulty, it took them a
> >good two years or so before they had this skill polished.
>
> This sounds very odd. It took _me_ about two weeks, and I've never met
> *anyone* with good Lisp skills who took even *one* year let alone two.
>
Well, I consider myself a good Lisp programmer, and it took me over a
year to MASTER the Common Lisp. Of course, if you mean some C/C++ like
programming, it is possible to grab CL quite soon, but to learn CL in
two weeks.. That is a good joke.
PKY
From: Erik Naggum
Subject: Re: Why lisp failed in the marketplace
Date:
Message-ID: <3066031941459593@naggum.no>
* Markku Laukkanen
| Well, I consider myself a good Lisp programmer, and it took me over a
| year to MASTER the Common Lisp. Of course, if you mean some C/C++ like
| programming, it is possible to grab CL quite soon, but to learn CL in two
| weeks.. That is a good joke.
more anecdotal evidence: I don't know how much time I spent learning the
basics in Lisp, because I don't think I spent any conscious time on it.
The Little Lisper lay on a table in the "pause area" where I once worked,
and I picked it up and read it. reading that book was probably all it took
to get most of the basics down pat. (I was somewhere between 13 and 15 at
the time, probably very impressionable.) the rest has just sort of floated
my way, _except_ for the more advanced aspects of CLOS and the condition
system, which I still find troubling -- philosophical misalignment, I
guess. (`change-class' still makes me queasy, but I was on the road to
reinventing it, so I have come to conclude it can be the Right Thing when
state-changes are easier to express with class changes.)
most of my journey in Common Lisp has been a series of incidents like this:
a week of programming, realizing that I'm doing "grunt work", having a
flash of anxiety that this is "bad", reading up on some of the stuff I
didn't see any use for or didn't understand in Steele or the HyperSpec, and
getting much relieved, then deleting 500 lines of code and doing that
week's work over in two hours. very satisfied, I write my observations
down in a "programmer's log", take the rest of the day off, and play with
the concept (and my cat). two years of that, and I think I have a pretty
good grasp of the language. (Scheme, in contrast, gives me the feeling
that this kind of "grunt work" is _not_ bad -- Scheme programmers implement
complex stuff with basic buildings blocks over and over, it seems.)
however, and this is what I find important, at no point in my using Common
Lisp have I been _stumped_, or feeling that I was banging my head against a
wall of minutiae or any such thing. I didn't _need_ to "master" Common
Lisp to use it well. the simpler aspects of CLOS was shown to me by a
friend not long ago -- it's just been saving me time, not the insufferable
hair that I had to fight myself through in C++. I'm sure C++ can be as
easy to learn as CLOS (Andrew Koenig's ever-present counter-argument that
C++ is hard is that he can teach people this stuff in mere days), but
_mistakes_ in C++ devour you (and sometimes your machine), and face you
with language details you didn't even know _could_ exist. a C++ programmer
might very easily see his program do something completely insane and spend
the next three days trying to figure out what the hell happened, just to
find that he had declared a new function and some other function was called
with an argument of the wrong type and some constructor was called that he
didn't even know would be affected by his new function. contrast this kind
of incident (I had one of them a week, not all equally severe, when I tried
to use C++ in a project in 1993) with the Common Lisp incidents I described
above. C++ instilled in me a fear of mistakes that crippled my ability to
experiment with the language, because I was unable to see the chain of
events that led to the compiler's decisions, and I don't think I should
have had to, either. Common Lisp provided me with an environment where
mistakes had a _very_ low cost and offered early and precise detection to
boot. this provided me with an early warning system for anything I might
need to look up or study more. in C++, I would tend to think "sh*t, this
_should_ work", whereas in Common Lisp, I would think "hmm, that's odd",
and reach for the documentation. (I have subtracted for the normal
bug-hunting in all the software I use in these descriptions.)
concluding from the way I have learned many different programming languages
(and CPU's) over the years, I'd say that the _only_ thing that matters to a
student of a language is that he can _trust_ the language. I can trust C,
I can trust Common Lisp, but I _could not_ trust C++. most of today's
programmers _don't_ trust their programming language or environment and
thus have a hard time with the "trust" concept, or so it seems, anyway.
(speaking of trust, allow me a digression: people will associate feelings
of distrust and the resulting powerlessness with some part of the learning
experience, but not necessarily the right one. I suspect that some of this
distrust from other languages is hurting Lisp. I speculate (I haven't made
the slightest effort to test this idea on others, however) that when a
programmer in a syntax-rich language reaches for the parens, it is because
he cannot trust the compiler to do what he wants. I know from my own
experience that I have had to add parens to oddly misbehaving expressions
in C, but I haven't associated the pain of the debugging with the parens --
I have associated it with the infix syntax. if you associate the pain with
the parens, how will you feel about a language where there are parens all
over the place? now, if you're into conspiracy theories, or just enjoying
them, consider that the most overloaded of all the horribly overloaded
operators in C++ are the parens. if you were desinging a language, and you
understood this feeling of distrust and the associative nature of the human
brain, would it not be a great idea to make parens the most painful of all
your operators if you wanted to keep your victims from discovering Lisp?)
#\Erik
--
if you think big enough, you never have to do it
From: Paul Schaaf
Subject: Re: Why lisp failed in the marketplace
Date:
Message-ID: <33160ED0.5B2F@acm.org>
Erik Naggum wrote:
> (`change-class' still makes me queasy, but I was on the road to
> reinventing it, so I have come to conclude it can be the Right Thing when
> state-changes are easier to express with class changes.)
I've found changing the class of an object in Smalltalk to be useful when
*behavior* changes are easier to express with class changes than they are
by replacing BlockClosures (lambda functions) stored by the object. When
you think of the class as being part of the *state* of the object then this
does not seem like such a bad idea. (Although I must admit I haven't used
this idea very often in practice.)
Not knowing CLOS very well, I'm not sure how well this idea translates.
> most of my journey in Common Lisp has been a series of incidents like this:
> a week of programming, realizing that I'm doing "grunt work", having a
> flash of anxiety that this is "bad", reading up on some of the stuff I
> didn't see any use for or didn't understand in Steele or the HyperSpec, and
> getting much relieved, then deleting 500 lines of code and doing that
> week's work over in two hours.
My experience learning Smalltalk was very much the same. I don't know whether
I should be suprised by this. I suppose the learning of any elegant language
might follow this pattern. When I replaced many day's work with a few hours'
it was because after having done it once I had a much clearer understanding of
the problem.
> very satisfied, I write my observations down in a "programmer's log",
Good idea. I wish I'd done the same.
> (Scheme, in contrast, gives me the feeling
> that this kind of "grunt work" is _not_ bad -- Scheme programmers implement
> complex stuff with basic buildings blocks over and over, it seems.)
I'm trying to learn Scheme--I'm almost finished with SICP--but I don't
understand your statement. Could you elaborate?
--
Paul G. Schaaf, Jr.
Smalltalk Consultant
Versant Object Technology
···········@acm.org
From: Erik Naggum
Subject: Re: Why lisp failed in the marketplace
Date:
Message-ID: <3066118552736104@naggum.no>
* Erik Naggum
| (Scheme, in contrast, gives me the feeling that this kind of "grunt
| work" is _not_ bad -- Scheme programmers implement complex stuff with
| basic buildings blocks over and over, it seems.)
* Paul Schaaf
| I'm trying to learn Scheme--I'm almost finished with SICP--but I don't
| understand your statement. Could you elaborate?
the lack of generalized functionality and the general low-level standard
substrate of Scheme means that you need to implement a very large number of
functions that are already there in Common Lisp. that is, this is true if
you program in Scheme, not in some particular Scheme _implementation_ or
Scheme + some non-standard library.
SICP doesn't teach you Scheme as much as it teaches you to think in terms
consonant with the computer, and I firmly believe that programmers need to
implement low-level stuff to learn how they work and how to use them, but I
draw a sharp line between learning and working; learning is a continuous
progression through new material, while working is mostly repeating a large
number of already well-known tasks as a means to create something new or
learn something so new that nobody can teach you. it's the repetitive part
of work in "real life" that I find to be "grunt work", and which I want to
minimize.
#\Erik
--
if you think big enough, you never have to do it
In article <·············@acm.org>, Paul Schaaf <···········@acm.org> writes:
>> Erik Naggum wrote:
>> > (`change-class' still makes me queasy, but I was on the road to
>> > reinventing it, so I have come to conclude it can be the Right Thing when
>> > state-changes are easier to express with class changes.)
>>
>> I've found changing the class of an object in Smalltalk to be useful when
>> *behavior* changes are easier to express with class changes than they are
>> you think of the class as being part of the *state* of the object then this
This is a very useful mechanism in some cases.
My real-world simple example is having the classes
'employee' and 'manager', where manager inherits from employee.
If someone gets promoted to a manager, their class changes, but
the instance retains its same identity and any existing
employee slots, like name, address, etc, carry over.
The manager instance will now have different applicable methods
for it than before,
such as the method used to report their work hours
(no longer on an hourly bases, but perhaps daily, or not at all)
-Kelly Murray ···@franz.com http://www.franz.com
a. ········@wam.umd.edu (Robert Rodgers) writes:
a. I found Lisp very *difficult* to parse. From what I've been told by
a. people who can actually read lisp without difficulty, it took them a
a. good two years or so before they had this skill polished.
b. I wrote
b. This sounds very odd. It took _me_ about two weeks, and I've never met
b. *anyone* with good Lisp skills who took even *one* year let alone two.
c. Markku Laukkanen <················@research.nokia.com> writes:
c. Well, I consider myself a good Lisp programmer, and it took me over a
c. year to MASTER the Common Lisp. Of course, if you mean some C/C++ like
c. programming, it is possible to grab CL quite soon, but to learn CL in
c. two weeks.. That is a good joke.
The joke is exclusively of Markku Laukkanen's twisting.
I did not write that I mastered Common Lisp in two weeks.
What I mastered in two weeks was the syntax of Lisp 1.5 and the elements
of list processing in it.
I was not speaking of "C/C++ like programming".
I learned Lisp before there *was* such a thing as C. Seriously.
I had written an interpreter for a language that was a cross between
Lisp and Pop-2, maintained an early BBN-Lisp port, and written a
Lisp interpreter that someone else ported to the P400 (via a rewrite
in Fortran, assisted by a SNOBOL program that converted the Algol...)
before I ever heard of C. And _that_ was before UNIX V7.
Lisp was the fourth programming language I learned after Fortran, Algol,
and PL/I. I learned it from that wonderful little "Recursive Programming
Techniques" book in the Methuen series.
The code I was writing after reading that book and the Lisp 1.5 manual
was Lispy, to the extent that that was possible before LET, DO, and
other structured alternatives to PROG.
Mastering Common Lisp requires a thorough understanding of the built in
types and functions, and the extension mechanisms. I still haven't used
CLOS at all in any of my code, so cannot pretend to have mastered the
whole of CLtL2. But that is quite irrelevant to a discussion of the
difficulty of mastering the *syntax*.
How many people have mastered *C* at that level? I mean, by the time
you've learned how to drive the 150 or so standard library functions,
the 1170 or so UNIX functions, &c, you've had to master a lot more than
you'll find in CLtL2. Indeed, the C++ draft standard is bigger and
harder. (Indeed, the C++ standard *without* annotations is a thicker
book than the Ada95 standard *with* annotations!)
--
Will maintain COBOL for money.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
Richard A. O'Keefe wrote:
>
> a. ········@wam.umd.edu (Robert Rodgers) writes:
> a. I found Lisp very *difficult* to parse. From what I've been told by
> a. people who can actually read lisp without difficulty, it took them a
> a. good two years or so before they had this skill polished.
>
> b. I wrote
> b. This sounds very odd. It took _me_ about two weeks, and I've never met
> b. *anyone* with good Lisp skills who took even *one* year let alone two.
>
> c. Markku Laukkanen <················@research.nokia.com> writes:
>
> c. Well, I consider myself a good Lisp programmer, and it took me over a
> c. year to MASTER the Common Lisp. Of course, if you mean some C/C++ like
> c. programming, it is possible to grab CL quite soon, but to learn CL in
> c. two weeks.. That is a good joke.
>
> The joke is exclusively of Markku Laukkanen's twisting.
>
> I did not write that I mastered Common Lisp in two weeks.
> What I mastered in two weeks was the syntax of Lisp 1.5 and the elements
> of list processing in it.
Sorry, misunderstood your saying (didn't look for the read verb out
there).
It is true, that LISP language is a little bit difficult to understand,
if it is "badly" written or formatted.
But nowadays the situation has changed quite much (at least on the CLtL2
side), because of the LOOP macros and stuff like that. I personally
understand well written loop macros better than C++ STL code.
And to understand Lisp, you really have to be using emacs (or some other
Lisp-) editor.
> Mastering Common Lisp requires a thorough understanding of the built in
> types and functions, and the extension mechanisms.
...SNIP...
> How many people have mastered *C* at that level? I mean, by the time
> you've learned how to drive the 150 or so standard library functions,
> the 1170 or so UNIX functions, &c, you've had to master a lot more than
> you'll find in CLtL2. Indeed, the C++ draft standard is bigger and
> harder. (Indeed, the C++ standard *without* annotations is a thicker
> book than the Ada95 standard *with* annotations!)
Yep, really mastering the syntax in Lisp is the smallest part. The nice
feature in CLtL2 is, that you can write the same code in dozens of
different ways. This could be the reason,why Lisp "failed on the
marketplace", if so can be said at all. Lisp gives to much power to
programmer (compared to C/C++) , and it can lead to some confusing
programming style.
Lisp would be awesome language for developers, if there would be nice,
portable UI over Winnt/Unix boxes.
> Will maintain COBOL for money.
Hmm, personally wouldn't :( otherhand , it depends from the amount of
compensation :)
PKY
This message is nothing to do with me, it's the 32 cups of coffee &
resulting lack of sleep that did it, honest.
* Erik Naggum wrote:
> what makes _me_ sad is the focus on "most folks" and "Joe Sixpack".
> why are we even _thinking_ about home computer equipment when we wish to
> attract professional programmers?
[And much more very true stuff]
One of my greatest frustrations as a system administrator is seeing
the awful encroachment of Windows machines in professional
environments. The hardware is dubious (every PC is *different* damn
it, even from the same maker -- how am I meant to be able to look
after n machines when each one has different idiosyncratic
incompatibilities!). Windows regularly eats itself and has to be
reinstalled. Sometimes Windows even manages to eat the machine by
trashing non-volatile state in some card. And how do you do C/C++
development on a machine with no memory protection that works (with
your fingers hovering over the reset switch I suspect).
And the tragedy is they aren't even *cheap*. OK the initial cost is a
bit less than a Sun or something, but the admin costs are crippling,
and I have no idea what the time lost through rebooting them every 10
minutes is. And when they die it takes 2 weeks to get a disk on a
`next day, on site' contract from a major manufacturer, while I've
*never* waited more than a day for Sun bits.
But the problem is very hard to solve: the mass market for SW is where
the money is, and it's on PCs running Windows. And you can't develop
PC software without PCs and C because the interfaces are so
poorly-specified & C-centric, so what do you do? People listen and
nod when you point out the true costs of this catastrophe, but their
brains have been destroyed and they don't understand what you say. I
wish I knew what the solution to this was.
So I think we're thinking about home computer equipment because we
want to have jobs unfortunately, and the number of jobs developing on
professional systems is not that large.
--tim
With a mighty <···············@staffa.aiai.ed.ac.uk>,
···@aiai.ed.ac.uk wibbled into the void...
> One of my greatest frustrations as a system administrator is seeing
> the awful encroachment of Windows machines in professional
> environments. The hardware is dubious (every PC is *different* damn
> it, even from the same maker -- how am I meant to be able to look
> after n machines when each one has different idiosyncratic
> incompatibilities!). Windows regularly eats itself and has to be
> reinstalled. Sometimes Windows even manages to eat the machine by
> trashing non-volatile state in some card. And how do you do C/C++
> development on a machine with no memory protection that works (with
> your fingers hovering over the reset switch I suspect).
One answer - that usually works for me - is to use NT, instead of
Win16 or the bodge job that MS calls Windows 95. I strongly suspect
that the latter is merely a marketing answer to the "Warp" threat,
from IBM's OS/2. I've seen Win95 machine regularly die, but only eat
themselves very rarely. The users I know are beating their machines
rather heavily, and definately more "techie" than your average Windows
user, so this might account for many of the problems.
It might also mean that they experience _fewer_ difficulties, tho I
doubt that most users will change their software and hardware as
regularly. This might be an invitation to crash the machine.
However, my experience with developing under NT is that it very rarely
crashes, and copes with rogue apps very smoothly. It's not perfect, of
course. I installed some new software yesterday, and NT promptly gave
me the notorious "blue screen of death". However, after using NT for
well over a year now, that's only the 3rd time I've seen this happen.
Not that NT would be my first choice of OS. If the motherboard in my
machine didn't have hardware bug (in the hard drive controller), then
I might've been using Linux for most of the last year.
> And the tragedy is they aren't even *cheap*. OK the initial cost is a
> bit less than a Sun or something, but the admin costs are crippling,
> and I have no idea what the time lost through rebooting them every 10
> minutes is. And when they die it takes 2 weeks to get a disk on a
> `next day, on site' contract from a major manufacturer, while I've
> *never* waited more than a day for Sun bits.
I'm not sure that the OS or the machine would make a real difference.
People cut corners, regardless of these choices. It may be that those
people who _don't_ cut corners just happen to use Unix, but I can't
say for sure. It just often seems that way, to me. For all I know,
there could be just as many corporate people cutting corners and
creating unreliable networks with Unix as there are with Netware, NT,
etc. Perhaps some of the horror stories that I've heard about Unix are
really about Xenix, which could be understandable.
If Xenix was a mess, perhaps it was because it ran on 286 machines, as
I recall once being told - or was I misinformed? It could certainly
explain a few things. The odd "bad apple" (or just a bad experience
with a "good apple") could've given an OS like Unix, or a language
like Lisp, a bad name with many people.
> But the problem is very hard to solve: the mass market for SW is where
> the money is, and it's on PCs running Windows. And you can't develop
> PC software without PCs and C because the interfaces are so
> poorly-specified & C-centric, so what do you do? People listen and
> nod when you point out the true costs of this catastrophe, but their
> brains have been destroyed and they don't understand what you say. I
> wish I knew what the solution to this was.
Think Dilbert. The corporate world has mostly chosen Windows. Either
you should embrace that world, or ignore it. I'm not certain that
there's much room for compromise. However, I don't think that means
that the choice is between Lisp under Unix, or C++ under Windows. It
could just as easily be - for some of us - Lisp under Windows, _if_ a
Lisp vendor were to fully embrace Windows.
So far, I'm not convinced that any Lisp vendor has done this. Lisp is
obviously available for Windows, but that's very different from
embracing it - as MS, Borland, Symantec, Watcom, etc have all done.
It may just be a coincidence that they all sell C++ compilers, as
there are a few vendors for other languages, like Smalltalk and APL,
who've also embraced Windows. Lisp is lagging behind in this respect.
> So I think we're thinking about home computer equipment because we
> want to have jobs unfortunately, and the number of jobs developing on
> professional systems is not that large.
We could paraphrase John le Carre: We can't afford to be more
professional than the opposition. That's an ugly idea, but it could
easily describe how the corporate world operates. They do things
_because they can_. It's all hopeless, ho. When Friends of the Earth
was started, it was believed that the industrial world and the natural
world were in mutual conflict. Today, we have a very different story,
as told by the Rio Summit. Emerging industrial nations don't want to
repeat the mistakes of the past, and instead they're learning from
them. Perhaps this can give us hope for Lisp's future, too.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
Teunis Peters <········@comfo.ca> writes:
| Okay, open challenge from me:
| --- How ABOUT some kind of GUI interface standard for Lisp. ---
Tk.
Tk is widely deployed, easy to use, and well engineered. The easiest
(hence best) solution is to simply call the Tk library from lisp.
Patrick Giagnocavo <·····@earthlink.net> wrote:
> Which one of you blathering Lisp weenies (not to name any names mind
> you) has the guts to try compiling this under the Cygnus/GNU toolkit
> that implements a lot of posix functionality under Win32? A bunch of you
> have stated that you are doing things under Windows anyways, right?
For your information, the Gambit-C Scheme to C compiler is very
portable and should compile pretty much as is under the Cygnus/GNU
toolkit. Gambit-C has been ported to DJGPP (another flavor of the GNU
toolkit for DOS), Microsoft Visual C++ (for Windows-NT/95), as well as
Macintosh (using CodeWarrior) and most flavors of UNIX.
The performance of the C code generated is reasonably good and with
the C-interface you can call C code easily.
Marc
* Sin-Yaw Wang wrote:
> Henry Baker wrote:
>> In article <·············@acm.org>, ······@acm.org wrote:
>> > I think fundamentally, Lisp syntax is not natural for human being.
> Why do we argue if this syntax is natural or not? This is silly. Go
> find a good sample of software engineers and ask them, "Is Lisp syntax
> and recursive thinking natural to you?" Tally the responses and you
> have the answer. No amount of argument will change that fact. (This
> seems like a good grad school project.)
Why do we argue if Latin is a natural language or not? This is silly.
Go find a good sample of natural language users and ask them, "Is
Latin natural to you?" Tally the responses and you have the answer.
No amount of argument will change that fact. (This seems like a good
grad school project.)
--tim
Sin-Yaw Wang <······@acm.com> writes:
> I still assert that the more natural the syntax, the more productive your
> engineers. How can anyone dispute this fact?
Here are two possible meanings I can think of for your claim of a syntax
being `more natural':
(1) It is easier to learn (because it is closer to something already known)
(2) It is closer to some fundamental underlying mechanism in the brain,
and so will always be easier to deal with
With regard to infix language X vs. lisp, you could probably say that (1) is
true for many people, but (2) seems much harder to support.
However, for most non-casual use, the learning period is a small part of
using a language; in such cases, (1) may be true, but is rather over-shadowed
by other factors.
-Miles
--
Miles Bader / ·····@gnu.ai.mit.edu / (617) 253-8568
Fast, small, soon; pick any 2.
On 21 Feb 1997, Miles Bader wrote:
> Sin-Yaw Wang <······@acm.com> writes:
> > I still assert that the more natural the syntax, the more productive your
> > engineers. How can anyone dispute this fact?
>
> Here are two possible meanings I can think of for your claim of a syntax
> being `more natural':
>
> (1) It is easier to learn (because it is closer to something already known)
> (2) It is closer to some fundamental underlying mechanism in the brain,
> and so will always be easier to deal with
>
> With regard to infix language X vs. lisp, you could probably say that (1) is
> true for many people, but (2) seems much harder to support.
Thank you for raising the level of this discussion.
IMO, the distinction that linguists make between spoken languages
(including sign languages) and written languages has some bearing on
the question of naturalness of PL syntaxes. Linguists claim that spoken
language is "in the brain", and writing is something we learn (sometimes)
with great difficulty. I believe that programming is like writing, math,
and music in this sense, and so claim (2), which I've seen many times on
the net, strikes me as preposterous.
I also find the claim that there is a relationship between the word order
and pre/post/in-fix PL preference in programmers dubious. Evidence?
(Book recommendation: "The Language Instinct" by Steven Pinker)
> However, for most non-casual use, the learning period is a small part of
> using a language; in such cases, (1) may be true, but is rather over-shadowed
> by other factors.
Well said!
Personal anecdote: one of my most pleasurable and productive programming
experiences was writing a simulation package for my undergrad advisor
on a Symbolics 3600 in ZetaLisp. I was a math guy, with little programming
experience. I don't recall having *any* problems with Lisp syntax. In my
first professional job as a C programmer, people would challenge each other
with C data type declarations to parse.
-- Brian
·······@cc.umanitoba.ca (Kevin Russell) writes:
>
> I'll grant you there is one huge problem for a postfix thinker like
> me. In reading, Lisp's prefix notation is like a minor typographical
> variation that quickly becomes transparent. *Writing* arithmetic in
> prefix notation is hell for me. I'll get a complex expression down
> perfect and then remember I have to divide the whole thing by two, which
> is usually the start of a cursor nightmare. I have the same problem
> writing arithmetic in infix notation, of course.
infix.lisp in CMU AI repository solves this problem. You can write
x^10 + y^7 /sin(z) as much as you want.
In article <··············@spot.uchicago.edu>, Alexey Goldin
<······@spot.uchicago.edu> wrote:
> ·······@cc.umanitoba.ca (Kevin Russell) writes:
> >
> > I'll grant you there is one huge problem for a postfix thinker like
> > me. In reading, Lisp's prefix notation is like a minor typographical
> > variation that quickly becomes transparent. *Writing* arithmetic in
> > prefix notation is hell for me. I'll get a complex expression down
> > perfect and then remember I have to divide the whole thing by two, which
> > is usually the start of a cursor nightmare. I have the same problem
> > writing arithmetic in infix notation, of course.
>
> infix.lisp in CMU AI repository solves this problem. You can write
> x^10 + y^7 /sin(z) as much as you want.
Symbolics Genera has an infix reader macro.
--
http://www.lavielle.com/~joswig/
·······@cc.umanitoba.ca (Kevin Russell) writes:
> *Writing* arithmetic in
> prefix notation is hell for me. I'll get a complex expression down
> perfect and then remember I have to divide the whole thing by two, which
> is usually the start of a cursor nightmare.
Hmm.
"(/ " Forward-S-Expression " 2)"
In the editor I use, 9 keystrokes.
If I have a complex expression in C, that needs dividing, it's
"(" <hairy cursor nightmare> ")/2"
because there isn't a key meaning "forward over C expression".
In fact I just keep hitting Forward-S-Expression until it reaches
the right place. I'd have to say that it's a lot _easier_ with
prefix notation.
Of course, the best approach in any language is not to have complex
expressions in the first place. This kind of thing is when I tend
to use LET* in Lisp, and to wish futilely that C had an equivalent.
(Yes I know about blocks, but they can't be used in _expressions_.)
--
limits on the scope of cooperation are often due to the inability
to recognise the identity or the acts of the other playes. --R.Axelrod
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
Richard A. O'Keefe <··@goanna.cs.rmit.edu.au> wrote:
+---------------
| > prefix notation is hell for me. I'll get a complex expression down
| > perfect and then remember I have to divide the whole thing by two, which
| > is usually the start of a cursor nightmare.
|
| Hmm.
| "(/ " Forward-S-Expression " 2)"
| In the editor I use, 9 keystrokes.
+---------------
And even in raw "vi", it's only 12 keystrokes: "i(/ <ESC>" to put the front
part on, " %" to step over the S-expression, and "i 2)<ESC>" for the rest.
(Or only 11 if you do it the counter-intuitive [to me] way and insert
"/ (" *after* the opening paren of the old S-expr.)
+---------------
| If I have a complex expression in C, that needs dividing, it's
| "(" <hairy cursor nightmare> ")/2"
| because there isn't a key meaning "forward over C expression".
+---------------
Indeed!
-Rob
-----
Rob Warnock, 7L-551 ····@sgi.com
Silicon Graphics, Inc. http://reality.sgi.com/rpw3/
2011 N. Shoreline Blvd. Phone: 415-933-1673 FAX: 415-933-0979
Mountain View, CA 94043 PP-ASEL-IA
In article <············@goanna.cs.rmit.edu.au>,
··@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
> Let me close with one more quote, from prof. dr. Edsger W. Dijkstra,
> "On the Economy of doing Mathematics", found in "Mathematics of
> Program Construction", Springer LNCS 669, 1992.
>
> Industrial pressure and propaganda promoted the view that,
> with the proper programming language, programming did not
> pose a major challenge and did not require mental gifts
> or education ... I would like to point out that, in very
> much the same way, mathematics has suffered and still
> suffers from the tryanny of "the average mathematician".
> Improvements in notation, in language or concepts, are
> rejected because such deviations from the hallowed
> tradition would only confuse the average mathematician ...
Reminds me of my former employeer. In the early 80's, they had a penchant for
hiring foreign language majors for software engineering positions. Their
rationale was that programming languages were like foreign languages, hence
foreign langauge majors would make good programmers. And there were a whole lot
of them around who would work for a lot less than CS majors.
Mike McDonald
·······@engr.sgi.com
In article <··········@crl9.crl.com>, ···@crl.com (Bradley Yearwood) wrote:
> In article <·······················@10.0.2.1>,
> Henry Baker <······@netcom.com> wrote:
> >
> >Some of the engineers I know love LabView/LabWindows, which is a graphical
> >language having nothing to do with the usual character-sequence-based
> >languages.
> >
> >I personally would like to use such a language (done in Lisp, of course!).
>
> I vaguely recall from the early 80s, a paper proposing a graphical language
> based upon Lisp. Arguments to a function were represented by enclosure within
> a distinctive symbol for that function. Example: a "forall" sort of function,
> whose symbol was an outline of an upside-down A. I think the language was
> called PAM. If one were to nest very deeply, the figures would quickly become
> difficult to draw, but the paper gave a couple of cute and almost compelling
> simple examples.
>
> It might've been in SIGPLAN, or a Lisp and Functional Programming conference.
> Unfortunately, I cannot recall the author's name.
You also may look at PatchWork (another Macintosh Common Lisp application):
http://www.ircam.fr/produits-real/logiciels/patchwork-e.html .
It is about Midi-Programming and includes a graphical programming language.
--
http://www.lavielle.com/~joswig/
In article <···············@hart.CS.Princeton.EDU> ·······@hart.CS.Princeton.EDU (Daniel Wang) writes:
>I'm of the impression that in the end one will discover that
>programming langauges don't matter that much and that programming
>enviroments (editors/debugers/documentation/libraries/IDE's) matter the most
>in the end when you want to improve "productivity". The Lisp machines of the
>past had excellent programming enviroments. C++ today has the edge because
>of market forces. In general a fancy enough programming environment can make
>up for lots of langauge defects.
I couldn't DISagree more.
Give me a nice programming langage with some basic debugging
facilities, in preference to a crap programming language and infinite
GUI/application builders with fancy icons, buttons, generators and
tracers.
For example, no amount of fancy front ends will ever gloss over the
slow edit/compile/debug cycle, compared to an interactive language
where I can type and see the result.
--
---------------------------------------------------------------
| Chris Bitmead.....................................9690 5727 |
| ·············@Alcatel.com.au............................... |
---------------------------------------------------------------
"Simply drag your mother in law's mobile phone number from the
Address Book to the Laser Satellite icon, and the Targeting
Wizard will locate her. Then follow the onscreen prompts for
gigawattage and dispersion pattern..."
> You can't win with language bigots. I was really enthusiastic about
> Abuse until it was pointed out that I had more graphically complex
> games with smoother animation and better performance rates on an 8MHz
> 68000 way back in 1987.
This is irrelevant. If you look at some of the excellent games that
were available for the 4kb VIC-20 machine, we all should be ashamed.
Did you know that you can now run the genuine arcade games written for
the 68000 assembler, in a 68000 *simulator* on a 486 at full speed?
So, if you want to write all your code in assembler go ahead. For me,
I'm forced to develop C++ programs which are 40Meg binaries. Believe
me, Lisp would do far better.
--
---------------------------------------------------------------
| Chris Bitmead.....................................9690 5727 |
| ·············@Alcatel.com.au............................... |
---------------------------------------------------------------
The fact that it works is immaterial.
-- L. Ogborn
In article <··············@galapagos.cse.psu.edu> ········@galapagos.cse.psu.edu.NO-SPAM (Scott Schwartz) writes:
>| Okay, open challenge from me:
>| --- How ABOUT some kind of GUI interface standard for Lisp. ---
>
>Tk.
>
>Tk is widely deployed, easy to use, and well engineered. The easiest
>(hence best) solution is to simply call the Tk library from lisp.
You've missed the whole point. The discussion is *interface standards*
not gui library standards. There are lots of good gui libraries, and
anyone can build an interface. The thing needed is a standard
interface. Whether it is Tk, or Motif or whatever underneath is
irrelevent.
--
---------------------------------------------------------------
| Chris Bitmead.....................................9690 5727 |
| ·············@Alcatel.com.au............................... |
---------------------------------------------------------------
The fact that it works is immaterial.
-- L. Ogborn
In article <·············@acm.org> Sin-Yaw Wang <······@acm.org> writes:
] Listen, "The more natural the syntax, the more productive the
] engineers." Do argue on this point. Argue on whether Lisp is more
] natural.
I'm having trouble locating the piece in CACM which quite persuasively
argued that "natural" is no more than a synonym for "familiar". Can
anyone supply a pointer? I think it would at least get this argument
going, so far no one has presented any evidence on either side.
Personally, I can accept that there may be such a thing as "natural"
for certain responses in infants, but the notion that the responses
of adult engineers to different programming languages is based on
anything but learned responses is pretty far fetched.
--
David Fox http://www.cat.nyu.edu/fox xoF divaD
NYU Media Research Lab ···@cat.nyu.edu baL hcraeseR aideM UYN
Once again in this thread we come to the wrong notion that "Lisp
Prefix SYntax" is bad. Fine.
However, Common Lisp has a very nice package to do infix expressions.
It can be found in the CMU AI.Repository, was written by Saint Mark
Kantrowitz and it serves to silence all the detractors using the
"syntax argument" against (Common) Lisp. :)
Happy Lisping
--
Marco Antoniotti - Resistente Umano
* I wrote:
> One of my greatest frustrations as a system administrator is seeing
> the awful encroachment of Windows machines in professional
> environments.
I should have been more specific here as several people have pointed
out in mail: I meant windows 3.1 or 95, specifically *not* NT which
seems to be admirably stable (the HW problems remain of course if you
buy domestic machines). (and this is 0 to do with lisp or scheme, so
I'll shut up now!)
--tim
In article <···················@naggum.no> Erik Naggum <····@naggum.no> writes:
> * Ola Rinta-Koski
> | I used to program in Common Lisp, and hence CLOS. One thing which
> | bothered me was the apparent lack of information hiding in using classes
> | and methods.
>
> why do you want information hiding in the first place?
I find it convenient to be able to see from the declaration which
methods and slots are to be available to other classes and which are
internal to the class, and even more importantly that I won't
accidentally (or that someone using my class won't be tempted to) use
internal parts where I shouldn't. In my opinion the environment should
help me attain that goal.
I suppose there is a good reason why CLOS does not have information
hiding (or if it has, does things differently from, say, C++). I just
never came across that reason.
* Ola Rinta-Koski
| I find it convenient to be able to see from the declaration which methods
| and slots are to be available to other classes and which are internal to
| the class, and even more importantly that I won't accidentally (or that
| someone using my class won't be tempted to) use internal parts where I
| shouldn't.
the package system should be able to separate the externally visible from
the internal methods and the accessor functions publish the accessability
for slots, don't they? a class in CLOS doesn't contain its methods, so the
class cannot hide them, either. in effect, a class in C++ is like a
package as far as the accessibility of symbols are concerned.
| I suppose there is a good reason why CLOS does not have information
| hiding (or if it has, does things differently from, say, C++). I just
| never came across that reason.
the purported reasons for having "information hiding" in the first place
have actually eluded me all these years. the "friend" concept in C++ tells
me that its information hiding is at a much too fine granularity, too.
I don't know what the right level of information hiding would be, but I
"grew up" with Simula (at the U of Oslo), and I still think information
hiding is the least useful aspect of object-oriented programming. I think
"black box" pertains to the user of a system, not that it is an intrinsic
quality of the system itself.
actually, the more I think about this information hiding stuff, the more I
get the feeling that it's most suitable to ex-post-facto-programming: after
you have done all your design work, learned all there is to learn about the
problem domain, you or somebody else sits down to code it all to a defined
specification. this is not a useful model for me, since I learn about the
problem while I solve it and frequently revise my opinion on the design and
the implementation. (I think the same is true for _any_ creative work, and
it's much more important to me to be able to explore and learn than just to
code a solution. it could be that C++ is not creative work -- that the
creative part should precede coding -- but I don't think that is a good
approach to programming, at least not for me.)
I have never felt the need for information hiding, and it's always been in
my way, but I'd like to hear of cases where it has been invaluable. I'm
sure this stuff isn't _all_ drummed up by marketing boys. :)
#\Erik
--
if you think big enough, you never have to do it
From: John R. "Bob" Bane
Subject: Re: CLOS and information hiding
Date:
Message-ID: <5f49r0$fh0@tove.cs.umd.edu>
In article <··············@pelle.som.fi> ···············@iki.fi (Ola Rinta-Koski) writes:
>
> I suppose there is a good reason why CLOS does not have information
>hiding (or if it has, does things differently from, say, C++). I just
>never came across that reason.
I believe it's a consequence of the MOP. By default, the insides of all
classes, methods, and objects are visible because the MOP uses the same
primitives used by programmers to allow extension of the core CLOS.
You could have information hiding in CLOS by using a little discipline:
* Define reader/writer/accessors for your slots, and don't use slot-value.
* Define a package for each of your classes, and only export the accessors
and other method names you want to be public.
Granted, to do this right you'd need a little environmental support, like
macros to automatically create the packages and ensure they shared and
exported the right symbols, and your own versions of things like with-slots
that enforced the hiding, but this is at least possible in principle.
--
Internet: ····@tove.cs.umd.edu
Voice: 301-352-5617
···············@iki.fi (Ola Rinta-Koski) writes:
>In article <···················@naggum.no> Erik Naggum <····@naggum.no> writes:
>> * Ola Rinta-Koski
>> | I used to program in Common Lisp, and hence CLOS. One thing which
>> | bothered me was the apparent lack of information hiding in using classes
>> | and methods.
>>
>> why do you want information hiding in the first place?
[I took the freedom to change the sequence of your paragraphs]
> I suppose there is a good reason why CLOS does not have information
>hiding (or if it has, does things differently from, say, C++). I just
>never came across that reason.
One reason for "public" slots in CLOS, besides the others pointed out
by other posters are probably multimethods. When defining
multimethods, it is not that obvious which slots you want to access
from which object or class. You need to specify them to use them in
multimethods. A mechanism to determine which slots you are allowed to
use and which not on the base of the classes you specialize you
methods on is imaginable. But people obviously thought it is not worth
the effort, a complication of the language and the implementation.
> I find it convenient to be able to see from the declaration which
>methods and slots are to be available to other classes and which are
>internal to the class, and even more importantly that I won't
>accidentally (or that someone using my class won't be tempted to) use
>internal parts where I shouldn't. In my opinion the environment should
>help me attain that goal.
In Common Lisp, you get information hiding only at a package level. In
practice, this means first of all that you can't hide details of one
class to other classes in the same package, but you can hide details
from users of this package. In my opinion, that serves the goal
sufficiently.
Of course, information-hiding at a finer-graded level is useful for
many people's thinking. But CLOS is a dynamically typed language and I
think before you ask for more security information-hiding wise, you
would need a statically typed language first. The number of errors you
avoid by C++ information hiding, but not by Lisp package hinding is
probably neglectable to the number of type errors.
Maybe my view is too narrow, but when I want detailed
information-hiding to avoid unintended use of my libraries, I probably
want static type checking, too. Of course, I mix two different issues
here (ensuring "right" usage of code versus programming style), but in
practice I thing these two are quite related, because both are on the
same side of "secure/comlex-vs-flexible/simple" programming language
design.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
···············@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
In article <··············@pelle.som.fi>,
Ola Rinta-Koski <···············@iki.fi> wrote:
> I suppose there is a good reason why CLOS does not have information
>hiding (or if it has, does things differently from, say, C++). I just
>never came across that reason.
The philosophy of Common Lisp (and most other Lisp dialects) is not to
restrict the programmer. However, it's generally easy to tell from the
code whether you're making appropriate use of abstractions -- calls to
functions like SLOT-VALUE and EVAL are pretty easy to spot. And
non-exported symbols can be accessed using '::' notation.
Although C also has a very permissive philosophy, it combines this with
lots of low-level facilities that make it extremely easy to hang yourself.
Common Lisp, on the other hand, provides lots of high-level features and no
machine-level interfaces (although many implementations have extensions
that let you access machine words directly -- again, use of these functions
is quite visible).
--
Barry Margolin
BBN Corporation, Cambridge, MA
······@bbnplanet.com
(BBN customers, call (800) 632-7638 option 1 for support)
BTW. In my previous posting I was ignoring the semantic implications
of public/protected/private declarations of C++.
--
Marco Antoniotti - Resistente Umano
===============================================================================
···············@iki.fi (Ola Rinta-Koski) writes:
>
> In article <················@naggum.no> Erik Naggum <····@naggum.no> writes:
> > the simpler aspects of CLOS was shown to me by a friend not long ago
>
> Which reminds me: I used to program in Common Lisp, and hence CLOS.
> One thing which bothered me was the apparent lack of information
> hiding in using classes and methods. Did I just not understand the way
> to do it, or is the way somewhat non-obvious? I may have been too set
> in thinking in terms of public and private parts in class declarations
> like in C++; even so, I would like to know...
Very roughly (and I know this is a flame bait :) ) In C++ you really
mix the problems of "information hiding" with those of "OO
programming". I.e. you really use classes for both purposes. In CL
you have two separate mechanisms for doing that: packages and CLOS.
If you define
(in-package "THE-CLASS-PACKAGE")
(export '(the-class slot1-in-the-class))
(defclass the-class ()
((slot1 :accessor slot1-in-the-class)
(slot2 :accessor the-second-non-visible-slot)
))
You have effectively hidden 'slot2' from use outside "THE-CLASS-PACKAGE".
Cheers
--
Marco Antoniotti - Resistente Umano
===============================================================================
International Computer Science Institute | ·······@icsi.berkeley.edu
1947 Center STR, Suite 600 | tel. +1 (510) 643 9153
Berkeley, CA, 94704-1198, USA | +1 (510) 642 4274 x149
===============================================================================
...it is simplicity that is difficult to make.
...e` la semplicita` che e` difficile a farsi.
Bertholdt Brecht
From: Raymond Toy
Subject: Re: CLOS and information hiding (was Re: Why lisp failed in the marketplace)
Date:
Message-ID: <4nhgix2552.fsf@rtp.ericsson.se>
>>>>> "Marco" == Marco Antoniotti <·······@crawdad.icsi.berkeley.edu> writes:
Marco> ···············@iki.fi (Ola Rinta-Koski) writes:
Marco> both purposes. In CL you have two separate mechanisms for
Marco> doing that: packages and CLOS.
Marco> If you define
Marco> (in-package "THE-CLASS-PACKAGE")
Marco> (export '(the-class slot1-in-the-class))
Marco> (defclass the-class () ((slot1 :accessor
Marco> slot1-in-the-class) (slot2 :accessor
Marco> the-second-non-visible-slot) ))
Marco> You have effectively hidden 'slot2' from use outside
Marco> "THE-CLASS-PACKAGE".
As an additional note, I believe Graham's "ANSI Common Lisp" book shows
how to make slot1 and slot2 completely hidden so that the only way to get
to them is through the accessor. The key is to make the slot names
gensym'ed or something like that. I don't have the book with me, but
you may want to look at it. It's one of the notes in the CLOS chapter
of the book, I think.
Ray
From: Ola Rinta-Koski
Subject: CLOS and information hiding (was Re: Why lisp failed in the marketplace)
Date:
Message-ID: <gmpvxmeacq.fsf_-_@pelle.som.fi>
In article <················@naggum.no> Erik Naggum <····@naggum.no> writes:
> the simpler aspects of CLOS was shown to me by a friend not long ago
Which reminds me: I used to program in Common Lisp, and hence CLOS.
One thing which bothered me was the apparent lack of information
hiding in using classes and methods. Did I just not understand the way
to do it, or is the way somewhat non-obvious? I may have been too set
in thinking in terms of public and private parts in class declarations
like in C++; even so, I would like to know...
* Ola Rinta-Koski
| I used to program in Common Lisp, and hence CLOS. One thing which
| bothered me was the apparent lack of information hiding in using classes
| and methods.
why do you want information hiding in the first place?
#\Erik
--
if you think big enough, you never have to do it
In article <················@naggum.no> Erik Naggum <····@naggum.no> writes:
> the package system should be able to separate the externally visible from
> the internal methods and the accessor functions publish the accessability
> for slots, don't they?
So am I supposed to put every class in its own package, and do the
necessary imports and exports, if I want to achieve the effect public
and private parts have in C++?
> actually, the more I think about this information hiding stuff, the more I
> get the feeling that it's most suitable to ex-post-facto-programming: after
> you have done all your design work, learned all there is to learn about the
> problem domain, you or somebody else sits down to code it all to a defined
> specification.
I like to think more in terms of publishing an interface.
> I have never felt the need for information hiding, and it's always been in
> my way, but I'd like to hear of cases where it has been invaluable.
Theoretically it perhaps should not play a very large part. However,
my experience has unfortunately been that if it's possible to bypass a
published interface and get at the internals, then someone will think
of a reason, perhaps even perfectly valid (at least to them), to do
so. It's at the point where someone else has to maintain that code
when something breaks. Theoretically good programming practice would
ensure there wouldn't be many problems. In practice, it seldom does,
because all too often there is none.
And like I said, maybe I just haven't understood how to achieve
similar or better results in CLOS. Certainly none of the other
programmers in the project had. Not everyone who programs in Common
Lisp, or of course any other language, is a fully-qualified wizard.
From: Joerg Hoehle
Subject: Re: CLOS and information hiding
Date:
Message-ID: <5g1h40$frt@omega.gmd.de>
Ola Rinta-Koski (···············@iki.fi) wrote:
: In article <················@naggum.no> Erik Naggum <····@naggum.no> writes:
: > the package system should be able to separate the externally visible from
: > the internal methods and the accessor functions publish the accessability
: > for slots, don't they?
: So am I supposed to put every class in its own package, and do the
: necessary imports and exports, if I want to achieve the effect public
: and private parts have in C++?
No, at most two. Follow the example of the "LISP" or "COMMON-LISP"
package: EXPORT all things that are public. Going further, you could
define a private package ("SYSTEM") where your methods etc. would be,
just exporting the public names to the "LISP"-like public package,
which itself would then contain the exported symbols only. Isn't that
protection enough?
Jo"rg Ho"hle.
············@gmd.de http://zeus.gmd.de/~hoehle/amiga-clisp.html
In article <················@naggum.no> Erik Naggum <····@naggum.no> writes:
[...]
for slots, don't they? a class in CLOS doesn't contain its methods, so the
class cannot hide them, either. in effect, a class in C++ is like a
[...]
It should perhaps be noted that CLOS' generic functions dispatch on
the type of all arguments. Thus, not only a class does not contain
`its' methods, but methods do not belong to a particular class.
Multimethods / generic functions obviously do not combine well with
information hiding as seen in message passing OO systems (incl. C++).
rthappe
In article <··········@tove.cs.umd.edu> ····@cs.umd.edu (John R. "Bob" Bane) writes:
>> In article <··············@pelle.som.fi> ···············@iki.fi (Ola Rinta-Koski) writes:
>> I suppose there is a good reason why CLOS does not have information hiding
>> (or if it has, does things differently from, say, C++). I just never came
>> across that reason.
> You could have information hiding in CLOS by using a little discipline:
> * Define reader/writer/accessors for your slots, and don't use slot-value.
> * Define a package for each of your classes, and only export the accessors
> and other method names you want to be public.
> Granted, to do this right you'd need a little environmental support, like
> macros to automatically create the packages and ensure they shared and
> exported the right symbols, and your own versions of things like with-slots
> that enforced the hiding, but this is at least possible in principle.
I think there is an article in Journal of Object Oriented Programming (must
be a 1994-96 edition) , that discusses info hiding in CLOS. I recall that
the use of packages was a key feature of the scheme.
Hopefully this will give you some hints/ptrs to more info.
Regards,
Steven Perryman
········@cpd.ntc.nokia.com
In article <...> ···············@iki.fi (Ola Rinta-Koski) writes:
> In article <...> Erik Naggum <····@naggum.no> writes:
>> * Ola Rinta-Koski
>> | I used to program in Common Lisp, and hence CLOS. One thing which
>> | bothered me was the apparent lack of information hiding in using classes
>> | and methods.
>>
>> why do you want information hiding in the first place?
>
> I find it convenient to be able to see from the declaration which
> methods and slots are to be available to other classes and which are
> internal to the class, and even more importantly that I won't
> accidentally (or that someone using my class won't be tempted to) use
> internal parts where I shouldn't. In my opinion the environment should
> help me attain that goal.
As far as slots go, one convention for implementing hiding would be to
only specify accessors and readers for those slots that are meant to be
public. The private slots could then be accessed internally using
slot-value of the with-slots macro. This isn't quite as heavily
enforced as in C++, but see below.
As far as methods go, they are tougher since they don't really belong to
any particular class (as another poster noted).
> I suppose there is a good reason why CLOS does not have information
> hiding (or if it has, does things differently from, say, C++). I just
> never came across that reason.
There are at least two reasons that I can think of. First, the lisp
programming tradition has been to allow you to do most anything and rely
on the presence of good programmers and good programming practice to
avoid doing bad things. (This could be called the "enough rope
philosophy"). In other words, although you can easily subvert attempts
to have hidden information, it is expected that a programmer would not
do such subversion in most cases. The power is there to allow it in the
rare (unforseen) instances where it might be necessary. In contrast,
many other languages force you to either revise the public interface or
forget about sharing the code and reimplement the functionality.
Lisp assumes that you don't need to protect your system from the
programmers. (Whether this is a wise idea or not is perhaps
debatable).
The other reason, and the one with a better theoretical foundation, is
that Lisp is a highly introspective language. You can find out a lot
about the system by using standard Lisp function calls. For example,
you can discover the names of a class' slots starting with an instance
of the class. There is no standard way to do this in C++, but a lot of
systems have implemented their own meta-information structures for C++
in order to enable what is built in to CLOS.
Besides, I don't think that C++ itself is fundamentally better at
information hiding than CLOS. By using pointers, knowing how the
compiler lays out storage for classes and method vtables, you can
subvert information hiding in C++ as well. It just takes a lot more
work. I suppose that one could call that an advantage.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
In article <··············@rtp.ericsson.se> Raymond Toy
<···@rtp.ericsson.se> writes:
[...]
As an additional note, I believe Graham's "ANSI Common Lisp" book shows
how to make slot1 and slot2 completely hidden so that the only way to get
to them is through the accessor. The key is to make the slot names
gensym'ed or something like that. I don't have the book with me, but
you may want to look at it. It's one of the notes in the CLOS chapter
of the book, I think.
Unintern the slot name after the definitions that refer to the slot,
or use uninterned symbols as slot names. The latter option is a bit
tricky, since all references to the uninterned symbol should occur
within the same expression; e.g. you can wrap a PROGN around the
definitions. Cf. P.Graham, ANSI CL, p.191 and note 191.
rthappe
···············@iki.fi (Ola Rinta-Koski) writes:
>
> In article <···················@naggum.no> Erik Naggum <····@naggum.no> writes:
>
>
> I suppose there is a good reason why CLOS does not have information
> hiding (or if it has, does things differently from, say, C++). I just
> never came across that reason.
Common Lisp (therefore CLOS) has a form of information hiding. The
fact that is different from the one provided by C/C++ is obviously a
good reson by itself to deem it "better" :) :) :) <- THESE ARE 3 SMILEYS!
--
Marco Antoniotti - Resistente Umano
===============================================================================
In article <·····················@wavehh.hanse.de> ········@wavehh.hanse.de (Martin Cracauer) writes:
> In Common Lisp, you get information hiding only at a package level. In
> practice, this means first of all that you can't hide details of one
> class to other classes in the same package, but you can hide details
> from users of this package. In my opinion, that serves the goal
> sufficiently.
It probably does. Apparently our application would have benefited
from more liberal use of packages.
> Of course, information-hiding at a finer-graded level is useful for
> many people's thinking. But CLOS is a dynamically typed language and I
> think before you ask for more security information-hiding wise, you
> would need a statically typed language first.
One of, if not the strongest asset of Lisp in my opinion is dynamic
typing. Another is that the table has already been laid out for you,
the need for reinventing the wheel is not all that large. These things
are beautifully combined in concepts such as lists or sets, which in
my experience appear in each and every program and are a pain to
implement in a C family language, where the pointer juggling
practically ensures you're going to shoot at least a couple of your
toes off. However, I don't think this has necessarily anything to do
with the idea of hiding implementation details from the class or
package user.
> The number of errors you avoid by C++ information hiding, but not by
> Lisp package hinding is probably neglectable to the number of type
> errors.
Probably. I just happen to like the clarity of a C++ class
declaration. It could be better, for instance if you could defer the
declaration of the private part until later.
> Maybe my view is too narrow, but when I want detailed
> information-hiding to avoid unintended use of my libraries, I probably
> want static type checking, too.
In some cases, yes. I guess this is largely a matter of style.
It is possible to use any language and have impeccable style. It's
just easier if the language supports it, especially if it happens to
support it in a way you can relate to.
In article <··············@pelle.som.fi>,
···············@iki.fi (Ola Rinta-Koski) writes:
> In article <·····················@wavehh.hanse.de> ········@wavehh.hanse.de (Martin Cracauer) writes:
>> The number of errors you avoid by C++ information hiding, but not by
>> Lisp package hinding is probably neglectable to the number of type
>> errors.
>
> Probably. I just happen to like the clarity of a C++ class
> declaration. It could be better, for instance if you could defer the
> declaration of the private part until later.
One of the things that always annoyed me about C++ class declarations was the
requirement to include all of the private data and member functions in the
public interface spec. (Yes, I understand why it's there.) It just seems wrong
to be publicly advertising your private parts.
Mike McDonald
·······@engr.sgi.com
* Mike McDonald
| One of the things that always annoyed me about C++ class declarations was
| the requirement to include all of the private data and member functions
| in the public interface spec. (Yes, I understand why it's there.) It
| just seems wrong to be publicly advertising your private parts.
this has annoyed Bjarne Stroustrup, as well. see his book The Design and
Evolution of C++. consider that published interfaces can be inherited, but
private parts cannot. it would make sense to inherit from a class that had
the published interface into a class with the private parts necessary to
implement it. few do this, however.
#\Erik
--
if you think big enough, you never have to do it
In article <··············@galapagos.cse.psu.edu> ········@galapagos.cse.psu.edu.NO-SPAM (Scott Schwartz) writes:
Teunis Peters <········@comfo.ca> writes:
| Okay, open challenge from me:
| --- How ABOUT some kind of GUI interface standard for Lisp. ---
Tk.
Tk is widely deployed, easy to use, and well engineered. The easiest
(hence best) solution is to simply call the Tk library from lisp.
Meanwhile, gcl has a wierd interface to Tk (they run 'wish', translata
Lisp commands to 'tcl' commands and use pipes for the interprocess
communications). There seem to be a 'stand-alone' Tk which does not
depend on tcl anymore...
--
Dmitry Zinoviev, Research Assistant
--------------------------------------------------------
For in much wisdom is much grief: and he that increaseth
knowledge increaseth sorrow. Eccl. 1:18
* Martin Cracauer wrote:
> One reason for "public" slots in CLOS, besides the others pointed out
> by other posters are probably multimethods. When defining
> multimethods, it is not that obvious which slots you want to access
> from which object or class. You need to specify them to use them in
> multimethods. A mechanism to determine which slots you are allowed to
> use and which not on the base of the classes you specialize you
> methods on is imaginable. But people obviously thought it is not worth
> the effort, a complication of the language and the implementation.
I don't think I understand this. I define multi-methods, but if they
are not part of the `implementation of a class' (whatever that might
mean!) they use the documented accessors to get at the information,
rather than getting at the slots. Could you clarify?
--tim
> > The only way to do touch the essential difficulties of programming is to
> > reduce the complexity of programming and the only way to touch that by
> > changing programming languages is by choosing a language that is more
> > specific to the problem to be solved. For example, you can be orders of
> > magnitude more efficient coding database applications in a database
> > language (like XBase) than you can be when coding them in a
> > general-purpose programming langauge like LISP or Scheme.
> I've heard this argument before, and it is amazing to me that no one
> wants to challenge it. Yes, it is true that if I want to add one
> column of numbers, it is more 'productive' to use Excel (a spreadsheet
> program) than to use Lisp (but not by much). What boggles my mind,
> though, are these _huge_ Excel macro packages that must have taken
> 10X to 100X times as long to program in Excel as in Lisp, and run
> 100X to 1000X slower than Lisp.
I have addressed these issues in some papers I have written:
A universal scripting framework
http://www.ai.mit.edu/~shivers/citations.html#ll
A Scheme shell
http://www.ai.mit.edu/~shivers/citations.html#scsh
It is possible to have your cake and eat it, too.
-Olin
* Cyber Surfer wrote:
> Would it be fair for me to refer to cruise missiles as a real world
> application of AI? It's one that few people will have failed to have
> heard of, and yet guiding a missile at street level at high speed
> could easily be described as AI. It also sounds pretty damn "real
> world" to me. Then there's the funding of AI...
Somewhat at a tangent: I just went to an exhibition of robotics stuff,
and at least some of the robots on show were running on-board Common
Lisp systems. Perhaps it's not quite real-world but it's a good
example of Lisp being used for the kind of application that I would
naively have associated with embedded microcontrollers programmed in
assembler...
--tim
With a mighty <···············@staffa.aiai.ed.ac.uk>,
···@aiai.ed.ac.uk uttered these wise words...
> Somewhat at a tangent: I just went to an exhibition of robotics stuff,
> and at least some of the robots on show were running on-board Common
> Lisp systems. Perhaps it's not quite real-world but it's a good
> example of Lisp being used for the kind of application that I would
> naively have associated with embedded microcontrollers programmed in
> assembler...
15 years ago, I'd have been suprised to find Forth being used on-
board, never mind Lisp. I wonder which CL it was?
I doubt that there's an on-board Lisp controlling a cruise missile,
but I wouldn't be suprised if Lisp was used at some point in the
development of the software. Still, you never know. That Scheme
to C compiler makes me wonder. I just have a feeling that Ada would be
a more likely choice (for completely non-technical reasons, of couse).
Here's something else at a tangent: I'm a little uncertain of the
details, as most of the info about this Lisp machine has come from
magazines, but I've read that Linn Hifi were the people who wanted the
Rekursiv, apparently to replace their VAXes. Alas, I'd told that it
never made it out the door. It sounded like Linn had some pretty real
world apps for it, probably using Lisp (or Smalltalk, Prolog, etc).
I guess their timing was wrong.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
Cyber Surfer <············@nospam.wildcard.demon.co.uk> wrote:
>I doubt that there's an on-board Lisp controlling a cruise missile,
I heard rumors back in the late 80's/early '90s of a Lisp system being
used for target acquisition in some U.S. Navy torpedo model. Can
anyone confirm or deny?
--David Gadbois
·······@cyc.com (David Gadbois) writes:
>Cyber Surfer <············@nospam.wildcard.demon.co.uk> wrote:
>>I doubt that there's an on-board Lisp controlling a cruise missile,
>I heard rumors back in the late 80's/early '90s of a Lisp system being
>used for target acquisition in some U.S. Navy torpedo model. Can
>anyone confirm or deny?
I remember discussions about putting TIs then new Lisp Chip into cruise
missiles. I remember thinking about the chip: "They're going to blow it
up??"
--
Will Hartung - Rancho Santa Margarita. It's a dry heat. ······@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck
Cyber Surfer <············@nospam.wildcard.demon.co.uk> wrote:
>I doubt that there's an on-board Lisp controlling a cruise missile,
Harlequin Common Lisp will be used to control NASA's New Millennium Deep
Space 1 spacecraft in 1998. It's not a cruise missile, but it does have
solar-electric ion propulsion, which is pretty cool.
E.
--
Erann Gat ···@jpl.nasa.gov ···@power.net
With a mighty <················@milo.jpl.nasa.gov>,
···@jpl.nasa.gov uttered these wise words...
> Harlequin Common Lisp will be used to control NASA's New Millennium Deep
> Space 1 spacecraft in 1998. It's not a cruise missile, but it does have
> solar-electric ion propulsion, which is pretty cool.
Excellent. Do you have a URL for more information on this? I'd like to
read it (of course), and add the link to my homepage.
Thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
In article <·························@news.demon.co.uk>,
············@nospam.wildcard.demon.co.uk (Cyber Surfer) wrote:
> > Harlequin Common Lisp will be used to control NASA's New Millennium Deep
> > Space 1 spacecraft in 1998. It's not a cruise missile, but it does have
> > solar-electric ion propulsion, which is pretty cool.
>
> Excellent. Do you have a URL for more information on this? I'd like to
> read it (of course), and add the link to my homepage.
Alas no. We have been too frantically busy just getting the system to
run to make a web page. There are some papers about some aspects of the
work that you can access through my home page
(www-aig.jpl.nasa.gov/home/gat)
but no comprehensive collection yet. But we are going to try to put
something together soon. Check back in a few weeks.
E.
--
Erann Gat ···@jpl.nasa.gov ···@power.net
On Wed, 26 Mar 1997 10:40:17 -0700, ···@jpl.nasa.gov (Erann Gat) wrote:
> In article <·························@news.demon.co.uk>,
> ············@nospam.wildcard.demon.co.uk (Cyber Surfer) wrote:
>
> > > Harlequin Common Lisp will be used to control NASA's New Millennium Deep
> > > Space 1 spacecraft in 1998. It's not a cruise missile, but it does have
> > > solar-electric ion propulsion, which is pretty cool.
> >
> > Excellent. Do you have a URL for more information on this? I'd like to
> > read it (of course), and add the link to my homepage.
>
> Alas no. We have been too frantically busy just getting the system to
> run to make a web page. There are some papers about some aspects of the
> work that you can access through my home page
> (www-aig.jpl.nasa.gov/home/gat)
> but no comprehensive collection yet. But we are going to try to put
> something together soon. Check back in a few weeks.
Harlequin's symbolic processing newsletter, "The Works", carried a brief item
entitled "LispWorks helps probe the secrets of the galaxy" a while back:
http://www.harlequin.com/full/products/sp/theworks.html#lisp
__Jason
With a mighty <··················@newshost>,
·····@harlequin.co.uk uttered these wise words...
> Harlequin's symbolic processing newsletter, "The Works", carried a brief item
> entitled "LispWorks helps probe the secrets of the galaxy" a while back:
>
> http://www.harlequin.com/full/products/sp/theworks.html#lisp
This is exactly what I was looking for.
Many thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
··@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
| But basically, Limbo is astonishingly like what you'd get if a crazed
| C programmer read a couple of books about CSP and Lisp implementation,
| understood _some_ of what he was missing, and went for it.
I rather suspect that the manifestly not crazed Limbo designers
understand all about Lisp, and then some. Limbo is the most recent in
a series of concurrent langauges, one of which ("newsqueak") was a
pure functional language.
········@galapagos.cse.psu.edu.NO-SPAM (Scott Schwartz) writes:
>··@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
>| But basically, Limbo is astonishingly like what you'd get if a crazed
>| C programmer read a couple of books about CSP and Lisp implementation,
>| understood _some_ of what he was missing, and went for it.
>I rather suspect that the manifestly not crazed Limbo designers
>understand all about Lisp, and then some. Limbo is the most recent in
>a series of concurrent langauges, one of which ("newsqueak") was a
>pure functional language.
I did not say that the Limbo designers were crazed.
I said that what they *produced* is *LIKE* what you'd get from
a crazed C programmer.
Given
- the heavy use of { ... } when Algol 68/Modula/Ada/F77-like
<keyword> ... end <keyword> syntax is supposed to have been proved
to be less error-prone (anyone got a reference either way?)
- the absence of any Boolean type (int is used instead)
- the absence of any character type (int is used instead; there _is_
a string type, but there is _not_ a character type)
- the absence of nested functions
- the absence of abstraction ('adt' is a keyword in the language, but
it really means 'record with attached functions', no abstraction
actually existing)
- interfaces done by textual inclusion (heck, even Fortran has modules
+ "use module") rather than by some mechanism that induces a necessary
connection between what the compiler sees when compiling the client
and what the compiler sees when compiling the implementation
- the absence of any form of generics/templates/polymorphism
[Someone told me by E-mail that there is no way to define a general
sorting routine in Limbo, and on checking the manual I believe this
to be true.]
- not only can assignments be embedded in expressions, so if I am reading
the manual correctly can declarations be.
..................... x := e .......................
declares x to have the type and initial value of e, and it seems this
can go anywhere a general expression can go.
I think that it is very fair to say that in at least these respects
it resembles what a C programmer who has come to love his chains would
chose. I also believe that specifying classic reference counted
garbage collection (there are two kinds of pointers: 'ref T' and
'cyclic ref T'; the first kind are counted and may not produce cycles,
the second kind aren't and may) in a multi-threaded language with no
syntactic cues as to which variables or objects are shared may not
have been a good idea: it would appear to require locking around
_every_ 'ref T' assignment. I don't know how Limbo actually implements
reference counting; it _may_ be that they have a smart implementation
which reduces the locking overheads.
In short, there are restrictions in Limbo which appear to be there
for no other reason than that they were in C.
--
Will maintain COBOL for money.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
In article <··········@news3.texas.net> ·······@cyc.com (David Gadbois) writes:
Cyber Surfer <············@nospam.wildcard.demon.co.uk> wrote:
>I doubt that there's an on-board Lisp controlling a cruise missile,
I heard rumors back in the late 80's/early '90s of a Lisp system being
used for target acquisition in some U.S. Navy torpedo model. Can
anyone confirm or deny?
Does this mean that they now have torpedoes that can only destroy Lisp machines
- frightening :-) Of course you have to persuade the enemy to buy them first!
John
--
***********************Dummy .sig file******************************************