Lisp# in .NET?
Resty Cena
that Microsoft .NET is a wide-open side-door for Lisp to enter into IS
shops.
Duane Rettig
We at Franz looked at it, and rejected it. The major reasons for
us deciding not to proceed were
1. It would slow our lisp down tremendously. I don't rememeber the
exact estimates, but I would guess and wouldn't be surprised if
the slowdown would have been on the order of 10x.
2. More than a hardware emulation, where the "hardware" provides
primitive functionality and we language vendors are able to use
this functionality however we see fit, .NET is a framework in which
software is constrained to conform. Thus, we would have to change
our calling sequence, object, typing, and gc architectures to
conform to .NET's.
3. The result would be MS specific, and not portable to other systems.
This point is weak, because it is conceivable that .NET will be /
is being ported to other operating systems, but at the time we
looked at it, it had no buy-in from any other operating-system
vendors.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
Kent M Pitman
> rc...@epcor.ca (Resty Cena) writes:
>
> > Is anybody working on a Lisp port to the .NET platform? Seems to me
> > that Microsoft .NET is a wide-open side-door for Lisp to enter into IS
> > shops.
>
> We at Franz looked at it, and rejected it. The major reasons for
> us deciding not to proceed were
>
> 1. It would slow our lisp down tremendously. I don't rememeber the
> exact estimates, but I would guess and wouldn't be surprised if
> the slowdown would have been on the order of 10x.
I wonder if a similar argument was made at Symbolics for not putting Lisp
onto the PC. ;-)
And I wonder also if every other program in the world will run slow on .NET,
such that the relative differences between slowed applications in Lisp
vs slowed applications in other languages will be not so visible.
Or is (2) the underlying reason and do other languages not have to do this?
> 2. More than a hardware emulation, where the "hardware" provides
> primitive functionality and we language vendors are able to use
> this functionality however we see fit, .NET is a framework in which
> software is constrained to conform. Thus, we would have to change
> our calling sequence, object, typing, and gc architectures to
> conform to .NET's.
Obviously a painful, up-front expense. But aren't there other gc'd
languages, etc. And would you then be able to use someone else's gc or
sell them yours? And also, wouldn't the potential market (if .NET succeeds,
I mean) be large. Are you, in effect, saying you think these things
will cause it not to? Or are you instead saying that if it succeeds, it
will be a niche market rather than a replacing market, and you can
afford not to be in it? Or are you saying that you expect it will be
the dominant market but nevertheless feel you shouldn't go into it?
It sounds like a criticism similar to the one made of Java--that it can never
be fast enough to succeed. But Microsoft has surely seen the problems with
Java and I can't believe it's going to replicate all those problems...
> 3. The result would be MS specific, and not portable to other systems.
> This point is weak, because it is conceivable that .NET will be /
> is being ported to other operating systems, but at the time we
> looked at it, it had no buy-in from any other operating-system
> vendors.
Hmmm. To me, this is the only reason you cited that sounds materially
important.
Frode Vatvedt Fjeld
it is the Common Type System, which is a "standard" for meta-data
representation, meaning what objects, functions etc. looks like at
compile- and run-time. The idea is that CTS enables software
components written in different languages to be linked together
seamlessly[1]. Unfortunately, the designers of CTS chose to ignore
Common Lisp with its rich type system, flexible generic functions
etc. My impression is that a CL implementor would have to really bend
over backwards in order to squeeze into the .NET mold. I'm not
convinced this would even be possible while staying reasonably ANSI
compliant.
Perhaps a viable approach would be to view CTS/.NET as a subset of
lisp typing, and implement a .NET (Common Intermediate Language)
compiler that compiles stuff so that it integrates into the lisp
run-time environment, rather than the other way around (i.e. C#
functions becomes compiled native "lisp" functions etc). I haven't
looked into the details, but I have a feeling this might actually work
precisely because of the strict requirements imposed by CTS and
CIL. As a bonus, this would really be true to the "embrace and extend"
formula :-)
BTW one M$ heavy that presented .NET here, informed us that his
favorite language scheme was ported to .NET, for those parenthetically
inclined. He also explained that they had not considered the family of
logic programming languages, because he himself had shown in his PhD
that they are equivalent (or something to that effect) to functional
languages (what this meant I dared not ask).
[1] There are of course certain other side-effects like, M$ getting
control over even more aspects of (3rd-party) software, and the
software environment in general.
--
Frode Vatvedt Fjeld
Duane Rettig
> Duane Rettig <du...@franz.com> writes:
>
> > rc...@epcor.ca (Resty Cena) writes:
> >
> > > Is anybody working on a Lisp port to the .NET platform? Seems to me
> > > that Microsoft .NET is a wide-open side-door for Lisp to enter into IS
> > > shops.
> >
> > We at Franz looked at it, and rejected it. The major reasons for
> > us deciding not to proceed were
> >
> > 1. It would slow our lisp down tremendously. I don't rememeber the
> > exact estimates, but I would guess and wouldn't be surprised if
> > the slowdown would have been on the order of 10x.
>
> I wonder if a similar argument was made at Symbolics for not putting Lisp
> onto the PC. ;-)
Perhaps. And in fact, I can imagine that if I were a developer at
Symbolics at that time, I would have made a similar argument - it
simply would not have made sense. In fact, it took us quite a long time
to get our GP lisp compiler to squeeze down into the register-starved
x86 architecture.
> And I wonder also if every other program in the world will run slow on .NET,
The short answer is that not every other program in the world has to run
on .NET.
Since we were under NDA while this was being looked into, and since now that
it is released the name has changed to something that does not really
describe what it does, I am not sure what people actually know about .NET -
So please excuse me if you already know this. In reality, .NET has little
to do with the internet, except for how it will apparently fit in to their
marketing strtegy. It is in fact a virtual architecture, much like the JVM,
plus a runtime substrate and any programs that support it. It is on top of
this virtual machine that we are simply not interested in trying to port our
lisp.
Now, it is entirely possible, that if .NET succeeds wildly, that we could
develop lisp-to-.net translators, in the same way as it is possible to
generate Java bytecodes from lisp. However, I would no more want to be
doing development sitting on a r-e-p-l running on a .NET VM than I would
on a JVM.
> such that the relative differences between slowed applications in Lisp
> vs slowed applications in other languages will be not so visible.
> Or is (2) the underlying reason and do other languages not have to do this?
>
> > 2. More than a hardware emulation, where the "hardware" provides
> > primitive functionality and we language vendors are able to use
> > this functionality however we see fit, .NET is a framework in which
> > software is constrained to conform. Thus, we would have to change
> > our calling sequence, object, typing, and gc architectures to
> > conform to .NET's.
>
> Obviously a painful, up-front expense. But aren't there other gc'd
> languages, etc. And would you then be able to use someone else's gc or
> sell them yours?
What would they do with our gc? It wouldn't run on their .NET VM,
and its assumptions about what objects look like wouldn't match that
of .NET.
> And also, wouldn't the potential market (if .NET succeeds,
> I mean) be large. Are you, in effect, saying you think these things
> will cause it not to? Or are you instead saying that if it succeeds, it
> will be a niche market rather than a replacing market, and you can
> afford not to be in it?
No, I believe I am saying that we can exist alongside it without
being _in_ it. We do this all the time with other languages and
interfaces, and .NET should not be any different. And although
I suppose it would be possible for MS to develop .NET-only machines,
nevertheless they would have a tough sell to push yet another order
of magnitude of slowness on their customer base.
> Or are you saying that you expect it will be
> the dominant market but nevertheless feel you shouldn't go into it?
Not at all.
> It sounds like a criticism similar to the one made of Java--that it can never
> be fast enough to succeed. But Microsoft has surely seen the problems with
> Java and I can't believe it's going to replicate all those problems...
No comment here :-)
> > 3. The result would be MS specific, and not portable to other systems.
> > This point is weak, because it is conceivable that .NET will be /
> > is being ported to other operating systems, but at the time we
> > looked at it, it had no buy-in from any other operating-system
> > vendors.
>
> Hmmm. To me, this is the only reason you cited that sounds materially
> important.
To be sure, the concept of a virtual machine which could run Lisp was
intriguing, even possibly at the expense of some speed. But when we
looked into it, (and found that they had already set the machine in
concrete with not enough support for a relatively efficient lisp) our
interest cooled significantly.
Duane Rettig
> My impression is that a CL implementor would have to really bend
> over backwards in order to squeeze into the .NET mold. I'm not
> convinced this would even be possible while staying reasonably ANSI
> compliant.
I don't believe that any of us that looked at it had any issue with
the possibility of retaining ANSI compliance. But you're absolutely
right; we would have to bend over backwards to do it!
Rob Warnock
+---------------
| It sounds like a criticism similar to the one made of Java--that it
| can never be fast enough to succeed. But Microsoft has surely seen
| the problems with Java and I can't believe it's going to replicate
| all those problems...
Believe it. Only now *Microsoft* will control the definition of the
VM (which is how they like it), not some indomitable 3rd-party like
Sun, or even worse (*shudder!*), an international standards committee.
-Rob
-----
Rob Warnock, 31-2-510 <rp...@sgi.com>
SGI Network Engineering <http://reality.sgi.com/rpw3/> [until 8/15]
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: aaan...@sgi.com and zedw...@sgi.com aren't for humans ]
Frank A. Adrian
that its primitive arithmetic operators are about the same as a JVM's -
i.e., overflow checking for bignum conversion would make math VERY slow
(although a sufficiently smart compiler with sufficiently detailed
declarations and sufficiently clever type analysis might be able to cope).
The other issue is that .NET's type system is very much in the "attach
methods to classes" school. Implementing variable length arglists would be
pain, too. You'd also end up with one class per generic function or a class
corresponding to a package with a method per function in the package and no
type checking (which would drive C#/VB users NUTS) and a bunch of added
cruft for accessing "normal" objects. Finally, I believe that the .NET VM
doesn't have restartable error frames, which would make implementing cerror
and its ilk relatively painful. In the end, you'd end up with a Lisp
written in a very slow C and with a bunch of compromises that wouldn't be
very muh fun.
faa
"Kent M Pitman" <pit...@world.std.com> wrote in message
news:sfwelsw...@world.std.com...
Geoffrey Summerhayes
"Duane Rettig" <du...@franz.com> wrote in message
news:47kyn9...@beta.franz.com...
How about doing it as an FLI, support calling and creation for
other language objects through .NET but not allow them to do the
same? I can see .NET not supporting CLOS, but CL should be more
than capable of supporting .NET
Geoff
George Neuner
<sNuOmS...@hNoOtSmPAaMil.com> wrote:
>
>How about doing it as an FLI, support calling and creation for
>other language objects through .NET but not allow them to do the
>same? I can see .NET not supporting CLOS, but CL should be more
>than capable of supporting .NET
>
>Geoff
>
I think that would leave Lisp# on a wire without a .NET
In a previous thread, someone (I think it was Kent Pitman) talked
about how, historically, Lisp was viewed as the primary application
language - library modules written using lesser languages were to be
linked to the main Lisp application when [absolutely] necessary.
We may like that idea philosophically, but practically it hurt Lisp
because modules written in Lisp frequently didn't (or couldn't) play
nicely with foreign applications.
Requiring a CIL compiler (extra steps even if transparent), IMO simply
reinforces this idea. Technically, it's a fine idea - I believe it
could work. However, I also believe that there will be a bias against
using .NET languages that require CILs. Regardless of Micro$quish's
assertions to the contrary (be there any), I believe such languages
will be relegated to the periphery and that significant deviation from
the standard CLS will be a detriment to any prospective .NET language.
Looking around at the current state of the M$ desktop world, my
prediction for .NET is that anything not immediately and easily usable
from Visual Basic will not fair well. In other words, not
significantly different from now.
I could be absolutely wrong, but that's how I see it.
George
Mark Watson
Well, I think that one obvious solution is to SOAP enable
your Lisp applications, then just call them as needed
from other .Net stuff. I assume that Lisp would be used
for implementing web services, not client side stuff. SOAP
plays well with Java, Python, Perl, etc., so you are not
limited to Microsoft's .Net (I favor the J2EE platform,
but that is my own bias).
A few months ago, I was trying to get good server
side support going for LispWorks and ALS Prolog, but
I got side tracked on a book project (SOAP, UDDI,
WSDL, etc. using Java).
Anyway, either XML-RPC or SOAP is a nice way to
wrap Lisp and Prolog applications as web services. There
is some real overhead for using XML-RPC or SOAP, but
who cares if it makes it easy to use Prolog and Lisp web
services with other languages.
-Mark
--Mark Watson
--Java consulting, Open Source and Content: www.markwatson.com
Resty Cena
Thank you for your reply. I will definitely explore your suggestion if
I decide to use Lisp.
There is a bit of a political call-to-arms in my posting. There are at
least quote 20 unquote languages being ported to .NET. Lisp does not
appear to be one of those. I see .NET as a venue for a fierce language
free-for-all, where everything else is equalized, or pretty much so,
except language syntax and semantics ("May the best grammar win!"). On
such a level playing field, I see Lisp as taking a fair market share,
precisely because it is a specialist among specialists (Today's
complex requirements require a specialist. There is no room out there
for a plain general practitioner; VB has that cornered). So there are
technical problems. Insurmountable? Pity.
"Mark Watson" <ma...@markwatson.com> wrote in message news:<Ck9W6.4767$Kq4.4...@newsread2.prod.itd.earthlink.net>...
Duane Rettig
> There is a bit of a political call-to-arms in my posting. There are at
> least quote 20 unquote languages being ported to .NET. Lisp does not
> appear to be one of those. I see .NET as a venue for a fierce language
> free-for-all, where everything else is equalized, or pretty much so,
> except language syntax and semantics ("May the best grammar win!"). On
> such a level playing field, I see Lisp as taking a fair market share,
I'd prefer that Common Lispers _not_ get involved with language
free-for-alls. Just as in the press of the crowds at a soccer match,
pain and suffering is usually inflicted in a free-for-all, and with
not much gain, if any. I'd prefer it if lispers devoted most of our
time to getting real work done, instead of trying to win contests for
which is the better language.
In the movie "Braveheart", William Wallace's good buddy Hamish
challenged him to a rock-throwing contest, and Hamish easily won the
contest, because the rock was huge and so was Hamish. But Wallace's
line was something like "Aye, that was good, but how well can you do
when it counts?" Wallace then proceeded to offer himself as a target,
but his friend couldn't control the rock and thus missed him. However,
Wallace then proceeded to knock his friend out with a well-placed
hit on the forhead with a tiny stone he had picked up just beforehand.
Moral: Hamish was the "better man", but William got the upper hand in
the end.
> precisely because it is a specialist among specialists (Today's
> complex requirements require a specialist. There is no room out there
> for a plain general practitioner; VB has that cornered). So there are
> technical problems. Insurmountable? Pity.
No, today's complex requirements require solutions, not specialists.
In this sense, software is the same today as it has always been.
And Lisp allows one to create solutions in a great variety of settings.
I would thus argue that Lisp is _more_ general-purpose than other
languages, not less.
And don't worry that lisp has been perceived as down-and-out by
some. Lisp survives.
Another story: This time it's an old TV show called "Here Come the
Brides". [this show was a pseudo sitcom about loggers in Seattle in
the late 1800s and the ladies that came to become their wives; it
gave some rise to Seattle's popularity long before Microsoft settled
there, and the theme song for the show became popular on radio]
Jeremy, the youngest brother, finally got the chance to work up
his first lumber bid for a secret project in San Francisco. When
they found out that they were one of the two lowest bids, Jeremy went
to SF and met with the customer, who was out to build a sleek new
ship (of wood, of course), and to make a presentation in competition
with the other bidder, a man with a big company in the California
Sierras. The other man was cacky and sure of himself, and put down
Jeremy's company because of their severe winters and fewer trees than
his company had access to in the Sierras, plus the great distance the
Seattle lumber would have to travel. When it came to Jeremy's
turn, he showed the shipbuilder some samples of Seattle wood, and
argued that it was precisely _because_ of the severe winters and
harsh conditions under which only the hardiest of trees survive,
that he could guarantee much higher quality lumber for the whole
project. Jeremy won the contract.
Moral: I would _much_ rather stick with a language that has gone
through harsh winters and survived...
Resty Cena
arrogance, unintended I'm sure, that doomed the Mac OS (and the Mac)
to a niche market when it should be where Windows is now. Any software
company that does not take every opportunity to grab mind and markert
share should be lined up against the wall and splattered with rotten
eggs. John Graham's strategy to keep the Lisp technology away from the
competitors will backfire when you notice that you're the only one
using and improving the tool. FWIW.
Duane Rettig <du...@franz.com> wrote in message news:<4n179y...@beta.franz.com>...
Duane Rettig
> Allow me to say that I sense in your posting exactly the same
> arrogance, unintended I'm sure, that doomed the Mac OS (and the Mac)
> to a niche market when it should be where Windows is now.
Your senses deceive you. It's not arrogance. It _would_ be arrogant
if I were to assume that .NET technology would never become popular,
due to its technical challenges. And technical merit has never been
a guarantee for market share.
There's an interesting discussion going on at slashdot:
http://slashdot.org/article.pl?sid=01/06/21/008216&mode=thread
regarding a rather scathing article written about .NET:
http://iwsun4.infoworld.com/articles/op/xml/01/06/18/010618oppetreley.xml
It will be interesting to see whether .NET succeeds or fails, or falls
somewhere in between.
> Any software
> company that does not take every opportunity to grab mind and markert
> share should be lined up against the wall and splattered with rotten
> eggs.
I was originally going to agree with this, but there is a subtle
disagreement I have with your statement. It is true that every
software company must attempt to maximize its market share. However,
a company is also responsible to minimize the cost of such market
penetration. What that means is, that given two opportunities to
penetrate a market, each presenting the same degree of penetration,
but one expensive and the other inexpensive, the wise choice is to
select the less expensive opportunity. If the company uses more of
its resources to pursue the more expensive opportunity, then it has
less resources to pursue other market-penetration opportunities.
And that comes right back around to your statement about grabbing as
much mind/market share as possible. Such efforts always involve
assessments of opportinity, risk, and expense, and prioritizing
against all three of those qualities.
Perhaps you believe that .NET is the _only_ vehicle to market
penetration, and that it will take over the software industry?
If so, then we disagree.
> John Graham's strategy to keep the Lisp technology away from the
> competitors will backfire when you notice that you're the only one
> using and improving the tool. FWIW.
Sorry, I don't understand this statement. Who is John Graham, and what
is his strategy to keep Lisp technology away from competitors? Lisp
is and has always been available to anyone who wants to use it.
At Franz, we make great efforts to bring Lisp technology _toward_
others - both toward competing lisps (via standards adherence) and
toward other languages (via standard connectivity such as CORBA and
OLE and through foreign-functions interfaces and tools).
Rob Warnock
+---------------
| > John Graham's strategy to keep the Lisp technology away from the
| > competitors will backfire when you notice that you're the only one
| > using and improving the tool. FWIW.
|
| Sorry, I don't understand this statement. Who is John Graham, and
| what is his strategy to keep Lisp technology away from competitors?
It's a garbled reference to Paul Graham's "Beating The Averages" paper
<URL:http://www.paulgraham.com/paulgraham/avg.html>.
Paolo Amoroso
> to a niche market when it should be where Windows is now. Any software
> company that does not take every opportunity to grab mind and markert
> share should be lined up against the wall and splattered with rotten
> eggs. John Graham's strategy to keep the Lisp technology away from the
Wasn't Lucid trying to take every opportunity for grabbing mind and market
share when it entered the growing C++ market?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
a@b.c
>Moral: I would _much_ rather stick with a language that has gone
>through harsh winters and survived...
When a language standard exists, survival of the language is practically
guaranteed, and is therefore meaningless. The Lisp community should be more
concerned about mindshare. If Lisp could become the lingua franca of future
software development, it would be a lot more valuable even to those who
already use it every day. The bigger the market, the more it gets improved
by competition. The more users, the more real-world testing, improving
quality, and the more money available for further development.
Resty Cena
Exactly the point I'm trying to put across.
My reading of Duane Rettig's position (correct me if I misread it) is
that a more fundamental issue in any decision to port CL to the .NET
platform is risk (i.e., profitability). The increased cost (due to
.NET's architecture) of porting an ANSI compliant CLOS to .NET and the
'uncertainty' about the commercial success of .NET put the risk at an
unacceptably high level. While I agree with the driving force (risk),
I don't agree with the analysis that .NET will be less than a stellar
success. As an amateur observer of the industry, I see two things that
are very dear to Mr. Gates heart: Basic and Windows. Relentless
improvements on these products over the years have made them
successes. I see .NET to be added to the list. (Something that was not
considered in the risk assessment is the fact that even if .NET is
successful, Lisp#.NET may not be. But this is where merciless
evangelizing can help.)
As a matter of fact, the risk factor may weigh heavily against Lisp in
my evaluation of Lisp, Smalltalk, and Eiffel for a new programming
environment. Why spend resources learning a development system (for
commercial products) about which, recently in its own forum, the
question of its future (the thread was The Future of Lisp, or some
thing) had one of the highest participations? [Eiffel# has a .NET
port, and I believe that there is a Smalltalk#.NET project. ISE
released today some documentation on the latest Eiffel, and I see very
very good things.]
Duane Rettig
> a@b.c wrote in message news:<b05tjtsafbfomq61e...@4ax.com>...
> > On 15 Jun 2001 18:48:21 -0700, Duane Rettig <du...@franz.com> wrote:
> >
> > >Moral: I would _much_ rather stick with a language that has gone
> > >through harsh winters and survived...
> >
> > When a language standard exists, survival of the language is practically
> > guaranteed, and is therefore meaningless. The Lisp community should be more
> > concerned about mindshare. If Lisp could become the lingua franca of future
> > software development, it would be a lot more valuable even to those who
> > already use it every day. The bigger the market, the more it gets improved
> > by competition. The more users, the more real-world testing, improving
> > quality, and the more money available for further development.
>
> Exactly the point I'm trying to put across.
>
> My reading of Duane Rettig's position (correct me if I misread it) is
> that a more fundamental issue in any decision to port CL to the .NET
> platform is risk (i.e., profitability). The increased cost (due to
> .NET's architecture) of porting an ANSI compliant CLOS to .NET and the
> 'uncertainty' about the commercial success of .NET put the risk at an
> unacceptably high level.
You did not misread my position.
> While I agree with the driving force (risk),
> I don't agree with the analysis that .NET will be less than a stellar
> success.
Who's analysis was that? I never said that. What I do say, is
that I don't know, _and_ that you don't know, either.
> As an amateur observer of the industry, I see two things that
> are very dear to Mr. Gates heart: Basic and Windows. Relentless
> improvements on these products over the years have made them
> successes. I see .NET to be added to the list.
Perhaps yes, perhaps no. I am not sure. But what does that
have to do with the applicability of a lisp vendor putting Lisp
onto .NET?
> (Something that was not
> considered in the risk assessment is the fact that even if .NET is
> successful, Lisp#.NET may not be.
Perhaps you're not reading carefully enough, or perhaps you need to
read between the lines. That is _precisely_ what I am saying.
> But this is where merciless evangelizing can help.)
Merciless evangelizing requires money. Perhaps MS can evangelize .NET
into a good position, or perhaps not. They certainly don't care about
lisp, so they're certainly not going to evangelize it.
> As a matter of fact, the risk factor may weigh heavily against Lisp in
> my evaluation of Lisp, Smalltalk, and Eiffel for a new programming
> environment.
Sounds like the only programming language that will have a risk acceptable
to you is Visual Basic.
> Why spend resources learning a development system (for
> commercial products) about which, recently in its own forum, the
> question of its future (the thread was The Future of Lisp, or some
> thing) had one of the highest participations?
A nonsequitur. The only reason why the Future of Lisp thread was so
popular is because several people like to talk about the future of lisp.
Meanwhile, Lisp plods on, as it has for the last 40 years.
> [Eiffel# has a .NET
> port, and I believe that there is a Smalltalk#.NET project. ISE
> released today some documentation on the latest Eiffel, and I see very
> very good things.]
I wish them luck. And I wish you luck in your search for the
perfect .NET language. However, if you really believe that Lisp
is that language, you should consider becoming a lisp vendor yourself
and writing that very .NET lisp. Perhaps it will take off, and you
will become the author of another successful lisp.
mikel evins
> Merciless evangelizing requires money. Perhaps MS can evangelize .NET
> into a good position, or perhaps not. They certainly don't care about
> lisp, so they're certainly not going to evangelize it.
While I agree with your arguments, it is notable that Microsoft has expended
a good deal of effort to ensure that lots of languages work pretty well on
the .NET runtime, going so far as giving away nontrivial amounts of money to
people like the Mercury Project folks to get good compilers to target .NET
and soliciting input from compiler writers on the design of the VM.
Although undoubtedly you are right that they don't care about lisp in
particular, they do seem to care that various languages exist and run well
on it.
> I wish them luck. And I wish you luck in your search for the
> perfect .NET language. However, if you really believe that Lisp
> is that language, you should consider becoming a lisp vendor yourself
> and writing that very .NET lisp. Perhaps it will take off, and you
> will become the author of another successful lisp.
Now there's a sound suggestion.
Paolo Amoroso
> success. As an amateur observer of the industry, I see two things that
> are very dear to Mr. Gates heart: Basic and Windows. Relentless
> improvements on these products over the years have made them
> successes. I see .NET to be added to the list. (Something that was not
Marketing might have had some--possibly minor--influence here. Given that
many users can't tell Win95 from WinNT, I'm not sure whether they are aware
of the relentless improvements.
Stanley Knutson
>> Duane Rettig <du...@franz.com> writes:
>>
>> > rc...@epcor.ca (Resty Cena) writes:
>> >
>> > > Is anybody working on a Lisp port to the .NET platform? Seems to me
>> > > that Microsoft .NET is a wide-open side-door for Lisp to enter into IS
>> > > shops.
>> >
>> > We at Franz looked at it, and rejected it. The major reasons for
>> > us deciding not to proceed were ...
[snip]
A few thoughts about Lisp and the ".Net Virtual Machine":
If lisp is not available to compile for execution on .net VM, this
will continue to keep lisp on the sidelines. Remeber one reason for
the .net VM: you can compile and test on a Win32, and then "just run"
on an IA64 [no recompile needed, and the developer does not need an
IA64 machine on their desk].
Not supporting lisp on .net [regardless of reasons] will continue the
perception that "lisp is NOT for the mainstream".
The lisp community is already at a disadvantage in real world -- it is
hard to convince managers that "lisp is better" when they can't easily
find [or afford] people that know it. Making it impossible to deliver
Lisp on (for example) IA64 / .net VM will make use of lisp even harder
to justify for new projects.
Perhaps someone should port CLisp to the .net VM -- regardless of
performance issues ... (or a scheme? ...)
I might even be willing to help....
- Stanley.Knutson @ [nospam] ktiworld.com
----
lxb
I prefer Latex and Bondage as ways of relaxing.
Do you have a problem with that?
Duane Rettig
> On 07 Jun 2001 16:58:57 -0700, Duane Rettig <du...@franz.com> wrote:
>
> >> Duane Rettig <du...@franz.com> writes:
> >>
> >> > rc...@epcor.ca (Resty Cena) writes:
> >> >
> >> > > Is anybody working on a Lisp port to the .NET platform? Seems to me
> >> > > that Microsoft .NET is a wide-open side-door for Lisp to enter into IS
> >> > > shops.
> >> >
> >> > We at Franz looked at it, and rejected it. The major reasons for
> >> > us deciding not to proceed were ...
>
> [snip]
>
> A few thoughts about Lisp and the ".Net Virtual Machine":
>
> If lisp is not available to compile for execution on .net VM, this
> will continue to keep lisp on the sidelines.
Hmm. "Sidelines" implies a game, from which a player is being
excluded. But who are the players on the field right now? .NET?
How about JVM instead? Or maybe something else? To continue the
sports analogy, there was a lot of hype about XFL last year, but
hardly anybody watched it and it failed very quickly. I'm not sorry
I missed out watching an XFL game, even though I do like a good
game of football.
> Remeber one reason for
> the .net VM: you can compile and test on a Win32, and then "just run"
> on an IA64 [no recompile needed, and the developer does not need an
> IA64 machine on their desk].
Portability: A noble pursuit. I would tend to believe that it could
happen if MS had at least attempted to be inclusionary in their
aspirations for .NET. But they haven't; MS intends .NET only for
MS operating systems. Even Sun, who did make great efforts to
create a virtual world in Java, had a terrible time making Java truly
portable. And although MS had attempted to port their NT operating
system to several other architectures, all of these attempts failed
for one reason or another. We had even done a port of Allegro CL to
the last attempt, NT on the Alpha architecture. We got paid, so we
didn't lose money on the port, but we certainly wasted time.
Unless and until MS changes their mind (or until others port .NET
to other operating systems), or unless MS decides to try once again
to port NT itself to other architetcures, I do not yet think of .NET
as mainstream or as living up to its goal of portability.
> Not supporting lisp on .net [regardless of reasons] will continue the
> perception that "lisp is NOT for the mainstream".
Not porting an implementation of lisp to .NET is not the same thing
as not supporting it. As it stands now, we have never ported our
lisp so that it runs on the JVM either, but we do have a product
coming out called JiL (which we talked about at an earlier conference)
which allows one to compile lisp code to Java byte codes. We could do
the same thing for .NET if it takes off, and so your premise "not
supporting lisp on .net" is false.
> The lisp community is already at a disadvantage in real world -- it is
> hard to convince managers that "lisp is better" when they can't easily
> find [or afford] people that know it. Making it impossible to deliver
> Lisp on (for example) IA64 / .net VM will make use of lisp even harder
> to justify for new projects.
How do we know IA64 will be successful? It hasn't yet proved itself.
I don't know myself, but if I were forced to decide right now, I think
AMD's x86-64 is more likely technically to succeed long-term than IA64,
which has had a terrible birth history so far.
What will happens if you follow one stream, lock, stock, and barrel, and
it then turns out not to be the main stream?
> Perhaps someone should port CLisp to the .net VM -- regardless of
> performance issues ... (or a scheme? ...)
> I might even be willing to help....
That would be a good idea. As much as it might sound like I am against
the .NET concept, I must emphasize _again_ that like the concept, but
that I do not know what the future holds, and that it would be a good
idea to cover all bases. But unless and until .NET actually does take
off, the Company I work for will not yet bother to pour our resources
into it, just because it comes from MS. If it does take off, then I
think our best bet will be to do something like JiL will do, but for
the .NET architecture.
cbbr...@hex.net
>> [snip]
If you learned some things that would make a 64 bit port to IA-64 [or
Sledgehammer, or SPARC, or PPC, or ...] easier, that "waste" may come
back to benefit you later...
> Unless and until MS changes their mind (or until others port .NET to
> other operating systems), or unless MS decides to try once again to
> port NT itself to other architetcures, I do not yet think of .NET as
> mainstream or as living up to its goal of portability.
The guys who started the "Gnome" desktop project are working on a .NET
"clone" called Mono; dunno how seriously to take that all...
>> Not supporting lisp on .net [regardless of reasons] will continue
>> the perception that "lisp is NOT for the mainstream".
> Not porting an implementation of lisp to .NET is not the same thing
> as not supporting it. As it stands now, we have never ported our
> lisp so that it runs on the JVM either, but we do have a product
> coming out called JiL (which we talked about at an earlier
> conference) which allows one to compile lisp code to Java byte
> codes. We could do the same thing for .NET if it takes off, and so
> your premise "not supporting lisp on .net" is false.
>> The lisp community is already at a disadvantage in real world -- it is
>> hard to convince managers that "lisp is better" when they can't easily
>> find [or afford] people that know it. Making it impossible to deliver
>> Lisp on (for example) IA64 / .net VM will make use of lisp even harder
>> to justify for new projects.
> How do we know IA64 will be successful? It hasn't yet proved itself.
> I don't know myself, but if I were forced to decide right now, I think
> AMD's x86-64 is more likely technically to succeed long-term than IA64,
> which has had a terrible birth history so far.
Very good question. It seems rather likely that _Alpha_ won't be
successful, although some of the Alpha folk are predicting that
"Itanic" will wind up becoming successful when the Intel "stuff" that
apparently isn't working well yet gets replaced by "Alpha bits" that
will...
But for those that have been following Intel, the 64 bit architecture
has regularly been predicted to be a year or so away since about 1996,
and that hasn't changed lately. Anyone that had been trying to bet
their workstation business on IA-64, well, I hope they had an
alternative plan...
> What will happens if you follow one stream, lock, stock, and barrel,
> and it then turns out not to be the main stream?
>> Perhaps someone should port CLisp to the .net VM -- regardless of
>> performance issues ... (or a scheme? ...)
>> I might even be willing to help....
> That would be a good idea. As much as it might sound like I am
> against the .NET concept, I must emphasize _again_ that like the
> concept, but that I do not know what the future holds, and that it
> would be a good idea to cover all bases. But unless and until .NET
> actually does take off, the Company I work for will not yet bother
> to pour our resources into it, just because it comes from MS. If it
> does take off, then I think our best bet will be to do something
> like JiL will do, but for the .NET architecture.
The scary thing about .NET is that making it useful depends on using
the authentication scheme, which essentially ties all the control into
Microsoft's horde of "Passport" authentication servers...
--
(concatenate 'string "cbbrowne" "@acm.org")
http://vip.hyperusa.com/~cbbrowne/sgml.html
If only women came with pull-down menus and online help.
Duane Rettig
> Duane Rettig <du...@franz.com> writes:
> > We had even done a port of Allegro CL to
> > the last attempt, NT on the Alpha architecture. We got paid, so we
> > didn't lose money on the port, but we certainly wasted time.
>
> If you learned some things that would make a 64 bit port to IA-64 [or
> Sledgehammer, or SPARC, or PPC, or ...] easier, that "waste" may come
> back to benefit you later...
No, we had already done the 64-bit port to the Alpha, and besides, the
version of NT that was available at the time was the 32-bit version.
The only thing we really learned was how x86-specific the NT implementation
was at the time, and how many hoops had to be jumped through to get
exception handling to work correctly.
> > Unless and until MS changes their mind (or until others port .NET to
> > other operating systems), or unless MS decides to try once again to
> > port NT itself to other architetcures, I do not yet think of .NET as
> > mainstream or as living up to its goal of portability.
>
> The guys who started the "Gnome" desktop project are working on a .NET
> "clone" called Mono; dunno how seriously to take that all...
Yes, but it's all very new. MS and Corel have also announced a "shared
source" version of .NET as well.
> > How do we know IA64 will be successful? It hasn't yet proved itself.
> > I don't know myself, but if I were forced to decide right now, I think
> > AMD's x86-64 is more likely technically to succeed long-term than IA64,
> > which has had a terrible birth history so far.
>
> Very good question. It seems rather likely that _Alpha_ won't be
> successful, although some of the Alpha folk are predicting that
> "Itanic" will wind up becoming successful when the Intel "stuff" that
> apparently isn't working well yet gets replaced by "Alpha bits" that
> will...
Yes, there are many flames going through comp.arch about this, and it
is not clear what the future holds for IA64.
> But for those that have been following Intel, the 64 bit architecture
> has regularly been predicted to be a year or so away since about 1996,
> and that hasn't changed lately. Anyone that had been trying to bet
> their workstation business on IA-64, well, I hope they had an
> alternative plan...
Spread the eggs over many baskets...
> The scary thing about .NET is that making it useful depends on using
> the authentication scheme, which essentially ties all the control into
> Microsoft's horde of "Passport" authentication servers...
Yes, of course, this is their real reason for proliferating .NET.
Whomever controls the exchange of money on the internet will control
the internet.
cbbr...@hex.net
> cbbr...@hex.net writes:
>
>> Duane Rettig <du...@franz.com> writes:
>>> We had even done a port of Allegro CL to
>>> the last attempt, NT on the Alpha architecture. We got paid, so we
>>> didn't lose money on the port, but we certainly wasted time.
>>
>> If you learned some things that would make a 64 bit port to IA-64 [or
>> Sledgehammer, or SPARC, or PPC, or ...] easier, that "waste" may come
>> back to benefit you later...
> No, we had already done the 64-bit port to the Alpha, and besides,
> the version of NT that was available at the time was the 32-bit
> version. The only thing we really learned was how x86-specific the
> NT implementation was at the time, and how many hoops had to be
> jumped through to get exception handling to work correctly.
Presumably an exceptional number of hoops? :-)
And that sounds like the sort of thing where the main thing learned
that gets reused is some grousing about "Boy, this is going to be
ugly!"
>> But for those that have been following Intel, the 64 bit
>> architecture has regularly been predicted to be a year or so away
>> since about 1996, and that hasn't changed lately. Anyone that had
>> been trying to bet their workstation business on IA-64, well, I
>> hope they had an alternative plan...
> Spread the eggs over many baskets...
About four years ago, if you believed Gartner Group, there wouldn't be
any 64 bit architecture other than IA-64 being actively maintained by
about now; the Unix vendors that were getting cozy with Intel have
_got_ to be hurting now, between:
- SGI, dropping active work on MIPS;
- Sequent;
- It looked like IBM thought that PPC would get bulldozed by IA-64,
but they're certainly big enough to keep their own chip foundries
going...
- Gotta wonder what's happening with Compaq/Digital, and whatever they
call Unix these days...
>> The scary thing about .NET is that making it useful depends on
>> using the authentication scheme, which essentially ties all the
>> control into Microsoft's horde of "Passport" authentication
>> servers...
> Yes, of course, this is their real reason for proliferating .NET.
> Whomever controls the exchange of money on the internet will control
> the internet.
Oh, my. "Bank of Microsoft." There's a lovely thought...
--
(concatenate 'string "cbbrowne" "@acm.org")
http://vip.hex.net/~cbbrowne/nonrdbms.html
"Win32 sucks so hard it could pull matter out of a Black Hole."
-- Pohl Longsine
Russell Senior
>> Yes, of course, this is their real reason for proliferating .NET.
>> Whomever controls the exchange of money on the internet will
>> control the internet.
cbbrowne> Oh, my. "Bank of Microsoft." There's a lovely thought...
``A fatal exception has occurred. Please open a new savings account.
Your balance has been reset to zero.''
--
Russell Senior ``The two chiefs turned to each other.
sen...@aracnet.com Bellison uncorked a flood of horrible
profanity, which, translated meant, `This is
extremely unusual.' ''
Duane Rettig
> Duane Rettig <du...@franz.com> writes:
> > cbbr...@hex.net writes:
> >
> >> Duane Rettig <du...@franz.com> writes:
> >>> We had even done a port of Allegro CL to
> >>> the last attempt, NT on the Alpha architecture. We got paid, so we
> >>> didn't lose money on the port, but we certainly wasted time.
> >>
> >> If you learned some things that would make a 64 bit port to IA-64 [or
> >> Sledgehammer, or SPARC, or PPC, or ...] easier, that "waste" may come
> >> back to benefit you later...
>
> > No, we had already done the 64-bit port to the Alpha, and besides,
> > the version of NT that was available at the time was the 32-bit
> > version. The only thing we really learned was how x86-specific the
> > NT implementation was at the time, and how many hoops had to be
> > jumped through to get exception handling to work correctly.
>
> Presumably an exceptional number of hoops? :-)
A number of exceptional hoops. :-)
> And that sounds like the sort of thing where the main thing learned
> that gets reused is some grousing about "Boy, this is going to be
> ugly!"
Well, our code based changed surprisingly little. In the operating system
interface, the C code has some #if defined(MS_NT) && defined(__alpha__)
in a few places, but the architecture itself was pretty portable.
We had to go to Dec/Compac to ask for help on those exceptional (:-)
pieces, though.
> >> But for those that have been following Intel, the 64 bit
> >> architecture has regularly been predicted to be a year or so away
> >> since about 1996, and that hasn't changed lately. Anyone that had
> >> been trying to bet their workstation business on IA-64, well, I
> >> hope they had an alternative plan...
>
> > Spread the eggs over many baskets...
>
> About four years ago, if you believed Gartner Group, there wouldn't be
> any 64 bit architecture other than IA-64 being actively maintained by
> about now; the Unix vendors that were getting cozy with Intel have
> _got_ to be hurting now, between:
I don't think any vendors really believed them - Even though they jumped
on the bandwagon, they tended to hedge their bets.
[ ... ]
[I started to answer each bullet, but thought better of it, since
some of my comments would not have been flattering]
And don't forget HP, the instigators of IA64 technology. Even they
have some of their eggs in the PA-RISC basket.
Rob Warnock
+---------------
| ...the Unix vendors that were getting cozy with Intel have _got_
| to be hurting now, between:
| - SGI, dropping active work on MIPS;
Fortunately, despite some confusing press releases, we never actually
did "drop" active work on MIPS, and have in fact been steadily (albeit
more slowly than some might have liked) been releasing upgrades -- the
latest being the 500 MHz R14k. (Also see our paper on the planned R18k
at the upcoming "HotChips" symposium.) And, yes, they're real & shipping:
<URL:http://www.sgi.com/newsroom/press_releases/2001/may/naval.html>.
cbbr...@hex.net
> <cbbr...@hex.net> wrote:
> +---------------
> | ...the Unix vendors that were getting cozy with Intel have _got_
> | to be hurting now, between:
> | - SGI, dropping active work on MIPS;
> +---------------
> Fortunately, despite some confusing press releases, we never
> actually did "drop" active work on MIPS, and have in fact been
> steadily (albeit more slowly than some might have liked) been
> releasing upgrades -- the latest being the 500 MHz R14k. (Also see
> our paper on the planned R18k at the upcoming "HotChips" symposium.)
> And, yes, they're real & shipping:
> <URL:http://www.sgi.com/newsroom/press_releases/2001/may/naval.html>.
Sometimes I'm quite pleased to be proven wrong; this is certainly one
of those occasions.
It still is wise to be a _little_ skeptical; the fact that there's
chips out there looking like spiders with all the pins on the bottom
[I'm assuming a lack of use of surface mount here :-)] doesn't
necessarily mean that it's of vast public interest unless there are
also a whole lot of motherboards/backplanes/... being built.
It's sort of useful to look at Linux for a moment; the _interesting_
architectures for Linux are primarily IA-32 and Alpha, as those are
the primary architectures where it's relatively straightforward to buy
chips and motherboards. PPC comes close, although the motherboards
tend to be really quite pricey.
StrongARM and MIPS [thinking of R4600 and the likes] have made the
promise of cheap CPUs, but when building a system requires people to
get into designing and arranging for fabbing of their own
motherboards, it instantly becomes rather more daunting. StrongARM
was probably the most pointed example; it offered something about as
powerful as a 200MHz Pentium for about $25, but it's not attractive
unless you've got a decent source of the rest of the computer system
infrastructure, and that's _not_ been there.
This is straying a fair bit away from Lisp; bumping it back is that
none of these options are terribly suggestive of providing anything
worthy for vendors [like Franz or Xanalys] or for "open source"
projects [like CMU/CL] to target as destinations.
It probably _is_ worthwhile to have some of the low end MIPS hardware
targetable by ACL, on the basis that there are a whole lot of
videogame machines with those CPUs; it is vastly _less_ clear that
it's worth targeting something like R18K where it's not evident just
where there will be systems. [I'm not familiar enough with the
underpinnings; it might well be that the relevant difference between
R4600 and R18K, for the purposes of code generation, is that the
latter has a whole bunch of additional 64 bit registers...]
I doubt anyone will be deploying desktop machines with R18K's the way
that there were early Windows NT systems running earlier generations
of MIPS chips; the fortunate side of things is that it's not evident
yet that there will be a lot of desktop machines with IA-64, either...
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://vip.hyperusa.com/~cbbrowne/oses.html
You know that little indestructible black box that is used on
planes---why can't they make the whole plane out of the same
substance?
Coby Beck
"Russell Senior" <sen...@aracnet.com> wrote in message
news:86wv4pj...@coulee.tdb.com...
> >>>>> "cbbrowne" == cbbrowne <cbbr...@hex.net> writes:
>
> >> Yes, of course, this is their real reason for proliferating .NET.
> >> Whomever controls the exchange of money on the internet will
> >> control the internet.
>
> cbbrowne> Oh, my. "Bank of Microsoft." There's a lovely thought...
>
> ``A fatal exception has occurred. Please open a new savings account.
> Your balance has been reset to zero.''
>
I don't know whether to laugh or cry....
Coby
--
(remove #\space "coby . beck @ opentechgroup . com")
cbbr...@hex.net
> "Russell Senior" <sen...@aracnet.com> wrote in message
> news:86wv4pj...@coulee.tdb.com...
> > >>>>> "cbbrowne" == cbbrowne <cbbr...@hex.net> writes:
> >
> > >> Yes, of course, this is their real reason for proliferating .NET.
> > >> Whomever controls the exchange of money on the internet will
> > >> control the internet.
> >
> > cbbrowne> Oh, my. "Bank of Microsoft." There's a lovely thought...
> >
> > ``A fatal exception has occurred. Please open a new savings account.
> > Your balance has been reset to zero.''
> >
>
> I don't know whether to laugh or cry....
Takes me back to the _best_ Polish joke of all time, which was NOT one
making Poles look stupid, unless you look at the punchline too
uncarefully...
(defun polish-banking-joke ()
"Two Poles are talking about the safety of their money, with the
guarantees provided by a whole hierarchy of Polish banks, and then
backed up by a further hierarchy of Russian/Soviet banks."
;;; Should have these lists be common sublists; I DON'T CARE TO CODE
;;; IT NOW...
(loop
for bank in (list Warsaw Poland Moscow)
for guarantor in (list Poland Moscow Soviet-Union)
do
(format t "Q: But what if the bank of ~A fails?~%" bank)
(format t "A: Well, your money's guaranteed by the bank of ~A" guarantor))
(format "Q: But what if the Great Imperial Bank of the Soviet Union fails?~%")
(format "A: Well, then you've lost all your money. But wouldn't it
be worth it?~%"))
The implications for the Imperial Bank of Microsoft should be obvious
:-).
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://vip.hyperusa.com/~cbbrowne/advocacy.html
Consciousness - that annoying time between naps.