Why I don't use Ruby

ruby-talk
1

For a short period I used Ruby and found that I liked it very much,
but gave it up after ashort while. Every so often I look for a new
language to act as my "second" language, Each time Ruby pops
into mind, but I immediately drop it.

I thought I would explain why so that some of TPTB can think it over
and decide if it might be worth while to make changes.

The first comment I would make is that I base my desires on features
provided in languages created in the functional programming community.
Languages such as Scheme/SML/OCaml/Haskell. I find that these
languages are oriented towards academia and research and often fall
short for serious work. One of the biggest examples is the inability
to provide systems which work the same on Unix and Windows. In
effect most of these systems give short shrift to Windows. I preffer
my code to work more or less the same on both types of OS.

The main thing I am looking for is a basic environment similar to
functional languages. In particular a ( native-code ) compiler and
an extensible REPL. By REPL I mean read-eval-print-loop, a fancy
word for interpreter. To make clear what I want, and why I think
it is a superior approach, I will now explain how it is used.

Typically you open the file you are working on in emacs,vi or
an IDE. ( Typically it would be emacs or vi. The IDEs available
tend to be too primitive. Other editors might do but I am not
aware of them. ) The you split the session into two windows
and start your REPL in one. You edit your file and send one
"line" at a time to the REPL to be evaluated. By line I mean
command. maybe a function definition, a class definition, a method
definition, an assignment to a global variable... basically one
"thought". You have problems so you debug the code. Then
you send it again. Over and over, till it works right. ( Ok sometimes
you have to restart the REPL, because you muck up something
in the envornment. ) Sometimes to figure out what went wrong,
say there is a global list and you want to see what's inside because
you think it's wrong. You switch to the window with the REPL
and you type the command to print the list.

Afdter a while the file is complete. Then you compile it into a
library file or application. This way you get the speed of a compiled
program with the flexibility of an interpreted program. And in
some cases you need the speed. In others you don't. In others
you don't know (eg libwww). Of course it would be nice to be
able to build new REPL with libraries incorporated, or at
least specified on the commandline.

It would also be nice to have an optional core/image.
That way if I run tests where testing uses a lot of data,
I can save images when i debug later stages and
save myself some time initializing.

The reply-to email address is olczyk2002@yahoo.com.
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess,

···

**
Thaddeus L. Olczyk, PhD

There is a difference between
*thinking* you know something,
and *knowing* you know something.

2

This message may be trollish, but it seem it is'nt :slight_smile:

The first comment I would make is that I base my desires on features
provided in languages created in the functional programming community.
Languages such as Scheme/SML/OCaml/Haskell. [..] In
effect most of these systems give short shrift to Windows. I preffer
my code to work more or less the same on both types of OS.

have you tried DrScheme ? The GUI environment is based on wxwindows
and runs quite fine on windows.

The main thing I am looking for is a basic environment similar to
functional languages. In particular a ( native-code ) compiler and
an extensible REPL. By REPL I mean read-eval-print-loop, a fancy
word for interpreter. To make clear what I want, and why I think
it is a superior approach, I will now explain how it is used.

Why do you feel the need for a native code compiler,
Do you expect better performances or something else?

Anyway, about REPL env, that's what IRB is for:

def f
10
end

=> nil

f

=> 10

Typically you open the file you are working on in emacs,vi or
an IDE. ( Typically it would be emacs or vi. The IDEs available
tend to be too primitive. Other editors might do but I am not
aware of them. ) The you split the session into two windows
and start your REPL in one.[..]

I think ruby-mode.el allows this. I usually do this in different
terminals, anyway, but that's quite subjective.

Afdter a while the file is complete. Then you compile it into a
library file or application. This way you get the speed of a compiled
program with the flexibility of an interpreted program. And in
some cases you need the speed. In others you don't. In others
you don't know (eg libwww). Of course it would be nice to be
able to build new REPL with libraries incorporated, or at
least specified on the commandline.

I'm not sure what you intended with the last statement, maybe
irb -r mylib

It's really agreeable that better performance would be nice. I think a
JIT would be ok, anyway.

If you feel that speed is such an important thing in your application
field, and that current C libraries or ruby extension are not a good
fit, I completely agree with you, ruby is not fine.

