Re: Universal Virtual Machine

"Steve Wart" <[hidden email]> wrote in message
news:Ryyi6.95397$[hidden email]...
> One thing that has disappointed me about .NET and Java is that these VMs
do
> not appear to provide good support for Smalltalk.
>
> [ re. .NET -- I have been a little confused by some of David Simmons'
posts.
> Although he has been quite helpful and informative, I am left with the
> impression that .NET will support SmallScript, but not Smalltalk as most
of
> us in this group understand Smalltalk.]

Sorry for creating that confusion. Maybe this post will help?

Then again, it is really long and almost certainly controversial so it may
actually do the opposite :-(

Hopefully those who choose to comment upon it, will comment on selected
sections in separate posts rather than bundling it all together :) [which of
course I didn't do]

>
> Whether .NET supports Smalltalk or not is not relevant.

Well, its relevant to me as the person who has developed Smalltalk for .NET
and has worked long and hard with Microsoft to continue to ensure that .NET
has the necessary elements to support Smalltalk.

> It is proprietary
> and closed (I wonder if Microsoft understands that .NET is supposed to be
> the operating system, not something you package with Windows or Windows CE
> or whatever they're calling it now).

Your comments regarding "proprietary" and "closed" are not "strictly
speaking" correct. The .NET specification is open and becoming a standard
via the ECMA process. A standard which is likely to be ratified and adopted
before the end of this year; in a process which involves many companies
including (and perhaps most notably) Sun Microsystems.

http://msdn.microsoft.com/net/ecma/

http://www.gotdotnet.com

The idea that Microsoft may not understand that .NET is "supposed to be an
operating system" is coming from left field.

I.e., Microsoft created and defined .NET, so de-facto they "defined" what it
is "supposed to be".

More to the point, I would contend that they intentionally designed it as a
technology to enable them to break their technology base free of both the
INTEL and Windows OS Family ties [and perhaps the Justice Department focus].
Which means they defined a "platform", which is not the same thing as an
"operating system".

Microsoft's .NET itself is very real and it really works. Microsoft has
barely begun marketing it. It will be at least as pervasive as COM, ActiveX,
Visual Basic, and IE/ASP/IIS Scripting. The heat in this area just has not
been turned up by Microsoft because they are, as usual, being
(instinctually) wily/smart about preparing all the adjunct software they own
or believe is key for the .NET. Once they reach that stage, they'll crank up
the heat and .NET will be de-facto reality.

In my judgment, one thing to understand about Microsoft is that their
*typical* "pragmatic" pattern, unlike companies such as Sun and Apple, is to
have solved a problem and implemented a solution that "to their
satisfaction" corresponds to what they think/believe they are promoting.
Their rationale is that by the time the world starts to care Microsoft has a
huge lead or dominant position that everyone else has to try and
overcome/catch up to.

That's part of how COM/ActiveX/OLE was able to completely crush Apple's
OpenDoc (and IBM's SOM) component technology [which is/was competition to
CORBA]. And .NET is just the next evolution of the COM/ActiveX/OLE
components and systems interop scalability story.

I would suggest that .NET is about Microsoft's efforts to keep moving
towards a dominant position regarding internet (and enterprise) deployment
and systems platform technology. I.e., .NET platform versus JVM platform
versus Apache/Linux collective, In my opinion, for Microsoft, it was never
about the language of Java -- that's why those who made or make noise about
C# are just missing the whole point.

>
> Neither does the Java VM support Smalltalk the way we know it today
(Bistro
> is a nice idea, but I don't think it's Smalltalk).
>
> In general, languages like Java, C#, and even Bistro and SmallScript
(IMHO)
> seem to be taking Smalltalk in the opposite direction it should be going.

What does Java or C# have to do with where Smalltalk is or is *not* going?

Where is SmallScript taking Smalltalk, that it should not be going?

    Smaller?
    Faster?
    More portable?
    Applicable to more of today's software tasks?
    More interoperable with other languages and systems?
    More capable of supporting multiple dialects/libraries
         simultaneously (incl non-Smalltalk)?
    More expressive for explicit enforcement of contracts?
    More scalable and deployable via the namespace, module,
         and interface technology QKS defined?
    More approachable and mainstream via familiar constructs
         from languages such as python, jscript, and c++?
    Retaining Smalltalk syntax/source compatibility.

The wrong directions are backwards and status quo.

There is a lot of important pioneering/implementation work that has been
done in the non st-80 derived dialects; and still continues to be done to
keep Smalltalk growing, evolving and competitive as a technology and as a
marketplace.

For example, take Smalltalk MT which has pioneered important new techniques
for Smalltalk implementation with their static compilation and its ability
to make small components/modules. It has significantly opened the
possibilities for Smalltalk applicability.

> And Smalltalk definitely needs to be going somewhere. For example, Self
> seems like a step in the right direction to me. But Self was buried by
Java
> and it doesn't appear to have much energy right now.
>
> Boris' recent posts regarding Lisp (here and in comp.lang.lisp) have me
> intrigued about things like meta-object capabilities. In our own work on
> Visual Knowledge, the modeling constructs provided by "vanilla" Smalltalk
> have proved inadequate and we have tried to extend those in creative ways
> (e.g. by developing a rather baroque, but useful prototyping system).
>
> IBM was trumpeting a UVM as part of their VisualAge offerings a year or
two
> ago, but I haven't seen much reference to that of late.
>
> What I am thinking of is an open source project to create a standard VM
for
> Smalltalk but that also supports other languages, such as Java and perl,
and
> more importantly, new language directions for Self-like and MOP extensions
> to Smalltalk. Similar to the Transmeta architecture (except all in
> software), one could define pluggable byte code dictionaries that the VM
> could swap in as required.

As far as pluggable byte code sets, both SmalltalkAgents(r) on QKS' Mac and
Win32 VM's had them. It is not the ideal model you want to use for a VM
design. It has importance only if you're building an interpreter and
interpreters should have CISC instruction sets to achieve best performance
and overall design characteristics. We demonstrated and explored this key
design area when we worked with Apple and IBM on our UVM system (AOS) in
the early 90's.

A jitter requires a different instruction set design that should be neither
CISC or RISC, but rather lend itself to supporting fast analysis and
optimization [of which, in my opinion, the JVM set is a poor example].

On today's technology (where memory is cheaper and processors and their
caches are the driver) a jitter approach has many more desirable
characteristics. It is just more complicated to build well enough to make it
better than a good interpreter (Dolphin ST is an example here). A jitter
also has the "potential" to be better and more desirable than a static
compiler -- but the competitive challenges and some of the basic tradeoffs
make it even harder to develop a jit that is better than a static system (a
hybrid approach may in fact be the best model).

Microsoft's .NET technology investment is a pragmatic foray/exploration into
this very space -- especially for implementing languages such as C++ (where
they have a good static compiler).

A VM with a pluggable jitter framework/architecture is the approach I've
used in the AOS design. With that architecture I can readily use a
cross-jitter to translate from one byte code set to another and then jit
that into native code. So there is no reason to have "pluggable" byte code
dictionaries.

The goal is not one of having "pluggable" byte code sets, but rather to have
a rich object model and efficient structured access to the metadata such as
type information and well structured information for analyzing data flow in
an instruction/opcode stream. The AOS current architecture of pluggable
jitters is similar to but not exactly the same as byte code dictionaries.
The AOS platform on which our native SmallScript runs has four jitters
within it. Only one of them actually generates native cpu code, the others
are cross-jitters of one form or another.
----------

Regarding UVM thoughts, let me make a few comments. I've been in the UVM
area for many years. I originally designed our VM in 1990-1991 to host a
variety of dynamic languages. In those days the term "platform" had not
become popularized and we called our Agents Object System (AOS) UVM platform
a "backplane" (stemming from my minicomputer and EE/VLSI background :).

We danced with Apple for three plus years and signed a system deal with them
in 1996 to make our VM the UVM for all the MacOS dynamic and scripting
languages other than Java -- A deal that Sun indirectly contributed to
screwing up, one day after signing, by assisting Apple's stock plummet to a
junk bond status which froze all Apple investment and technology funds. But
that is another of the sad Smalltalk history stories...

Today that is water (stained with my BST) under the bridge.

So, back to the present day:

SmallScript and its virtual machine (AOS) will be free.
However, the AOS will not be open sourced.

The VM is part of a separate technology known as the Agents Object
System(tm)[AOS(tm)]. The AOS platform is a UVM and a corresponding object
model (CLS - common language specification) that has the elements to support
a wide range of languages that include the ability to support pointer based
languages and languages with strongly typed fields like Java. It
intentionally has the necessary mechanisms to support the lisp family of
languages.

FYI: There is already work underway on a native scheme implementation. And,
a large part of the work for python, and jscript has already been done. I
also have a very strong desire to see Java and VB implemented natively as
well. (each of these implementations, if they become available, I would
expect to be free -- which is better than open source GPL restrictions).

The AOS represents my collective knowledge (and investment) from over 10
years of direct (first hand) design and experience in the building of
sophisticated virtual machine technology and object models. As an
individual, I may not be the smartest or most linguistically expert or
rigorous in this field, and there are certainly others who have explored
this area over the years; some who did so quite a few years before me. But
I'm pretty certain that by now I've explored it at least if not more broadly
(possibly even more deeply), and perhaps as long and hard as anyone you'll
find in the area of dynamic languages (especially for UVM facilities).

I'm confident that my work (based on my involvement with Apple, IBM,
Microsoft, and seeing some of what has been published, et cetera) has
continually been at the forefront of evolution in this area for the last ten
years. I'm equally certain that there is a great deal more evolution and
improvement to be made in this area, and in specifics on my work.

