Why lisp failed in the marketplace
George J. Carrette
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
Henry Baker
In article <01bc13dc$cfaa2b20$0f02...@gjchome.nis.newscorp.com>, "George
J. Carrette" <g...@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.
Jeffrey B. Siegal
In article <hbaker-1202...@10.0.2.1>, hba...@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
Rainer Joswig
> In article <01bc13dc$cfaa2b20$0f02...@gjchome.nis.newscorp.com>, "George
> J. Carrette" <g...@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.
Barry Margolin
In article <joswig-ya0231800...@news.lavielle.com>,
Rainer Joswig <jos...@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
bar...@bbnplanet.com
(BBN customers, call (800) 632-7638 option 1 for support)
William Paul Vrotney
In article <5e09eo$j...@tools.bbnplanet.com> bar...@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 - vro...@netcom.com
Henry Baker
In article <jbs-130297...@dial-sf1-5.iway.aimnet.com>,
j...@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...
Rainer Joswig
> 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
Jeffrey B. Siegal
In article <joswig-ya0231800...@news.lavielle.com>,
jos...@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.
Daniel Finster
In article <jbs-130297...@dial-sf1-5.iway.aimnet.com>, Jeffrey B. Siegal <j...@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
Rainer Joswig
In article <jbs-140297...@dial-sf1-23.iway.aimnet.com>,
j...@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
Sin-Yaw Wang
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, sin...@acm.org
http://www.concentric.net/~sinyaw/
William Paul Vrotney
In article <330512...@acm.org> Sin-Yaw Wang <sin...@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.
Teunis Peters
On Thu, 13 Feb 1997, Jeffrey B. Siegal wrote:
> In article <hbaker-1202...@10.0.2.1>, hba...@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!
Erik Naggum
* 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
Earl & Daniella Harris
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, sin...@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.
Erik Naggum
* 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.
Brian Harvey
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.
Henry Baker
> 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?
Cyber Surfer
With a mighty <joswig-ya0231800...@news.lavielle.com>,
jos...@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."
Lars Magne Ingebrigtsen
b...@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.)
la...@ifi.uio.no * Lars Ingebrigtsen
Cyber Surfer
With a mighty <30650066...@naggum.no>,
er...@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...
Cyber Surfer
With a mighty <5e4lm3$q...@agate.berkeley.edu>,
b...@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.
Will Hartung
Earl & Daniella Harris <esha...@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. vfr...@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck
Kevin Russell
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."
Erik Naggum
* 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.)
Alaric B. Williams
>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 : ala...@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>
Rainer Joswig
> 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.
Cyber Surfer
With a mighty <vfr750E5...@netcom.com>,
vfr...@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.
Cyber Surfer
With a mighty <30650480...@naggum.no>,
er...@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.
Jeffrey B. Siegal
> 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
In article <5e4lm3$q...@agate.berkeley.edu>, b...@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.
Erik Naggum
* 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.
Jim McDonald
Henry Baker (hba...@netcom.com) 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
Peter S. Housel
> #\Erik
> --
> my other car is a cdr
>
MY other CAR is a CADR. CDR isn't a CAR at all.
-Peter S. Housel- hou...@ms7.hinet.net
Cyber Surfer
With a mighty <3306493...@news.demon.co.uk>,
ala...@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.
Cyber Surfer
With a mighty <30651328...@naggum.no>,
er...@naggum.no wibbled into the void...
> _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.
Ideally, yes. In practice, this rarely happens. A lot of programmers
will learn "on the job". While they may fail to qualify as
"professional", by your definition, most people probably won't notice.
That doesn't mean that I'm disagreeing with you, just pointing out
that a great many others _might_. I gues nobody wants to admit that
they employ "unprofessional" programmers, dispite the evidence to the
contrary (bugs, crashes, etc).
I'd hesitate to call someone "unprofessional" for choosing C++, but
not because I believe C++ to adequate. No, I simply acknowledge the
necessity for programmers to work, the high degree of ignorance within
this industry, and the inability of every programmer to do something
about it. It might not be the programmers who are ignorant of the
failings of C++, but the managers.
Not that I'd like to excuse anyone for the folly of choosing C++. I
just note how hard it can be to convince non-programmers that C++ is
the _wrong_ choice, when so many (marketing) people claim otherwise.
The high availability of "C++ solutions" to common problems doesn't
help much, either.
Perhaps addressing those same problem domains in Lisp could help tip
the balance in favour of Lisp. I've already suggested adding support
for ActiveX to Lisps for Windows, which would give those Lisps the
same leverage as C++ - pick a component that does what you need, plug
it into your app, and most of the job has been done.
> | 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.
Did you not detect the irony in that statement? I guess not.
> 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?
Exactly. I totally agree with you.
> I want "programmer" to be a professional title, with all the expectations
> that come with it.
Same here. We're just heavily outnumbered. The demand for code seems
to "justify" the cowboy solutions, like C++. I'm totally disgusted by
what's available, but consider why these solutions are so popular.
They may not work well, but they _do_ work. Like the talking dog...
Sadly, that's "good enough" for most people. Esp if they have to pay
more for a better product. Given a choice, the bean counters will
choose a product that barely works, but is sold cheaper than anything
else. Being "professional" has nothing to do 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.
Lisp isn't a service, it's a tool. You might just as well demand to
license programming, like doctoring. I'd be happy if this were so, but
it's not. Instead, programmers are like car mechanics - who have a
very dodgy reputation in the country where I live. Nobody likes it,
but what do they do about it? So far, nothing like the fuss that gets
made when a doctor makes mistake.
So, I agree with you! Make programming a professional career, complete
with all the safeguards that apply to the medical profession. Then we
might see a few programmers in court, for negligence.
> 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"?
The answer to that is, unfortunately, no. This is a general problem.
As I said, it also applies to car mechanics - and cars have been known
to kill a few people. A computer can be just as deadly, if it's given
dangerous hardware to control, and then _trusted_. We're trusting the
car mechanic and the programmer of the car's software not to screw up.
> 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.
So, this has nothing to do with Lisp, specifically? A C++ is just as
available, perhaps more so as it might well cost less money. This is
about trusting someone in possesion of a tool, not the tool itself.
I'm not sure that Lisp is any more or less safe or dangerous than any
other programming language, in this respect. Lisp can help us avoid
certain kinds of bugs, but no language can prevent a careless
programmer from creating a bug.
This sounds like an argument for licensing the right call yourself a
professional programmer, and I have no problem with that. Remember me
saying that we were agreeing? I'm just unsure how we convince the
world that this is worth doing, tho I might start by suggesting that
everyone read the RISKS mailing list (digest in comp.risks).
> | 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.)
Thanks for clarifing your point of view. Please let me clarify _my_
point of view. I didn't say that "that if the consumer can't use those
languages himself, then nobody else should be allowed to write in
them, either." I'm simply interested in making quality tools available
to anyone who wants them, and reducing the level of ignorance about
such tools.
> 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.)
"Car mechanics - Don't let 'em touch your car!" Wouldn't it be great
if people followed this advise? Of course, it won't happen soon.
Instead, people will continue to grip and complain about shodding
work, and yet still go back for more.
Y'see, I agree with you, Erik! This is why I'd like to see a Lisp
targetted at the programmers who are currently using those shoddy
tools, like VC++ and VB. Unfortunately, that may mean creating a Lisp
that looks a little more like VC++ and VB, in the sense that it might
use a similar IDE. This is the approach that Borland took with Delphi,
but Pascal is barely any better than C++ or Basic. Imagine what we
could do with a "Visual Lisp"? The idea may seem ugly, but it could be
the way to get quality tools into the hands of these programmers.
However, the real problem is one of education. We have to convince
people that being professional is worth it, and _then_ offer Lisp as a
more professional tool for programming. What's the best way to do
this? That may be debatable, but I like the idea of just writing
software, creating apps, and then saying, "This is how I did it!" The
answer that I get is "That won't do, it costs too much", but perhaps
not everyone will be so unlucky. If you can avoid the bean counters,
or find a Lisp that competes with C++ in terms of the purchase price
(bean counters ignore the other costs, of course), then you may have a
chance of using Lisp to write Windows software, i.e. consumer apps.
Alternately, just use a Mac and write code in MCL.
Richard A. O'Keefe
Sin-Yaw Wang <sin...@acm.org> writes:
>Basically, a procedural language is more "natural" than a symbolic one.
Whoa there! Lisp *is* a procedural language!
There have been *lots* of languages that are *both* symbolic *and*
procedural. Lisp, Pop-2, SAIL, ..
>When I taught Scheme in school, it takes a good 2 weeks just to get the
>recursive part into their heads.
Well, when teacher X teaches subject Y to students Z, any difficulties
found *could* be due to
- Z being dumb
- Y being hard
- X being a poor teacher
- a heat wave that year
- various combinations of the above...
If the teacher thinks recursion is hard, the students will learn that
recursion is hard. If the teacher thinks recursion is no big deal,
and the students haven't been brainwashed by a bad teacher before,
the students will learn that recursion is no big deal.
Scheme isn't the only recursive language in the world, you know.
C has a "recursive part" too. So does PL/I. So does Fortran.
So does Java. Where are the people doom-crying Java because it
is recursive?
>If it is less natural, it is less productive, statistically speaking.
This is a mere assertion with no foundation whatsoever.
If you want to speak statistically, provide statistics.
Face it: programming is not a natural art. We don't expect everyone
to be a concert pianist. We don't expect everyone to be an Academy
painter. We don't expect everyone to master tensor calculus (which
isn't actually all that hard). If it comes to that, arguing soundly
is not natural, and many people never learn the art. Predicate
calculus is by *far* less natural than prefix syntax. There are
quite a few VSO human languages, where "is-greater X than Y" is the
way to go instead of the "unnatural" "X is-greater-than Y" (unnatural
for _them_). You cannot be a good programmer without understanding
the predicate calculus.
>Companies lose using a less productive tool.
>It is a Darwinian selective process.
Hmm. Experiments have shown C to be substantially less productive than
Ada. I would be thrilled to the very socks to hear that a Darwinian
selective process was eliminating C in favour of Ada.
What matters to a company is not its productivity but its profits.
This depends on
- the difficulty of the tasks being undertaking
- productivity
- price of labour
- what the product sells for
- size of market.
Productivity is only one of *many* factors. The continued survival of
C and C++ demonstrates conclusively that "naturalness" of a language
has very little to do with the survival of companies that use it.
*Connectivity* is more important than naturalness for many many programmers.
--
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.
Rainer Joswig
In article <Pine.LNX.3.91.97021...@sigil.wwe.net>, Teunis
Peters <snow...@comfo.ca> wrote:
> So, where do we start to make LISP a visible success?
Do work in some project that advances Lisp.
There are a lot of people in the Scheme and CL community
with interesting ideas/projects.
> 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].
What is VR? "Virtual Reality"?
> 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....
We already have enough Lisp implementations.
Better start using an existing one (for example CMU CL) and
work with that.
> I need information. I have NO access anywhere except online (am on
> welfare basically - not fun). Any pointers would be appreciated.
see http://www.lavielle.com/~joswig/lisp.html for a start. ;-)
The ALU will set up an interesting site soon (hopefully).
Rainer Joswig
Rainer Joswig
In article <MPG.d6ff3ba4...@news.demon.co.uk>,
cyber_...@wildcard.demon.co.uk (Cyber Surfer) wrote:
Cyber is it you? Really? I'm comparing this to some older
postings of yours.
> 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.
It was/is.
> I've noticed that a lot of experienced Windows people will criticise
> the MS "Bob" interface for being _too friendly_.
Bob was written in Lisp. ;-)
> > 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?
Newton at Apple
http://www.newton.apple.com/newton/newton.html
Newton Developer stuff at Apple
http://devworld.apple.com/dev/newton/
Newton Toolkit (Development system for the Newton)
http://devworld.apple.com/dev/newton/tools/ntk.html
Newton Programmer Documentation
http://devworld.apple.com/dev/newton/techinfo/docs.pdf.html
Newton OS 2.0 preview in Mobilis Magazine
http://www.volksware.com/mobilis/november.95/newton1.htm
Remember the inner workings of this OS should
be *very* familiar to Lisp users.
> 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.
Well for those who hunt for old pictures, I have put
a scan (not very good, but you get the idea) of someone
using a Lisp machine as a frontend to a Connection Machine cube
on my pages: http://www.lavielle.com/~joswig/cm+lispm.jpg .
> Now we should show what modern Lisp can do.
Some people already are trying this.
What is your contribution?
Rainer Joswig
In article <jbs-160297...@dial-sf1-6.iway.aimnet.com>,
j...@quiotix.com (Jeffrey B. Siegal) wrote:
> In article <joswig-ya0231800...@news.lavielle.com>,
> jos...@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.
Yeah, with a proprietary OS (Solaris) and proprietary software
(OpenWindows, SunView, NeWS, NIS+, ...). It was specialized
for running Unix/Solaris. I haven't seen that many other OS
on these machines being sold.
SUNs idea was to make a standard (bitmap display, disk, VM, network adapter)
workstation *relatively* cheap (the hardware that is).
Symbolics failed to do that.
Cyber Surfer
> > I've noticed that a lot of experienced Windows people will criticise
> > the MS "Bob" interface for being _too friendly_.
>
> Bob was written in Lisp. ;-)
I'm not keen to point this out to C++ people, in case the "negative"
aspects of Bob are associated with Lisp. That's not a good way to
convert C++ people, in my experience.
> Newton OS 2.0 preview in Mobilis Magazine
> http://www.volksware.com/mobilis/november.95/newton1.htm
This was what I was after. I found a few of your other links, but
failed to find the mobile article. Thanks.
> > Now we should show what modern Lisp can do.
>
> Some people already are trying this.
>
> What is your contribution?
I'm still working on my Lisp to C compiler. Progress is slow because
of various distractions, like sometimes writing C code for my
employer. This week, I have some server code to re-write. I've no idea
who else might use my compiler, as I'm ignoring code quality entirely,
so that I can focus on supporting Win32 features. We'll see.
Sin-Yaw Wang
Henry Baker wrote:
> In article <330512...@acm.org>, sin...@acm.org wrote:
> > I think fundamentally, Lisp syntax is not natural for human being.
I don't read comp.lang.lisp, so I respond only to the comp.lang.scheme
postings.
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.)
I will place my bets on right now...
Gone are the days people (even professionals) change for computer. It
is the time computer must become natural to people. Whether the syntax
is mathematically beuatiful does not make it more natural.
I still assert that the more natural the syntax, the more productive
your engineers. How can anyone dispute this fact?
--
Sin-Yaw Wang, sin...@acm.org
http://www.concentric.net/~sinyaw
Erik Naggum
* Sin-Yaw Wang
| I still assert that the more natural the syntax, the more productive
| your engineers. How can anyone dispute this fact?
because it is not a fact. please demonstrate how you came to believe this.
in my country, politicians try to have your kind of tallies to find out
wether it is natural or reasonable (or any of those other "whatever I feel
like" responses) that stock brokers should earn millions of dollars a year,
and lo and behold! the general public is opposed to it. so now we're
facing a proposal for a cap on stock brokers' earnings. (it won't win
enough support -- after all, the fraction of politicians that are complete
idiots in this country is still not big enough.)
speaking of fractions, a friend of mine is a math teacher. she says that
the majority of the _adult_ population does not understand calculations
with fractions. given a popular vote, fractions would also be removed from
the curriculum of public education, like almost every other hard science or
mathematical subject has been in what we call "Reform 94". it's intent is
to make it possible for _all_ the kids out there to feel well about school,
and learn only what's _natural_ to them. (it de-emphasizes the natural
sciences to an alarming degree, and now they're doing away with every
objective measure of a kid's improvement, too.)
I guess you're really in favor of dumbing down everything and everybody to
the lowest common denominator (that's a term from the unnatural fractions).
I still think the human potential is largely untapped, and that if you
argue about what's natural to the majority as a measure of what you will
not allow _anybody_ to do, or that what's "natural" to the _uneducated_ as
a measure of what people should not have to learn, you're going to destroy
everything that _is_ natural to human beings: self-fulfilment, happiness,
security, progress, and growth.
why don't you make a grad school project to determine how much money people
should have in their bank accounts, too? and is it really _natural_ for
the bank to own your house? do away with that, too! let the public vote
on free houses!
#\Erik
--
if you think big enough, you never have to do it
861 <snowlion@comfo.ca>
(quick warning beforehand - my mail setup is a LITTLE weird at the moment
'cause of HD space probs
- so if ya WANNA reply, reply to snow...@comfo.ca. It'll be easier :)
Nother quick warning: This is DEFINITELY not helping this 'holy war'.
I'm trying to avoid any kind of flame at anyone in particular - so try
not to take this personally. (most of my flames are self-directed anyways)
Oh, this is also a LONG message.... reader beware....
On 17 Feb 1997, Erik Naggum wrote:
> * 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.
Yes. This is a VERY important point. I have MANY bones to pick with this
(one being I would NEVER pass such a test - am completely broke. It is
irrelevent that I almost never write buggy code and usually make it
user-friendly (according to people who use it :).
But more importantly, my points:
- Software is still in it's infancy; Consider it at a scientific
point of ~14th century chemistry.... We have nothing TO standardise.
(if it wasn't I wouldn't feel so bad about being 'unqualified')
- There are no organizations to support this. Probably because of
previous point, but the current failing government/education fields
probably doesn't hurt.
- Relating to medical profession is nice, but programming isn't that
clean. We don't have a stable leg to stand on.... we'd all have
to start fresh actually learning from prior experience rather than
depending on previous work by unqualified people (aka Windows, for
lack of a more appropriate example :)
- We don't have any real experts. Just lots of people who either think
they are or other people think they are. No board of experts.
- No exam to qualify - what would be on it anyways?
FWIW - Talking about this in c.l.lisp or c.l.scheme is prolly a no-no,
beyond that it impacts everyone present [lurker or not].
Anyone have any better comments? Just saying 'and so mote it be' is not
an effective way of implementing change (normally) - so declaring 'let
there be tests that qualify and boards of experts' won't do anything.
Gotta be a way to make it happen (if it's actually worth doing).
> | 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 like the comment earlier about this- 'aristocracy'.
I'm gonna add another one: 'poverty'..... I'm not quite to the point
where I have to grow my own food.... (and I can still cover power bills)
I never use consumer products (or even see them) because they cost more
than I can afford.
> 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'll make them if necessary (though a microwave oven is NOT for home
builders - unless ya wanna little self flash-cooking, eh? :)
And since when is professional high-quality anywhere outside the medical
profession? (where quality is ensured by nasty laws and other unpleasant
measures - not really by boards of doctors [that's a gross generalization
- don't flame please :]. )
> | 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 understand. I am an 'idiot' in many professions :) True capability is
worthy of respect.
Most programming is just how you look at things these days. True skill
is yet to be seen. This is a 'science' in it's infancy - or a
profession, if you prefer. FWIW software protection and information
hiding is just slowing the growth of the profession. Not that it is a
BAD thing, just that it is slowing things down.
> 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.
I would LOVE too see programming tools at that level of quality. Not to
mince too fine a point, but most tools I've seen (excepting a bit of the
Lisp tool world) seem to be of the 'stone chisel' level. Some of the
Lisp tools were the only surprise for me on that mark. Some of them are
almost as advanced as 'iron chisels' :)
> 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.)
Where's the effective real-time OS? Waiting for stable tools, or being
quietly written by people who ARE qualified. Who wants to trust a
driveshaft (or nuclear reactor) to the vaguaries of a stable system like
Windows? (sarcasm intented)
Martin Cracauer
Erik Naggum <er...@naggum.no> writes:
>* 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.
Franz Allegro has a few Redhat dependencies in the installation
script. Otherwise, you don't need much more than a running Linux
kernel. I am even near to running it on FreeBSD.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
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
Henry Baker
> 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.)
Bzzzt!! We we talking about students, and now you bring up 'SW engineers'.
'SW engineering' is a myth promulgated by Ada advocates who couldn't think
of any other way to sell their dog language.
There is also the highly charged question of what is 'natural'... I
think that a great deal of ink has been spilled in vain by philosophers
over this question...
> I will place my bets on right now...
>
> Gone are the days people (even professionals) change for computer. It
^^^^^^
> is the time computer must become natural to people. Whether the syntax
^^^^^^^
> is mathematically beuatiful does not make it more natural.
^^^^^^^^^^^^^^^^^^^^^^^^
>
> I still assert that the more natural the syntax, the more productive
^^^^^^^^^^
> your engineers. How can anyone dispute this fact?
^^^^
'Change' from what to what? Who is to say that infix is 'natural'? If you
ask 3rd graders, I think you'd get a real diversity of opinion about this.
'Natural' is highly dependent on your context. I'm just guessing, but I
suspect that you find Chinese characters more 'natural' than ASCII text.
'Mathematical beauty' and 'productivity' _do_ often go hand-in-hand. A system
that can be taught faster and can do more will be more productive.
I don't think that there was ever any argument about whether Lisp was more
productive (especially on Lisp machines). I think that the question was
whether the productivity was worth the extra cost, and whether the result
of this productivity could be delivered on low-cost platforms.
Will Hartung
Sin-Yaw Wang <sin...@acm.com> writes:
>Henry Baker wrote:
>> In article <330512...@acm.org>, sin...@acm.org wrote:
>> > I think fundamentally, Lisp syntax is not natural for human being.
>I don't read comp.lang.lisp, so I respond only to the comp.lang.scheme
>postings.
>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 driving on the left is natural or not? This is
silly. Go find a good sample of all of the drivers of the London
Taxi Fleet and ask them "Is driving on the left natural to you?" Tally
the responses and you have the answer. No amount of argument will
change that fact. (This seems like a silly waste of bandwidth.)
>I will place my bets on right now...
Hmm...putting money on opionion polls...I though thats what election
campaign contributions were for...
>Gone are the days people (even professionals) change for computer. It
>is the time computer must become natural to people. Whether the syntax
>is mathematically beuatiful does not make it more natural.
Absolutely! Well said! Here, Here!
Let me chime in and add my voice to the chant "Work harder, and
not smarter." Keep that head a pounding and the brick wall WILL yield!
How can anyone expect someone to perform THE most natural feat of a
human being: Learn, and adapt to its environment. What a shocking
assumption.
>I still assert that the more natural the syntax, the more productive
>your engineers. How can anyone dispute this fact?
Have you ever been in a design meeting? Here, people use their most
natural syntax: shouting, finger pointing, opaque "charts and graphs",
pre-concieved notions and petty little self-contained empires to
protect. They aren't very productive at all.
>--
>Sin-Yaw Wang, sin...@acm.org
>http://www.concentric.net/~sinyaw
Oh dear, I'm sorry...I seem to have been typing with my [SARCASM LOCK]
on...
Marc Wachowitz
861 (snow...@comfo.caroot@comfo.ca) wrote:
> - Software is still in it's infancy; Consider it at a scientific
> point of ~14th century chemistry.... We have nothing TO standardise.
Well, I'd say there's quite a lot of good theory available; for many
problems, the difficulty isn't that no applicable scientific background
would exist, but that the production process tends to ignore theory,
be it due to people not understanding much of it, or due to "external
demands" being incompatible with responsible system construction.
What's much more important for most of Erik's criticism (which I share)
than the lack of accumulated knowledge is the unwillingness or inability
of many software designers/programmers to learn something such that the
result isn't just a reproduction of several volumes of examples in the
brain of the learner (dictionaries and reference manuals - particularly
when managed by appropriate software - are better suited for it than a
human's brain, and what's really frequently used will soon be remembered
anyway), but also some insight into the learned topic, and some ability
to notice when one's current competence is exceeded. Without such skills,
a basic curiousity, and joy in exercising one's mental flexibility, I
doubt that any amount of so-called "education" would help much. Good
programming is also a lot like good literature - you can't judge it merely
from inspecting the spelling, the grammatical patterns and a statistical
distribution of words from a dictionary. It may be difficult to judge
many important qualities objectively in typical educational environments,
but this doesn't make them superfluous any more than the simplicity and
formal verifyability of a train station's time table will transform it
into a good piece of literature. For many programmers, the status quo
is unfortunately more like creating a collage by cut-and-paste from the
text parts of low-quality comics.
-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>
David H. Thornley
In article <33096B...@acm.com>, Sin-Yaw Wang <sin...@acm.com> wrote:
>Henry Baker wrote:
>> In article <330512...@acm.org>, sin...@acm.org wrote:
>> > I think fundamentally, Lisp syntax is not natural for human being.
>
>I don't read comp.lang.lisp, so I respond only to the comp.lang.scheme
>postings.
>
>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.)
>
I'll tell you what you'll get: they'll tell you that whatever they
use a lot is natural, and whatever they don't use a lot isn't. Since
C and C++ is big right now in software engineering, the majority
response will be that "C is natural" and "Lisp isn't natural". If
you had done this about 1980 or so, the answer would have been that
"COBOL is natural", and "Lisp and C aren't natural". If you want
to find out what people find natural, you'll have to find people who
haven't already learned programming, and therefore have no learned
instincts. Try teaching half of them with Pascal and half with Scheme,
and see who does better.
>I will place my bets on right now...
>
>Gone are the days people (even professionals) change for computer. It
>is the time computer must become natural to people. Whether the syntax
>is mathematically beuatiful does not make it more natural.
>
Aside from the fact that programming is a highly unnatural activity,
programming languages and systems are still very inflexible and not
intuitive, and require a lot of change in how people do things.
I've heard rumors of Unix use here and there, and I think some people
still work in MS-DOS. If you want something flexible and adaptable,
you could do much worse than Lisp. You pretty much adopt one standard
syntax, don't worry about the precedence of i + j << 2, don't have
to remember that getchar() returns an int, and after that you don't
have to change nearly as much; you simply reform the language.
>I still assert that the more natural the syntax, the more productive
>your engineers. How can anyone dispute this fact?
>
Easy. What is natural? Engineers will be more productive working with
something they're comfortable in, in general (although the few studies
I've seen don't indicate a large effect here), but comfort can be
attained by simple experience. How many of us are comfortable maneuvering
a hunk of steel at 60 miles per hour (90 kph) with simple hand and
foot controls? How many people are comfortable with while (*ch1++ = *ch2++);?
Neither of these are natural, in any reasonable sense of the word.
Nor is there any evidence whatsoever that Lisp is less natural than
C++. I'd argue the reverse, since Lisp has far fewer gotchas (do
you know when exceptions might be thrown, and exactly how to keep the
program in a constant state around them?). I know that C++ is more
popular than Lisp, but I've never observed that popularity is dependent
on nature.
--
David H. Thornley, known to the Wise as thor...@cs.umn.edu O-
Disclaimer: These are not the opinions of the University of Minnesota,
its Regents, faculty, staff, students, or squirrels.
Datclaimer: Well, maybe the squirrels. They're pretty smart.
Sin-Yaw Wang
Why lisp failed in the marketplace? That was the question!
I ventured the answer, "Because Lisp is not natural to most software
engineer." I gave several examples on how it is not natural. Many did
not like my examples and attacked.
I stand by my claim, "Lisp failed because its syntax is not natural."
You may argue its syntax is better, I would have agreed. But if you
argue its syntax is really natural to most engineers. You have not been
in the real software world.
--
Sin-Yaw Wang, sin...@acm.org
http://www.concentric.net/~sinyaw/
Sin-Yaw Wang
Erik Naggum wrote:
>
> * Sin-Yaw Wang
> | I still assert that the more natural the syntax, the more productive
> | your engineers. How can anyone dispute this fact?
>
What! Which planet you came from? Go sit in the sigchi discussion
group for 2 months before you post anything again.
Listen, "The more natural the syntax, the more productive the
engineers." Do argue on this point. Argue on whether Lisp is more
natural.
Sin-Yaw Wang
Henry Baker wrote:
> > Gone are the days people (even professionals) change for computer.
> 'Change' from what to what? Who is to say that infix is 'natural'? If you
> ask 3rd graders, I think you'd get a real diversity of opinion about this.
>
> 'Natural' is highly dependent on your context. I'm just guessing, but I
> suspect that you find Chinese characters more 'natural' than ASCII text.
It is the computer scientists' challenge to bridge the gap of computer
and human being. One of the task is to come up with a language that is
efficient for both. One of the design trade-off is the slope of the
learning curve.
> I don't think that there was ever any argument about whether Lisp was more
> productive (especially on Lisp machines). I think that the question was
> whether the productivity was worth the extra cost, and whether the result
> of this productivity could be delivered on low-cost platforms.
Wrong. Lisp is not more productive. Form 2 teams to do the same task,
one using Lisp and the other use something else. See which one can
accomplish with less resources. If your task is anything serious (a
venture capitalist will invest on), the C++ team will win.
David B. Lamkins
On Tue, Feb 18, 1997 12:42 AM, Sin-Yaw Wang <mailto:sin...@acm.com> wrote:
>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?"
Or you could ask a good sample of North Americans whether
any of the romance languages is natural to them. Just as
valid as your test...
> Tally the responses and
>you
>have the answer. No amount of argument will change that fact.
>(This
>seems like a good grad school project.)
>
And what does the answer tell you? That few grad students
bother to learn Lisp?
>Gone are the days people (even professionals) change for computer.
>It
>is the time computer must become natural to people. Whether the
>syntax
>is mathematically beuatiful does not make it more natural.
>
>I still assert that the more natural the syntax, the more
>productive
>your engineers. How can anyone dispute this fact?
>
So, what is a "natural" computer language syntax, in your
opinion?
Do you think that the semantics of a language might have
anything to do with an engineer's productivity?
---------------------------------------------------------
David B. Lamkins --- http://www.teleport.com/~dlamkins/
CPU Cycles: Use them now, or lose them forever...
---------------------------------------------------------
cosc...@bayou.uh.edu
Sin-Yaw Wang (sin...@acm.org) wrote:
: Erik Naggum wrote:
: >
: > * Sin-Yaw Wang
: > | your engineers. How can anyone dispute this fact?
: > because it is not a fact. please demonstrate how you came to believe this.
: What! Which planet you came from? Go sit in the sigchi discussion
: group for 2 months before you post anything again.
As much as I'd hate to come to the aid of Erik, I think it is you
who should be sitting somewhere (do they give lectures on common
sense?).
Lack of a natural syntax has little to do with productivity, and
that's assuming that Lisp syntax is not natural.
I use Lisp for my programming tasks (it's finally grown on me
to the point where the parenthesis don't bother me much). While
the syntax is 100% natural to me, I am far more productive in
Lisp than I am in languages that have a (to me) more natural
syntax like Ada.
Have you ever stopped and thought of the other factors that
affected productivity? Syntax isn't the end of the world.
You've got the capabilities of the language. How many
functions does it provide? Of what type? How reliable
are they? How easy is it to trap errors? How easy is it
to express operations? What sort of data types are
provided? How flexible is the type system?
You've got the capabilities of the system. Is it
interpreted? If so, there's a big productivity boost
right there since you get damn near instantaneous feedback
and a nice cush environment where incrementally testing code
and debugging is a snap. Are there runtime checks for
various problems? Whammo, more productivity. Now instead
of tracking down core dumps you can find out where the
error occurred and fix it.
Lisp wins big on many counts. It comes with an interpreted
environment so there's the boost from being interpreted.
It has a vast array of powerful and useful functions, more
useful than what numerous other languages (like C) provide.
It has a type system (or lack thereof) that enables generic
programming without a second thought (rather than
hacks like C++'s templates). The data types available are
incredibly useful -- lists can express everything from
linked lists, to variable branched trees. Macros give
unbelievable power--you can define your own control
structures and more!
Even if Lisp has an unnatural syntax, all the above more than
makes up for it. And that's assuming that the syntax is
unnatural.
And just how unnatural is Lisp's syntax? Maybe not as
much as you think (maybe not at all when compared with
other languages).
How natural is this?
p == (*ch++ = s(&i1, &i2, *(++i3)))
Not at all I say! So we can see that Lisp is already more
natural than at least 2 languages out there (3 guesses
as to which 2 they are).
Now, when we are dealing with Lisp, all you really need to do
is just remember that everything is a function and whammo
there are 90% of the rules right there. No order of
precedence or other stuff to remember, and since everything
is bounded by paranthesis, which are automatically grouping
mechanisms, that connection is not difficult at all.
Now I'm finding statements like
(and (not (= i j))
(not (= k c))
(equal l1 l2))
To be in some ways as natural, if not more so than:
i /= j and k /= c and equal(l1, l2)
Heck, the first example (Lisp) has the benefit of
illustrating immediately the precedence levels, whereas
I'd have to look twice at the second example (Ada),
and that's a relatively trivial example.
It gets even more complicated when you're mucking about
in C/C++ and working with side effecting operations and
assignments that also return values as my first example
illustrated.
There is no doubt about what gets executed first in Lisp,
and that's part of its beauty.
Furthermore, let's go a little further. Let's get into
actual usage, and how natural it is to express certain
algorithms. Let's say for example, that you want to
search for a number, and you want to return the number
or some error code if it wasn't found. In Lisp
you can simply return the number, or if it wasn't
found nil or some appropriate symbol.
Not so simple in C/C++. You have to resort to yet more
hacks. In C you could return a pointer to the value,
but you'd better pray that who's using it doesn't
try anything funny or it's core dump city (if you're
lucky, if not it'll seem to work until you really need
it then BLAM!). Hey in C++ you can play with exceptions
or try to roll some return class. Still ugly.
What is natural in this case is to return the freaking
number or something that indicates it wasn't found,
why are these languages making it so difficult?
Lisp sure seems natural now eh?
: Listen, "The more natural the syntax, the more productive the
: engineers." Do argue on this point. Argue on whether Lisp is more
: natural.
I've already argued on both how natural Lisp is, and how productive
it is given the assumption that it isn't natural.
: --
: Sin-Yaw Wang, sin...@acm.org
: http://www.concentric.net/~sinyaw/
--
Cya,
Ahmed
cosc...@bayou.uh.edu
Sin-Yaw Wang (sin...@acm.org) wrote:
[Snip]
: It is the computer scientists' challenge to bridge the gap of computer
: and human being. One of the task is to come up with a language that is
: efficient for both. One of the design trade-off is the slope of the
: learning curve.
:
And the slope of the learning curve has a hell of a lot more to
it than just how natural the language's syntax seems to be. C++
for windows has (by your definition) a more natural syntax, but
it sure as hell has a steeper learning curve. I'd venture more
steep than a comparable GUI Lisp system like Allegro CL, or
Scheme with tk extensions.
: > I don't think that there was ever any argument about whether Lisp was more
: > productive (especially on Lisp machines). I think that the question was
: > whether the productivity was worth the extra cost, and whether the result
: > of this productivity could be delivered on low-cost platforms.
: Wrong. Lisp is not more productive. Form 2 teams to do the same task,
: one using Lisp and the other use something else. See which one can
: accomplish with less resources. If your task is anything serious (a
: venture capitalist will invest on), the C++ team will win.
Oh more conclusive statements from a guy who can't even understand
that syntax isn't the only thing to a language? I'll say the
same thing Erik said, do you have evidence of this? If you don't
then you have nothing to say, and you should keep your mouth
shut accordingly. Note that even though I believe that the
Lisp team would *CREMATE* the C++ team, I (unlike you) will
refrain from spouting my opinions off as fact, even though
they are well based (certainly better based than yours).
I await this mountain of evidence Sing-Yaw.
David B. Lamkins
<mailto:thor...@cs.umn.edu> wrote:
>How many people are comfortable with while (*ch1++ = *ch2++);?
;? -- Isn't that the new ternary statement separator now under
consideration by
the working group? (Sorry...)
cosc...@bayou.uh.edu
Sin-Yaw Wang (sin...@acm.org) wrote:
: Erik Naggum wrote:
: >
: > * Sin-Yaw Wang
: > | I still assert that the more natural the syntax, the more productive
: > | your engineers. How can anyone dispute this fact?
: >
: > because it is not a fact. please demonstrate how you came to believe this.
: What! Which planet you came from? Go sit in the sigchi discussion
: group for 2 months before you post anything again.
As much as I'd hate to come to the aid of Erik, I think it is you
who should be sitting somewhere (do they give lectures on common
sense?).
Lack of a natural syntax has little to do with productivity, and
that's assuming that Lisp syntax is not natural.
I use Lisp for my programming tasks (it's finally grown on me
to the point where the parenthesis don't bother me much). While
the syntax is not 100% natural to me, I am far more productive in
How natural is this?
Chris Bitmead
>I still assert that the more natural the syntax, the more productive
>your engineers. How can anyone dispute this fact?
I disagree. Certainly infix notation is more human like. But human
like language is very imprecise. How many legal contracts could
benefit from a few parentheses to clarify the meaning of ands and ors?
The best language to communicate with a machine is a language with a
very clear and precise syntax. Such a language is not likely to be
natural. Human beings can usually, but not always figure out what you
mean.
e.g. Are you going to work or going shopping and buy some food.
you will probably parse this as
Are you ((going to work or (going shopping and buy some food.))
rather than
Are you ((going to work or going shopping) and buying some food.)
The computer can't figure this sort of thing out. That's why a natural
style language is bad for talking to machines. It lulls the programmer
into a false sense of security.
Erik Naggum
* Sin-Yaw Wang
| Wrong. Lisp is not more productive. Form 2 teams to do the same task,
| one using Lisp and the other use something else. See which one can
| accomplish with less resources. If your task is anything serious (a
| venture capitalist will invest on), the C++ team will win.
do you have any references to actual cases? that would be nice. a fact
here and a fact there.
the experience of _every_ Lisp programmer I know is that a working, robust
solution is delivery in 1/2 to 1/10 of the time it takes to do it in C++,
with the same amount of resources consumed per unit of time.
another fact that blows the minds of hype-mongers is that of two teams, one
using a nominally powerful text editor (like Emacs or vi) and a structured
markup language (like a troff package, LaTeX or (a well-designed) SGML
document type), the other using the state of the art in WYSIWYG editors,
the former will produce and maintain a set of documentation at about half
the cost of the latter and the quality and consistency of the result will
be vastly better, too.
the reason the hyped solutions "win" in the marketplace is that there is a
far greater market in building tools that require more people to use them
than there would be in building tools that require few people to use them.
the economy of scale also applies to software, but the quality of the end
result is none of the vendors' business. Bill Gates understands this
relationshp well. it's time the rest of the world also understands it.
the more "natural" the syntax, the more programmers you need to complete
the job and the easier it is to find them. the more _formal_ the syntax
and the semantics of the language, the fewer programmers you will find, but
you don't _need_ even fewer of them.
case in point: I have found it much easier to recruit Lisp programmers to
help me with a couple projects than I ever found recruiting C programmers
to help me with projects in the past. the reason is very simple: I need
people who know what they're doing, and I don't want to be the _best_ among
the people I work with. a Lisp programmer costs about twice as much as a C
programmer, but when you need four C programmers or one Lisp programmer to
get the same job done, guess where I put my money. (no, I'm not a venture
capitalist. I make my own money.)
Paul Prescod
In article <vfr750E5...@netcom.com>,
Will Hartung <vfr...@netcom.com> wrote:
>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.
I think that the syntax of Lisp and Scheme are really a big part of what
frightens people off. I can show you some ML code, and it has nice big
function declarations, and the if/then/else constructs are familiar,
patterns are a little weird-looking, but you expect some weird stuff in
any new language. But ML is a functional programming language: it just uses
syntax that is closer to mainstream programming languages.
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?
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.
Paul Prescod
Paul Prescod
In article <330512...@acm.org>, Sin-Yaw Wang <sin...@acm.org> 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.
>
>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.
Really? Is 2 the result of applying the "+ 1" function to "1" or the result
of allocating a location called "x" that has the contents of 1 and then
incrementing the data at the location "x"?
Functional programming is about taking expressions like:
(a + b - ( c * d ) )
and extending them to do computations:
(a + b - ( (if c 1/e else 1/f) * d) )
Seems pretty natural to me!
Does this seem like a more natural progression to you:
real temp;
if c then
temp = 1/e;
else
temp = 1/f;
(a + b - (temp * d)); // better check overflow in the next statement
Note that I have separated the issues of infix vs. prefix as irrelevant to
functional languages vs. imperative ones.
>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.
Mathematics is not natural at all. How long does it take to teach
it? Should we quit doing so?
I think that recursion and computer programming can be taught right
alongside traditional math from grade 1 up. When you are learning order
of operations you should be able to type in the expressions and see
how the computer interprets them. When you are exploring functions,
you should be able to write functions, using a syntax similar to that
on the blackboard (which is certainly NOT procedural!).
Paul Prescod
Teunis Peters
On 15 Feb 1997, Erik Naggum wrote:
> * 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.
You're right, of course <grin>.
Looks like I got some more reasons (I finally remember why Lisp :)
- Need threads. Badly.
(I use Linux, which NOW has threads of the fork and share
memory variety... Problem: Nothing supports it.
Solution: me build support :)
- Need to be able to shut down console (should be easy)
[my system is 100% graphical - 2D/3D/+]
- Oh yeah, I keep forgetting: This is a Linux environment (Unix
basically). Keep forgetting not everyone uses Unix :)
- CLOS is mandatory (or equivalent...)
- Shared module support is mandatory
[uhmm - does Allegro or CMU support this? I got CMU
installed at the moment]
I gave up trying to find a thread-supportive package some bit ago (when I
discovered noone was yet using Linux's thread capability); so I decided
to code my own compiler. Not a small undertaking, and I've been dreading
starting coding since December. (I tossed GCC 'cause it's lowlevel
output code isn't very thread-safe .... though it's safe enough for
threaded code if no libraries are included). Scheme + assembly (don't
groan - that might look gross but it'd work for me) will probably work
for a bootstrap to hook the system together.
I checked out siod - a small Scheme implementation. If it weren't for
the lack of threading, it's almost perfect for my starting point. (Close
enough to Lisp for my needs :) I think Scheme is cool!
> I think it may need RedHat 4.0, but I don't know how compatible the
> different distributions of Linux are.
Largely compatible. I've force-fed redhat packages to my system before <g>.
Mine's a largely self-modified system anyways.... It's approx a 5 year
old project of mine <grin>. (probably why I keep forgetting there's
people out there who don't use linux...)
Oh, and don't mind my bare-metal comments.... I'm now an Assembly
programmer (well, trying to avoid assembly :); so I'm looking for
languages with all the power of assembly coding but with a friendly
interface. C sorta qualifies. Lisp most DEFINITELY qualifies. Doesn't
mean Lisp is low-level. However, it's very GOOD at low-level if ya need
it <Grin>....
hmmm... don't know if I forgot anything.... my memory has been quite
foggy of late. Suppose I should write up some notes (if I had any way to
explain on paper what I'm building... grrr....)
Thanks everyone for responses so far! Now that I've actually READ some
docs on scheme I might know better what I'm talking 'bout :)
Wind to your wings!
- Teunis
Henry Baker
> What! Which planet you came from? Go sit in the sigchi discussion
> group for 2 months before you post anything again.
> Sin-Yaw Wang, sin...@acm.org
^^^^^^^^^^^^^^
This email apparently doesn't work from netcom.
Since when does sigchi have an inside knowledge about what makes a language
natural or not? Back before 'direct manipulation languages', they were
still arguing about how many angels could sit on the head of a syntax clause.
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!).
Andreas Eder
cosc...@Bayou.UH.EDU (cosc...@bayou.uh.edu) writes:
> Sin-Yaw Wang (sin...@acm.org) wrote:
>
> [Snip]
>
> : Wrong. Lisp is not more productive. Form 2 teams to do the same task,
> : one using Lisp and the other use something else. See which one can
> : accomplish with less resources. If your task is anything serious (a
> : venture capitalist will invest on), the C++ team will win.
>
> Oh more conclusive statements from a guy who can't even understand
> that syntax isn't the only thing to a language? I'll say the
> same thing Erik said, do you have evidence of this? If you don't
> then you have nothing to say, and you should keep your mouth
> shut accordingly. Note that even though I believe that the
> Lisp team would *CREMATE* the C++ team, I (unlike you) will
> refrain from spouting my opinions off as fact, even though
> they are well based (certainly better based than yours).
>
> I await this mountain of evidence Sing-Yaw.
>
>
>
> : --
> : Sin-Yaw Wang, sin...@acm.org
> : http://www.concentric.net/~sinyaw/
>
> --
> Cya,
> Ahmed
But there is evidence; there have been studies! Look at
Haskell vs. Ada vs. C++ vs. Awk vs. ...
An Experiment in Software Prototyping Productivity
{hudak-paul, jones-mark}@cs.yale.edu
and what was the result? You may have already guessed it, the Haskell and Lisp
teams won by a great margin. And their code was according to the reviewers much clearer.
Andreas
Robert Rodgers
Kevin Russell <kru...@cc.umanitoba.ca> wrote:
>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,
Just a post from a lurker:
I found Japanese to be very natural & easy when I took 4 years of it.
Very little effort required to structure sentences&c.
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. 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).
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.
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).
Visual locality was another annoying factor in lisp. I'm not bashing
lisp, but what is the *advantage*, as you see it?
>My HP calculator works like Japanese -- get all the characters on the
>stage, *then* say what to do with them.
I think I side with the original poster -- RPN & stack style languages
really are quite unnatural (this doesn't make them bad). I don't
think this is being ethnocentric -- Japanese doesn't really work this
way and I can't remember a language which does (I've only taken
Japanese, Chinese, French and Spanish, plus a few survey courses, so
this is AFAIK).
(Justification for disagreeing on Japanese: the verb (such as it is)
is at the end of the sentence (but you find verbals *throughout* a
sentence in clauses), but you don't get constructions like "one two
one three five add subtract divide equals." Lisp is not a mirror
image of infix.)
Robert Rodgers
cyber_...@wildcard.demon.co.uk (Cyber Surfer) wrote:
>I'm not keen to point this out to C++ people, in case the "negative"
>aspects of Bob are associated with Lisp. That's not a good way to
>convert C++ people, in my experience.
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.
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?
Mike McDonald
I believe that the reason Lisp has failed to be widely accepted is that for
most programmers, their first and only exposure to Lisp is in some rinky dink
"Introduction to AI" class. At the end of which, if they're lucky, they might
have written programs like Eliza and a checkers player. I can understand why
they don't think Lisp is good for anything real.
As for Symbolics part in the downfall of Lisp, sure, they contributed to the
problem in some respects. They also built some of the nicest machines to do
programming on that have ever been built. I only wish they could have gotten
their act together so that they'd still be a viable option today. But they
could never make up their mind as to whether they were a hardware or software
company. (Attempting to be both is almost always fatal.) They also didn't want
to face their competition, which was primarily Sun. When the Sun3 was first
introduced, both Symbolics and Sun were about the same size, in terms of
revenue. Symbolics decided that they were not in the "workstation" market. They
were in the AI market. One of the all time stupidest moves ever. (And I told
the president of Symbolics that at the time! (I still have my trusty Symbolics
letter opener that I received as a result of that meeting.) Oh well.)
Anyway, that's history and it's too late to do much about it now. The real
question now is can anything be done to increase the acceptance of Lisp as a
viable programming solution? I'm rather pessimistic about it. Heck, GUI's have
been a requirement for any serious developement and delivery environment for at
least eight years. Lisp still doesn't have a viable and convincing answer to
that part.
Mike McDonald
mik...@engr.sgi.com
Paul Prescod
In article <330A09...@acm.org>, Sin-Yaw Wang <sin...@acm.org> wrote:
>Why lisp failed in the marketplace? That was the question!
>
>I ventured the answer, "Because Lisp is not natural to most software
>engineer." I gave several examples on how it is not natural. Many did
>not like my examples and attacked.
No, you said: "I think fundamentally, Lisp syntax is not natural for human
being." The statement above is true, because software engineers are
accustomed to infix and procedural programming. But since most people are
not familiar with either, Lisp syntax will be as easy as that of most other
languages for anyone who has the mental capacity to actually become a
programmer.
Paul Prescod
Erik Naggum
* Robert Rodgers
| 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.
we've been here before, but I think this is still an interesting topic:
there seems to be some kind of predetermined affinities for modes of
communication, and by inference, languages styles. we already know that
some people are more visual than aural, some more verbal than visual, etc,
and there appears to be a similar "built-in" affinity to syntax. me, I'm
verbal and I'm thrown by the arbitrariness of hieroglyphics (what I call
visual signs devoid of any meaning, including the modern "icons"). e.g., I
_much_ prefer `(command-line-arguments)' to `"$@"'. others find that long
words and complex sentence structure throw them off balance, but revel in
remembering thousands of seemingly arbitrary abbreviations, instead.
I speculate that these affinities are innate or shaped _before_ we learn
any programming languages, that there is no _one_ natural syntax, but that
"natural" depends on who you _are_. even if it is not innate or precedes
programming language exposure, but shaped by something _other_ than such
exposure, such that you find yourself "at home" with Lisp even if you have
years of experience with C, we would have some evidence that the "natural"
is not a function of some notion of a universal human character.
| 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).
hm. my experience with showing people Lisp is that it takes mere minutes
for them to pick up the basic patterns and modes of expression.
| 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.
perhaps it really is, to some people. for instance, it's nearly impossible
for me to remember music well enough to play or whistle something, and I
have a very hard time remembering lyrics. others remember the melody, the
rhythm, and the lyrics the first time they hear a song. I very easily
remember technical specifications and numbers, but forget names. others
are the exact reverse. I love puns and see I patterns in words all over
the place. others think puns are the worst kind of humor and find their
humor in situational comedy, which I find too predictable to be fun. none
is really _better_ than the other, but humans differ so much in so many
respects that it would be hard to argue for _one_ aspect being universal,
such as programming language syntaxes. after all, whoever invented it
probably thought it was the most natural thing in the world. those who
adopted it must obviously have found it unproblematic, too. this applies
equally to C++ and to Lisp and to Perl and to Ada. the mere existence of
these languages suggest that if there is _one_ "natural" syntax, it must be
a core of commonality in all of these languages, and not the full-fledged
forms that we associate with a complete programming language.
I also remember fondly when I read about the Meyer-Briggs Temperament Index
(MBTI), where they are able to predict behavioral patterns and affinities
from a relatively short list of questions whose answers score on various
axes. Jung's apparently pioneered this work with his "personality types".
insofar as it can help people understand more about themselves or other
people, it seems very valuable. (I'm an INTP, with a *very* strong T.)
| 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).
I haven't studied human languages enough to know for sure, but it seems to
me that parts of sentences return "values" for use with other, frequently
preceding, parts of the sentences I naturally write and speak. it seems
that I prefer verbs early and narrowing down the agents and the objects
late in the sentence. perhaps there really _is_ a correlation between
natural language style and programming language? if I remember correctly
something I heard many years ago, it is possible for another human being to
identify an author by his style, choice of words, sentence structure, etc,
and programs that can detect these patterns and write like the person in
question such that others will "sense" who is being parodied, even though
the parody has no meaning. it this is correct, it suggests that language
is profoundly _personal_ attribute, and it's a wonder we can talk at all.
speaking of which...
| Visual locality was another annoying factor in lisp. I'm not bashing
| lisp, but what is the *advantage*, as you see it?
I don't understand what this means. could you elaborate?
Len Charest
Sin-Yaw Wang wrote:
> Listen, "The more natural the syntax, the more productive the
> engineers." Do argue on this point. Argue on whether Lisp is more
> natural.
"More natural." Now there's a meaningful concept...
Is the sea more wet than the rain?
BTW, my 5+ years as a Lisp programmer were the most productive in my
career, both in terms of projects completed and personal satisfaction.
My Lisp code flowed across the screen like a post-modern word sculpture.
Stop confusing the syntax of a language with its semantics. And stop
conflating the terms "procedural" and "functional" with "iteration" and
"recursion".
--
Len Charest l...@cogent.net
Senior Software Engineer 818-585-2788
Cogent Software, Inc. http://www.cogent.net/
Bradley Yearwood
In article <hbaker-1802...@10.0.2.1>,
Henry Baker <hba...@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.
Brad Yearwood b...@crl.com
Cotati, CA
Daniel Wang
>>>>> "Sin-Yaw" == Sin-Yaw Wang <sin...@acm.org> writes:
Sin-Yaw> Erik Naggum wrote:
Sin-Yaw> What! Which planet you came from? Go sit in the sigchi
Sin-Yaw> discussion group for 2 months before you post anything again.
Sin-Yaw> Listen, "The more natural the syntax, the more productive the
Sin-Yaw> engineers." Do argue on this point. Argue on whether Lisp is
Sin-Yaw> more natural.
Operationalize "natural syntax" and "productivity" before you post anything
again. So anyone with a minimal background in empirical reserach
methods/pyschologial research won't laugh at you and can understand what
claim you're making.
Chris Bitmead
In article <E5txo...@undergrad.math.uwaterloo.ca> papr...@csclub.uwaterloo.ca (Paul Prescod) writes:
>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?
Would this help...
(define make-function lambda)
(define first-in-list car)
(define rest-of-list cdr)
Daniel Wang
>>>>> "Sin-Yaw" == Sin-Yaw Wang <sin...@acm.org> writes:
Sin-Yaw> Henry Baker wrote:
>> > Gone are the days people (even professionals) change for computer.
>> 'Change' from what to what? Who is to say that infix is 'natural'?
>> If you ask 3rd graders, I think you'd get a real diversity of opinion
>> about this.
>>
>> 'Natural' is highly dependent on your context. I'm just guessing,
>> but I suspect that you find Chinese characters more 'natural' than
>> ASCII text.
Sin-Yaw> It is the computer scientists' challenge to bridge the gap of
Sin-Yaw> computer and human being. One of the task is to come up with a
Sin-Yaw> language that is efficient for both. One of the design
Sin-Yaw> trade-off is the slope of the learning curve.
It is the computer scientists challenge to not make silly claims about
psychological/sociological effects of computers without having the basic
peer reviewed psycholgoical/sociological research to back them up. There is
no a prior reason to believe that the "learning curve" of a language has any
bearing on the design/efficiencies/complexity of a given langauge.
>> I don't think that there was ever any argument about whether Lisp was
>> more productive (especially on Lisp machines). I think that the
>> question was whether the productivity was worth the extra cost, and
>> whether the result of this productivity could be delivered on
>> low-cost platforms.
Sin-Yaw> Wrong. Lisp is not more productive. Form 2 teams to do the
Sin-Yaw> same task, one using Lisp and the other use something else.
Sin-Yaw> See which one can accomplish with less resources. If your task
Sin-Yaw> is anything serious (a venture capitalist will invest on), the
Sin-Yaw> C++ team will win.
One should add hold all things other things equal repeat, replicate and
publish. I'm not aware of any such study in the litterature that can argue
either case. 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.
BTB To quote an exasperated PL designer...
"Don't we have better things to argue about other than the surface syntax."
Sin-Yaw Wang
Andreas Eder wrote:
> But there is evidence; there have been studies! Look at
> Haskell vs. Ada vs. C++ vs. Awk vs. ...
> An Experiment in Software Prototyping Productivity
> {hudak-paul, jones-mark}@cs.yale.edu
>
> and what was the result? You may have already guessed it, the Haskell and Lisp
> teams won by a great margin. And their code was according to the reviewers much clearer.
If Lisp is more productive, as the studies proved, why, then, did it
fail in the marketplace?
Because (and this is my opinion, not a fact) it is NOT productive to the
majority of the software engineers out there. For the elite group of
very bright, it is often the language of choice. For the rest 90%, who
managers need to hire, train, grow, and pamper, it is NOT more
productive.
You can be one of those elite super software engineer. You would love
Lisp or Scheme. Getting a large group of people (4 people or more) is a
different story.
Of course, if you have 4 bright engineers who all love Lisp, you are a
lucky manager. I envy you.
Sin-Yaw Wang
cosc...@bayou.uh.edu wrote:
> Oh more conclusive statements from a guy who can't even understand
> that syntax isn't the only thing to a language?
Wow, getting hostile here. When the debate gets personal, it also gets
boring.
> I await this mountain of evidence Sing-Yaw.
>
> : --
> : Sin-Yaw Wang, sin...@acm.org
> : http://www.concentric.net/~sinyaw/
Funny, even with my signature line right there, you spelled my name
wrong.
OK, guys, I do not have the evidence. But, Lisp did fail in the market
place. If you don't like my reasons, what are yours?
cosc...@bayou.uh.edu
Mike McDonald (mik...@engr.sgi.com) wrote:
: I believe that the reason Lisp has failed to be widely accepted is that for
: most programmers, their first and only exposure to Lisp is in some rinky dink
: "Introduction to AI" class. At the end of which, if they're lucky, they might
: have written programs like Eliza and a checkers player. I can understand why
: they don't think Lisp is good for anything real.
BINGO! That was my first introduction to Lisp and in fact my first
impression was "Screw this!".
But then after I understood the concepts of functional programming
I came back to Lisp. I still found the syntax rather bothersome
at first, but I looked beyond that. I looked at all the power,
all the capabilities, things which weren't apparent to me in
my "rinky dink AI class", and I thought "Not bad".
Now the parenthesis don't really bother me, neither does the non-infix
notation, and I'm quite happy with the language. It has some really
nice features, which are truly useful (actually makes me think
someone *THOUGHT* about putting this stuff in rather than C/C++
where useless functions were thrown about with obvious carelessness).
[Snip]
: Anyway, that's history and it's too late to do much about it now. The real
: question now is can anything be done to increase the acceptance of Lisp as a
: viable programming solution? I'm rather pessimistic about it. Heck, GUI's have
: been a requirement for any serious developement and delivery environment for at
: least eight years. Lisp still doesn't have a viable and convincing answer to
: that part.
Well the whole GUI question is one of implementation dependency.
I mean Lisp doesn't have a viable answer in that there is no
standardized mechanism for GUI programming, but different
implementations do provide different methods (Allegro Common Lisp
looked quite good). This is precisely the same support that
C/C++ provides -- zilch. Whether or not you get it, and how
you do it is entirely implementation dependent, and from the
implementations I've seen, they've got nothing to brag about.
From UNIX's motif library (tedium at its worst) to VC++
(even with "Visual Tools" it's still a mess), the fact that
Basic has made a comeback in the midst of this debacle should
tell you something.
Now then, there are those languages which have wisely decided to
make GUI programming their business, rather than an aside.
Concurrent Clean and Tcl/Tk (Tk more of a toolkit) come to
mind but they're still rather unique in this as most of the
languages I've seen simply avoided the issue.
: Mike McDonald
: mik...@engr.sgi.com
--
Cya,
Ahmed
Richard A. O'Keefe
Sin-Yaw Wang <sin...@acm.com> writes:
>I still assert that the more natural the syntax, the more productive
>your engineers. How can anyone dispute this fact?
Because there is no such animal as "natural syntax".
Excuse the personal reference, but from your name I guess you are
Chinese. Mandarin, like English, is a "syntaxful" language, where
most of the information about what part of an utterance links up
with what other part is in the order of the words. Native speakers
of English find it "natural" to use programming languages where the
relationships are shown by "prepositions" (actual English
prepositions in many cases) and by the order of lexemes. I would
expect native speakers of any of the major Chinese languages to
find the same kinds of things natural, although they might prefer
different orders.
But there are literally _thousands_ of other human languages, the
majority of them working on rather different principles. Nobody
ever asked the Russians (whose inflecting language has much freer
word order than English) whether C or Pascal was "natural", and
nobody ever asked the Australian aborigines (whose languages are
very free in the ordering thanks to extensive intra-word cross
referencing) what _they_ thought was "natural". Nor did anyone
consult Amerindians, speakers of Hindi, &c &c &c.
Consider just one simple example.
In English, we have
Subject Verb Object
which means that
x < y
links up perfectly with our speech (X is less than Y).
But all _six_ of the logically possible orders
SVO
SOV
OSV
OVS
VOS
VSO
are known in human languages, and many languages allow free choice
between several of them. In fact, the aboriginal language in my
home country is more-or-less a VSO language, so the speakers of
that language would find (< X Y) *MORE* natural than X < Y.
Heck, there are even languages that haven't got a comparative form,
so you have to say "is-big X, more-than Y".
If natural syntax were always more productive, we would expect COBOL
programmers in English-speaking countries to be the most productive
programmers in the world. COBOL really _does_ read pretty much like
English. But COBOL programmers are jumping at CASE tools, which do
things in very different ways!
So "How can anyone dispute this fact?"
Because it isn't a fact.
--
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
Erik Naggum <er...@naggum.no> writes:
>I still think the human potential is largely untapped, and that if you
>argue about what's natural to the majority as a measure of what you will
>not allow _anybody_ to do, or that what's "natural" to the _uneducated_ as
>a measure of what people should not have to learn, you're going to destroy
>everything that _is_ natural to human beings: self-fulfilment, happiness,
>security, progress, and growth.
The psychiatrist M. Scott Peck had something to say about this.
I'll have to paraphrase, because I haven't the book handy.
"It's nonsense to say you can't change human nature.
Human nature is to go to the toilet in your pants. Parents change that."
The point of education is to replace our natural ignorance and prejudice
with knowledge, skills, and judgement.
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 ...
He has a lovely little example on p5/6 where treating something as
an infix operator made it _harder_ to reason about.
Richard A. O'Keefe
Sin-Yaw Wang <sin...@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.
There are three separate and distinct propositions before us.
1. The more natural the syntax, the more productive the engineers.
I note that Sin-Yaw Wang has offered _no_ argument or evidence
for this, only bluster and intimidation.
2. Lisp is more/less natural.
Naturally, one has to ask, more/less natural than WHAT?
Sin-Yaw Wang coyly refuses to say.
3. Lisp is more/less productive.
Again, one must ask, more/less productive than WHAT?
THERE IS EVIDENCE THAT PROPOSITION 1 IS FALSE.
That evidence is the flight of COBOL programmers to 4GLs and CASE
tools, precisely because they are thought to be _more_ productive
than COBOL.
THERE IS EXPERIMENTAL EVIDENCE THAT PROPOSITION 3 IS FALSE,
comparing Lisp with C and C++.
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.]
Now this is an extremely interesting point. Pulling in a few
more statements from that chapter, and drawing some inferences,
- the productivity of the 90th-percentile _teams_ is FOUR TIMES
the productivity of the 15th-percentile teams.
- the productivity of the best _individuals_ is about TWENTY
times the productivity of the worst.
- productivity is correlated with the number of programming
languages that the person knows
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.
Now me, I've learned to find APL "natural", and Lisp, and Prolog,
and ML, and Fortran, and Ada, and .... In fact, just about the
only programming languages I _don't_ find natural are Intercal
and C++ (which greatly resembles it).
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.
I would also expect such a person to be aware that the overall
productivity of a _company_ is only loosely related to the productivity
of its _programmers_; sales, marketing, administration, shipping, &c all
have to be factored in.
I would also such a person to be aware that most programming is maintenance
programming. Discussions of whether language X or language Y would be more
productive is somewhat beside the point when you have a mountain of language
Z code to maintain. There being no perfect language translators that I know
of, even if you translate said mountain into language Y, _someone_ still has
to understand the old code well enough to see if the translation is right.
I would also expect such a person to be aware of the consequences of
re-use for productivity, and that 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. If, for example, it should be true that Lisp is
less productive than C++ (for which there is NO evidence), Lisp might
still win if Lisp code were easier to re-use. A priori, I would expect
that to be so, for the same reason that Smalltalk code is easier to
re-use than C++.
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.
Mike McDonald
In article <5eg0oj$t...@masala.cc.uh.edu>,
cosc...@Bayou.UH.EDU (cosc...@bayou.uh.edu) writes:
> Mike McDonald (mik...@engr.sgi.com) wrote:
>: Anyway, that's history and it's too late to do much about it now. The real
>: question now is can anything be done to increase the acceptance of Lisp as a
>: viable programming solution? I'm rather pessimistic about it. Heck, GUI's have
>: been a requirement for any serious developement and delivery environment for at
>: least eight years. Lisp still doesn't have a viable and convincing answer to
>: that part.
>
> Well the whole GUI question is one of implementation dependency.
> I mean Lisp doesn't have a viable answer in that there is no
> standardized mechanism for GUI programming, but different
> implementations do provide different methods (Allegro Common Lisp
> looked quite good). This is precisely the same support that
> C/C++ provides -- zilch. Whether or not you get it, and how
> you do it is entirely implementation dependent, and from the
> implementations I've seen, they've got nothing to brag about.
> From UNIX's motif library (tedium at its worst) to VC++
> (even with "Visual Tools" it's still a mess), the fact that
> Basic has made a comeback in the midst of this debacle should
> tell you something.
In the Unix world, I can pretty much count on a Motif library being available
for the machine, usually at a pretty "reasonable" cost. In the Lisp world under
Unix, there is no standard GUI library. The two major vendors push CLIM for
thousands of bucks. There is no cheap, compatible implementation for any of the
public domain lisps. So, I'm back to the position, when I need to have a GUI
for my code, I write the whole thing in C/C++. It's a pretty sad state of
affairs, from my point of view.
Mike McDonald
mik...@engr.sgi.com
cosc...@bayou.uh.edu
Daniel Wang (dan...@hart.CS.Princeton.EDU) wrote:
[Snip]
: [...] 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'd have to disagree. While environments can have a powerful effect
on productivity, the underlying language is still of tremendous
importance. How can an environment for say a low level language
give you the high level constructs necessary for dealing with
say higher order functions? An environment can't do that for
you. All it can do is make the tedious task of employing this
functionality more efficient, but you're still stuck providing
it. What about advanced data types like lists? Again a
powerful environment can't do anything for you there, you're
still stuck designing them. I could go on, but I think
my point is clear.
I've used a variety of environments and in my experience while
the environment may have made things easier, it did little
to address the problems of the underlying language itself.
I've used VC++, Emacs, and simple text editors with various
languages, and in my experience a powerful language with
zero environment still outdoes a weaker language with a
powerful environment by a substantial margin.
The best IDE I've seen, VC++ 4.0, couldn't even come close
to matching the productivity of Lisp running in a generic
text editor like Edit simply because when all was said and
done I was *STILL* programming in C++.
[Snip]
--
Cya,
Ahmed
One small step for man,
One goose step for mankind.
"Master Race in Outer Space", by the Vandals
Kevin Russell
In article <330b4d8a...@news.wam.umd.edu>, Robert Rodgers
<kn...@acm.org> wrote:
>I found Japanese to be very natural & easy when I took 4 years of it.
>Very little effort required to structure sentences&c.
>
>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. Contrast
As Erik said, people differ in this. I'm sure most of the people
reading this group took a lot less time. It might be helpful (or it might
not) to distinguish between learning to parse and learning to read a
program. It takes all of ten seconds to learn to parse statements in APL,
but really learning to *read* APL? Don't ask me -- I haven't managed it
yet, and I started in 1979. On the other hand, I can read and get the
gist of average C, but I couldn't parse it to save my life. Lisp is more
like APL on this count. Most people should quickly reach the point where
they can say "this is the function, this is the first argument, this is
the second argument." The problem isn't syntax, it's vocabulary: it
doesn't help your reading much to know what the name of the function is if
you have no clue what that function does. (There's the added glitch that
it might not even be a function, but a special form.)
I still have vocabulary problems with Lisp (as I've whined about
before here to unsympathetic audiences, sniff!), but the pure parsing part
is a piece of cake. Most of the time, I find I read Lisp as if it were
really a postfix language. I'll zoom right down to the most deeply
embedded expression and work my way back out again, taking only enough
time on my way in to make sure that I'm not dealing with a special form
like "if" or a short-circuit "and". Which, I'm told by wise ones, is
pretty much what the interpreter does. I guess that's why Lisp and I get
along so well.
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.
>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
Aside from their superficial differences in the order of arguments,
all of them. Maybe this is because those AI freaks in the late 50s wanted
their data structures to look like the domain they were modelling, or
maybe human language was simply evolution's premature attempt to invent
Scheme. :-)
>(you don't get *large* stacks of operands / operators, you get small
>ones, usually seperated into clauses).
Depends what you mean by "large" (and by "stacks"). Sentences in
natural languages do come in clauses, but they don't necessarity come
*separated into* clauses. More often you'll find the clauses embedded in
each other in ways that will drive you crazy if you ever have to analyze
them. Just like Lisp. Take "Because the guy who sold me C++ wasn't
honest, I'm going to spray-paint grafitti on his Porsche the next time I
see it." Five verbs, but not five separate clauses. Put brackets around
the clauses if you're ever bored enough, the result will look eeriely like
Lisp.
>I think I side with the original poster -- RPN & stack style languages
>really are quite unnatural (this doesn't make them bad). I don't
It is not the existence of stacks which is unnatural, only extreme
depths. Natural languages use recursion all the time. You can say
"The cheese has gone mouldy"
"The cheese that the rat ate has gone mouldy"
"The rat that has rabies ate the cheese"
You can put them together:
"The cheese that the rat that has rabies ate has gone mouldy"
You can deeper and deeper:
"The cheese that the rat that the cat that the dog that the farmer
bought bit chased ate has gone mouldy."
The difficulties people have with the last sentence don't come from
recursion or stacked operators, they come from our stack not being *big*
enough to handle it.
>(Justification for disagreeing on Japanese: the verb (such as it is)
>is at the end of the sentence (but you find verbals *throughout* a
>sentence in clauses), but you don't get constructions like "one two
>one three five add subtract divide equals." Lisp is not a mirror
>image of infix.)
Again, it's important to distinguish between what's possible and
what's usual (or convenient for our puny brains). I suspect that
something much like your example would obey all the grammatical rules of
Japanese. But Japanese speakers would avoid using it for the same reasons
English speakers avoid the last cheese sentence. Similarly, it's
theoretically possible to do it on a stack calculator (though not on my
HP, stack size is only four, poor thing), but skilled calculator users
will have developed a number of tricks that let them avoid it, like
judicious use of the x<->y button or memory registers. Similarly in Lisp,
the mirror image (duly decorated with parentheses) would be legal, but
programmers would often avoid it. They probably don't avoid things like
it as often as they should (assuming readable programs are their only goal),
but that's true no matter which language they use.
So there's something deeply natural about the way Lisp works. Many
verb-initial human languages work in a way that's extremely similar. The
strategies I use when dealing with verb-final languages have carried over
very easily to reading Lisp (though not quite so easily to writing it).
I'm not saying Lisp is the only natural way to do it. C works, ahem, all
right... Pascal works much the way a lot of "infixing" human languages do,
and many speakers of these languages legitimately have a hard time
adapting to prefix or postfix notation. The problem for Lisp is that the
infixing languages are the ones whose speakers own most of the computers.
(The problem for the speakers comes as soon as they have to define their
own prefix procedures in Pascal or C, though curiously I've never heard
that used as an argument for the fundamental unnaturalness of those
languages.)
All right, I've been procrastinating too long. Back to work.
-- Kevin
Patrick Giagnocavo
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.
While the other programmers working in C and C++ actually designed
toolkits and stuff that actually -worked-, sorta.
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.
Meanwhile, scores of messages scrolled by my newsreader concerning
Lisp's failure.
Seems most people would rather -talk- about things than actually expend
any effort in fixing them.
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?
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.
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?
Cordially
Patrick Giagnocavo
Will Hartung
papr...@csclub.uwaterloo.ca (Paul Prescod) writes:
>I think that the syntax of Lisp and Scheme are really a big part of what
>frightens people off. I can show you some ML code, and it has nice big
>function declarations, and the if/then/else constructs are familiar,
>patterns are a little weird-looking, but you expect some weird stuff in
>any new language. But ML is a functional programming language: it just uses
>syntax that is closer to mainstream programming languages.
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.
>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?
Absolutely not! It is one of the beauties of the language, to me. It
is SO consistent, because of its SIMPLE syntax. No periods,
semi-colons and asterisks to muddy the waters. My favorite Pascal
error message "Semi-colon required." makes me scream "Well! PUT ONE IN
(stupid machine)".
Lisps syntax is simple, clear, OBVIOUS (once you know the secret....oh
wait..THERE ISN'T ONE!), and elegant. The major Lisp challenges are
programming idiom and, parTICularly with CL, vocabulary.
Of course, these can not really be taught, per se, they can only be
exposed to the student who learns them through use.
Its like giving someone a pile of Lego(tm) Bricks.
"What can I build with them?"
"Anything you want!"
"But how do I start?"
"Why, with your first brick!"
>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.
Well, you know, that's the real trick. See, while there is a altruistic
side of me, I don't care THAT much about Joe Programmer. I care about
me. (That's the selfish side). Lisp is good for me, I think. I want to
not waste my time worrying about details that are not pertinent to my
task.
But, Lisp is not Mainstream. Lisp is not cascaded in glossy ads across the
printed spectrum. Lisp is not Blessed By Bill. So, it is not
"INSTANTLY OBVIOUS" to be a viable option for programming development
in my current professional environments.
I would like Lisp to appeal to Joe Progammer so that it would become
more mainstream, more glossy ads, and closer to Bill. That makes it
easier for ME to work in the language.
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.
Versus VB/C/C++/etc programmers who are there because it is the PLACE
to be, and any way they can convince themselves that they know enough
to put the bullet-point on their resume' is all they need to get
through the door.
Of course not all programmers are like this. They aren't all complete
dolts...but there are a LOT of 90 Day wonders who just finished "XYZ
in 21 Days", and feel they're bullet-point compliant. I've seen them,
my company has hired them, and I've had to fix their ******* code
after we've "let them go".
So...no, I really don't want Lisp for Joe Sixpack. I want Lisp for me,
and I'd like it an option where it works for me, my company, and its
clients. It's not there, yet. *I'm* not there yet. But one way or
another, it will be paying me in the next year or two.
--
Will Hartung - Rancho Santa Margarita. It's a dry heat. vfr...@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
With a mighty <330b5129...@news.wam.umd.edu>,
rsro...@wam.umd.edu wibbled into the void...
> 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.
Disclaimer: I'm unfamiliar with Abuse. All I know about is what I've
read about it online. I can, however, make some general comments about
language bigotry, based on my experience of a fair amount of it.
_If_ the performance of Abuse suffers in any way, then I doubt it's
purely because of the use of Lisp. Someone ignorant of Lisp
implementation techniques might assume that it was garbage collection
that was causing delays - and as far as I know, this _might_ be the
problem with Abuse - but this isn't a Lisp problem. If the people who
wrote Abuse used a Lisp compiler, perhaps producing bytecodes, then
the performance should be much better than if they used a Lisp
interpreter.
On the other hand, it could be that they knew more about Lisp and game
_design_ than game implementation, i.e. realtime multimedia. It might
also reflect the different attitudes of programmers using DOS and 68K
machines. The 68K machines may have invited fewer kludges, and they
should certainly have allowed 32bit code to be used, instead of 16bit.
> 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."
Perhaps Abuse should be compared to a game written in VB? A game
written in C++ by programmers with lots of animation experience should
be compared to a game written in a compiled Lisp, by programmers with
a similar degree of animation experience.
As you've said, you can't win with language bigots. They're unlikely
to look at all the factors that determine the performance of software.
This may be as true of the Lisp advicates as it is for C++ advocates.
Claming that Abuse is written in Lisp may be misleading.
I certainly think that making a similar claim for AutoCAD is
misleading. There are apps that use AutoCAD, witten in AutoLISP, but
that's far from the same thing IMHO. The C++ bigots may certainly make
such a distinction, even if one or two Lisp advocates (bigots?) prefer
not to. Instead, I think it would be better to say that AutoCAD is an
app that uses Lisp as its embedded language, allowing large numbers of
more specialised apps to be easily developed.
We should take care not to give the C++ advocates any more "ammo" than
they have already, by overselling Lisp with less than perfect
examples. We should be honest about Lisp's weaknesses, while focusing
on Lisp's _real_ strengths.
I'm sure that one or two Lisp advocates will disagree with this. ;-)
So, here's another disclaimer:
If someone can tell me that Abuse was entirely written in compiled
Lisp, and the yet the performance still sucks, then I'd expect that
the programmers who wrote were just very bad at animation. That would
still make Abuse a poor example of Lisp, IMHO, as not everyone will
understand the technology well enough to appreciate this.
If AutoCAD is entirely written in AutoLISP, then I'll be very happy.
However, that's not the impression given to me by everything I've ever
read about AutoCAD in magazines, over the years. Of course, journos
have been known to get a few details wrong...
> 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?
Some interesting techniques were used in QuickBasic, but they seem to
have not represented a trend in compiler design, at least for DOS.
Where did you read this, BTW? Perhaps it was written by someone
looking at a "niche" that may well exploit such techniques, but most
compilers ignore them.
Obviously there should be more _good_ examples of Lisp, like apps
written in Lisp that sell well, perform well, and don't fall over in a
strong breeze. The arguments supporting these clamims should also be
_watertight_. This is necessary bcause of the nature of advocacy,
where any _perceived_ weakness (it needn't be real at all!) will be
ruthlessly exploited.
I don't think this means that overstating the pro-Lisp arguments can
be excused. If we can't find watertight examples, then perhaps we're
no better than the C++ bigots. _We_ have to exploit the weaknesses in
the pro-C++ arguments - without cheating.
So, if there's any evidence that AutoCAD, Abuse, or any other popular
apps where high performance is vital, are written entirely in Lisp,
then I'd love to see it. If anyone wishes to mention HotMetal Pro,
then I should point out that this app has a few problems (it can
crash, it's not the fastest editor available, etc) which C++ advocates
could easily exploit. A pure SGML argument for using Lisp that refers
to HotMetal may be another matter, of course.
--
<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
With a mighty <5efl85$3...@fido.asd.sgi.com>,
mik...@engr.sgi.com wibbled into the void...
> I believe that the reason Lisp has failed to be widely accepted is that for
> most programmers, their first and only exposure to Lisp is in some rinky dink
> "Introduction to AI" class. At the end of which, if they're lucky, they might
> have written programs like Eliza and a checkers player. I can understand why
> they don't think Lisp is good for anything real.
Yes, this certainly doesn't help Lisp's image. "AI" is a dirty word in
many circles. Programmers like to think of themselves as "real
programmers", which may be very far from the truth, but it C++ does a
lot to support this myth.
I've seen the need for using assembly language for writing an MPEG
driver as an argument that even C/C++ is too high level! Good grief,
how many of us need to write device drivers, and does that have
anything to with the choice of a language for writing _apps_?
Special cases like this get used all the time, both for C++ _and_
Lisp. Just count the number of AI apps that get used to support the
pro-Lisp argument. To many people, this kind of argument will make C++
look good (to the C++ people), not Lisp!
It's one of those classic communication problems. Like the Douglas
Adams joke about humans and dolphins, each sees themselves as superior
for exactly the same reasons. Perhaps we need to change the language
used in pro-Lisp arguments? We could start by _never_ refering to AI.
> As for Symbolics part in the downfall of Lisp, sure, they contributed to the
> problem in some respects. They also built some of the nicest machines to do
> programming on that have ever been built. I only wish they could have gotten
> their act together so that they'd still be a viable option today. But they
> could never make up their mind as to whether they were a hardware or software
> company. (Attempting to be both is almost always fatal.) They also didn't want
> to face their competition, which was primarily Sun. When the Sun3 was first
> introduced, both Symbolics and Sun were about the same size, in terms of
> revenue. Symbolics decided that they were not in the "workstation" market. They
> were in the AI market. One of the all time stupidest moves ever. (And I told
> the president of Symbolics that at the time! (I still have my trusty Symbolics
> letter opener that I received as a result of that meeting.) Oh well.)
I agree about the hardware or software choice. Steve Jobs had that
problem, too. The dfference is that his product is now software only
(like Symbolics) but everyone is queueing up to stick OpenStep onto
their OS. Why are they not doing this for Genera? I believe that Open
Genera runs under OSF/1 on Alpha machines. That's a step in the right
direction.
> Anyway, that's history and it's too late to do much about it now. The real
> question now is can anything be done to increase the acceptance of Lisp as a
> viable programming solution? I'm rather pessimistic about it. Heck, GUI's have
> been a requirement for any serious developement and delivery environment for at
> least eight years. Lisp still doesn't have a viable and convincing answer to
> that part.
For Windows, Lisp has to compete against tools like VC++, VB and
Delphi. All these environments have strong support for platform
specific GUI features. Every Lisp for Windows that I know of seems to
lack such support. Lisp isn't alone in that respect, as MLWorks also
has vey weak GUI support. The development envionment may be excellent,
but that's not what Windows developers look for! Incredible, but true.
The answer may be painfully obvious: create a "Visual Lisp". Give it
strong support for OLE, ActiveX, and _all_ the MS technologies that
VC++/VB support, put the entire runtime system into a DLL, and we
_may_ possibly begin to see mass market software written in Lisp.
That should help sell the idea that the more traditional Lisps are
also worth using...
Teunis Peters
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
Tim Bradshaw
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
Martin Cracauer
Patrick Giagnocavo <pg...@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 cmuc...@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
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
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
Martin Cracauer
mik...@engr.sgi.com (Mike McDonald) writes:
> Anyway, that's history and it's too late to do much about it now. The real
>question now is can anything be done to increase the acceptance of Lisp as a
>viable programming solution? I'm rather pessimistic about it. Heck, GUI's have
>been a requirement for any serious developement and delivery environment for at
>least eight years. Lisp still doesn't have a viable and convincing answer to
>that part.
Well, CLIM is an excellet answer to some real requirements GUI
programms have. CLIM is the GUI toolkit that can adapt a given
application to the widest range of different environments with the
fewest application change demands.
But it has availiablity problems, to say at least.
Martin Cracauer
rsro...@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.
Scott Schwartz
Teunis Peters <snow...@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.
Henry Baker
In article <5efl85$3...@fido.asd.sgi.com>, mik...@engr.sgi.com (Mike
McDonald) wrote:
> I believe that the reason Lisp has failed to be widely accepted is that for
> most programmers, their first and only exposure to Lisp is in some rinky dink
> "Introduction to AI" class. At the end of which, if they're lucky, they might
> have written programs like Eliza and a checkers player. I can understand why
> they don't think Lisp is good for anything real.
Excellent point! Such a class usually uses a really bad (slow) implementation
of Lisp, and no decent parenthesis matching editor. Lisp has come a long way
from 1965, which is the kind of Lisp those courses teach.
> As for Symbolics part in the downfall of Lisp, sure, they contributed to the
> problem in some respects.
> When the Sun3 was first
> introduced, both Symbolics and Sun were about the same size, in terms of
> revenue. Symbolics decided that they were not in the "workstation" market.
> They were in the AI market. One of the all time stupidest moves ever.
Symbolics was crucified on the cross of 'gross margin', just like Apple
recently was. Some idiot investors who went to business school in the 1970's
got the hair-brained idea that you could charge a 'premium' price for a
'protected' market, and continue to get away with it. Both Apple and Symbolics
learned the hard way that _there are no 'protected' markets in the computer
business._ The idiots who made these decisions were out of both stocks long
ago, leaving the hulks to rust on the dustbin of history.
I think it is curious that Autodesk cannot kill AutoLisp, even after years
of trying very hard.
Rainer Joswig
In article <5egkr0$2...@Masala.CC.UH.EDU>, cosc...@Bayou.UH.EDU
(cosc...@bayou.uh.edu) wrote:
> The best IDE I've seen, VC++ 4.0, couldn't even come close
> to matching the productivity of Lisp running in a generic
> text editor like Edit simply because when all was said and
> done I was *STILL* programming in C++.
I'm biased. But Macintosh Common Lisp has a ***nice***
programming environment and with the work of Digitool
and their users things will improve a lot.
Also from an IDE point of view, I won't forget LispWorks.
LispWorks has some very nice graphical tools. AND ---
--- it will be released on Windows NT (this year I hope).
Alaric B. Williams
>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 : ala...@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>
Alaric B. Williams
>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
Alaric B. Williams
>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.
Rainer Joswig
In article <hbaker-2002...@10.0.2.1>, hba...@netcom.com (Henry
Baker) wrote:
> In article <5efl85$3...@fido.asd.sgi.com>, mik...@engr.sgi.com (Mike
> McDonald) wrote:
>
> > I believe that the reason Lisp has failed to be widely accepted is
that for
> > most programmers, their first and only exposure to Lisp is in some
rinky dink
> > "Introduction to AI" class. At the end of which, if they're lucky, they
might
> > have written programs like Eliza and a checkers player. I can understand why
> > they don't think Lisp is good for anything real.
>
> Excellent point! Such a class usually uses a really bad (slow) implementation
> of Lisp, and no decent parenthesis matching editor. Lisp has come a long way
> from 1965, which is the kind of Lisp those courses teach.
I know of a course where people teach Miranda with vi!
Well the theory is that people do learn unfamiliar concepts
with Lisp (recursion, list processing, combinators, ...),
so they think Lisp is weird. Teach imperative programming
uses Pascal or whatever. So people associated Lisp with
some unpleasant experiences ("thinking", "learning"!).
> I think it is curious that Autodesk cannot kill AutoLisp, even after years
> of trying very hard.
That is really funny. What is even more funny is that
they obviously not have tried to improve Autolisp. I
remember a posting from David Betz (the author of XLisp,
the Lisp that has been used by Autodesk), where he mentioned
that he has contacted them about improving AutoLisp and
the weren't interested. Still, people are using it.
So, there is another company that tries hard to
harm Lisp - still people use it.