Why I don't use Ruby.

T

TLOlczyk

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 (e-mail address 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.
 
G

gabriele renzi

il Thu, 01 Jul 2004 04:43:49 -0500, TLOlczyk <[email protected]> ha
scritto::


This message may be trollish, but it seem it is'nt :)
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:
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?)
 
R

Robert Klemme

I totally agree with you.

gabriele renzi said:
il Thu, 01 Jul 2004 04:43:49 -0500, TLOlczyk <[email protected]> ha
scritto::


This message may be trollish, but it seem it is'nt :)
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:
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.
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
 
L

Lothar Scholz

Hello TLOlczyk,

T> The main thing I am looking for is a basic environment similar to
T> functional languages. In particular a ( native-code ) compiler and
T> 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.

T> word for interpreter. To make clear what I want, and why I think
T> 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.
 
R

richard lyman

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

Why would it cause problems with exerb?

-Rich
 
L

Lothar Scholz

Hello richard,

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

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

Lennon Day-Reynolds

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
 
C

Curt Hibbs

Klaus said:
TLOlczyk said:

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
 
L

Lennon Day-Reynolds

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
 
A

Ara.T.Howard

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

yes. yes.

regards.

-a
--
===============================================================================
| 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
===============================================================================
 
B

bruno modulix

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
 
C

Carl Youngblood

OCaml is as dynamic as LISP and some implementations produce native
code that _is_ as fast as C. It's quite amazing.
 
L

Lennon Day-Reynolds

There are several reasons that Common Lisp can achieve much better
performance than Ruby. First and foremost is the fact that Lisp-like
languages in general have been around longer than C, and have been the
subject of extensive work in optimization and native code generation.
Second, CL, while being value-typed in a fashion similar to modern
scripting languages, also supports type annotations, which allow the
compiler to generate more efficient code for critical sections.

Performance has much less to do which language selection than it does
with abstraction and algorithm selection. Some languages (like C) are
excellent for manipulating data at the level of individual pointers
and registers, but require a great deal of infrastructure to approach
the productivity of higher-level languages. If you were to write C
code that emulated the Ruby object model, it would likely run in
approximately equivalent time.

Lennon
 
J

James Britt

Klaus said:

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
 
L

Lothar Scholz

Hello Lennon,

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

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

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

LDR> Anyone with more language implementation experience care to weigh in
LDR> on the feasibility of such a hack? I know that several "academic"
LDR> languages already implement such functionality, and that as a
LDR> garbage-collected language, Ruby should already have most of the
LDR> 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.
 
L

Lennon Day-Reynolds

OCaml is, as far as I understand, actually much closer to C++ than
CLOS/Ruby/Smalltalk in object model and dynamism. Its object model
supports polymorphism, inheritance, and even parameterization, but
does not really allow redefinition of methods and instance variables
at runtime. In my usual thinking, "dynamic" and "statically typed" do
not often go together.

There's always going to be a certain amount of overhead incurred by
using a "pure", message-based object model. You can either try to
avoid it by having a restricted sub-language that can be turned into
fast native code (Psyco, Objective C, etc.), or by doing runtime JIT
compilation, with its implied assumption that changes to "hotspot"
code will be infrequent enough to make code cache invalidation a minor
cost compared to the savings provided by compilation.

In effect, the current solution for Ruby closely mirrors Objective C,
in that "high performance" code can be written in C (either using
Inline, or as a standalone extension). Personally, now that I'm
familiar with the Ruby C API, I don't really consider it to be that
bad having to drop into another language for performance-critical
code.

Lennon
 
L

Lothar Scholz

Hello bruno,

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

No. You need to use things like (the 'Integer i) all the time, and if
i would call this lisp anymore i don't know.

And even if you go this way, your program will then be as save as a
program in FORTH - or a C program where everything is casted to (void*)

Lisp guys write some routines in this "typed Lisp", rubyist's write
them in "C", so it's not so different.
 
J

Jeff Mitchell

--- TLOlczyk said:
[...]
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.
[...]

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.





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

Mikael Brockman

Carl Youngblood said:
OCaml is as dynamic as LISP and some implementations produce native
code that _is_ as fast as C. It's quite amazing.

It's definitely not as dynamic as Lisp. It's entirely statically
typed: types do not exist at runtime. It has very few facilities for
introspection. The performance of its generated code and garbage
collector crucially depends on its static type system.

Not to say OCaml is a bad language for it. Dynamicity is a very nice
property -- but so is fast code. For me, the trade-off tends to favor
dynamicity, but if it didn't, I would love to use OCaml.

Except the lack of overloading would probably drive me crazy.

mikael
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top