python on the smalltalk VM

[Dave LeBlanc]

Checking the QKS website, SmallScript (aka Smalltalk 2000) isn't
available yet (4th Q 2000 they say! - looks like the schedule
slipped).

There seems to be another product called Smallscript from the UK
that's $485/user. Seems to be some sort of runtime for IBM Visual Age
Smalltalk.

Dave LeBlanc

On Thu, 19 Apr 2001 16:11:43 GMT, Keith Ray
<k1e2i3t4h5r6a7y at 1m2a3c4.5c6o7m> wrote:

>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>