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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4