I've only read a few pages of the Slate site so far but it's brought back fond memories of image based systems I played with in the 80s.
(I've done a total of about 5 years worth of professional programming over the last 30 years, primarily assembler and BCPL in the 80s and some Pascal and Perl in the 90s; I've played with many langs -- lisp, snobol, the toy smalltalkish systems Smalltalk/V and Actor, etc. -- in the late 80s; I'm currently a Perl 6 "enthusiast" -- my periodic HN search for "perl6" caught your mention of it.)
If you have little to no idea what NQP [1] is, then my question is:
What are the characteristics that a language/compiler/runtime/library have to have to adequately support an image based approach? I'm imagining OO; source code as objects; running code as objects; object serialization; incremental compilation; etc. I know I should research this myself (and will, now you've rekindled my interest) but I think your off-the-cuff answer will be an interesting and valuable start for me and perhaps others.
Or, in the unlikely event that you DO know what NQP is, then my question is:
Is it reasonable to think about building an image based system using the NQP toolchain?
I've heard of NQP but haven't dug into it. I suppose you could, but I'd estimate the effort as higher than for say Rubinius which has been tracking a Smalltalk model since its inception.
Really, an image is just a heap snapshot with roundtrip serialization possibilities. You want to be able to serialize all the operational data structures, so the model of data has to sort of respect a certain abstraction layer. One consideration is whether the image has to be portable; word-size of 32 or 64 bits, or under endianness. This has strong implications about what kind of code you can keep in the image.
You also would want hooks for startup and shutdown if you expect to be able to snapshot a heap and then restart it under a debugger, say, and get the runtime circumstances that are relevant, like open sockets and files, dynamic-linked libraries, and so on.
I am now really curious about building an image-based edition of Rakudo Perl 6. I'm going to ask about this on #perl6 and reply here if anything comes of it.
Thanks again. May the eggnog season serve you well.
I've only read a few pages of the Slate site so far but it's brought back fond memories of image based systems I played with in the 80s.
(I've done a total of about 5 years worth of professional programming over the last 30 years, primarily assembler and BCPL in the 80s and some Pascal and Perl in the 90s; I've played with many langs -- lisp, snobol, the toy smalltalkish systems Smalltalk/V and Actor, etc. -- in the late 80s; I'm currently a Perl 6 "enthusiast" -- my periodic HN search for "perl6" caught your mention of it.)
If you have little to no idea what NQP [1] is, then my question is:
What are the characteristics that a language/compiler/runtime/library have to have to adequately support an image based approach? I'm imagining OO; source code as objects; running code as objects; object serialization; incremental compilation; etc. I know I should research this myself (and will, now you've rekindled my interest) but I think your off-the-cuff answer will be an interesting and valuable start for me and perhaps others.
Or, in the unlikely event that you DO know what NQP is, then my question is:
Is it reasonable to think about building an image based system using the NQP toolchain?
Thank you offering AMA. :)
[1] https://github.com/perl6/nqp