I recently chaired a committee tasked with evaluating programming
languages for our planning and scheduling systems. Most of what we
have now is Lisp.
Our report might be of interest to others. The arguments have not
received too much critical review. I would appreciate any comments.
The report is not structured for an external audience and includes
some peculiar content owing to the document's history within the
organization. At some point, I would like to rework the relevant
portions for a more general audience.
http://www.ess.stsci.edu/psdb/spike/spike-wg/psflang-report.pdf
--
John Michael Adams
Smalltalk is and has always been a much superior language to Java in spite
of Java's
popularity. Lisp is definitely a great choice and in todays day and age of
almost everything
getting 'webified', GUI's are probably not as important as a browser
interface. In that
scenario, the language begins to transcend the platform.
Just fyi, Smalltalk _does_ compile to bytecode and has app servers as well.
I am guessing
that most of today's Smalltalk commercial IDE's have the ability to generate
Java bytecode
and will probably have comparable performance.
Excellent GUI alternatives to Swing, like wxWindows were ignored. wxPython
is an
excellent GUI environment and really beats the heck out of Java anyday.
Also the fact that GUI clients usually are better when they use native
widgets. The others
just feel clunky and look out of place.
Why does every study have to include Java and C++? Are these alternatives
that you
are seriously considering. C++ is better than Java and Lisp is better than
C++. This
has been proven not once, but many times. Paul Graham says it best:
"The reward for your efforts will be an equivocal one: you will feel as
suffocated programming in C++ as an experienced C++ programmer would feel
programming in Basic. It's more encouraging, perhaps, if we think about
where this feeling comes from. Basic is suffocating to someone used to C++
because an experienced C++ programmer knows techniques that are impossible
to express in Basic. Likewise, learning Lisp will teach you more than just a
new language-it will teach you new and more powerful ways of thinking about
programs".
Did you folks even take half a chance of looking at Objective Caml. This is
a very good
language that has very good design as well as features. What client machines
do you have
at the organization? If they are Win based then any commercial Lisp GUI with
CLIM support
should also suffice. Some of them have interfaces to GTK+ as well.
"John M. Adams" <·······@stsci.edu> wrote in message ····················@an
arky.stsci.edu...
> I recently chaired a committee tasked with evaluating programming
> languages for our planning and scheduling systems. Most of what we
> have now is Lisp.
>
> Our report might be of interest to others. The arguments have not
> received too much critical review. I would appreciate any comments.
> The report is not structured for an external audience and includes
> some peculiar content owing to the document's history within the
> organization. At some point, I would like to rework the relevant
> portions for a more general audience.
>
> http://www.ess.stsci.edu/psdb/spike/spike-wg/psflang-report.pdf
>
> --
> John Michael Adams
"OCID" <······@purdue.edu> writes:
> Smalltalk is and has always been a much superior language to Java in
> spite of Java's popularity.
Agreed.
> Did you folks even take half a chance of looking at Objective
> Caml. This is a very good language that has very good design as well
> as features. What client machines do you have at the organization?
> If they are Win based then any commercial Lisp GUI with CLIM support
> should also suffice. Some of them have interfaces to GTK+ as well.
No. I don't doubt for a moment that there is something beautiful
about Objective Caml. But frankly, if it's (relatively) exotic and it
isn't Lisp, then I can't be bothered. Sorry! I've got enough to
worry about trying to keep up with Java and Python. I'm a real lover
of the study of languages, but I have to draw the line somewhere if I
am going to be useful.
--
John Michael Adams
John,
That report was a very interesting read and well compiled. We really
appreciate
you putting it out. The inclusion of other articles in it is nice as well.
Java is a popular language that is controlled by a proprietary organization
whose
future is questionable. Its very similar to MS and C# in terms of
technology. They
compete with each other .... but you already know that. Thats what makes me
uncomfortable to recommend Java to anyone.
Objective Caml is much closer to Lisp than Python or at least as much and is
a
very good language, perhaps better than Python in many respects, However, it
is not commercial and does not have support which might be an issue with
most
organizations. BSD has survived very succesfully over the years and been
used
succesfully by organizations without any vendor support. Clisp and CMUCL do
appear to be thriving Lisps.
Franz Allegro CL does have a lot of interfaces to Java from the language as
well
as to other languages. So I can see people using Lisp with Java or Lisp with
C++
as is done by the ITA Software app that powers Orbitz. Xanalys also has CLIM
support AFAIK.
However, I don't see a good reason to use Java as a front end. wxWindows GUI
libraries with C++ or even Python are much better than Swing and its fairly
stable
and uses native widgets. Commercial Lisp GUI's also appear to be quite
decent
and are cross-platform to an extent because of the inclusion of GTK+
bindings.
We would be very interested in knowing what you actually go for when making
the final decisions as well.
Thanks Again!
"John M. Adams" <·······@stsci.edu> wrote in message
····················@anarky.stsci.edu...
> "OCID" <······@purdue.edu> writes:
>
> > Smalltalk is and has always been a much superior language to Java in
> > spite of Java's popularity.
>
> Agreed.
>
> > Did you folks even take half a chance of looking at Objective
> > Caml. This is a very good language that has very good design as well
> > as features. What client machines do you have at the organization?
> > If they are Win based then any commercial Lisp GUI with CLIM support
> > should also suffice. Some of them have interfaces to GTK+ as well.
>
> No. I don't doubt for a moment that there is something beautiful
> about Objective Caml. But frankly, if it's (relatively) exotic and it
> isn't Lisp, then I can't be bothered. Sorry! I've got enough to
> worry about trying to keep up with Java and Python. I'm a real lover
> of the study of languages, but I have to draw the line somewhere if I
> am going to be useful.
>
> --
> John Michael Adams
"OCID" <······@purdue.edu> writes:
> That report was a very interesting read and well compiled. We really
> appreciate you putting it out.
Thanks for the encouragement.
> Java is a popular language that is controlled by a proprietary
> organization whose future is questionable. Its very similar to MS
> and C# in terms of technology. They compete with each other .... but
> you already know that. Thats what makes me uncomfortable to
> recommend Java to anyone.
Yeah, I don't disagree. I've done enough Java and Swing programming
to have a well-informed dislike. Although I must admit I found inner
classes to be amusing. Half the fun was nesting them deeper than a
certain book allowed as prudent. One thing I did enjoy about Swing
was that I could just go and read the source code to find out how
things worked. I am not sure that it is possible to adequately
document any full-featured gui api, so that counts for something.
I've programmed a bunch of gui api's: Vermont Views, Zinc Interface
Library, MS Windows 3.1, Borland OWL, MFC, Qwindows (QNX), Garnet,
CLX, Motif, Swing, at least one other whose name I can't remember.
They all have something wrong with them. Therefore, `it sucks' or
`some parts are poorly designed' is hardly a basis for judgment, as I
am sure you know.
> Objective Caml is much closer to Lisp than Python or at least as
> much and is a very good language, perhaps better than Python in many
> respects, However, it is not commercial and does not have support
> which might be an issue with most organizations.
My first encounters with functional languages were via ML and Miranda.
I was really taken with Miranda. This was before I learned Lisp. In
general, I have little or no interest in type systems or proofs of
correctness and I think that puts me at odds with a lot of fine work
in functional languages. Ah, but I see that Caml has polymorphic
typing. I like that.
> However, I don't see a good reason to use Java as a front
> end. wxWindows GUI libraries with C++ or even Python are much better
> than Swing and its fairly stable and uses native widgets. Commercial
> Lisp GUI's also appear to be quite decent and are cross-platform to
> an extent because of the inclusion of GTK+ bindings.
I'm going to look at wxPython. That's a fine suggestion, folks.
Thanks ever so much.
> We would be very interested in knowing what you actually go for when
> making the final decisions as well.
OK. Thanks again for your comments!
--
John Michael Adams
From: Tim Bradshaw
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <ey33ckzcgq8.fsf@cley.com>
* OCID wrote:
> Java is a popular language that is controlled by a proprietary
> organization whose future is questionable. Its very similar to MS
> and C# in terms of technology. They compete with each other .... but
> you already know that. Thats what makes me uncomfortable to
> recommend Java to anyone.
I think this is kind of a strange view. Do you really think that if
Sun went away (which hardly seems really likely in the near future
despite propaganda spread by the Linux cult), that Java will die?
What, exactly, will make the non-Sun-controlled Java systems go away?
And I would have thought that the experience of CL and standardisation
should help people understand why Sun might not want to go through
some nightmare standards process, while the fact that they are not a
monopolist should make it clear why they aren't about to turn around
and play the nasty tricks that monopolists do.
I don't particularly like Java, though I admire it as a bit of
engineering[1], but I definitely think it's not going away any time
soon.
--tim
Footnotes:
[1] yes yes, I know `it's not engineering it's marketing, whine whine
complain'. Just shut up.
Tim Bradshaw <···@cley.com> writes:
> I think this is kind of a strange view. Do you really think that if
> Sun went away (which hardly seems really likely in the near future
> despite propaganda spread by the Linux cult), that Java will die?
Despite being a fully paid-up[*] member of the Linux cult, I think I
must have missed this propaganda. Who's saying Sun is going away?
You didn't get suckered into reading slashdot or something, did you?
-dan
[*] it was Free to join ...
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
From: Paul F. Dietz
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <Q_WcnUk9E5cV5BCjXTWcrg@dls.net>
Daniel Barlow wrote:
> Despite being a fully paid-up[*] member of the Linux cult, I think I
> must have missed this propaganda. Who's saying Sun is going away?
> You didn't get suckered into reading slashdot or something, did you?
Sun sure is doing a fine imitation of a company being chased upmarket
by Christensen disruptive technologies.
Paul
From: Tim Bradshaw
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <ey3k7eal9o9.fsf@cley.com>
* Paul F Dietz wrote:
> Sun sure is doing a fine imitation of a company being chased upmarket
> by Christensen disruptive technologies.
That's because upmarket is *where the money is*. There really isn't a
lot of profit selling PC-level HW. And what, exactly, is this
disruptive technology? Linux? Come on, man, you need to do better
than that.
--tim
From: Paul F. Dietz
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <0becnQT61YCS4hCjXTWcow@dls.net>
Tim Bradshaw wrote:
>>Sun sure is doing a fine imitation of a company being chased upmarket
>>by Christensen disruptive technologies.
>
> That's because upmarket is *where the money is*. There really isn't a
> lot of profit selling PC-level HW. And what, exactly, is this
> disruptive technology? Linux? Come on, man, you need to do better
> than that.
Of course. You've given a concise description of the trap inherent
in the response of established companies to disruptive technologies.
Read Christensen's book for numerous examples.
Paul
From: Tim Bradshaw
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <ey3d6k2l8gd.fsf@cley.com>
* Paul F Dietz wrote:
> Of course. You've given a concise description of the trap inherent
> in the response of established companies to disruptive technologies.
> Read Christensen's book for numerous examples.
His (or his consulting company's) website seems to be trapped in some
kind of weird dot.com bubble timewarp: I think I'll pass, thanks.
--tim
From: Tim Bradshaw
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <ey38yuql4po.fsf@cley.com>
* Paul F Dietz wrote:
> Linux on x86 has been rougher, less scalable, with less third party software,
> perhaps less functional, perhaps less reliable than Solaris on Sparcs. But
> it's been cheaper, and it's been improving. The areas where Sun has
> a clear advantage are being pushed upward.
But this isn't anything to do with Linux, it's to do with hardware
costs. Solaris is *free* on low-end machines. From where I sit I can
see 2 PCs and 3 suns, and the only one of those machines that costs us
in OS SW licenses is the Windows PC.
If someone wanted to make an argument about cheap x86 HW eating the
RISC (and specifically in this context SPARC) market from below then I
think that's an interesting case, and very worrying for people like
Sun, but the noise about Linux is just, well, noise.
In other words I don't think Sun's problem is Solaris, I think it's
that they have a huge dilemma about hardware. SPARC isn't really
keeping up, specifically at the low end. But they can't move
wholesale to x86 both because it's not 64bit, and because it will be
in danger of commoditising them (the same way it is gradually killing
HP). So far that's seemed, really surprisingly, like the right thing
to do, because Itanic has been *so* late. But now (or nearly now)
there it Opteron, and maybe Itanic will finally be some good, so
perhaps the SPARC story sounds less plausible.
But really, *all* of this is missing the point. I think there's been
a long period where nerds have managed to actually make people care
whether something is Linux or Unix, or Windows, or free, or
commercial, or whatever. This kind of made sense because there's been
a long period where a lot of people have been really blinded by a
certain small area of technological progress. But I think that time
is ending now, and people will start to ask the important questions
like `does this thing make me money', and they're going to discover
that the difference between linux and solaris, or x86 and sparc is
just in the noise compared with other factors, like service and so on[1].
Sure, some smelly people who sit in front of computers too much obsess
about this, and somehow they seemed really important in the late 90s,
but those people are going to get relegated back to the basements
where they always lived.
Arguing about Solaris vs linux is like arguing about LOOP vs DO: there
are newsgroups full of it, but none of those people actually get to
make any decisions that matter.
The people Sun have to worry about and become more like aren't RedHat,
but IBM, who are past masters at the kind of thing that *actually*
matters when you get over worrying about technical trivia: `So you
want us to run your data centre, OK. You have Suns, that's fine, we
can maintain them. Oh and a Vax, we can do that too. Do you want to
buy some IBM kit to replace the Vax? No, you want to by an alpha, OK,
that's fine too, let us know when your ready. Just sign here'.
That's why I think Christensen (or his company) is in some weird
timewarp, because they seem to be obsessing on about how technology
will transform everything, and that's just *so* 90s.
--tim
Footnotes:
[1] I think the only technical difference which isn't in the noise is
likely MS vs anyone else.
The people Sun have to worry about and become more like aren't
RedHat, but IBM, who are past masters at the kind of thing
that *actually* matters when you get over worrying about
technical trivia: `So you want us to run your data centre, OK.
You have Suns, that's fine, we can maintain them. Oh and a
Vax, we can do that too. Do you want to buy some IBM kit to
replace the Vax? No, you want to by an alpha, OK, that's fine
too, let us know when your ready. Just sign here'.
That's why I think Christensen (or his company) is in some
weird timewarp, because they seem to be obsessing on about how
technology will transform everything, and that's just *so*
90s.
It's a compound game.
IBM builds, purchases, and partners with a basis set of service
elements (a notable example is glue technology).
As nearly as I can tell, their front-line service reps are then like
"general contractors" -- able to draw on IBM's assets to solve
customer problems in manners presumably befitting gentle-people of
good reputation in crisp, blue suits.
I said "basis set" of service elements because I want you to recognize
that the topology of the "span" of that set is critical to IBM's
mobility within the market; to their agility at solving customer
problems. The span, not a fixed product list, is what IBM sales reps
are armed with.
What "technology transforms" isn't everything -- it transforms those
basis sets, hence their span. IBM seems to have been very aggressive
about recognizing early the values of both Java and Linux if added
to their toolbox.
Sun, though they seem to be trying to change, was late to start
playing that game. They were far more parochial -- presumably because
(1) in the 80s and early 90s, there was a lot of business to be had
setting up "homogeneous shops" from scratch; (2) in some of their
bread-and-butter sectors in that same time period -- Sun achieved the
false-sense-of-security-inducing status of "(niche) solution provider
whose solutions `just work'"; (3) with all due respect, and perhaps a
bit analogously to some of us in the lisp world, I think their mgt and
culture was a bit "ego bound" -- after all, these are the guys who
were conquering RSX-11-running PDP-11s with BSD-flavor Sun
workstations. Those guys _knew_ the future a few years before anyone
else and they left the cramped offices of Stanford and Berkeley to
turn it into a huge business -- it's hard to come down from that and
take "inferior" technology seriously.
HP/C, especially the merger, can be interpreted as an attempt to
catch up to IBM's model. They pretty much said so explicitly.
There are disruptive "technologies" (in the broad sense) here, at
multiple scales. There's x86/Linux and Linux-as-commodity-platform in
the basis set toolboxes. And there's the human/organizational
technology of being a complete service provider. Tim Bradshaw and
Paul Dietz are both partly right. Technology (hacker sense) is most
definitely not "in the noise", but it also isn't the whole story.
It's interesting, if you buy my "ego bound" assessment of Sun,
to look at at least the official history of IBM's shift to its current
strategy. Putting it crudely, they got a non-hacker CEO who came
in an started shouting about the importance of focusing on customer
needs and, amazingly, the technical organization translated that into
their current state.
What can lisp do in this environment? It depends what you believe
lisp is capable of, I guess. Where, in the "basis set", can it make
a big, convincing difference?
-t
From: Tim Bradshaw
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <ey3istqny5y.fsf@cley.com>
* Tom Lord wrote:
> What "technology transforms" isn't everything -- it transforms those
> basis sets, hence their span. IBM seems to have been very aggressive
> about recognizing early the values of both Java and Linux if added
> to their toolbox.
I think my problem is that I find it hard to see the `transforming
technology' here. Well, let's be specific: Java may be a transforming
technology, although I don't think so: it's just a reasonably good
programming language, which will (I hope!) displace horrors like C++
in due course, but I don't think it will change the world.
So that leaves Linux. Well, forgive me for being cynical about open
source software's poster child, but I fail to see what is special
about Linux. Or rather, what I see as special about it is that it is
the single most visible sign of what is wrong with OSS: Linux tells us
just how little free software will actually change, and how tragically
uncreative the OSS movement is.
We all know the hype, of course - Linux will change the world, Linux
is the best OS, linux is transforming technology, Linus is God and
Linux is his holy word given to us that we may be enlightened, drone,
drone. But what, actually, *is* Linux? Well ... it's Unix. Of
course, it's not Unix in some silly technical sense beloved of
lawyers, but in every other way it is. Of course, Unix is pretty
cool, but didn't we already have one? Well, yes, we did. But it's
hugely better than all the rest, right? Well, no, it's not: it's a
fine system, and Linux distributions are certainly well ahead on the
desktop (a market which, unfortunately, is owned by Windows), but it's
definitely not `hugely better'. But it's *free*, right? Well, yes,
it is. But there are other free Unices, like the BSDs (which were
pretty obviously going to be free (in whatever sense) by, say
1992). And, actually, how much is the license cost for Solaris, say?
Well, it's bundled with machines costing ~$1000, so it can't be very
much.
So the greatest achievement of the OSS movement seems to be that it's
managed to implement another Unix. I find this profoundly depressing:
all that work has gone into doing something we already knew how to
do. I hate MS as much as the next person, but Windows looks pretty
good compared to this abject failure of imagination.
So, OK, whatever it is about Linux that is going to `transform' things
clearly isn't anything really technical, since it's not a very
interesting technical achievement. Maybe what people really mean is
that it's something about the way Linux - and OSS - is *written* that
will transform things? This is certainly more plausible.
So what could this be? I think it has to be that OSS is radically
cheaper to write than commercial software (and as a result, faster,
less buggy &c). This certainly seems to be what a lot of claims about
OSS come down to once you remove the religious dross. And if it's
true that OSS is radically cheaper, then it will certainly be bad news
for closed-source shops unless they can establish monopoly locks.
Well, I'm not sure OSS is much cheaper, although I could be wrong.
Firstly, as I've argued before, one of the side-effects of the
high-tech bubble was that people had more money than they knew what to
do with: spending some of it on OSS seemed like a good idea. So OSS
looked very cheap because so many companies were essentially using it
as a mechanism to give away some of their VC/IPO money. Secondly,
whether or not OSS is cheaper, it's certainly much harder to account
for its cost since the effort is scattered all over the place (all
those hours you spent fixing some device driver when you were meant to
be writing a billing system aren't being accounted for), so it is easy
to make it *look* cheaper. I've seen this second trick first hand
with Windows PCs: the Unix systems I ran in the mid 90s had fairly
accurately known costs: time to run them (me), support contracts & HW
costs. In 1995, Windows came in and essentially replaced them, and it
looked cheaper, too. But it looked cheaper because the support costs
were `zero' because now everyone spent 15% of their time fixing
Windows, which time was not accounted for, as mine had been. In fact,
Windows was much more expensive than Unix, but an accounting fiddle
had hidden the cost.
Maybe this is wrong - maybe OSS is radically technically better and
cheaper, but I am very unconvinced. I think it is mostly hype, both
technically and financially. Of course, hype can destroy companies
quite effectively, especially in IT - Lisp people should know that!
--tim
Tim Bradshaw <···@cley.com> writes:
> But what, actually, *is* Linux? Well ... it's Unix. Of course,
> it's not Unix in some silly technical sense beloved of lawyers, but
> in every other way it is. Of course, Unix is pretty cool, but
> didn't we already have one? Well, yes, we did.
I thought we had two: SysV-derived Unixes, and BSD Unixes. I mean,
the University of California *did* win that lawsuit by showing that
there was no AT&T code in 4.4BSD. (This only adds support to your
argument, of course).
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
[Aside:
People are asking why unix won.
Nobody has mentioned TCP/IP -- which I think is one
of the bigger reasons.
But then you have to ask why the authors of a
winning TCP/IP stack happened to be writing on unix.]
me:
> What "technology transforms" isn't everything -- it transforms those
> basis sets, hence their span. IBM seems to have been very aggressive
> about recognizing early the values of both Java and Linux if added
> to their toolbox.
Tim Bradshaw:
I think my problem is that I find it hard to see the
`transforming technology' here. Well, let's be specific: Java
may be a transforming technology, although I don't think so:
it's just a reasonably good programming language, which will
(I hope!) displace horrors like C++ in due course, but I don't
think it will change the world.
It _has_ changed the world, in a huge way. So has Linux.
Have you looked at programmer job listings recently? Around here it's
90%:
a) J2EE and related.
b) Linux device drivers and protocol stacks.
c) Various Windows technology.
d) RDBMS (especially Oracle) hacking.
e) NAS related (mostly, but not entirely Sun)
There was an "enterprise legacy <-> web" problem to solve -- Java (in
spite of the advertised original and secondary intentions) solved it
well enough to commoditize.
Personally, I think one big opportunity for lisps going forward is in
productivity apps / GUIs and, with all due respect, I don't think
Kenny is on the right architectural track (but it's hard to be certain
based only on his posts/web site).
So that leaves Linux. Well, forgive me for being cynical
about open source software's poster child, but I fail to see
what is special about Linux. Or rather, what I see as special
about it is that it is the single most visible sign of what is
wrong with OSS: Linux tells us just how little free software
will actually change, and how tragically uncreative the OSS
movement is.
If there's hope there, it's that that lack of creativity is a
weakness of the Linux and Linux app vendors. They need to come to
terms with it or slowly fade away.
A funny thing: gazzillions of both actual money and unaccounted
"volunteer resources" have been poured into Gnome and KDE. You know
what's going to take the day there? OpenOffice with a thin layer of
window managers from those other projects.
A big paradigm shift there is waiting to happen. Emacs is the crude
blueprint, and lisp the only appropriate tool.
We all know the hype, of course - Linux will change the world,
Linux is the best OS,
Nobody serious says that.
Serious people say: "Linux is catching up to proprietary unix faster
than we might have expected."
Linux isn't eating away MSFT. Apache took the web server domain --
but beyond that, Linux is eating proprietary unix, which was dying
already before linux even arrived. OpenOffice will put a big dent
into MSFT -- without advancing the technology, of course -- but I
can't help wonder whether MSFT R&D will simply leapfrog that.
But there are other free Unices, like the BSDs (which were
pretty obviously going to be free (in whatever sense) by, say
1992).
My take on it is that the rumours of the bsds' deaths are greatly
exaggerated. For social, cultural reasons -- the BSDs have a strong
orientation towards _deep_ quality -- and that's completely
incompatible with the rapid changes needed to ramp your boxed set up
into an IPO. Linux "won" (so far) because it's community is,
culturally, a cheap whore.
Personally, I think that one of the greatest indirect influences on
the BSDs is Alice Waters of Chez Panisse fame. The Berkeley
restaurant culture is vibrant, profound, and oriented toward fresh,
affordable quality. As a _slight_ fiction, we blame Alice Waters for
that. There's a kind of charmingly snotty attitude that goes with
preserving that orientation -- and I think it leaked into the grad
school offices of Evans hall, where it resonated with the input from
New Jersey. A snotty attitude makes you incompatible with a dot com
bubble. You are what you eat.
So the greatest achievement of the OSS movement seems to be
that it's managed to implement another Unix. I find this
profoundly depressing:
Likewise, mostly.
So, OK, whatever it is about Linux that is going to
`transform' things clearly isn't anything really technical,
Right. And MSFT R&D is all over that. The Linux companies need to
catch up -- and that's the wedged-but-unlocked-door for lisps.
So what could this be? I think it has to be that OSS is
radically cheaper to write than commercial software (and as a
result, faster, less buggy &c). This certainly seems to be
what a lot of claims about OSS come down to once you remove
the religious dross.
Disgusting, isn't it? The "good" news is that there are increasing
numbers of of OSS hackers either out of work or making their money by
writing Windows apps. Further good news is that KDE and Gnome, some
of the biggest absorbers of free labor, have blown it badly and
deeply. The final good news is that the low hanging fruit has
commited companies to GNU/Linux and given them some revenue from
that.
So, all we need now is a return to sanity among the Linux-committed
execs, some recognition of the need for practical R&D and innovation,
and some sexy and efficient marketers of all things lispish.
Maybe this is wrong - maybe OSS is radically technically better
and cheaper, but I am very unconvinced. I think it is mostly
hype, both technically and financially. Of course, hype can
destroy companies quite effectively, especially in IT - Lisp
people should know that!
The hype is partly self-fullfilling because of free labor -- but
that's easy to confuse with the non-hypish aspect of lowered
transaction costs between OSS companies (non-free labor, deployed more
efficiently).
But it looked cheaper because the support costs were `zero'
because now everyone spent 15% of their time fixing Windows,
which time was not accounted for, as mine had been. In fact,
Windows was much more expensive than Unix, but an accounting
fiddle had hidden the cost.
I wish M. Fouault were alive and interested in software and software
economics. You're talking about accounting from a social cost
perspective, but "they" are talking about accounting as part of a
discorsive deployment of power over the "unaccounted".
Yes, to put it in radical terms, the OSS businesses define a lot
of people as, essentially, non-persons.
-t
From: Kenny Tilton
Subject: Cello! [was Re: Report on languages for planning and scheduling}
Date:
Message-ID: <3E91DC63.6080007@nyc.rr.com>
Tom Lord wrote:
> Personally, I think one big opportunity for lisps going forward is in
> productivity apps / GUIs and, with all due respect, I don't think
> Kenny is on the right architectural track (but it's hard to be certain
> based only on his posts/web site).
you mean the (free)glut/opengl choice? I'm all ears, privately if you
prefer. Scott's passing remark (yesterday I think) about an imagined
Lisp GUI project "...with a GTk backend" had me staring at that
alternative again today, and if the upcoming expansion of Cello to
CMUCL/X reveals problems with FG... ya never know.
The only thing I am really married to is the dataflow model supported by
Cells. Well, and "universality" across sufficiently compliant Lisps.
I now have a demo/real project on its feet, a portable object inspector.
Idea came from a suggestion by tfburdick, who is working on the cmucl/x
version of Cello for me.
For development purposes, the inspector window (code-name "Cloucell")
launches into an inspection of itself. Just for the hell of it (and
maybe this will be useful, but I myself never use the ACL inspector
"refresh" feature so I doubt it) I had the widgets /displaying/ cell
values themselves be linked dataflow-wise to those values. So as I move
the mouse around and the window is recalculating stuff based on mouse
motion events, I see the values updated in the inspector.
Nutty feature, more to make the point about dataflow than anything else.
I'll see if I can get some screenshots up, though more time is needed on
cosmetics.
Cells originally were used to drive the Mac OS native widgets, then on
win32 I found it easier to roll all my own than fight it out with ACL's
CommonGraphics atop win32 (tho I got it working as part of the
feasibility assessment) so... my expectation is that down the road some
huge fan of Tk or GTk or MFC or whatever will use Cells to drive those
and have great success.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
From: Tom Lord
Subject: Re: Cello! [was Re: Report on languages for planning and scheduling}
Date:
Message-ID: <v944p8sce6f9d3@corp.supernews.com>
> Personally, I think one big opportunity for lisps going forward is in
> productivity apps / GUIs and, with all due respect, I don't think
> Kenny is on the right architectural track (but it's hard to be certain
> based only on his posts/web site).
you mean the (free)glut/opengl choice? I'm all ears, privately
if you prefer. Scott's passing remark (yesterday I think)
about an imagined Lisp GUI project "...with a GTk backend" had
me staring at that alternative again today, and if the
upcoming expansion of Cello to CMUCL/X reveals problems with
FG... ya never know.
No...that's not what I mean.
I mean you are fidgeting with widgets when that's not the right
approach. It's the wrong level of abstraction for a framework.
For, like, 16 years or such -- commercial and quasi-commericial gui
framework development has centered on:
a) "view trees" of widgets
b) gosh, _how_ _ever_ can we manage the dataflow among widgets?
c) i wanna put a spread-sheet in my word document -- don't we need a
comprehensive "component architecture" for that?
d) hey, let's hire some ui experts to help polish (a) (b) and (c) with
things like better menu and icon design; better locate-highlight
feedback, etc.
You don't look like you're diverging from that.
I don't think app-specific widgets and app-specific dialogs and things
like that are the way to go. Not by a long shot.
Screw all that: I want a generic display manager and generic
interaction manager, and generic buffer manager -- ala emacs. Yes, I
need to augment it with drawings and embedded graphical output windows
and such.
But I don't need widgets. Thus I don't need to worry about how
they're connected. And I certainly don't need to generalize that into
components. I need multi-font, looks-nice emacs with support for some
drawings and pictures and a nice extension language -- and we'll take
it from there.
The only thing I am really married to is the dataflow model
supported by Cells.
Well, then, there is little hope for you :-)
-t
From: Kenny Tilton
Subject: Re: Cello! [was Re: Report on languages for planning and scheduling}
Date:
Message-ID: <3E925AB3.7040605@nyc.rr.com>
Tom Lord wrote:
> I mean you are fidgeting with widgets when that's not the right
> approach. It's the wrong level of abstraction for a framework.
You fell for my marketing: if I want to share Cells, only a Cello (with
widgets off the shelf) will get the message across.
I agree, widgets are boring. Frameworks are the wrong level of
abstraction. Hell, I am not even interested in frameworks. I think my
use of "widget" for what is nothing more than a concept of user
interacton with visual element was too-shorthandy. The reality is that
Cello offers abstraction out the wazoo, such that a new widget (or no
widget at all) can be tossed off in a day or three.
In brief, I expect to satisfy roll-your-owners and off-the-shelfers both
with Cello.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
From: Christopher C. Stacy
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <uznn2humk.fsf@dtpq.com>
>>>>> On Mon, 07 Apr 2003 18:17:19 -0000, Tom Lord ("Tom") writes:
Tom> People are asking why unix won.
Tom> Nobody has mentioned TCP/IP -- which I think is one
Tom> of the bigger reasons.
Unix was one of the later systems to eventually have TCP/IP,
which was pioneered on PDP-10 computers (TENEX, TOPS-20, and
actually the first working implementation I think was the one
we had on ITS) and Multics. The Lisp Machine had TCP/IP at
about the same time as Unix (maybe a little before); all of
these systems had networking for many years before Unix did.
Tom> Have you looked at programmer job listings recently?
Tom> Around here it's 90%:
Tom> a) J2EE and related.
Tom> b) Linux device drivers and protocol stacks.
Tom> c) Various Windows technology.
Tom> d) RDBMS (especially Oracle) hacking.
Tom> e) NAS related (mostly, but not entirely Sun)
A clear demonstration of Theodore Sturgeon's law.
Tom> People are asking why unix won. Nobody has mentioned
Tom> TCP/IP -- which I think is one of the bigger reasons.
Unix was one of the later systems to eventually have TCP/IP,
which was pioneered on PDP-10 computers (TENEX, TOPS-20, and
actually the first working implementation I think was the one
we had on ITS) and Multics. The Lisp Machine had TCP/IP at
about the same time as Unix (maybe a little before); all of
these systems had networking for many years before Unix did.
I said "one of the bigger", not "only". Your followup emphasizes the
portability aspect of unix (tenex, tops-20, its, multics, lisp machine
-- all comparatively hw-specific).
So then in the mid-80s, if your shop was like my internship shop, you
needed networking on cheap hw -- and there were these unix guys who
came in and demoed it on Sun 68K boxes and told you about the vax
distro .... at that shop, they (my employer) were up-to-then
reselling RSX-11 pdp-11s pre-loaded with the ECAD app in question. I
don't think they worried about getting unix with networking on pdp's
since the sun boxen hit the right price point to totally change the
market dynamics. (But, hey, I was 17 or 18 -- so this is all
reconstruction in retrospect).
Wow. That was back when mice were (in the market) a new thing. The
PDP 11 version of the ECAD editor had two displays. I mean -- they
sold this whole big hardware mess just for one little app that
happened to have a layout editor and autorouter for PC boards. One
display showed the board you were editting. The other showed either a
menu or just a completely green screen. You did all your editting
with a light pen, pointing at the green screen. It looked like a big
video arcade game:
______
| |
/ |
( <- Display of board
light \ |
pen \ / |
display\ / |
___v__ |
_____ | pdp11 |
| | |
| | |
/ \ |==============|
^
|
operator seat
A big custom monster completely blown away by a generic sun
workstation. Think about it -- Sun helped destory the business of the
company that used to mill the particle board components of that "ECAD
video game" monster. Until sun came along, "ECAD workstation" meant
that custom assembly of particle board and late-model pdp-11 and two
crts and light pen and power supply.....
One of my internship duties, before the company decided to move to
unix: helping the DEC ex-patriot RSX-11 hacker work on ethernet
support for RSX-11. Everything from drilling yellow coax to parsing
packets. Later I got to muck with the redisplay code under unix. In
between I got to work on code to parse those pesky tar files that were
popping up. Now _that_ was (part of) a good programming education;
college, on the other hand, was a total let down (except for the
library and the "corridor conversations" with grad students and
faculty).
It was a _huge_ deal, back then, that you could (on the unix platform)
have a single head with mouse with good enough graphics to actually
scroll the PC-board picture (something that people stood on their
heads to get working on the 11s.) And I mean _huge_ -- as in, bring
in members of the corporate board for a demo.
There _was_ in fact, a lisp hacker at that shop. He was wrapped up in
expert systems and their application to automatic layout of pc board
components (while honoring design rules). or something like that -- I
didn't work with him closely. I do recall that there was some tool
with complicated parameters that it took an expert to solve --- and
that guy was going to use some "AI" (in the form of expert systems) to
simplify. Anyway, he pointed me at the local installation of franz
(on the unix vax) -- which I then used to implement a crude theorem
prover. And then there was CGA Emacs ...
-t
Tim Bradshaw <···@cley.com> writes:
> as a mechanism to give away some of their VC/IPO money. Secondly,
> whether or not OSS is cheaper, it's certainly much harder to account
> for its cost since the effort is scattered all over the place (all
> those hours you spent fixing some device driver when you were meant to
> be writing a billing system aren't being accounted for), so it is easy
... while in an adjacent thread people are praising the Lispm for the
ease with which the developer can get distracted from whatever he's
supposed to be working on and end up fixing bugs in his networking stack
(for which he presumably isn't being paid by Symbolics) or spending
several hours impressing the neophyte user who's just trashed his
world by setting T to NIL, instead of doing the obvious thing and just
rebooting the box. I wonder who was accounting for that time.
(I have no particualrly strongly held position in this debate.
There've been times I've wasted too many hours trying to fix weird
bugs in Linux, but then there's other times I've wasted way too many
hours communicating with support services trying to get someone _else_
to fix bugs in their software that I don't have the source to, or
guessing what the problem probably is and attempting workaround. It's
a trade-off every time)
One nice - though scarcely transforming - thing about Linux is that
it's put some pressure on other Unix vendors to fix their
out-of-the-box installs a bit. When did Sun start shipping gzip in
Solaris? Irix were still defaulting the stty erase character to @ in
6.2, for goodness' sake.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
From: Christopher C. Stacy
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <u4r5aj9gs.fsf@dtpq.com>
>>>>> On Mon, 07 Apr 2003 18:48:43 +0100, Daniel Barlow ("Daniel") writes:
Daniel> ... while in an adjacent thread people are praising the Lispm for the
Daniel> ease with which the developer can get distracted from whatever he's
Daniel> supposed to be working on and end up fixing bugs in his networking stack
Daniel> (for which he presumably isn't being paid by Symbolics) or spending
Daniel> several hours impressing the neophyte user who's just trashed his
Daniel> world by setting T to NIL, instead of doing the obvious thing and just
Daniel> rebooting the box. I wonder who was accounting for that time.
... while in an adjacent room, people are cursing the systems of today for the
ease with which the developer can get distracted from whatever he's
supposed to be working on and end up spending infinite hours trying to guess
why his program is not working, when he can hardly be able to even diagnose
that the problem is due to a part of the system that he doesn't have access to,
couldn't understand, and even if he did, there's nothing he could really
do about it. I wonder who is accounting for that time?
Apparently, people are not very well explaining what it was like to
use LispMs. I'm not sure how I would explain it, either: it's such a
different world view from the way computers are today.
Daniel> One nice - though scarcely transforming - thing about Linux
Linux in no way compares favorably with the Lisp Machine's development environment.
From: Doug Quale
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <877ka54vuh.fsf@charter.net>
······@dtpq.com (Christopher C. Stacy) writes:
> Linux in no way compares favorably with the Lisp Machine's
> development environment.
It sure as hell does if you are programming in any language other than
Lisp.
Doug Quale <······@charter.net> writes:
> ······@dtpq.com (Christopher C. Stacy) writes:
>
> > Linux in no way compares favorably with the Lisp Machine's
> > development environment.
>
> It sure as hell does if you are programming in any language other than
> Lisp.
Actually, it does not.
The compilers for static languages supported incremental compilation
and a whole slew of other creature comforts which are nowhere to be
found in the contemporary commercial environments. Never mind that
passing data between language environments is a lot less painful on a
Lisp Machine then it is on a UNIX system.
From: Doug Quale
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <878yul35vf.fsf@charter.net>
Carl Shapiro <·············@panix.com> writes:
> Doug Quale <······@charter.net> writes:
>
> > ······@dtpq.com (Christopher C. Stacy) writes:
> >
> > > Linux in no way compares favorably with the Lisp Machine's
> > > development environment.
> >
> > It sure as hell does if you are programming in any language other than
> > Lisp.
>
> Actually, it does not.
>
> The compilers for static languages supported incremental compilation
> and a whole slew of other creature comforts which are nowhere to be
> found in the contemporary commercial environments. Never mind that
> passing data between language environments is a lot less painful on a
> Lisp Machine then it is on a UNIX system.
Actually it does.
Just how many static languages are supported on a Lisp machine? C and
Fortran are not the entire world outside of Lisp. Even C and Fortran
are better on Linux than on a Lisp machine for most applications. All
the creature comforts in the world don't make up for the lack of useful
libraries and slow hardware.
If you're a scientist or an engineer working with MPI software to run
on clustered machines then the Lisp machine doesn't seem like a good
bet.
If you're developing software to run on IBM Z/OS hardware, Linux would
be an infinitely better bet than a Lisp machine.
It would be interesting to see a project like the Gimp developed on
the Lisp Machine. The development environment would be nice, but
you'd never have much of a user or developer community because almost
no one could run it. The hardware is too expensive, scarce and slow.
Something like Linux itself could never have happened on the Lisp
Machine. Again the hardware is too expensive so the developer
community could never reach critical mass.
It's rather funny that it isn't sufficient that the Lisp Machine had
many things to offer that are not found in popular current systems.
Instead it must be revered as superior in every way to anything else.
It's that kind of arrogance that helped kill it. But since it's dead,
I guess there's no reason to stop now.
From: Gabe Garza
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <87u1d91po1.fsf@ix.netcom.com>
Doug Quale <······@charter.net> writes:
> It would be interesting to see a project like the Gimp developed on
> the Lisp Machine. The development environment would be nice, but
> you'd never have much of a user or developer community because almost
> no one could run it. The hardware is too expensive, scarce and slow.
Heh. There was a great deal of graphics work done on the Lisp
machine--from what I gather, some of the most successful Lisp Machine
applications where graphics-related. Symbolics made S-Graphics, which
has, after $n$ changes of ownership and a lot of evolution, ended
up here:
http://www.izware.com/
Along the way it's done everything from ground-breaking animation
("Stanley and Stella in 'Breaking the Ice'") to Nintendo 64 games.
I find it far more impressive then a photoshop knock-off.
> Something like Linux itself could never have happened on the Lisp
> Machine.
Nor could the Pinto have ever happened in a Porsche studio.
> It's rather funny that it isn't sufficient that the Lisp Machine had
> many things to offer that are not found in popular current systems.
> Instead it must be revered as superior in every way to anything else.
If you think writing Oracle-driven web apps with ColdFusion,
JavaScript, Flash, etc., that any of a hundred thousand
interchangeable "developers" could spit out is what it's all about,
then a Lisp Machine ain't for you.
Not that there's anything wrong with that.
Gabe Garza
From: Doug Quale
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <87of3h9hcz.fsf@charter.net>
Gabe Garza <·······@ix.netcom.com> writes:
> Doug Quale <······@charter.net> writes:
>
> > It would be interesting to see a project like the Gimp developed on
> > the Lisp Machine. The development environment would be nice, but
> > you'd never have much of a user or developer community because almost
> > no one could run it. The hardware is too expensive, scarce and slow.
>
> Heh. There was a great deal of graphics work done on the Lisp
> machine--from what I gather, some of the most successful Lisp Machine
> applications where graphics-related. Symbolics made S-Graphics, which
> has, after $n$ changes of ownership and a lot of evolution, ended
> up here:
>
> http://www.izware.com/
>
> Along the way it's done everything from ground-breaking animation
> ("Stanley and Stella in 'Breaking the Ice'") to Nintendo 64 games.
>
> I find it far more impressive then a photoshop knock-off.
Really? What about Cinepaint? (Film Gimp). Linux is responsible for
a *lot* more feature animation than the Lisp Machine ever was or could
be. I don't find the Lisp Machine's contributions here very
impressive at all.
A photoshop knock-off would be pretty amusing on a Lisp Machine today.
Not very many artists would use it -- it would just be too slow.
> > Something like Linux itself could never have happened on the Lisp
> > Machine.
>
> Nor could the Pinto have ever happened in a Porsche studio.
There's a place for both, but the world needs Pintos more than it
needs Porsches. The simple fact is that the Model T contributed far
more to the world more than Ferrari. Failure to understand that
killed the Lisp Machine. Unix is both the Model T and the Concorde
and everything in between. Unix's ecological niche completely
swallows the far too small niche that the Lisp Machine filled. That's
why Unix thrives and the Lisp Machine died.
> > It's rather funny that it isn't sufficient that the Lisp Machine had
> > many things to offer that are not found in popular current systems.
> > Instead it must be revered as superior in every way to anything else.
>
> If you think writing Oracle-driven web apps with ColdFusion,
> JavaScript, Flash, etc., that any of a hundred thousand
> interchangeable "developers" could spit out is what it's all about,
> then a Lisp Machine ain't for you.
>
> Not that there's anything wrong with that.
How does this make the Lisp Machine environment better in every way
than current environments? A *lot* more people get paid to write
Oracle driven apps than Lisp Machine apps. If you can't earn a living
hacking the superior Lisp Machine environment, it clearly isn't
superior in one very critical way.
Doug Quale <······@charter.net> writes:
> > Along the way it's done everything from ground-breaking animation
> > ("Stanley and Stella in 'Breaking the Ice'") to Nintendo 64 games.
> >
> > I find it far more impressive then a photoshop knock-off.
>
> Really? What about Cinepaint? (Film Gimp). Linux is responsible for
> a *lot* more feature animation than the Lisp Machine ever was or could
> be. I don't find the Lisp Machine's contributions here very
> impressive at all.
Are you dividing out by the number of seats?
That is, how many cool things per capita are produced on Linux
compared to the per capita coolness of things done on LispMs?
> A photoshop knock-off would be pretty amusing on a Lisp Machine today.
> Not very many artists would use it -- it would just be too slow.
And if there was such a thing, we'd be accused of being able to do
little more than cheap knock-offs of what other systems do. Hmm. The
LispM graphics products were technologically quite competitive in
their time, and there's no reason to suppose they wouldn't be today if
they'd been maintained. Hardware cost was an issue, but that was an
issue of market size, not an issue of technical competence.
And, if anything, the key barrier to a larger market was dumbing down
the product, not making it more capable. I used to think about how
fun it was to program Lisp and share with my friends, and for a while
I stupidly entertained the serious thought that as the market grew,
the world would become filled with smart, interesting people all using
this cool tool. Then, over a year or two, the awful, creeping, sad
truth sunk in: The number of smart, interesting people capable of
using the tool 'as is' was going to remain approximately constant--to
reach a bigger audience, we needed to spend time on embracing the
mundane. Don't get me wrong--this SHOULD have been done for marketing
reasons. It had to be to reach out. But ALSO, don't confuse this
with there having been something technologically unsound about what
we'd developed...
>
> > > Something like Linux itself could never have happened on the Lisp
> > > Machine.
> >
> > Nor could the Pinto have ever happened in a Porsche studio.
>
> There's a place for both, but the world needs Pintos more than it
> needs Porsches. The simple fact is that the Model T contributed far
> more to the world more than Ferrari. Failure to understand that
> killed the Lisp Machine.
Failure to understand that this kind of "criticism" of the Lisp Machine
(i.e., a kind of ad hominem argument, directed at the marketers of
Lisp Machines) does not support any claim of technical superiority is
what kills these discussions.
I hope it's clear that in an analogy between Porsche and Pinto,
claiming that you're happy to be like the Pinto is _good_ if the
domain into which you're mapping the analogy is
'business'/'money'/'service' but is bad if the domain into which
you're mapping the analogy is 'ideas'/'art'/'power'/etc.
> Unix is both the Model T and the Concorde
> and everything in between.
I don't see any supporting evidence for it being a Concorde. The most
'advanced' argument I've seen for the high end is "it has a lot of
libraries", which is an issue of market penetration, not an issue of
goodness of the system. As I've discussed endlessly, anything you
offer free is going to be hard to compete with--doubly so for
something like the LispM which was generally on the high end of price.
But exactly because market forces were not in play, you can't say that
these numbers or these libraries owe _anything_ to the technical value
of Linux at all. If we open-sourced Windows and closed Linux, people
would probably make tons of Windows libraries, and you'd probably
claim that Windows was the Model T and the Concorde and everything in
between. But the truth is probably that people like it when they get
lots of stuff for free, probably more than they like that particular
architecture and environment, which I'd be hard-pressed to say was
really revolutionary in any very material way.
> Unix's ecological niche completely
> swallows the far too small niche that the Lisp Machine filled. That's
> why Unix thrives and the Lisp Machine died.
Again argument based purely on size.
If you keep a constant vigil, you'll catch any good idea before it is
too big and you'll alwyas be able to use this form of argument to kill it,
veritably assuring Linux is not only the best you've ever seen, but will,
without doubt, be the best you ever _do_ see, even in the future.
Good job.
> > > It's rather funny that it isn't sufficient that the Lisp Machine had
> > > many things to offer that are not found in popular current systems.
> > > Instead it must be revered as superior in every way to anything else.
> >
> > If you think writing Oracle-driven web apps with ColdFusion,
> > JavaScript, Flash, etc., that any of a hundred thousand
> > interchangeable "developers" could spit out is what it's all about,
> > then a Lisp Machine ain't for you.
> >
> > Not that there's anything wrong with that.
>
> How does this make the Lisp Machine environment better in every way
> than current environments? A *lot* more people get paid to write
> Oracle driven apps than Lisp Machine apps. If you can't earn a living
> hacking the superior Lisp Machine environment, it clearly isn't
> superior in one very critical way.
A lot more people probably got paid to stand in stores greeting people
one-on-one with a smile before webapps replaced stores. Is sheer
numbers a metric of goodness?
Heck, I miss those stores so don't think I don't understand this as
a metric of _social_ value. I just don't see it as a metric of technical
value.
Business thrives on inefficiency. Inefficiency makes jobs. Don't try
to defend technical superiority by showing how many jobs it can make because
that's practically an proof that you're wrong.
Incidentally, Symbolics tried the marketing strategy where it showed you
could do a lot of your work with smaller organizations. It flopped.
People in power don't want their empires shrunk. People wanting to buy
something don't want to buy something that will put them out of business.
They'd rather have something inefficient.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> > Unix's ecological niche completely
> > swallows the far too small niche that the Lisp Machine filled. That's
> > why Unix thrives and the Lisp Machine died.
>
> Again argument based purely on size.
>
> If you keep a constant vigil, you'll catch any good idea before it is
> too big and you'll alwyas be able to use this form of argument to kill it,
> veritably assuring Linux is not only the best you've ever seen, but will,
> without doubt, be the best you ever _do_ see, even in the future.
And why not? It worked for Microsoft.
E.
--
The opinions expressed here are my own and do not necessarily
reflect the views of JPL or NASA.
From: Joe Marshall
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <k7e4zovm.fsf@ccs.neu.edu>
> Doug Quale <······@charter.net> writes:
>
> > Unix is both the Model T and the Concorde
> > and everything in between.
Kent M Pitman <······@world.std.com> writes:
>
> I don't see any supporting evidence for it being a Concorde.
I think he is being mislead by the pointy nose.
Sure, you can run X windows, pop up a GNU emacs, run make, GDB, and a
shell from a subwindow, and it almost, kinda, sorta, reminds you of an
IDE. Just like you can fasten a pointy nose on a model T and make
`vroom' noises and pretend it is a Concorde. And these days, what
with the Interstate and all, you can drive your model T all the way
across the continent pretty damn fast.
Joe Marshall <···@ccs.neu.edu> writes:
>> Doug Quale <······@charter.net> writes:
>>
>> > Unix is both the Model T and the Concorde
>> > and everything in between.
>
> Kent M Pitman <······@world.std.com> writes:
>>
>> I don't see any supporting evidence for it being a Concorde.
>
> I think he is being mislead by the pointy nose.
>
> Sure, you can run X windows, pop up a GNU emacs, run make, GDB, and a
> shell from a subwindow, and it almost, kinda, sorta, reminds you of an
> IDE. Just like you can fasten a pointy nose on a model T and make
> `vroom' noises and pretend it is a Concorde. And these days, what
> with the Interstate and all, you can drive your model T all the way
> across the continent pretty damn fast.
Oh puhleese. Just because there hasn't been much progress on the Lisp
side of the world in the last decade, it doesn't mean that all others
didn't improve their tools either.
It may well be that hacking C code for Unix with vi, make and gdb was
way worse than hacking Lisp on a Symbolics back when more that 2
people not reading comp.lang.lisp knew what a Lisp Machine is, but
hey, it's 2003: Users of lesser languages now have working IDEs, even
on Linux. Have a look at Eclipse or IntelliJ for Java, try
KDevelop/Gideon, or even Anjuta for C/C++, maybe Boa Constructor, Eric
or Komodo for Python - they still don't have special variables and
invoke-restart, but they definitely help getting stuff done, while
Lispers are stuck with Emacs and it's clones (that generally work
worse than it, and aren't exactly pretty either, in my experience.)
Don't get me wrong - I love Lisp (and Emacs, for that matter)
personally, but I am seriously pissed of by the lost opportunities. I
think Lisp /is/ still the best programming language available, but I
for one would be way more comfortable if it wouldn't just claim to be
the best choice for "solving the world's hardest problems" that others
claim to be "impossible", but wouldn't require solving all of the
worlds most boring problems from scratch every time.
Regards
Henrik
Doug Quale <······@charter.net> wrote in message news:<··············@charter.net>...
> Gabe Garza <·······@ix.netcom.com> writes:
>
> > Doug Quale <······@charter.net> writes:
> >
> > > It would be interesting to see a project like the Gimp developed on
> > > the Lisp Machine. The development environment would be nice, but
> > > you'd never have much of a user or developer community because almost
> > > no one could run it. The hardware is too expensive, scarce and slow.
> >
> > Heh. There was a great deal of graphics work done on the Lisp
> > machine--from what I gather, some of the most successful Lisp Machine
> > applications where graphics-related. Symbolics made S-Graphics, which
> > has, after $n$ changes of ownership and a lot of evolution, ended
> > up here:
> >
> > http://www.izware.com/
> >
> > Along the way it's done everything from ground-breaking animation
> > ("Stanley and Stella in 'Breaking the Ice'") to Nintendo 64 games.
> >
> > I find it far more impressive then a photoshop knock-off.
>
> Really? What about Cinepaint? (Film Gimp). Linux is responsible for
> a *lot* more feature animation than the Lisp Machine ever was or could
> be. I don't find the Lisp Machine's contributions here very
> impressive at all.
FYI, Bay Raitt and his crew (Sven Jensen and some others I am
forgetting) used Mirai (Leonardo's grand-daddy, and as far as I know
Larry Malone is still working on it after starting S-Geometry at
Symbolics nearly (over?) 17 years ago) to make most of Gollum's face
(in addition to the cave troll's face and some other critters).
http://mag.awn.com/index.php3?ltype=pageone&article_no=1650
Cinepaint is Gimp with 64-bit color and some animation support added;
not very impressive by most measures. Most of the really impressive
graphics apps were originally written for SGI workstations (I heard
that back in the 80s Symbolics was SGI's chief competitor, which
wouldn't be surprising considering how far ahead of everything
Leonardo was). Of course, I also heard that even back then the SGIs
were faster than the Symbolics machines, which again wouldn't be
surprising. Nowadays the x86 is faster than anything that SGI puts out
(you also have to consider that the biggest use of Linux in film
studios by far is running Renderman clusters, as it was with the
SGIs).
http://kogs-www.informatik.uni-hamburg.de/~moeller/symbolics-info/s-products.html
> A photoshop knock-off would be pretty amusing on a Lisp Machine today.
> Not very many artists would use it -- it would just be too slow.
A photoshop knockoff running on a 386 would also be amusing. What's
your point?
> > > Something like Linux itself could never have happened on the Lisp
> > > Machine.
> >
> > Nor could the Pinto have ever happened in a Porsche studio.
>
> There's a place for both, but the world needs Pintos more than it
> needs Porsches. The simple fact is that the Model T contributed far
> more to the world more than Ferrari. Failure to understand that
> killed the Lisp Machine. Unix is both the Model T and the Concorde
> and everything in between. Unix's ecological niche completely
> swallows the far too small niche that the Lisp Machine filled. That's
> why Unix thrives and the Lisp Machine died.
Unix isn't a very good development environment. Why do you think so
many people use emacs?
> > > It's rather funny that it isn't sufficient that the Lisp Machine had
> > > many things to offer that are not found in popular current systems.
> > > Instead it must be revered as superior in every way to anything else.
> >
> > If you think writing Oracle-driven web apps with ColdFusion,
> > JavaScript, Flash, etc., that any of a hundred thousand
> > interchangeable "developers" could spit out is what it's all about,
> > then a Lisp Machine ain't for you.
> >
> > Not that there's anything wrong with that.
>
> How does this make the Lisp Machine environment better in every way
> than current environments? A *lot* more people get paid to write
> Oracle driven apps than Lisp Machine apps. If you can't earn a living
> hacking the superior Lisp Machine environment, it clearly isn't
> superior in one very critical way.
PS - I hate to state the obvious and break my own rule, but let's all
please stop feeding the troll.
Vladimir
From: Joe Marshall
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <1y0d9jih.fsf@ccs.neu.edu>
> > > ······@dtpq.com (Christopher C. Stacy) writes:
> > >
> > > > Linux in no way compares favorably with the Lisp Machine's
> > > > development environment.
> >
> > Doug Quale <······@charter.net> writes:
> > >
> > > It sure as hell does if you are programming in any language other than
> > > Lisp.
>
> Carl Shapiro <·············@panix.com> writes:
> >
> > Actually, it does not.
> Doug Quale <······@charter.net> writes:
>
> Actually it does.
>
> Just how many static languages are supported on a Lisp machine?
True, programming a LispM in a language not supported by a LispM is
probably as painful as programming in a language supported by Unix,
but there is no development environment on Unix for any language that
compares with the Lisp development environment on a Lisp machine.
> Something like Linux itself could never have happened on the Lisp
> Machine.
Of course not. Why would anyone want to cripple a LispM in such a
way?
> It's rather funny that it isn't sufficient that the Lisp Machine had
> many things to offer that are not found in popular current systems.
> Instead it must be revered as superior in every way to anything else.
> It's that kind of arrogance that helped kill it. But since it's dead,
> I guess there's no reason to stop now.
It was hardly superior to everything else in every conceivable way,
but it *was* superior for developing Lisp applications for LispMs.
Arrogance doesn't kill companies (or M$ would be long gone by now),
lack of customers does.
From: Doug Quale
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <87smst9i39.fsf@charter.net>
Joe Marshall <···@ccs.neu.edu> writes:
> > > > ······@dtpq.com (Christopher C. Stacy) writes:
> > > >
> > > > > Linux in no way compares favorably with the Lisp Machine's
> > > > > development environment.
> > >
> It was hardly superior to everything else in every conceivable way,
> but it *was* superior for developing Lisp applications for LispMs.
> Arrogance doesn't kill companies (or M$ would be long gone by now),
> lack of customers does.
The original comment I responded to was
"Linux in no way compares favorably with the Lisp Machine's
development environment."
That statement is bullshit. You might charitably consider it puffery.
Doug Quale <······@charter.net> writes:
> Joe Marshall <···@ccs.neu.edu> writes:
>
> > > > > ······@dtpq.com (Christopher C. Stacy) writes:
> > > > >
> > > > > > Linux in no way compares favorably with the Lisp Machine's
> > > > > > development environment.
> > > >
> > It was hardly superior to everything else in every conceivable way,
> > but it *was* superior for developing Lisp applications for LispMs.
> > Arrogance doesn't kill companies (or M$ would be long gone by now),
> > lack of customers does.
>
> The original comment I responded to was
>
> "Linux in no way compares favorably with the Lisp Machine's
> development environment."
>
> That statement is bullshit. You might charitably consider it puffery.
Did you use a Lisp Machine?
I have to say I don't find the quoted statement far from truth.
I've not been following this thread so have only this message as context.
From: Doug Quale
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <87brzh9fdu.fsf@charter.net>
Kent M Pitman <······@world.std.com> writes:
> Did you use a Lisp Machine?
>
> I have to say I don't find the quoted statement far from truth.
> I've not been following this thread so have only this message as context.
Only a little classroom experience with the Xerox Dolphin, which of
course doesn't qualify as a Lisp Machine (TM). I think I would have
enjoyed using a Symbolics, but I never had that pleasure.
Today I am happy that I have a comfortable environment that is
inexpensive enough for home non-business use. I don't see how the
Lisp Machine could fill that role as well.
I don't have any problem believing the Lisp Machine was the preeminent
single user workstation environment, surpassing in that area all
current popular systems. That's not the same as being a superior
environment in all cases for all applications, which was the original
claim.
From: Joe Marshall
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <ptnx82ey.fsf@ccs.neu.edu>
Doug Quale <······@charter.net> writes:
> Joe Marshall <···@ccs.neu.edu> writes:
>
> > > > > ······@dtpq.com (Christopher C. Stacy) writes:
> > > > >
> > > > > > Linux in no way compares favorably with the Lisp Machine's
> > > > > > development environment.
> > > >
> > It was hardly superior to everything else in every conceivable way,
> > but it *was* superior for developing Lisp applications for LispMs.
> > Arrogance doesn't kill companies (or M$ would be long gone by now),
> > lack of customers does.
>
> The original comment I responded to was
>
> "Linux in no way compares favorably with the Lisp Machine's
> development environment."
>
> That statement is bullshit. You might charitably consider it puffery.
I consider it at most `mild hyperbole'. Linux certainly has LispMs
beat on price, performance, availability, and cost of ownership.
But if you want to compare the `development environment' the statement
is hardly bullshit. Since I haven't used the C development
environment on a LispM, I'm willing to give you the benefit of the
doubt on that, but since the LispM was never intended to be a C
development platform it hardly seems interesting to compare them on
those grounds. (Perhaps we should compare how well LispMs and Linux
compare for developing Algol 60 on a Unisys machine)
From: Doug Quale
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <87k7e59h0k.fsf@charter.net>
Joe Marshall <···@ccs.neu.edu> writes:
> > Doug Quale <······@charter.net> writes:
> >
> > Just how many static languages are supported on a Lisp machine?
>
> True, programming a LispM in a language not supported by a LispM is
> probably as painful as programming in a language supported by Unix,
> but there is no development environment on Unix for any language that
> compares with the Lisp development environment on a Lisp machine.
That's just silly. "Probably as painful"? The first step is to write
an interpreter or compiler on the Lisp Machine for the unsupported
language before you can start work on the program itself, and that's
"probably as painful". Sheesh.
> > Something like Linux itself could never have happened on the Lisp
> > Machine.
>
> Of course not. Why would anyone want to cripple a LispM in such a
> way?
You don't have to cripple the Lisp Machine. You might want to write
something that runs on commodity hardware. Oh wait -- Lisp Machine
fans don't care about commodity hardware. RIP.
From: Joe Marshall
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <k7e5820b.fsf@ccs.neu.edu>
> Joe Marshall <···@ccs.neu.edu> writes:
> >
> > True, programming a LispM in a language not supported by a LispM is
> > probably as painful as programming in a language supported by Unix,
Doug Quale <······@charter.net> writes:
>
> That's just silly. "Probably as painful"? The first step is to write
> an interpreter or compiler on the Lisp Machine for the unsupported
> language before you can start work on the program itself, and that's
> "probably as painful". Sheesh.
Obviously you haven't used a LispM or you would be aware that you
would *not* have to write an interpreter or compiler before starting
work on the program itself. Nor would you consider writing an
interpreter or a compiler particularly onerous.
From: Doug Quale
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <87fzot9g7s.fsf@charter.net>
Joe Marshall <···@ccs.neu.edu> writes:
> > Joe Marshall <···@ccs.neu.edu> writes:
> > >
> > > True, programming a LispM in a language not supported by a LispM is
> > > probably as painful as programming in a language supported by Unix,
>
> Doug Quale <······@charter.net> writes:
> >
> > That's just silly. "Probably as painful"? The first step is to write
> > an interpreter or compiler on the Lisp Machine for the unsupported
> > language before you can start work on the program itself, and that's
> > "probably as painful". Sheesh.
>
> Obviously you haven't used a LispM or you would be aware that you
> would *not* have to write an interpreter or compiler before starting
> work on the program itself. Nor would you consider writing an
> interpreter or a compiler particularly onerous.
If you have to begin by trying to build your own Haskell environment
to match (or surpass, if you are ambitious) the ghc compiler, you are
lost before you have started. There's a tremendous value in building
on the work of others, and the scarcity of the Lisp Machine works
against it here.
Doug Quale <······@charter.net> writes:
> > > Something like Linux itself could never have happened on the Lisp
> > > Machine.
> >
> > Of course not. Why would anyone want to cripple a LispM in such a
> > way?
>
> You don't have to cripple the Lisp Machine. You might want to write
> something that runs on commodity hardware. Oh wait -- Lisp Machine
> fans don't care about commodity hardware. RIP.
This is false, btw. The hardware provides a specific set of handy
services that many of us miss, but in general there is nothing about
the operating system that couldn't happen on stock hardware. It was
most efficient organizationally to produce an emulator, which is why
we chose to do that with OpenGenera, but it wasn't the only way to go.
Moreover, many both inside of Symbolics and in its community felt the
true value of the lispm community was in its software, not its hardware.
It was hotly debated. But certainly there are _many_ who cared really
quite a lot about commodity hardware. Remarks like yours here are
either made in ignorance or out of deliberate attempt to provoke.
I'm getting tired of responding to such baiting and will soon stop.
But there were tons of misstatements here that I felt would benefit
from reply--not for your sake, but for the sake of others reading.
Joe Marshall <···@ccs.neu.edu> writes:
> True, programming a LispM in a language not supported by a LispM is
> probably as painful as programming in a language supported by Unix,
> but there is no development environment on Unix for any language that
> compares with the Lisp development environment on a Lisp machine.
Actually, the debugger for the non-Lisp languages on the LispM was WAY
better than the Lisp debugger due to accidents of fate. It showed source
code in a very nicely integrated way and made it easy to see what the
matter was... Lisp took years and years later to come into its own on
"source code locators" and even then was not as pretty.
"Doug Quale" <······@charter.net> wrote in message
···················@charter.net...
> It would be interesting to see a project like the Gimp developed on
> the Lisp Machine. The development environment would be nice, but
> you'd never have much of a user or developer community because almost
> no one could run it. The hardware is too expensive, scarce and slow.
Hardware that is expensive, scarce, and slow TODAY will not remain so
forever.
You are apparently far too young to remember when the state of the art in
personal computers was a 4 MHz Zilog Z80 8-bit processor, with a 64K address
space, and dual floppy disk drives, running CP/M. That machine would cost
you about $3000.
You are apparently far too young to remember when the state of the art in
SUPERCOMPUTING was the Control Data 6600, which had a 10 MHz processor,
131072 60-bit words of core memory (and up to 1 or 2 million words of
extended core storage, essentially an electronic disk: you couldn't execute
code directly from it). That machine had a BASE price of $6,000,000. The
installation at UT Austin cost more like $30,000,000.
You are apparently far too young to remember when Richard Stallman started
the GNU project. At that time, he was designing software for a 32-bit
machine with a MINIMUM of 1 Mb RAM, and I don't remember how big a hard
drive. At the time, that was a very pricey engineering workstation, or a
fair-sized minicomputer to midicomputer. It was NOT a personal computer by
any stretch of the imagination.
Observe that Linux would NOT have become successful without the huge GNU
software library to draw upon for applications.
Do I have your attention yet?
Perhaps an example from another domain would be more suitable.
In the mid-1980s, a company called New England Digital sold a synthesizer
called the Synclavier. Base price on the Synclavier was $20,000. For that
you got an 8-voice additive synthesis machine, that was really not very much
to write home about. To get the Synclavier up to something interesting, you
had to spend more like $70,000, to load it out to about 24 voices, and to
add the sampling and resynthesis options. Fully loaded, with all the
options max'ed out, you were looking at a cool quarter of a million dollars.
Michael Jackson bought a fully-loaded, max'ed out Synclavier. Oh, and they
were built to order: you paid your money and you waited.
Today, scarcely fifteen years later, you can buy a machine, from any of
several manufacturers, that is just about equivalent to Michael Jackson's
Synclavier, for about $3000. That's about 80-1 price compression, in less
than two decades. And you can walk into just about any music store in the
country, today, lay your money down, today, and walk out with your new axe,
today.
Oh, and note that you can WALK out with it. A fully-loaded Synclavier was
NOT portable. You installed it in a studio and it STAYED in that studio.
Computing hardware gets cheaper and faster and more powerful faster than
just about everything else out there. Go look at some of the retrocomputing
archives around the Web to see where the state of the art was a few decades
ago. I'll give you one data point: the IBM 360/40 was the backbone of
corporate data processing in the 1960s. It was approximately equivalent to
an IBM PC/XT of the 1980s: 16-bit data bus, 256 kBytes of RAM, a few megs of
hard drive.
Texas Instruments built a LISP machine chip, and marketed for a while a
board that plugged into an Apple Mac II, that basically turned the Mac II
into a Lisp Machine, full power. As I recall, they sold the board, with
software, for about $5000, and you had to supply your own Mac II. The price
on that was only going to come down. Sooner or later, someone would have
put that chip, or an equivalent, on an ISA card, or maybe an EISA card, or a
PCI card. Maybe it would have been TI, maybe someone else. The point is
that the price was not going to stay high forever.
From: Andreas Eder
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <m3istoj2qq.fsf@elgin.eder.de>
"John R. Strohm" <······@airmail.net> writes:
> Texas Instruments built a LISP machine chip, and marketed for a while a
> board that plugged into an Apple Mac II, that basically turned the Mac II
> into a Lisp Machine, full power. As I recall, they sold the board, with
> software, for about $5000, and you had to supply your own Mac II. The price
> on that was only going to come down. Sooner or later, someone would have
> put that chip, or an equivalent, on an ISA card, or maybe an EISA card, or a
> PCI card.
I wish someone would do it!
'Andreas
--
Wherever I lay my .emacs, there�s my $HOME.
"Andreas Eder" <············@t-online.de> wrote in message
···················@elgin.eder.de...
> "John R. Strohm" <······@airmail.net> writes:
>
> > Texas Instruments built a LISP machine chip, and marketed for a while a
> > board that plugged into an Apple Mac II, that basically turned the Mac
II
> > into a Lisp Machine, full power. As I recall, they sold the board, with
> > software, for about $5000, and you had to supply your own Mac II. The
price
> > on that was only going to come down. Sooner or later, someone would
have
> > put that chip, or an equivalent, on an ISA card, or maybe an EISA card,
or a
> > PCI card.
>
> I wish someone would do it!
Well, ya know, the old Scheme-on-a-chip paper from the MIT AI Lab is still
available from the AI Lab FTP server. That'd give you some logic to start
with.
Chuck Moore has been doing some fairly incredible things in processor design
lately, including some really impressive IC CAD stuff that he keeps fairly
closely-held. Computers capable of doing IC design work are getting DIRT
CHEAP these days. RAM is incredibly cheap, so are disk drives, so are video
cards and monitors and mice and keyboards.
It probably wouldn't be that hard for someone who was sufficiently crazy and
out-there to design a state-of-the-art LISP chip, that could be fabbed in a
relatively cheap process, that would eat Pentiums for breakfast without
salt.
From: Joe Marshall
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <3ckrztat.fsf@ccs.neu.edu>
"John R. Strohm" <······@airmail.net> writes:
> It probably wouldn't be that hard for someone who was sufficiently
> crazy and out-there to design a state-of-the-art LISP chip, that
> could be fabbed in a relatively cheap process, that would eat
> Pentiums for breakfast without salt.
Probably.
There are those in this group that disagree with me, but I think that
microprocessor *designed* for Lisp could outperform a Pentium by at
least a factor of ten. But only for a little while. A Pentium (or
whatever it would be called) built five years from now would be
competitive with a Lisp chip built today, so even though you are not
in the same market, you still compete with Intel.
Unfortunately, performance doesn't sell computers (ask Digital
Equipment about their Alpha).
I think that I am sufficiently crazy, but for better or worse, I'm not
sufficiently wealthy.
From: Christopher C. Stacy
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <uu1d9qcbh.fsf@dtpq.com>
>>>>> On 08 Apr 2003 00:39:16 -0500, Doug Quale ("Doug") writes:
Doug> Just how many static languages are supported on a Lisp machine?
The LispM was considered to be the very best development environment
available (and would still be if compared today) for FORTRAN and ADA,
It C (which was used to port the X Window System), and PASCAL.
There were also the dynamic languages: Lisp (several dialects),
PROLOG, and MACSYMA. Those are the languages I remember off the top
of my head that were actual products, but I've probably forgotten some;
this is certainly not the complete list of what was available.
Doug> Even C and Fortran are better on Linux than on a Lisp machine
Doug> for most applications. All the creature comforts in the world
Doug> don't make up for the lack of useful libraries and slow hardware.
Doug> If you're developing software to run on IBM Z/OS hardware,
Doug> Linux would be an infinitely better bet than a Lisp machine.
I wouldn't say that, and neither would people who did that at
the time, including some who (still today) program Z/80s.
You have a lot of strong opinions about this system that you've
never seen and don't know anything about, and you seem to enjoy
posting inflammatory misinformation.
Seeing as how you're obviously just a troll, this is the end
of your participation in the newsgroup as far I'm concerned.
But I guess I'll post this message anyway since it includes
a few facts some other people might actually be interested in.
From: Florian Weimer
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <87znmykvf2.fsf@deneb.enyo.de>
······@dtpq.com (Christopher C. Stacy) writes:
> The LispM was considered to be the very best development environment
> available (and would still be if compared today) for FORTRAN and ADA,
It's spelled "Ada", and it isn't part of the Ada folklore I know...
From: Christopher C. Stacy
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <uu1d5kbuj.fsf@dtpq.com>
>>>>> On Thu, 10 Apr 2003 21:24:33 +0200, Florian Weimer ("Florian") writes:
Florian> ······@dtpq.com (Christopher C. Stacy) writes:
>> The LispM was considered to be the very best development environment
>> available (and would still be if compared today) for FORTRAN and ADA,
Florian> It's spelled "Ada", and it isn't part of the Ada folklore I know...
Your rebuttal is that you don't know everything?
From: Florian Weimer
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <877ka1qxn7.fsf@deneb.enyo.de>
······@dtpq.com (Christopher C. Stacy) writes:
>>>>>> On Thu, 10 Apr 2003 21:24:33 +0200, Florian Weimer ("Florian") writes:
>
> Florian> ······@dtpq.com (Christopher C. Stacy) writes:
> >> The LispM was considered to be the very best development environment
> >> available (and would still be if compared today) for FORTRAN and ADA,
>
> Florian> It's spelled "Ada", and it isn't part of the Ada folklore I know...
>
> Your rebuttal is that you don't know everything?
I supposed even I would have heard of the finest Ada development
environment ever.
From: Joe Marshall
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <7ka59jwx.fsf@ccs.neu.edu>
Daniel Barlow <···@telent.net> writes:
> ... while in an adjacent thread people are praising the Lispm for the
> ease with which the developer can get distracted from whatever he's
> supposed to be working on and end up fixing bugs in his networking stack
> (for which he presumably isn't being paid by Symbolics) or spending
> several hours impressing the neophyte user who's just trashed his
> world by setting T to NIL, instead of doing the obvious thing and just
> rebooting the box. I wonder who was accounting for that time.
The examples are given by way of illustration, not as documentation of
a typical work day at a LispM company. The point was that with no
boundary between `kernel space' and `user space' the developer was
able to easily accomplish things that are quite difficult on a
`standard' OS --- things such as shared libraries, user-level device
drivers, distributed networked address spaces, etc.
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
> The point was that with no
> boundary between `kernel space' and `user space' the developer was
> able to easily accomplish things that are quite difficult on a
> `standard' OS --- things such as shared libraries, user-level device
> drivers, distributed networked address spaces, etc.
And, presumably, crashing the OS.
E.
--
The opinions expressed here are my own and do not necessarily
reflect the views of JPL or NASA.
From: Joe Marshall
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <el4czon5.fsf@ccs.neu.edu>
···@jpl.nasa.gov (Erann Gat) writes:
> In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
>
> > The point was that with no
> > boundary between `kernel space' and `user space' the developer was
> > able to easily accomplish things that are quite difficult on a
> > `standard' OS --- things such as shared libraries, user-level device
> > drivers, distributed networked address spaces, etc.
>
> And, presumably, crashing the OS.
Sure.
But that was rarer than you'd think. Things like buffer overflows or
dereferencing null pointers were trapped by the hardware. You really
couldn't call AREF on something that wasn't an array or send a message
to something that wasn't an instance of a flavor. So an erring
program was very unlikely to call an appropriately typed series of
accessors and mutators on structures it wasn't designed for and end up
trashing them. Especially if the data structures in question were in
a separate package.
From: Bulent Murtezaoglu
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <874r5ab49m.fsf@acm.org>
>>>>> "TimB" == Tim Bradshaw <···@cley.com> writes:
[...]
TimB> ... Linux tells us just how little
TimB> free software will actually change, and how tragically
TimB> uncreative the OSS movement is. ...
Hmm, dunno. I take your point about Linux, but how do we measure
creativity? Surely not another Unix, I agree, but what? Is there
anything you'd consider creative (non-OSS obviously) that came out
within the past 10 years or so? (post web let's say so we don't
argue about WWW). I might be missing something obvious here. What
is it?
cheers,
BM
From: Tim Bradshaw
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <ey3of3ml9wi.fsf@cley.com>
* Daniel Barlow wrote:
> Despite being a fully paid-up[*] member of the Linux cult, I think I
> must have missed this propaganda. Who's saying Sun is going away?
> You didn't get suckered into reading slashdot or something, did you?
The Sun newsgroups are full of endless tirades by people explaining
how much better Linux is than Solaris & how Sun are therefore doomed,
& blah blah. It's almost as tedious as the `let's write a Lisp OS /
revive the LispM / GPL everything' crap that is infesting cll
recently, if not quite as stupid - Sun *have* really fouled up their
story about Linux, even given it being a much harder thing to spin for
them than it is for, say, IBM who aren't seen as having a big
investment in a `competing' system; and they've made and are making a
number of other annoying mistakes.
> [*] it was Free to join ...
But you just know you'll end up buried in a pit with all the other
cult members somewhere when it all goes bad... If not cut down by
some deranged loony from Edinburgh with *way* too many kalashnikovs
and a fridge full of biological weapons when he finally loses patience
with the endless pseudo-religious maunderings of the `free software'
brainwashed.
--tim. That's not a biological weapon, that's yoghurt i think anyway
the vx is in the green pots don't mix it with the milk damn
where are my pain pills.
"OCID" <······@purdue.edu> writes:
> Just fyi, Smalltalk _does_ compile to bytecode and has app servers as well.
Or to native machine code.
> I am guessing that most of today's Smalltalk commercial IDE's have
> the ability to generate Java bytecode
No.
> and will probably have comparable performance.
Yes. Or better. Anyway, performance of the application is rarely the
problem today. The bottleneck is the performance of the programmer.
From: Joe Marshall
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <1y0kd4yk.fsf@ccs.neu.edu>
·······@stsci.edu (John M. Adams) writes:
> I recently chaired a committee tasked with evaluating programming
> languages for our planning and scheduling systems. Most of what we
> have now is Lisp.
>
> Our report might be of interest to others. The arguments have not
> received too much critical review. I would appreciate any comments.
> The report is not structured for an external audience and includes
> some peculiar content owing to the document's history within the
> organization. At some point, I would like to rework the relevant
> portions for a more general audience.
After reading the papers I have to ask why this sort of evaluation was
done in the first place. What is the problem that is being addressed?
One *might* think it had something to do with scheduling time for
using the space telescope, but the criteria for evaluation seem to
belie this. The paper states that the analysis considers technical
language features, technology trends, and business factors such as
staffing costs and customer attitudes. In addition, judgements about
language power, maturity, market share, stability, and vendor
independence are included. Finally, the fact that there is an
existing code base was specifically ignored!
One paper stated `The non-technical features of Java outweigh any
technical limitations of Java' and `CL does not fit into the ESS
culture'. This author is more concerned with the amount of time he
spends justifying Lisp than he is with the issue of actually having a
body of working code.
Does your organization have an interest in pointing a telescope, or is
it more interested in `popular, trendy software' that a lot of people
like? If your goal is the former, use lisp! *Every paper* says that
it is technically superior. People who object on the grounds of lack
of popularity should clearly advocate using Visual Basic. It is an
order of magnitude more popular.
Joe Marshall <···@ccs.neu.edu> writes:
> ·······@stsci.edu (John M. Adams) writes:
>
> > I recently chaired a committee tasked with evaluating programming
> > languages for our planning and scheduling systems. Most of what we
> > have now is Lisp.
> >
> > Our report might be of interest to others. The arguments have not
> > received too much critical review. I would appreciate any comments.
> > The report is not structured for an external audience and includes
> > some peculiar content owing to the document's history within the
> > organization. At some point, I would like to rework the relevant
> > portions for a more general audience.
>
> After reading the papers I have to ask why this sort of evaluation
> was done in the first place. What is the problem that is being
> addressed?
We are going to have another space telescope after Hubble, a
completely different observatory. It will have an L2 orbit instead of
a low-earth orbit like Hubble. The scheduling constraints are
different for the L2 case. For example there is no earth occultation.
In addition, we think we have learned something over the past twenty
years about operating a space-based observatory. The onboard flight
operations will be simplified of themselves and in their relationship
to the ground system. Because of the many differences, it is not
immediately obvious that continuing with what we have now is better
than writing something new.
If the possibility of writing something new is admitted, then the
question of what language to use arises. Since programming languages
are not well understood except by programmers, since non-programmers
are involved in our work, and because even among programmers, Lisp is
not widely understood, the question cannot be settled trivially.
I agreed to lead the work because it gave me a chance to study my
belief that Lisp was better than the alternatives. It also gave me
the chance to state why I believe that in detailed terms.
> Finally, the fact that there is an existing code base was
> specifically ignored!
The report you read represents only a fraction of the work ongoing to
determine our course. As noted in the report, the existing codebase
is important but is considered elsewhere. We were evaluating
languages as languages.
Also, recall that I said that the report is not structured for an
external audience. That's a polite way of saying that you don't have
all of the facts needed to make an informed interpretation of how the
text relates to our business.
> One paper stated `The non-technical features of Java outweigh any
> technical limitations of Java' and `CL does not fit into the ESS
> culture'. This author is more concerned with the amount of time he
> spends justifying Lisp than he is with the issue of actually having a
> body of working code.
>
> Does your organization have an interest in pointing a telescope, or is
> it more interested in `popular, trendy software' that a lot of people
> like? If your goal is the former, use lisp! *Every paper* says that
> it is technically superior. People who object on the grounds of lack
> of popularity should clearly advocate using Visual Basic. It is an
> order of magnitude more popular.
<mops brow>
Articles 4,5,6, are what I have called `peculiar content'. The
precise meaning of the term I leave to your interpretation, gentle
reader.
--
John Michael Adams
On 02 Apr 2003 17:04:57 -0500, ·······@stsci.edu (John M. Adams)
wrote:
>Also, recall that I said that the report is not structured for an
>external audience. That's a polite way of saying that you don't have
>all of the facts needed to make an informed interpretation of how the
>text relates to our business.
By external audience do you mean like the guy that takes over for the
head honcho six months from now.
Like I used to tell my students when they showed me an assignment and
said "What I meant to say...", "Then why didn't you say it?"
--------------------------------------------------
Thaddeus L. Olczyk, PhD
Think twice, code once.
Joe Marshall <···@ccs.neu.edu> writes:
> After reading the papers I have to ask why this sort of evaluation was
> done in the first place. What is the problem that is being addressed?
CYA.
Any questioning of the use of CL can now be answered by pointing to
a 90 pages long "evaluation report".
From: Nils Goesche
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <87smt06du8.fsf@darkstar.cartan>
·······@stsci.edu (John M. Adams) writes:
> I recently chaired a committee tasked with evaluating
> programming languages for our planning and scheduling systems.
> Most of what we have now is Lisp.
>
> Our report might be of interest to others. The arguments have
> not received too much critical review. I would appreciate any
> comments. The report is not structured for an external
> audience and includes some peculiar content owing to the
> document's history within the organization. At some point, I
> would like to rework the relevant portions for a more general
> audience.
>
> http://www.ess.stsci.edu/psdb/spike/spike-wg/psflang-report.pdf
Wonderful text, thanks. One thing surprised me: Is it so clear
that there is no multi-platform GUI kit for Lisp? What about
LispWorks' CAPI, for instance? (ACL has something similar, I
guess) It's been about two years since I last used Java's Swing
API (on Linux), but I remember it as being incredibly slow and
bloated, butt-ugly, buggy and not very powerful (few widgets).
CAPI would certainly be /much/ better than that (and it uses
native widgets on Windows and Linux/Unix (where it uses Motif)).
Ok, I don't know just how cross-platform it has to be -- Java
certainly runs on more systems. But that's about the only
advantage I can think of.
Regards,
--
Nils G�sche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xD26EF2A0
Nils Goesche <···@cartan.de> writes:
> ·······@stsci.edu (John M. Adams) writes:
>
> > I recently chaired a committee tasked with evaluating
> > programming languages for our planning and scheduling systems.
> > Most of what we have now is Lisp.
> >
> > Our report might be of interest to others. The arguments have
> > not received too much critical review. I would appreciate any
> > comments. The report is not structured for an external
> > audience and includes some peculiar content owing to the
> > document's history within the organization. At some point, I
> > would like to rework the relevant portions for a more general
> > audience.
> >
> > http://www.ess.stsci.edu/psdb/spike/spike-wg/psflang-report.pdf
>
> Wonderful text, thanks. One thing surprised me: Is it so clear
> that there is no multi-platform GUI kit for Lisp? What about
> LispWorks' CAPI, for instance? (ACL has something similar, I
> guess) It's been about two years since I last used Java's Swing
> API (on Linux), but I remember it as being incredibly slow and
> bloated, butt-ugly, buggy and not very powerful (few widgets).
> CAPI would certainly be /much/ better than that (and it uses
> native widgets on Windows and Linux/Unix (where it uses Motif)).
> Ok, I don't know just how cross-platform it has to be -- Java
> certainly runs on more systems. But that's about the only
> advantage I can think of.
Well, you are right, there are Lisp possibilities. Can I use CAPI
with ACL? ACL has something that seems nice for windows and have
recently shipped some GTK bindings. But, all things considered, Swing
looks like the best bet to me right now, much as I'd prefer to use
Lisp. This is an aspect of technology where going with the weight of
the masses makes sense to me. Widgets are a commodity. We understand
what they are supposed to do.
> Ask not for whom the <CONTROL-G> tolls.
It always brightens my day to read that. It's funny.
--
John Michael Adams
In article <···············@anarky.stsci.edu>,
·······@stsci.edu (John M. Adams) wrote:
> But, all things considered, Swing
> looks like the best bet to me right now, much as I'd prefer to use
> Lisp. This is an aspect of technology where going with the weight of
> the masses makes sense to me. Widgets are a commodity. We understand
> what they are supposed to do.
Swing is known to have several problems, including:
+ Everything is implemented in Java, Swing doesn't make use of the
capabilities of the host operating system.
+ For several reasons, Swing is extremely slow.
+ AFAIK, they still haven't fixed the problems with serialization, but I
am not sure about that. (The format isn't compatible across different
platforms.)
+ Parts of Swing are badly designed. For example, they "simplified" the
MVC patterns and introduced some drawbacks along the way. On the other
hand, it's overly complicated in order to allow for some useless demo
features, like switching the look&feel at runtime - who needs that? (As
Erich Gamma put it: It's a good idea to introduce patterns into your
software, but not all of them at once.)
I don't remember all the details, but it is generally acknowledged in
the Java community that Swing was a bad idea. For this reason, the
Eclipse IDE comes with its own GUI API that seems to be much better.
I am sorry that I don't have any links at hand, but you should do some
further research on this topic and choose something better.
Pascal
--
"If I could explain it, I wouldn't be able to do it."
A.M.McKenzie
Pascal Costanza <········@web.de> writes:
> I don't remember all the details, but it is generally acknowledged in
> the Java community that Swing was a bad idea. For this reason, the
> Eclipse IDE comes with its own GUI API that seems to be much better.
I disagree with your assessment of the general acknowledgement. I
believe the consensus I observe in comp.lang.java.programmer, for
instance, is more along the lines of "There are tricky issues in
Swing" and "there are some problems with Swing". There is a large
group that believes SWT (which IBM developed for Eclipse) is better,
certainly. But I don't think it's as large as you're making it out to
be.
--
If you want divine justice, die.
-- Nick Seldon
Brian Palmer wrote:
> Pascal Costanza <········@web.de> writes:
>
>
>>I don't remember all the details, but it is generally acknowledged in
>>the Java community that Swing was a bad idea. For this reason, the
>>Eclipse IDE comes with its own GUI API that seems to be much better.
>
>
> I disagree with your assessment of the general acknowledgement. I
> believe the consensus I observe in comp.lang.java.programmer, for
> instance, is more along the lines of "There are tricky issues in
> Swing" and "there are some problems with Swing". There is a large
> group that believes SWT (which IBM developed for Eclipse) is better,
> certainly. But I don't think it's as large as you're making it out to
> be.
OK, you are probably right. But the technological shortcomings of Swing
should definitely be considered.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
·······@stsci.edu (John M. Adams) writes:
> Well, you are right, there are Lisp possibilities. Can I use CAPI
> with ACL? ACL has something that seems nice for windows and have
> recently shipped some GTK bindings. But, all things considered,
> Swing looks like the best bet to me right now, much as I'd prefer to
> use Lisp. This is an aspect of technology where going with the
> weight of the masses makes sense to me. Widgets are a commodity.
> We understand what they are supposed to do.
If you haven't looked at CAPI yet then maybe you should do it now. As
far as I am concerned it's a wonderful cross-platform toolkit which
enables you to re-use your GUI code without any significant porting
efforts. I've just recently finished and delivered a Win32 application
for a customer of mine and just for the fun of it I built the same app
on Linux. It all worked fine except for some minor modifications
regarding font size.
As far as I know (somebody please correct me if I'm wrong) this not
only holds for Linux and Windows but also for the commercial Unix
platforms LispWorks runs on. Plus, you'll soon be able to cater to Mac
OS X as well. And, as others have mentioned already, we're talking
about compiled code which uses native widgets - compare that to
Swing...
No, you can't use CAPI with ACL, it's a Xanalys thing, but note that
Franz as well as Xanalys also offer CLIM which would be another way to
build cross-platform GUIs.
Edi.
From: Kenny Tilton
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <3E8B3D1C.9070903@nyc.rr.com>
Thx for sharing that, I have been looking for the one best answer to Why
Lisp? Thought I was going to have to write one. You have several papers
in there, but it's one PDF, and it is current which also matters in this
fast-moving field.
John M. Adams wrote:
> I recently chaired a committee tasked with evaluating programming
> languages for our planning and scheduling systems. Most of what we
> have now is Lisp.
>
> Our report might be of interest to others. The arguments have not
> received too much critical review. I would appreciate any comments.
> The report is not structured for an external audience and includes
> some peculiar content owing to the document's history within the
> organization. At some point, I would like to rework the relevant
> portions for a more general audience.
>
> http://www.ess.stsci.edu/psdb/spike/spike-wg/psflang-report.pdf
>
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Unfortunately no evaluation of the Smalltalk environments was done.
Judging by the number of commercial vendors (e.g. IBM, Cincom, Object
Arts), multiple Open Source versions (Squeak, GNU) and a probably
larger community (based on the number of Usenet and mailing list
postings) you can get the impression that a possibly superior platform
(for the given task, as always) was excluded.
I'm also not convinced that Swing is "the superior multi-platform GUI
facility". There are a lot of alternatives, e.g. wxWindows, QT, or
GTK. By the way, you can use Swing in a Python application, thanks to
Jython. It's a bit biased to give CL and Python the same score when
you have much more GUI-related libraries available in Python.
Nils Kassube <····@kassube.de> writes:
> Unfortunately no evaluation of the Smalltalk environments was done.
> Judging by the number of commercial vendors (e.g. IBM, Cincom, Object
> Arts), multiple Open Source versions (Squeak, GNU) and a probably
> larger community (based on the number of Usenet and mailing list
> postings) you can get the impression that a possibly superior platform
> (for the given task, as always) was excluded.
Some of us are familiar with Smalltalk. We like it, but not as much
as Lisp. It is impossible to take every attractive fork in the road
in such a study. You have to make some guesses as to which paths are
likely to be the more fruitful according to local constraints. Hey,
at least I used the *word* Smalltalk in the report.
One very cool thing about Smalltalk is that it has a very cohesive
user community--at least that is my impression after witnessing Camp
Smalltalk at OOPSLA 2001.
> I'm also not convinced that Swing is "the superior multi-platform
> GUI facility". There are a lot of alternatives, e.g. wxWindows, QT,
> or GTK. By the way, you can use Swing in a Python application,
> thanks to Jython. It's a bit biased to give CL and Python the same
> score when you have much more GUI-related libraries available in
> Python.
We are not unaware of these alternatives. However, while your
feedback is much appreciated, your criticism of the score is
questionable since you don't really know what the score means. If you
go back and read the report, you will find that the scoring was
engaged in to `develop and probe our perspective'. We simply
presented them as an illustration of a kind of activity we engaged
in---not as a factual assertion about the candidate languages. Maybe
I should state this more clearly or omit them altogether to avoid
confusion.
My current belief is that to get anything like the platform coverage
of Swing, I would have to write my own ffi's. Am I mistaken? I know
that Franz shipped some GTK bindings. Last time I looked they weren't
available for windows.
I'd much rather use Swing from Python. We should think more about
that. Thanks for your comments.
--
John Michael Adams
John M. Adams wrote:
> Hey,
> at least I used the word Smalltalk in the report.
Yeah. You were right about that.
I've had experience with both environments. In my opinion, Lisp is better
for general, non-GUI programming because of macros, multiple return values,
and a more-powerful object model. Plus, if you can hide the GUI behind a
web interface, the GUI issue simplifies, too. OTOH, if you are interfacing
with a database or doing heavy client GUI stuff, Cincom's VisualWorks
provides very convenient, platform-independent ways to do this. I haven't
looked lately at many of the others, so I don't know if this is currently
true of the other Smalltalk implementations - the last time I checked, they
were either single- (or limited-) platform constrained or didn't have very
good database interfaces.
So, if I was doing the front-end for a client-server business system, I'd
use Smalltalk. But for the type of app you're interested in, I'd think
that Lisp's superior modeling and technical capabilities win.
faa
From: Kenny Tilton
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <3E8DD237.8070403@nyc.rr.com>
Frank A. Adrian wrote:
> I've had experience with both environments. In my opinion, Lisp is better
> for general, non-GUI programming
The report likewise concedes the cross-platform GUI "problem". Damn, I
detect a market! (For Cello, of course.)
And STSI programmers will have no problem with cells because they
already use a similar mechanism in COSI.
Hey, I ran into a guy in a bar last night. Manager. exprogrammer. never
heard of Lisp. It was amazing listening to him rag on his Java
developers. Invited him to next week's lispnyk meeting, and I just sent
him this report.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
On 02 Apr 2003 10:45:17 -0500, ·······@stsci.edu (John M. Adams)
wrote:
>I recently chaired a committee tasked with evaluating programming
>languages for our planning and scheduling systems. Most of what we
>have now is Lisp.
>
>Our report might be of interest to others. The arguments have not
>received too much critical review. I would appreciate any comments.
>The report is not structured for an external audience and includes
>some peculiar content owing to the document's history within the
>organization. At some point, I would like to rework the relevant
>portions for a more general audience.
>
>http://www.ess.stsci.edu/psdb/spike/spike-wg/psflang-report.pdf
I haven't read it inside and out, but my general impression...
If you expect to change minds or convince someone who might
be convinced then you will be sorely dissappointed. The paper
looks way too much like your group decided "We want to use Lisp"
ahead of time, then went on to prove your conclusions without
really examining the alternatives.
--------------------------------------------------
Thaddeus L. Olczyk, PhD
Think twice, code once.
On Fri, 04 Apr 2003 07:41:34 GMT, Thaddeus L Olczyk
<······@interaccess.com> wrote:
> On 02 Apr 2003 10:45:17 -0500, ·······@stsci.edu (John M. Adams)
> wrote:
>>http://www.ess.stsci.edu/psdb/spike/spike-wg/psflang-report.pdf
>
> I haven't read it inside and out, but my general impression...
> If you expect to change minds or convince someone who might
> be convinced then you will be sorely dissappointed. The paper
> looks way too much like your group decided "We want to use Lisp"
> ahead of time, then went on to prove your conclusions without
> really examining the alternatives.
You should have at least read to the end. Two of the five people
involved say, in essence, "we should use Java because it's mainstream"
(this isn't quite fair, but close enough). That hardly suggests a
group that had decided to prove they ought to use Lisp.
Thaddeus L Olczyk <······@interaccess.com> writes:
> I haven't read it inside and out, but my general impression... If
> you expect to change minds or convince someone who might be
> convinced then you will be sorely dissappointed. The paper looks way
> too much like your group decided "We want to use Lisp" ahead of
> time, then went on to prove your conclusions without really
> examining the alternatives.
Well, that's not something I like to hear. On the other hand, people
are always making stuff up in their head to suit themselves. It's
important to remember that four of the six members were not Lisp
programmers. All them were willing to concede that Lisp was
technically superior as a programming language, but that the
`mainstream' argument was overriding. If one examines the mainstream
argument in detail, it doesn't hold up in our case. We described the
conditions under which we believe it to hold and explained why we
believe it does not hold in our case.
I think the report can be justly criticized for only explicitly
considering two languages in any depth. (That being said, I know
Python and C++ and others in the group knew C++, Fortran and Smalltalk
so our process of whittling the candidates down to a manageable number
was reasonably well-informed). But that defect stems directly from
the chartered time commitment imposed externally on the group. We
had to scale our efforts to that. One cannot credibly ascribe the
lack of breadth to bias.
In my role as an article writer, my goal was to describe, as best I
could, my reasons for thinking that Lisp is the best for our project.
I try to avoid expectations about what people think or believe--that
usually leads to negative emotions that make people unhappy. I can't
control what other people think or believe, but if they want to think,
at least I can offer cogent material for them to think about.
In my role as chairman, my goal was to write the recommendation that
best fit the known evidence and analysis. I'll say to you the same
thing I would say to anyone else. If there are important arguments or
empirical evidence that we missed and that you think would shed light
on the subject, we want very much to hear them.
--
John Michael Adams
·······@stsci.edu (John M. Adams) writes:
> I recently chaired a committee tasked with evaluating programming
> languages for our planning and scheduling systems. Most of what we
> have now is Lisp.
>
> http://www.ess.stsci.edu/psdb/spike/spike-wg/psflang-report.pdf
To avoid confusion, I should add that one of the Java advocacy
articles was inadvertently omitted in a version of the report
available earlier yesterday. This is Scott Speck's Position. So, if
two people got the article at different times, it is possible that the
earlier retrieval may have been missing this article.
I have also remarked that there were six in our group. One did not
submit an article. That is why there are only five positions.
--
John Michael Adams
On 02 Apr 2003 10:45:17 -0500, ·······@stsci.edu (John M. Adams)
wrote:
>I recently chaired a committee tasked with evaluating programming
>languages for our planning and scheduling systems. Most of what we
>have now is Lisp.
>
>Our report might be of interest to others. The arguments have not
>received too much critical review. I would appreciate any comments.
>The report is not structured for an external audience and includes
>some peculiar content owing to the document's history within the
>organization. At some point, I would like to rework the relevant
>portions for a more general audience.
>
>http://www.ess.stsci.edu/psdb/spike/spike-wg/psflang-report.pdf
Biased towards Lisp and in general "academish". I am doing
scheduling stuff in the industry. Yes, Lisp was the option, but
where are the libraries that would a) provide algorithms that
support scheduling, b) support constraint programming, c) link Lisp
to OR libraries such as Linear Programming. Of course, I need
commercial products with commercial support, but not unfinished and
not supported academic projects.
The answer I got on this group and from Lisp manufacturers was : "do
this yourself". No, thank you, I will not. I don't have to. There is
excellent library for scheduling provided by ILOG (ILOG-Scheduler).
It is tightly integrated with other ILOG tools: constraint solver,
Linear Programming and presentation. There is high-level prototyping
language named OPL. All is in C++, but the last version supports
.NET, what makes it possible to use any language that runs on .NET.
Sorry, guys, maybe Lisp is better, but using ILOG and any language
that can talk to ILOG I don't have to reinvent the wheel.
Finally, there is Prolog, at least 4 commercial implementations with
support for scheduling and constraint programming: SICStus, ECLIPSE,
IF/Prolog and CHIP. I am personally doing scheduling with Prolog.
Simple and efficient.
Maybe in the academia "what is the best language" still does count.
In the industry this what counts is "what libraries are available".
For Lisp - the answer is simple: "NONE. Do this yourself"
A.L.
Andrzej Lewandowski <·············@attglobal.net> writes:
> Biased towards Lisp and in general "academish".
I'm curious to know what you mean by biased. Do you mean that we
ignored important facts or evidence in order to present our individual
preference in a better than deserved light? If so, what did we miss?
If I eat some blueberry pie and then some apple pie and conclude that
I like apple better, is that bias?
From your note, it seems like your major complaint was that we didn't
evaluate 3rd party tools. Actually, we had a separate working group
do that. Its report is separate from mine. I am not sure whether
they evaluated all of the products you mention, but I will follow up
on that. The conclusion was that none of the 3rd party products met
our needs well, meaning that if we used them, significant development
would be necessary to adapt them to our particular application. One
reason is that we use some novel concepts that aren't supported in
these other tools.
My general belief is that planning and scheduling is an area of active
research and that people don't really know how to produce general
toolkits that scale well and transport easily across domain
boundaries. However, I am not an expert in the field.
Also, you used the words academic and academia in your post. Do you
mean that we are lacking practical perspective? I wouldn't agree to
that. We operate a spacecraft here with the help of our software and
have budget pressure like everyone else.
Thanks for your comments.
I am doing
> scheduling stuff in the industry. Yes, Lisp was the option, but
> where are the libraries that would a) provide algorithms that
> support scheduling, b) support constraint programming, c) link Lisp
> to OR libraries such as Linear Programming. Of course, I need
> commercial products with commercial support, but not unfinished and
> not supported academic projects.
>
> The answer I got on this group and from Lisp manufacturers was : "do
> this yourself". No, thank you, I will not. I don't have to. There is
> excellent library for scheduling provided by ILOG (ILOG-Scheduler).
> It is tightly integrated with other ILOG tools: constraint solver,
> Linear Programming and presentation. There is high-level prototyping
> language named OPL. All is in C++, but the last version supports
> .NET, what makes it possible to use any language that runs on .NET.
>
> Sorry, guys, maybe Lisp is better, but using ILOG and any language
> that can talk to ILOG I don't have to reinvent the wheel.
>
> Finally, there is Prolog, at least 4 commercial implementations with
> support for scheduling and constraint programming: SICStus, ECLIPSE,
> IF/Prolog and CHIP. I am personally doing scheduling with Prolog.
> Simple and efficient.
>
> Maybe in the academia "what is the best language" still does count.
> In the industry this what counts is "what libraries are available".
> For Lisp - the answer is simple: "NONE. Do this yourself"
>
> A.L.
>
>
--
John Michael Adams
From: Asha Das
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <b7ekfj$bbt$1@news5.jaring.my>
"John M. Adams" <·······@stsci.edu> wrote in message
····················@anarky.stsci.edu...
> Andrzej Lewandowski <·············@attglobal.net> writes:
>
> > Biased towards Lisp and in general "academish".
> [........]
> My general belief is that planning and scheduling is an area of active
> research and that people don't really know how to produce general
> toolkits that scale well and transport easily across domain
> boundaries. However, I am not an expert in the field.
> [........]
> > Finally, there is Prolog, at least 4 commercial implementations with
> > support for scheduling and constraint programming: SICStus, ECLIPSE,
> > IF/Prolog and CHIP. I am personally doing scheduling with Prolog.
> > Simple and efficient.
> >
> > Maybe in the academia "what is the best language" still does count.
> > In the industry this what counts is "what libraries are available".
> > For Lisp - the answer is simple: "NONE. Do this yourself"
> >
> > A.L.
> >
> >
>
Andrzej,
What John wrote above is so true. A general purpose language with a solver
is so much more suitable for exploring your problem domain. The accurate
modeling of the problem domain IS the problem and the mechanics of
operations research are only a distraction.
If the problem you face is so simple and straightforward that it can be
constructed with an off the shelf solution then you should not bother using
lisp. However, if you don't know what you want to do and you can only find
out by successive approximation then you should reconsider lisp: for
example, you can make a class and then redefine it if you are not happy with
the end-result or switch slots around or use multimethods to segment the
problem domain. You can experiment.
You do need to do some programming to use lisp. With LispWorks you can use
the foreign language interface (FLI) to access DLLs; this may seem very
difficult but it's not. So, you can purchase an inexpensive solver like
LINGO (which has a version with unlimited constraints, unlimited variables
and unlimited integers for US$5,000) and tie the LINGO API into lisp with
the FLI.
It is a lot of work in the beginning to use lisp, but once you're finished,
you're really finished - updating and debugging will literally occupy only
1/2 a day a month.
p.s. Andrzej - Can you recommend a prolog-centric book for constraint
satisfaction and scheduling? Sounds interesting.
On 02 Apr 2003 10:45:17 -0500, ·······@stsci.edu (John M. Adams) wrote:
> I recently chaired a committee tasked with evaluating programming
> languages for our planning and scheduling systems. Most of what we
> have now is Lisp.
>
> Our report might be of interest to others. The arguments have not
> received too much critical review. I would appreciate any comments.
[...]
> http://www.ess.stsci.edu/psdb/spike/spike-wg/psflang-report.pdf
In his position paper, Robert Hawkins writes (section 3.1 "GUI Support" on
page 56):
Although LISP has CLIM for GUI support, its features are fairly behind
the times, non-standard and extremely poorly documented in comparison to
the rest of LISP's features.
Which CLIM features, in particular, are behind the times? Why? Given that
CLIM has a specification, what does he mean by non-standard?
Paolo
--
Paolo Amoroso <·······@mclink.it>
Paolo Amoroso <·······@mclink.it> writes:
> On 02 Apr 2003 10:45:17 -0500, ·······@stsci.edu (John M. Adams) wrote:
>
> > I recently chaired a committee tasked with evaluating programming
> > languages for our planning and scheduling systems. Most of what we
> > have now is Lisp.
> >
> > Our report might be of interest to others. The arguments have not
> > received too much critical review. I would appreciate any comments.
> [...]
> > http://www.ess.stsci.edu/psdb/spike/spike-wg/psflang-report.pdf
>
> In his position paper, Robert Hawkins writes (section 3.1 "GUI Support" on
> page 56):
>
> Although LISP has CLIM for GUI support, its features are fairly behind
> the times, non-standard and extremely poorly documented in comparison to
> the rest of LISP's features.
>
> Which CLIM features, in particular, are behind the times? Why? Given that
> CLIM has a specification, what does he mean by non-standard?
Maybe Scott McKay will chime in on this. He's one of the people who's
thought hardest about this, I think. Meanwhile you might get some hints
by either looking at DUIM (Dylan's User Interface Manager) or by using
Google Groups to search for: duim clim
to find discussion that usually compares both of those.
If you want Scott's older comments particularly, use: swm duim clim
On 05 Apr 2003 11:22:02 -0500, Kent M Pitman <······@world.std.com> wrote:
> Paolo Amoroso <·······@mclink.it> writes:
[...]
> > In his position paper, Robert Hawkins writes (section 3.1 "GUI Support" on
> > page 56):
> >
> > Although LISP has CLIM for GUI support, its features are fairly behind
> > the times, non-standard and extremely poorly documented in comparison to
> > the rest of LISP's features.
> >
> > Which CLIM features, in particular, are behind the times? Why? Given that
> > CLIM has a specification, what does he mean by non-standard?
>
> Maybe Scott McKay will chime in on this. He's one of the people who's
> thought hardest about this, I think. Meanwhile you might get some hints
> by either looking at DUIM (Dylan's User Interface Manager) or by using
I saw Scott's comments on DUIM in the past. I wonder whether the alternate
languages and environments analyzed in the STScI Scheduling & Planning
group report have DUIM's additional features that are missing from CLIM,
and whether such features have been considered in evaluating the GUI
capabilities of the languages under study.
Paolo
--
Paolo Amoroso <·······@mclink.it>
From: Kenny Tilton
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <3E8F226A.7090101@nyc.rr.com>
Paolo Amoroso wrote:
> On 02 Apr 2003 10:45:17 -0500, ·······@stsci.edu (John M. Adams) wrote:
>
>
>>I recently chaired a committee tasked with evaluating programming
>>languages for our planning and scheduling systems. Most of what we
>>have now is Lisp.
>>
>>Our report might be of interest to others. The arguments have not
>>received too much critical review. I would appreciate any comments.
>
> [...]
>
>>http://www.ess.stsci.edu/psdb/spike/spike-wg/psflang-report.pdf
>
>
> In his position paper, Robert Hawkins writes (section 3.1 "GUI Support" on
> page 56):
>
> Although LISP has CLIM for GUI support, its features are fairly behind
> the times, non-standard and extremely poorly documented in comparison to
> the rest of LISP's features.
>
> ... Given that CLIM has a specification, what does he mean by non-standard?
Possibly that vendor implementations vary enough to make actual CLIM
code non-portable between vendors. That's what I have heard, anyway.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Paolo Amoroso <·······@mclink.it> writes:
> In his position paper, Robert Hawkins writes (section 3.1 "GUI Support" on
> page 56):
>
> Although LISP has CLIM for GUI support, its features are fairly behind
> the times, non-standard and extremely poorly documented in comparison to
> the rest of LISP's features.
>
> Which CLIM features, in particular, are behind the times? Why? Given that
> CLIM has a specification, what does he mean by non-standard?
I read that as a comparison with non-Lisp GUIs. Where is the CLIM
support for themable skinned chrome, alpha transparency, 3d rendering,
anti-aliased fonts, etc etc, blah blah? And why do all CLIM apps use
that ugly Courier font so much?
(Disclaimer: I've hacked a little on McCLIM, but never used a
commercial CLIM in anger. I've seen screenshots ...)
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
"Daniel Barlow" <···@telent.net> wrote in message
···················@noetbook.telent.net...
> Paolo Amoroso <·······@mclink.it> writes:
>
> > In his position paper, Robert Hawkins writes (section 3.1 "GUI Support"
on
> > page 56):
> >
> > Although LISP has CLIM for GUI support, its features are fairly behind
> > the times, non-standard and extremely poorly documented in comparison
to
> > the rest of LISP's features.
> >
> > Which CLIM features, in particular, are behind the times? Why? Given
that
> > CLIM has a specification, what does he mean by non-standard?
>
> I read that as a comparison with non-Lisp GUIs. Where is the CLIM
> support for themable skinned chrome, alpha transparency, 3d rendering,
> anti-aliased fonts, etc etc, blah blah? And why do all CLIM apps use
> that ugly Courier font so much?
>
> (Disclaimer: I've hacked a little on McCLIM, but never used a
> commercial CLIM in anger. I've seen screenshots ...)
At Kent's urging, I'll reply to this thread. This is a good message
to reply to.
CLIM *is* behind the times. Nobody has invested in it seriously since
1994 at the latest. Nobody has done a careful redesign of its architecture
to better support modern toolkits. Nobody in the Lisp community has
offered to pay for this work and there are no Lisp companies capable
of pouring hundreds of millions of dollars into it, the way Sun has done
with Java. No Lisp vendors have seen fit to open-source CLIM to
allow individuals to do this work.
When I did DUIM for Dylan, I thought very carefully about many of these
issues (with Andy Armstrong as my right-hand man, to give full credit).
DUIM has a far more modern architecture. I have offered to port the
output record and presentation layer of CLIM to the architecture of DUIM
(I call it "CLIM 2000", to keep it a little behind the time), but since I am
not a dot-com zillionaire, I cannot afford to do it for free. DUIM has
"the right" architecture to scale to new features. For example, the Fun-O
DUIM examples include a DUIM sheet class that transparently supports
(no pun intended) OpenGL. The amount of code beyond the raw FFI
code is negligible. The DUIM sources are open-source.
Oh, and CLIM apps use that ugly font because nobody thinks to pick a
different one. Their bad, not CLIM's.
From: Timothy Moore
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <b6ocln$vaf$0@216.39.145.192>
"Scott McKay" <···@attbi.com> writes:
> "Daniel Barlow" <···@telent.net> wrote in message
> ···················@noetbook.telent.net...
> > Paolo Amoroso <·······@mclink.it> writes:
> >
> > > In his position paper, Robert Hawkins writes (section 3.1 "GUI Support"
> on
> > > page 56):
> > >
> > > Although LISP has CLIM for GUI support, its features are fairly behind
> > > the times, non-standard and extremely poorly documented in comparison
> to
> > > the rest of LISP's features.
> > >
> > > Which CLIM features, in particular, are behind the times? Why? Given
> that
> > > CLIM has a specification, what does he mean by non-standard?
...
> >
> > (Disclaimer: I've hacked a little on McCLIM, but never used a
> > commercial CLIM in anger. I've seen screenshots ...)
>
> At Kent's urging, I'll reply to this thread. This is a good message
> to reply to.
>
> CLIM *is* behind the times. Nobody has invested in it seriously since
> 1994 at the latest. Nobody has done a careful redesign of its architecture
> to better support modern toolkits. Nobody in the Lisp community has
> offered to pay for this work and there are no Lisp companies capable
> of pouring hundreds of millions of dollars into it, the way Sun has done
> with Java. No Lisp vendors have seen fit to open-source CLIM to
> allow individuals to do this work.
Perhaps no one has invested in "real" CLIM for 9 years, but there is
an active band of hackers working on McCLIM. Perhaps it seems a waste
to duplicate the effort that went into real CLIM; if a CLIM had been
freely available, we wouldn't have felt compelled to do it :)
We're wrestling with some of the same "support for modern toolkit"
issues, but we think we've got a handle on it.
> When I did DUIM for Dylan, I thought very carefully about many of these
> issues (with Andy Armstrong as my right-hand man, to give full credit).
> DUIM has a far more modern architecture. I have offered to port the
> output record and presentation layer of CLIM to the architecture of DUIM
> (I call it "CLIM 2000", to keep it a little behind the time), but since I am
> not a dot-com zillionaire, I cannot afford to do it for free. DUIM has
> "the right" architecture to scale to new features. For example, the Fun-O
> DUIM examples include a DUIM sheet class that transparently supports
> (no pun intended) OpenGL. The amount of code beyond the raw FFI
> code is negligible. The DUIM sources are open-source.
Presentations are probably the most "non-standard" thing about CLIM,
but they and their dual, context-dependent input, are totally cool,
better than anything in any other graphics toolkit.
> Oh, and CLIM apps use that ugly font because nobody thinks to pick a
> different one. Their bad, not CLIM's.
Gilbert Baumann's Closure web browser, implemented using (Mc)CLIM,
doesn't have ugly fonts :)
Tim
From: Bulent Murtezaoglu
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <878yuoatoo.fsf@acm.org>
>>>>> "SMcK" == Scott McKay <···@attbi.com> writes:
SMcK> ... I have offered to port the output record and
SMcK> presentation layer of CLIM to the architecture of DUIM (I
SMcK> call it "CLIM 2000", to keep it a little behind the time),
SMcK> but since I am not a dot-com zillionaire, I cannot afford to
SMcK> do it for free. ...
How many man-hours do you think it would take to do this? Say, starting
from McCLIM?
cheers,
BM
"Bulent Murtezaoglu" <··@acm.org> wrote in message
···················@acm.org...
> >>>>> "SMcK" == Scott McKay <···@attbi.com> writes:
> SMcK> ... I have offered to port the output record and
> SMcK> presentation layer of CLIM to the architecture of DUIM (I
> SMcK> call it "CLIM 2000", to keep it a little behind the time),
> SMcK> but since I am not a dot-com zillionaire, I cannot afford to
> SMcK> do it for free. ...
>
> How many man-hours do you think it would take to do this? Say, starting
> from McCLIM?
>
I don't know, since I haven't looked at the guts of McCLIM.
If it were me doing it, I would start with DUIM (converted to Lisp,
of course), then port the stream, command processing, and presentation
layer to it, and add a GTk back-end. This would take me at least
six months, full-time, to get it working well.
On 02 Apr 2003 10:45:17 -0500, ·······@stsci.edu (John M. Adams) wrote:
> I recently chaired a committee tasked with evaluating programming
> languages for our planning and scheduling systems. Most of what we
> have now is Lisp.
>
> Our report might be of interest to others. The arguments have not
> received too much critical review. I would appreciate any comments.
[...]
> http://www.ess.stsci.edu/psdb/spike/spike-wg/psflang-report.pdf
Now that I have read the complete report, I have found a few amusing
statements. The first is in Scott Speck's position paper. On page 64 he
writes:
3) Java has better "safety features" than C++ or Lisp. This includes
garbage collection, to help minimize the effects of memory leaks.
Finding what is amusing is left as an exercise for the reader. The other
statements are in Frank Tanner's position paper. In section 1 "Executive
Summary" on page 66 he writes:
The non-technical features of Java outweigh any technical limitations of
Java.
A few lines below he writes:
Java is a more forward looking, innovative language because of the strong
Java community supporting it.
and incidentally, in section 2 "Notes & Disclaimers", also:
From a strict computer science point of view, CL is the superior
programming language evaluated in this study.
Assuming that most of the Java innovation does not deal with reinventing
Lisp, I wonder what technical innovation is worth if Java's non-technical
features outweigh its technical limitations.
Paolo
--
Paolo Amoroso <·······@mclink.it>
From: Tim Bradshaw
Subject: Re: Report on languages for planning and scheduling
Date:
Message-ID: <ey3znn3loxi.fsf@cley.com>
* Paolo Amoroso wrote:
> writes:
> 3) Java has better "safety features" than C++ or Lisp. This includes
> garbage collection, to help minimize the effects of memory leaks.
I think that Java *does* have better safety features than CL, it's
just that GC isn't one of them (it is a better safety feature than C++
though).
--tim