SmallScript represents an even longer span of my knowledge and experience
applied to developing (and continuing to evolve) the minimum (core) set of
classes and methods necessary (on top of the AOS) to build any current
Smalltalk implementation using only SmallScript language constructs.

Noting that the core framework includes a complete SmallScript compiler, and
that SmallScript can compile "vanilla" Smalltalk and all the known dialect
specific extensions *I am aware of* (other than primitives -- which don't
[need to] exist in SmallScript).

That means that on each platform on which the AOS runs, every AOS ported
language or AOS ported Smalltalk dialect would be able to run.

SmallScript for .NET represents the translation of my knowledge (investment)
to the .NET platform, and my educating, lobbying, and actually getting
Microsoft to make the essential .NET changes needed to support dynamic
languages in general (which includes not only Smalltalk, but almost every
scripting language, and the lisp family).

That work alone, ignoring other historical investments, has cost me a lot of
personal sacrifice, time and money to create. I can tell you that without
the up front investment on my part to create the technology and demonstrate
its capabilities, Microsoft would not have been willing to make the changes
they have or consider the additional features I've requested so ensure
Smalltalk and other dynamic languages could be developed for the .NET
platform. And I have other irons in the fire with Intel for dynamic language
technology support.

----------------------
.NET Limitations Today
----------------------
Code that has been built in "vanilla" Smalltalk will compile and execute on
the AOS SmallScript system, and thereby should compile and run on
SmallScript.NET with good performance (significantly better than a JVM based
Smalltalk).

Specifically on .NET, there are provisos for areas such as dynamic MOP
operations, and object space enumeration that have to do with both security
issues and overall design constraints of the current V1 implementation of
.NET.

------------
Back to the question of what is "Smalltalk" and the idea of what a standard
Smalltalk library base could or should be...

The various dialect specific class libraries are proprietary in one form or
another. (I consider "Open Source" to be as proprietary as any other source
license since it has restrictions on its use).

If your goal is a good framework base to provide a standard set of
additional services, then that standard base should be based on a true
bsd-style source license. I.e.,a freely redistributable (without limitation)
set of core library sources. Such a free base library would put more
emphasis on dialects adding value in terms of solutions and integrated
toolsets for those solutions.

<opinion:volatile-topic>

"Advance warning: If you wish to discuss this section further, let's please
take it to comp.lang.advocacy"

I would also tell you that too much emphasis on making everything free and
unrestricted will eventually erode Smalltalk as viable business technology
because it won't be adequately supported and it won't evolve to meet
commercial needs. Like many of you we've all had time to watch the "Open
Source" movement.

Unlike some of you, I've had personal first hand experience with watching
its impact in areas such as the tools (separate from tools solutions)
market; an area that has (perhaps by definition) always suffered financially
relative to other software sectors. "When money flows, technology grows.
When ideas and their implementation have no value so to does the act and
effort of developing and creating them. Correspondingly, when ideas and
their implementation are constrained (as in patents and virtual monopolies
without open/unrestrained competition) then ideas and their implementation
get equally stifled."

So, I will tell you that in my opinion, it is important and valuable to have
"some" elements owned by the "collective" (which means freely
redistributable without limitation). But taken too far its negative effects
begin to significantly outweigh its benefits - striking a balance is
important. Otherwise, you end up just creating a service economy where there
is no value to software goods and intellectual as well as social achievement
and effort is not rewarded and is therefore effectively discouraged -- and
I'd like to think we have enough of that (at least in the US) already.

</opinion:volatile-topic>

