On 15 January 2012 09:40, Gerry Weaver <[email protected]> wrote: > Hi Frank, > >> I have a minor nit here: it's not an image that's the problem, it's >> living in the image. > > Yes. This is pretty much what I was thinking about. Thanks for the > clarification. > >> Lisps are image-based systems, but one tends to construct one's >> working image from a base image + extras. SBCL's SAVE-LISP-AND-DIE >> lets you turn that image into an executable. I don't think anyone >> would particularly care - or even know - that their TextLint is, on >> the inside, some small image + VM. In short, I don't think it's a lot >> of work to get something ostensibly a native executable, and I don't >> think that compiling to a native executable's particularly valuable. >> (Java applications aren't compiled to a native executable, for >> instance!) > > Firstly, for many reasons, I think Java is the absolute worst thing that has > ever happened to software development. However, it is a testament to the > power of good marketing ;-) I'm going to resist going on a rant. It would > suffice to say that the packaging of Java apps is one of the many things that > I dislike.
Sure. I'm suggesting that packaging a VM + image isn't necessarily the end of the world and, in particular, isn't necessarily an obstacle to developer adoption. (But also, we have loads of Pharo images packaged up as executables - Pharo itself, Seaside, Helvetia, and so on.) > I like native executables, because they are so much easier to package and > distribute. They also play nicer with the OS in terms of shared libraries > etc. Each OS already has a well known mechanism for dealing with them. There > just... more comfortable. The ability to embed the VM solves this nicely as > well (ie; ECL, Gambit-C, etc.) It would be pretty cool to have multiple > instances of the Smalltalk VM running in an embedded fashion. > > > > Thanks, > Gerry > > > >