OTOH IIRC there are some effort to build ruby2c, ruby2asm, and JIT
compilers for ruby. I hope those will mature with time, but I
understand you can't care about them.

It would also be nice to have an optional core/image.
That way if I run tests where testing uses a lot of data,
I can save images when i debug later stages and
save myself some time initializing.

I'm not sure what you mean here. Do you want to freeze the interpreter
in a given state? Or do you feel the need for some serialization
format that can be retrieved at any time fast? (in this case Marshal
could fit, maybe?)

···

il Thu, 01 Jul 2004 04:43:49 -0500, TLOlczyk <olczyk2002@yahoo.com> ha scritto::

3

Hello TLOlczyk,

The main thing I am looking for is a basic environment similar to
functional languages. In particular a ( native-code ) compiler and
an extensible REPL. By REPL I mean read-eval-print-loop, a fancy

The ruby language makes a native compiler almost useless. It's far to
dynamic.

word for interpreter. To make clear what I want, and why I think
it is a superior approach, I will now explain how it is used.

So you mean you want an image based language system like lisp, scheme
or smalltalk.

Right Ruby is not working this way. But it could work this way. I was
experimenting with this feature in my Arachno Ruby IDE. But it is not
possible just for the way many libraries are written.
And trying to convince people to obey to at least a minimal coding
standard is a waste of time, you can't even convince them that every
file needs a

if $0 == __FILE__
   -- to your main stuff here
end

statement around the code body. Otherwise its not useable by a lot of
tools like the refactoring browser, exerb etc.

···

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

4

TLOlczyk <olczyk2002@yahoo.com> wrote in message news:<e2n7e058oliihrdldn41p3ocr5c3qtq6vs@4ax.com>...

[....]

why would anyone care that you are not using Ruby ?

-klaus

5

Obviously, there have already been a number of useful comments about
irb, the Ruby interpreter; it is an invaluable part of my development
and test cycle, as I'm sure it is for many other Ruby users on this
list.

As for the issue of persistent heap images, I agree that such a
feature would be quite useful, especially when coupled with an
interactive interpreter. I've worked in groups that used Common Lisp
as their primary development language, and I have to say that
distributing an application was almost embarassingly easy when
compared to, say, compiling and linking C sources, or installing a
Ruby application with diverse library and version requirements.

For those who haven't had the pleasure, let me give a brief
explanation. Most implementations of Common Lisp (as well as many
Scheme dialects, Smalltalk implementations, and other
functional/research languages) include the ability to perform a dump
of the entire runtime heap memory space into an "image" file. That
snapshot essentially contains the working state of the system, much
like the dump of RAM a laptop saves to disk for "hibernation" mode.

The value of this feature for distribution comes from being able to
then transfer this image file to another system, load it into another
instance of the runtime there, and resume working where you left off
previously. Most implementations also allow you to specify a new
toplevel entry point, allowing you to effectively pick a 'main()'
function of your choosing when creating the image.

The "Prevayler" family of object peristence models are, in effect, a
limited (though incremental, rather than bulk) version of this idea.
By building such peristence into the core runtime, though, you can
trivially distribute new versions of both the core language, and
applications built on top of it.

However, there are issues with this approach. Unlike most Lisps and
Smalltalks, Ruby is not a self-hosting system; the core runtime is
implemented in C, and depends heavily on the system libraries and
memory model of the underlying operating system. By using native
structures like file handles, dynamic libraries, and virtual memory
management pervasively, Ruby has more or less bound itself to the
lifecycle and call conventions of a "native" application.

However, it should be entirely possible to experiment with a limited
form of the global-image class of persistence. There are two main
paths I could see working. The more obvious would be performing a
standard Marshal.dump on every object in the heap, saving the state of
any serializable objects to disk (and allowing them to perform any
cleanup necessary prior to shutdown).

Less trivial, but potentially more interesting, would be to allocate
new objects within mmap'ed address space, (effectively bypassing the
native virtual memory system) which would allow a 'dump' operation to
simply be implemented as a 'sync' on that space. Updates could be
incremental, and have near the same performance as the native OS does
with VM paging.

Anyone with more language implementation experience care to weigh in
on the feasibility of such a hack? I know that several "academic"
languages already implement such functionality, and that as a
garbage-collected language, Ruby should already have most of the
infrastructure necessary to build it again.