I suggest that the process of defining Smalltalk should begin with defining
an object model (i.e., UVM and its associated MOP). A design that requires
looking well beyond current Smalltalk features.

As to some important but missing frameworks... It is possible to build
portable user-interface frameworks that allow full access and integration
with native services. Having such frameworks would be an important and
powerful enhancement for Smalltalk. But my experience suggests that it
should not be done in a st-80 style (self contained world) approach and it
can't be done properly without a modular Smalltalk.

It requires layering the frameworks where the principle of greatest common
set of features must be supported, rather than least common set of
features -- which means that platform services from one system may need to
be synthetically emulated on other platforms.

I have typically used a two (or more) layer approach where you have a native
base layer, and a generalized portable layer built on top of the native
layer. I've done it for the Mac and Windows platforms, and I am intimate
with what it takes to support X windows. And we all know that there just
aren't that many operating systems (or more broadly, platforms); so the
number of different native user interface layers to build is limited. One of
the key enablers for this was the rich graphics framework and event systems
I developed.

Being able to properly build a native layer means having standard language
mechanisms for interop with other languages. Something Smalltalk is
surprisingly poor at doing. The marshalling process and level of custom
coding effort is always significant and typically requires very specialized
Smalltalk skills and knowledge. And even then, there is the whole question
of performance costs for transitioning back and forth between Smalltalk and
the native world.

I am arguing that classic Smalltalk is not efficient or well architected for
native integration. Just as a few examples: it does not [as a language]
support concepts of structured (typed) fields, different forms of memory
references, pinned data pointers, foreign functions mechanisms, threads of
execution, or types in general for marshalling and interop.

The language doesn't address specific aspects of execution specification and
semantics that are needed for intrinsic foreign language interop. Noting
that foreign language interop is essential for any form of native system
access or, for that matter, integration with the rest of the world.

And a large reason for all of this is that it never adequately addressed or
rigorously explored the object model or execution engine architecture. So it
could not and did not get properly defined in terms of it. The closest it
came was in the Smalltalk-80 language and implementation book.

Here's just one pet peeve of mine:
---------------------------------
Primitives are lame and represent an old and limiting technique for
supporting interop (which really is the same as extending the language or
virtual machine). The mere fact that they exist is a glaring symptom of some
of what the Smalltalk language is missing (if it is to be able to function
as a full featured (general purpose) first class language in today's
software
world).

The whole concept of primitives is fundamentally outside the bounds of the
Smalltalk language. Yet we are exposed to them at the Smalltalk level. We
often cannot rewrite them, or when we can write them or write our own
primitives we have to do so in some external system and environment and
shutdown and rebuild our Smalltalk virtual machine to use them -- which
means that something is clearly missing in the Smalltalk language.

>
> This would allow one VM to work with several Smalltalk dialects, without
> requiring vendors to agree on a standard set of byte codes. The issues
with
> the Garbage Collector seem more difficult to me, but if Microsoft can
claim
> that .NET is a multi-language VM that provides GC services to any
language,
> than it should be possible to do this for Smalltalk as well, shouldn't it?

NOTE: .NET is much more than a multi-language VM that provides GC
services...

Given what you've described you're looking for, why couldn't you use a
*free* system like SmallScript to build your portable dialects that
contained only "vanilla" Smalltalk?

If your answer is that you want to see more platform ports than those which
are planned for SmallScript, I'm open to solving that issue.

If your answer is that you want to ensure bugs can get fixed in the
"restricted source", I'm also open to solving that issue.

If you have some other reasons I'd want to discuss and understand them. Its
a guess, but I suspect that at their heart are questions of business
investment and recovery: intellectual property, patents (which I abhor), and
to a large degree the very nature of what it takes for financially/business
oriented people (like me) to be in a position to be able/willing to make or
sustain "free" contributions into the Smalltalk community.

