Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Why I don't use Ruby.

Reply
Thread Tools

Why I don't use Ruby.

 
 
Lennon Day-Reynolds
Guest
Posts: n/a
 
      07-01-2004
Forgot to copy the list on this...sorry to anyone who was hoping this
thread would just die.

---------- Forwarded message ----------

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

On Fri, 2 Jul 2004 01:03:23 +0200, Lothar Scholz
<(E-Mail Removed)> wrote:
>
> 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


 
Reply With Quote
 
 
 
 
Lennon Day-Reynolds
Guest
Posts: n/a
 
      07-01-2004
Doh! Should have checked the source...I could have answered one of my
own questions:

Q: Do continuations use setjmp/longjmp?
A: No, they use threads. But threads use setjmp/longjmp.

Lennon


 
Reply With Quote
 
 
 
 
Rando Christensen
Guest
Posts: n/a
 
      07-02-2004
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?


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.

--
Rando Christensen
http://www.velocityreviews.com/forums/(E-Mail Removed)


 
Reply With Quote
 
TLOlczyk
Guest
Posts: n/a
 
      07-02-2004
On Thu, 01 Jul 2004 10:45:54 GMT, gabriele renzi
<(E-Mail Removed)> 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 (E-Mail Removed).
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.
 
Reply With Quote
 
Bill Kelly
Guest
Posts: n/a
 
      07-02-2004

From: "TLOlczyk" <(E-Mail Removed)>
> 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.


Although different than saving the whole program image,
It's pretty to load/save entire object hierarchies in
Ruby... For ex:

# A little boilerplate...

require 'yaml/store'
ystore = YAML::Store.new("my_persistent_data")

# At the end of phase one, we'll have our file list,
# which we can persist as easily as:

ystore.transaction { ystore["filelist"] = phase_one_filelist }

# At the beginning of phase two, we can load it:

phase_one_filelist = ystore.transaction { ystore["filelist"] }


. . This would allow phase 1 and 2 to be totally separate
ruby programs, if you like.

Just one possibility...


Regards,

Bill




 
Reply With Quote
 
Austin Ziegler
Guest
Posts: n/a
 
      07-02-2004
On Fri, 2 Jul 2004 11:37:48 +0900, TLOlczyk <(E-Mail Removed)> wrote:
> 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.


There is no reason that you can't do this with Ruby. If I have code
that works like:

file_list = find_files
missing_files = file_list - find_hrefs(file_list)
make_hrefs(missing_files)

Then I can simply do:

file_list = find_files
File.open("file_list.m", "wb") { |f| f.write Marshal.dump(file_list) }

Then, I can make the main loop do:

file_list = Marshal.load(File.read("file_list.m"))
missing_files = file_list - find_hrefs(find_files)
make_hrefs(missing_files)

With a bit of work, you could integrate this into the main program; it
might even be desirable if find_hrefs takes even longer than
find_files; that way, you could choose to load a predetermined
file_list (making it possible to "version" such lists) or use the
stored file_list as a comparison point. Or, even, do something like:

if File.exists?("file_list.m")
file_list = Marshal.load(File.read("file_list.m"))
File.rm("missing_files.rm")
else
file_list = find_files
end

begin
if File.exists?("missing_files.m")
missing_files = Marshal.load(File.read("missing_files.m")
File.rm("missing_files.rm")
else
missing_files = file_list - find_hrefs(find_files)
end
rescue
File.open("file_list.m", "wb") { |f| f.write Marshal.dump(file_list) }
raise
end

begin
make_hrefs(missing_files)
rescue
File.open("missing_files.m", "wb") { |f| f.write Marshal.dump(file_list) }
raise
end

Now, you have something repeatable that withstands all sorts of errors
without having to repeat portions that you don't need to do.

-austin
--
Austin Ziegler * (E-Mail Removed)
* Alternate: (E-Mail Removed)


 
Reply With Quote
 
Nicholas Van Weerdenburg
Guest
Posts: n/a
 
      07-02-2004
--------------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
><(E-Mail Removed)> 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 (E-Mail Removed).
>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--


 
Reply With Quote
 
Nicholas Van Weerdenburg
Guest
Posts: n/a
 
      07-02-2004
If Ruby is 2-6X more productive then Java, wouldn't it make sense for
almost all software projects to use full lifecycle prototypes? That is,
everything is built in Ruby, completely, and this forms a key part of
the specification and requirements feedback for the lagging J2EE /etc.
commerical implementation? Are there any cases of this being attempted
and are there industry learning/best practices in this regard?

Nick



 
Reply With Quote
 
Nicholas Van Weerdenburg
Guest
Posts: n/a
 
      07-02-2004
I get the impression that the J2EE world is starting to go ballastic
over Jython. JRuby gets some mention, but not that much, and I get the
impression that the long term prospects of JRuby are a bit mixed. For
this reason, I felt compelled to learn some Jython so I could use a
modern language in my day-to-day J2EE work.

Unfortunatly, I really can't stand using Python. The selfs, method
__protection__ mechanism, and lack of expression-orientation (unlike
Lisp and Ruby) make me weep. I'm still plinking at it here and there,
giving it a chance, but my mindset is not improving, and I'm starting to
think Python claims of readability are only relative to Perl- I find
Java/C/C++ easier to read. But that's really irrelevant to this point,
outside of my personal motivation for looking at JRuby more seriously.

So now I'm trying to use JRuby, and it's much better then I expected.
However, I'm still concerned about:
1. it's robustness and how it impacts my chosing to use it, and
2. it's impact on Ruby longterm due to prevalence of Jython. I get the
impression that Jython is becoming almost the defacto J2EE scripting
language, with Groovy possibly taking off when it's more mature (is it
just me, or does Groovy look a lot like a Ruby clone with a bit of Java
baggage left in for more seamless interoperability?). Where Jython has
followed Python into general usage, that could change with Jython being
the reason people use Python.

Not sure what point is...I guess I'm looking for some
experiences/ideas/feedback. I think dynamic JVM langauges are going to
become an essential part of enterprise Java, and I'm hoping I don't have
to use Jython on my next job. Those underscores and selfs- how can
anyone stand it? And the lack of expression-kindness.

Thanks,
Nick



 
Reply With Quote
 
David Garamond
Guest
Posts: n/a
 
      07-02-2004
Lennon Day-Reynolds wrote:
>>why would anyone care that you are not using Ruby ?
>>

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


As much as we like that to happen, Ruby is not for everyone.

+ it has many Perlisms (not that it's bad) that many people can't bear.

+ it's purely object-oriented (unlike Python & Perl), thus functional or
procedural guys might get offended or turned off.

+ it comes from Japan.

I am guessing that Python will always be more popular than Ruby in
general, because the language is more acceptable to many people.
However, that's fine. I myself think that the Ruby language is perfect
for me. It has the nice balance of practicality and purity. It has a
nice syntax. It is pretty popular (unlike, say, Ocaml or Haskell) so
it's easier to find libraries or bindings for many things. It simply rocks.

--
dave



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
Cisco 2611 and Cisco 1721 : Why , why , why ????? sam@nospam.org Cisco 10 05-01-2005 08:49 AM
Why, why, why??? =?Utf-8?B?VGltOjouLg==?= ASP .Net 6 01-27-2005 03:35 PM
Why Why Why You HAVE NO IDEA MCSE 31 04-24-2004 06:40 PM



Advertisments