On 6 Oct 2010, at 13:11, Rick DeNatale wrote:
> Languages differ in much more important and subtle ways than their
> syntax and surface-level semantics.  Those differences lead to very
> different architectures/strategies or whatever you want to call it.
>=20
> Converting an OO program written in, say Ruby, requires adaptation of
> not only the language syntax, but the underlying class library, if you
> are converting to C++, you need to figure out what to do about the
> usage in the Ruby program of base classes, you do probably have
> several choices of C++ libraries providing things like collection
> classes, all of which will mismatch the interfaces of their Ruby
> equivalents, probably in frightening ways.
>=20
> Replace Smalltalk/Ruby message send semantics with C++ virtual
> function calls, and the constraints change. Move the burden of
> accounting for and reclaiming the memory used by objects from a GC to
> the programmer and things get complicated, and often the performance
> of the hand-written memory management (copy constructors, reference
> counts ...) starts making the performance 'win' of switching horses
> much less certain.
>=20
> This is Greenspun's tenth rule of programming at work.
> http://philip.greenspun.com/research/

Funnily enough this is one of the inspirations behind my golightly[0] =
project: if every significant program I write will end up with an ad hoc =
implementation of Lisp (or more often than not Lisp and several other =
languages) then why not just use an abstract platform that allows me to =
plug together Lisp machines, Forth machines, Ruby machines etc. and have =
them all operate on the same underlying type space?

This is subtly different to the traditional virtual machine approach as =
by taking seriously the notion of language agnosticism you end up with =
less a single machine and more a set of components that can be plugged =
together to build an infinite variety of machines that are each better =
suited to the particular tasks they're used for than a general-purpose =
VM. I suspect it's probably similar to the software IC concept you =
mentioned over on Core recently, but with the added wrinkle that I'm =
interested in building in generalised type space transformations if I =
can get my head around them. These would effectively provide a means of =
JIT translation between different language type models, including =
assembler-level type expression where practical. I suspect a big chunk =
of the winter is likely to be spent researching current developments in =
compiler theory in hopes someone else has already solved this problem... =
and if they haven't perhaps it's time I went back to Uni and got my =
Doctorate :)


Ellie

[0] http://golightly.games-with-brains.net/

Eleanor McHugh
Games With Brains
http://feyeleanor.tel
----
raise ArgumentError unless @reality.responds_to? :reason