>
> I would like to attend Smalltalk Solutions this year, but it falls on my
> son's birthday. Perhaps if I get some time in the next few weeks I will
pick
> up Squeak again and see if I can get my head around some of the VM issues.
> E-mail is no substitute for face-to-face discussion, however :-(.
>
> Maybe the issues of a standard Smalltalk VM and taking Smalltalk to a new
> level by opening up the meta object model are old topics and maybe they
are
> independent of one another. I know that there are some people who are
> (hopefully still) reading this who have a much better understanding of VMs
> and Meta Object models than I do.

I'm guessing that some, if not all, the things that you don't have comfort
with in SmallScript are the result of opening up the meta object protocol of
a UVM.

To be a UVM, much more is required than what a "Smalltalk" implementation
needs. So if you're serious about wanting a UVM, we should publicly explore
the things about SmallScript that you classify as:

  "SmallScript, but not Smalltalk as most of us
   in this group understand Smalltalk"

What I have trouble understanding is the very statement that SmallScript is
not really Smalltalk. I would really like to understand this perception.

I believe I understand Dave Harris position on this quite well. His argument
is that SmallScript has additional features Smalltalk does not have and
therefore it is not Smalltalk because not only can you access those
features, but you will use them because they offer the option to utilize new
or more expressive patterns -- at which point you are no longer thinking or
programming in Smalltalk, but in the new language of SmallScript.

So I think I understand Dave Harris' point of view although I don't fully
know where I stand on it (I should point out that it is only a technical
issue to disable/turn-off the extended features).

But here is what is odd to me. SmallScript compiles Smalltalk code and
executes Smalltalk code just like any of the known dialects do today. If it
can do that, then why isn't it a Smalltalk?

It can't simply be because of a question of class libraries. Because those
can be implemented at will given a full "language" implementation of
Smalltalk. Which in turn allows one to bypass the whole dialect and bytecode
compatibility issue -- although there is great value in building a common
base of frameworks. And this is further enhanced because SmallScript and the
AOS object model makes it possible to have multiple libraries/frameworks
co-resident in a running application without conflict.

If it is some question of supporting the ANSI X3J20 standard I helped to
develop, that too should just be a question of creating a portable library
from basic Smalltalk language constructs and should be independent of
implementation -- especially because it doesn't address implementation
issues. The X3J20 standard is not (in my opinion) the correct or complete
set of "classes" needed to implement the language and therefore it is *not*
the language and thereby it is not the *core* framework for the language.
AND, even if it were, it doesn't address issues of object model or execution
engine behavior.

The fact that SmallScript can do *more* than this should not exclude it from
being a Smalltalk. I think I can make a good case that it is the purest (in
the sense of just being about the language elements and MOP) form of the
"language" that has been built in the last 20 years. The fact that the
implementation additionally supports the SmallScript language features and
constructs, is *no* different than having a python, scheme, jscript, vb, or
java compiler available within the same system.

SmallScript embodies my understanding of the essence of the Smalltalk
language without the extra baggage and confusion of those frameworks which
are not actually required to implement the language in itself. I.e., to
define itself via a compiler written in itself and run on itself.

Given such a core essence, and a rich UVM and MOP, it should be possible to
build the various frameworks (we call dialects) on top of it without VM or
platform specific dependencies.

As I mentioned a few paragraphs above, that includes implementing the ANSI
x320 standard frameworks which I both helped work on, and which I feel, by
themselves, have limited value. The X3J20 work is woefully incomplete for
what a Smalltalk language standard needs to contain to enable standardized
yet extensible implementation, and has a large number of elements that are
superfluous and should be extruded and placed into (standard) adjunct
libraries.

The basic reasoning, within this and similar threads, about what is
"Smalltalk" or not, is awfully reminiscent of my time spent on the ANSI
X3j20 (Smalltalk standards) committee. A time and place where the X3j20
group was not even willing to accept there was line, let alone try and draw
the line between the language and its adjunct class libraries/frameworks.

A line that I would argue *must* be drawn to create a useful Smalltalk
language definition/standard. A standard from which a truly small and
portable Smalltalk could be built. A base from which Smalltalk can be recast
to be more competitive and useful as a substitute/replacement for the
popular and fast growing languages of today. And it is those very
questions/frustrations with the X3j20 work that lead me to develop
SmallScript -- hence my wanting to really understand why SmallScript is not
perceived as a valid Smalltalk?

The UVM question is distinctly separate from Smalltalk. Just like the JVM is
not well suited to dynamic languages, a classic Smalltalk VM is not suited
to static languages (and is missing a variety of other elements).  A MOP
architecture reflects the UVM's object model, *not* the languages that are
implemented on that UVM. Let's not confuse these two separate and distinct
ideas or we will be no better than Java and JVM (which is strikingly similar
to in its own myopic way to a Smalltalk-80 world).

> Is this concept viable?

Yes, it certainly is.

>
> Steve

Ahhh, shewh. That was a long and almost certainly a controversial post. I'm
sure I'm not ready for all the questions and responses it may raise...

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

This post is a response to David's observations or concerns that I may have
made glib statements about .NET or SmallScript that are confusing or
inaccurate. It may be partly off-topic, but I want to ensure my
clarifications are in the original posted groups.

Please direct all followups to comp.lang.smalltalk.advocacy (also please do
not post complaints regarding availability of that newsgroup).

"David Simmons" <[hidden email]>
> "Steve Wart" <[hidden email]> wrote
> > One thing that has disappointed me about .NET and Java is that these VMs
do
> > not appear to provide good support for Smalltalk.
> >
> > [ re. .NET -- I have been a little confused by some of David Simmons'
posts.
> > Although he has been quite helpful and informative, I am left with the
> > impression that .NET will support SmallScript, but not Smalltalk as most
of
> > us in this group understand Smalltalk.]
>
> Sorry for creating that confusion. Maybe this post will help?
>
> Then again, it is really long and almost certainly controversial so it may
> actually do the opposite :-(
>
> Hopefully those who choose to comment upon it, will comment on selected
> sections in separate posts rather than bundling it all together :) [which
of
> course I didn't do]

Thanks for doing this. I have seen some very long posts from you in the past
and it is probably my own impatience that has led to my confusion.

I would like to split up your post, but not necessarily to respond to every
point. There is some useful stuff here that should be put up in a Smalltalk
and .NET FAQ.

> > Whether .NET supports Smalltalk or not is not relevant.
>
> Well, its relevant to me as the person who has developed Smalltalk for
.NET
> and has worked long and hard with Microsoft to continue to ensure that
.NET
> has the necessary elements to support Smalltalk.
>
> > It is proprietary
> > and closed (I wonder if Microsoft understands that .NET is supposed to
be
> > the operating system, not something you package with Windows or Windows
CE
> > or whatever they're calling it now).
>
> Your comments regarding "proprietary" and "closed" are not "strictly
> speaking" correct. The .NET specification is open and becoming a standard
> via the ECMA process. A standard which is likely to be ratified and
adopted it
> is "supposed to be".

Fair points. I apologize for the FUD. My perception of .NET is that is a
technology platform to allow MS to extend their reach to hardware devices
beyond the PC as we know it, as you suggest below. But my assumption is that
they want to extend their OS entrenchment to these devices as well.

Therefore, it is not the .NET VM that is a problem for me, but rather my
belief that .NET will require the presence of MS operating system services
in order to be useful. When I first heard of .NET, I thought of products
like VB, Word and Excel (which I have heard are pCode-based), and of course
Perl and Smalltalk, that would be good candidates for a VM implementation.

My perception of MS and the CE market is that MS is "hurting" because of the
porting efforts required to get not only CE running on all these different
devices, but also each application that needs to be redeployed for each
hardware vendor. The solution provided by .NET will allow MS (and more
importantly application developers) to have their products run on all such
devices without a recompile (or worse, a porting effort). But my assumption
is that these devices will still require the presence of a commercial MS
operating system.

Also, my bias stems from discussions I have read on the MSDN web site
regarding C# and C++ and the "controversy" around the fact that C# does not
provide "synchronous or deterministic destructors" (see
http://msdn.microsoft.com/library/Welcome/dsmsdn/deepc10192000.htm) [Warning
to Smalltalkers: do not look at this link if you have just had lunch].

The C++ development community is important to MS, and they are the primary
market for C#. Based on what you have said it is not likely that MS will
break the language independence in .NET in order to satisfy these concerns.
I especially appreciate your lobbying efforts with MS to ensure that MS
supports dynamic languages like Smalltalk (and beyond!).

But in its desire to be all things to all programmers, the logical concern
is that .NET (like Windows) will be extraordinarily complex and consequently
take years to stabilize. Maybe this is a problem with all software. But is
especially difficult to deal with in commercal software (see David's
comments below regarding the balance of free tools and funding for tool
development).

Until recently, I have been quite positive about Microsoft operating systems
and applications. In fact, I still believe the level of quality and
usefulness of their products is unsurpassed. But in the software industry,
upgrade revenues are like the goose that laid the golden egg. Microsoft has
thousands of clever people whose sole job appears to be finding ways of
tricking their customers into upgrading software that works perfectly well
for them, wasting valuable time and eroding the value proposition that these
products allegedly provided in the first place.

Hence my comment that .NET "should be" the operating system. When you buy or
build computer hardware, you need an O/S. To use that hardware you must
license an O/S. If that O/S is commercial software, there is a conflict on
the part of the vendor between selling product upgrades and providing a
stable platform for development and deployment. I remember reading a quote
recently that the only purpose of an O/S is to provide such a platform. To
me, a standard VM should be an important part of such an O/S.

And also, my point regarding the irrelevance of Smalltalk on .NET was not
intended to be insulting to you or your efforts (I apologize for the
crassness of this remark, and also commend you for not flaming me into a
black patch of dirt). My point was really that .NET is not relevant to me
based on the assumption that it is tied to Microsoft's commercial O/S
endeavors.

If .NET will work on Unix and Macintosh platforms without requiring a
commercial software license from Microsoft, I will be impressed. But I have
seen no unequivocal statement from Microsoft that this will be the case. In
spite of their attempts to deflect criticism around their commercial
practices, I believe that MS is founded on a simple principle that he who
controls the O/S, controls everything else. To give that up would be
anathema.

> More to the point, I would contend that they intentionally designed it as
a
> technology to enable them to break their technology base free of both the
> INTEL and Windows OS Family ties [and perhaps the Justice Department
focus].
> Which means they defined a "platform", which is not the same thing as an
> "operating system".

To me, a "platform" is more than just software.

[ other comments regarding .NET ]

> > Neither does the Java VM support Smalltalk the way we know it today
(Bistro
> > is a nice idea, but I don't think it's Smalltalk).
> >
> > In general, languages like Java, C#, and even Bistro and SmallScript
(IMHO)
> > seem to be taking Smalltalk in the opposite direction it should be
going. [ lots of good stuff about UVMs, jitters and the history AOS ]

These are all noble and useful objectives, however, there is one overriding
characteristic about Smalltalk that I value above everything else, and that
is its simplicity of expression.

<imho>
As with my concerns about .NET, extra "language" features (such as DBC,
Namespaces, etc.) inhibit learning and understanding, especially by people
who are learning to program. In fact, these features are often marginally
useful and serve as a mechanism for entrenchment of old ideas and may
unintentionally inhibit the growth of new ideas.

The *right* direction is greater simplicity and flexibility, while opening
up the object/class/method/inheritance mechanisms to be explored in
Smalltalk itself, rather than burying them in the depths of the VM.

Maybe the right direction *is* backwards. Maybe we should be looking more
closely at Smalltalk-72 instead of Smalltalk-80.
</imho>

> ------------
> Back to the question of what is "Smalltalk" and the idea of what a
standard
> Smalltalk library base could or should be...
>
> The various dialect specific class libraries are proprietary in one form
or
> another. (I consider "Open Source" to be as proprietary as any other
source
> license since it has restrictions on its use).
>
> If your goal is a good framework base to provide a standard set of
> additional services, then that standard base should be based on a true
> bsd-style source license. I.e.,a freely redistributable (without
limitation)
> set of core library sources. Such a free base library would put more
> emphasis on dialects adding value in terms of solutions and integrated
> toolsets for those solutions.
>
> <opinion:volatile-topic>
>
> "Advance warning: If you wish to discuss this section further, let's
please financially
> relative to other software sectors. "When money flows, technology grows.
> When ideas and their implementation have no value so to does the act and
> effort of developing and creating them. Correspondingly, when ideas and
> their implementation are constrained (as in patents and virtual monopolies
> without open/unrestrained competition) then ideas and their implementation
> get equally stifled."
>
> So, I will tell you that in my opinion, it is important and valuable to
have
> "some" elements owned by the "collective" (which means freely
> redistributable without limitation). But taken too far its negative
effects
> begin to significantly outweigh its benefits - striking a balance is
> important. Otherwise, you end up just creating a service economy where
there
> is no value to software goods and intellectual as well as social
achievement
> and effort is not rewarded and is therefore effectively discouraged -- and
> I'd like to think we have enough of that (at least in the US) already.
>
> </opinion:volatile-topic>

This is a difficult issue. I am not in favour of abritrary distinctions
between "tools" and "applications" (or even "O/S"s).

However I know many people who have worked hard on creating something in
software, and then, through no fault of their own (other than perhaps their
lack of high net worth), found that the fruits of their labour have been
"put on a shelf", never to be seen again. This, because of legal definitions
of "intellectual property", because of selfish and small-minded people, and
because of complex circumstances that conspire to crush creativity and breed
cynicism in this industry -- this cynical, soul-crushing software industry
that naive and idealistic software developers toss themselves into for
weeks, months and years on end without repreive and then surface to find it
has all gone to waste.

So, open source saves you from this. You build a suite of tools and
frameworks (hey, we could make a product from this), development progresses
apace, funding dries up, competitor or VC comes in (with horns on head and
pitchfork in hand) and says, "I'll save you from this problem" and shelves
it -- or, alternatively, developer picks self up off ground, dusts off
trusty laptop, moves on to new opportunity, and continues development
without losing anything other than perhaps a personal relationship that had
likely gone sour long ago.

YMMV :-)

[ more stuff about Smalltalk features and MOPs ]

> And a large reason for all of this is that it never adequately addressed
or
> rigorously explored the object model or execution engine architecture. So
it
> could not and did not get properly defined in terms of it. The closest it
> came was in the Smalltalk-80 language and implementation book.
>
> Here's just one pet peeve of mine:
> ---------------------------------
> Primitives are lame and represent an old and limiting technique for
> supporting interop (which really is the same as extending the language or
> virtual machine). The mere fact that they exist is a glaring symptom of
some
Hard not to agree. I thought of primitives after my initial post, and
realized, geez that'll put a damper on this idea. I suppose you could come
up with a standard way of providing primitive support in a UVM, but it
doesn't sound like a pleasant project.

> > This would allow one VM to work with several Smalltalk dialects, without
> > requiring vendors to agree on a standard set of byte codes. The issues
with
> > the Garbage Collector seem more difficult to me, but if Microsoft can
claim
> > that .NET is a multi-language VM that provides GC services to any
language,
> > than it should be possible to do this for Smalltalk as well, shouldn't
it?
>
> NOTE: .NET is much more than a multi-language VM that provides GC
> services...

It slices, it dices, it juliennes! ;-)

> Given what you've described you're looking for, why couldn't you use a
> *free* system like SmallScript to build your portable dialects that
> contained only "vanilla" Smalltalk?
>
> If your answer is that you want to see more platform ports than those
which
> are planned for SmallScript, I'm open to solving that issue.

My #1 issue.

> If your answer is that you want to ensure bugs can get fixed in the
> "restricted source", I'm also open to solving that issue.

Sounds important.

> If you have some other reasons I'd want to discuss and understand them.
Its
> a guess, but I suspect that at their heart are questions of business
> investment and recovery: intellectual property, patents (which I abhor),
and
> to a large degree the very nature of what it takes for
financially/business
> oriented people (like me) to be in a position to be able/willing to make
or
> sustain "free" contributions into the Smalltalk community.

See my earlier rant -- but for me, it really comes down to 2 things:

1) Am I unreasonably restricted from moving the fruits of my efforts to new
"platforms"?
2) Am I going to get locked into the "upgrade spiral of death" because some
marketing wizard has outsmarted me into upgrading my "platform" to support
say, the new Microsoft Digital Sunglasses.

