python on the smalltalk VM

[Keith Ray]

In article <mailman.987684754.31126.python-list at python.org>, "Chris 
Gonnerman" <chris.gonnerman at usa.net> wrote:

> ----- Original Message ----- 
> From: "Andrew Dalke" <dalke at acm.org>
> Subject: python on the smalltalk VM
> 
> 
> > http://www.smalltalkconsulting.com/html/SmalltalkSolutions2001%232.html
> 
> This URL appears dead to me... is there an alternate location?

I don't have a problem loading the URL
<http://www.smalltalkconsulting.com/html/SmalltalkSolutions2001%232.html>

Here is a snippet from that page:

After the break I attended the Building COM and .NET in SmallScript  by 
David Simmons for a few minutes

About 70 people in attendence. Standing room only.

David talked about his Smallscript goals, he then launched into an 
explanation of how Smallscript is build by showing us the source code. 
If you were a Microsoft developer this would have been very interesting, 
and it is interesting to see how it all interfaced to the existing MS 
framework for development.

David's take is that Smalltalk is built wrong for scripting, it has a 
monolithic image. It really should be a bunch of Smalltalk pieces. 
Smallscript isn't a Smalltalk traditional image. It's the best features 
of the language but changed for doing scripting.

SmallScript is small, it is free, it's not an IDE. It's a compiler and 
execution engine. Someone else needs to build an IDE and frameworks, QKS 
may build a simple IDE but these aren't an important part of their 
research. Smallscript like all scripting languages is text based just 
tackle it with your emac editor.

Someone asked what is the revenue model for QKS?
It's not tools (We all know that today, look around how many tools 
companies are there?)
Consulting is a big part
Microsoft is a big part.
Python is a big part for the execution engine, this is a new area. The 
Smalltalk VM runs Python 10 to 100x faster. {JMM I should point out the 
Perl and Python folks are working toward having/wanting/needing a 
universal VM}

SmallScript is subset of Smalltalk dialects, not of the frameworks. You 
can migrate frameworks, and it has a lot of features for foreign 
function interoperability.

David then moved on within his slides and talked about the files you 
need to support Smallscript. The point being there are only a few small 
files required.

He then brought up the VisualStudio project for building this and 
explained how the VM starts and worked us thru what happens when the VM 
launches. The execution path is very short and took about 85ms on this 
machine, thus 12 executions a second. A more optimized VM, this was a 
test VM, would run faster. However David pointed out on a heavier loaded 
machine you could have at least a 30ms variation in startup times 
because of system load. But the key point here was that you can run a 
lot of individual scripts per second if required.

Later at lunch David pointed out that perhaps it wasn't clear in the 
presentation that the entire image is built from the class definitions 
at startup, there is NO image. It's all built from the definitions 
really really fast. On termination a module can decide if it must save a 
persistent state, which could be loaded on restarting. In fact If I 
recall correctly he say that a rather large smalltalk image would be 
built by the engine in less than 6 seconds. From nothing to a known 
state on each startup, this is a important concept.

On-ware to DLL hell, well maybe not. .Net get out of this problem 
domain. Components are self describing and have versioning which allows 
you to resolve all the requirements to run an application and to move 
things around without harming the application. Smallscript allows you to 
build small DLLS which are compiled very quickly. Smallscript takes the 
strengths of Smalltalk, it's a simple grammar it's untyped. And it's 
easy to refactor and change versus C or C++. In Smalltalk it was hard to 
deal with the outside, handing a Smalltalk object to an external DLL 
is/was an adventure. In .Net it just gets passed, no wrapping or 
marshalling etc.

Alas at this point I had an errand to run.

-- 
       <http://homepage.mac.com/keithray/resume.html>