In article <············@wildcard.demon.co.uk>,
············@wildcard.demon.co.uk wrote:
> This is true, tho Java has managed to generate a great deal of
> interest _without_ an obvious killer app, while Lisp should've
> had several by now. If none of the symolic math packages are
> "killer apps", then what about HotMetal?
Killer apps for languages are not single programs, but an entire
categories of programs that were previously impossible to write. For
Java, applets are the killer app. Two years ago there was no way to put
live content on web pages. Now there is.
For the record, here is a list of the killer apps for the winners in the
language wars over the past 40 years:
1950s COBOL -- business programming in something more legible than assembler.
1960s FORTRAN -- numerical modeling.
1970s C -- UNIX (ability to port an OS to new hardware just as number of
platforms started exploding).
1980s C++ -- "object oriented", builds on knowledge of C gained in the 70s.
1990s Java -- Applets.
Note that each new language wasn't just better (or in some cases any
better at all) than the previous language. Rather, each language let you
do something you previously couldn't do at all.
Note also that the killer app was never "powerful and easy to use
programming language."
If you want a Lisp-like language to win in the next round of the language
wars, you need to find the next killer app, not the last one. Don't add
applet support to Lisp or Dylan and expect the world to beat a path to
your door. Do something nobody could do before, but can with your
language.
--
John Brewer Senior Software Engineer Spyglass, Inc.
Opinions expressed do not necessarily reflect those of my employer.
Heck, I'm old enough to remember the _first_ time Apple was "doomed".
In article <························@news.mcs.com>,
John Brewer <·······@spyglass.com> wrote:
>For the record, here is a list of the killer apps for the winners in the
>language wars over the past 40 years:
>
>1950s COBOL -- business programming in something more legible than assembler.
>1960s FORTRAN -- numerical modeling.
>1970s C -- UNIX (ability to port an OS to new hardware just as number of
>platforms started exploding).
>1980s C++ -- "object oriented", builds on knowledge of C gained in the 70s.
>1990s Java -- Applets.
I think it's more than a little premature to say that Java has been
the "killer app" winner of the "language wars" for the 1990s.
I suspect Visual BASIC is a much stronger claimant for the 1990s
title. A lot of companies are using VB to build graphical front-ends
for commercial bespoke applications, and it allowed thousands of people
who couldn't previously build graphical Windows applications to do so.
VB thus gave end users Windows interfaces to lots of previously hard to
use software. Tcl/Tk would be the UNIX equivalent.
Perl is another strong candidate, letting people do simple scripting,
text processing and reporting on data in a quick, easy multi-platform
way. The result has been a profusion of useful Perl 'applets' to
summarize information, check data, search for things, and so on.
>Note that each new language wasn't just better (or in some cases any
>better at all) than the previous language. Rather, each language let you
>do something you previously couldn't do at all.
I haven't seen any application built with Java that couldn't be built
using something else. By 'application', I mean a piece of software
which performs some useful task for an end user.
The thing Java can do which is unusual is run the same code on
multiple platforms, and download it from the web; but that's a
technical detail, not something end users really care about.
Most of the other items on your list succeeded not because they were
'killer apps' themselves, but because they were linked with 'killer
apps'. COBOL's killer app was business software; FORTRAN's was, as
you point out, numerical modelling applications; and yes, C's was UNIX
and microcomputer OSs in general.
The language itself can be awful if the 'killer app' is compelling;
ultimately, it really doesn't matter how bad the language is, much
as I hate to admit it. Perl is disgusting, but there were so many
useful (not just decorative) Perl scripts around, and so many things
Perl could do for me, I had to give in and learn it.
What was the 'killer app' for C++? I don't think it has one. Most
people seem eager to ditch it for something else, and users don't see
that applications built in C++ give them anything special over
applications built in C.
So what's the killer app for Java? What's the thing which will make
the people who don't care about implementation details get interested,
make them think "I must get Java so I can do this thing I can't do any
other way"? I've not seen anything yet which has made *me* feel that I
need Java. I downloaded the JDK and Java run time, tried a couple of
apps, found that they were ugly and grindingly slow, and haven't
touched it since.
And to make the thread relevant to the newsgroups it's posted to, what
might be the killer apps for Common LISP, Scheme and Dylan?
My guess for Scheme is that it might be able to ride the SGML/DSSSL
wave... Platform-independent content-based machine-processable
documents; single source documentation which can be delivered in
multiple formats, including intelligent hypertext -- those are new
things which a lot of people want.
mathew
--
····@pobox.com content available at http://www.pobox.com/%7Emeta/
Help prevent bias on the net; http://www.pobox.com/%7Emeta/rs/ot/ for info
"There's safety in numbers... Large prime numbers." -- John Gilmore
In article <··········@snotra.harlequin.co.uk>, ····@pobox.com (mathew) wrote:
> I suspect Visual BASIC is a much stronger claimant for the 1990s
> title. A lot of companies are using VB to build graphical front-ends
> for commercial bespoke applications, and it allowed thousands of people
> who couldn't previously build graphical Windows applications to do so.
Visual Basic is definitely a good pick for the language of the 90s. Being
a Mac person, I often overlook it. However, visual Java environments are
starting to crop up (see for example, Peter Coffee's opinion of a
pre-release version of Visual Cafe
<http://cafe.symantec.com/reviews/12coff.html>).
> The thing Java can do which is unusual is run the same code on
> multiple platforms, and download it from the web; but that's a
> technical detail, not something end users really care about.
I must respectfully disagree. When I say live content, I don't just mean
the "Tumbling Duke" animation. Think client/server, only you can jam the
client down a wire to a remote user, and keep a live connection open to
the server. This is going to be big in commerce, and in multi-player
games. And there was no good way to do this before Java.
> And to make the thread relevant to the newsgroups it's posted to, what
> might be the killer apps for Common LISP, Scheme and Dylan?
>
> My guess for Scheme is that it might be able to ride the SGML/DSSSL
> wave... Platform-independent content-based machine-processable
> documents; single source documentation which can be delivered in
> multiple formats, including intelligent hypertext -- those are new
> things which a lot of people want.
Maybe, but it's not clear to me that HTML hasn't already filled that
vacuum. Vacuums that everybody sees don't stay vacuums for long.
--
John Brewer Senior Software Engineer Spyglass, Inc.
Opinions expressed do not necessarily reflect those of my employer.
Heck, I'm old enough to remember the _first_ time Apple was "doomed".
In article <························@news.mcs.com>,
John Brewer <·······@spyglass.com> wrote:
>In article <··········@snotra.harlequin.co.uk>, ····@pobox.com (mathew) wrote:
>> The thing Java can do which is unusual is run the same code on
>> multiple platforms, and download it from the web; but that's a
>> technical detail, not something end users really care about.
>
>I must respectfully disagree. When I say live content, I don't just mean
>the "Tumbling Duke" animation. Think client/server, only you can jam the
>client down a wire to a remote user, and keep a live connection open to
>the server.
Sure, you can - but what's the benefit to the user?
> This is going to be big in commerce, and in multi-player
>games. And there was no good way to do this before Java.
Oh, come on. There are loads of multi-player games around already
which far surpass anything you can do in Java. Look at DOOM, Quake,
SimCity 2000, Bolo, Spaceward Ho!, and so on -- all played across the
Internet. Users don't care if they're downloading a single
platform-independent client, or a platform-dependent client. What
they care about is how good the game is; and I very much doubt anyone
will be playing JavaQuake in the near future.
Even in text-based Interactive Fiction, which Java *can* handle, the
existence of Java-based Z-code interpreters has had no impact - it
seems people still prefer to download a Z interpreter for their system,
instead; something which has the UI they're used to, and makes full use
of the system's capabilities.
>> My guess for Scheme is that it might be able to ride the SGML/DSSSL
>> wave... Platform-independent content-based machine-processable
>> documents; single source documentation which can be delivered in
>> multiple formats, including intelligent hypertext -- those are new
>> things which a lot of people want.
>
>Maybe, but it's not clear to me that HTML hasn't already filled that
>vacuum.
HTML does a restricted subset of what SGML can do. In particular,
HTML lacks a rich enough markup scheme to allow data to be marked up
according to what it is, rather than just what it looks like. There
are a few useful semantic tags like <ADDRESS>, but a lot of gaps:
there's no HTML tag for telephone numbers, to pick just one example.
mathew
--
····@pobox.com content available at http://www.pobox.com/%7Emeta/
Help prevent bias on the net; http://www.pobox.com/%7Emeta/rs/ot/ for info
"There's safety in numbers... Large prime numbers." -- John Gilmore
In article <··········@snotra.harlequin.co.uk>, ····@pobox.com (mathew) wrote:
> In article <························@news.mcs.com>,
> John Brewer <·······@spyglass.com> wrote:
>
> >I must respectfully disagree. When I say live content, I don't just mean
> >the "Tumbling Duke" animation. Think client/server, only you can jam the
> >client down a wire to a remote user, and keep a live connection open to
> >the server.
>
> Sure, you can - but what's the benefit to the user?
The benefit to the user is web pages that are orders of magnitude more
interactive. They don't have to know that it's because there's a Java
program running on the page. If you want a graphical database client, why
kludge one together with GIFs, CGIs and client pull? Why not just send a
real client down the pipe?
> Oh, come on. There are loads of multi-player games around already
> which far surpass anything you can do in Java. Look at DOOM, Quake,
> SimCity 2000, Bolo, Spaceward Ho!, and so on -- all played across the
> Internet. Users don't care if they're downloading a single
> platform-independent client, or a platform-dependent client. What
> they care about is how good the game is; and I very much doubt anyone
> will be playing JavaQuake in the near future.
What if there was a standard native 3d library for Java? Better yet, what
if it used something like QuickDraw 3D RAVE, so it could take advantage of
hardware accelleration. I haven't written 3D games in something like a
decade, but I seem to recall all the CPU time was taken up in 3D
transforms and polygon rendering. Code the game logic in Java, and now
you have one binary that can run on everything. Then you don't have that
one-year lag to port to all the other platforms. Could be very
compelling.
> Even in text-based Interactive Fiction, which Java *can* handle, the
> existence of Java-based Z-code interpreters has had no impact - it
> seems people still prefer to download a Z interpreter for their system,
> instead; something which has the UI they're used to, and makes full use
> of the system's capabilities.
I personally thought the Java Z interpreter was the neatest thing since
sliced bread. As we speak, Infocom is letting people download Zork I for
free off the web. Why all that mucking about with ".sea" and ".zip"
files? Why not just have a page at www.infocom.com that runs Zork I
inside your browser?
> HTML does a restricted subset of what SGML can do. In particular,
> HTML lacks a rich enough markup scheme to allow data to be marked up
> according to what it is, rather than just what it looks like. There
> are a few useful semantic tags like <ADDRESS>, but a lot of gaps:
> there's no HTML tag for telephone numbers, to pick just one example.
This can be remedied by patching HTML. Yes, it's a hack, but you can't
throw out a terabyte of installed base.
--
John Brewer Senior Software Engineer Spyglass, Inc.
Opinions expressed do not necessarily reflect those of my employer.
Heck, I'm old enough to remember the _first_ time Apple was "doomed".
From: Cyber Surfer
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <842955555snz@wildcard.demon.co.uk>
In article <························@news.mcs.com>
·······@spyglass.com "John Brewer" writes:
> If you want a Lisp-like language to win in the next round of the language
> wars, you need to find the next killer app, not the last one. Don't add
> applet support to Lisp or Dylan and expect the world to beat a path to
> your door. Do something nobody could do before, but can with your
> language.
It appears that Perl has already conquered the CGI department,
and Java has the applet territory (I know about ActiveX BTW).
What does that leave? Better OOP than C++, Java, and Smalltalk?
Possibly, but very few people know it - yet.
Lisp has other strengths, of course. The problem could be that
many of these strengths are not so easy for non-Lisp programmers
to understand and, more importantly, appreciate. The ability to
develop code rapidly is one that we can all recognise, but I find
it's not so easy getting the opportunity to exploit it. Most of
the code I'm asked to write specifies the _language_, and very
often the compiler, too. While it sometimes may be _possible_
to do it in Lisp, that's not what I'm asked to use.
Look at it this way. When a programmer is asked to write some
CGI code, it's more likely that they'll write it in Perl, simply
because it's more likely that the server that'll run the code
will have Perl installed on it. If more web servers had MzScheme
installed as standard, perhaps more programmers would write CGI
code using MzScheme.
As for browsers, Scheme could be compiled to code for the JVM,
so that's not as hard to do. How many books teach Java (VM)
programming using the Kawa compiler? It would be unfair to expect
any to be available so early, but how many do you expect to
appear during the next 5 years? Obviously we should write them
ourselves, and start writing them _now_. We've got a lot of
work to do to catch up with Java.
This is why I agree with you about languages that have established
themselves in certain problem domains, like Perl and CGI, Java
and running code in a web browser (_and_ without a web browser).
It's great being able to say "Me too!", but it'll do little to
change people's association of an app domain with a particular
language. Lisp is associated with AI, and most people think that
AI has nothing to do with their app domains.
Obviously we have to create a new app domain, do it in Lisp, and
make damn sure everybody knows about it. That means understanding
what everbody wants from an app (something popular, like a web
browser?), not just a select few (e.g. the taditional AI apps and
their users).
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
From: William Clodius
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <32406609.41C6@lanl.gov>
Minor correction to Brewer's post
1950s FORTRAN -- numerical modeling.
1960s COBOL -- business programming in something more legible than
assembler.
See the Language List
http://cuiwww.unige.ch/langlist
"FORTRAN I John Backus, IBM for the IBM 704. Design begun 1954, compiler
released April 1957."
"COBOL COmmon Business Oriented Language. 1960. CODASYL Committee, Apr
1960. Simple computations on large amounts of data. The most widely used
programming language today. The natural language style is intended to be
largely self-documenting. Introduced the record structure. "Initial
Specifications for a Common Business Oriented Language" DoD, US GPO, Apr
1960."
--
William B. Clodius Phone: (505)-665-9370
Los Alamos National Laboratory Email: ········@lanl.gov
Los Alamos, NM 87545
From: Guillermo (Bill) J. Rozas
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <GJR.96Sep19152851@hplgr2.hpl.hp.com>
| From: Andreas Bogk <·······@artcom.de>
| Date: 19 Sep 1996 00:57:40 +0200
|
| >>>>> "John" == John Brewer <·······@spyglass.com> writes:
|
| John> What if there was a standard native 3d library for Java?
| John> Better yet, what if it used something like QuickDraw 3D
| John> RAVE, so it could take advantage of hardware accelleration.
|
| Why is it that everyone is ffoles by Sun into thinking Java and Java
| bytecode are identical? There's a Scheme to JavaBC compiler. Why is it
| that no one can imagine an universal bytecode, that is equally
| suitable for all languages?
|
| Andreas
There is one. It is called x86 binary code.
Advantages:
1. It is dense (often denser than Java byte codes).
2. It can be interpreted very quickly -- no JIT or anything else needed. :-)
3. There are compilers from virtually all languages to it.
4. It is already supported by most general purpose computers in the
world, and the number and fraction keeps growing.
5. It has native interfaces to most OS and GUI libraries. :-)
Disadvantages:
No byte-code verifier.
Now, it's pretty clear to me that it is not inherently hard to
establish constraints for x86 code that allow a Java-like code
verifier to run, and to publish such constraints and get (some/many)
compiler writers to abide by them than it is for them to retarget
their compilers to Java byte codes.
I think Java and Java byte codes are a great thing. Too bad it was
not done with Scheme, CL, or Dylan. However, in their present form
Java byte codes are not really suitable as a target for many languages
and applications, and it will be a while before performance and
interoperability are at the level expected.
From: Cyber Surfer
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <843227273snz@wildcard.demon.co.uk>
In article <·················@hplgr2.hpl.hp.com>
···@hpl.hp.com "Guillermo (Bill" writes:
> I think Java and Java byte codes are a great thing. Too bad it was
> not done with Scheme, CL, or Dylan. However, in their present form
> Java byte codes are not really suitable as a target for many languages
> and applications, and it will be a while before performance and
> interoperability are at the level expected.
I thought it _was_ being done with Java? I don't know how
efficient is it, but I'm very glad the Kawa Scheme compiler
is there. Perhaps it'll grow into big system with a friendly
user interface, tools like an interface builder etc. I'm more
concerned that such a compiler should exist than whether or
not it can compete with the performance of MIT Scheme on any
particular platform.
MIT Scheme is wonderful, and I love the compiler, but it's
very far from the kind of Scheme I can easily use, mainly coz
MIT Scheme for Windows, the platform I'm using, doesn't have
a friendly user interface or an FFI yet. Nor can it produce
stand-alone apps. It doesn't have to.
On the other hand, perhaps Kawa can. I'm hoping to try it at
the weekend. Even if it doesn't do much at the moment, it could
easily become something much more impressive in the relatively
near future. MIT Scheme for Windows hasn't changed much in the
last 3 years.
My point here, unlike in other posts (see below), is not that
I'd like better Windows support, but that the JVM can give us
a better cross-platform Scheme, on _every_ platform that's it's
available for. Not just those platforms that support X Windows
or whatever.
This is what I've been waiting about 15 years for. It has
nothing to do with Lisp, but everything to do with writing
and using portable software, and on as many platforms as
possible. How else are you going to do it in Lisp? IMHO this
is it.
Ok, I _have_ said this all before. ;-) Perhaps I'll shut up now!
I've got some Java books to read...
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
From: Ozan Yigit
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <3241A295.41C67EA6@border.com>
John Brewer wrote:
...
> If you want a Lisp-like language to win in the next round of the language
> wars, you need to find the next killer app, not the last one. Don't add
> applet support to Lisp or Dylan and expect the world to beat a path to
> your door. Do something nobody could do before, but can with your
> language.
on this note, an essay in Gabriel's new book[1] titled "The End of
History and the Last Programming Language" may be of some interest: it
tries to figure out why many languages go through a stagnation period,
and how languages succeed. [he does not mention oodles of darpa money
as a key to success, alas. :]
oz
---
[1] Richard P. Gabriel
Patterns of Software: Tales from the Software Community
Oxford University Press, 1996
---
simplicity is only skin deep. | electric: ··@border.com
- peter roosen-runge | or [416] 368 0074 x 294
From: Rob Warnock
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <51u3co$h22@tokyo.engr.sgi.com>
John Brewer <·······@spyglass.com> wrote:
+---------------
| 1970s C -- UNIX (ability to port an OS to new hardware just as number of
| platforms started exploding).
+---------------
You're off by a decade, and have causality backwards. Until circa 1980
the *only* platforms Unix ran on (in any quantity) were DEC PDP-11s and
VAX-11/780. The number of platforms started exploding in 1981 *because* --
almost *ENTIRELY* because -- of the introduction of the AT&T Unix "Binary
Sub-License, Limited Number of Users", which for the first time made
(re)selling Unix affordable on small platforms.
At the same time, Unix was the *only* operating system for which you could
"buy" (license) the source outright *and* which was written in a fairly
portable language (the PCC compiler was the key to portability, not C syntax),
thus meaning that tons of small start-ups [such as one I worked for] could
save about a megabuck by "buying" Unix instead of writing an O/S.
A secondary driving force that caused the "explosion" to occur at first
on Mc68000-based platforms was the availability "for free" (well, you had
to show you'd already paid AT&T for a license) of a mostly-working 68k port
from Steve Ward's group at MIT, including a PCC for the 68k that cross-
compiled from a PDP-11 or VAX.
So... $25000 to AT&T for a V.32 license, a magtape and a plane ticket
[and a copy of your AT&T license] to visit MIT, another magtape [& copy
of your AT&T lic.] to get BSD 4.1a (or so), and you had (almost) everything
you needed to be a "Unix systems vendor" on a J-random 68K platform.
*That's* why the number of platforms exploded: A change in Unix licensing,
a portable compiler, and a handy reference port. Without them -- and especially
without the licensing change, the "explosion" wouldn't have happened... then.
[It would have happened sooner or later, certainly, when some other O/S was
available in source form with a portable compiler and reasonable licensing...]
-Rob
-----
Rob Warnock, 7U-550 ····@sgi.com
Silicon Graphics, Inc. http://reality.sgi.com/rpw3/
2011 N. Shoreline Blvd. Phone: 415-933-1673 FAX: 415-933-0979
Mountain View, CA 94043 PP-ASEL-IA