> > Maybe the issues of a standard Smalltalk VM and taking Smalltalk to a
new
> > level by opening up the meta object model are old topics and maybe they
are
> > independent of one another. I know that there are some people who are
> > (hopefully still) reading this who have a much better understanding of
VMs
> > and Meta Object models than I do.
>
> I'm guessing that some, if not all, the things that you don't have comfort
> with in SmallScript are the result of opening up the meta object protocol
of
> a UVM.
>
> To be a UVM, much more is required than what a "Smalltalk" implementation
> needs. So if you're serious about wanting a UVM, we should publicly
explore
> the things about SmallScript that you classify as:
>
>   "SmallScript, but not Smalltalk as most of us
>    in this group understand Smalltalk"
>
> What I have trouble understanding is the very statement that SmallScript
is
> not really Smalltalk. I would really like to understand this perception.
>
> I believe I understand Dave Harris position on this quite well. His
argument
> is that SmallScript has additional features Smalltalk does not have and
> therefore it is not Smalltalk because not only can you access those
> features, but you will use them because they offer the option to utilize
new
> or more expressive patterns -- at which point you are no longer thinking
or
> programming in Smalltalk, but in the new language of SmallScript.
>
> So I think I understand Dave Harris' point of view although I don't fully
> know where I stand on it (I should point out that it is only a technical
> issue to disable/turn-off the extended features).
>
> But here is what is odd to me. SmallScript compiles Smalltalk code and
> executes Smalltalk code just like any of the known dialects do today. If
it
> can do that, then why isn't it a Smalltalk?

