What Ruby needs

I do not have any problem with item 1) on your wish list as long as I don’t
loose the dynamic nature of Ruby.
But with 2) I am afraid, I have to disagree. For me the “Ruby attraction”
is stronger * because of * (and not inspite of )
its independence from the image/core. Again, that is just me !

Wonder what other *** infuential **** Rubyists think …

– Shanko

“Thaddeus L. Olczyk” olczyk@interaccess.com wrote in message
news:3d61fe91.348210671@nntp.interaccess.com

···

I use Ruby quite often for scripting and what use it more often for
general stuff except that it has two things missing:

  1. A compiler. Something that takes Ruby code down to as fast as it
    can go ( something like the compilers that come with some Lisps
    and with OCaml).
  2. An image/core like Smalltalk and Lisp where I can define things
    then save core and pick up where I left off later.

Wonder what other *** infuential **** Rubyists think …
Oops ! Here is a typo: ^^^^^^^ was supposed to be “influential”

···

“Thaddeus L. Olczyk” olczyk@interaccess.com wrote in message
news:3d61fe91.348210671@nntp.interaccess.com

I use Ruby quite often for scripting and what use it more often for
general stuff except that it has two things missing:

  1. A compiler. Something that takes Ruby code down to as fast as it
    can go ( something like the compilers that come with some Lisps
    and with OCaml).
  2. An image/core like Smalltalk and Lisp where I can define things
    then save core and pick up where I left off later.

I do not have any problem with item 1) on your wish list as long as I don’t
loose the dynamic nature of Ruby.
Both OCaml and Lisp are very dynamic. Some might argue that these are
the most dynamic languages around yet they are able to compile down to
very tight code.

ST is also dynamic but does not compile down as tightly. However I am
not convinced that this is a necessity, but rather that STers for the
most part don’t care enough to exert the effort to get code that
tight.

But with 2) I am afraid, I have to disagree. For me the “Ruby attraction”
is stronger * because of * (and not inspite of )
its independence from the image/core. Again, that is just me !

And what is the objection to a core?
A core is just a snapshot of the runtime.
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.

···

On Sun, 18 Aug 2002 15:39:31 -0500, “Shashank Date” ADATE@kc.rr.com wrote:

Wonder what other *** infuential **** Rubyists think …

– Shanko

“Thaddeus L. Olczyk” olczyk@interaccess.com wrote in message
news:3d61fe91.348210671@nntp.interaccess.com

I use Ruby quite often for scripting and what use it more often for
general stuff except that it has two things missing:

  1. A compiler. Something that takes Ruby code down to as fast as it
    can go ( something like the compilers that come with some Lisps
    and with OCaml).
  2. An image/core like Smalltalk and Lisp where I can define things
    then save core and pick up where I left off later.

I totally agree. I did ST exclusively for 15 years. But Ruby drew me away
BECAUSE it was not image based.

···

On Sunday 18 August 2002 03:44 pm, Shashank Date wrote:

I do not have any problem with item 1) on your wish list as long as I don’t
loose the dynamic nature of Ruby.
But with 2) I am afraid, I have to disagree. For me the “Ruby attraction”
is stronger * because of * (and not inspite of )
its independence from the image/core. Again, that is just me !

> 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.

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?

Don’t get me wrong. I love ST: browsing, debugging, refactoring, etc. But to
me the image was a big pain in the butt.

···

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

I think the current trend is to move away from images.
I looked at SmallScript lately and there David Simmons
also points out that on purpose he did not go for images.

Bye,
Armin.

···

Am Montag, 19. August 2002 06:57 schrieben Sie:

But with 2) I am afraid, I have to disagree. For me the “Ruby
attraction” is stronger * because of * (and not inspite of )
its independence from the image/core. Again, that is just me !

I totally agree. I did ST exclusively for 15 years. But Ruby drew me away
BECAUSE it was not image based.


Armin Roehrl, http://www.approximity.com
Rubybuch: http://approximity.com/rubybuch/