Okay, enough rambling. Back to work.

Lennon

6

My REPL looks like this:

irb(main):005:0> test
=> true
irb(main):006:0> load 'foo.rb'
=> true
irb(main):007:0> test
=> true
irb(main):008:0> load 'testcase.rb'
=> true
irb(main):009:0> test
=> true
irb(main):010:0> load 'foo.rb'
=> true
irb(main):011:0> test
=> true
irb(main):012:0> load 'foo.rb'
=> true
irb(main):013:0> test
=> true
irb(main):014:0> load 'testcase.rb'
=> true
irb(main):015:0> test

This is all intermixed with setting and examining particular
variables and data structures. irb history and tab completion
make the process faster than it appears here.

···

--- TLOlczyk <olczyk2002@yahoo.com> wrote:

[...]
The main thing I am looking for is a basic environment similar to
functional languages. In particular a ( native-code ) compiler and
an extensible REPL. By REPL I mean read-eval-print-loop, a fancy
word for interpreter. To make clear what I want, and why I think
it is a superior approach, I will now explain how it is used.

Typically you open the file you are working on in emacs,vi or
an IDE. ( Typically it would be emacs or vi. The IDEs available
tend to be too primitive. Other editors might do but I am not
aware of them. ) The you split the session into two windows
and start your REPL in one. You edit your file and send one
"line" at a time to the REPL to be evaluated. By line I mean
command. maybe a function definition, a class definition, a method
definition, an assignment to a global variable... basically one
"thought". You have problems so you debug the code. Then
you send it again. Over and over, till it works right. ( Ok sometimes
you have to restart the REPL, because you muck up something
in the envornment. ) Sometimes to figure out what went wrong,
say there is a global list and you want to see what's inside because
you think it's wrong. You switch to the window with the REPL
and you type the command to print the list.
[...]

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

7

I totally agree with you.

"gabriele renzi" <surrender_it@remove.yahoo.it> schrieb im Newsbeitrag
news:1rp7e0dc0bgkm0t82r1rk2ta126ut75iuf@4ax.com...

il Thu, 01 Jul 2004 04:43:49 -0500, TLOlczyk <olczyk2002@yahoo.com> ha
scritto::

This message may be trollish, but it seem it is'nt :slight_smile:

>The first comment I would make is that I base my desires on features
>provided in languages created in the functional programming community.
>Languages such as Scheme/SML/OCaml/Haskell. [..] In
>effect most of these systems give short shrift to Windows. I preffer
>my code to work more or less the same on both types of OS.

have you tried DrScheme ? The GUI environment is based on wxwindows
and runs quite fine on windows.

>The main thing I am looking for is a basic environment similar to
>functional languages. In particular a ( native-code ) compiler and
>an extensible REPL. By REPL I mean read-eval-print-loop, a fancy
>word for interpreter. To make clear what I want, and why I think
>it is a superior approach, I will now explain how it is used.

Why do you feel the need for a native code compiler,
Do you expect better performances or something else?

Anyway, about REPL env, that's what IRB is for:
>> def f
>> 10
>> end
=> nil
>> f
=> 10
>>

>Typically you open the file you are working on in emacs,vi or
>an IDE. ( Typically it would be emacs or vi. The IDEs available
>tend to be too primitive. Other editors might do but I am not
>aware of them. ) The you split the session into two windows
>and start your REPL in one.[..]

I think ruby-mode.el allows this. I usually do this in different
terminals, anyway, but that's quite subjective.

>
>Afdter a while the file is complete. Then you compile it into a
>library file or application. This way you get the speed of a compiled
>program with the flexibility of an interpreted program. And in
>some cases you need the speed. In others you don't. In others
>you don't know (eg libwww). Of course it would be nice to be
>able to build new REPL with libraries incorporated, or at
>least specified on the commandline.

I'm not sure what you intended with the last statement, maybe
irb -r mylib

It's really agreeable that better performance would be nice. I think a
JIT would be ok, anyway.

If you feel that speed is such an important thing in your application
field, and that current C libraries or ruby extension are not a good
fit, I completely agree with you, ruby is not fine.

OTOH IIRC there are some effort to build ruby2c, ruby2asm, and JIT
compilers for ruby. I hope those will mature with time, but I
understand you can't care about them.

