--------------030405050000010400020005
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Personally, I think languages are about the right tool for the job, and 
Perl, Python and Ruby have nicely proven that dynamic file-based 
scripting languages are more then sufficient for a huge variety of 
programming tasks. If you are looking for a secondary tool-language, I 
can't imagine images, native compilers, and REPL being so critical as to 
drop Ruby.  What better options are there? And the points about native 
compilers in the responses are well put- it's a trade off, and in the 
Ruby world you can drop into C where you need to (not ideal, but 
sufficient). As Donald Knuth put it, "premature optimization is the root 
of all evil".

A question back to the original poster: I think that many Rubyists and 
Pythonists return to native compiled languages etc. only to drop them 
because the loss of productivity is too painful and costly. What effects 
do the problem domains you code in have on this tradeoff, and what 
solutions have you found?

Images would be nice, but the scale of most Ruby programs I write, and 
the methods that I write them by, don't make me lament them too much.  
One epiphany test driven development has produced in programmers is that 
tests drive the design, forcing good design early and often- e.g. the 
common statement that TDD isn't really about testing.

The reason for this is that unit testability requires clean interfaces, 
strong cohesion, loose coupling- i.e. good modular code. Constantly 
subjecting code to testing from the start forces continual design 
decisions and refactoring to maintain testability, and the modularity is 
easier to maintain as a result.

If your code requires 10 minutes to get to a certain point, and you 
can't easily capture that state with a data-only dump (e.g. Marshal or 
YAML), and then continue testing from that point, that would be a good 
motivation to refactor.  However, if TDD hasn't been followed up to that 
point, the code may be hard to seperate due to the design debt built up 
by not having the code constantly challenged by small tests (my solution 
there is to use log4x to due a pseudo-design-by-contract, make core 
domain classes invariant, elimate trival singletons/globals, and then 
find a couple of good "cut" points to get pseudo-modularity, and then 
try to use TDD going forward).

(Aside: Personally, I learned more about design and design patterns via 
TDD and refactoring in six months then I did in 5 years of pattern 
reading. In my real world career, the problems and problem domains I 
coded tended to preclude writing the same program multiple times and 
personally trying various design approaches. And the nature of 
traditional coding practice is that the early design decisions tend to 
stick.  So most projects get stuck with marginal designs. The nature of 
TDD/refactoring and there emergent design practices is that you get to 
see broken/fixed design elements continually in the same coding process, 
and the more elegant and robust end product result in a much more 
learning intense experience).

I guess the short summary to my long-winded point is that unit-tests and 
TDD somewhat obviate the need for images from a development process, and 
I think other responses indicated that REPL is well handled in Ruby and 
that the speed issue is well enough handled by using C to provide point 
optimization where necessary (in clear recognization that certain 
problems and problem domains would find this insufficient).

Regards.
Nick

TLOlczyk wrote:

>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?)
>>    
>>
>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,
>
>**
>Thaddeus L. Olczyk, PhD
>
>There is a difference between
>*thinking* you know something,
>and *knowing* you know something.
>
>  
>

--------------030405050000010400020005--