Agile Entwicklerkonferenz: 22. und 23.10 in Nürnberg.

I do not have any problem with item 1) on your wish list as long as I don’t
loose the dynamic nature of Ruby.
Both OCaml and Lisp are very dynamic. Some might argue that these are
the most dynamic languages around yet they are able to compile down to
very tight code.

But OCaml is strongly typed.

Gergo

±[Kontra, Gergely @ Budapest University of Technology and Economics]-+

    Email: kgergely@mcl.hu,  kgergely@turul.eet.bme.hu          |

URL: turul.eet.bme.hu/~kgergely Mobile: (+36 20) 356 9656 |
±------“Olyan langesz vagyok, hogy poroltoval kellene jarnom!”-------+
.
Magyar php mirror es magyar php dokumentacio: http://hu.php.net

> 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.

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.

···

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

“Kontra, Gergely” kgergely@mlabdial.hit.bme.hu wrote in message
news:Pine.LNX.4.21.0208271744580.30287-100000@mlabdial.hit.bme.hu…

I do not have any problem with item 1) on your wish list as long as I
don’t
loose the dynamic nature of Ruby.
Both OCaml and Lisp are very dynamic. Some might argue that these are
the most dynamic languages around yet they are able to compile down to
very tight code.

But OCaml is strongly typed.

And very much static, not dynamic…

Thaddeus L. Olczyk wrote:

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. )

This in itself doesn’t convince me you need a core. If you keep program
state in persistable objects, you can just dump them. Of course if you
use singletons or dynamically generated procs, you will have some
difficulty…

And you think persistance is instantaneous?

···

On Mon, 19 Aug 2002 18:20:14 GMT, Joel VanderWerf vjoel@PATH.Berkeley.EDU wrote:

Thaddeus L. Olczyk wrote:

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. )

This in itself doesn’t convince me you need a core. If you keep program
state in persistable objects, you can just dump them. Of course if you
use singletons or dynamically generated procs, you will have some
difficulty…

Thaddeus L. Olczyk wrote:

···

On Mon, 19 Aug 2002 18:20:14 GMT, Joel VanderWerf > vjoel@PATH.Berkeley.EDU wrote:

Thaddeus L. Olczyk wrote:

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. )

This in itself doesn’t convince me you need a core. If you keep program
state in persistable objects, you can just dump them. Of course if you
use singletons or dynamically generated procs, you will have some
difficulty…

And you think persistance is instantaneous?

I guess that’s just my perspective. For me, simulations can take hours
to evolve, but the objects can be persisted in seconds. I can imagine
otherwise, though.

In simulations you have manymany objects which are constantly
destroyed and created ( unless you recycle objects, but even then
the recycling dominates ) that’s in part why they take so long. Only
a small percantage of the total objects in existance over the lifetime
of a program need be persisted at any moment to restore the state.

In most programs the lifetime of an object is a signifcant percentage
( at least 10% ) of the program as a result at any time a large
percentage of total objects is present and need to be persisted.
Therefore the persistence and especially the restore ( where the
objects have to be recreated ) mechanisms take almost as long
as the Method of “run till you get to the desired point”.

···

On Tue, 20 Aug 2002 17:29:58 GMT, Joel VanderWerf vjoel@PATH.Berkeley.EDU wrote:

Thaddeus L. Olczyk wrote:

On Mon, 19 Aug 2002 18:20:14 GMT, Joel VanderWerf >> vjoel@PATH.Berkeley.EDU wrote:

Thaddeus L. Olczyk wrote:

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. )

This in itself doesn’t convince me you need a core. If you keep program
state in persistable objects, you can just dump them. Of course if you
use singletons or dynamically generated procs, you will have some
difficulty…

And you think persistance is instantaneous?

I guess that’s just my perspective. For me, simulations can take hours
to evolve, but the objects can be persisted in seconds. I can imagine
otherwise, though.