And, for real high performance requirements it's likely that Ruby -
whether compiled to native or whatever - will not reach the mark that can
be set languages like C and C++. The dynamic nature does cost some
performance. If performance is paramount one either has to use another
language or write an extension that does the performance critical things.

>It would also be nice to have an optional core/image.
>That way if I run tests where testing uses a lot of data,
>I can save images when i debug later stages and
>save myself some time initializing.

I'm not sure what you mean here. Do you want to freeze the interpreter
in a given state? Or do you feel the need for some serialization
format that can be retrieved at any time fast? (in this case Marshal
could fit, maybe?)

I'd use Marshal for that. I even once wrote a function that automatically
loads the marshalled representation of a file if that is unchanged and
otherwise loads the file. Marhshall is pretty fast indeed.

Regards

    robert

8

"inf-ruby.el" provides exactly what you want. Then you indeed split
the session in 2 windows in emacs, one running irb, the other one
editing your source. "inf-ruby.el" provides a couple of functions (you
should look into the elisp file) to send a region/block/definition to
the running irb and can additionally send focus to the irb window.
I find it very handy.

Ruben

···

At Thu, 1 Jul 2004 19:47:54 +0900, gabriele renzi wrote:

>Typically you open the file you are working on in emacs,vi or
>an IDE. ( Typically it would be emacs or vi. The IDEs available
>tend to be too primitive. Other editors might do but I am not
>aware of them. ) The you split the session into two windows
>and start your REPL in one.[..]

I think ruby-mode.el allows this. I usually do this in different
terminals, anyway, but that's quite subjective.

9

I've never used that code snippet... and I've never had problems with exerb.

Why would it cause problems with exerb?

-Rich

···

And trying to convince people to obey to at least a minimal coding
standard is a waste of time, you can't even convince them that every
file needs a

if $0 == __FILE__
   -- to your main stuff here
end

statement around the code body. Otherwise its not useable by a lot of
tools like the refactoring browser, exerb etc.

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

10

Klaus Momberger wrote:

TLOlczyk <olczyk2002@yahoo.com> wrote in message
news:<e2n7e058oliihrdldn41p3ocr5c3qtq6vs@4ax.com>...
> [....]

why would anyone care that you are not using Ruby ?

As long as we not talking about comments from a troll, it can be very useful
to know why as we factor such things (as appropriate) into future plans.

Curt

11

[...]

why would anyone care that you are not using Ruby ?

-klaus

Perhaps because we would like to see more people using Ruby? Or even
just because the sort of people who use "fringe" languages like Ruby
tend to enjoy discussion of obscure details of implementation and
semantics?

Lennon

···

On Fri, 2 Jul 2004 01:42:55 +0900, Klaus Momberger <klausm0762@yahoo.de> wrote:

12

Klaus Momberger wrote:

TLOlczyk <olczyk2002@yahoo.com> wrote in message news:<e2n7e058oliihrdldn41p3ocr5c3qtq6vs@4ax.com>...

[....]
   
why would anyone care that you are not using Ruby ?

The Ruby community may not care if any one person decides not to use Ruby (unless, say, that one person were Matz).

But it's in the interest of language development to hear when people have problems using the Ruby.

Most of the time the reason is a bit more mundane: lack of a specific library of particular interest; low recognition value among so-called IT managers who only know what they read in E-Week; syntax that conflicts with some previously divined notion of the One True Way. That sort of thing.

In some cases the concerns are legit (that is, they address issues that are likely of interest to more than a handful of users); sometimes theses issues can be addressed. And sometimes it is worth the trouble to address a correctable, legitimate issue.

My recollection is that most of the so-called complaints come from folks with a C/Java/Python/Perl background and are unhappy when Ruby doesn't always map to their internal world view. Most of these have been discussed to death; a suggestion to search ruby-talk is usually the best response.

I'm more interested when somebody from a functional or logic programming background gives Ruby a whirl and finds fault. It may, again, be an issue of cognitive dissonance, but there is still something to be learned from it.