Well, it may be more than Smalltalk, but if it offers new features that
potentially complicate things for me, then I will be reluctant to use it. I
am still not sure if I would like to use Smalltalk as a scripting language.
The syntax seems to be optimized for interactive browsing and debugging.
That is how I understand and use it.

This is not much different than Sun arguing (successfully) that what MS did
to extend Java effectively created something that is not Java. Similarly,
Netscape's HTML extensions were not HTML. These extensions may be useful,
but in the case of Java at least, trademarks and legal agreements prevented
them from being used as part of something being called "Java".

SmallScript (tm?) is a good way to extend Smalltalk, because while it may be
a superset of Smalltalk, it is not Smalltalk. But that's okay, because you
are not positioning it that way anyhow.

There are lots of Smalltalk dialects that do not meet the ANSI spec, and I
don't think anyone is saying their vendors can't call those languages
"Smalltalk".

[ further explanations re. the origin of SmallScript and "definition" of
languages ]

> The UVM question is distinctly separate from Smalltalk. Just like the JVM
is
> not well suited to dynamic languages, a classic Smalltalk VM is not suited
> to static languages (and is missing a variety of other elements).  A MOP
> architecture reflects the UVM's object model, *not* the languages that are
> implemented on that UVM. Let's not confuse these two separate and distinct
> ideas or we will be no better than Java and JVM (which is strikingly
similar
> to in its own myopic way to a Smalltalk-80 world).

Thanks for the ideas and clarifications.

> > Is this concept viable?
>
> Yes, it certainly is.
>
> Ahhh, shewh. That was a long and almost certainly a controversial post.
I'm
> sure I'm not ready for all the questions and responses it may raise...
>
> -- Dave Simmons [www.qks.com / www.smallscript.com]
>   "Effectively solving a problem begins with how you express it."

Cheers,
Steve

David Simmons wrote (abridged**n :-)):
 
> Ahhh, shewh. That was a long and almost certainly a controversial post. I'm
> sure I'm not ready for all the questions and responses it may raise...
>
> -- Dave Simmons [www.qks.com / www.smallscript.com]
>   "Effectively solving a problem begins with how you express it."

I read the whole post because I found it interesting, but I suspect
that not many others will read all of it. Have you considered
collecting your better posts into a book, perhaps published online?
Especially since deja has disappeared. If I tend towards verbosity,
I can point to a greater example. :-)

One issue you raised, and that c.l.s. has discussed pretty heavily,
is to what extent SmallScript is Smalltalk. Since there are many ways
to answer this question, it might be worth making it a little more
rigorous. Your explanation has included terms such as ST (Smalltalk),
SS (SmallScript), VM, UVM, EE (execution engine), MOP (meta object
protocol), CL (computer language), DCL (dynamic computer language),
SSL (static computer language), SY (syntax), CLIB (class library).
Some of these abbreviations are mine. There's also VI (virtual image),
which may relevant. Would it help you explain SS better if you wrote
out relations between these terms? Perhaps it would be more clear than
plain English. I don't know. Anyway, here are a few examples.

inheritance SS = ST + new-SS-state + new-SS-behavior (SS is kind of ST)
composition new-SS-state = ...
composition new-SS-behavior = ...
composition SS = ST + new-component1 +... (SS includes ST as a subset)
composition new-component1 = ...
dependence SS-VM is the minimal VM necessary to run SS
dependence UVM is a sufficient VM to run SS
dependence UVM is sufficient to run DCL or SSL
what-relation? How are SS-VM and UVM related?
composition VM = EE + MOP
inheritance SS is a kind of DCL
composition SS = SS-SY + SS-CLIB + SS-objects + what else?
inheritance VM-for-Linux is kind of VM
instantiation can't think of good examples
other-relations ...

I know many of these are muddled, but I just wonder whether it is
possible to formalize SmallScript's definition more tersely. If a
decent response would be verbose, perhaps these ideas would help
your private thinking. What I fear is that computer languages and
IDEs are so complex that they can't be easily described in these
terms.

"Steve Wart" <[hidden email]> wrote in message
news:U7ej6.111680$[hidden email]...
> This post is a response to David's observations or concerns that I may
have
> made glib statements about .NET or SmallScript that are confusing or
> inaccurate. It may be partly off-topic, but I want to ensure my
> clarifications are in the original posted groups.
>
> Please direct all followups to comp.lang.smalltalk.advocacy (also please
do
> not post complaints regarding availability of that newsgroup).
>

