On Mon, 19 Aug 2002 05:18:44 GMT, Albert Wagner <alwagner / tcac.net>
wrote:

>On Sunday 18 August 2002 05:44 pm, Thaddeus L. Olczyk wrote:
>> On Sun, 18 Aug 2002 15:39:31 -0500, "Shashank Date" <ADATE / kc.rr.com>
><snip>
>> And what is the objection to a core?
>> A core is just a snapshot of the runtime.
>
>Yes, usually a very, very, large snapshot.  And usually full of crap that is 
>not needed for the current project.
>
1) very,very,very large is a relative term. Checking clisp cores I
have, I see that clisp generates cores of roughly 7M core, and cmucl
generates a 20M core. VW generates a 15M core.

In these days of 1/2G-1G RAM and 40G hard drives on what are 
relatively small computers those are not big. And they can be made
smaller.

As you say they are usually full of all sorts of crap that you don't
need. Why? Because it's often herd to find and load the individual
packages. So ST preloads them for you ( lisp is a bit more circumspect
about it ).

In Ruby there is already a system that can do that easily. It's called
"require". With this you can start with a core that should be
relatively small ( the core and vm together would probably not
be any bigger than 2 times the size of the ruby interpreter ).

>> It is pretty handy when it takes you a half hour to start up ruby
>> and get it to the point where you were last time.
>
>Wow.  What are you doing that it takes you a half hour to start up ruby?
>
Real programming. 
People ask me to write code for them that does things that take a long
time ( hours, days, weeks, months years ) for them to do.
( After all it hardly makes sense for them to ask me to write code
that does things slower than they would. )

Even with a computer these things often take time. For exmple I
recently wrote code that takes a network mounted file system, reads
all the files in the system, starts with a base HTML index file
generates a list of all hrefs and src in the HTML file and all linked
hrefs ( ie a spider ). It compared the two and put in links ( at the
appropriate spot ) to the unreferenced files. It took several hours to
run. Further when I was debugging the last few little bits, it took 
about an hour and a half before it would hit the bugs. Lisp's core
saved me there.

I know that I would not want to write this program in a language that
did not have a core.

BTW I did not say it takes half an hour to start Ruby. I said it can
take half an hour to start Ruby and get to the point where I left off.
( Or to the last bug I fixed. )

Since your not clear about this point it's obvious that while you 
may have used languages with cores, you never really understood how to
do things in them.
><snip>
>
>Don't get me wrong.  I love ST: browsing, debugging, refactoring, etc.  But to 
>me the image was a big pain in the butt.
>
Why should it be a pain?
If you don't want extra images, don't keep them. Keep your original
image ( and back it up somewhere in case you do accidentally overwrite
it -- better start Lisp/ST/Ruby in a script which takes your backup
and overwrites the original ). File your changes in and out and you
don't have to deal with images ( except for the dialog boxes, such
as "You are leaving but have unsaved changes. Do you want to save?" ).

IT's also obvious that you have never used an editor or environment
that runs your vm as an inferior process. In ST you program by
modifying your environment. In Lisp you program by working in your
editor and loading your file. Then seeing where it stops working
correctly modifying your file sending the new function ( assuming it
was a function you modified ) to the vm where you pick off where you
left off. You don't have to do much work to keep all your code in a
file. That's the natural state. ( Whereas in ST you have to make an
effeort to keep things in a file, ie FIleout or Parcel out. ) 

That's already the way most people do Ruby. It wouldn't change much
for the programmer, except to give him a command to save an image
and a commandline option to start with a different image than the
standard.