From: William Paul Vrotney
Subject: Re: Why lisp failed in the marketplace
Date:
Message-ID: <vrotneyE5y8Iy.5KJ@netcom.com>
In article <·························@news.demon.co.uk>
············@wildcard.demon.co.uk (Cyber Surfer) writes:
>
> Special cases like this get used all the time, both for C++ _and_
> Lisp. Just count the number of AI apps that get used to support the
> pro-Lisp argument. To many people, this kind of argument will make C++
> look good (to the C++ people), not Lisp!
>
> It's one of those classic communication problems. Like the Douglas
> Adams joke about humans and dolphins, each sees themselves as superior
> for exactly the same reasons. Perhaps we need to change the language
> used in pro-Lisp arguments? We could start by _never_ refering to AI.
>
Great idea! But why stop there? Let's stop referring to the term "Lisp" in
this news group. In fact let's change then name of this newsgroup to
comp.lang.euphemism
Sorry, absolutely could not resist. :-)
--
William P. Vrotney - ·······@netcom.com
With a mighty <·················@netcom.com>,
·······@netcom.com wibbled into the void...
> Great idea! But why stop there? Let's stop referring to the term "Lisp" in
> this news group. In fact let's change then name of this newsgroup to
>
> comp.lang.euphemism
>
> Sorry, absolutely could not resist. :-)
<grin> Yeah, if we're not careful, we might wander into 1984
territory, and the find the Ministry of Truth rewritting history while
it's still, in theory, in living memory. We're told that history is
written by the "winning side", so if we find people who mistakenly
think that AI has nothing to with the real world, we shouldn't be
suprised. I'd prefer to _not_ stoop to their level, by also rewiting
history, reinventing the language by which we refer to programming
ideas, etc.
I just hope that we can afford to be less ruthless than the
opposition, because that appears to be the myth. If we stopped calling
it AI and instead used terms like "Business Knowledge Engineering",
we'd be playing the same game as the marketing droids. If that's what
it takes to keep Lisp alive, I might accept it, but that's not
certain, is it?
A more realistic approach might be to write a few Lisp tutorials that
have a more "down to earth", and sneak the AI ideas in without
announcing them as AI. Let the bibliography do that. That way, a few
"real programmers" might read these books and learn something about
Lisp for a change.
I've been using the ODBC functions for Windows recently, and while my
SQL knowledge is well and truely rusty, it's very easy to use once you
have a few examples to work from. When I have the time, I may try
using this stuff in Lisp. Unfortunately, what I know about writing
database apps can fit onto the back of a stamp, so I'm unlikely to
write a "ODBC for Lisp Programmers" book any time soon. However, I
know what kind of "advanced" things I'd do in the last few chapters!
Code generators, for examples. I know that sounds like pretty easy
stuff for Lisp people, but I doubt that many database folk would
consider writing anything resembling even a simple compiler.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
On Sat, 22 Feb 1997 11:03:02 -0000, ············@wildcard.demon.co.uk
(Cyber Surfer) wrote:
>I've been using the ODBC functions for Windows recently, and while my
>SQL knowledge is well and truely rusty, it's very easy to use once you
>have a few examples to work from. When I have the time, I may try
>using this stuff in Lisp. Unfortunately, what I know about writing
>database apps can fit onto the back of a stamp, so I'm unlikely to
>write a "ODBC for Lisp Programmers" book any time soon. However, I
>know what kind of "advanced" things I'd do in the last few chapters!
>Code generators, for examples. I know that sounds like pretty easy
>stuff for Lisp people, but I doubt that many database folk would
>consider writing anything resembling even a simple compiler.
That reminds me of something I'm planning to put into ARGOT: a
database management library based around Prolog-style relationship
inference rules. If we define a relationship with type assertions on
the variable fields, we can store it efficiently as a standard
database structure. Constant elements in an relationship - which is
represented as a list - specify the unique "name" of the relation; for
example, the relationship defined as (?a is in love with ?b) could
contain elements such as:
(Lorenz is in love with Kate)
which would be stored as (Lorenz Kate) - and since those had probably
been type-asserted as symbols, unless flexibility was needed, that
would be 32 bits or so each, for 64 bits per record. Not bad.
That can be queried, a query returning either #t or #f if the query
cotnains no variables, the result being the presence or absence of a
match in the database, or else a list of records binding those
variables (Records are a primitive ARGOT data type - lists with a
symbolic name at each node) to matching values.
There can also be inference rules, such as:
(?a and ?b are a happy couple) if (and (?a is in love with ?b) (?b is
in love with ?a))
This is all very nice, AI-ish, and easy to think about for the tired
business types who don't realise they're being introduced to predicate
calculus and the AI opportunities that follow...
ABW
--
"Simply drag your mother in law's cellphone number from the
Address Book to the Laser Satellite icon, and the Targeting
Wizard will locate her. Then follow the onscreen prompts for
gigawattage and dispersion pattern..."
(Windows for Early Warning and Defence User's manual P385)
Alaric B. Williams Internet : ······@abwillms.demon.co.uk
<A HREF="http://www.abwillms.demon.co.uk/">Hello :-)</A>