[...lots snipped to get these posts smaller :) ...]
going? overriding
> characteristic about Smalltalk that I value above everything else, and
that
> is its simplicity of expression.

I thoroughly agree. Simplicity is elegance -- that has been the motto that
drove QKS Smalltalk's evolution from before day 1.

User experience will determine the reality of the following statements
----------------------------------------------------------------------
I designed SmallScript to extend Smalltalk's capabilities. Which means that
if Smalltalk can express and do all that you need to do, then you don't need
to learn the additional elements or features of SmallScript.

I.e., DBC, namespaces, etc are not essential and they can be ignored.

However, I think that both namespaces and interfaces are important concepts
that should be part of the learning experience. Learning about error
handling early and developing good habits regarding exceptions vs return
codes is equally important.

I have not found namespaces to be a problem for newbies to programming or
Smalltalk. A typical explanation is to give them a parallel to
folders/directories and the rest follows pretty naturally.

We'll see about interfaces. However, people tend to grasp the idea of
"roles" very quickly.

Generally speaking, the  extended capabilities of SmallScript have been
designed based on the 90/10 rule. 90% of the development problems being
solved don't require the extended SmallScript features, etc. But for the 10%
that do, you have the power to be precise and explicitly declare or control
what is supposed to happen.

One of the biggest reasons I like Smalltalk in particular and dynamic
languages in general is that they allow me to think more about the problem
rather than about how what I have to do to express it in my programming
language. That makes the process more fluid, and enables me to be more
productive.

It is one of the driving reasons for adding syntax to Smalltalk for
simplifying expression when interacting with the world outside of Smalltalk.

    Such as:
        parenthetical/functional messages -> foo(...)

        Interfaces -- where classes *are* interfaces
        Types -- where classes *are* types
        Namespaces -- where classes *are* namespaces

If I want to call the ::MessageBox(...) function in the User32.DLL I can
directly call it, or any arbitrary DLL function, via a self contained script
of the form:

------
class name=User32 dll='User32'.
eval [                "<- the 'eval' keyword is optional"
    User32.MessageBox(
        0,
        'TITLE',
        'Message',
        ( 0x00000030 "" MB_ICONWARNING
        | 0x00000000 "" MB_OK
        | 0x00010000 "" MB_SETFOREGROUND
        | 0x00002000 "" MB_TASKMODAL
        | 0x00040000 "" MB_TOPMOST
        )).
].
------

Or I could choose to extend the <String> class with:

------
class name=User32 extends=Module dll='User32'.
method class=String [
alert: msg

    User32.MessageBox(
        0,
        self,
        msg,
        ( 0x00000030 "" MB_ICONWARNING
        | 0x00000000 "" MB_OK
        | 0x00010000 "" MB_SETFOREGROUND
        | 0x00002000 "" MB_TASKMODAL
        | 0x00040000 "" MB_TOPMOST
        )).
].
------

Any class can be a repository of external methods/code within a
DLL/shared-library. So, the "extends=Module" is not necessary. But it is
good to group modules under the same inheritance family if you want to
implicitly inherit its interfaces for other module features.

Or I could have more explicitly written with our own type marshalling
information and calling conventions, etc:

------
module name=User32 dll='User32'.
method class=User32
[
  <$native=stdapi;Integer>
  MessageBox(<void> a,
             <String> title,
             <String> message,
             <Integer> modeFlags)
].
class name=String imports='+User32'.
method class=String
[
  alert: msg

    MessageBox(
        0,
        self,
        msg,
        ( 0x00000030 "" MB_ICONWARNING
        | 0x00000000 "" MB_OK
        | 0x00010000 "" MB_SETFOREGROUND
        | 0x00002000 "" MB_TASKMODAL
        | 0x00040000 "" MB_TOPMOST
        )).
].
------

The following is not a good way to have designed this service. But, for the
purposes of this simple example it does show how I could have written it
using an interface:

------
interface name=IUIInteraction dll='User32'.
method class=IUIInteraction
[
  alert: msg

    MessageBox(
        0,
        self,
        msg,
        ( 0x00000030 "" MB_ICONWARNING
        | 0x00000000 "" MB_OK
        | 0x00010000 "" MB_SETFOREGROUND
        | 0x00002000 "" MB_TASKMODAL
        | 0x00040000 "" MB_TOPMOST
        )).
].
class name=String implements='+IUIInteraction'.
------

With any of those different forms, I could then send any <String> instance
the message #alert:.
------
[
    'Improper input encountered' alert: 'WARNING'.

    "OR via the message aliasing semantics
     while also using the dot message notation"

    'Improper input encountered'.alert('WARNING').
].
------

The result is a 20 line script. Which could be built as a literally
miniscule DLL or EXE.

The 10% case of this would be if we wanted to handle MessageBoxA vs
MessageBoxW explicitly (perhaps it is obvious that the VM system is doing
something for use with regard to Wide vs Ascii method invocation and
marshalling).

===================
On the other hand, there is the 10% case where I'm calling an external
method that wants a pointer to a given type, and may need to dispatch
through some external vtable vector.

What we want is to implement interface methods with COM support for:
------
[
    someObject as: someInterfaceClass.
]
------

As you'll see below, we have complex issues (the 10% case). We need to pass
a reference to our container that will hold the result
<anInterfaceInstance>, and we would like to have the system automatically
marshal arguments and invoke COM style vtable services, as well as update an
<anInterfaceInstance> to hold an instance of that class rather than the
native ppvObject. The story for <IDispatch> dispInterfaces is similar but
that is another topic...

NOTE:
If we used <HResult> instead of <HRESULT> as the return value's type
descriptor in the method that follows, the marshalling machinery would map
the value into an exception/warning as appropriate.

We could, of course, change that behavior by rewriting the marshalling code
in the <HResult> class. Doing so would also mean that the #as: method should
be written differently.

The reverse (external vtable callback) invocation case (for the
QueryInterface method we wrote below) of mapping thrown exceptions into
<HRESULT> values is handled for us by the JITTER.

We also note that the <Interface> type currently treats '*' indirections as
the <Integer> type. So a pointer can be a negative value to minimize
<LargeInteger> object mapping.

So, we would write the additional methods:
(with that extra stuff because this is the 10% case)

------
method class=Interface [<$vtable=0;HRESULT>
QueryInterface(<GUID> interfaceId, <OUT Interface*> anObject)
    anObject := stObject as: interfaceId primaryValue.
   ^S_OK
].

