Re: vendor collaboration [Re: Smalltalk for Web development?]

"Dave Harris" <[hidden email]> wrote in message
news:[hidden email]...
Well, I should step in and give my opinion since I worked with Microsoft to
develop support for Smalltalk on .NET. I find that there is ONE giant
difference between the Sun JVM and the Microsoft .NET VM philosophy.  Which
is that the technical feats necessary to "moderately efficiently" support
language features, such as what Smalltalk requires, can be created on .NET
using the reflection, metdata, and IL facilities of .NET itself without
needing any custom extensions/non-portable elements such as native code.
Thus the extensions required can be made using .NET facilities and are
therefore portable so they will run on any .NET version. Microsoft worked
very hard and was very proactive about supporting design changes to make
this possible -- i.e., it was/is a fundamental goal for them.

Most of, but not all, the technical issues that I have with .NET for
supporting Smalltalk are things which Microsoft could solve at a future
date. And, which they are openly interested in addressing at a future date.
They did not make the cut for the initial design because Microsoft, who is
very good with product schedules, had lockdown dates at which they had to
begin freezing v1 features. More than anything else, this single factor
precluded availability of resources and facility to add some key features to
v1 that would make a big difference for dynamically bound language
implementation on .NET. Compared to trying to build a portable (non JNI)
support library for dynamic languages on JVM, the issues are night and day.

I.e., IMHO Sun, on the other hand, could give a damn about other languages
because they are promoting Java and their ownership of it as a language
therefore their VM model is Java-bounded (effectively rigid/closed) and they
have never made an effort to ensure it could portably support other
languages. One might conclude they even discourage it, since they have had
(Smalltalk technology via HotSpot, Self, etc) and know what technical
changes might be needed to support a broader range of languages. However, to
do so would be in direct conflict with the essence of Sun's vision for Java
(one language for all; in the competitive business spririt of course).

In reality, I attribute most of the problems I have with Java and its VM
issues not too well planned aggessive business tactics, but rather to
limited technical breadth and vision among the controlling (politics in Sun)
personalities who drove/drive the technical and corresponding business model
for Sun's Java vision.

The problem fostered by Sun begins with a design flaw that the language is
what is important for portability. Microsoft took the approach that the VM
was what was important for portability and ubiquitous functionality. Either
approach allows the option for the respective companies involved to control
and/or create proprietary elements that are challenging to produce in clean
room form.

Technically speaking, the .NET platform is a giant leap forward over the
JVM. The .NET platform changes the problem from one of enabling a languages
portability to one of enabling an executables portability. There is a lot
more well designed technology and capability in the architecture of .NET
than there is in the relatively crippled JVM architecture. Which is to
Microsoft's advantage, of course, since it raises the bar significantly on
producing a clean room .NET platform.

So to make sure everyone reads between the lines on my comments, I'm have no
beliefs or desires regarding defending either companies business practices.
But I am telling you that from a technical point of view, .NET is a superior
architecture (implementation may be another thing, time will tell). As to my
naivette in trusting Microsoft to hold the keys to the core VM technology of
the future of my work, SmallScript, it should be obvious that I'm not. It
has been and will remain the case for the forseeable future that QKS own AOS
VM platform is the reference VM for SmallScript and QKS Smalltalk, and that
Microsoft's .NET platform is just a valuable and supported alternative
platform.

IMHO
----
As to a plot by Microsoft to "crush" Java as some parties have indicated, I
would simply call that a naive Java centric (paranoid Java advocates) view
because it really suggests a far too narrow focus for Microsoft's vision. I
would have suggested that Microsoft and the .NET vision was operating on a
much grander business scale than just targetting Java ;-).

If you observe C#, which the pundits at large claim is the Java clone, one
finds that within Microsoft's .NET focus and usage today DOES NOT treat C#
as a centerstage element but rather just one of many many key elements to
the grander picture. C# was perhaps one of the most essential elements in
the bootstrapping up of the .NET platform because it was the language that
emodied and evolved with the VM object model and was thus the first language
that could make use of and test out all the functionality. Keeping in mind
that the MS.NET architecture is focused on compiled element portability
(abstracted from source language), C# was important to create the frameworks
that go into what I believe forms the true value and essence of .NET as a
Microsoft strategy.

In fact, now that they have so many other languages supporting the .NET VM,
they are working to defocus away from C# because as explained by the thesis
in the previous paragraph it is not really an essential element to the big
picture of .NET. As an aside, it is my understanding is that there will be a
Java for .NET and that it is a third party producing it. I believe that the
party is Rational, but I could be wrong.
----
END


-- Dave Simmons [www.qks.com / www.smallscript.com]
  "Effectively solving a problem begins with how you express it."