[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: bytecode unification for scripting (and other!) languages



I can't help adding my 2p to this discussion (which is
US$0.0285!  value!)

Now I've read more on the CIL I see that .NET is a
reasonable target for a Scheme compiler.  However I'm
not sure what it gains (PLT) Scheme.

Consider three classes of applications:
- web apps
- numeric apps
- general end-user apps

For web apps, playing with .NET doesn't win you much. 
In fact it is probably a net loss (unintentional pun)
when considering the time it would take to create the
compiler.  PLT Scheme already plays fine with today's
Web protocols.  Tomorrow's web protocol (in the MS
vision) is XML-RPC.  It is much easier to create an
XML-RPC library than a compiler.  So no win.

Numeric apps want speed!  This includes any multimedia
(audio, graphics - anything that manipulates big
matrices).  I don't see any win for .NET here.  I
doubt the .NET runtime will be as fast a native code
and I doubt it will optimise for matrix manipulations.

General end-user apps.  A big win for .NET here, if
you restrict yourself to Windows (or the Linux ports
happen).  You can play with all the runtime features
that other languages can.

I think the CLR is a bit of a red herring from MS. 
End users pay for goods and services, not for the
language you write in.  A service to book airline
seats has the same value to the consumer whether it
runs in Perl, C or Scheme.  In MS's vision, Passport
is the real key to Internet services.  Open source can
embrace and extend Passport on the level of XML-RPC -
the CLR is not required!  Implementing the CLR
irresistable to hackers  - it's big and tech-heavy and
cutting edge (kinda).  But it is also a sink of time
that could be spent writing services that users
actually use and care about.  The dotGNU project
understands at least some of this, and is implementing
a similar service to Passport in addition to cloning
the CLR.  
Should PLT Scheme use the CLR?  Well, it depends what
the users (that's us!) want.  I identified the end
user apps as the one big win for .NET integration.  Do
Schemers want to write these sorts of applications?  I
doubt it.  The majority of end-user application
development is done in cubicle farms where VB, Java,
C++ and probably C# are corporate policy.  I don't see
how having Scheme as a viable alternative would
suddenly lead to a change of policy and an explosion
of end user apps written in Scheme.  I'm all for
interacting with .NET, COM, XPCOM and the Linux
desktop environments but I don't think .NET is the
best use of the limited avaiable hacker time (but I'd
love to see an optimising native code compiler ;)

cya,
Noel

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/