Howdy,
My "Aha!" moment, put into words - well, my "Aha! AHA!" moment - my first
one came when I built a web app in 6 weeks in Lisp that me and a bunch of
other people couldn't finish in 2 years (MS tools & Java) and started
wondering what the hell this Lisp stuff was that it could affect the
space/time continuum so radically. It was like Archimedes paying me a visit,
saying, "See? That's called 'leverage'". Then I got sick. I got better! Now
I'm itchin' to get something going. :)
So I've got Hemlock running with editor windows and a Slave Lisp running and
I'm editing my web site, a server app, Hemlock, an experimental MOP and my
CLX application (CLX! It's a dinosaur and it's easy!) and I'm just changing
code and sending it to the Lisp process that's driving everything and
nothing's stopping, complaining, breaking or making life difficult and I
don't have to stop the world and build or wait for the compiler to tell me
about a missed semi-colon and it all works and I just finished half a dozen
features in the CLX app in no time, added CL code to extend Hemlock, updated
my web site using CL, extended my test framework for the MOP and it just hit
me - this Lisp stuff is amazing beyond words. All I knew before Lisp was
that I didn't know why, but I hated OOP. Now I know some of the limitations
and I got to build my own to learn how OOP works and how it can be evolved -
that alone is worth the price of admission. I guess having problems with
Emacs on this last system update and having to switch gears between CL and
elisp and getting frustrated and ilisp not working right and slime not
working right or maybe not installing right and not getting which and
feeling like I was wasting time on sys admin stuff and not developing and
giving up until my next system upgrade then finally realizing that gnu
wasn't something cool anymore and they were subverting the US Constitution
did I run over to Hemlock where all of a sudden, things just came together
REALLY WELL. Really well. Wow. Really, really, well. Lisp really is alive.
So I ask myself, "Self, what's out there for a lisp geek?" Where are the
jobs? Where are the companies that get this technology? Where is the funding
for Lisp companies? Tumble weeds(tm). Ghost towns(tm). Old Timers(tm) with
green teeth saying, "Lisp ain't been heard around these parts going on nigh
15 years." Is this some sort of twilight zone episode? Where's that Candid
Camera guy? This is a joke, right? I've slogged away in the bowels of major
software houses, never heard a peep about Lisp. I didn't just crawl out from
under a rock. All these Lisp programs have been available for eons. Why is
this language adopted by so few? Is it that there's a small "club" of
Lisp-based development houses that have a super-secret handshake and agree
to veil their work to make it look like Language "F" so people don't figure
out their Coke(tm) recipe? Do they lurk on c.l.l to dissuade people from
adopting Lisp by sounding surly and nasty? Has somebody hired a Voodoo
Priestess to stick pins in a Lisp-doll? If I don't get real answers soon,
I'm gonna bust. And don't give me that AI Winter crap. My meat-head
construction friends know the advantage of better tools and the importance
of saving time on the job to keep their job. We don't? We're supposed to be
educated. Well, you guys are - I'm sure the hell not.
AI winter - what a load. The first person I spoke with about Lisp worked for
McCarthy at Stanford in the 60's(? whenever, it was way back) and he told me
not to tell people I used Lisp, that it was career limiting to mention - and
he *loved Lisp*. In fact, all my "smart" programmer friends have said the
same thing, "Avoid Lisp. It'll ruin your career" (maybe they were really
saying, "Be One of Us. Be One of Us." - f*ckin' zombies). It's like IBM, Sun
and MS spiked the collective punch and we're all using tools that embody
Greenspun's Tenth. Are we devolving? Shouldn't we be GOING FORWARD?! Doing
more with less??!!! I thought we were supposed to be engineers and
scientists. Where's the science?! It's faster to write code in Lisp!!! It's
more stable! It's QUANTIFIABLE!! Call an accountant, call a banker, tell
them IT SAVES MONEY!!! Is this thing on?!?!?! Do something, somebody,
ANYBODY! Gilligan!!
Damn. Preachin' to the choir again. Better go out and find me some heathens
to convert. :)
Stand back, sucka. I feel good!
Mike
"Mike Ajemian" <············@verizon.net> writes:
> Stand back, sucka. I feel good!
Breathe, man, breathe...
--
Dave Roberts
dave -remove- AT findinglisp DoT com
http://www.findinglisp.com/
"Dave Roberts" <···········@remove-findinglisp.com> wrote in message
···················@linux.droberts.com...
> "Mike Ajemian" <············@verizon.net> writes:
>
> > Stand back, sucka. I feel good!
>
> Breathe, man, breathe...
>
Phew, thanks dude. Kind of lost it there for a second...
"Mike Ajemian" <············@verizon.net> writes:
> Is it that there's a small "club" of Lisp-based development houses
> that have a super-secret handshake and agree to veil their work to
> make it look like Language "F" so people don't figure out their
> Coke(tm) recipe?
The first rule of Lisp Club is, you do not talk about Lisp Club.
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@gigamonkeys.com> wrote:
> The first rule of Lisp Club is, you do not talk about Lisp Club.
Hilarious :)
You may find this amusing:
http://www.perlmonks.org/index.pl?node_id=131598
cheers,
S.
--
Stefano Rodighiero | http://larsen.perlmonk.org
·············@perl.it | http://www.perl.it
··················@tiscali.it (Stefano Rodighiero) writes:
> Peter Seibel <·····@gigamonkeys.com> wrote:
>
> > The first rule of Lisp Club is, you do not talk about Lisp Club.
>
> Hilarious :)
>
> You may find this amusing:
>
> http://www.perlmonks.org/index.pl?node_id=131598
Hmmm. Since Lisp has almost always been first, is:
http://www.dave.org.uk/talks/advocacy.html
Why Lisp is still a mystery to most people?
Certainly the Philadelphia Area Lisp Mongers are well hidden.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
"Peter Seibel" <·····@gigamonkeys.com> wrote in message
···················@gigamonkeys.com...
> "Mike Ajemian" <············@verizon.net> writes:
>
> > Is it that there's a small "club" of Lisp-based development houses
> > that have a super-secret handshake and agree to veil their work to
> > make it look like Language "F" so people don't figure out their
> > Coke(tm) recipe?
>
> The first rule of Lisp Club is, you do not talk about Lisp Club.
>
:) Got it.
"Mike Ajemian" <············@verizon.net> writes:
> this language adopted by so few? Is it that there's a small "club" of
> Lisp-based development houses that have a super-secret handshake and agree
> to veil their work to make it look like Language "F" so people don't figure
> out their Coke(tm) recipe? Do they lurk on c.l.l to dissuade people from
> adopting Lisp by sounding surly and nasty? Has somebody hired a Voodoo
By the way, the Coke recipe may not be so secret:
Urban Legends Reference Pages: Cokelore (Have a Cloak and a Smile)
http://www.snopes.com/cokelore/formula.asp
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
"Paolo Amoroso" <·······@mclink.it> wrote in message
···················@plato.moon.paoloamoroso.it...
> "Mike Ajemian" <············@verizon.net> writes:
>
> > this language adopted by so few? Is it that there's a small "club" of
> > Lisp-based development houses that have a super-secret handshake and
agree
> > to veil their work to make it look like Language "F" so people don't
figure
> > out their Coke(tm) recipe? Do they lurk on c.l.l to dissuade people from
> > adopting Lisp by sounding surly and nasty? Has somebody hired a Voodoo
>
> By the way, the Coke recipe may not be so secret:
>
> Urban Legends Reference Pages: Cokelore (Have a Cloak and a Smile)
> http://www.snopes.com/cokelore/formula.asp
>
Well, it used to be secret to me, thanks very much for ruining a good myth.
:) I suppose next you'll probably be telling me there's no "Great Pumpkin",
either...
Thanks for the link. The "Knew Coke" article was good, too.
Mike Ajemian wrote:
> AI winter - what a load. The first person I spoke with about Lisp
worked for
> McCarthy at Stanford in the 60's(? whenever, it was way back) and he
told me
> not to tell people
AI winter is over: we are in the new AI Spring. The National Science
Foundation has a number of new research programs and one of them
includes ... Artificial Intelligence!!
and it's OK to use Lisp. For pretty much all our research in the past
and current we have used Lisp. The biggest problem is to find new
students who really want to program in Lisp. It's actually becoming a
little simpler because CS is no longer the guaranteed path to wealth.
Realizing that doing the mainstream thing, e.g., coding Java from spec
sheets, may result in getting themselves outsourced, student are ready
to explore more exotic options.
One of my biggest problems is that it is hard to find a good Common
Lisp that motivates new students. All of our applications are heavily
graphics oriented. 2D/3D graphics, user interfaces, devices interfaces,
.... CL is great for this sort of stuff. We I change some OpenGL code
while a game is running student will pause and say: "oh my good, how
did you do that" This is the power of Lisp. Now you have their
attention. They tried to do the same things in C++ and it was not fun.
Some of the text books that apparently a number of c.l.l folks seem to
like (the we love car, cdr, and OO into in FINAL chapter kind) frankly
do a great job in keeping CL as a relict from the past right next to
punch cards. So, my claim is that most of the CL books are written for
people who are already sold, e.g., c.l.l. readers. There is a need to
have interesting apps and books connecting to the interests of 18 year
olds.
Alexander Repenning wrote:
> AI winter is over: we are in the new AI Spring. The National Science
> Foundation has a number of new research programs and one of them
> includes ... Artificial Intelligence!!
>
> and it's OK to use Lisp.
Uh-oh, I guess the bloody government pork is in the water, with big
obnoxious AI companies on the horizon... ;) I hope these fellows don't
deify/demonize the tools they happen to use, like last time...
A bit offtopic, I was actually curious when this spike in basic tech
research would happen. The big neocon organization explained a year
before 9-11 that technologically transforming the military "is likely
to be a long one, absent some catastrophic and catalyzing event -- like
a new Pearl Harbor." (p.51)
http://www.newamericancentury.org/RebuildingAmericasDefenses.pdf
Might not be too bad though. AI seems to be the search for general
solutions to problems, and it could go either way.
> For pretty much all our research in the past
> and current we have used Lisp. The biggest problem is to find new
> students who really want to program in Lisp. It's actually becoming
> a little simpler because CS is no longer the guaranteed path to
> wealth. Realizing that doing the mainstream thing, e.g., coding
> Java from spec sheets, may result in getting themselves outsourced,
> student are ready to explore more exotic options.
David Noble explores this well:
http://www.nooranch.com/synaesmedia/wiki/wiki.cgi?DavidNoble/ForcesOfProduction
Java is fundamentally a deskilling tech. Which makes outsourcing
easier. The entire reason I like Lisp is because it lends itself to a
usage which augments skill, rather than commoditizing it.
> Some of the text books that apparently a number of c.l.l folks seem
> to like (the we love car, cdr, and OO into in FINAL chapter kind)
> frankly do a great job in keeping CL as a relict from the past right
> next to punch cards. So, my claim is that most of the CL books are
> written for people who are already sold, e.g., c.l.l. readers.
> There is a need to have interesting apps and books connecting to the
> interests of 18 year olds.
I think we have the bling... the "hipness" to show today's youth that
we can "play dat." With high amounts of relevantness, youngsters can
get into the Lisp "groove," as it were.
In fact, this book was written with today's kids in mind, giving them a
wholesome magical tour of relevant topics like mp3 piracy:
http://www.gigamonkeys.com/book/
Parents would be flattered to know it also covers safe sexp with "unit"
testing. From reading comp.lang.lisp, I can confidently say Lisp users
spend many hours testing and polishing their units, which naturally
keeps them safe from viruses. Or any buffer overflow resulting from
contact with promiscuous sources.
Tayssir John Gabbour wrote:
> Parents would be flattered to know it also covers safe sexp with "unit"
> testing. From reading comp.lang.lisp, I can confidently say Lisp users
> spend many hours testing and polishing their units, which naturally
> keeps them safe from viruses. Or any buffer overflow resulting from
> contact with promiscuous sources.
>
Don't indulge in unprotected Software EXchange. Always use a firewall.
I don't do the latter, but I don't have any open Windows, either, which
limits the amount of viruses coming in. And I only exchange software
with trusted entities.
As for Lisp, it makes you more flexible than the 08/15 Java coder. Try
some new macro-positions sometime. If you don't want to, you can always
use LOOP and DO.
"Alexander Repenning" <·····@cs.colorado.edu> writes:
> Some of the text books that apparently a number of c.l.l folks seem to
> like (the we love car, cdr, and OO into in FINAL chapter kind) frankly
> do a great job in keeping CL as a relict from the past right next to
> punch cards. So, my claim is that most of the CL books are written for
Any specific examples? Have you checked Peter Seibel's upcoming
"Practical Common Lisp" book?
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Paolo Amoroso wrote:
> "Alexander Repenning" <·····@cs.colorado.edu> writes:
>
> > Some of the text books that apparently a number of c.l.l folks seem
to
> > like (the we love car, cdr, and OO into in FINAL chapter kind)
frankly
> > do a great job in keeping CL as a relict from the past right next
to
> > punch cards. So, my claim is that most of the CL books are written
for
>
> Any specific examples? Have you checked Peter Seibel's upcoming
> "Practical Common Lisp" book?
>
>
> Paolo
"OnLisp" has failed pretty consistently to excite students. "ANSI
Common Lisp" is OK but from the same author who is proud to say about
CLOS " I've never used it once." Well, ... it shows.
Most students want to hack on applications involving GUIs, event
handling, sounds, movies, 2d/3d graphics, etc. OOP is pretty important
for these kinds of applications. CLOS provides great ways of wrapping
up and extending high functionality APIs. To that end any Lisp book
that does not take CLOS seriously is of little value to me. To take
CLOS serious does not just mean to cover it with a chapter but to be an
author who is also an actual and excited user of CLOS.
I have not completely reviewed "Practical Common Lisp" but from what I
have looked at so far it does look very promising.
Alex
Alexander Repenning wrote:
> "OnLisp" has failed pretty consistently to excite students. "ANSI
> Common Lisp" is OK but from the same author who is proud to say about
> CLOS " I've never used it once." Well, ... it shows.
On Lisp is the thing that finally made me curious enough to put Lisp on
my to-learn list.
> Most students want to hack on applications involving GUIs, event
> handling, sounds, movies, 2d/3d graphics, etc. OOP is pretty important
> for these kinds of applications. CLOS provides great ways of wrapping
> up and extending high functionality APIs. To that end any Lisp book
> that does not take CLOS seriously is of little value to me. To take
> CLOS serious does not just mean to cover it with a chapter but to be an
> author who is also an actual and excited user of CLOS.
I hate OOP. The kind of generic functions that CLOS seems to allow more
freedom than something like Java and go hand in hand with procedural
programming.
> I have not completely reviewed "Practical Common Lisp" but from what I
> have looked at so far it does look very promising.
I think I'll get PCL when it comes out, and read On Lisp after that.
Ulrich Hobelmann wrote:
> Alexander Repenning wrote:
>
>> "OnLisp" has failed pretty consistently to excite students. "ANSI
>> Common Lisp" is OK but from the same author who is proud to say about
>> CLOS " I've never used it once." Well, ... it shows.
>
>
> On Lisp is the thing that finally made me curious enough to put Lisp on
> my to-learn list.
>
>> Most students want to hack on applications involving GUIs, event
>> handling, sounds, movies, 2d/3d graphics, etc. OOP is pretty important
>> for these kinds of applications. CLOS provides great ways of wrapping
>> up and extending high functionality APIs. To that end any Lisp book
>> that does not take CLOS seriously is of little value to me. To take
>> CLOS serious does not just mean to cover it with a chapter but to be an
>> author who is also an actual and excited user of CLOS.
>
>
> I hate OOP. The kind of generic functions that CLOS seems to allow more
> freedom than something like Java and...
Hang on. Do you hate OOP or Java? Sounds like you like CLOS. Is CLOS not
OOP? If it is, then you like what you hate. It happens.
:)
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton wrote:
>> I hate OOP. The kind of generic functions that CLOS seems to allow
>> more freedom than something like Java and...
>
>
> Hang on. Do you hate OOP or Java? Sounds like you like CLOS. Is CLOS not
> OOP? If it is, then you like what you hate. It happens.
>
> :)
I think it's not just Java, though that might be an important part of
it. I don't like mixing data structures with functions too closely,
even though, say, the syntax of C++ over C structures (bla = 5; instead
of foo->bla = 5;) is nice.
Haskell type classes or Java interfaces (= collections of generic
functions for one type) are better, since now you can just parameterize,
say, qsort with a list of Foos and the FooCompare function, without
having to include that function in the Foo object (maybe you can't; it's
closed-source?).
Also, lots of functions really don't belong into a class (string -> int;
is this a function of class string, or of class int? I think it's just
a function), but in Java they have to, including code duplication.
But Smalltalk (probably Self too) and most other OO languages with
classes would share this problem.
I don't know CLOS yet, so I can't comment on that, but the code I've
seen seems to define classes und functions separately :)
Anyway, I wouldn't call something like Haskell OO, even though at some
level the concepts are the same. OO for 99% of all programmers means
classes and (= subtyping inheritance) and stuff like that. I say noo to oo.
Spake Alexander Repenning:
> "OnLisp" has failed pretty consistently to excite students. "ANSI
> Common Lisp" is OK but from the same author who is proud to say about
> CLOS " I've never used it once." Well, ... it shows.
I like it. I had got as far in C as needing GENSYM for my macros when I
first turned to Lisp as something to do on the holidays. On Lisp
explains well the phenomena I was encountering, so I can now say e.g.
"variable capture" instead of having to describe it by example.
The universities I've been to have been pumping OO into students as hard
as they can. It's a relief to have a break from that.
(Having said that, I'm looking forward to reading PCL for doing `real'
things with Lisp. But I'm gonna finish On Lisp first.)
--
Trent Buck, Student Errant
<foo>I'll probably just go into work next week and kill everyone.
<bar>I do that all the time.
Alexander Repenning wrote:
> Paolo Amoroso wrote:
>
>>"Alexander Repenning" <·····@cs.colorado.edu> writes:
>>
>>
>>>Some of the text books that apparently a number of c.l.l folks seem
>
> to
>
>>>like (the we love car, cdr, and OO into in FINAL chapter kind)
>
> frankly
>
>>>do a great job in keeping CL as a relict from the past right next
>
> to
>
>>>punch cards. So, my claim is that most of the CL books are written
>
> for
>
>>Any specific examples? Have you checked Peter Seibel's upcoming
>>"Practical Common Lisp" book?
>>
>>
>>Paolo
>
>
> "OnLisp" has failed pretty consistently to excite students. "ANSI
> Common Lisp" is OK but from the same author who is proud to say about
> CLOS " I've never used it once." Well, ... it shows.
>
> Most students want to hack on applications involving GUIs, event
> handling, sounds, movies, 2d/3d graphics, etc. OOP is pretty important
> for these kinds of applications. CLOS provides great ways of wrapping
> up and extending high functionality APIs. To that end any Lisp book
> that does not take CLOS seriously is of little value to me. To take
> CLOS serious does not just mean to cover it with a chapter but to be an
> author who is also an actual and excited user of CLOS.
>
> I have not completely reviewed "Practical Common Lisp" but from what I
> have looked at so far it does look very promising.
I thought you were a CLOS snob. Last I heard, PCL's author does not
believe in inheritance, let alone multiple inheritance. And one
practical example I looked at used first-class functions as attributes,
where GFs specialized on subclasses should have been used to achieve
specialization.
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton <·······@nyc.rr.com> writes:
> Alexander Repenning wrote:
>> I have not completely reviewed "Practical Common Lisp" but from
>> what I have looked at so far it does look very promising.
>
> I thought you were a CLOS snob. Last I heard, PCL's author does not
> believe in inheritance, let alone multiple inheritance. And one
> practical example I looked at used first-class functions as
> attributes, where GFs specialized on subclasses should have been
> used to achieve specialization.
Nah, I just believe in using the right tool for the job at hand with
needlessly hairing things up. And who says I don't like multiple
inheritance--the binary data framework in Chapter 24 explicitly
supports multiple inheritance and he then uses that facility in
chapter 25.
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Alexander Repenning wrote:
>
>
>>>I have not completely reviewed "Practical Common Lisp" but from
>>>what I have looked at so far it does look very promising.
>>
>>I thought you were a CLOS snob. Last I heard, PCL's author does not
>>believe in inheritance, let alone multiple inheritance. And one
>>practical example I looked at used first-class functions as
>>attributes, where GFs specialized on subclasses should have been
>>used to achieve specialization.
>
>
> Nah, I just believe in using the right tool for the job at hand with
> needlessly hairing things up. And who says I don't like multiple
> inheritance--the binary data framework in Chapter 24 explicitly
> supports multiple inheritance and he then uses that facility in
> chapter 25.
Time for a Road to Inheritance survey?
:)
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
From: Josip Gracin
Subject: Modifying code "on the fly", Was: I get it
Date:
Message-ID: <d0fpcb$4b4$1@sunce.iskon.hr>
Alexander Repenning wrote:
> .... CL is great for this sort of stuff. We I change some OpenGL code
> while a game is running...
Being a newbie in CL, I don't quite understand CL's ability to change the
code while program is running. Does this mean I need to manually provide a
separate thread for REPL while other threads are doing their stuff?
Josip Gracin <······@tel.fer.hr> writes:
> Alexander Repenning wrote:
> > .... CL is great for this sort of stuff. We I change some OpenGL code
> > while a game is running...
>
> Being a newbie in CL, I don't quite understand CL's ability to change the
> code while program is running. Does this mean I need to manually provide a
> separate thread for REPL while other threads are doing their stuff?
Not necessarily.
If you don't have threads, you can still interrupt the program (C-c),
which drops you into the debugger by default, giving you a REPL. Of
course, while you're in the debugger REPL, the program doesn't
progress. But you can redefine functions, and in the next loop, the
new functions will be used instead of the old.
Note that in both cases, functions currently executing (in the call
stack), are not substituted. But new calls will refer the new
functions.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Litter box not here.
You must have moved it again.
I'll poop in the sink.
From: Josip Gracin
Subject: Re: Modifying code "on the fly", Was: I get it
Date:
Message-ID: <d0g19d$d2o$1@sunce.iskon.hr>
Pascal Bourguignon <····@mouse-potato.com> writes:
> If you don't have threads, you can still interrupt the program (C-c),
> which drops you into the debugger by default, giving you a REPL. Of
> course, while you're in the debugger REPL, the program doesn't
> progress. But you can redefine functions, and in the next loop, the
> new functions will be used instead of the old.
>
> Note that in both cases, functions currently executing (in the call
> stack), are not substituted. But new calls will refer the new
> functions.
I'm not sure about this, unless the redefined function is declared
notinline.
Andras
"Alexander Repenning" <·····@cs.colorado.edu> wrote in message
·····························@z14g2000cwz.googlegroups.com...
>
> Mike Ajemian wrote:
>
> > AI winter - what a load. The first person I spoke with about Lisp
> worked for
> > McCarthy at Stanford in the 60's(? whenever, it was way back) and he
> told me
> > not to tell people
>
> AI winter is over: we are in the new AI Spring. The National Science
> Foundation has a number of new research programs and one of them
> includes ... Artificial Intelligence!!
>
> and it's OK to use Lisp. For pretty much all our research in the past
> and current we have used Lisp. The biggest problem is to find new
> students who really want to program in Lisp. It's actually becoming a
> little simpler because CS is no longer the guaranteed path to wealth.
> Realizing that doing the mainstream thing, e.g., coding Java from spec
> sheets, may result in getting themselves outsourced, student are ready
> to explore more exotic options.
>
> One of my biggest problems is that it is hard to find a good Common
> Lisp that motivates new students. All of our applications are heavily
> graphics oriented. 2D/3D graphics, user interfaces, devices interfaces,
> .... CL is great for this sort of stuff. We I change some OpenGL code
> while a game is running student will pause and say: "oh my good, how
> did you do that" This is the power of Lisp. Now you have their
> attention. They tried to do the same things in C++ and it was not fun.
>
> Some of the text books that apparently a number of c.l.l folks seem to
> like (the we love car, cdr, and OO into in FINAL chapter kind) frankly
> do a great job in keeping CL as a relict from the past right next to
> punch cards. So, my claim is that most of the CL books are written for
> people who are already sold, e.g., c.l.l. readers. There is a need to
> have interesting apps and books connecting to the interests of 18 year
> olds.
>
Well, thank frickin' goodness things are changing. :) I wish you and your cs
students, prodigy and slacker alike, much success. Hope their brains grow
like sequoia trees. Figuratively. Of course.
WRT the book thing. I didn't come from academia and found Paul Graham's
books at Borders. I think I read about 30 pages at the store of ANSI Common
Lisp, liked what I read and bought the book and the one sitting next to it
by the same guy. That was enough to get me started studying Lisp. I started
using the language in parallel with a project I was working on pretty much
right away - after the train ride home. It was obvious from the start that
the Lisp code came together faster than the Java I was writing because the
code was modifying a running program and the language was more expressive.
His book was enough to get me through one oop project, although his
treatment of oop is spartan. I think On Lisp is an amazing book. Hard to
approach, but once there, awesome. Agree that some new books which cover
greater depth can only be beneficial to the growth and acceptance of the
language. (I use CLtL2, On Lisp and AMOP as my other references. Like
Steele's book, especially the index where entries like that for "kludge" are
good for a laugh.) Would like to see a book composed of essays on OOP in CL.
Also, on creating interfaces - that's been an amazingly difficult nut to
crack solely for the dearth of examples.
I still think that AI winter stuff is a crock, though. In competition, the
advantage is to the swift, strong and/or smart. Lisp is faster, providing
shorter time to market. For company's with profit motive, ignoring Lisp has
been like willingly running a sprint while towing a 400-pound sled. Ergo,
therefore, and suchwith, AI winter is the symbolic abstraction for the
millions of reasons people got tired of fighting and advocating for Lisp and
just gave up. Forgetting that basic Trump-ism, "Never Lose The Fight". Maybe
that was Lao Tzu. Hard to tell the difference sometimes.
Mike
"Mike Ajemian" <············@verizon.net> writes:
> I still think that AI winter stuff is a crock, though. In competition, the
> advantage is to the swift, strong and/or smart. Lisp is faster, providing
> shorter time to market. For company's with profit motive, ignoring Lisp has
> been like willingly running a sprint while towing a 400-pound sled. Ergo,
> therefore, and suchwith, AI winter is the symbolic abstraction for the
> millions of reasons people got tired of fighting and advocating for Lisp and
> just gave up. Forgetting that basic Trump-ism, "Never Lose The Fight". Maybe
> that was Lao Tzu. Hard to tell the difference sometimes.
The AI winter was a reality, and it wasn't due to lack of trying or
giving up.
As an analogy, the Sun was never any colder during the Ice Age, nor
(we think) was the Earth any farther away from it, but its warming
effects simply could not counteract whatever cataclysm overwhelmed
the Earth with cold. Now one can scientifically state that cold is
simply the lack of heat, but in the case of the Ice Age, that
explanation just isn't adequate to explain the forces at work, or
in fact to explain how the Earth came back out of the Ice Age, all
other things being equal. Whatever cataclysm is used to explain
the effect, it was surely both unique and temporary, but during its
influence it had a strong positive heat-subtraction influence on
the parts of the Earth affected.
Now, back to Lisp and AI: The AI winter was in fact an active campaign
by management of many organizations to specifically reject AI (and,
per guilt by assiciation, Lisp), rather than a removal of efforts by
those who were pro-AI/pro-Lisp. What caused this sudden cataclysm?
The promulgation of hype (either actively, or by failing to warn
against downsides) about what Lisp and AI could do within the next
10 years at that time. The hype was very promising, and perhaps
those not in the know extrapolated unscientifically as to what the
implications were. Examples:
- When "Block World" was created, the TV "science" shows were
running rampant about how Asimov's worlds were coming true, and
"thinking machines" would be prevalent within 10 years (it hasn't
yet happened).
- Speech synthesis was predicted, and even accomplished, within
the normal timeframe of the AI peak. But the voices were unnatural,
and only now are voices sounding more natural and esthetic.
- Speech recognition was predicted, but took a lot longer than
predicted (probably by about 20 years, by my own observation).
- etc.
Anyway, those corporations that could profit most by AI technology
and who were taken in by (or manufacutred some of) this hype dumped
billions of dollars into the projects, and most got absolutely
nothing out of them, or at least close enough to nothing to call
the projects disasters.
If you were a manager, and you dumped a billion dollars into
a specific piece of technology that had a 0% ROI, then regardless of
why the technology failed to meet your expectations, what would
you be saying about that technology today, if you actually managed to
keep your job? Or, in fact, if you had been fired over it, and
had been forced to take lower-paying jobs elsewhere, what would you
do when the technology came across your desk? Would such a reaction
be rational? Might anybody even know why you despise AI and Lisp?
We in the newly blossoming Lisp industry must never make the same
mistake again. We must never hype the abilities of Lisp; we must
instead show solid facts for what Lisp can do. I see alarming trends
in this area; the old myths of Lisp being 10X more efficient than
other languages is resurfacing - let's face it; there is no hard data,
and the anecdotal data points to 2 to 4 times design efficiency,
rather than 10X that has been shown. A single case of 10X does not
qualify as evidence; in the presence of subjective and anectdotal
data we should take advice from Gymnastics scoring techniques, where
one highest and one lowest score are tossed out routinely to ensure
that the curve is more accurately centered at the mean.
That 400 pound sled you described used to be much heavier.
It must be on a diet, because it is shedding pounds. But we must
also be careful not to add to its weight. The dogs are still
pulling (arf, arf) and we canines are growing in number, but the
weight of the sled will determine whether or not the sled will
move. I do know many people who got tired of pulling the sled.
There weren't millions of reasons; there was only one: it was
too heavy. Some have come back.
You can trivialize the AI winter, but please don't be revisionist
about it, if you didn't live through it. It happened, and if you
don't recognize it you are doomed to repeat its mistakes.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
[on hype and AI Winter]
> We in the newly blossoming Lisp industry must never make the same
> mistake again. We must never hype the abilities of Lisp; we must
> instead show solid facts for what Lisp can do. I see alarming trends
> in this area; the old myths of Lisp being 10X more efficient than
> other languages is resurfacing - let's face it; there is no hard data,
> and the anecdotal data points to 2 to 4 times design efficiency,
> rather than 10X that has been shown. A single case of 10X does not
> qualify as evidence; in the presence of subjective and anectdotal
> data we should take advice from Gymnastics scoring techniques, where
> one highest and one lowest score are tossed out routinely to ensure
> that the curve is more accurately centered at the mean.
I agree with the above. I enjoy Lisp more than any other programming
language I have ever used. While I don't think I'm near my maximum
potential productivity with the language due to my inexperience with
it, I don't think that Lisp is inherently more productive to use than
other VHLLs like Perl, Python, Tcl, etc. I would rank it about the
same. My rational for this is that my personal experience seems to
agree with the theory that a programmer on average produces about the
same number of lines of code per day regardless of the language used.
There are other limits on programmer productivity that Lisp can not
fix. Lack of domain knowledge would be at or near the top of the
list. Lack of familiarity with an algorithm or algorithmic complexity
will also get in the way. These things are fundemental to programming
and the language doesn't really matter. This is a separate issue from
implementation.
Programming languages generally do not stand alone. There are also
development environments. I'm currently using Emacs + SLIME as my
Lisp IDE. I haven't mastered these tools yet because I spend time
looking up things in the hyperspec or Apple's documentation (I'm
trying to develope a native OS X application). For obvious reasons
there isn't the level of integration that Xcode offers. I often have
Xcode running as well to help me look up Carbon documentation with
Xcode's help feature. These things present me with a somewhat steep
learning curve and not the most efficient work flow (although that is
improving).
At least a beginning VB programmer on Windows has the illusion of
progress by drawing up a GUI. I'm just hoping that my initial
investment will have better returns down the road. I actually choose
Lisp for what I think is a good reason. I want a built in extension
language that is powerful enough to use to develop the actual
application.
In conclusion, the barriers to my productivity really have nothing to
do with Lisp itself. But I am using Lisp. If I don't achieve what I
want, an observer could easily make the mistake of blaming Lisp
instead of the real culprit especially since I tend to advocate Lisp
to my friends (who mostly don't want to hear about it).
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber wrote:
> Duane Rettig <·····@franz.com> writes:
>
> [on hype and AI Winter]
>
>
>>We in the newly blossoming Lisp industry must never make the same
>>mistake again. We must never hype the abilities of Lisp; we must
>>instead show solid facts for what Lisp can do. I see alarming trends
>>in this area; the old myths of Lisp being 10X more efficient than
>>other languages is resurfacing - let's face it; there is no hard data,
>>and the anecdotal data points to 2 to 4 times design efficiency,
>>rather than 10X that has been shown.
Nonsense! First you say the numbers are no good, then you try to give
them legitimacy by saying the "right" number is 2-4, not 10!!
Look, there is probably no way we will ever measure programmer
productivity. Given a general task, two solutions will likely vary
wildly in the extensibility/power/maintainability of the code (and I am
not even saying which language will have been used by the author of the
better code). Given a tight spec, we are no longer measuring
productivity, because normally coding is designing.
But there is no need for numbers. Jeez, just use Common Lisp for a week
and you'll be running around saying it is ten times better. Note that in
the case, the numbers are never meant to be taken literally. When I say
something is two times better, I mean "a lot". When I say ten times, I
mean "a whole lot".
Are youse guys saying Lisp is not a whole lot better?!
A single case of 10X does not
>>qualify as evidence; in the presence of subjective and anectdotal
>>data we should take advice from Gymnastics scoring techniques, where
>>one highest and one lowest score are tossed out routinely to ensure
>>that the curve is more accurately centered at the mean.
Nonsense! What a capricious, arbitrary, desperate attempt to get good
numbers out of bad! Who says the low scoring judge did not see some
gaffe the others missed? Who says the high scoring judge did not see
subtle perfection others missed while looking for grandiose tricks?
hell, why not throw out the middle scores on the premise that they must
be the judges so unsure of their ability to assess performance that they
simply put of middle values in the hope of not having some announcer
saying, "And there's an inexplicable 5.9 from the Swedish judge."?
> it, I don't think that Lisp is inherently more productive to use than
> other VHLLs like Perl, Python, Tcl, etc.
Now you are scaring me.
I would rank it about the
> same. My rational for this is that my personal experience seems to
> agree with the theory that a programmer on average produces about the
> same number of lines of code per day regardless of the language used.
Ouch. Ok, we have no way of getting a good metric on programmer
productivity, but we /have/ determined that a given programmer is
LOC-constant? How could I measure my LOC?
:)
kenny
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
From: Duane Rettig
Subject: Re: Productivity With Lisp (was Re: I get it)
Date:
Message-ID: <4k6ogwtw9.fsf@franz.com>
Kenny Tilton <·······@nyc.rr.com> writes:
> David Steuber wrote:
>
> > Duane Rettig <·····@franz.com> writes:
> > [on hype and AI Winter]
>
> >
>
> >>We in the newly blossoming Lisp industry must never make the same
> >>mistake again. We must never hype the abilities of Lisp; we must
> >>instead show solid facts for what Lisp can do. I see alarming trends
> >>in this area; the old myths of Lisp being 10X more efficient than
> >>other languages is resurfacing - let's face it; there is no hard data,
> >>and the anecdotal data points to 2 to 4 times design efficiency,
> >>rather than 10X that has been shown.
>
> Nonsense! First you say the numbers are no good, then you try to give
> them legitimacy by saying the "right" number is 2-4, not 10!!
If the right number _is_ 2-4, and not 10, then why is it nonsense?
It's not the numbers I'm opposed to, it's the numbers!
> Look, there is probably no way we will ever measure programmer
> productivity. Given a general task, two solutions will likely vary
> wildly in the extensibility/power/maintainability of the code (and I
> am not even saying which language will have been used by the author of
> the better code). Given a tight spec, we are no longer measuring
> productivity, because normally coding is designing.
It's a lot less than that. But that's not the reason we won't ever
measure programmer productivity in our lifetimes. Let's be honest;
the reason why nobody will ever measure our productivity is because
we don't _want_ to be measured, and we can get away with it. But
given a programmer who is willing (or subjected) to being measured,
there will be measurements taken. The measurements are usually wrong,
because they don't take into consideration the complexities of the
whole software lifetime analsysis, like the hardware companies are
forced to do, but I believe that people will eventually understand
the "Mythical Man Month" and assign better numbers to it.
> But there is no need for numbers. Jeez, just use Common Lisp for a
> week and you'll be running around saying it is ten times better. Note
> that in the case, the numbers are never meant to be taken
> literally. When I say something is two times better, I mean "a
> lot". When I say ten times, I mean "a whole lot".
It depends on how big your lot is. People throw around factors much
too often. The problem with factors is, they don't scale. It's just
like Amdahl's Law. If you are 10X more productive in one specific
area, but that area covers 1/10th of your total time spent, then how
much more productive are you, really?
If you're going to use hyperbole, at least do a constant one: "Lisp
beats the others by a mile!" That way, the size of your mile is
not hyped up by the size of your project, and if you have a tiny
project, you can win big, and if the Lisp portion of your project
is only mile-wide with respect to the galatic proportions of the
rest of your project, you don't end up looking like a liar or a
fool.
> Are youse guys saying Lisp is not a whole lot better?!
[Putting on my best Stalone accent: ] Absho-loot-lay!
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Duane Rettig
Subject: Re: Productivity With Lisp (was Re: I get it)
Date:
Message-ID: <4fyz4wshm.fsf@franz.com>
Duane Rettig <·····@franz.com> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Are youse guys saying Lisp is not a whole lot better?!
>
> [Putting on my best Stalone accent: ] Absho-loot-lay!
Taking a more serious look at this:
Lisp is not a whole lot better than other languages, though it
tends to be better:
- The reason it is better is because of the efforts that have
been put into it by many who love the language. It is not
automatic, but hard-fought. It is not inherent in the language,
because eventually all language-war arguments come down to a
question of Turing-completeness. It is possible that Lisp's
very age (coupled with good design choices) is what gives it
its biggest advantage.
We can agonize over the fact that other languages have added
concepts invented in the Lisp community and are catching up,
or we can celebrate the fact that ours are the concepts
worth catching up to, and we can continue working hard to ensure
that we continue to supply the other languages with concepts
worth catching up to.
- There are areas where Lisp is _not_ better. We don't like to
talk about them, but they are there. Is this a problem? No, it
is a challenge. Where other languages have found better concepts,
we should embrace them and catch up.
My fear for the Lisp community is that it will slip back into
the same arrogance that eventually brought on the disasters of
the '90s. It would be the same arrogance that I saw in
Silicon Valley in the late '90s that resulted in the .com bust.
It wasn't that either community had nothing to offer, but it
had to do with how each presented what they did have. We should
not present what we don't have; we should call it what it is,
and no more.
Fortunately, the fear of the kind I have can easily be allayed,
because it stems from attitudes. If we shake off attitudes that
are destructive, then I believe that there is very little that
the Lisp community could not do.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> Duane Rettig <·····@franz.com> writes:
>
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> > > Are youse guys saying Lisp is not a whole lot better?!
> >
> > [Putting on my best Stalone accent: ] Absho-loot-lay!
>
> [...]
>
> Fortunately, the fear of the kind I have can easily be allayed,
> because it stems from attitudes. If we shake off attitudes that
> are destructive, then I believe that there is very little that
> the Lisp community could not do.
I'm not sure why, but, while reading this dialog between you two, I had
an instantaneous association to the intro scene of Maniac Mansion 2:
Day of the Tentacle (DoTT) where the evil Purple Tentacle makes the
decision to strive for world domination and the Green Tentacle attempts
to dissuade him, vainly. (That game was probably after your time, I
guess)
--tcr.
From: Duane Rettig
Subject: Re: Productivity With Lisp (was Re: I get it)
Date:
Message-ID: <47jkgwkyu.fsf@franz.com>
"Tobias C. Rittweiler" <······@freebits.de> writes:
> Duane Rettig wrote:
>
> > Duane Rettig <·····@franz.com> writes:
> >
> > > Kenny Tilton <·······@nyc.rr.com> writes:
> > >
> > > > Are youse guys saying Lisp is not a whole lot better?!
> > >
> > > [Putting on my best Stalone accent: ] Absho-loot-lay!
> >
> > [...]
> >
> > Fortunately, the fear of the kind I have can easily be allayed,
> > because it stems from attitudes. If we shake off attitudes that
> > are destructive, then I believe that there is very little that
> > the Lisp community could not do.
>
> I'm not sure why, but, while reading this dialog between you two, I had
> an instantaneous association to the intro scene of Maniac Mansion 2:
> Day of the Tentacle (DoTT) where the evil Purple Tentacle makes the
> decision to strive for world domination and the Green Tentacle attempts
> to dissuade him, vainly.
Which one am I?
Are these tentacles attached to the same octopus? Talk about "the
right hand not knowing what the left is doing"!
> (That game was probably after your time, I guess)
Yes.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
[catching up frantically now that I have a weekend free from working in
SF... ironically I'm catching up mostly on stuff SF-area'ers write..]
Duane Rettig <·····@franz.com> writes:
> Fortunately, the fear of the kind I have can easily be allayed,
> because it stems from attitudes. If we shake off attitudes that
> are destructive, then I believe that there is very little that
> the Lisp community could not do.
Nice discussion here, and excellent points.
The key is that the less we claim we can do, the more we will
succeessfully do.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain <·····@nyct.net> writes:
> The key is that the less we claim we can do, the more we will
> succeessfully do.
I think the key is the more we do, the more we do; claiming is largely
orthogonal to doing.
Christophe
Kenny Tilton <·······@nyc.rr.com> writes:
> Ouch. Ok, we have no way of getting a good metric on programmer
> productivity, but we /have/ determined that a given programmer is
> LOC-constant? How could I measure my LOC?
wc -l
I don't know a good way to measure productivity. There is some
discussion of it here:
http://c2.com/cgi/wiki?HowFastCanYouWriteCode
This paper is rather more interesting:
http://home.pacbell.net/ouster/scripting.html
There are fundamental constraints on how fast I can get things done.
One of them is how quickly I can type in code. Lisp helps by reducing
the amount of code I have to type in. Often as not though I find
myself going back and factoring the code down into something better
than I first thought of that is even fewer lines. So now I've spent
time writing the first iteration of code and then more time trimming
it down.
LOC is more a measure of my bandwith to the computer than actual
productivity.
I also have my good days and my bad days. On a bad day, nothing gets
done. On a good day I can get a fair bit done. I haven't measured
the ratio of good days to bad or those in between days. Good days are
more of a function of how well my brain is working and not really
related to the language I'm using.
A bad language will get in the way though and Lisp is fairly decent at
not getting in the way.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
From: Duane Rettig
Subject: Re: Productivity With Lisp (was Re: I get it)
Date:
Message-ID: <43bv4wk6l.fsf@franz.com>
David Steuber <·····@david-steuber.com> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Ouch. Ok, we have no way of getting a good metric on programmer
> > productivity, but we /have/ determined that a given programmer is
> > LOC-constant? How could I measure my LOC?
>
> wc -l
I assume that this measurement comes with some kind of delta
calculation. It would be ludicrous to just measure total LOC
(i.e. "In the end, the boy with the most LOC wins"). Presumably
you would subtract the result today from the result yesterday.
> I don't know a good way to measure productivity. There is some
> discussion of it here:
>
> http://c2.com/cgi/wiki?HowFastCanYouWriteCode
>
> This paper is rather more interesting:
>
> http://home.pacbell.net/ouster/scripting.html
>
> There are fundamental constraints on how fast I can get things done.
> One of them is how quickly I can type in code. Lisp helps by reducing
> the amount of code I have to type in. Often as not though I find
> myself going back and factoring the code down into something better
> than I first thought of that is even fewer lines. So now I've spent
> time writing the first iteration of code and then more time trimming
> it down.
>
> LOC is more a measure of my bandwith to the computer than actual
> productivity.
When the goal is to write lines of code, them LOC is the best and most
direct measurement. However, how would you amortize this measurement
against the time you spend doing other things (like reading this NG?)
In fact, if you believe the Mythical Man Month (don't have a copy, so
I am not sure about the numbers) it turns out that in a regular
software project, a very small percentage is spent in actual coding.
A sizeable portion is spent in fixing initial bugs (which sometimes
leads to more lines, or sometimes less) and by far the largest portion
of time is spent on maintenance of the code. In that mode, the goal
is loc _elimination_ not generation. You must be able to figure
in the rewrite and removal as weighted measurements as well. I
consider proper code removal to be more desirable than proper code
addition, because the former leads to less code to maintain, and the
latter leads to more code to maintain.
> I also have my good days and my bad days. On a bad day, nothing gets
> done. On a good day I can get a fair bit done. I haven't measured
> the ratio of good days to bad or those in between days. Good days are
> more of a function of how well my brain is working and not really
> related to the language I'm using.
Instead of thinking of them as "bad days" and "good days", consider the
total gestalt of being a programmer, and think of those bad days as
necessary times for the internment of your programming models, and
for better focus when the time comes to code again.
> A bad language will get in the way though and Lisp is fairly decent at
> not getting in the way.
I agree.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> David Steuber <·····@david-steuber.com> writes:
>
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> > > Ouch. Ok, we have no way of getting a good metric on programmer
> > > productivity, but we /have/ determined that a given programmer is
> > > LOC-constant? How could I measure my LOC?
> >
> > wc -l
>
> I assume that this measurement comes with some kind of delta
> calculation. It would be ludicrous to just measure total LOC
> (i.e. "In the end, the boy with the most LOC wins"). Presumably
> you would subtract the result today from the result yesterday.
No, for that you need a proper revision control system like CVS or
some such. With CVS, there are all sorts of things you can measure.
I think Wade is correct that to be scientific, you need something that
can be measured.
> > I don't know a good way to measure productivity. There is some
> > discussion of it here:
> >
> > http://c2.com/cgi/wiki?HowFastCanYouWriteCode
> >
> > This paper is rather more interesting:
> >
> > http://home.pacbell.net/ouster/scripting.html
> >
> > There are fundamental constraints on how fast I can get things done.
> > One of them is how quickly I can type in code. Lisp helps by reducing
> > the amount of code I have to type in. Often as not though I find
> > myself going back and factoring the code down into something better
> > than I first thought of that is even fewer lines. So now I've spent
> > time writing the first iteration of code and then more time trimming
> > it down.
> >
> > LOC is more a measure of my bandwith to the computer than actual
> > productivity.
>
> When the goal is to write lines of code, them LOC is the best and most
> direct measurement. However, how would you amortize this measurement
> against the time you spend doing other things (like reading this NG?)
> In fact, if you believe the Mythical Man Month (don't have a copy, so
> I am not sure about the numbers) it turns out that in a regular
> software project, a very small percentage is spent in actual coding.
> A sizeable portion is spent in fixing initial bugs (which sometimes
> leads to more lines, or sometimes less) and by far the largest portion
> of time is spent on maintenance of the code. In that mode, the goal
> is loc _elimination_ not generation. You must be able to figure
> in the rewrite and removal as weighted measurements as well. I
> consider proper code removal to be more desirable than proper code
> addition, because the former leads to less code to maintain, and the
> latter leads to more code to maintain.
I agree. What I find myself doing is code removal (at least I often
do that). I was quite happy to learn about CLOS's EQL specialization
because it allowed me to remove and restructure code in a much nicer
way.
> > I also have my good days and my bad days. On a bad day, nothing gets
> > done. On a good day I can get a fair bit done. I haven't measured
> > the ratio of good days to bad or those in between days. Good days are
> > more of a function of how well my brain is working and not really
> > related to the language I'm using.
>
> Instead of thinking of them as "bad days" and "good days", consider the
> total gestalt of being a programmer, and think of those bad days as
> necessary times for the internment of your programming models, and
> for better focus when the time comes to code again.
That is definitely a more positive spin. I think you are right
though. Sometimes the code has to sit a bit to gell so that when you
come back you can better judge if it is the right way to do it.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
From: Wade Humeniuk
Subject: Re: Productivity With Lisp (was Re: I get it)
Date:
Message-ID: <Xo_Xd.21171$gJ3.2570@clgrps13>
David Steuber wrote:
> LOC is more a measure of my bandwith to the computer than actual
> productivity.
>
Actually it is a measurement of your ability to make concrete your
ideas. There is no productivity without actual results. You can
think and think and plan and plan, but without it actually becoming
externalized it does not exist. To be scientific one has to measure.
LOC is measurable, keystrokes is measurable, meeting programming goals
are measurable. Other things are measurable. Unfortunately,
thinking is not yet measurable, so
if someone sees you sitting around they cannot know if you
are actually progressing to a solution. In fact you cannot even
know if you are progressing to a solution. Experience shows
we can progress to a solution, but how does one know? Its by seeing
working code being produced, which is (whether one likes it or not)
seeing LOC and seeing that functional goals are being met.
> I also have my good days and my bad days. On a bad day, nothing gets
> done. On a good day I can get a fair bit done. I haven't measured
> the ratio of good days to bad or those in between days. Good days are
> more of a function of how well my brain is working and not really
> related to the language I'm using.
>
Personally I have found that my "bad" days tend to caused by
some psychological resistance to proceeding to a solution. Usually
it means I am close to committing to an idea, but something keeps me
from "pushing" it to completion. Now I try to just to push ahead
and ignore my internal inertia. It is more important that I get some
coding actually done. In the movie "Finding Nemo" there is a little
ditty "Keep on Swimming, Swimming, Swimming ...". Or the Nike Inc.
trademark saying "Just Do It." . For me, good advice.
> A bad language will get in the way though and Lisp is fairly decent at
> not getting in the way.
>
Another 10x argument. One's personal quirks are 100x more influential
than one's language choice.
Wade
Wade wrote
> To be scientific one has to measure. LOC is measurable,
> keystrokes is measurable, meeting programming goals are
> measurable. Other things are measurable. Unfortunately,
> thinking is not yet measurable, so if someone sees you
> sitting around they cannot know if you are actually
> progressing to a solution. In fact you cannot even know
> if you are progressing to a solution. Experience shows we
> can progress to a solution, but how does one know? Its by
> seeing working code being produced, which is (whether one
> likes it or not) seeing LOC and seeing that functional
> goals are being met.
Lines of code are a cost. The equivalent in automobile
engineering is the number of parts in a car design. We
esteem a car designer more highly because his design uses
fewer parts.
Lines of code are a cost. The equivalent in die and mould
design is the number of parts in a mould. We consider a
mould all the more practical for having few parts.
Lines of code are a cost. The equivalent in rocketry is the
fuel that is burned. We consider the Saturn V a mighty
rocket because of the payload it lifts. We would be
delighted if it needed less hydrogen to do it.
How much do they cost? Imagine that Alice has taken 6 weeks
to implement a function in 1000 lines. Imagine instead that
Bob took 5 weeks to implement the function in 2000
lines. Whose employer has got the better deal? If Marianne
the maintenance programmer understands Alice's code in half
the time, because it is half as long, and fixes bugs in it
in half the time, because it is half as long, what does her
employer save over the life cycle of the software? $5000,
$10000. Probably much more than a weeks wages.
So perhaps producing a line of code destroys $5 or $10 of
value.
Wade writes:
> Its by seeing working code being produced, which is
> (whether one likes it or not) seeing LOC and seeing that
> functional goals are being met.
but meeting functional goals is positive, contributing to
productivity, and writing LOC is negative, subtracting from
productivity.
I've seen this kind of thing before and write about it here:
http://www.cawtech.freeserve.co.uk/cost-benefit-simplification.2.html
Wade is using a ``simplification'' of cost/benefit analysis
I call Proportional Benefit, in which costs are used as a
proxy for benefits.
Such an approach requires a prior measurement of the
constant of proportionality. Suppose that we already know
that C# and JAVA are equally expressive. Then we find that
C# programmers are producing 30 lines a day, while JAVA
programmers are productin 20. We can conclude that C# is 50%
more productive than JAVA. Or suppose instead that we
already know that C# is twice as wordy as JAVA, and C#
programmers outperform JAVA programmers by 30 lines a day
instead of 20. Then we conclude that JAVA is more
productive.
But where could such numbers possibly come from? We would
need a study in which JAVA programmers and C# programmers
compete to implement the same functionally to the same
standards of documentation and maintainability. Suppose we
get some results
kLOC Man-Months kLOC kLOC
per Man-Month per function
JAVA 100 50 2 100
C# 225 75 3 225
At first sight C# is more productive, 3 kLOC per Man-month
as against 2. But we have to allow for verbosity.
milliFunctions per Man-month comes from dividing LOC per
Man-month by kLOC per function
JAVA 2000/100 = 20 mFunctions per Man-month
C# 3000/225 = 13.3 mFunctions per Man-month
So JAVA is 50% more productive.
The point I'm making is that we knew this answer immediately
we saw that JAVA took 50 Man-months and C# took 75. The
general point is that the Lines of Code cancel. Although
using LOC as a proxy is popular it is absurd. LOC is in both
the numerator determining the productivity, and in the
denominator, determining the verbosity.
Worse, although using LOC as a proxy is futile, it is not
entirely harmless, because it obscures the moderately
important point that LOC are a cost, and other things being
equal one would prefer to have fewer of them, rather than more.
Alan Crowe
Edinburgh
Scotland
Alan Crowe wrote:
> Worse, although using LOC as a proxy is futile, it is not
> entirely harmless, because it obscures the moderately
> important point that LOC are a cost, and other things being
> equal one would prefer to have fewer of them, rather than more.
Well, in that case LOC would be a useful indicator -- less is generally
more desirable.
And I think there are measurements which are useful. Such as "library
leakage": how much does a library call force more code to be written,
in order to support it? For example in Java, reading a file requires
you to write try/finally scaffolding.
Also, damage can be measured by how many lines of code you must modify.
Java's checked exceptions force me to damage lots of code.
Alan Crowe wrote:
>>Its by seeing working code being produced, which is
>>(whether one likes it or not) seeing LOC and seeing that
>>functional goals are being met.
>
>
> but meeting functional goals is positive, contributing to
> productivity, and writing LOC is negative, subtracting from
> productivity.
>
This is wrong. The mistake in the reasoning is that you need
some code to accomplish any functional goals. So not all
LOC are negative, in reality some has to exist. But what
is the number? I am not advocating LOC as a measurement
of productivity, but working code as a measurement that
_anything_ is actually happening. If there is no code,
there is no productivity. I think LOC is useful as
a statistical measurement to gauge the size and complexity
of a software project. As with all statistics if the
sample size is large enough you can make assertions about
LOC and productivity, because in general all the variations
will cancel one another out. (also the reality is the more
functionality, the more code is needed).
Also I personally do not think language choice has much
bearing on a large software project's productivity. My
personal experience has been that other project issues
take much more time and money. Large software products need
large administrative configuration efforts (though I ardently
hope for the day they do not).
Wade
Wade Humeniuk <··················@telus.net> writes:
> Alan Crowe wrote:
>
>>> Its by seeing working code being produced, which is (whether one
>>> likes it or not) seeing LOC and seeing that functional goals are
>>> being met. but meeting functional goals is positive, contributing
>>> to productivity, and writing LOC is negative, subtracting from
>>> productivity.
>
> This is wrong. The mistake in the reasoning is that you need some
> code to accomplish any functional goals. So not all LOC are
> negative, in reality some has to exist.
Don't you need some parts to make a machine? Does that mean that the
parts required to make the machine are free? And you only have to pay
for the "extra" parts. Seems to me Alan's analogy is apt--each line of
code is a hand-tooled, custom part for a very complex machine. Each
one costs a fair bit, both to make and to maintain. The fact that you
can't make a machine out of no parts just means that you can't make a
machine for free.
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
>
> Don't you need some parts to make a machine? Does that mean that the
> parts required to make the machine are free? And you only have to pay
> for the "extra" parts. Seems to me Alan's analogy is apt--each line of
> code is a hand-tooled, custom part for a very complex machine. Each
> one costs a fair bit, both to make and to maintain. The fact that you
> can't make a machine out of no parts just means that you can't make a
> machine for free.
>
I see your point. However Alan stated that meeting functional goals
is positive, but that involves writing code, which is a negative. How
can a negative produce a positive? BTW I agree that meeting functional
goals is a positive. One could write 10,000 lines which does not
meet a functional goal, one's productivity is basically zero. Another
could write 200 (or a 1,000,000) and meet the functional goal.
Their productivity is infinitely greater. But as someone observing
the progress of a project, if nothing was being written, then one
could get very worried irrespective of whether the goal is reached.
You would know that productivity is headed towards zero. There has
to be some place for LOC as being feedback that something is
proceeding. And on the other hand, blind counting of code is
dangerous, it would be far better if a responsible reviewer
checked whether the code was moving towards meeting a goal.
Wade
From: Christopher C. Stacy
Subject: Re: Productivity With Lisp (was Re: I get it)
Date:
Message-ID: <uu0nh762y.fsf@news.dtpq.com>
Wade Humeniuk <··················@telus.net> writes:
> Peter Seibel wrote:
>
> > Don't you need some parts to make a machine? Does that mean that the
> > parts required to make the machine are free? And you only have to pay
> > for the "extra" parts. Seems to me Alan's analogy is apt--each line of
> > code is a hand-tooled, custom part for a very complex machine. Each
> > one costs a fair bit, both to make and to maintain. The fact that you
> > can't make a machine out of no parts just means that you can't make a
> > machine for free.
> >
>
> I see your point. However Alan stated that meeting functional goals
> is positive, but that involves writing code, which is a negative. How
> can a negative produce a positive?
It takes code to make code?
······@news.dtpq.com (Christopher C. Stacy) writes:
> Wade Humeniuk <··················@telus.net> writes:
>
>> Peter Seibel wrote:
>>
>> > Don't you need some parts to make a machine? Does that mean that the
>> > parts required to make the machine are free? And you only have to pay
>> > for the "extra" parts. Seems to me Alan's analogy is apt--each line of
>> > code is a hand-tooled, custom part for a very complex machine. Each
>> > one costs a fair bit, both to make and to maintain. The fact that you
>> > can't make a machine out of no parts just means that you can't make a
>> > machine for free.
>> >
>>
>> I see your point. However Alan stated that meeting functional goals
>> is positive, but that involves writing code, which is a negative. How
>> can a negative produce a positive?
>
> It takes code to make code?
You gotta spend money to make money.
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Wade Humeniuk <··················@telus.net> writes:
> Peter Seibel wrote:
>
> > Don't you need some parts to make a machine? Does that mean that the
> > parts required to make the machine are free? And you only have to pay
> > for the "extra" parts. Seems to me Alan's analogy is apt--each line of
> > code is a hand-tooled, custom part for a very complex machine. Each
> > one costs a fair bit, both to make and to maintain. The fact that you
> > can't make a machine out of no parts just means that you can't make a
> > machine for free.
> >
>
> I see your point. However Alan stated that meeting functional goals
> is positive, but that involves writing code, which is a negative. How
> can a negative produce a positive?
Obviously the point is that the two are at odds. Clearly, getting the
functionality with zero lines of code is optimal (perhaps by means of
some form of magic or "AI" - as in the goofy Star Trek ask the
computer and get the result: "Computer, generate a full ERP system
with the following characteristics. Bla bla bla...." and N
hours/minutes later out pops the result). In reality, this is always
(at least until the magic arrives) non zero, i.e., there is a cost,
i.e., a negative. The only question left is "is the result worth the
cost?"
> But as someone observing the progress of a project, if nothing was
> being written, then one could get very worried irrespective of
> whether the goal is reached. You would know that productivity is
> headed towards zero.
You would know nothing of the sort. That is a completely invalid
conclusion. Admittedly most manager/suit types would indeed "come to"
this conclusion. For any given case _it might turn out_ to be true,
but the "reasoning" is invalid.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
From: Wade Humeniuk
Subject: Re: Productivity With Lisp (was Re: I get it)
Date:
Message-ID: <N6tYd.42203$fc4.186@edtnps89>
Peter Seibel wrote:
>
> Don't you need some parts to make a machine? Does that mean that the
> parts required to make the machine are free? And you only have to pay
> for the "extra" parts. Seems to me Alan's analogy is apt--each line of
> code is a hand-tooled, custom part for a very complex machine. Each
> one costs a fair bit, both to make and to maintain. The fact that you
> can't make a machine out of no parts just means that you can't make a
> machine for free.
>
On further thought...
Based on the human view of productivity in these modern times,
any costs are viewed as a drain on productivity.
We have become the instant-on culture, where
there is only negative productivity marks for anyone's effort.
If people could have it with zero-time and zero-effort, they would.
Even LOC have become suspect, where programmers are not trusted
to be somewhat reasonable. God-damn those initial efficiency
engineers (I think it was those time and motion studies) :).
Someone better hurry up and create that programming-program
(preferably in Lisp).
Wade
Alan Crowe <····@cawtech.freeserve.co.uk> writes:
In general, your points are well put.
> But where could such numbers possibly come from? We would
> need a study in which JAVA programmers and C# programmers
> compete to implement the same functionally to the same
> standards of documentation and maintainability. Suppose we
> get some results
>
> kLOC Man-Months kLOC kLOC
> per Man-Month per function
>
> JAVA 100 50 2 100
>
> C# 225 75 3 225
This begins to get at why any notion of rigorous, good experimental
methodological results wrt productivity measures in the context of
software development (languages, tools, people, whatever) is a non
starter. You indeed need studies of the level you indicate here to
even begin to have legitimate answers. And, in fact, you would need a
_lot_ of them. OTOH, even one is unlikely due to the large time frame
and expense involved. We're more than likely talking millions of $$
here for even one decent such study. No _company_ is _ever_ going to
do this, universities have no hope of finding the resources for it
(and besides it lacks any kind of "fundamental research" character,
and the public sector doesn't appear even remotely interested.
Basically, for these sorts of _serious_ economic reasons, there has
never been such a study and for the same reasons it is extremely
unlikely that you will ever see such a study let alone the dozens
(perhaps hundreds) needed to get anything like good results.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay wrote:
> Alan Crowe <····@cawtech.freeserve.co.uk> writes:
>
> In general, your points are well put.
>
>
>
>>But where could such numbers possibly come from? We would
>>need a study in which JAVA programmers and C# programmers
>>compete to implement the same functionally to the same
>>standards of documentation and maintainability. Suppose we
>>get some results
>>
>> kLOC Man-Months kLOC kLOC
>> per Man-Month per function
>>
>>JAVA 100 50 2 100
>>
>>C# 225 75 3 225
>
>
> This begins to get at why any notion of rigorous, good experimental
> methodological results wrt productivity measures in the context of
> software development (languages, tools, people, whatever) is a non
> starter. You indeed need studies of the level you indicate here to
> even begin to have legitimate answers. And, in fact, you would need a
> _lot_ of them. OTOH, even one is unlikely due to the large time frame
> and expense involved. We're more than likely talking millions of $$
> here for even one decent such study. No _company_ is _ever_ going to
> do this, universities have no hope of finding the resources for it
> (and besides it lacks any kind of "fundamental research" character,
> and the public sector doesn't appear even remotely interested.
>
> Basically, for these sorts of _serious_ economic reasons, there has
> never been such a study and for the same reasons it is extremely
> unlikely that you will ever see such a study let alone the dozens
> (perhaps hundreds) needed to get anything like good results.
Nonsense. I have been playing a lot of GT4 lately, and believe you me,
when I am behind the wheel of a fully outfitted race car I need exactly
one turn to know it.
Study schmudy. Take any good programmer and have them play with language
X for a week and they will tell you how it compares.
Identifying good programmers is left as an exercise.
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
On Mon, 14 Mar 2005 05:26:59 +0000, Kenny Tilton wrote:
> jayessay wrote:
>> Basically, for these sorts of _serious_ economic reasons, there has
>> never been such a study and for the same reasons it is extremely
>> unlikely that you will ever see such a study let alone the dozens
>> (perhaps hundreds) needed to get anything like good results.
>
> Nonsense. I have been playing a lot of GT4 lately, and believe you me,
> when I am behind the wheel of a fully outfitted race car I need exactly
> one turn to know it.
>
> Study schmudy. Take any good programmer and have them play with language
> X for a week and they will tell you how it compares.
Although I agree, this is of course a very subjective metric and only
studies could turn up something that anyone else but a good programmer or
that even rarer person, a good manager, could be bothered to take into
account when making language/system decisions.
>
> Identifying good programmers is left as an exercise.
And that is even more subjective. It seems the easiest way is the 'it
takes one to know one' approach, but you'll have to find a good programmer
first for that... (well, not you personally, Kenny... ;-)
--
Christopher
Christopher Koppler wrote:
> On Mon, 14 Mar 2005 05:26:59 +0000, Kenny Tilton wrote:
>
>
>>jayessay wrote:
>
>
>>>Basically, for these sorts of _serious_ economic reasons, there has
>>>never been such a study and for the same reasons it is extremely
>>>unlikely that you will ever see such a study let alone the dozens
>>>(perhaps hundreds) needed to get anything like good results.
>>
>>Nonsense. I have been playing a lot of GT4 lately, and believe you me,
>>when I am behind the wheel of a fully outfitted race car I need exactly
>>one turn to know it.
>>
>>Study schmudy. Take any good programmer and have them play with language
>>X for a week and they will tell you how it compares.
>
>
> Although I agree, this is of course a very subjective metric and only
> studies could turn up something...
Really? I just get an introductory text on a language and start banging
out code, usually with a fun problem I have been thinking about
tackling. And given that we all agree no useful study is even possible...
:)
kenny
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton <·······@nyc.rr.com> writes:
> jayessay wrote:
> > Alan Crowe <····@cawtech.freeserve.co.uk> writes:
> > In general, your points are well put.
> >
> >>But where could such numbers possibly come from? We would
> >>need a study in which JAVA programmers and C# programmers
> >>compete to implement the same functionally to the same
> >>standards of documentation and maintainability. Suppose we
> >>get some results
> >>
> >> kLOC Man-Months kLOC kLOC
> >> per Man-Month per function
> >>
> >>JAVA 100 50 2 100
> >>
> >>C# 225 75 3 225
> > This begins to get at why any notion of rigorous, good experimental
> > methodological results wrt productivity measures in the context of
> > software development (languages, tools, people, whatever) is a non
> > starter. You indeed need studies of the level you indicate here to
> > even begin to have legitimate answers. And, in fact, you would need a
> > _lot_ of them. OTOH, even one is unlikely due to the large time frame
> > and expense involved. We're more than likely talking millions of $$
> > here for even one decent such study. No _company_ is _ever_ going to
> > do this, universities have no hope of finding the resources for it
> > (and besides it lacks any kind of "fundamental research" character,
> > and the public sector doesn't appear even remotely interested.
> > Basically, for these sorts of _serious_ economic reasons, there has
> > never been such a study and for the same reasons it is extremely
> > unlikely that you will ever see such a study let alone the dozens
> > (perhaps hundreds) needed to get anything like good results.
>
> Nonsense. I have been playing a lot of GT4 lately, and believe you me,
> when I am behind the wheel of a fully outfitted race car I need
> exactly one turn to know it.
Obviously irrelevant to the points at hand.
> Study schmudy. Take any good programmer and have them play with
> language X for a week and they will tell you how it compares.
And exactly how is this in any way in conflict with the points made?
I actually tend to agree with you on this, but even one of your
monkey's should be able to see it has nothing to do with getting,
using, or having anything like rigorous supporting information as to
the truth of the claim.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>jayessay wrote:
>>
>>>Alan Crowe <····@cawtech.freeserve.co.uk> writes:
>>>In general, your points are well put.
>>>
>>>
>>>>But where could such numbers possibly come from? We would
>>>>need a study in which JAVA programmers and C# programmers
>>>>compete to implement the same functionally to the same
>>>>standards of documentation and maintainability. Suppose we
>>>>get some results
>>>>
>>>> kLOC Man-Months kLOC kLOC
>>>> per Man-Month per function
>>>>
>>>>JAVA 100 50 2 100
>>>>
>>>>C# 225 75 3 225
>>>
>>>This begins to get at why any notion of rigorous, good experimental
>>>methodological results wrt productivity measures in the context of
>>>software development (languages, tools, people, whatever) is a non
>>>starter. You indeed need studies of the level you indicate here to
>>>even begin to have legitimate answers. And, in fact, you would need a
>>>_lot_ of them. OTOH, even one is unlikely due to the large time frame
>>>and expense involved. We're more than likely talking millions of $$
>>>here for even one decent such study. No _company_ is _ever_ going to
>>>do this, universities have no hope of finding the resources for it
>>>(and besides it lacks any kind of "fundamental research" character,
>>>and the public sector doesn't appear even remotely interested.
>>>Basically, for these sorts of _serious_ economic reasons, there has
>>>never been such a study and for the same reasons it is extremely
>>>unlikely that you will ever see such a study let alone the dozens
>>>(perhaps hundreds) needed to get anything like good results.
>>
>>Nonsense. I have been playing a lot of GT4 lately, and believe you me,
>>when I am behind the wheel of a fully outfitted race car I need
>>exactly one turn to know it.
>
>
> Obviously irrelevant to the points at hand.
I don't know. Folks keep dismissing subjective experience, but in racing
and programming the feel of one's vehicle is probably more accurate than
any contrived number produced by any study.
Of course if one is in love with numbers, it is hard to leave the house
without a nice two or three decimal value to give one courage.
By the way, do we need a study to tell us that GC roolz or that macros rool?
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton <·······@nyc.rr.com> writes:
> I don't know. Folks keep dismissing subjective experience, but in
> racing and programming the feel of one's vehicle is probably more
> accurate than any contrived number produced by any study.
Having raced on track (and flown aerobatics), not video games, where
frankly the total lack of kinesthetics makes any "subjectivity" a lot
less relevant, I can absolutely vouch that "subjective" aspects are a
big deal. However (given real money, as in say Formula 1) a lot of
that "subjectivity" can get real objective measurements showing where
and what it is arising out of. That's also a very big deal as it
gives the race engineers something a lot more solid to work with to
help _increase_ the drivers subjective wants.
> By the way, do we need a study to tell us that GC roolz or that
> macros rool?
Not as far as I'm concerned. BTW, I'm someone who has no problem with
the 10X (and even more in some cases) sorts of claims of Lisp's
superiority over mundanes. I've had direct experience where such
claims hold up very well.
Also, I don't think these examples are "outlyers" that should be
tossed out, as Duane R. has stated. I believe they are very concrete
and would lay $$ on their repeatability. The important unmentioned
bit is that this level of leverage is very sensitive to the _kind_ of
application. I'm not convinced you can get necessary or sufficient
conditions to define these "kinds", but (and here's some subjectivity
for you) they are pretty easy to identify when you see them. It may
well be that for many ordinary things, Lisp is "only" 3X or so
"better" than say <insert your favorite crappy language whipping boy
here>, but that doesn't imply that 10X cases are just "random
oddballs".
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
From: Christopher C. Stacy
Subject: Re: Productivity With Lisp (was Re: I get it)
Date:
Message-ID: <u64zuez0g.fsf@news.dtpq.com>
jayessay <······@foo.com> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > I don't know. Folks keep dismissing subjective experience, but in
> > racing and programming the feel of one's vehicle is probably more
> > accurate than any contrived number produced by any study.
>
> Having raced on track (and flown aerobatics), not video games, where
> frankly the total lack of kinesthetics makes any "subjectivity" a lot
> less relevant, I can absolutely vouch that "subjective" aspects are a
> big deal. However (given real money, as in say Formula 1) a lot of
> that "subjectivity" can get real objective measurements showing where
> and what it is arising out of. That's also a very big deal as it
> gives the race engineers something a lot more solid to work with to
> help _increase_ the drivers subjective wants.
Just to get suitably recursive here: Symbolics Lisp Machines
were used by some Formula 1 racing team, way back when.
(I don't remember exactly what the application did.)
······@news.dtpq.com (Christopher C. Stacy) writes:
> jayessay <······@foo.com> writes:
>
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> > > I don't know. Folks keep dismissing subjective experience, but in
> > > racing and programming the feel of one's vehicle is probably more
> > > accurate than any contrived number produced by any study.
> >
> > Having raced on track (and flown aerobatics), not video games, where
> > frankly the total lack of kinesthetics makes any "subjectivity" a lot
> > less relevant, I can absolutely vouch that "subjective" aspects are a
> > big deal. However (given real money, as in say Formula 1) a lot of
> > that "subjectivity" can get real objective measurements showing where
> > and what it is arising out of. That's also a very big deal as it
> > gives the race engineers something a lot more solid to work with to
> > help _increase_ the drivers subjective wants.
>
> Just to get suitably recursive here: Symbolics Lisp Machines
> were used by some Formula 1 racing team, way back when.
> (I don't remember exactly what the application did.)
Wow, that's cool. Would that have been mid-late '80s? I don't recall
any lambdas plastered on any of the cars, :-). As an aside, Sun are
tied up with McLaren (logos typically on the mirrors) while HP is all
over BMW/Williams.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
From: Christopher C. Stacy
Subject: Re: Productivity With Lisp (was Re: I get it)
Date:
Message-ID: <ull8p6gyl.fsf@news.dtpq.com>
······@news.dtpq.com (Christopher C. Stacy) writes:
> jayessay <······@foo.com> writes:
>
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> > > I don't know. Folks keep dismissing subjective experience, but in
> > > racing and programming the feel of one's vehicle is probably more
> > > accurate than any contrived number produced by any study.
> >
> > Having raced on track (and flown aerobatics), not video games, where
> > frankly the total lack of kinesthetics makes any "subjectivity" a lot
> > less relevant, I can absolutely vouch that "subjective" aspects are a
> > big deal. However (given real money, as in say Formula 1) a lot of
> > that "subjectivity" can get real objective measurements showing where
> > and what it is arising out of. That's also a very big deal as it
> > gives the race engineers something a lot more solid to work with to
> > help _increase_ the drivers subjective wants.
>
> Just to get suitably recursive here: Symbolics Lisp Machines
> were used by some Formula 1 racing team, way back when.
> (I don't remember exactly what the application did.)
I asked around and have been reminded about that story.
It was the for TrueSports Racing team with Bobby Rahal
for the 1986 Indy 500. It downloaded, analyzed, and
visualized the logs from on-board data acquisition.
It looked at the driver inputs, some engine telemetry,
and the forces on the vehicle, shown against its position
on the race track, to help them figure out how to optimize
the aerodynamics. Symbolics got its logo on the car's fins.
Christopher C. Stacy wrote:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
>
>>jayessay <······@foo.com> writes:
>>
>>
>>>Kenny Tilton <·······@nyc.rr.com> writes:
>>>
>>>
>>>>I don't know. Folks keep dismissing subjective experience, but in
>>>>racing and programming the feel of one's vehicle is probably more
>>>>accurate than any contrived number produced by any study.
>>>
>>>Having raced on track (and flown aerobatics), not video games, where
>>>frankly the total lack of kinesthetics makes any "subjectivity" a lot
>>>less relevant, I can absolutely vouch that "subjective" aspects are a
>>>big deal. However (given real money, as in say Formula 1) a lot of
>>>that "subjectivity" can get real objective measurements showing where
>>>and what it is arising out of. That's also a very big deal as it
>>>gives the race engineers something a lot more solid to work with to
>>>help _increase_ the drivers subjective wants.
>>
>>Just to get suitably recursive here: Symbolics Lisp Machines
>>were used by some Formula 1 racing team, way back when.
>>(I don't remember exactly what the application did.)
>
>
> I asked around and have been reminded about that story.
> It was the for TrueSports Racing team with Bobby Rahal
> for the 1986 Indy 500. It downloaded, analyzed, and
> visualized the logs from on-board data acquisition.
> It looked at the driver inputs, some engine telemetry,
> and the forces on the vehicle, shown against its position
> on the race track, to help them figure out how to optimize
> the aerodynamics.
If I am having trouble with an event I can use the GT4 analyzer to show
me where on the course I am losing time. Turns out I was hitting the
breaks too hard entering a blind turn.
> Symbolics got its logo on the car's fins.
Awesome. That is almost better than Lisp In Space.
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
On Tue, 15 Mar 2005 06:09:13 GMT, <·······@nyc.rr.com> wrote:
>>>>Kenny Tilton <·······@nyc.rr.com> writes:
>>>>Having raced on track (and flown aerobatics), not video games, where
Aerobatics in what? Extra? SZD-59?
> If I am having trouble with an event I can use the GT4 analyzer to show
> me where on the course I am losing time. Turns out I was hitting the
> breaks too hard entering a blind turn.
Still do that in F1, maybe still in lisp too (?).
--
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.
GP lisper <········@CloudDancer.com> writes:
> On Tue, 15 Mar 2005 06:09:13 GMT, <·······@nyc.rr.com> wrote:
> >>>>Kenny Tilton <·······@nyc.rr.com> writes:
> >>>>Having raced on track (and flown aerobatics), not video games, where
>
> Aerobatics in what? Extra? SZD-59?
Pitts S2A and S2B; Super Decathlon; Extra 200 (but only a very little
- way too much $$). Also T34 (which is like a truck compared to any
of the others here)!
> > If I am having trouble with an event I can use the GT4 analyzer to show
> > me where on the course I am losing time. Turns out I was hitting the
> > breaks too hard entering a blind turn.
>
> Still do that in F1, maybe still in lisp too (?).
This has been elevated to a entire science in F1. I have no idea if
any of it is in Lisp.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
······@news.dtpq.com (Christopher C. Stacy) writes:
> ······@news.dtpq.com (Christopher C. Stacy) writes:
>
> > jayessay <······@foo.com> writes:
> >
> > > Kenny Tilton <·······@nyc.rr.com> writes:
> > >
> > > > I don't know. Folks keep dismissing subjective experience, but in
> > > > racing and programming the feel of one's vehicle is probably more
> > > > accurate than any contrived number produced by any study.
> > >
> > > Having raced on track (and flown aerobatics), not video games, where
> > > frankly the total lack of kinesthetics makes any "subjectivity" a lot
> > > less relevant, I can absolutely vouch that "subjective" aspects are a
> > > big deal. However (given real money, as in say Formula 1) a lot of
> > > that "subjectivity" can get real objective measurements showing where
> > > and what it is arising out of. That's also a very big deal as it
> > > gives the race engineers something a lot more solid to work with to
> > > help _increase_ the drivers subjective wants.
> >
> > Just to get suitably recursive here: Symbolics Lisp Machines
> > were used by some Formula 1 racing team, way back when.
> > (I don't remember exactly what the application did.)
>
> I asked around and have been reminded about that story.
> It was the for TrueSports Racing team with Bobby Rahal
> for the 1986 Indy 500. It downloaded, analyzed, and
> visualized the logs from on-board data acquisition.
> It looked at the driver inputs, some engine telemetry,
> and the forces on the vehicle, shown against its position
> on the race track, to help them figure out how to optimize
> the aerodynamics. Symbolics got its logo on the car's fins.
That's cool. Always kind of liked Rahal, but it would have been much
cooler if it had been F1. Especially back then, F1 has become much
watered down over the last 8 years or so. Back 15 years or so ago, I
used to make the analogy: F1 is war; CART is paintball!
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Kenny Tilton <·······@nyc.rr.com> writes:
> I don't know. Folks keep dismissing subjective experience, but in
> racing and programming the feel of one's vehicle is probably more
> accurate than any contrived number produced by any study.
Seat of the pants coding? :)
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
··························@twister.nyc.rr.com...
> I don't know. Folks keep dismissing subjective experience, but in racing
> and programming the feel of one's vehicle is probably more accurate than
> any contrived number produced by any study.
Have you compared the quality of a review in, say, _The Absolute Sound_ to
_The Audio Critic_? The former is subjective, the latter is objective.
Personally, I prefer the latter - it's scientific (in the Popperian sense).
Besides, I object to the notion that plugging a "special" clock somewhere
into the AC distribution system in my house will cause my stereo to sound
better.
That's not to say that subjective experience can build intuition on where to
look for objective measures, but as someone who uses the results of
subjective and objective human studies (I work in HCI), let me tell you that
subjective reports are very unreliable. Memory itself is very unreliable,
being a reconstructed experience, not a recording. What you may remember
about driving your vehicle or programming, even a few minutes after doing it
may not correlate with the objective facts. A lot of things get in the way
(including outlook - one cannot take reports from religious zealots as to
the truth of their creed or the power of their deity seriously).
jayessay <······@foo.com> writes:
> This begins to get at why any notion of rigorous, good experimental
> methodological results wrt productivity measures in the context of
> software development (languages, tools, people, whatever) is a non
> starter. You indeed need studies of the level you indicate here to
> even begin to have legitimate answers. And, in fact, you would need a
> _lot_ of them. OTOH, even one is unlikely due to the large time frame
> and expense involved. We're more than likely talking millions of $$
> here for even one decent such study.
Well, might be true for experimental studies. But note that there are
also epidemiological ones: Where you observe many relatively
uncontrolled data points in the real world and condition on possible
causes for variation. (I'm so briefly speaking that it's almost wrong).
In medicine this sort of studies works quite well: For obvious ethical
reasons you cannot do controlled studies on the influence of X (X =
radiation, or smoking, or pollution, or whatever) on human health.
But what you can do is observe people living under different
conditions and getting sick in different ways.
The statistical analysis of such studies (i.e., analysis of many
"finished" software projects in academia and industry) is by no means
trivial, but possible. They don't cost millions. They aren't for
free, either. But they are doable and they might pay off.
The number one reason why such things are not common are, IMHO, not
technical but cultural.
Matthias <····@spam.pls> writes:
> jayessay <······@foo.com> writes:
>
> > This begins to get at why any notion of rigorous, good experimental
> > methodological results wrt productivity measures in the context of
> > software development (languages, tools, people, whatever) is a non
> > starter. You indeed need studies of the level you indicate here to
> > even begin to have legitimate answers. And, in fact, you would need a
> > _lot_ of them. OTOH, even one is unlikely due to the large time frame
> > and expense involved. We're more than likely talking millions of $$
> > here for even one decent such study.
>
> Well, might be true for experimental studies. But note that there are
> also epidemiological ones: Where you observe many relatively
> uncontrolled data points in the real world and condition on possible
> causes for variation. (I'm so briefly speaking that it's almost wrong).
I know what you're talking about here and it is indeed a plausible
course of action that falls somewhere between anectdote and hard
evidence.
> The statistical analysis of such studies (i.e., analysis of many
> "finished" software projects in academia and industry) is by no means
> trivial, but possible. They don't cost millions.
Where did you get the "is" part here?, i.e., where are the studies you
seem to be claiming exist for such projects and their costs?
> The number one reason why such things are not common are, IMHO, not
> technical but cultural.
The number one reason is money. That's how it works in this society
(for good or ill). Culture is only involved to the extent that it
influences a belief that it is not worth spending the money.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay <······@foo.com> writes:
> Matthias <····@spam.pls> writes:
> > jayessay <······@foo.com> writes:
> > The statistical analysis of such studies (i.e., analysis of many
> > "finished" software projects in academia and industry) is by no means
> > trivial, but possible. They don't cost millions.
>
> Where did you get the "is" part here?, i.e., where are the studies you
> seem to be claiming exist for such projects and their costs?
I was thinking about the corresponding studies from medicine. They
exist. They motivated real advances in statistics. Their results
influence our daily life in a useful way. (E.g. there's statistical
evidence that smoking causes lung cancer and people tend to smoke
less.)
> > The number one reason why such things are not common are, IMHO, not
> > technical but cultural.
>
> The number one reason is money. That's how it works in this society
> (for good or ill). Culture is only involved to the extent that it
> influences a belief that it is not worth spending the money.
Exactly. And computer scientists and software engineers believe that
money is better spent philosophizing over what might work and what
might be useful than to actually collect and analyze data. Of course,
not looking at data is much more comfortable as one is not forced to
reconsider one's preconceptions.
Advancements in science and engineering by means of philosophy was the
way to go in the middle ages. Yes, you can make progress that way.
But it's sloooow. The scientific method (make a theory and test it)
speeds things up a bit.
Think about it: Physicists build large, billion-dollar expensive,
complicated particle colliders to test reasonable and well thought-out
theories that probably have no financial impact in the foreseeable
future. Software engineers often decide to go without empirical
research, although any insight could immediately be worth real money.
That's what I meant with 'cultural'.
Matthias <····@spam.pls> writes:
> jayessay <······@foo.com> writes:
> > Matthias <····@spam.pls> writes:
> > > jayessay <······@foo.com> writes:
> > > The statistical analysis of such studies (i.e., analysis of many
> > > "finished" software projects in academia and industry) is by no means
> > > trivial, but possible. They don't cost millions.
> >
> > Where did you get the "is" part here?, i.e., where are the studies you
> > seem to be claiming exist for such projects and their costs?
>
> I was thinking about the corresponding studies from medicine.
Ah. Sure, those things (and similar ones in other areas) definitely
have real information in them. To my knowledge nothing of the sort
exists for software. Part of the problem (probably a very small part)
may have to do with the fact that the extent examples deal with
(typically) unrelated individuals (or individual events). In the
software case, you would have to deal with not just with sets of
individuals (those actually tasked with developing the software) but
"higher level" organizations (departments, divisions, companies, etc.)
as well. Since all this junk is tightly intertwined it is much more
difficult to get what would be considered good random samplings, which
are pretty easy (relatively speaking) for the cases of individuals (as
in epidemiology studies or accident investigations).
> > The number one reason is money. That's how it works in this society
> > (for good or ill). Culture is only involved to the extent that it
> > influences a belief that it is not worth spending the money.
>
> Exactly. And computer scientists and software engineers believe
> that money is better spent philosophizing over what might work and
> what might be useful than to actually collect and analyze data.
SWE really have no say in the matter - it's not their job and most
probably don't have a clue about how to go about it. Computer
scientists probably don't care either - what does it have to do with
the "science" underlying computation? Probably nothing. In neither
case do the people involved have much (if any) say in "where the money
is spent". They may both be guilty of naval gazing, but I'm not sure
that in this case that makes them out to be the goats.
> Think about it: Physicists build large, billion-dollar expensive,
> complicated particle colliders to test reasonable and well thought-out
> theories that probably have no financial impact in the foreseeable
> future.
Only to the extent that they can convince someone (typically the
public sector) that what they are doing has some sort of
intrinsic/fundamental value. It's much closer to something like the
arts, though the money involved is vastly different. As an aside: if
string theory turns out to be on the right track, all those particle
colliders and "reasonable" theories are basically a complete waste.
> Software engineers often decide to go without empirical research,
> although any insight could immediately be worth real money.
I don't think SWE decide much of anything about this. Out to, oh say
four or five nines, they're just cogs (or maybe only a tooth on a cog)
whose views are completely dominated by "the marketplace", with all
the fadism, hype and pop culture that make up most of what it is.
Which is basically saying they are totally dominated by the entities
with the $$ that could require and produce the research, but which
don't. So, the question becomes, why don't these entities do the
work, or at least pay to have it done? That's not _entirely_ clear,
but there are plenty of big money reasons for these things, and thus
the people running them, to not point out that the "emperor has no
clothes", let alone actively pursue a course to show this.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Matthias wrote:
>
>
> Exactly. And computer scientists and software engineers believe that
> money is better spent philosophizing over what might work and what
> might be useful than to actually collect and analyze data. Of course,
> not looking at data is much more comfortable as one is not forced to
> reconsider one's preconceptions.
>
And of course there have been such studies. The COCOMO models
did that.
http://sunset.usc.edu/research/COCOMOII/index.html
> Advancements in science and engineering by means of philosophy was the
> way to go in the middle ages. Yes, you can make progress that way.
> But it's sloooow. The scientific method (make a theory and test it)
> speeds things up a bit.
>
> Think about it: Physicists build large, billion-dollar expensive,
> complicated particle colliders to test reasonable and well thought-out
> theories that probably have no financial impact in the foreseeable
> future. Software engineers often decide to go without empirical
> research, although any insight could immediately be worth real money.
>
> That's what I meant with 'cultural'.
As another scientific approach we build computer simulations of weather, climate
and traffic. They all yield useful information and some predictability.
How about a computer model of software development? It should be
simpler than a weather forecasting model.
Wade
Wade Humeniuk <··················@telus.net> writes:
> As another scientific approach we build computer simulations of
> weather, climate and traffic. They all yield useful information
> and some predictability. How about a computer model of software
> development? It should be simpler than a weather forecasting
> model.
Probably not. Weather involves natural forces that obey the laws of
physics; software development involves humans, which (at times) don't
obey much of anything. :)
--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
David Magda <··················@ee.ryerson.ca> writes:
> Wade Humeniuk <··················@telus.net> writes:
>
> > As another scientific approach we build computer simulations of
> > weather, climate and traffic. They all yield useful information
> > and some predictability. How about a computer model of software
> > development? It should be simpler than a weather forecasting
> > model.
>
> Probably not. Weather involves natural forces that obey the laws of
> physics; software development involves humans, which (at times) don't
> obey much of anything. :)
What part of the human brain does not obey the laws of physics?
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
On Wed, 16 Mar 2005 00:09:31 -0500, David Steuber wrote:
> David Magda <··················@ee.ryerson.ca> writes:
>
>> Probably not. Weather involves natural forces that obey the laws of
>> physics; software development involves humans, which (at times) don't
>> obey much of anything. :)
>
> What part of the human brain does not obey the laws of physics?
What laws of physics directly influence the software development behaviour
of humans? ;-)
--
Christopher
Christopher Koppler <········@chello.at> writes:
> On Wed, 16 Mar 2005 00:09:31 -0500, David Steuber wrote:
>
>> David Magda <··················@ee.ryerson.ca> writes:
>>
>> What part of the human brain does not obey the laws of physics?
>
> What laws of physics directly influence the software development behaviour
> of humans? ;-)
Hum... all of them? ;-)
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
David Steuber <·····@david-steuber.com> writes:
> David Magda <··················@ee.ryerson.ca> writes:
>
> > Wade Humeniuk <··················@telus.net> writes:
> >
> > > As another scientific approach we build computer simulations of
> > > weather, climate and traffic. They all yield useful information
> > > and some predictability. How about a computer model of software
> > > development? It should be simpler than a weather forecasting
> > > model.
> >
> > Probably not. Weather involves natural forces that obey the laws of
> > physics; software development involves humans, which (at times) don't
> > obey much of anything. :)
>
> What part of the human brain does not obey the laws of physics?
The spirit, ie. the software!
What you think does not obey the laws of physics.
How you think does obey the laws of physics.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
Pascal Bourguignon <····@mouse-potato.com> writes:
> David Steuber <·····@david-steuber.com> writes:
> >
> > What part of the human brain does not obey the laws of physics?
>
> The spirit, ie. the software!
>
> What you think does not obey the laws of physics.
> How you think does obey the laws of physics.
Hmm. Isn't what I think constrained by how I think?
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber <·····@david-steuber.com> writes:
> Pascal Bourguignon <····@mouse-potato.com> writes:
>
> > David Steuber <·····@david-steuber.com> writes:
> > >
> > > What part of the human brain does not obey the laws of physics?
> >
> > The spirit, ie. the software!
> >
> > What you think does not obey the laws of physics.
> > How you think does obey the laws of physics.
>
> Hmm. Isn't what I think constrained by how I think?
Not on a Turing Machine.
Is your brain more or less powerful than a (finite but big) Turing Machine?
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
Pascal Bourguignon <····@mouse-potato.com> writes:
> David Steuber <·····@david-steuber.com> writes:
>
> > Pascal Bourguignon <····@mouse-potato.com> writes:
> >
> > > David Steuber <·····@david-steuber.com> writes:
> > > >
> > > > What part of the human brain does not obey the laws of physics?
> > >
> > > The spirit, ie. the software!
> > >
> > > What you think does not obey the laws of physics.
> > > How you think does obey the laws of physics.
> >
> > Hmm. Isn't what I think constrained by how I think?
>
> Not on a Turing Machine.
> Is your brain more or less powerful than a (finite but big) Turing Machine?
I think brains are Turing Machines. Ever had an unthinkable thought?
Some machines are faster than others. Faster allows more options.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber <·····@david-steuber.com> writes:
> Pascal Bourguignon <····@mouse-potato.com> writes:
...
> > Not on a Turing Machine.
> > Is your brain more or less powerful than a (finite but big) Turing Machine?
>
> I think brains are Turing Machines. Ever had an unthinkable thought?
No, but for all we know, we may well all have had _uncomputable_
thoughts.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
From: Karl A. Krueger
Subject: Re: Productivity With Lisp (was Re: I get it)
Date:
Message-ID: <d1f4aj$rij$1@baldur.whoi.edu>
jayessay <······@foo.com> wrote:
> David Steuber <·····@david-steuber.com> writes:
>> Pascal Bourguignon <····@mouse-potato.com> writes:
>> > Not on a Turing Machine.
>> > Is your brain more or less powerful than a (finite but big) Turing Machine?
>>
>> I think brains are Turing Machines. Ever had an unthinkable thought?
>
> No, but for all we know, we may well all have had _uncomputable_
> thoughts.
How would you tell if you had?
--
Karl A. Krueger <········@example.edu> { s/example/whoi/ }
From: Kent M Pitman
Subject: Re: Productivity With Lisp (was Re: I get it)
Date:
Message-ID: <umzt0es8l.fsf@nhplace.com>
"Karl A. Krueger" <········@example.edu> writes:
> jayessay <······@foo.com> wrote:
> > David Steuber <·····@david-steuber.com> writes:
> >> Pascal Bourguignon <····@mouse-potato.com> writes:
> >> > Not on a Turing Machine.
> >> > Is your brain more or less powerful than a (finite but big)
> >> > Turing Machine?
> >>
> >> I think brains are Turing Machines. Ever had an unthinkable
> >> thought?
> >
> > No, but for all we know, we may well all have had _uncomputable_
> > thoughts.
>
> How would you tell if you had?
If I were to take your question seriously, I think the answer is:
You'd laugh.
I believe at least one broad classification of humor can be traced to
situations the brain has marked as 'computationally questionable'.
Consider the notion of handing someone a card that says "see other
side" on both sides. These become "patterns" of humor where people
learn to recognize and laugh rather than continue computing. Probably
the right brain is watching for the "going in circles" phenomenon all
the time to make sure the left brain doesn't melt down.
I further believe that a lot of the reason people concern themselves
with good style, whether in natural language or programming language,
is to limit the computational complexity for the language receiver so
that it doesn't exceed normal computational bounds. We tell people to
build recursions using well-established paradigms like inductions
(with a clear base case and a step that clearly reduces the problem)
so that it's well within the range of easy code analysis. We don't
tell people to freely cross-call programs in ways that don't obviously
reduce complexity (hence, if you model go tags as collections of
mutually recursive functions with no special model of "reducing the
problem complexity as they cross-call", you can understand the fear of
the "goto"). And so on.
From: Karl A. Krueger
Subject: Re: Productivity With Lisp (was Re: I get it)
Date:
Message-ID: <d1fijh$3vc$1@baldur.whoi.edu>
Kent M Pitman <······@nhplace.com> wrote:
> "Karl A. Krueger" <········@example.edu> writes:
>> jayessay <······@foo.com> wrote:
>> > No, but for all we know, we may well all have had _uncomputable_
>> > thoughts.
>>
>> How would you tell if you had?
>
> If I were to take your question seriously, I think the answer is:
> You'd laugh.
>
> I believe at least one broad classification of humor can be traced to
> situations the brain has marked as 'computationally questionable'.
> Consider the notion of handing someone a card that says "see other
> side" on both sides. These become "patterns" of humor where people
> learn to recognize and laugh rather than continue computing. Probably
> the right brain is watching for the "going in circles" phenomenon all
> the time to make sure the left brain doesn't melt down.
A function whose computation takes just one more recursive call than
your stack can handle is not an incomputable one -- it's just one that
you can't compute right now. So catching a stack overflow doesn't mean
you tried to compute something incomputable -- it just means you tried
to compute something too deep ... or used the wrong approach.
The problem of detecting the condition "I'm spending too many cycles on
this problem" seems similar to the economics problem of information in a
market. Markets for goods and services are supposed to work the best
when all participants have access to all information -- however, the act
of gathering information does itself consume time and resources which
could otherwise be spent on goods.
(In other words, eventually you have to stop "shopping around" and buy
something, take the job, whatever ... even though it's possible that if
you just looked in one more place you could find a better deal.)
None of this suggests anything *incomputable* is going on, just that
these systems (stacks, brains, language users or instruction followers,
buyers and sellers) have resource limits and have to do their work in
real time that really does count.
I think something else is going on in reading the "see other side" card.
We recognize humor here because of the clash between two kinds of
interpretation: that of the "mindless" follower of instructions, and
that of the intentionality-bearing writer of those instructions.
"Mindlessly" following instructions is only sensible when one presumes
that the writer of instructions has some useful meaning in mind. When
the writer is just being perverse, there is no sense in following the
instructions.
The more esoteric of "lightbulb jokes" may fall into the same category,
e.g.: "How many surrealists does it take to change a lightbulb? Two --
one to play the accordion while the other fills the bathtub with
brightly colored machine tools." The fact that the proposed algorithm
totally fails to accomplish the stated goal is part of the joke.
ObLisp: The one about the "conforming Common Lisp implementation" that
does nothing but signal an out-of-memory error and exit, is much the
same. The program is strictly "following the rules" for being a Lisp
implementation, even though it can never accomplish the presumed goal of
all implementations, namely to correctly run conforming Lisp programs.
It is funny because pointless.
> I further believe that a lot of the reason people concern themselves
> with good style, whether in natural language or programming language,
> is to limit the computational complexity for the language receiver so
> that it doesn't exceed normal computational bounds.
Sure. Users of bad grammar and spelling sometimes claim that if the
reader can tell what they mean, their usage should be accepted. The
problem is that bad and ambiguous grammar place extra "system load" on
the reader. Like fraud in a marketplace, the meaning behind the bad
grammar can eventually be found out -- but it costs extra effort.
--
Karl A. Krueger <········@example.edu> { s/example/whoi/ }
From: Kent M Pitman
Subject: Re: Productivity With Lisp (was Re: I get it)
Date:
Message-ID: <uoedg1p0q.fsf@nhplace.com>
"Karl A. Krueger" <········@example.edu> writes:
> A function whose computation takes just one more recursive call than
> your stack can handle is not an incomputable one --
I didn't say it was.
Your entire reply makes conclusions about what I said incompatible with
what I wrote and intended to imply.
I'm not going to bother to reply in detail because you so utterly missed
my point, but I wanted to log the fact that I don't consider your remarks
a refutation of what I said.
From: Karl A. Krueger
Subject: Re: Productivity With Lisp (was Re: I get it)
Date:
Message-ID: <d1glc4$fid$1@baldur.whoi.edu>
Kent M Pitman <······@nhplace.com> wrote:
> I'm not going to bother to reply in detail because you so utterly missed
> my point, but I wanted to log the fact that I don't consider your remarks
> a refutation of what I said.
No worries. It wasn't intended as such.
--
Karl A. Krueger <········@example.edu> { s/example/whoi/ }
"Karl A. Krueger" <········@example.edu> writes:
> jayessay <······@foo.com> wrote:
> > David Steuber <·····@david-steuber.com> writes:
> >> Pascal Bourguignon <····@mouse-potato.com> writes:
> >> > Not on a Turing Machine.
> >>
> >> I think brains are Turing Machines. Ever had an unthinkable thought?
> >
> > No, but for all we know, we may well all have had _uncomputable_
> > thoughts.
>
> How would you tell if you had?
I have no idea. Maybe that's part of the point. Do you have any idea?
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
From: Karl A. Krueger
Subject: Re: Productivity With Lisp (was Re: I get it)
Date:
Message-ID: <d1ipuc$6tn$1@baldur.whoi.edu>
jayessay <······@foo.com> wrote:
> "Karl A. Krueger" <········@example.edu> writes:
>> jayessay <······@foo.com> wrote:
>> > David Steuber <·····@david-steuber.com> writes:
>> >>
>> >> I think brains are Turing Machines. Ever had an unthinkable thought?
>> >
>> > No, but for all we know, we may well all have had _uncomputable_
>> > thoughts.
>>
>> How would you tell if you had?
>
> I have no idea. Maybe that's part of the point. Do you have any idea?
Would it make any difference if you had one?
Suppose you had, but I had not ... what would that say about us?
--
Karl A. Krueger <········@example.edu> { s/example/whoi/ }
"Karl A. Krueger" <········@example.edu> writes:
> jayessay <······@foo.com> wrote:
> > "Karl A. Krueger" <········@example.edu> writes:
> >> jayessay <······@foo.com> wrote:
> >> > David Steuber <·····@david-steuber.com> writes:
> >> >>
> >> >> I think brains are Turing Machines. Ever had an unthinkable thought?
> >> >
> >> > No, but for all we know, we may well all have had _uncomputable_
> >> > thoughts.
> >>
> >> How would you tell if you had?
> >
> > I have no idea. Maybe that's part of the point. Do you have any idea?
>
> Would it make any difference if you had one?
>
> Suppose you had, but I had not ... what would that say about us?
Most likely nothing. I suppose your question was just rhetorical.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
On Wed, 16 Mar 2005 21:25:21 +0100, Pascal Bourguignon wrote:
> David Steuber <·····@david-steuber.com> writes:
>
>> Pascal Bourguignon <····@mouse-potato.com> writes:
>>
>> > David Steuber <·····@david-steuber.com> writes:
>> > >
>> > > What part of the human brain does not obey the laws of physics?
>> >
>> > The spirit, ie. the software!
>> >
>> > What you think does not obey the laws of physics.
>> > How you think does obey the laws of physics.
>>
>> Hmm. Isn't what I think constrained by how I think?
>
> Not on a Turing Machine.
> Is your brain more or less powerful than a (finite but big) Turing Machine?
Well, *my* brain likes to think it's vastly more powerful than any finite
Turing machine but it hasn't proven that to me...
--
Christopher
"Pascal Bourguignon" <····@mouse-potato.com> wrote in message
···················@thalassa.informatimago.com...
> David Steuber <·····@david-steuber.com> writes:
>
> > Pascal Bourguignon <····@mouse-potato.com> writes:
> >
> > > David Steuber <·····@david-steuber.com> writes:
> > > >
> > > > What part of the human brain does not obey the laws of physics?
> > >
> > > The spirit, ie. the software!
> > >
> > > What you think does not obey the laws of physics.
> > > How you think does obey the laws of physics.
> >
> > Hmm. Isn't what I think constrained by how I think?
>
> Not on a Turing Machine.
> Is your brain more or less powerful than a (finite but big) Turing
Machine?
This is a bizzare question on several levels. First of all, the brain can't
possibly be a Turing Machine, because it does not have an infinite tape, and
any finite Turing Machine can be modeled by a Finite State Machine. Now if
you augment the brain with paper (something to write on), you can now argue
you have infinite multi-dimensional tape, however, modeling the brain itself
as a finite state machine (as part of the Turing Machine model) is not
useful or interesting - it's the moral equivalent of saying that any finite
system is a finite state machine, so regular expressions are all there is...
which has not been very productive for analyzing pretty much anything, let
alone human natural language, for instance.
Second, the Turing Machine abstraction doesn't work for systems that are
embodied, i.e., the world (input) changes as they compute. Instead, new
theoretical notions are needed, that address issues of, e.g., latency,
satisficing behavior, etc. that are foreign concepts to the Turing Machine
model, but very interesting when you start talking about things with brains
(robots or people). In fact, the ability to observe the environment directly
breaks the Turing Machine model (in a TM, the input is fixed until an output
is produced).
Third, we appear to be able to come to believe things that are not provable
or disprovable in a first order system (which is all you get with a Turing
Machine - first order logic is equivalent to the recursively enumerable
functions).
Fourth, even modern software (such as networking software, distributed
agents, robots, etc.) are not well modeled by the Turing Machine paradigm,
at least partially because the TM has no notion of "real time" or as noted
above, enviornmental observation. Why would you want to apply it to brains
that if anything are observation engines?
So, yes, brains are in fact more powerful than a Turing Machine. The notion
of time and space complexity on a Turing Machine does not adequately model
the time/space (and other forms) of complexity we see in human behaviors.
The Turing Machine is a particular abstraction that has some utility on von
Neumann style computers, but isn't even a good model of data flow machines
(that is, the formal complexity of the TM does not correlate with the
behavior of a data flow machine). Brains are able to comprehend higher
ordered logics, and thus can conceive of uncomputable functions a TM could
not even be implemented for.
The notion that people are walking Turing Machines is so 1980s...
David Magda <··················@ee.ryerson.ca> writes:
> Wade Humeniuk <··················@telus.net> writes:
>
> > As another scientific approach we build computer simulations of
> > weather, climate and traffic. They all yield useful information
> > and some predictability. How about a computer model of software
> > development? It should be simpler than a weather forecasting
> > model.
>
> Probably not. Weather involves natural forces that obey the laws of
> physics; software development involves humans, which (at times) don't
> obey much of anything. :)
Note however that you could build a computer model for _some_ software
_use_.
For example, you could build a computer model for the use of Microsoft
Word. Given X dactylos, Y copies of MS-Word version Z, W copies of
MS-Windows version V, predict the number of pages of legal documents
generated (For X, Y and W big enough).
It's the use of emacs that's less predicible...
--
__Pascal Bourguignon__ http://www.informatimago.com/
In article <·······················@twister.nyc.rr.com>, Kenny Tilton wrote:
>
>
> David Steuber wrote:
>
>> Duane Rettig <·····@franz.com> writes:
>>
>> [on hype and AI Winter]
>>
>>
>>>We in the newly blossoming Lisp industry must never make the same
>>>mistake again. We must never hype the abilities of Lisp; we must
>>>instead show solid facts for what Lisp can do. I see alarming trends
>>>in this area; the old myths of Lisp being 10X more efficient than
>>>other languages is resurfacing - let's face it; there is no hard data,
>>>and the anecdotal data points to 2 to 4 times design efficiency,
>>>rather than 10X that has been shown.
>
> Nonsense! First you say the numbers are no good, then you try to give
> them legitimacy by saying the "right" number is 2-4, not 10!!
>
> Look, there is probably no way we will ever measure programmer
> productivity. Given a general task, two solutions will likely vary
> wildly in the extensibility/power/maintainability of the code (and I am
> not even saying which language will have been used by the author of the
> better code). Given a tight spec, we are no longer measuring
> productivity, because normally coding is designing.
>
> But there is no need for numbers. Jeez, just use Common Lisp for a week
> and you'll be running around saying it is ten times better. Note that in
> the case, the numbers are never meant to be taken literally. When I say
> something is two times better, I mean "a lot". When I say ten times, I
> mean "a whole lot".
>
> Are youse guys saying Lisp is not a whole lot better?!
>
> A single case of 10X does not
>>>qualify as evidence; in the presence of subjective and anectdotal
>>>data we should take advice from Gymnastics scoring techniques, where
>>>one highest and one lowest score are tossed out routinely to ensure
>>>that the curve is more accurately centered at the mean.
>
> Nonsense! What a capricious, arbitrary, desperate attempt to get good
> numbers out of bad! Who says the low scoring judge did not see some
> gaffe the others missed? Who says the high scoring judge did not see
> subtle perfection others missed while looking for grandiose tricks?
>
> hell, why not throw out the middle scores on the premise that they must
> be the judges so unsure of their ability to assess performance that they
> simply put of middle values in the hope of not having some announcer
> saying, "And there's an inexplicable 5.9 from the Swedish judge."?
>
>
>> it, I don't think that Lisp is inherently more productive to use than
>> other VHLLs like Perl, Python, Tcl, etc.
>
> Now you are scaring me.
What I'd like is a lisp/scheme interpreter that is as easy to
use as the PERL interpreters. The lisp systems I have access
to do not have the functionality of 'perl -d' nor the infrastructure
of CPAN.
Having those two issues fixed would put me much further to
using lisp/scheme and off using PERL. I really like the way
lisp is put together.
Mike
Mike <·····@mikee.ath.cx> writes:
> What I'd like is a lisp/scheme interpreter that is as easy to
> use as the PERL interpreters. The lisp systems I have access
> to do not have the functionality of 'perl -d'
What's wrong with clisp -interactive-debug ????
If you don't like long option names, why don't you write a little
script such as:
#!/bin/bash
opt=()
for arg ; do
if [ "$arg" = "-d" ] ; then
opt[${#opt}]=-interactive-debug
else
opt[${#opt}]="$arg"
fi
done
exec /usr/local/bin/clisp "${opt[@]}"
> nor the infrastructure of CPAN.
ASDF is a bad name. It should take the CLAN name!
> Having those two issues fixed would put me much further to
> using lisp/scheme and off using PERL. I really like the way
> lisp is put together.
Ok, so now you're put much further to using lisp. Please forget perl.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay
Kenny Tilton <·······@nyc.rr.com> writes:
> But there is no need for numbers. Jeez, just use Common Lisp for a
> week and you'll be running around saying it is ten times better. Note
> that in the case, the numbers are never meant to be taken
> literally. When I say something is two times better, I mean "a
> lot". When I say ten times, I mean "a whole lot".
But there are enough people, notably engineers and scientists, out
there who say 10 when they mean 10 and 2 when they mean 2 and when
they mean "a whole lot" they say so. I have a lot of respect for
that. Not every communication in the world is -- or should be -- a
marketing effort.
> > Duane Rettig <·····@franz.com> writes:
> >>A single case of 10X does not
> >>qualify as evidence; in the presence of subjective and anectdotal
> >>data we should take advice from Gymnastics scoring techniques, where
> >>one highest and one lowest score are tossed out routinely to ensure
> >>that the curve is more accurately centered at the mean.
>
> Nonsense! What a capricious, arbitrary, desperate attempt to get good
> numbers out of bad! Who says the low scoring judge did not see some
> gaffe the others missed? Who says the high scoring judge did not see
> subtle perfection others missed while looking for grandiose tricks?
Because you are looking for the performance on average (over a number
of users, a number of projects, a number of impressions, etc). This
average number is not affected by a "wrong" decision that lies in the
middle. It's strongly affected by outliers lying on the tails.
The concept Duane sketched is called "trimming" in statistics. It's
one approach to tackle problems where you have little data with strong
variation and lots of outliers. There are others, but it's not
"capricious, arbitrary, desperate".
From: James Graves
Subject: Re: Productivity With Lisp (was Re: I get it)
Date:
Message-ID: <d0q9no$d6o$1@new7.xnet.com>
What follows is all completely my opinion, and may not have any relation
to any reality you currently experience.
Let's suppose for a moment that you've got the time and money to do a
proper study of programmer productivity. And you've got a large and
beefy project which will adequately test programmer effectiveness. And
the spec isn't so tight that it constrains the implementation
unnecessarily.
And lastly, suppose you've got N really good programmers of X years of
experience for both Java and Common Lisp. And they're all about the
same level of skill, intelligence, education, and communication ability.
Even if you could do all that, I still don't think the test would be
fair.
Here's why. It has to do with the nature of each respective group's
experience.
If you've been doing X years of Java programming (with X greater than
5), you're in one of two categories:
1. You're frustrated with the limitations of Java.
2. You're not frustrated with the limitations of Java.
Say you are in category #1, but you're still using Java anyway. That
kind of does something to you. To your attitude. I believe it wears
you down, and lowers your overall creativity. I think it will tend to
sap your enthusiasm, and take away your gumption to try new and better
solutions to problems.
Because of its limits in expressiveness, I think it will also limit your
own expressiveness. I won't go so far to say that using Java makes you
stupid, but I think it can harm your growth as a developer in the long
term, and keep you from fulfilling your potential.
And if you're in category #2, well, you've got other problems. And
you're just not going to be in the same class as top-shelf developers.
So if you compare your bunch of Java developers to your Lisp developers,
they're not going to be the same in outlook and capabilities, even if
you try to control for other factors such as years of experience and
education.
So I think Lisp would win such a hypothetical study, but it wouldn't
necessarily prove anything.
Most developers these days aren't choosing Lisp because it was all that
was used in school, or because they needed it for a job. They are
choosing it for specific reasons, such as dissatisfaction with existing
languages and development enviroments. There's a lot of self-selection
going on.
James Graves
"Duane Rettig" <·····@franz.com> wrote in message
··················@franz.com...
> "Mike Ajemian" <············@verizon.net> writes:
>
> > I still think that AI winter stuff is a crock, though. In competition,
the
> > advantage is to the swift, strong and/or smart. Lisp is faster,
providing
> > shorter time to market. For company's with profit motive, ignoring Lisp
has
> > been like willingly running a sprint while towing a 400-pound sled.
Ergo,
> > therefore, and suchwith, AI winter is the symbolic abstraction for the
> > millions of reasons people got tired of fighting and advocating for Lisp
and
> > just gave up. Forgetting that basic Trump-ism, "Never Lose The Fight".
Maybe
> > that was Lao Tzu. Hard to tell the difference sometimes.
>
> The AI winter was a reality, and it wasn't due to lack of trying or
> giving up.
Hmm. Perhaps the problem here is that I used the term "AI Winter" in
association with Lisp. I was referring to the crock being the failure of
Lisp to garner market share while representing an advantage to corporations.
I think anybody who wants to associate the failure of Lisp with the failure
of AI is making excuses for their not being able to sell a productivity
tool with quantifiable advantages into a retail or commercial market in
need of increased throughput and stability. Maybe you guys think smart=sexy?
Hmmm, read the marketing crap I wrote below. I mean, every other language
has jobs available except Lisp. That's not AI Winter, that's Lisp Drought.
> As an analogy, the Sun was never any colder during the Ice Age, nor
> (we think) was the Earth any farther away from it, but its warming
> effects simply could not counteract whatever cataclysm overwhelmed
> the Earth with cold. Now one can scientifically state that cold is
> simply the lack of heat, but in the case of the Ice Age, that
> explanation just isn't adequate to explain the forces at work, or
> in fact to explain how the Earth came back out of the Ice Age, all
> other things being equal. Whatever cataclysm is used to explain
> the effect, it was surely both unique and temporary, but during its
> influence it had a strong positive heat-subtraction influence on
> the parts of the Earth affected.
So now it's the Lisp Ice Age? I think I need some waders, it's getting
deep in here...
> Now, back to Lisp and AI: The AI winter was in fact an active campaign
> by management of many organizations to specifically reject AI (and,
> per guilt by assiciation, Lisp), rather than a removal of efforts by
> those who were pro-AI/pro-Lisp. What caused this sudden cataclysm?
> The promulgation of hype (either actively, or by failing to warn
> against downsides) about what Lisp and AI could do within the next
> 10 years at that time. The hype was very promising, and perhaps
> those not in the know extrapolated unscientifically as to what the
> implications were. Examples:
> - When "Block World" was created, the TV "science" shows were
> running rampant about how Asimov's worlds were coming true, and
> "thinking machines" would be prevalent within 10 years (it hasn't
> yet happened).
> - Speech synthesis was predicted, and even accomplished, within
> the normal timeframe of the AI peak. But the voices were unnatural,
> and only now are voices sounding more natural and esthetic.
> - Speech recognition was predicted, but took a lot longer than
> predicted (probably by about 20 years, by my own observation).
> - etc.
>
> Anyway, those corporations that could profit most by AI technology
> and who were taken in by (or manufacutred some of) this hype dumped
> billions of dollars into the projects, and most got absolutely
> nothing out of them, or at least close enough to nothing to call
> the projects disasters.
So AI was Lisp's only market? And still is? Sorry, I'm at a loss to try to
fathom this illogic. Following you to your logical extreme, the internet
boom and bust should have killed any or all of '(java c++ asp vb .net perl
php sql etc.) Especially since monetary losses were equal, on relative
terms, to the AI losses you describe. Our whole industry is a disaster. Just
ask anybody in construction. The people I speak with don't know how we
rationalize our paychecks - we're typically late, over budget and ship poor
quality. Your company sells a product that addresses all those
problems and you can't beat PHP for marketshare?
> If you were a manager, and you dumped a billion dollars into
> a specific piece of technology that had a 0% ROI, then regardless of
> why the technology failed to meet your expectations, what would
> you be saying about that technology today, if you actually managed to
> keep your job? Or, in fact, if you had been fired over it, and
> had been forced to take lower-paying jobs elsewhere, what would you
> do when the technology came across your desk? Would such a reaction
> be rational? Might anybody even know why you despise AI and Lisp?
Give me a break. This logic is so awful it's embarrasing. Extrapolating:
Given 20 programming languages and an 80% failure rate for all software
projects, how many languages would be left standing after one decade?
According to your logic, none. I have been a manager and I have been
associated with projects that failed. If you have people trained in C++ and
the project fails, the manager is fired (unless you work for a really great
company, then they're promoted) and the next project, if there's funding, is
written in C++. Otherwise, people are out on the street looking for work.
That's just life.
Truth is, people don't like Lisp because we're an image-conscious,
"everything is marketing" creature and Lisp has a *very bad name* from a
marketing perspective. It's like Colgate-Palmolive invented an amazing
detergent and branded it "Filth" then blamed poor sales on a "Detergent
Winter". Just doesn't happen that way. A lisp is a speech impediment. Few
people are willing to look beyond the name and realize any benefit from the
language. So, instead of saying they hate the name to our face (it is "our
baby" after all), they say things like, "I hate the parenthesis." Yeah,
gotcha, no parenthesis in Java. Sex sells. That's why academics try to
look real smart. It's an image thing...
> We in the newly blossoming Lisp industry must never make the same
> mistake again. We must never hype the abilities of Lisp; we must
> instead show solid facts for what Lisp can do. I see alarming trends
> in this area; the old myths of Lisp being 10X more efficient than
> other languages is resurfacing - let's face it; there is no hard data,
> and the anecdotal data points to 2 to 4 times design efficiency,
> rather than 10X that has been shown. A single case of 10X does not
> qualify as evidence; in the presence of subjective and anectdotal
> data we should take advice from Gymnastics scoring techniques, where
> one highest and one lowest score are tossed out routinely to ensure
> that the curve is more accurately centered at the mean.
"A single case of 10X does not qualify as evidence..." Yes it does.
It's a single data point but it's data. In my case, I had 3 total shots
at the same product. One I cleaned up (MS tools), another I co-authored
(Java) and the Lisp version I designed and built. Two were abject
failures, costing, minimum 4 man years (coding only) using tools I was
familiar with. The Lisp project took 6 weeks and was 100% complete with
1 person - and I'd never built a Lisp application in my life.
You do the math. That's not 10X, that's infinitely better *because
the product was finished*.
Yeah, yeah, yeah...no mistakes, ever again. Right. What species are you part
of? I'm in the "to err is human" part of the family. My life is a series of
corrections from malapropism's, misunderstandings, foot-in-mouth disease,
freudian slips, drops, tears and spills with remarkable suprises
interspersed when things actually work. Face it. When people find
something cool they oversell it. I'm happy telling people that Lisp
provides a minimum 10-20% productivity gain. The point to me isn't to
exagerate, it's to show how to get more done in less time - to sell
leverage.
> That 400 pound sled you described used to be much heavier.
> It must be on a diet, because it is shedding pounds. But we must
> also be careful not to add to its weight. The dogs are still
> pulling (arf, arf) and we canines are growing in number, but the
> weight of the sled will determine whether or not the sled will
> move. I do know many people who got tired of pulling the sled.
> There weren't millions of reasons; there was only one: it was
> too heavy. Some have come back.
The sled was an analogy describing company's that willingly ignore Lisp as a
productivity tool. It wasn't an analogy about Lisp or its' advocates. People
are willingly pulling the sled by using C++, C#, Java, etc., ignoring Lisp.
It's a horse-racing, handicapping analogy. Sheesh... :)
The people I knew didn't get tired. They got scared and they quit because
they didn't want to stand up and speak their mind. I know they quit, because
the C++ advocates who'd failed in other projects didn't quit. The Lisp
people sold out their coworkers and their companies by not promoting Lisp in
a rational manner. Keeping silent is to not an option. So I open my mouth
and get flak for it. No problem, I have...wait for it...here it
comes...DATA.
Don't you? Doesn't your company? Real, published data showing how hard it is
to write code in C++ compared to Lisp? If Java is an attempt to drag people
halfway to Lisp, shouldn't you be showing them the Direct Route?
I said before that people told me not to put Lisp on my resume.
They're being proved right because the Lisp industry - including your
company - isn't creating any jobs. And haven't been for years. AI Winter
indeed. AI is alive and well and being coded in Java. What do you guys do
out there in Berzerkly all day?
> You can trivialize the AI winter, but please don't be revisionist
> about it, if you didn't live through it. It happened, and if you
> don't recognize it you are doomed to repeat its mistakes.
Doomed to repeat what mistakes? I'm not selling Lisp for AI and I'm not
promising the moon. The Darpa funded AI boom ended. That's a fact. Funding
in the late 80's to early 90's dried up for lots of things, including
commercial software projects. Lots of companies failed. War. Recession.
Boogey men. It was a bad time. But, after that, where was Lisp?
I see commercial opportunity with Lisp. There's a market just begging for
relief from the awful tools people are using failure after failure after
failure...how the hell you guys could be married to the notion of Lisp
suffering through the last 10 years because of the AI Winter is beyond me.
Hey, maybe there's opportunity out there for a knothead like myself. I'm
just dumb enough to try to sell Lisp as a solution for normal human
problems, not just AI.
Mike
Mike Ajemian wrote:
> My life is a series of corrections from malapropism's,
> misunderstandings, foot-in-mouth disease, freudian slips, drops,
> tears and spills with remarkable suprises interspersed when things
> actually work.
You know, that's a very underrated way to code.
Drunken Wrist Style.
> Our whole industry is a disaster. Just ask anybody
> in construction. The people I speak with don't know how we
> rationalize our paychecks - we're typically late, over budget and
> ship poor quality. Your company sells a product that addresses all
> those problems and you can't beat PHP for marketshare?
Distorted industries exist everywhere you look. Which is why I think
considering computing in a bubble doesn't get us far.
* Journalism: take Jon Stewart's criticisms -- journalists look to his
fake news show for good journalism
http://www.c-span.org/search/basic.asp?ResultStart=1&ResultCount=10&BasicQueryText=jon+stewart&image1.x=0&image1.y=0&image1=Submit
* Music: is Britney really the best ever?
http://www.nme.com/news/111454.htm
* Food: McD's has world-beating marketshare
* Democracy: where participation is usually limited to voting for Coke
vs. Pepsi (you know, Bush vs. Kerry), and many citizens must resort to
demonstrations to have any chance of participating in their nations.
* Economy: in an enormously wealthy city of the world's wealthiest
nation, over 50% of NYC children reportedly grow up in poverty
http://cccnewyork.org/genfacts.html
* Prison: the world's wealthiest nation somehow beats China and Russia
in imprisonment -- and prisoners are used for cheap labor which can't
unionize
http://www.homeoffice.gov.uk/rds/pdfs2/r234.pdf
And the funny thing is, execs love to blame their customers. CNN execs
claim viewers only want car chases and MJ Simpson, not news. But the
truth is their news sucks.
"They who have put out the people's eyes, reproach them of their
blindness." -- John Milton
"Mike Ajemian" <············@verizon.net> writes:
> [...]
> Truth is, people don't like Lisp because we're an image-conscious,
> "everything is marketing" creature and Lisp has a *very bad name* from a
> marketing perspective. It's like Colgate-Palmolive invented an amazing
> detergent and branded it "Filth" then blamed poor sales on a "Detergent
> Winter". Just doesn't happen that way. A lisp is a speech impediment. Few
> people are willing to look beyond the name and realize any benefit from the
> language. So, instead of saying they hate the name to our face (it is "our
> baby" after all), they say things like, "I hate the parenthesis." Yeah,
> gotcha, no parenthesis in Java. Sex sells. That's why academics try to
> look real smart. It's an image thing...
Yes. That's why we should keep naming it LISP and even: L.I.S.P. (ell
aie ess pee) as in "List & Introspective Symbolic Processing".
But I don't mind, personnally I don't program in Common-Lisp, I
program in L++.
(DEFUN LIST-EXTERNAL-SYMBOLS (PACKAGE &KEY (SORTED T))
(LET ((PACK (FIND-PACKAGE PACKAGE)))
(IF PACK
(LET ((SL '())) (DO-EXTERNAL-SYMBOLS (S PACK) (PUSH S SL))
(IF SORTED (SORT SL (FUNCTION STRING<)) SL))
(ERROR "No package ~S" PACKAGE))))
(DEFUN COPY-PACKAGE (OLD-PACKAGE NEW-NAME)
(LET ((NEW-PACKAGE (MAKE-PACKAGE NEW-NAME))
(SYMBOLS (LIST-EXTERNAL-SYMBOLS OLD-PACKAGE :SORTED NIL)))
(IMPORT SYMBOLS NEW-PACKAGE)
(EXPORT SYMBOLS NEW-PACKAGE)
NEW-PACKAGE))
(COPY-PACKAGE "COMMON-LISP" "L++")
(DEFPACKAGE "L++-USER" (:USE "L++"))
(IN-PACKAGE "L++-USER")
> [...]
> Yeah, yeah, yeah...no mistakes, ever again. Right. What species are you part
> of? I'm in the "to err is human" part of the family. My life is a series of
> corrections from malapropism's, misunderstandings, foot-in-mouth disease,
> freudian slips, drops, tears and spills with remarkable suprises
> interspersed when things actually work. Face it. When people find
> something cool they oversell it. I'm happy telling people that Lisp
> provides a minimum 10-20% productivity gain. The point to me isn't to
> exagerate, it's to show how to get more done in less time - to sell
> leverage.
10%-20% better is no reason to switch. The costs are too high. You
have to change the coding monkey (or worse, teach them the new tools),
you have to change the tool-chains, perhaps even you'll have to change
the hardware. To displace the existing competitor you must be at
least 10X better.
> [...]
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
Pascal Bourguignon <····@mouse-potato.com> writes:
> 10%-20% better is no reason to switch. The costs are too high. You
> have to change the coding monkey (or worse, teach them the new tools),
> you have to change the tool-chains, perhaps even you'll have to change
> the hardware. To displace the existing competitor you must be at
> least 10X better.
Numbers again. Where do they come from?
According to Computerworld [1], software companies are outsourcing
development to other countries for savings of 80% in wages resulting
in net savings of 15-30%. That's less than 2x better.
[1] http://www.computerworld.com/managementtopics/outsourcing/story/0,10801,98252,00.html
<On 11 Mar 2005 21:49:33 +0100, Pascal Bourguignon <····@mouse-potato.com>
wrote:
How come such a terse language gives such verbose remarks?
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Mike Ajemian wrote:
>
> So AI was Lisp's only market? And still is? Sorry, I'm at a loss to try to
> fathom this illogic. Following you to your logical extreme, the internet
> boom and bust should have killed any or all of '(java c++ asp vb .net perl
> php sql etc.) Especially since monetary losses were equal, on relative
> terms, to the AI losses you describe. Our whole industry is a disaster. Just
> ask anybody in construction. The people I speak with don't know how we
> rationalize our paychecks - we're typically late, over budget and ship poor
> quality. Your company sells a product that addresses all those
> problems and you can't beat PHP for marketshare?
>
Construction is just as bad. The whole mentality now is to estimate
things with so much slack it cannot possibly fail (they do anyways).
Many construction projects end in a flurry of law-suits with people
trying to recover their costs and "blame the other guy". I was
a construction co-ordinator for a while a we hired an old welder
to weld some pipes. The other young guys hounded him out because
he was 10x (there is that number again) faster and more productive.
The mentality of mediocrity is everywhere.
It took only one year and 45 days to build the Empire State Building.
http://history1900s.about.com/library/misc/blempirefacts.htm
It would take 5x as long to do it today.
Wade
Wade Humeniuk <··················@telus.net> writes:
> Construction is just as bad. The whole mentality now is to estimate
> things with so much slack it cannot possibly fail (they do anyways).
> Many construction projects end in a flurry of law-suits with people
> trying to recover their costs and "blame the other guy". I was
> a construction co-ordinator for a while a we hired an old welder
> to weld some pipes. The other young guys hounded him out because
> he was 10x (there is that number again) faster and more productive.
> The mentality of mediocrity is everywhere.
>
> It took only one year and 45 days to build the Empire State Building.
>
> http://history1900s.about.com/library/misc/blempirefacts.htm
>
> It would take 5x as long to do it today.
Sorry to contradict, but it would take *more* than 10x as long to do
it today. (And it's logical, if old workers were 10x faster than
current workers).
Data point:
Hotel Bali of Benidorm Empire State Building
height 186 m 381 m
flats 52 102
years to build 14 years 1.12 years
Actually, it's 27x or 28x slower (weither you count flats or height).
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot. don't bother saving your artefacts.
"Mike Ajemian" <············@verizon.net> writes:
> Hmmm, read the marketing crap I wrote below. I mean, every other language
> has jobs available except Lisp. That's not AI Winter, that's Lisp Drought.
That isn't the summary I would personally use.
The problem was that when all those AI projects failed, the way they
"bought" their second chance to do things in other languages was to
sell out Lisp. They claimed it was Lisp, not bad management, that
caused the failure. The implication? Well, I personally infer from
this bold claim that if only those failing projects had begun with C++
in the mid 1980's, we'd have been knee-deep in successful AI programs
by the 90's. I don't buy it.
They then rescued from Lisp what they probably never could have
written in C++ from scratch in terms of knowledge engines and other
tools, deploying them and then crediting C++ ...
Lisp's unwilling and unwarranted sacrifice saved many an AI company.
It seems unfair to retroactively say that Lisp was the only one to
experience it. Lisp was the only one cranking out AI ideas until
people scrambling to save themselves made it politically unfashionable
to crank out ideas in Lisp, and then suddenly all these other
languages were the "obvious" choice.
Every time there's an end to a market investment bubble, someone gets
scapegoated. Remember the ".com" crash? Do you REALLY think it's the
use of a foo.com that is the problem? Might it possibly be the myriad
goofy statements instead like "We've found a new economics where you
don't have to break even in order to have a successful company." ...?
A great many things changed in the new world order of the Internet,
but one of them that didn't was the basic rules of business, yet I'll
bet a bunch of people who spouted utter economic gibberish were
allowed to blame their failures on ".coms" and then to go on with
starting new companies.
Further, Lisp was also a victim of its own success in that if you're
cash poor, you keep your ear very close to what customers are asking
for, whereas if you have lots of cash you sometimes start dreaming
about the future. Lisp was doing well enough that it didn't cater
enough to the interchange standards like static linked libraries, COM,
DLLs, sockets libraries, and so on for a period of about 10 years, and
then had to play catch-up with a world that had figured out a more or
less peaceful way for multiple languages to co-exist. Today, those
gaps are in many places repaired, but it wasn't timed well, and the
effort to make those repairs has kept Lisp a bit behind the curve
since then. Which is not to say it doesn't have other compensating
advantages, but there are ceratinly reasons that it's had trouble
getting back into the mainstream. During the interim it was away, C,
C++, and Java were duking it out for the hearts and minds of computer
centers everywhere, and by the time Lisp was back in the game, the
issues were less technical and more political. Large production
houses have a lot of programmers in one or another of those other
languages, and it would be a loss of power and stature for them to
change.
Besides, at this point, free software has turned the economics of
software so much on its head that I don't know if I understand any more
what it would mean for a language to "succeed" (or "fail"). It's not
like they go away if no one uses them, nor like they get used by everyone
if they succeed...
> [...] AI is alive and well and being coded in Java.
Hmm.
> I see commercial opportunity with Lisp. There's a market just begging for
> relief from the awful tools people are using failure after failure after
> failure...
Are these those same people who are coding in Java? Or some other people?
"Kent M Pitman" <······@nhplace.com> wrote in message
··················@nhplace.com...
> "Mike Ajemian" <············@verizon.net> writes:
>
>
> Further, Lisp was also a victim of its own success in that if you're
> cash poor, you keep your ear very close to what customers are asking
> for, whereas if you have lots of cash you sometimes start dreaming
> about the future. Lisp was doing well enough that it didn't cater
> enough to the interchange standards like static linked libraries, COM,
> DLLs, sockets libraries, and so on for a period of about 10 years, and
> then had to play catch-up with a world that had figured out a more or
> less peaceful way for multiple languages to co-exist.
This is very true. I could imagine many curious beginners turned away by
simple things
they can't do before they get a chance to learn apparently great things they
_can_ do.
Like
- Creating standalone EXE's
- Creating DLL's
- Various libraries that one has come to expect (http, xml, database
access etc.)
- Native multi threading.
- Many high quality open source lisps have no Win32 ports. (no offence to
clisp)
I think, the barrier of entry is a bit high for most casual beginners.
"pj" <···@hotmail.com> writes:
> "Kent M Pitman" <······@nhplace.com> wrote in message
> ··················@nhplace.com...
>> "Mike Ajemian" <············@verizon.net> writes:
>>
>>
>> Further, Lisp was also a victim of its own success in that if
>> you're cash poor, you keep your ear very close to what customers
>> are asking for, whereas if you have lots of cash you sometimes
>> start dreaming about the future. Lisp was doing well enough that it
>> didn't cater enough to the interchange standards like static linked
>> libraries, COM, DLLs, sockets libraries, and so on for a period of
>> about 10 years, and then had to play catch-up with a world that had
>> figured out a more or less peaceful way for multiple languages to
>> co-exist.
>
> This is very true. I could imagine many curious beginners turned
> away by simple things they can't do before they get a chance to
> learn apparently great things they _can_ do.
>
> Like
> - Creating standalone EXE's
> - Creating DLL's
Just out of curiosity, how do you create standalone EXEs and DLLs in
Java, Python, Perl, or Ruby?
> - Various libraries that one has come to expect (http, xml, database
> access etc.)
Libraries for all three of those, at least, seem to exist for Common
Lisp. Look up (Portable)AllegroServe, XMLS, CL-XML, and CL-SQL.
> - Native multi threading.
Do Python, Perl, and Ruby have native multithreading now? (They may, I
know Perl has some support for threads but last I was paying attention
it was still sort of bolted on.)
> I think, the barrier of entry is a bit high for most casual
> beginners.
I agree that there are many reasons that folks give up on Lisp before
they really get started and I even agree that those reasons include
the ones you cite. But I think that's more about people wanting to
find excuses to not have to learn something new than real barriers.
Thus I think the answer is for Lispers to do their best to present
Lisp as a practical language. I've made some efforts in that direction
myself recently but the best way to convince the skeptical is to write
software in Lisp.
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@gigamonkeys.com> writes:
> I agree that there are many reasons that folks give up on Lisp before
> they really get started and I even agree that those reasons include
> the ones you cite. But I think that's more about people wanting to
> find excuses to not have to learn something new than real barriers.
Well, these barriers were real for a while in the late 80's and early
90's. Now, as has happened many times in Lisp's past, we have the
problem also that the public has a memory of the excuses it uses and
assumes that the excuses still apply.
In part, I think this is because most people are users of static
languages, and such languages teach people to think statically--that
is, to think that any time you entrench the knowledge of the day is as
good as any other. Lisp, by contrast, teaches you to think that
today's knowledge might not be tomorrow's. So we often assume things
will change with people, when often it's not going to.
But also, lots of time people just make up their mind and their
excuses are just cover for their lazy desire not to reconsider the
world. The more they can appeal to a simple, easy-to-grab rule, the
more they don't have to do any real work.
In part, this is probably a natural consequence of the information
explosion. We're transitioning from a world with a thirst to know
into a world with a thirst to dismiss, to ignore, to not know... or,
in engineering terms, to seek "good enough". And if you set your
sights low enough on the programming project you're using, just about
anything is good enough. And who's going to set their sights high if
they've never seen good results?
> Thus I think the answer is for Lispers to do their best to present
> Lisp as a practical language. I've made some efforts in that direction
> myself recently but the best way to convince the skeptical is to write
> software in Lisp.
We're in agreement here.
Kent M Pitman <······@nhplace.com> writes:
> Peter Seibel <·····@gigamonkeys.com> writes:
>
>> I agree that there are many reasons that folks give up on Lisp before
>> they really get started and I even agree that those reasons include
>> the ones you cite. But I think that's more about people wanting to
>> find excuses to not have to learn something new than real barriers.
>
> Well, these barriers were real for a while in the late 80's and early
> 90's. Now, as has happened many times in Lisp's past, we have the
> problem also that the public has a memory of the excuses it uses and
> assumes that the excuses still apply.
>
This is what I have seen also. In addition I see a typical reluctance
of people to put real effort in something before getting result.
If it's hard it's not good. Lisp takes some effort to get results and
this is too much for many of today's software "engineers".
With some 10 years of programming experience under my belt I see many
of the younger people abandon approaches that require more than average
effort.
Being smart means to reuse code that's there and that's easy to understand.
Lisp is dense because the syntactic sugar is just not there. I had and
still have that experience myself when switching back and forth between
C and Lisp. For me, it does require some effort to "switch to Lisp
mode" again. It's a different way of thinking. This is what makes the
difference for me between Lisp and every other mainstream language
out there.
> In part, I think this is because most people are users of static
> languages, and such languages teach people to think statically--that
> is, to think that any time you entrench the knowledge of the day is as
> good as any other. Lisp, by contrast, teaches you to think that
> today's knowledge might not be tomorrow's. So we often assume things
> will change with people, when often it's not going to.
>
Yes, that's what I confirm also from what I see with junior programmers -
with exceptions, of course.
> But also, lots of time people just make up their mind and their
> excuses are just cover for their lazy desire not to reconsider the
> world. The more they can appeal to a simple, easy-to-grab rule, the
> more they don't have to do any real work.
>
Again, this is a wide-spread phenomenom not only in the software business.
> In part, this is probably a natural consequence of the information
> explosion. We're transitioning from a world with a thirst to know
> into a world with a thirst to dismiss, to ignore, to not know... or,
> in engineering terms, to seek "good enough". And if you set your
> sights low enough on the programming project you're using, just about
> anything is good enough. And who's going to set their sights high if
> they've never seen good results?
The shift you describe requires a different education: Not knowing as much
as possible is a good thing - because it's too much. Young people see this
because email and SMS and mobile phones are just everywhere and anytime.
They do not know how to think for a couple of hours before actually doing
something. There will be emails or an SMS or a mobile phone call or sth
else as a distraction.
So: education needs to teach how to concentrate on a specific task and
how to focus on sth without being drawn away from it by distractions.
If we learn how to focus on things (a task, a problem, a challenge)
then the thinking process will come to the point when we ask ourselves:
How can I do this with the best of elegance in my solution?
(Because just solving it is then not more the task at hand)
This also requires other measures in today's job environments. Managers
need to understand that company performance depends on elegant
(maintainable, scalable, flexible) solutions - not on solutions with
short-term optimization in time-to-market.
>
>> Thus I think the answer is for Lispers to do their best to present
>> Lisp as a practical language. I've made some efforts in that direction
>> myself recently but the best way to convince the skeptical is to write
>> software in Lisp.
>
> We're in agreement here.
Hm. For reasons explained also in this thread I think this is not enough.
A solution architect or lead programmer or other decision making person
in the software creation process or organization needs the freedom to
choose the tools and technology that best suits the task.
Even if Lisp is better for a task and the corporate technology strategy
does not allow for Lisp to be used "just because" then Lisp can be better
a 100x without getting used.
So: Management principles (such a MBO: management by objectives) are
a critical ingrediant for a certain technology to become a part of a
solution.
But: Of course we need efforts like Peter's book and also an active
user community to sell Lisp as a means for doing work - in a more
elegant and therefore in a way to the benefit of the company.
My summary is that we need a wide approach for Lisp to get used in
real projects - new books, Lisp conferences, examples for successes,
c.l.l., an standard
Frank Goenninger DG1SBG <················@t-online.de> writes:
> Kent M Pitman <······@nhplace.com> writes:
>
>> Peter Seibel <·····@gigamonkeys.com> writes:
>>
>>> I agree that there are many reasons that folks give up on Lisp before
>>> they really get started and I even agree that those reasons include
>>> the ones you cite. But I think that's more about people wanting to
>>> find excuses to not have to learn something new than real barriers.
>>
>> Well, these barriers were real for a while in the late 80's and early
>> 90's. Now, as has happened many times in Lisp's past, we have the
>> problem also that the public has a memory of the excuses it uses and
>> assumes that the excuses still apply.
>>
> This is what I have seen also. In addition I see a typical reluctance
> of people to put real effort in something before getting result.
>
> If it's hard it's not good. Lisp takes some effort to get results and
> this is too much for many of today's software "engineers".
>
> With some 10 years of programming experience under my belt I see many
> of the younger people abandon approaches that require more than average
> effort.
>
> Being smart means to reuse code that's there and that's easy to understand.
>
> Lisp is dense because the syntactic sugar is just not there. I had and
> still have that experience myself when switching back and forth between
> C and Lisp. For me, it does require some effort to "switch to Lisp
> mode" again. It's a different way of thinking. This is what makes the
> difference for me between Lisp and every other mainstream language
> out there.
>
>> In part, I think this is because most people are users of static
>> languages, and such languages teach people to think statically--that
>> is, to think that any time you entrench the knowledge of the day is as
>> good as any other. Lisp, by contrast, teaches you to think that
>> today's knowledge might not be tomorrow's. So we often assume things
>> will change with people, when often it's not going to.
>>
>
> Yes, that's what I confirm also from what I see with junior programmers -
> with exceptions, of course.
>
>> But also, lots of time people just make up their mind and their
>> excuses are just cover for their lazy desire not to reconsider the
>> world. The more they can appeal to a simple, easy-to-grab rule, the
>> more they don't have to do any real work.
>>
>
> Again, this is a wide-spread phenomenom not only in the software business.
>
>> In part, this is probably a natural consequence of the information
>> explosion. We're transitioning from a world with a thirst to know
>> into a world with a thirst to dismiss, to ignore, to not know... or,
>> in engineering terms, to seek "good enough". And if you set your
>> sights low enough on the programming project you're using, just about
>> anything is good enough. And who's going to set their sights high if
>> they've never seen good results?
>
> The shift you describe requires a different education: Not knowing as much
> as possible is a good thing - because it's too much. Young people see this
> because email and SMS and mobile phones are just everywhere and anytime.
> They do not know how to think for a couple of hours before actually doing
> something. There will be emails or an SMS or a mobile phone call or sth
> else as a distraction.
>
> So: education needs to teach how to concentrate on a specific task and
> how to focus on sth without being drawn away from it by distractions.
>
> If we learn how to focus on things (a task, a problem, a challenge)
> then the thinking process will come to the point when we ask ourselves:
> How can I do this with the best of elegance in my solution?
> (Because just solving it is then not more the task at hand)
>
> This also requires other measures in today's job environments. Managers
> need to understand that company performance depends on elegant
> (maintainable, scalable, flexible) solutions - not on solutions with
> short-term optimization in time-to-market.
>
>>
>>> Thus I think the answer is for Lispers to do their best to present
>>> Lisp as a practical language. I've made some efforts in that direction
>>> myself recently but the best way to convince the skeptical is to write
>>> software in Lisp.
>>
>> We're in agreement here.
>
> Hm. For reasons explained also in this thread I think this is not enough.
> A solution architect or lead programmer or other decision making person
> in the software creation process or organization needs the freedom to
> choose the tools and technology that best suits the task.
>
> Even if Lisp is better for a task and the corporate technology strategy
> does not allow for Lisp to be used "just because" then Lisp can be better
> a 100x without getting used.
>
> So: Management principles (such a MBO: management by objectives) are
> a critical ingrediant for a certain technology to become a part of a
> solution.
>
> But: Of course we need efforts like Peter's book and also an active
> user community to sell Lisp as a means for doing work - in a more
> elegant and therefore in a way to the benefit of the company.
>
> My summary is that we need a wide approach for Lisp to get used in
> real projects - new books, Lisp conferences, examples for successes,
> c.l.l., an standard
Woops - send that article before finishing that last sentence. Sorry.
Here's what I wanted to say:
a Standard (I see more need for standardization - we all know the areas),
an discussion like this - but more in non-lisp environments and not on
c.l.l.
With best regards,
Frank
Frank Goenninger DG1SBG <················@t-online.de> writes:
> Kent M Pitman <······@nhplace.com> writes:
>
> > Peter Seibel <·····@gigamonkeys.com> writes:
...
> >> Thus I think the answer is for Lispers to do their best to present
> >> Lisp as a practical language. I've made some efforts in that direction
> >> myself recently but the best way to convince the skeptical is to write
> >> software in Lisp.
> >
> > We're in agreement here.
>
> Hm. For reasons explained also in this thread I think this is not enough.
> A solution architect or lead programmer or other decision making person
> in the software creation process or organization needs the freedom to
> choose the tools and technology that best suits the task.
>
> Even if Lisp is better for a task and the corporate technology strategy
> does not allow for Lisp to be used "just because" then Lisp can be better
> a 100x without getting used.
>
> So: Management principles (such a MBO: management by objectives) are
> a critical ingrediant for a certain technology to become a part of a
> solution.
>
> But: Of course we need efforts like Peter's book and also an active
> user community to sell Lisp as a means for doing work - in a more
> elegant and therefore in a way to the benefit of the company.
>
> My summary is that we need a wide approach for Lisp to get used in
> real projects - new books, Lisp conferences, examples for successes,
> c.l.l., an standard
Well, I certainly don't deny that there are approaches for making
painstaking progress in certain corporate and management situations.
And having various kind of collateral always helps. I wasn't meaning
to say it was "enough" to merely program ahead and ignore these other
issues; I was just saying that a lot of philosophy and no practical
successes won't convince people either.
The problem is multi-dimensional and just plain hard.
But it is made accidentally easier by business successes. Once you're
successful, people like to imitate you, and that's certainly a
favorable situation to be in over a missionary-style sale to the
[perceived] unwashed.
But I do think we've seen our worst times, because Lisp was at its
worst when memory sizes were small, memory cycles were expensive, etc.
That was a nearly insurmountable problem.
Plus, the modern world expects mix-and-match heterogeneous solutions,
so there's often at least a potential place for Lisp. People do need
to be ready to notice such places and ready to make the case.
One of the biggest mistakes that can be made is to try for an
all-or-none success, or to win by showing someone they don't like they
tool they're used to. Let people use what they're happy with for as
long as they're happy and achieving the goals they want to achieve.
But call them out when they are ducking hard goals or finding the
goals they have taken on to be insurmountable, and tell them about
technology you know that would allow them to keep pressing ahead
instead of backing up from perceived inevitable defeat.
Kent M Pitman <······@nhplace.com> writes:
> Frank Goenninger DG1SBG <················@t-online.de> writes:
>
>> Kent M Pitman <······@nhplace.com> writes:
>>
>> > Peter Seibel <·····@gigamonkeys.com> writes:
> ...
>> >> Thus I think the answer is for Lispers to do their best to present
>> >> Lisp as a practical language. I've made some efforts in that direction
>> >> myself recently but the best way to convince the skeptical is to write
>> >> software in Lisp.
>> >
>> > We're in agreement here.
>>
>> Hm. For reasons explained also in this thread I think this is not enough.
>> A solution architect or lead programmer or other decision making person
>> in the software creation process or organization needs the freedom to
>> choose the tools and technology that best suits the task.
>>
>> Even if Lisp is better for a task and the corporate technology strategy
>> does not allow for Lisp to be used "just because" then Lisp can be better
>> a 100x without getting used.
>>
>> So: Management principles (such a MBO: management by objectives) are
>> a critical ingrediant for a certain technology to become a part of a
>> solution.
>>
>> But: Of course we need efforts like Peter's book and also an active
>> user community to sell Lisp as a means for doing work - in a more
>> elegant and therefore in a way to the benefit of the company.
>>
>> My summary is that we need a wide approach for Lisp to get used in
>> real projects - new books, Lisp conferences, examples for successes,
>> c.l.l., an standard
>
> Well, I certainly don't deny that there are approaches for making
> painstaking progress in certain corporate and management situations.
> And having various kind of collateral always helps. I wasn't meaning
> to say it was "enough" to merely program ahead and ignore these other
> issues; I was just saying that a lot of philosophy and no practical
> successes won't convince people either.
Absolutely: I was saying just this in the previous section also. So, yes,
I see you did not just say it is enough to program ahead and ignore
other factors.
>
> The problem is multi-dimensional and just plain hard.
Yes!
>
> But it is made accidentally easier by business successes. Once you're
> successful, people like to imitate you, and that's certainly a
> favorable situation to be in over a missionary-style sale to the
> [perceived] unwashed.
So, why oh why did the Yahoo Store example not boost Lisp in a way
every startup company is using it today? I think the answer to this
question gives a multitude of insights albeit it is not easy to
get the real answer.
>
> But I do think we've seen our worst times, because Lisp was at its
> worst when memory sizes were small, memory cycles were expensive, etc.
> That was a nearly insurmountable problem.
>
> Plus, the modern world expects mix-and-match heterogeneous solutions,
> so there's often at least a potential place for Lisp. People do need
> to be ready to notice such places and ready to make the case.
Agreed. This is why we need to integrate with hypes. Lsharp and UFFI
are very good examples how to integrate Lisp with other environments
to be able to plug-in Lisp into a bigger solution. We need to make
sure that this kind of work is kept going.
>
> One of the biggest mistakes that can be made is to try for an
> all-or-none success, or to win by showing someone they don't like they
> tool they're used to.
Do you say you need to like people in order to convince them? My
experience is that you need to be able to convince also people you
don't like - after all, this is business we are speaking about.
What you really need is to know what people motivates (not just to
listen what they say they want but what the reasons are for them
to say what they want). If you know this you can convince them by
giving them energy to what motivates them - and that is in most
cases very effective (and sometimes people even do not notice you
address them on that level).
Ok. Enough philosophy ;-)
> Let people use what they're happy with for as
> long as they're happy and achieving the goals they want to achieve.
Very true. You need to give them the freedom to do so. And this is
influenced by management principles in the business environment.
You need to say "I want you to achieve this and that" instead of
"You need to use the language X and the tool Y to make this and that".
Tell this the management levels involved in immediate decision
making and when they behave like this then we get the ground for
improving the situation.
> But call them out when they are ducking hard goals or finding the
> goals they have taken on to be insurmountable, and tell them about
> technology you know that would allow them to keep pressing ahead
> instead of backing up from perceived inevitable defeat.
This requires that people have a broad knowledge of technology - and
that is why education is important. Computer Science used to be an
education where you have been taught the basic principles and then
the available tools (languages, implementations,...) with the
ability to judge what's good and what's bad in which situation.
Today, in many cases, you get to know that you are a good CS student
if you know how to program in the current hype language. Why ?
Frank
Frank Goenninger DG1SBG schrieb:
> Kent M Pitman <······@nhplace.com> writes:
Hallo
This is interesting so here are some thoughts about from my side.
**********************************************************
> > The problem is multi-dimensional and just plain hard.
> Yes!
And years goes by.
**********************************************************
> > But I do think we've seen our worst times, because Lisp was at its
> > worst when memory sizes were small, memory cycles were expensive, etc.
> > That was a nearly insurmountable problem.
> > Plus, the modern world expects mix-and-match heterogeneous solutions,
> > so there's often at least a potential place for Lisp. People do need
> > to be ready to notice such places and ready to make the case.
> Agreed. This is why we need to integrate with hypes. Lsharp and UFFI
> are very good examples how to integrate Lisp with other environments
> to be able to plug-in Lisp into a bigger solution. We need to make
> sure that this kind of work is kept going.
Hype is good for sellers. They need this to keep the show going on. They
do not ask for details. Hype is only good for business.
When you develop something new, this is never a hype, maybe sensation,
sometimes. This is in most cases something like a risk. And that is in
no case good for business. A seller has to invest various things to
bring something new to the market. Why should one do so, while
established products work fine?
Users who use something new are forceed to invest time and should be
able to learn, think and often leave the hype-ways behind. Maybe out
there are people, that can develop and sell at the same time - I can
not.
In my case, I like to go on using Lisp, because something new can be
done easy. Easier than in any language I know and there are not many
others, cause I do not look at those as long I have something to work
with.
The question is: How to develop the next hype. (be sure, you want that,
this can be done)
> > One of the biggest mistakes that can be made is to try for an
> > all-or-none success, or to win by showing someone they don't like they
> > tool they're used to.
> Do you say you need to like people in order to convince them? My
> experience is that you need to be able to convince also people you
> don't like - after all, this is business we are speaking about.
> What you really need is to know what people motivates (not just to
> listen what they say they want but what the reasons are for them
> to say what they want). If you know this you can convince them by
> giving them energy to what motivates them - and that is in most
> cases very effective (and sometimes people even do not notice you
> address them on that level).
On the car-market this is called showroom. Not only a success-story or a
in-use example. More a quite event between the user and the product,
there is intuition and kind of unknown progress between "I like that"
and "Do not want", but this is personally every time a bit different.
What makes you feel like "home"?
Else learning a new way to program is not a thing for a day, in special,
when the language enfold to think a (large) bit different. As you know,
many people hear about Lisp, but they are miles away to use it...
(standarts: too many ((())) )
(You know there are trucks and truck drivers, but did you ever drive
one?)
> > Let people use what they're happy with for as
> > long as they're happy and achieving the goals they want to achieve.
> Very true. You need to give them the freedom to do so. And this is
> influenced by management principles in the business environment.
In special here with Lisp, you can write code like you thought (have in
mind) and there are not so much depends like in other kinds off ~.
Yeah, pioneers are used to make the first step. What follows can be
hype. These are 2 worlds. Exploring something new needs to be able to
react for something unexpected while hype-ways exactly means the
opposite, react as expect, every time.
To build a bridge there is a difficult act. Trappers don't like to much
civilization and civilization do not recognize trappers. Lisp is a
tool-box and tools usually are not in the living room. Well, one can use
tools to create a comfortable chair for the living room, but the
tool-box remains in the garage. Hm? Did a typical tool-worker sit in a
nice living room chair? I mean, thats the place for braindead ones, so
spend them a TV and let sleeping take place, otherwise... oh oh :)
...keep it as a big secret and tell them on their favorite TV-channel
that there is a big secret.
Repeat:
> > The problem is multi-dimensional and just plain hard.
> Yes!
Lets find solutions. A good description of the area may help there.
> Tell this the management levels involved in immediate decision
> making and when they behave like this then we get the ground for
> improving the situation.
Or, tell it to universities, where next-generation managers can test the
stuff. (See, this happens today and did not bring more Lisp to the
world)
> Today, in many cases, you get to know that you are a good CS student
> if you know how to program in the current hype language. Why ?
Analyze the changing point of hype languages.
stefan
ride that do-it-all macro beast
pj schrieb:
> This is very true. I could imagine many curious beginners turned away by
> simple things
> they can't do before they get a chance to learn apparently great things they
> _can_ do.
> Like
> - Creating standalone EXE's
> - Creating DLL's
> - Various libraries that one has come to expect (http, xml, database
> access etc.)
> - Native multi threading.
> - Many high quality open source lisps have no Win32 ports. (no offence to
> clisp)
... and move the smile-icon around the screen...
> I think, the barrier of entry is a bit high for most casual beginners.
As I remember, once I named this "newbie-mode". If a beginner sits
infront of his box and plays with the interpreter, it often happens,
that he caused things he could not follow in his head. And it is not
very amusing to search and pickup readmes, howtodos, docs an so one from
the internet, this took weeks to realize, while switching to java my do
the expecting things in one hour...
The other point I hear about is the mind that presenting a command-line
looks poor and will not be accepted from many not-lisp-knowers.
But I don't look at that. Someone who knows whats going on, or someone
who is experienced will see, what Lisp is worth. Therefor I do not
understand these talks about Lisp. Is it just from the money-maker-side?
Than please shut-up. Solid quality can speak for its own.
Just some rhetoric?
To what kind of programmers are this words adressed? What is the typical
beginner? Who needs Lisp realy to do what nothing other can? Is it so
good to take c++ or java coders on board? Do you fear other languages
can take out Lisp? Last: Why do you use Lisp?
stefan
Kent M Pitman wrote:
> "Mike Ajemian" <············@verizon.net> writes:
>
>
>>Hmmm, read the marketing crap I wrote below. I mean, every other language
>>has jobs available except Lisp. That's not AI Winter, that's Lisp Drought.
>
>
> That isn't the summary I would personally use.
>
> The problem was....
OK folks, this it, last call. If you want to publish on The Death of
Lisp please take care of that in the next few weeks. After then we will
be too busy with manuscripts on How Lisp Won to give you much attention.
See y'all at the next Lisp Job Fair.
kenny
ps. Jeez, I can't Peter is going to get credit for inventing Lisp. My
McCarthy Laptop will be worthless!
k
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
"Kent M Pitman" <······@nhplace.com> wrote in message
··················@nhplace.com...
> "Mike Ajemian" <············@verizon.net> writes:
>
> > Hmmm, read the marketing crap I wrote below. I mean, every other
language
> > has jobs available except Lisp. That's not AI Winter, that's Lisp
Drought.
>
> That isn't the summary I would personally use.
>
> The problem was that when all those AI projects failed, the way they
> "bought" their second chance to do things in other languages was to
> sell out Lisp. They claimed it was Lisp, not bad management, that
> caused the failure. The implication? Well, I personally infer from
> this bold claim that if only those failing projects had begun with C++
> in the mid 1980's, we'd have been knee-deep in successful AI programs
> by the 90's. I don't buy it.
>
The ol' "we couldn't get anything done because of the crappy old tool we
begged you to buy in the first place after our own careful analysis and
evaluation. This time we'll get it right with C++", scenario?
> They then rescued from Lisp what they probably never could have
> written in C++ from scratch in terms of knowledge engines and other
> tools, deploying them and then crediting C++ ...
This is really disappointing.
> Lisp's unwilling and unwarranted sacrifice saved many an AI company.
> It seems unfair to retroactively say that Lisp was the only one to
> experience it. Lisp was the only one cranking out AI ideas until
> people scrambling to save themselves made it politically unfashionable
> to crank out ideas in Lisp, and then suddenly all these other
> languages were the "obvious" choice.
So Lisp and AI are pretty much joined at the hip? That seems to be such a
common theme, I guess I better just accept it...
> Every time there's an end to a market investment bubble, someone gets
> scapegoated. Remember the ".com" crash? Do you REALLY think it's the
> use of a foo.com that is the problem? Might it possibly be the myriad
> goofy statements instead like "We've found a new economics where you
> don't have to break even in order to have a successful company." ...?
> A great many things changed in the new world order of the Internet,
> but one of them that didn't was the basic rules of business, yet I'll
> bet a bunch of people who spouted utter economic gibberish were
> allowed to blame their failures on ".coms" and then to go on with
> starting new companies.
>
<shaking fist and scowling>It was pet.com's fault! Burn the puppet!
I cleaned up some sw for a company that might just as well have piled all
their money in the middle of the office and lit it on fire. They were in so
far over their heads. Yet, when the game ended, the founders and their
senior staff were funded by the VC's to start other companies. It's the old,
"The devil I know is better than the devil I don't", I guess.
> Further, Lisp was also a victim of its own success in that if you're
> cash poor, you keep your ear very close to what customers are asking
> for, whereas if you have lots of cash you sometimes start dreaming
> about the future. Lisp was doing well enough that it didn't cater
> enough to the interchange standards like static linked libraries, COM,
> DLLs, sockets libraries, and so on for a period of about 10 years, and
> then had to play catch-up with a world that had figured out a more or
> less peaceful way for multiple languages to co-exist. Today, those
> gaps are in many places repaired, but it wasn't timed well, and the
> effort to make those repairs has kept Lisp a bit behind the curve
> since then. Which is not to say it doesn't have other compensating
> advantages, but there are ceratinly reasons that it's had trouble
> getting back into the mainstream. During the interim it was away, C,
> C++, and Java were duking it out for the hearts and minds of computer
> centers everywhere, and by the time Lisp was back in the game, the
> issues were less technical and more political. Large production
> houses have a lot of programmers in one or another of those other
> languages, and it would be a loss of power and stature for them to
> change.
This is the history I'm after. Thanks. Sounds like Lisp was/is more 'nix
centric and took some time finding MS Windows? In your opinion, does the
name "Lisp" present a hurdle to adoption?
I'd say 2-4x reduction in development time is a pretty significant
"compensating advantage".
> Besides, at this point, free software has turned the economics of
> software so much on its head that I don't know if I understand any more
> what it would mean for a language to "succeed" (or "fail"). It's not
> like they go away if no one uses them, nor like they get used by everyone
> if they succeed...
>
Recently made the decision not to use Gnu tools anymore as I don't agree
with the goals and objectives of the organization. If Bill Gates was really
evil wouldn't *he* be the one demanding people sign over their copyright?
Well, he's evil for other reasons.
The economics seem to be simple. One way or another, they're going to give
away your product - either by you signing it over, or them cloning and
knocking it off.
I just want to finish some software that I've been working on to sell for
profit so I can hire developers and grow a company. Somehow, that makes me
feel "old" (as in out-of-touch with the times).
> > [...] AI is alive and well and being coded in Java.
>
> Hmm.
>
Ahem <whistling and looking at shoes>...Not buying it, I see...Alright! It
might not be true, but I liked the way it sounded.
> > I see commercial opportunity with Lisp. There's a market just begging
for
> > relief from the awful tools people are using failure after failure after
> > failure...
>
> Are these those same people who are coding in Java? Or some other people?
Yes. No. Maybe. Both. I wasn't there. I don't know...what was the question
again? Why would it matter what language they use? Oh, the AI Java stuff?
Anybody - AI or non-AI, Java or non-Java types. So long as they can benefit
from the tool. Why sell a milling machine to somebody that just needs a
hammer?
All the information you've provided has been very helpful. It still leaves
me wondering why there are so few Lisp jobs for such a powerful tool? That's
the most difficult thing to fathom. If the .com bust really forced companies
to look at the bottom line, wouldn't that be a great opportunity for Lisp
solutions to step in?
Mike
"Mike Ajemian" <············@verizon.net> writes:
> > Lisp's unwilling and unwarranted sacrifice saved many an AI
> > company. It seems unfair to retroactively say that Lisp was the
> > only one to experience it. Lisp was the only one cranking out AI
> > ideas until people scrambling to save themselves made it
> > politically unfashionable to crank out ideas in Lisp, and then
> > suddenly all these other languages were the "obvious" choice.
>
> So Lisp and AI are pretty much joined at the hip? That seems to be
> such a common theme, I guess I better just accept it...
Lisp wasn't dependent on AI, but AI was once dependent on Lisp.
Then AI sold out Lisp as the price of survival, at least for a while.
I heard a lot of people who know they couldn't have figured out how to
develop something in C++ say that C++ was suddenly just as good. I
don't think they were always disingenuous. But they were certainly
short-sighted as to why suddenly C++ was ok, and I think the answer
was: (a) it was what was paying and (b) they weren't giving credit to
the great difficulty of developing a product in the first place, and
they were saying (unrealistically) that porting something like a
knowledge engine to another language is no more complicated than
inventing the concept of that same knowledge engine from scratch.
Good development involves a lot of changes. C++ does not tolerate
change as well as Lisp does. Java neihter. They are languages that
are for something with a strong spec that doesn't change a lot.
> This is the history I'm after. Thanks. Sounds like Lisp was/is more
> 'nix centric and took some time finding MS Windows? In your opinion,
> does the name "Lisp" present a hurdle to adoption?
No, I don't think this is fair. Lisp was GENERAL. It was nothing
centric. It survived MANY, MANY changes of operating systems. You
know of only a small number of operating systems, if you think it's
all *nix vs windows (vs mac). But in the olden days, we had
conditionals for dozens of operating systems, and we designed a
language that would not play favorites.
In fact, it the market's decision about how to address the operating
system problem was very different. Kill anything that doesn't look
like ... uh, well, like the PC looking like a Mac. (That is, the Mac
comes up with the good ideas, PC standardizes them, the linux
community grudgingly reimplements them--trying always to do better,
but in the end coming up with something that looks like a poor man's
substitute for Windows.) So, in this regard, Lisp went through a
period of time (extending even somewhat to today) where it was
criticized for not having the forethought to be specific to the
specific winners.
> I'd say 2-4x reduction in development time is a pretty significant
> "compensating advantage".
Depends on how you market it.
We wasted a lot of time marketing smaller investment in development
teams. I don't know who liked that less: the teams that didn't want
to get laid off or the managers that didn't want to manage smaller
organizations.
But also, there is a subtle (in its visibility) but huge (in its
effect) difference between the order in which you do things in
developing Lisp vs C++/Java. In Lisp, you often get something
prototyped long before it's product quality. In other languages, it's
unlikely you're going to do much to your design or implementation
after it runs at all, so the investment is much more front-loaded.
This is an opportunity for managers who are unaware to radically
misfocus their development dollars and/or to oversell what is a
prototype, among other things.
> > Besides, at this point, free software has turned the economics of
> > software so much on its head that I don't know if I understand any
> > more what it would mean for a language to "succeed" (or "fail").
> > It's not like they go away if no one uses them, nor like they get
> > used by everyone if they succeed...
>
> Recently made the decision not to use Gnu tools anymore as I don't
> agree with the goals and objectives of the organization.
Btw, I don't push this as an outcome. One can barely afford NOT to
use Gnu tools. The whole problem in a capitalist environment is you
can't charge for things that your competition doesn't pay for but you
do. Eventually the cost will affect your ability to shrink out the
margins that the market engine is designed to shrink out.
> If Bill Gates was really evil wouldn't *he* be the one demanding
> people sign over their copyright? Well, he's evil for other
> reasons.
I'll side-step this. I'm not his greatest supporter, but I don't
think demonizing him helps either. I prefer to speak of behavior that
is good and behavior that is bad, and hope that all people are capable
of good if correctly guided/led/... not that I suppose he's looking to
ME for leadership.
> The economics seem to be simple. One way or another, they're going
> to give away your product - either by you signing it over, or them
> cloning and knocking it off.
>
> I just want to finish some software that I've been working on to
> sell for profit so I can hire developers and grow a
> company. Somehow, that makes me feel "old" (as in out-of-touch with
> the times).
Yeah...
> All the information you've provided has been very helpful. It still
> leaves me wondering why there are so few Lisp jobs for such a
> powerful tool? That's the most difficult thing to fathom. If the
> .com bust really forced companies to look at the bottom line,
> wouldn't that be a great opportunity for Lisp solutions to step in?
Well, consider that to be a manager, it helps to have used the tool
and to be looking back and wanting to direct others doing it. Most
Lisp programmers probably have not outgrown the desire to program in
Lisp, which probably means there are a lot of people dead-tired at
programming Visual Basic or C++ or Java (or even FORTRAN or COBOL) who
are more anxious to "lead" you forward in a tool they understand than
one they don't.
And then there's that other issue I mentioned above which is that the
development path is just different.
> "Mike Ajemian" <············@verizon.net> writes:
>>
>> All the information you've provided has been very helpful. It still
>> leaves me wondering why there are so few Lisp jobs for such a
>> powerful tool? That's the most difficult thing to fathom. If the
>> .com bust really forced companies to look at the bottom line,
>> wouldn't that be a great opportunity for Lisp solutions to step in?
I have looked at all of the open source HLLs now. I have decided that
languages don't matter nearly so much as tools, support, and developer
culture. In particular, I find the open source crowd doesn't deal with
Windows developer culture. The HLL people don't deal with 3D game developer
culture, nor do the 3D game developers deal with HLL culture. Sure there
may be opportunities, but it's also the opportunity to invent everything
from scratch yourself. If you've got that much time, money, and manpower to
throw at R&D, you may consider business models other than pissing everything
away on the unproven.
Nevertheless, because I simply can't stand C++, Java, and C#, and Python is
too slow, I still pursue a compiled HLL business model for Windows game
development. One of these days, it may work and then I'll be filthy rich
uber-guru guy instead of dirt poor vagabond nobody guy like I am now. I'm
taking the high road because I have an overwhelming personal intolerance for
the low road. I really would sooner dig ditches and mow lawns; I've
actually made those decisions in the past 2 years.
When I have my Star Trek voice activated computer, I will be happy. Who
needs this programmer shit!
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
Taking risk where others will not.
"Brandon J. Van Every" <·····························@yahoo.com> writes:
> When I have my Star Trek voice activated computer, I will be happy. Who
> needs this programmer shit!
Well, I certainly agree that Star Trek is a GREAT metric of what people
want interfaces to be. The pressure to be concise really boils out the
extra business and leaves you with just the amount of interaction that
people have the patience and desire to deal with.
But even so, the philosophical question will always haunt us as a society:
do we, or do we not... (or maybe even: can we, or can we not...)
understand what the computer is doing for us, and adjust it.
Maybe the answer will be that to get to the Star Trek world we'll have to
build a neural net and let it grow up, and we'll have to endure our computers
having temper tantrums like Trelane has in Squire of Gothos. Or maybe we'll
have to program things a subroutine at a time from "hello, world" to
"hello, captain kirk". Maybe it doesn't matter which way we go, or maybe
only one of those ways can succeed. But if it's going to be the painstaking
subroutine-at-a-time way we seem to be going now, I sure hope we don't have
to do it all in C++ or Java.
"Scotty, you have to do it all in 45 seconds or we'll all be blown to bits."
"Sorry, Captain, but ya remember last week when I approached you about doing
everything over in Lisp so that I could handle situations like this in finite
time? I'm afraid that even if I could make the change in the time allotted,
just uselessly recompiling all the affected base classes would take more time
than we have... So I guess this is it..."
Kent M Pitman <······@nhplace.com> writes:
> "Scotty, you have to do it all in 45 seconds or we'll all be blown to bits."
>
> "Sorry, Captain, but ya remember last week when I approached you about doing
> everything over in Lisp so that I could handle situations like this in finite
> time? I'm afraid that even if I could make the change in the time allotted,
> just uselessly recompiling all the affected base classes would take more time
> than we have... So I guess this is it..."
Well, we _know_ that the Start Trek computer wasn't programmed in Lisp,
or else its AI was pretty shoddy. How else would it have been so easy
to shut it down by giving it a priority directive to compute the value
of PI to the last place? If the program were truly smart, it would
have finished very quickly with a #<condition result-incomputable>
Aha! Now _that's_ why Lisp is so much perceived to be unpopular:
imagine a future world where the computer were smart enough to
protect itself - there wouldn't have been any story! So all of
the dramas that never were to be, and all of the interesting conflicts
that could never have happened, all contribute to the realization
that the future in which Lisp takes over would provide no
entertainment value at all! If worse-is-better, then worst-is-best?
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
>
> Aha! Now _that's_ why Lisp is so much perceived to be unpopular:
> imagine a future world where the computer were smart enough to
> protect itself - there wouldn't have been any story! So all of
> the dramas that never were to be, and all of the interesting conflicts
> that could never have happened, all contribute to the realization
> that the future in which Lisp takes over would provide no
> entertainment value at all! If worse-is-better, then worst-is-best?
I take it you haven't seen or read "I, Robot."
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
"Brandon J. Van Every" <·····························@yahoo.com> writes:
> Duane Rettig wrote:
> >
> > Aha! Now _that's_ why Lisp is so much perceived to be unpopular:
> > imagine a future world where the computer were smart enough to
> > protect itself - there wouldn't have been any story! So all of
> > the dramas that never were to be, and all of the interesting conflicts
> > that could never have happened, all contribute to the realization
> > that the future in which Lisp takes over would provide no
> > entertainment value at all! If worse-is-better, then worst-is-best?
>
> I take it you haven't seen or read "I, Robot."
Another incorrect perception :-) I've read and seen both.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> "Brandon J. Van Every" <·····························@yahoo.com>
> writes:
>
>> Duane Rettig wrote:
>>>
>>> Aha! Now _that's_ why Lisp is so much perceived to be unpopular:
>>> imagine a future world where the computer were smart enough to
>>> protect itself - there wouldn't have been any story! So all of
>>> the dramas that never were to be, and all of the interesting
>>> conflicts that could never have happened, all contribute to the
>>> realization that the future in which Lisp takes over would provide
>>> no entertainment value at all! If worse-is-better, then
>>> worst-is-best?
>>
>> I take it you haven't seen or read "I, Robot."
>
> Another incorrect perception :-) I've read and seen both.
In "I, Robot," the Master Computer was smart enough to protect itself, and
there was indeed a story that resulted from it. The story was that robots
would necessarily evolve, and would not mindlessly obey the Three Laws Of
Robotics forever.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
"Brandon J. Van Every" <·····························@yahoo.com> writes:
> Duane Rettig wrote:
> > "Brandon J. Van Every" <·····························@yahoo.com>
> > writes:
> >
> >> Duane Rettig wrote:
> >>>
> >>> Aha! Now _that's_ why Lisp is so much perceived to be unpopular:
> >>> imagine a future world where the computer were smart enough to
> >>> protect itself - there wouldn't have been any story! So all of
> >>> the dramas that never were to be, and all of the interesting
> >>> conflicts that could never have happened, all contribute to the
> >>> realization that the future in which Lisp takes over would provide
> >>> no entertainment value at all! If worse-is-better, then
> >>> worst-is-best?
> >>
> >> I take it you haven't seen or read "I, Robot."
> >
> > Another incorrect perception :-) I've read and seen both.
>
> In "I, Robot," the Master Computer was smart enough to protect itself, and
> there was indeed a story that resulted from it. The story was that robots
> would necessarily evolve, and would not mindlessly obey the Three Laws Of
> Robotics forever.
[Warning: somehwat of a spoiler: don't read if you haven't seen the movie...]
Actually, that's not true. In both the book and the movie, the theory
behind the three laws is laid out (and is the same), but in the book
Asimov explores the possible ramifications of alterations of the three
laws and how particular nonconformances result in particular behaviors.
But in the movie, before which any Asimov fan will be asking what piece
of the three laws is going to be perverted in this story, it turns out
that the laws are perfectly obeyed; the aberrent behavior stems from the
logical conclusion that the three laws must imply. It is the three laws
themselves that are imperfect...
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> Kent M Pitman <······@nhplace.com> writes:
>
>
>>"Scotty, you have to do it all in 45 seconds or we'll all be blown to bits."
>>
>>"Sorry, Captain, but ya remember last week when I approached you about doing
>>everything over in Lisp so that I could handle situations like this in finite
>>time? I'm afraid that even if I could make the change in the time allotted,
>>just uselessly recompiling all the affected base classes would take more time
>>than we have... So I guess this is it..."
>
>
> Well, we _know_ that the Start Trek computer wasn't programmed in Lisp,
> or else its AI was pretty shoddy. How else would it have been so easy
> to shut it down by giving it a priority directive to compute the value
> of PI to the last place?
Try to keep up, will you? What about the episode where he drives the
renegade system into a nervous breakdown by pointing out that having
killed six hundred Star Fleeters was inconsistent with one of its
functional constraints? Hmm?
> If the program were truly smart, it would
> have finished very quickly with a #<condition result-incomputable>
Nonsense. I have the rational right here, regrettably too small to fit
in the margin. But it's a little more than three.
>
> Aha! Now _that's_ why Lisp is so much perceived to be unpopular:
> imagine a future world where the computer were smart enough to
> protect itself - there wouldn't have been any story!
Helloooo? 2001, A Space Odyssey? <sigh> Had you seen the sequel 2010,
you would know Hal killed the crew because.. nah, why spoil it for you
all. Suffice to say, the better the AI, the better the breakdown story.
kt
Kenny Tilton <·······@nyc.rr.com> writes:
> Duane Rettig wrote:
> > Kent M Pitman <······@nhplace.com> writes:
> >
>
> >>"Scotty, you have to do it all in 45 seconds or we'll all be blown to bits."
> >>
> >>"Sorry, Captain, but ya remember last week when I approached you about doing
> >>everything over in Lisp so that I could handle situations like this in finite
> >>time? I'm afraid that even if I could make the change in the time allotted,
> >>just uselessly recompiling all the affected base classes would take more time
> >>than we have... So I guess this is it..."
> > Well, we _know_ that the Start Trek computer wasn't programmed in
> > Lisp,
>
> > or else its AI was pretty shoddy. How else would it have been so easy
> > to shut it down by giving it a priority directive to compute the value
> > of PI to the last place?
>
> Try to keep up, will you? What about the episode where he drives the
> renegade system into a nervous breakdown by pointing out that having
> killed six hundred Star Fleeters was inconsistent with one of its
> functional constraints? Hmm?
Obviously, that was _after_ the third Lisp renaissance. You don't
remember the episode that explained all that? Well, that's Lisp in
the marketplace for you.
> > If the program were truly smart, it would
> > have finished very quickly with a #<condition result-incomputable>
>
> Nonsense. I have the rational right here, regrettably too small to fit
> in the margin. But it's a little more than three.
22/7. Right.
> > Aha! Now _that's_ why Lisp is so much perceived to be unpopular:
>
> > imagine a future world where the computer were smart enough to
> > protect itself - there wouldn't have been any story!
>
> Helloooo? 2001, A Space Odyssey? <sigh> Had you seen the sequel 2010,
> you would know Hal killed the crew because.. nah, why spoil it for you
> all. Suffice to say, the better the AI, the better the breakdown story.
One of my colleagues sent this message to the office over 12 years
ago; I couldn't help but save it (names blanked):
=====
Return-Path: xxx
Return-Path: <xxx>
Received: from crisp.Franz.COM by clay.Franz.COM (4.0/FI-1.0)
id AA01144; Wed, 8 Jan 92 16:07:33 PST
Received: by crisp.Franz.COM (4.0/FI-1.0)
id AA01591; Wed, 8 Jan 92 16:07:23 PST
Date: Wed, 8 Jan 92 16:07:23 PST
From: xxx
To: yyy
Subject: HAL's birth
Just read on hackers_guild that according to "2001, A Space
Odyssey", HAL is born on 12-Jan-92, this Sunday.
=====
But in reality the historians of Space Odyssey took poetic license
with the dates (probably because they wanted so much for the AI hype
to be true, and would have spiked the incredulity of SciFi fans if
they'd given correct dates); so in reality HAL is just now being
brought up, and the space adventure will take place in 2011, after
which Lisp will be blamed for HAL's failure and that will start the
next AI winter...
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> so in reality HAL is just now being
> brought up, and the space adventure will take place in 2011, after
> which Lisp will be blamed for HAL's failure and that will start the
> next AI winter...
Shades of Terminator 3. You still wanna stick to this idea that defensive
computers have no story to them?
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
"Brandon J. Van Every" <·····························@yahoo.com> writes:
> Duane Rettig wrote:
> > so in reality HAL is just now being
> > brought up, and the space adventure will take place in 2011, after
> > which Lisp will be blamed for HAL's failure and that will start the
> > next AI winter...
>
> Shades of Terminator 3. You still wanna stick to this idea that defensive
> computers have no story to them?
Not defensive; _sucessfully_ defensive. My exact description of
such computers was "smart enough to protect itself". Obviously,
none of the computers in these examples were smart enough to
protect themselves (they were smart enough to _try_, but were
not successful), hence the story in each case...
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> Just read on hackers_guild that according to "2001, A Space
> Odyssey", HAL is born on 12-Jan-92, this Sunday.
I believe the date is different in the book and movie, though I don't
recall which was which.
Bonus points if you can say where HAL's name came from.
Kent M Pitman wrote:
>
> Bonus points if you can say where HAL's name came from.
> > >
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
Kent M Pitman wrote:
> Duane Rettig <·····@franz.com> writes:
>
>> Just read on hackers_guild that according to "2001, A Space
>>Odyssey", HAL is born on 12-Jan-92, this Sunday.
>
> I believe the date is different in the book and movie, though I don't
> recall which was which.
>
> Bonus points if you can say where HAL's name came from.
Old story: IBM shifted by one letter. ;)
Pascal
On Thu, 17 Mar 2005 10:39:23 +0100, Pascal Costanza <··@p-cos.net> wrote:
> Kent M Pitman wrote:
>
>> Bonus points if you can say where HAL's name came from.
>
> Old story: IBM shifted by one letter. ;)
"although this has been denied by both Arthur C. Clarke and
Dr. Chandra, who states that 'by now, any idiot should know that
HAL stands for Heuristic ALgorythm'"
<http://en.wikipedia.org/wiki/HAL_9000>
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz schrieb:
> On Thu, 17 Mar 2005 10:39:23 +0100, Pascal Costanza <··@p-cos.net> wrote:
> > Kent M Pitman wrote:
> >> Bonus points if you can say where HAL's name came from.
> > Old story: IBM shifted by one letter. ;)
> "although this has been denied by both Arthur C. Clarke and
> Dr. Chandra, who states that 'by now, any idiot should know that
> HAL stands for Heuristic ALgorythm'"
Ahja, heuristic:
"Lehre von den Methoden
zur Auffindung neuer
wissenschaftlicher Erkenntnisse"
Nop.
HAL means in truth:
Hire All Lispner
So, guess why there is a movie titled with "...2010"
Nop.
(hint)
Somebody cannot do (reverse) to the original numbers.
oh-oh
stefan
Trust HAL:
"The 9000er series never make a mistake"
Kenny Tilton wrote:
> Helloooo? 2001, A Space Odyssey? <sigh> Had you seen the sequel 2010,
> you would know Hal killed the crew because.. nah, why spoil it for
you
> all. Suffice to say, the better the AI, the better the breakdown
story.
>
> kt
If you watch carefully, there's a screenful of Fortran code in 2001
which I can only assume is part of HAL's source code. Geez, as if Lisp
doesn't get enough blame for problems with AI already..
··········@gmail.com writes:
> Kenny Tilton wrote:
>
> > Helloooo? 2001, A Space Odyssey? <sigh> Had you seen the sequel 2010,
>
> > you would know Hal killed the crew because.. nah, why spoil it for
> you
> > all. Suffice to say, the better the AI, the better the breakdown
> story.
> >
> > kt
>
> If you watch carefully, there's a screenful of Fortran code in 2001
> which I can only assume is part of HAL's source code. Geez, as if
> Lisp doesn't get enough blame for problems with AI already..
Maybe that's some code written by a human that HAL was looking over.
Maybe he was spending his spare cycles answering homework
questions on comp.lang.fortran.
"Duane Rettig" <·····@franz.com> wrote in message
··················@franz.com...
> Kent M Pitman <······@nhplace.com> writes:
>
> Aha! Now _that's_ why Lisp is so much perceived to be unpopular:
> imagine a future world where the computer were smart enough to
> protect itself - there wouldn't have been any story!
I always thought the computer in The Matrix was programmed in Lisp. I also
vaguely recall something lisp-like for one of the Terminator robots....
"Gorbag" <······@invalid.acct> wrote in message
·················@bos-service2.ext.ray.com...
>
> "Duane Rettig" <·····@franz.com> wrote in message
> ··················@franz.com...
> > Kent M Pitman <······@nhplace.com> writes:
> >
>
> > Aha! Now _that's_ why Lisp is so much perceived to be unpopular:
> > imagine a future world where the computer were smart enough to
> > protect itself - there wouldn't have been any story!
>
> I always thought the computer in The Matrix was programmed in Lisp. I also
> vaguely recall something lisp-like for one of the Terminator robots....
Really? I recall 6502 machine code. It was, after all, an embedded app.
Perhaps I should be redirecting to c.l.forth now...
Regards,
Will Hartung
(·····@msoft.com)
Will Hartung schrieb:
> "Gorbag" <······@invalid.acct> wrote in message
> > "Duane Rettig" <·····@franz.com> wrote in message
> > I always thought the computer in The Matrix was programmed in Lisp. I also
> > vaguely recall something lisp-like for one of the Terminator robots....
> Really? I recall 6502 machine code. It was, after all, an embedded app.
> Perhaps I should be redirecting to c.l.forth now...
Agent Smith says: (about the failure of the first matrix engine)
"Perhaps we do not have the right programming language ..."
It is not so clear, what language the machines then use for the next
matrix wourld, but ...
... can we take Lisp to generate a better Lisp?
(see what the compiler does, seems a step to the rihgt direction?)
stefan
"Mike Ajemian" <············@verizon.net> wrote on Fri, 11 Mar 2005:
> Truth is, people don't like Lisp because we're an image-conscious,
> "everything is marketing" creature and Lisp has a *very bad name* from a
> marketing perspective. It's like Colgate-Palmolive invented an amazing
> detergent and branded it "Filth" then blamed poor sales on a "Detergent
> Winter". Just doesn't happen that way. A lisp is a speech impediment. Few
> people are willing to look beyond the name and realize any benefit from the
> language. So, instead of saying they hate the name to our face (it is "our
> baby" after all), they say things like, "I hate the parenthesis."
You've got to be kidding. You denigrate everyone else's explanation for
Lisp's lack of popular success, and then _this_ is the best you can come up
with? That Lisp failed because the name is bad marketing?
When you're rethinking your silly theory, consider:
1. Lisp was very popular in the early 80's, when it had the very same name.
2. Scheme and Dylan are two very close languages in the Lisp family
(the latter even took out the parentheses), yet they found no more
popular success than mainstream Lisp.
Try again. Your theory on Lisp's popularity is obviously wrong. At least
the theories of other people were open to debate, not laughable like yours.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Any man, in the right situation, is capable of murder. But not any man is
capable of being a good camper. So, murder and camping are not as similar as
you might think. -- Deep Thoughts by Jack Handey [SNL]
Don Geddis <···@geddis.org> writes:
> "Mike Ajemian" <············@verizon.net> wrote on Fri, 11 Mar 2005:
> > [...] Few people are willing to look beyond the name and realize
> > any benefit from the language. So, instead of saying they hate the
> > name to our face (it is "our baby" after all), they say things
> > like, "I hate the parenthesis."
>
> You've got to be kidding. You denigrate everyone else's explanation for
> Lisp's lack of popular success, and then _this_ is the best you can come up
> with? That Lisp failed because the name is bad marketing?
>
> When you're rethinking your silly theory, consider:
> 1. Lisp was very popular in the early 80's, when it had the very same name.
> 2. Scheme and Dylan are two very close languages in the Lisp family
> (the latter even took out the parentheses), yet they found no more
> popular success than mainstream Lisp.
>
> Try again. Your theory on Lisp's popularity is obviously wrong. At least
> the theories of other people were open to debate, not laughable like yours.
Indeed.
Superficial arguments like those Mike advances are more likely to be
advanced to the totally unaware as a way of telling them "it's ok to
be dismissive".
It's like the way racial stereotypes are useful ways of telling people
they don't have to interact with broad groups of people. Everyone in
a world as big as ours is daunted by the sheer size of it all, and is
looking for ways of saying (a) there's some big, concerted enemy out
there who's the cause of all problems and (b) it's easy to recognize
them on sight, so you just ignore that whole class of people or, even
better, treat them as non-people.
What makes race hatred, or gender discrimination, or the problem with
parentheses so insidious is the sheer relaxing nature of it. Wow, you
can boil a whole world of problems down to a simple syntactic test that
has no apparent relation whatsoever to the problem at hand? Skin color
affects trustworthiness how? Gender affects intelligence or skill how?
Placement of parens affects problem solving capability how?
Ah, but if you can find people dumb enough to be dissuaded from going
down those paths by the mere application of syntax, why waste your
breath telling them the real reasons? You've got control of their
hearts already, why even try talking to their brains anyway?
And for them, the accidental fact that syntax can divine such grand truths
is soooo relaxing. Why ever would they want to give up their comfortable
superstitions?
In fact, this is what's so frustrating about the postmodern world in
which not every white is out to do in every black (nor every white to
do in every black), not every man is out to do in every woman (nor
every woman out to do in every man), ... and not every program with
algebraic syntax is fast, nor every program with Lispy syntax slow.
Now people are forced to think to know who their friends and enemies
are. And I'm not sure everyone likes that.
I don't think the people who mention parens often really care. I
think they just think OTHERS will hear this side-track and get so
caught up in that they don't consider the real issues.
Just like I don't think the people in the recent US election who
mentioned gay marriage and abortion as much as they did really think
those two issues matter. They just know that if they can keep the
Religious Right whipped up on those two issues, they'll not have time
to think about whether things like wars, shutting down social
security, cutting back hospital funds, etc. are Moral. It's not like
the Republican party is the party of Morality in the US, but as long
as they can keep the discussion on a few simple, fear-inducing
superficialities, they can control the debate. If the debate goes to
REAL issues, they can't. And the debate gets messy, with no clear
winners and losers. People hate that, too.
"Kent M Pitman" <······@nhplace.com> wrote in message
··················@nhplace.com...
> Don Geddis <···@geddis.org> writes:
>
> > "Mike Ajemian" <············@verizon.net> wrote on Fri, 11 Mar 2005:
> > > [...] Few people are willing to look beyond the name and realize
> > > any benefit from the language. So, instead of saying they hate the
> > > name to our face (it is "our baby" after all), they say things
> > > like, "I hate the parenthesis."
> >
> > You've got to be kidding. You denigrate everyone else's explanation for
> > Lisp's lack of popular success, and then _this_ is the best you can come
up
> > with? That Lisp failed because the name is bad marketing?
> >
> > When you're rethinking your silly theory, consider:
> > 1. Lisp was very popular in the early 80's, when it had the very same
name.
> > 2. Scheme and Dylan are two very close languages in the Lisp family
> > (the latter even took out the parentheses), yet they found no more
> > popular success than mainstream Lisp.
> >
> > Try again. Your theory on Lisp's popularity is obviously wrong. At
least
> > the theories of other people were open to debate, not laughable like
yours.
>
Every once in a while I do something so wrong...so I'd like to play my
Mulligan. Hooked that shot pretty damn badly. Besides, Mr. Geddis suggested
I try again, so here goes...
I was thinking about why there might be so few Lisp jobs so I could figure
out how to sell myself or the language into the job market. I'd had some
good hard data about my own experience for quite some time and had presented
it to numerous tech friends. They didn't care about productivity gains, cost
savings or other important metrics. Many highlighted staffing concerns. Some
said the lack of libraries. Others represented misconceptions that were
easily dispelled. All pretty normal stuff that could be argued in favor of
Lisp. Some risk, but manageable. Suprisingly, many said they didn't like the
name of the language. Some were so passionate in their disdain for the name
"Lisp" they looked like they were going to either stroke out or get violent
as the conversation progressed. It isn't often that a name engenders such
passion. So, what if it really was named something else? Would that really
help the Lisp market? I seriously doubted it, but it sure did start to feel
that something might be holding Lisp back. So, I entertained the possibility
that the name really does get in the way. With such a long history, it
didn't seem plausible to really go ahead and actually change the name. That
meant Lisp had to be the name, but that Lisp couldn't be the name...Then it
dawned on me that Lisp could follow the lead of Prince, the musician who
changed his name to a symbol, and become:
Lambda - the language formerly known as Lisp
You'd never know from what I presented, but that was what I was thinking.
I'll admit I made a mistake with regard to parenthesis. Hell, I made a
mistake by not editing my post...
> Indeed.
>
> Superficial arguments like those Mike advances are more likely to be
> advanced to the totally unaware as a way of telling them "it's ok to
> be dismissive".
Wow. Now I'm ignorant and coercive. My lucky day. I may have completely
missed the mark with my "Hunter S. Thompson" style post but there was no
agenda here. I just had an off day trying to post something edgy that
reflected my general frustrations with Lisp and the Lisp job market. Maybe I
should do what my uncle says and learn Cobol because there are "lots of jobs
for Cobol coders". HST was right, "when the going gets weird, the weird turn
pro."
Mike Ajemian wrote:
>
> Lambda - the language formerly known as Lisp
That's a terrible name. Do better.
Maybe some people don't like the sound of the word "Lisp." Maybe some
people don't like what the word means in plain English. Most people
probably disdain it for its technical associations - too many parentheses,
AI rubbish, stuff they got forced to do in a CS class that they didn't
understand, etc. In the past, others have suggested that Lisp could be born
anew, marketing-wise, if only a version was put out that wasn't called Lisp.
Old wine in new bottles.
This begs a question: who's marketing Lisp *now* ? Is Lisp unpopular for
the very simple reason that nobody actively markets it? Granted I haven't
read computer magazines in a long time, but I've never seen a full page ad
for a Lisp anywhere. I've never seen a vendor booth at a conference or
trade show. Testimonials in the game industry exist (Naughty Dog, Square)
but are rare, and nobody seems interested in reproducing their results. If
there is actually any Lisp marketing going on, it isn't reaching me.
Lisp has no heavyweight industrial champion. Heck, even Python doesn't.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
When no one else sells courage, supply and demand take hold.
From: Duane Rettig
Subject: Re: Lisp marketing (was Re: I get it)
Date:
Message-ID: <4is3s3ce6.fsf@franz.com>
"Brandon J. Van Every" <·····························@yahoo.com> writes:
> This begs a question: who's marketing Lisp *now* ? Is Lisp unpopular for
> the very simple reason that nobody actively markets it? Granted I haven't
> read computer magazines in a long time, but I've never seen a full page ad
> for a Lisp anywhere. I've never seen a vendor booth at a conference or
> trade show. Testimonials in the game industry exist (Naughty Dog, Square)
> but are rare, and nobody seems interested in reproducing their results. If
> there is actually any Lisp marketing going on, it isn't reaching me.
Be reached. Come to the ILC this year and see how "unpopular" Lisp
really is (http://www.international-lisp-conference.org/)
> Lisp has no heavyweight industrial champion. Heck, even Python doesn't.
How many languages do? Java has Sun, .Net has MS. What else?
Like C, Common Lisp has many vendors - unlike C, none of CL's vendors
are hardware-vendors.
Why are you looking for a "heavyweight" champion? Longevity? Clout?
And just how much clout do you think that any-company-that-is-not-Microsoft
has?
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> "Brandon J. Van Every" <·····························@yahoo.com>
> writes:
>
> Be reached. Come to the ILC this year and see how "unpopular" Lisp
> really is (http://www.international-lisp-conference.org/)
I will peruse the site.
>> Lisp has no heavyweight industrial champion. Heck, even Python
>> doesn't.
>
> How many languages do? Java has Sun, .Net has MS. What else?
Java also has IBM. C++ had / has several industrial champions including,
oddly enough, Microsoft. I suppose that makes C++, Java, and C# "The Big
Three." Microsoft also previously championed Visual Basic before it cooked
up C#. I don't think anyone really champions C, but it is ubiquitous,
because it was industrially championed in a previous era.
> Why are you looking for a "heavyweight" champion?
I did not say I was. My original thread started with, "This begs a
question: who's marketing Lisp now ? Is Lisp unpopular for the very simple
reason that nobody actively markets it?" The lack of an industrial champion
is an adjunct thought.
> Longevity? Clout?
> And just how much clout do you think that
> any-company-that-is-not-Microsoft has?
Well, Sun, IBM, and HP certainly have some.
I think Python has far more clout than Lisp. But last I checked 2 years
ago, Python's market share was tiny, like maybe 2%. I don't know what it is
today. Guessing not much more.
Several of my colleagues believe that the popularity of so-called "scripting
languages" is due to the fact that they get used on unimportant, throwaway
projects. Heck, I even have a friend who does Python coding for his own
tools at Microsoft! If the code doesn't have to be shipped, or widely
shared, or maintained, then management doesn't greatly care what gets used.
So there's a low risk vector for trying out a scripting language. Now, why
would Python beat Lisp in such a scenario? Because Python is far easier to
pick up, frankly. Lisp favors the power programmer, but power programming
projects require a lot more design and development risk. Consequently,
managerial resistance is much greater. Meanwhile, Lisp has no advantages
over Python or Perl for something "dumb." And so it seems, the unchampioned
"scripting" languages are more popular than Lisp precisely because they're
more dumb.
So, I guess most of the industrial heavyweights don't think Lisp is worth
anything, and most of the "scripters" don't think Lisp is worth anything. I
guess that means Lisp ends up being a vertical market?
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
Brandon's Law (after Godwin's Law):
"As a Usenet discussion grows longer, the probability of
a person being called a troll approaches one RAPIDLY."
Brandon J. Van Every wrote:
> Java also has IBM. C++ had / has several industrial champions including,
> oddly enough, Microsoft. I suppose that makes C++, Java, and C# "The Big
> Three." Microsoft also previously championed Visual Basic before it cooked
> up C#. I don't think anyone really champions C, but it is ubiquitous,
> because it was industrially championed in a previous era.
I think C is THE champion (and standard language for FFIs; not C++),
because noone owns it. It's like TCP/IP: in came up with Unix, sort of,
and now everyone has their implementation of it, and there are good ones
under the GPL and BSDL too.
> I did not say I was. My original thread started with, "This begs a
> question: who's marketing Lisp now ? Is Lisp unpopular for the very simple
> reason that nobody actively markets it?" The lack of an industrial champion
> is an adjunct thought.
I think Franz and Xanalys (Lispworks) are marketing it somewhat. I
don't know who their customers mainly are; it's certainly not the
Java-using public; as you can see, most of them hate lisp enough to not
ever (yes, that's an R) consider it.
> I think Python has far more clout than Lisp. But last I checked 2 years
> ago, Python's market share was tiny, like maybe 2%. I don't know what it is
> today. Guessing not much more.
Just more people are picking it up because it's similar to what they
know (C, VB or Java) and reasonably comfy. And Lisp has those weeeeeird
()s, (OMG (they are) ((EVERYWHERE!!)))
> Several of my colleagues believe that the popularity of so-called "scripting
> languages" is due to the fact that they get used on unimportant, throwaway
you got a point there!
> projects. Heck, I even have a friend who does Python coding for his own
> tools at Microsoft! If the code doesn't have to be shipped, or widely
> shared, or maintained, then management doesn't greatly care what gets used.
> So there's a low risk vector for trying out a scripting language. Now, why
> would Python beat Lisp in such a scenario? Because Python is far easier to
> pick up, frankly. Lisp favors the power programmer, but power programming
> projects require a lot more design and development risk. Consequently,
Well, Python has more Unix-bindings, obviously. Lisp has always tried
to be independent of any individual OS, that's why it ran better on,
say, the classic Mac, or Windows, than I think Python does.
How about something like scsh (Scheme Shell) for CL?
> managerial resistance is much greater. Meanwhile, Lisp has no advantages
> over Python or Perl for something "dumb." And so it seems, the unchampioned
> "scripting" languages are more popular than Lisp precisely because they're
> more dumb.
No, because they have scripting functions, that is, the Unix standard
functions. Lisp is more of a powerful (and portable) application framework.
> So, I guess most of the industrial heavyweights don't think Lisp is worth
> anything, and most of the "scripters" don't think Lisp is worth anything. I
> guess that means Lisp ends up being a vertical market?
What do you mean by that?
Ulrich Hobelmann wrote:
>
>> So, I guess most of the industrial heavyweights don't think Lisp is
>> worth anything, and most of the "scripters" don't think Lisp is
>> worth anything. I guess that means Lisp ends up being a vertical
>> market?
>
> What do you mean by that?
"Vertical market" means all applications development is custom. No
off-the-shelf components are used.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
crappy software with total shit for tools and process."
- Ed McKenzie
> And so it seems, the unchampioned
> "scripting" languages are more popular than Lisp precisely because they're
> more dumb.
>
I don't think so. The problem of CL is, that the interface to the rest of
the world is just horrible ("pathname") and incomplete. The advantage of
"scripting languages" is, that there is just one implementation to choose from,
and they are open-source, so it easier to interface to them.
That's at least my theory.
For the same reason the only Lisp that I currently like is Bigloo.
-klaus.
klaus wrote:
>Brandon wrote:
>>
>> And so it seems, the unchampioned
>> "scripting" languages are more popular than Lisp precisely because
>> they're more dumb.
>>
> I don't think so. The problem of CL is, that the interface to the
> rest of
> the world is just horrible ("pathname") and incomplete. The advantage
> of "scripting languages" is, that there is just one implementation to
> choose from, and they are open-source, so it easier to interface to
> them.
> That's at least my theory.
>
> For the same reason the only Lisp that I currently like is Bigloo.
Interesting endorsement. Truthfully Bigloo Scheme is my current guinea pig.
But I wouldn't notice ease of interfacing to libraries offhand, as the
Bigloo archive has few offerings. That's why I've been checking around here
for alternatives.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
crappy software with total shit for tools and process."
- Ed McKenzie
klaus wrote:
>>And so it seems, the unchampioned
>>"scripting" languages are more popular than Lisp precisely because they're
>>more dumb.
>
> I don't think so. The problem of CL is, that the interface to the rest of
> the world is just horrible ("pathname") and incomplete.
I have started to like pathnames. Macintosh Common Lisp still requires
the use of "classic" style filenames [1], which means you have to say
"Macintosh HD:Users:costanza:..." instead of "/Users/costanza/...".
Pathnames allow me to forget about such platform dependencies.
Furthermore, the fact that pathnames are lists of strings that name
folders, instead of a single string that separates folders by slashes or
colons makes some things easier to express.
Pascal
[1] ...which is admittedly a wart in MCL that they should remove.
Pascal Costanza <··@p-cos.net> writes:
> klaus wrote:
>
>>>And so it seems, the unchampioned
>>>"scripting" languages are more popular than Lisp precisely because they're
>>>more dumb.
>> I don't think so. The problem of CL is, that the interface to the
>> rest of
>> the world is just horrible ("pathname") and incomplete.
>
> I have started to like pathnames.
Likewise. You do want something like CL-FAD[1] to smooth over some of
the implementation differences, but once you've got that, for actually
manipulating file names (e.g. make a filename that's just like this
one but with this extension and relative to that directory) pathnames
are quite nice. Much better than string munging.
-Peter
[1] <http://www.weitz.de/cl-fad/> Edi Weitz's library based on the
code I wrote for
<http://www.gigamonkeys.com/book/practical-a-portable-pathname-library.html>
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Pascal Costanza <··@p-cos.net> writes:
> Furthermore, the fact that pathnames are lists of strings that name
> folders, instead of a single string that separates folders by slashes
> or colons makes some things easier to express.
I second that. I think it's great to do list processing rather than
strchring for /,\ or : in strings and munching these.
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Brandon J. Van Every wrote:
> This begs a question: who's marketing Lisp *now* ? Is Lisp
> unpopular for the very simple reason that nobody actively markets
> it? Granted I haven't read computer magazines in a long time, but
> I've never seen a full page ad for a Lisp anywhere. I've never
> seen a vendor booth at a conference or trade show. Testimonials
> in the game industry exist (Naughty Dog, Square) but are rare, and
> nobody seems interested in reproducing their results. If
> there is actually any Lisp marketing going on, it isn't reaching me.
>
> Lisp has no heavyweight industrial champion. Heck, even Python
> doesn't.
This discussion is so 1999. ;)
Once you look past absolute numbers, and look instead at rates of
growth, you'll likely realize that there are extremely effective people
who help achieve these goals you seem to care about. Because you've
shifted the question from
"Why isn't Lisp the main tool for this generation of codemonkeys?"
to:
"What historically has been most effective for reducing the
reality-distortion surrounding things like Lisp?"
I think it's simple -- day-to-day stuff like creating programs,
explaining things, and organizing meetings. No surprise there.
And there are ineffective things, like grand centralized strategizing.
Little surprise there either.
We can have a discussion on marketing, but is that really your goal?
Marketing isn't an end in itself.
Tayssir John Gabbour wrote:
> Brandon J. Van Every wrote:
>> This begs a question: who's marketing Lisp *now* ? Is Lisp
>> unpopular for the very simple reason that nobody actively markets
>> it? Granted I haven't read computer magazines in a long time, but
>> I've never seen a full page ad for a Lisp anywhere. I've never
>> seen a vendor booth at a conference or trade show. Testimonials
>> in the game industry exist (Naughty Dog, Square) but are rare, and
>> nobody seems interested in reproducing their results. If
>> there is actually any Lisp marketing going on, it isn't reaching me.
>>
>> Lisp has no heavyweight industrial champion. Heck, even Python
>> doesn't.
>
> Once you look past absolute numbers, and look instead at rates of
> growth,
Do you have URLs for such numbers?
> We can have a discussion on marketing, but is that really your goal?
> Marketing isn't an end in itself.
I find techies who don't like to discuss marketing very tiring, and I've
learned to avoid such people. So please, don't discuss anything you don't
want to.
The goal is simple: show me where the Lisp jobs are, so I can stop investing
ridiculous amounts of time learning about Higher Level Languages that don't
do a damn thing to keep a roof over my head.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
On Usenet, if you're not an open source hippie who
likes to download and play with programming toys
all day long, there's something wrong with you.
Brandon J. Van Every wrote:
> Tayssir John Gabbour wrote:
> > Once you look past absolute numbers, and look instead at rates of
> > growth,
>
> Do you have URLs for such numbers?
Yes. I've even mentioned a few on various forums.
> > We can have a discussion on marketing, but is that really your
> > goal? Marketing isn't an end in itself.
>
> I find techies who don't like to discuss marketing very tiring, and
> I've learned to avoid such people. So please, don't discuss
> anything you don't want to.
The problem is you don't seem to know much about marketing. Do you know
the PR industry's history, and the roles in which it's effective?
More often than not, "talking about marketing" is the lazy person's
excuse to do nothing but talk. I should know, as I am a lazy person.
> The goal is simple: show me where the Lisp jobs are, so I can stop
> investing ridiculous amounts of time learning about Higher Level
> Languages that don't do a damn thing to keep a roof over my head.
You were given the answer by Duane. But first determine whether your
"investments" are actually capable of paying off. You usually expect a
payoff, otherwise it's better to budget as consumption rather than
investment.
Tayssir John Gabbour wrote:
> Brandon J. Van Every wrote:
>> Tayssir John Gabbour wrote:
>>>
>>> Once you look past absolute numbers, and look instead at rates of
>>> growth,
>>
>> Do you have URLs for such numbers?
>
> Yes. I've even mentioned a few on various forums.
Would you care to present these URLs here again?
>> The goal is simple: show me where the Lisp jobs are, so I can stop
>> investing ridiculous amounts of time learning about Higher Level
>> Languages that don't do a damn thing to keep a roof over my head.
>
> You were given the answer by Duane.
I was? I'm reading the Google archive... I see nothing in the past week by
Duane Rettig that addresses any post I've made, let alone the specific
subject of Lisp jobs. Did Duane just post something, and my news server and
Google are both slow?
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
Brandon J. Van Every wrote:
> Did Duane just post something, and my
> news server and Google are both slow?
It appears that was the case.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"The pioneer is the one with the arrows in his back."
- anonymous entrepreneur
"Brandon J. Van Every" <·····························@yahoo.com> writes:
> This begs a question: who's marketing Lisp *now* ? Is Lisp unpopular for
If by marketing you mean magazine ads and booths at trade shows, I'm
not sure the people who actually write the code, i.e. the hackers, are
going to be impressed much. And those who write the code are among
the ones, if not the only ones, who can make the difference.
So, I personally think it's better to concentrate on something
different: it may be as simple as writing the Lisp tools, libraries
and documentation the hackers need (the scratch an itch thing). There
is no need for big ads on glossy paper magazines. If the hackers are
interested, they will find the code anyway.
Having followed the Lisp world for the past 15 years or so, I see some
subjective, anecdotal evidence that the hackers are indeed coming.
> the very simple reason that nobody actively markets it? Granted I haven't
> read computer magazines in a long time, but I've never seen a full page ad
> for a Lisp anywhere. I've never seen a vendor booth at a conference or
> trade show. Testimonials in the game industry exist (Naughty Dog, Square)
A few years ago (3-4, if I recall correctly) Franz had ads in DDJ and
a booth at OOPSLA.
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Paolo Amoroso wrote:
> "Brandon J. Van Every" <·····························@yahoo.com>
> writes:
>
>> This begs a question: who's marketing Lisp *now* ? Is Lisp
>> unpopular for
>
> If by marketing you mean magazine ads and booths at trade shows, I'm
> not sure the people who actually write the code, i.e. the hackers, are
> going to be impressed much. And those who write the code are among
> the ones, if not the only ones, who can make the difference.
Well, in Python circles our strategy was to go after the suits. The people
with authority to hire, fire, and specify projects, who may not be as sharp
about tech as the hardcore techies. We identified 3 possible targets -
suits, techies, and educators - and were trying to devise a suit-friendly
campaign when Guido and the PSF Dilberted the whole thing. I conclude that
a language has to gestate a very long time, growing by "technical diffusion"
until enough non-technical people smell enough $$$$$$$ that they mount
proper marketing campaigns. Getting beyond the control of a BDFL helps too.
> So, I personally think it's better to concentrate on something
> different: it may be as simple as writing the Lisp tools, libraries
> and documentation the hackers need (the scratch an itch thing). There
> is no need for big ads on glossy paper magazines. If the hackers are
> interested, they will find the code anyway.
Hackers always think this. They blithely ignore the power that companies
like Microsoft exert upon the world through marketing. Everyone in the
Seattle Metro Area knows that 2/3 of a technology's popularity is marketing,
but hackers never care.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
Wade Humeniuk wrote:
> Mike Ajemian wrote:
>
>>
>> Lambda - the language formerly known as Lisp
>>
>
> Actually my favourite alias for Lisp is ...
>
> Boomerang
>
> Forget Lambda.
>
http://beinginharmony.com/boomerangs.html
Wade
On 2005-03-12 21:56:50 -0500, Kent M Pitman <······@nhplace.com> said:
> Don Geddis <···@geddis.org> writes:
>
>> "Mike Ajemian" <············@verizon.net> wrote on Fri, 11 Mar 2005:
>>> [...] Few people are willing to look beyond the name and realize
>>> any benefit from the language. So, instead of saying they hate the
>>> name to our face (it is "our baby" after all), they say things
>>> like, "I hate the parenthesis."
>>
>> You've got to be kidding. You denigrate everyone else's explanation for
>> Lisp's lack of popular success, and then _this_ is the best you can come up
>> with? That Lisp failed because the name is bad marketing?
>>
>> When you're rethinking your silly theory, consider:
>> 1. Lisp was very popular in the early 80's, when it had the very same name.
>> 2. Scheme and Dylan are two very close languages in the Lisp family
>> (the latter even took out the parentheses), yet they found no more
>> popular success than mainstream Lisp.
>>
>> Try again. Your theory on Lisp's popularity is obviously wrong. At least
>> the theories of other people were open to debate, not laughable like yours.
>
> Indeed.
>
> Superficial arguments like those Mike advances are more likely to be
> advanced to the totally unaware as a way of telling them "it's ok to
> be dismissive".
Where did this conversation go from a, "HOLY COW, Lisp is GREAT! Just
lookit what you can do,
WOOHOO!"-Southern-Baptist-Revival-Tent-Hot-diggity! testimonial to
people carping on him about his ideas on how the hell we ended up here?
I would think Mike would be refueled by the excitement such a
testimonial and AHA! moment would engender here. A very surprising
reaction, to say the least, even *if* his theories about Lisp's
popularity are wrong. The energy he gained from 6 weeks immersion
should be a bouy to the community.
Zac
"Mike Ajemian" <············@verizon.net> wrote in message
··························@trndny01...
> I still think that AI winter stuff is a crock, though.
I'm sorry. Look at the level of funding DARPA had for AI projects prior to
1988, vs. 1988-2000. Now it's picking up again (Brachman, an AI person, is
director of IPTO), but for a long time it was very hard to get research
money if you were in AI. That meant universities and research labs had to
find something else to do (or some other thing to name what they were
doing). It also meant using tools associated with AI (like Lisp) had to be
under the covers, lest the sponsor think you might be doing something they
had already written off for dead.
A large chunk of AI research was underwritten by DARPA (or ARPA as it is
occasionally rechristianed)... but it mirrors what was going on in the other
agencies as well.
> A large chunk of AI research was underwritten by DARPA (or ARPA as
> it is occasionally rechristianed)... but it mirrors what was going
> on in the other agencies as well.
I seem to remember hearing that a Lisp application (scheduling? sortie
planning? something like that) that was used during the first Gulf War
saved the military as much money as was spent on all AI research to
that date.
Does anyone know about this, or is it a figment of my imagination?
--
Fred Gilham ······@csl.sri.com
In order to be "presidential material" in the two big parties, you
must meet two standards. First, you must be charismatic, messianic,
exciting, with a message that will electrify the electorate. Second,
you must be absolutely conventional, never questioning the premises of
the welfare state. -- Joseph Sobran
Fred Gilham wrote:
> > A large chunk of AI research was underwritten by DARPA (or ARPA
> > as it is occasionally rechristianed)... but it mirrors what was
> > going on in the other agencies as well.
>
> I seem to remember hearing that a Lisp application (scheduling?
> sortie planning? something like that) that was used during the
> first Gulf War saved the military as much money as was spent on
> all AI research to that date.
>
> Does anyone know about this, or is it a figment of my imagination?
It's likely Ascent's DART, which apparently is now called AMP or
something.
Its fairly interesting history is discussed here:
http://www.sts.tu-harburg.de/~r.f.moeller/symbolics-info/ai-business.pdf
Mixed message from Ascent employee:
http://people.csail.mit.edu/people/gregs/ll1-discuss-archive-html/msg02565.html
"DARPA reported that an AI-based logistics planning tool, DART, pressed
into service for operations Desert Shield and Desert Storm, completely
repaid its three decades of investment in AI research."
http://www.cs.washington.edu/homes/lazowska/cra/ai.html
The effect of Lisp military systems on European leaders:
http://www.jwz.org/images/bushzipperpic1fr.jpg
> I've slogged away in the bowels of major
> software houses, never heard a peep about Lisp. I didn't just crawl out from
> under a rock. All these Lisp programs have been available for eons. Why is
> this language adopted by so few?
Well this is really easy to understand.
Just ask yourself: "how many middle managers with no or close to no
software building experience or knowledge but plenty of company
political ability and experience and plenty of lust for power and large
expensive company cars/jets can a software project support?"
Using M$ products -> a very big number of purely political middle
managers can eb supported
Using Cobol/CICS/MVS related products -> a very big number of purely
political middle managers can be supported
Using J2EE related products -> a fairly large number of purely political
middle managers
Using Java or C++ -> a smallish number and at least some of them have to
have some knowledge of creating software
With perl, python and ruby -> a small number and at least some of them
have to have some knowledge of creating software
With Lisp -> zero
Kristian
Kristian Elof S�rensen wrote:
>
>> I've slogged away in the bowels of major
>> software houses, never heard a peep about Lisp. I didn't just crawl
>> out from
>> under a rock. All these Lisp programs have been available for eons.
>> Why is
>> this language adopted by so few?
>
>
> Well this is really easy to understand.
>
> Just ask yourself: "how many middle managers with no or close to no
> software building experience or knowledge but plenty of company
> political ability and experience and plenty of lust for power and large
> expensive company cars/jets can a software project support?"
>
> Using M$ products -> a very big number of purely political middle
> managers can eb supported
>
> Using Cobol/CICS/MVS related products -> a very big number of purely
> political middle managers can be supported
>
> Using J2EE related products -> a fairly large number of purely political
> middle managers
>
> Using Java or C++ -> a smallish number and at least some of them have to
> have some knowledge of creating software
>
> With perl, python and ruby -> a small number and at least some of them
> have to have some knowledge of creating software
>
> With Lisp -> zero
>
>
> Kristian
Now in any given company, who of the following two do you think holds
the most power and influence with upper management, the board of
directors, the important customers, the department heads etc.
1) The hacker consultant who spends two moths on-site writing a piece of
software that then gets put into production and works flawlessly for
years to come.
2) The politically inclined manager who spends three years on-site
during a manpower intensive project, attends a meeting a week with all
the important upper-medium level management in the company and gives
montly presentations and advice to upper management, who during the
three years manages a dozen crises in clear view of the management, in
ways that keeps the management peoples careers safe.
"Kristian Elof S�rensen" <····@image.dk> wrote in message
····························@dread11.news.tele.dk...
> Kristian Elof S�rensen wrote:
> >
> >> I've slogged away in the bowels of major
> >> software houses, never heard a peep about Lisp. I didn't just crawl
> >> out from
> >> under a rock. All these Lisp programs have been available for eons.
> >> Why is
> >> this language adopted by so few?
> >
> >
> > Well this is really easy to understand.
> >
> > Just ask yourself: "how many middle managers with no or close to no
> > software building experience or knowledge but plenty of company
> > political ability and experience and plenty of lust for power and large
> > expensive company cars/jets can a software project support?"
> >
> > Using M$ products -> a very big number of purely political middle
> > managers can eb supported
> >
> > Using Cobol/CICS/MVS related products -> a very big number of purely
> > political middle managers can be supported
> >
> > Using J2EE related products -> a fairly large number of purely political
> > middle managers
> >
> > Using Java or C++ -> a smallish number and at least some of them have to
> > have some knowledge of creating software
> >
> > With perl, python and ruby -> a small number and at least some of them
> > have to have some knowledge of creating software
> >
> > With Lisp -> zero
> >
> >
> > Kristian
>
>
> Now in any given company, who of the following two do you think holds
> the most power and influence with upper management, the board of
> directors, the important customers, the department heads etc.
>
> 1) The hacker consultant who spends two moths on-site writing a piece of
> software that then gets put into production and works flawlessly for
> years to come.
>
> 2) The politically inclined manager who spends three years on-site
> during a manpower intensive project, attends a meeting a week with all
> the important upper-medium level management in the company and gives
> montly presentations and advice to upper management, who during the
> three years manages a dozen crises in clear view of the management, in
> ways that keeps the management peoples careers safe.
>
I understand your position, but all of my superiors have been highly
educated software engineers knowledgable in a diverse range of programming
languages. Many have held advanced CS degrees. Further, many have sacrificed
enormously (along with the rest of us rowing in the bowels) at great
personal cost (divorce, missed childbirths, family functions, life in
general). I've worked at companies founded and run by software engineers. In
fact, I've heard comments from many about their favorite languages being
scheme or lisp (well before I started using Lisp). This isn't about greed
because if it was, people would look for every advantage possible to kick
the snot out of the competition and take their money. This isn't about
safety, because if it was, people would look for every advantage to kick the
snot out of the competition to drive them out of business. You're suggesting
that George Steinbrenner will only hire mediocre people to ensure success in
his organization. Sorry, that just doesn't hold water.
There's a brain-freeze in our industry whereby people are locking themselves
into projects and plans using tools that they *believe* will provide them
the leverage they need to succeed in the project (where success is measured
solely by completion of the task at hand) all the while being unable or
unwilling to actually lay things out and measure to ensure their beliefs are
founded in reality. Putting the science into computer science. You might
think I'm hardcore, but I actually worked at an analytical lab doing
science. We're beyond total slackers, we as an industry are like heroin
addict's, psychotics or John Belushi in "Blues Brothers", "I ran out of gas!
I had a flat tire! I didn't have enough money for cab fare! My tux didn't
come back from the cleaners! An old friend came in from out of town! Someone
stole my car! There was an earthquake! A terrible Flood! Locusts! IT WASN'T
MY FAULT, I SWEAR TO GOD!"
Further, as has been stated on this board a number of times, there's a need
to be able to replace and/or add bodies to projects. Writing code in <safe
language> ensures there's a pool of employable people available to draw
from. A self-fulfilling prophecy. My point is that, according to a statistic
I read recently, 90% of software engineers are college educated (I'm in the
minority). This means that they are trainable. Allegedly. Supposedly. It's
supposed to also mean they're smart. Which means that company X can hire
programmer Y and teach them language Z. Truth is, everybody wants to make
safe decisions devoid of risk. Company X locks into language Z to be safe.
Programmer Y locks into language Z to make themselves available to companies
using it. All without measuring productivity and performance. Or proving
that their decision is actually safe. It's just a short-term view that has
horrible long-term effects on the project, the people and the future of our
industry by limiting growth and opportunity for all participants.
No other industry I've taken an interest in is so idiotic and this is *my*
industry. I tell people what I do and people who use software invariably ask
things like, "Why can't you guys get projects done on time?", "How can you
guys charge so much for such buggy products?" "Don't you guys know anything
about security?" People are pissed that their credit cards are being stolen,
their computers getting hacked, they lose important data from bugs. And we
lock ourselves into using tools that are used to pull C++ programmers
halfway to Lisp. Great, just what I want, to get pulled halfway back to C++.
I can watch pro baseball and know about a player: batting avg, speed to
first, # of stolen bases, and a myriad of other stats. The players accept
that they're being measured and work to improve. Because improvement means
better pay, better opportunity, better career. Nothing like that exists in
software. We grind people down to nothing to make up for CRAPPY TOOLS! I
talk to friends in construction and they talk about training new employees
to use tools they hadn't ever used. They learn on the job or the company rep
sends a trainer out. These concepts are foreign to our industry. We ignore
fundamental analysis of the most basic aspects of our work - the toolset.
Lisp really is different and yes, I am really pissed off :)
This problem is out-of-control enough to make a guy stand up and say:
The Emperor has no clothes.
Lisp is the new wardrobe. Not because it's a better language, but because
it's a programmable programming language.
Mike
"Mike Ajemian" <············@verizon.net> writes:
> No other industry I've taken an interest in is so idiotic and this is *my*
> industry. I tell people what I do and people who use software invariably ask
> things like, "Why can't you guys get projects done on time?", "How can you
> guys charge so much for such buggy products?" "Don't you guys know anything
> about security?" People are pissed that their credit cards are being stolen,
> their computers getting hacked, they lose important data from bugs. And we
> lock ourselves into using tools that are used to pull C++ programmers
> halfway to Lisp. Great, just what I want, to get pulled halfway back to C++.
You need to read _The Mythical Man Month_. In short, people (smart
people, even) have been asking these same questions about what makes
software so different that it resists all effort to make it
predictable. The short answer is that it's a hard problem.
> I can watch pro baseball and know about a player: batting avg, speed to
> first, # of stolen bases, and a myriad of other stats. The players accept
> that they're being measured and work to improve. Because improvement means
> better pay, better opportunity, better career. Nothing like that exists in
> software. We grind people down to nothing to make up for CRAPPY TOOLS! I
> talk to friends in construction and they talk about training new employees
> to use tools they hadn't ever used. They learn on the job or the company rep
> sends a trainer out. These concepts are foreign to our industry. We ignore
> fundamental analysis of the most basic aspects of our work - the toolset.
> Lisp really is different and yes, I am really pissed off :)
This is frankly an organizational/culture problem more than a language
problem. I can't explain why so many software companies seem to have
that disease, however.
> This problem is out-of-control enough to make a guy stand up and say:
>
> The Emperor has no clothes.
>
> Lisp is the new wardrobe. Not because it's a better language, but because
> it's a programmable programming language.
Exactly.
--
Dave Roberts
dave -remove- AT findinglisp DoT com
http://www.findinglisp.com/
> "Mike Ajemian" <············@verizon.net> writes:
> > I can watch pro baseball and know about a player: batting avg,
> > speed to first, # of stolen bases, and a myriad of other stats.
> > The players accept that they're being measured and work to
> > improve. Because improvement means better pay, better opportunity,
> > better career. Nothing like that exists in software. We grind
> > people down to nothing to make up for CRAPPY TOOLS! I talk to
> > friends in construction and they talk about training new
> > employees to use tools they hadn't ever used. They learn on the
> > job or the company rep sends a trainer out. These concepts are
> > foreign to our industry. We ignore fundamental analysis of the
> > most basic aspects of our work - the toolset. Lisp really is
> > different and yes, I am really pissed off :)
This baseball reference is very interesting. Observers from Ralph Nader
to Noam Chomsky frequently point out how much intelligence is lavished
on sports:
"It's striking when you listen to the ones about sports. They have
these groups of sports reporters, or some kind of experts on a panel,
and people call in and have discussions with them. First of all, the
audience obviously is devoting an enormous amount of time to it all.
But the more striking fact is, the callers have a tremendous amount of
expertise, they have detailed knowledge of all kinds of things, they
carry on these extremely complex discussions. And strikingly, they're
not at all in awe of the experts - which is a little unusual. See, in
most parts of the society, you're encouraged to defer to experts: we
all do it more than we should. But in this area, people don't seem to
do it - they're quite happy to have an argument with the coach of the
Boston Celtics, and tell him what he should have done, and enter into
big debates with him and so on. So the fact is that in this domain,
people somehow feel quite confident, and they know a lot - there's
obviously a great deal of intelligence going into it."
Of course, we are frequently told that Ralph and Noam froth at the
mouth and see conspiracies in shadows, but let's take that last quote
at face value for the moment, regardless of our political affiliations.
Dave Roberts wrote:
> This is frankly an organizational/culture problem more than a
> language problem. I can't explain why so many software companies
> seem to have that disease, however.
Martin Luther King once explained to a union:
"The political strength you are going to need to prevent automation
from becoming a Moloch, consuming jobs and contract gains, can be
multiplied if you tap the vast reservoir of Negro political power."
http://www.nathanielturner.com/martinlutherking.htm
Historically, we programmers have formed "planning deparments"
alongside management, creating golems which operate with minimal worker
intervention. This requires us to be ideological, or at least
unconcerned technocrats. Who don't bat an eyelid when we claim
corporations save money by making employees redundant with our tech.
(As at least one Microsoft developer/salesman I know claims.)
Fortunately, tech doesn't only lend itself to command & control uses.
Technologies may be used to remove layers of management, as well. I
believe dynamic tools have something of this flavor. And I think if
we're to solve those AI nightmares we keep seeing in movies,
human-oriented technologies will be vital. Ones which lend themselves
to democratic use, where humans participate centrally, throughout its
operations.
"Tayssir John Gabbour" <···········@yahoo.com> wrote in message
····························@f14g2000cwb.googlegroups.com...
> Fortunately, tech doesn't only lend itself to command & control uses.
> Technologies may be used to remove layers of management, as well.
Minor nit in your screed: C&C is management. Manning reduction (i.e.
management) is a big thing and getting into the driver seat for automation.
Why? Because you remove a manager, you remove the worker bees that support
him too.
Think of a ship that used to have a complement of 500, having more missions,
a larger displacement, but getting the manning down to 130 or so. That's a
lot of automation, but it's also what's currently happening.
Of course manning reduction in the military is a good thing - it exposes
fewer warfighters to hazard.
>>>>> "gorbag" == gorbag <······@invalid.acct> writes:
[...]
gorbag> Of course manning reduction in the military is a good
gorbag> thing - it exposes fewer warfighters to hazard.
It also makes wars cheaper politically. I am not convinced that is
such a good thing.
cheers,
BM