method class=Interface [
as: <Interface.class> anInterfaceClass

   "Check for the self case -- subclasses may refine this method"
    if (anInterfaceClass == self class) return self "this".

   "If we are not a wrapper on an external object, and noting
    that interfaces don't wrapper interfaces"
    ffiHandle ? "#ifNil:" [^stObject as: anInterfaceClass].

   "Otherwise, invoke the external query interface routine"
    |ppvObject|
    |hResult| := QueryInterface(aBehavior md_uuid, <&>ppvObject).

   "If successful, return a wrappered instance"
    if (hResult = S_OK)
        return(aBehavior fromPPVHandle: ppvObject).

   "Otherwise, signal an exception and be sure to return <nil>
    in case the exception is caught and resumed."
    COMException signal: hResult.
   ^nil
].
------

Again, its a 28 line script (with comments) but we did have to know a bit
more syntax to accomplish our goals. I.e., we did have to understand how:
the annotation for the <$vtable> directive works (especially with
interfaces); how <types> work for marshalling and binding, and how
<&;in;out;*> type qualifiers work.

As a Smalltalker, we don't have to write these methods because they are part
of the core system, but we still note that they are written in SmallScript.
The fact that the mechanisms exist means that we can readily write our own
(portable) methods like this using only SmallScript, which will have
performance *and* capabilities equivalent to C/C++ code. [* We also have the
option to write methods with inline assembly and C++, but that too is
another topic *].

OTOH, we are free to ignore the mechanism by which those methods were built
and just use them as vanilla smalltalk:
------
[
    someObject as: someInterfaceClass.
]
------

The 10% case example was concocted because it also intentionally contains a
mixture of various SmallScript syntax styles for things like if(), ^,
return, return(), etc. A developer or project should just pick one of those
styles and use it consistently. The various style choices exist because one
of SmallScript's goals is to make the language more comfortable for those
coming from a more mainstream language background.

To be fair, those two <Interface> methods are a simplification of what you
would really write because they ignore the <outerInterface> attribute
(aggregation), and a few other niggling items.

First about .NET, then about the AOS and SmallScript.

-- .NET --
There is a lot of stuff in .NET. It is complicated (even by my standards).
So I not only understand the many concerns voiced about it, but I share many
of them. However, if any company has the resources to properly go through
the design, documentation, and implementation efforts it is Microsoft. Once
they've done it, the second generation folks will have an easier time
building some form of a clone.

The demands on a language to provide full featured access to all of .NET,
are really huge. Many of the language groups have noted this issue. The
arguments are similar to those about SmallScript not being a Smalltalk.
Starting with full featured COM and ActiveX automation interop is a minimum
starting point -- if you're looking at the big picture.

I.e., you don't have to support and use all the .NET features to be able to
function as you always have with your language. If your language was not a
general purpose language then you will almost certainly need to come up with
special mechanisms if you want to be able to call all the different types of
methods, or participate in the superclassing/subclassing mechanics.

-- AOS and SmallScript --
The AOS platform and all the SmallScript technology is owned entirely by me
(and is licensed to QKS). Microsoft currently owns none of it.

The SmallScript language is a separate technology from .NET and the AOS
version of it is unrelated and completely independent of the .NET
technologies.

The SmallScript language (when used with the .NET implementation of
SmallScript) allows you to be shielded from dealing with the vagaries of the
.NET architecture. You can do most of what you want in .NET without learning
more than the SmallScript language (and any frameworks you care to use).

I've done quite a bit of work in C# and I prefer SmallScript (but then I'm
obviously biased).  C# should be considered Microsoft's reference language
for utilizing the .NET object model (MOP) facilities.

The AOS platform does not have the same characteristics as the .NET system.
But it also does not have anything like the market importance and impact
that .NET has.

As to the SmallScript inheritance mechanisms, I'd like to believe they are
fully exposed in the SmallScript source layer. Certainly the <Behavior>
class, the <Interface> class and their subclasses are fully exposed and thus
make explicit all the data structures that are used within the VM.

It is true that the fundamental dispatching code isn't written in
SmallScript. But then again, it isn't written in any language, it is jitted.
It is also true the binding algorithms are not exposed at the SmallScript
layer, but there is no reason why the logic for them can't be exposed.

The SmallScript system allows one object [an object manager, which can be a
class] to manage binding and dispatching for some other set of arbitrary
objects (of any available class). This is how the bindNotification mechanism
works for swizzling objects. I.e., proxies: object-relational-maping,
distributed objects, etc. It can also be used to provide your own MOP level
binding or dispatching system.

>
> Maybe the right direction *is* backwards. Maybe we should be looking more
> closely at Smalltalk-72 instead of Smalltalk-80.
> </imho>

[...lots snipped to get these posts smaller :) ...]

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

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

David Simmons wrote:
>
> The SmallScript language is a separate technology from .NET and the AOS
> version of it is unrelated and completely independent of the .NET
> technologies.

So when/why would we use the AOS implementation instead of the .NET
implementation? (or visa-versa)

Nevin Pratt

Sorry if this may be a little OT. But it's short and replies to a specific
point.

"Steve Wart" <[hidden email]> wrote in message
news:U7ej6.111680$[hidden email]...
...
> If .NET will work on Unix and Macintosh platforms without requiring a
> commercial software license from Microsoft, I will be impressed. But I have
> seen no unequivocal statement from Microsoft that this will be the case. In
> spite of their attempts to deflect criticism around their commercial
> practices, I believe that MS is founded on a simple principle that he who
> controls the O/S, controls everything else. To give that up would be
> anathema.

AFAIK not only MS is pushing for .NET to be standard (and C# too, but this is
not the concern here), but it was directly concerned that it does get ported to
at least a Unix platform. Surprise surprise: that's Linux.

Again AFAIK MS have an agreement with Corel that Corel, if asked so by MS within
2 years, will port .NET to Linux. And will do it within 1 year. And then keep
the port up to date within no more than 6 months from any MS released update to
.NET for at least 5 yers.

Corel promises to put on .NET duty no less than 1/2 of it's developlment
efforts.

Therefore you will probably not have to pay MS for .NET per se (you may for .NET
on Windows, of course). However, strictly speaking, nowere is written that the
port will be free, even if I doubt that either MS or Corel would bet a dime on
any non free SW for Linux! So logic tells me that the port will actually be
free.

In any case the real point in making .NET standard means that anybody could port
it to whatever OS.

How successfull .NET will be is just another question, but it looks like MS is
really on focus to make .NET as usefull as it can be, as open as it can be and
as universal as it can be. And even as free as it can be.

Eventually they have TONS of technology that is .NET ready (or almost). And
they'll get cash flowing from that door.

Andrea Ferro
-------------------------------
Urka s.r.l.
DVD Authoring and Premastering