Unless someone is trolling (and it's not always easy to tell) I appreciate the effort to tell this crowd about possible ways to improve the language.

James

13

Hello Lennon,

However, there are issues with this approach. Unlike most Lisps and
Smalltalks, Ruby is not a self-hosting system; the core runtime is
implemented in C, and depends heavily on the system libraries and
memory model of the underlying operating system. By using native
structures like file handles, dynamic libraries, and virtual memory
management pervasively, Ruby has more or less bound itself to the
lifecycle and call conventions of a "native" application.

Sorry but here you miss the point, using file handles, DLL's and
native structure does not mean anything for implementing an image
based language (it's not a heap image by the way).

However, it should be entirely possible to experiment with a limited
form of the global-image class of persistence. There are two main
paths I could see working. The more obvious would be performing a
standard Marshal.dump on every object in the heap, saving the state of
any serializable objects to disk (and allowing them to perform any
cleanup necessary prior to shutdown).

At the moment you can't dump methods and classes. So this would
require a lot of work. We are not talking about data persistence here.

Less trivial, but potentially more interesting, would be to allocate
new objects within mmap'ed address space, (effectively bypassing the
native virtual memory system) which would allow a 'dump' operation to
simply be implemented as a 'sync' on that space. Updates could be
incremental, and have near the same performance as the native OS does
with VM paging.

The current problem is the serialization of the program stack because
there native C function calls and ruby calls are mixed. Okay we could
dump only if there is nothing on the stack (which is the case when the
program exits normally), and return to a special "main" function on
the next start, but this is normally not that what you want in an
image based language.

Anyone with more language implementation experience care to weigh in
on the feasibility of such a hack? I know that several "academic"
languages already implement such functionality, and that as a
garbage-collected language, Ruby should already have most of the
infrastructure necessary to build it again.

I think the technical implementation is not the difficult thing here,
its the current state of libraries.

Oh yes, i implemented an LISP system in about 50000 lines of Assembler
code many many years ago. The core system, the VM, is not difficult to
write, but we would need a complete rewrite of Ruby.

···

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

14

Sigh. The way things are going today, I've finally gotten to Usenet
today, but on the radio is a very good discussion of the American
Revolution. So I can't pay attention to the whole thread, but
I will discuss this part.

Let us as an example look at a program that looks at a directory of
Web pages, and traces through them. If it cannot find a link to a
certain page, then it creates a link on a page in a prescribed manner.

You've written the program and tested it on a small data set.
Now you want to test it on a large data set. It fails miserably
and you try to debug.
Phase one of the program gets a list of all the files in the directory
( recursively ).
Phase two is to scan the root files for hrefs. Then scan the files in
the hrefs. Then ... untill there are no more files to scan.
Phase three is to pick some file you didn't reach and create a link to
it.

So you work on Phase one and get it to run.
Then you work on Phase two. But it takes Phase one
ten minutes to run. So each time you test a fix in phase two
it takes at least ten minutes to run.

So you save an image at the end of phase one. Each time
you test phase two, you load the image from phase one
and just test phase two. Save ten minutes on each test run.

The reply-to email address is olczyk2002@yahoo.com.
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess,

···

On Thu, 01 Jul 2004 10:45:54 GMT, gabriele renzi <surrender_it@remove.yahoo.it> wrote:

It would also be nice to have an optional core/image.
That way if I run tests where testing uses a lot of data,
I can save images when i debug later stages and
save myself some time initializing.

I'm not sure what you mean here. Do you want to freeze the interpreter
in a given state? Or do you feel the need for some serialization
format that can be retrieved at any time fast? (in this case Marshal
could fit, maybe?)

**
Thaddeus L. Olczyk, PhD

There is a difference between
*thinking* you know something,
and *knowing* you know something.

15

Hello richard,

I've never used that code snippet... and I've never had problems with exerb.

Why would it cause problems with exerb?

One way to use "exerb" is to start your program and track the
necessary files that are required to build the final exe. But if your application
instead starts its main tasks and go into application loop and
does not return it's not nice. Especially if this happens in one of
the required libraries. In 90% percent of the cases it works fine, but
this is the problem, that this means it fails in 10% of all usecases.

Same is true with "rbb" the refactoring browser.

···

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

16

yes. yes.

regards.

-a

···

On Fri, 2 Jul 2004, Lennon Day-Reynolds wrote:

Perhaps because we would like to see more people using Ruby? Or even just
because the sort of people who use "fringe" languages like Ruby tend to
enjoy discussion of obscure details of implementation and
semantics?

Lennon

--

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
A flower falls, even though we love it;
and a weed grows, even though we do not love it. --Dogen

===============================================================================

17

Robert Klemme a écrit :
(snip)

And, for real high performance requirements it's likely that Ruby -
whether compiled to native or whatever - will not reach the mark that can
be set languages like C and C++. The dynamic nature does cost some
performance.

Just for the record, Common Lisp is (more or less) as dynamic as Ruby, and some implementations produce really good and fast native code...
(ok, perhaps not as fast as C !-)
(snip)

bruno

18

Forgot to copy the list on this...sorry to anyone who was hoping this
thread would just die.

Lothar,

Thanks for "weighing in." You're definitely right about many of the
corrections, but I also think there are a few places where we're just
getting mixed up on terminology (probably due to my admittedly
"amateur" knowledge of programming language implementation).

Hello Lennon,

[...]

Sorry but here you miss the point, using file handles, DLL's and
native structure does not mean anything for implementing an image
based language (it's not a heap image by the way).

I'm confused that on the one hand, you would say that native libraries
and data structures are not the problem, and on the other that the
mixing of Ruby and C stack preclude serialization. I think of the two
as more or less equivalent -- use native structures and calling
conventions, and you're tied to that execution model.

(BTW, what is the correct term for the dumped image? "Heap image" was
the standard term used within the language implementation group I
worked for a few years ago, who included old Lucid Lisp core
developers, but it's possible I'm mis-using it.)

[...]

At the moment you can't dump methods and classes. So this would
require a lot of work. We are not talking about data persistence here.

Sorry, I'm thinking in terms of Lisp, where code simply *is* a
special-case type of data. I'm curious as to what about the internal
representation of Ruby code objects is imcompatible with normal data
serialization methods -- is it just that the code isn't constructed in
a relocatable way?

[...]

The current problem is the serialization of the program stack because
there native C function calls and ruby calls are mixed. Okay we could
dump only if there is nothing on the stack (which is the case when the
program exits normally), and return to a special "main" function on
the next start, but this is normally not that what you want in an
image based language.

See my contents above for my confusion on this point. I don't disagree
that freely mixing the Ruby and C stacks causes problems for global
persistence, but I do wonder how continuations are implemented in that
case. Are they just using setjmp/longjmp?

Again, my experience with Common Lisp and Scheme colored my
interpretation here; when generating an image, you actually *did*
specify a toplevel function to enter at start, though most had a
default setting of the REPL mainloop.

[...]

I think the technical implementation is not the difficult thing here,
its the current state of libraries.

That's always the critical issue with major language implementation
changes; if you core API compatibility, you effectively create a new
language from the perspective of library authors.

Oh yes, i implemented an LISP system in about 50000 lines of Assembler
code many many years ago. The core system, the VM, is not difficult to
write, but we would need a complete rewrite of Ruby.

I'm sorry; perhaps I got carried away in my earlier comments about the
amount of work involved in adding image-based persistence to the
existing Ruby runtime. I was thinking more of the overall object
model, not the nitty-gritty details of maintaining low-level
compatibility.

It doesn't seem quite as bleak as "needing a complete rewrite,"
though. There's even a precedent in "that other language". (i.e., the
Python core developers seperated the Python and C stacks so they could
implement generators).

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

Thanks for the additional information,

Lennon

···

---------- Forwarded message ----------
On Fri, 2 Jul 2004 01:03:23 +0200, Lothar Scholz <mailinglists@scriptolutions.com> wrote:

19

Doh! Should have checked the source...I could have answered one of my
own questions:

Q: Do continuations use setjmp/longjmp?

Lennon

···

A: No, they use threads. But threads use setjmp/longjmp.

20

That's certainly the only reason I'm on the ruby lists. I haven't had a
chance to write any serious ruby code in a year and a half, but since I
love programming so much, and especially in ruby, the mailing lists of
a young language such as ruby provide insightful looks into the heart
of what coding really is.

That or I'm just a huge nerd.

···

On Fri, 2 Jul 2004 04:13:51 +0900, Lennon Day-Reynolds wrote:

Perhaps because we would like to see more people using Ruby? Or even
just because the sort of people who use "fringe" languages like Ruby
tend to enjoy discussion of obscure details of implementation and
semantics?

--
Rando Christensen
eyez@illuzionz.org