Rite/Ruby2.0 & Ruby vs OCaml

Hi All,

I'm new here, and I hope I don't offend anyone by mentioning a
different programming language here on Ruby-Talk.

I have two questions that are borne of the fact that I have been
searching for a language that provides both rapid development
(via an interperter) and performance (via compilation to either
byte- or native code).

I understand that Ruby is being developed towards the realization
of a VM for byte-code execution. My question is, will the
interpreter function of Ruby remain? Will I be able to have the
best of both worlds -- rapid development _and_ performance?

I looked at the comparison of various computer programming
languages at The Great Computer Language Shootout
[[url]http://www.bagley.org/~doug/shootout/][/url] and was a bit
disappointed to see Ruby rated as low as it was in performance.
This is the only reason I have not yet adopted Ruby.

I did notice OCaml (Objective Caml) at the top of the list --
right up there with C. And, in my investigation, I discovered
the OCaml can be run as a script interpreter _and_ that it can
also compile byte-code and native code! Wow -- just what I've
been looking for. But for some strange reason, I am still drawn
to Ruby.

Could someone please offer a comparison between OCaml and Ruby?

Thank you all for your time.

Best,
Terry

[james_b]

[email]prosys@chartermi.net[/email] wrote:

> Hi All,
>
> I'm new here, and I hope I don't offend anyone by mentioning a
> different programming language here on Ruby-Talk.

Not at all. We (some of us, at least) encourage it.

<snip/>

> I did notice OCaml (Objective Caml) at the top of the list --
> right up there with C. And, in my investigation, I discovered
> the OCaml can be run as a script interpreter _and_ that it can
> also compile byte-code and native code! Wow -- just what I've
> been looking for. But for some strange reason, I am still drawn
> to Ruby.

For what it's worth, you can also get OCaml (or a version of it ) for
.net as well. It's called F#.

[url]http://research.microsoft.com/projects/ilx/fsharp-manual-extras.aspx[/url]

>
> Could someone please offer a comparison between OCaml and Ruby?

*I* can't, but would love to hear one. OCaml looks quite interesting.

James

[Rich]

I have no formal programming background - so my experience won't be the case
with the majority of the people on this list.

I spent 2.5 months reading and re-reading the OCaml OReilly book... and
finally I 'understood' when you're supposed to use either a semi-colon,
double semi-colon, or nothing at the end of a line of OCaml code. Once I had
that breakthrough, I could 'think' OCaml. Ever since then I've been amazed
at how quick I can write very simple programs. The problem is that I mostly
write multi-user server apps, and that isn't so 'quick' to do in OCaml -
Ruby OTOH is ofcourse very quick to write almost anything you want.

Remember - OCaml is based on Lambda Calculus... which I really don't know
that much about, just that there's only three things in LC... a function
that accepts one argument, an argument, and the application of that single
argument to a single function... or somethign like that... SO... thinking in
OCaml is _nothing_ and i mean _nothing_ like thinking in C, or Java, or
Ruby, or Perl.

Here's a snippet of code from a 2 user socket server that does polling over
the connections... (yes, I know, no comments, and should have been expanded
at ';;'s. Remember - I'm not saying I'm good at this, I just get the job
done. ;-))

START CODE
let p=(int_of_string Sys.argv.(2));;let myAddr=(Unix.inet_addr_of_string
(Sys.argv.(1)));;
let sockaddr=Unix.ADDR_INET(myAddr, p);;let sock=(Unix.socket Unix.PF_INET
Unix.SOCK_STREAM 0);;
Unix.bind sock sockaddr;;Unix.listen sock 2;;
let (s,scaller)=Unix.accept sock;;let sOut=Unix.out_channel_of_descr s;;let
sIn=Unix.in_channel_of_descr s;;
let (t,scaller)=Unix.accept sock;;let tOut=Unix.out_channel_of_descr t;;let
tIn=Unix.in_channel_of_descr t;;
output_string sOut "Connected\000";;flush sOut;;output_string tOut
"Connected\000";;flush tOut;;
let this=ref ([s;s],[s;s],[s;s]);;
let sH=ref (String.create 1024);;let tH=ref (String.create 1024);;
sH:="";;tH:="";;
let sF=ref 0;;let tF=ref 0;;
let rS m= (if((!tF)=0) then (tH:=input_line sIn;tF:=1;print_string
"|s|";flush stdout));;
let rT m= (if((!sF)=0) then (sH:=input_line tIn;sF:=1;print_string
"|t|";flush stdout));;
let wS m=if((!sF)=1) then (output_string sOut (!sH ^ "\000");flush
sOut;sH:="";sF:=0;print_string "-s-";flush stdout);;
let wT m=if((!tF)=1) then (output_string tOut (!tH ^ "\000");flush
tOut;tH:="";tF:=0;print_string "-t-";flush stdout);;
while true do
try (
print_string ".";
flush stdout;
this:=Unix.select [s;t] [s;t] [s;t] (-.1.0);
match !this with _,_,[w] -> (print_endline "error";exit 0)
| [w],[],_ -> (if(w=s) then (rS w) else (rT w))
| [],[w],_ -> (if(w=s) then (wS w) else (wT w))
| [w],[x],_ -> (if(w=s) then (rS w) else (rT w);if(x=s) then (wS x) else
(wT x);)
| [w;x],[],_ -> (if(w=s) then (rS w;rT x) else (rT w;rS x))
| [],[w;x],_ -> (if(w=s) then (wS w;wT x) else (wT w;wS x))
| [w],[x;y],_ -> (if(w=s) then (rS w) else (rT w);if(x=s) then (wS x;wT
y) else (wT x;wS y))
| [w;x],[y],_ -> (if(w=s) then (rS w;rT x) else (rT w;rS x);if(y=s) then
(wS y) else (wT y))
| [w;x],[y;z],_ -> (if(w=s) then (rS w;rT x) else (rT w;rS x);if(y=s)
then (wS y;wT z) else (wT y;wS z))
| _,_,_ -> ()
) with End_of_file -> (print_endline "exiting";exit 0)
done;;
END CODE

OCaml native code is ~better~ than C - see the language shootout to
understand what I mean.

OCaml bytecode has all the benefits of Java - plus none of the failings
(development time is shorter by far - my OCaml skill compared to my
comparably skilled Java oriented brother).

OCaml toplevel is just like IRB, there are some quirks, but it's great for
testing a quick snippet of code before you end up using it.

OCaml is wonderfully easy to compile to a 'native' exe (I had to distribute
the cygwin.dll with it) or 'close-to-crossplatform' bytecode (I think some
libraries didn't exist for certain platforms, but my memory is hazy on that
point), and super easy to run in a toplevel interpreter.

The bad points - exactly the same as Ruby. Next to no corporate backing
(think Sun's marketing pocketbook), next to no 'real-world' uses even though
they also have a 'these-are-the-real-world-uses' page just like Ruby.

There is one drawback that hurt me alot - and it might have just been me...
I was very offended by the nuby mailing list responses I recieved... that
list is not for nubies. You've been warned. :-)

That's my simple opinion.

When people ask what languages I like most, I say Ruby first, OCaml a very
close second - and no... I really have no clue how to write C or Java... and
I really don't ever want to learn ;-).

-Rich

----- Original Message -----
From: <prosys@chartermi.net>
To: "ruby-talk ML" <ruby-talk@ruby-lang.org>
Sent: Saturday, August 16, 2003 8:30 PM
Subject: Rite/Ruby2.0 & Ruby vs OCaml

> Hi All,
>
> I'm new here, and I hope I don't offend anyone by mentioning a
> different programming language here on Ruby-Talk.
>
> I have two questions that are borne of the fact that I have been
> searching for a language that provides both rapid development
> (via an interperter) and performance (via compilation to either
> byte- or native code).
>
> I understand that Ruby is being developed towards the realization
> of a VM for byte-code execution. My question is, will the
> interpreter function of Ruby remain? Will I be able to have the
> best of both worlds -- rapid development _and_ performance?
>
> I looked at the comparison of various computer programming
> languages at The Great Computer Language Shootout
> [[url]http://www.bagley.org/~doug/shootout/][/url] and was a bit
> disappointed to see Ruby rated as low as it was in performance.
> This is the only reason I have not yet adopted Ruby.
>
> I did notice OCaml (Objective Caml) at the top of the list --
> right up there with C. And, in my investigation, I discovered
> the OCaml can be run as a script interpreter _and_ that it can
> also compile byte-code and native code! Wow -- just what I've
> been looking for. But for some strange reason, I am still drawn
> to Ruby.
>
> Could someone please offer a comparison between OCaml and Ruby?
>
> Thank you all for your time.
>
> Best,
> Terry
>
>

[MikkelFJ]

<prosys@chartermi.net> wrote in message
news:200308162229.16796.prosys@chartermi.net...

> I understand that Ruby is being developed towards the realization
> of a VM for byte-code execution. My question is, will the
> interpreter function of Ruby remain? Will I be able to have the
> best of both worlds -- rapid development _and_ performance?

Ruby will be faster as it matures, but it will not give you real
performance. In some cases the C-compiled libraries can be scripted in a way
that is very fast (e.g. by having a fast regular expression matcher and fast
hash table) but generally Ruby is not and will not be as fast as statically
typed compiled languages.

Very often Ruby is fast enough. For many applications it completes the job
instantly. Ruby allows you to write a lot of programs you would otherwise
never bother to write. It has a very friendly syntax. The major problem with
Ruby (and scripting in general) is deployment - you need an interpreter to
run a Ruby script.

> disappointed to see Ruby rated as low as it was in performance.
> This is the only reason I have not yet adopted Ruby.

It is fast enough for many purposes and it is certainly in my toolbox. Given
how easy it is to get started, it is worth learning Ruby even if you can't
use it for everything.

> I did notice OCaml (Objective Caml) at the top of the list --
> right up there with C. And, in my investigation, I discovered

You should generally assume that C is twice as fast as OCaml although it
differs.
OCaml may sometimes lack easily accessible libraries but it has good
standard libraries.

> the OCaml can be run as a script interpreter _and_ that it can
> also compile byte-code and native code! Wow -- just what I've
> been looking for. But for some strange reason, I am still drawn
> to Ruby.

OCaml is also in my toolbox. It takes much more effort to get comfortable
with OCaml, but you can write even shorter programs than in Ruby. The syntax
is efficient but not friendly.

It is very important to me that OCaml compiles to object code that can link
directly with C code. If you take the time to understand the relatively easy
C call interface you can use OCaml for serious programming. Ruby also
interacts well with C, but you can take an OCaml executable and run it
everywhere. It takes up 200-300K.

I like Ruby more than OCaml but OCaml is a better tool for hardcore
development.

> Could someone please offer a comparison between OCaml and Ruby?

Here is a posting I wrote a year ago

[url]http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/45787[/url]

featured in Ruby Weekly News :-)
[url]http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/46348[/url]

OCaml is especially efficient in writing compilers. You get a productivity
boost of more than a factor 10 over C++ and the runtime is probably at least
as fast in this scenario.

I recommend both Ruby and OCaml. The effort in learning Ruby will be 10% of
that learning OCaml so you get Ruby for free. Ruby does things in a
different way and it depends on the task at hand.

I would use OCaml for heavily loaded web servers because Ruby isn't fast
enough, but I would use Ruby to prepare data offline for the same server
because it is so flexible and easy to update.

Mikkel

[Erik Terpstra]

>> I spent 2.5 months reading and re-reading the OCaml OReilly book... and

Is there an OCaml O'Reilly book? I can not find it. Can you provide a link?

Thanks,

Erik.

[Florian Frank]

On 2003-08-18 17:20:23 +0900, Erik Terpstra wrote:

> >>I spent 2.5 months reading and re-reading the OCaml OReilly book... and

> Is there an OCaml O'Reilly book? I can not find it. Can you provide a
> link?

The book has only been published in French so far, the title is
"D�veloppement d'applications avec Objective Caml". However, there is a
preliminary translation online:
[url]http://caml.inria.fr/oreilly-book/[/url]

--
The liberty of a democracy is not safe if the people tolerate the growth
of private power to a point where it becomes stronger than their
democratic State itself. That, in its essence, is Fascism -- ownership
of government by an individual, by a group, or any controlling private power.
-- Franklin D. Roosevelt

[Erik Terpstra]

Thanks!

Now I've found the original page as well:

[url]http://www.oreilly.fr/catalogue/ocaml.html[/url]

Florian Frank wrote:

> On 2003-08-18 17:20:23 +0900, Erik Terpstra wrote:
>

>>>>I spent 2.5 months reading and re-reading the OCaml OReilly book... and

>>
>>Is there an OCaml O'Reilly book? I can not find it. Can you provide a
>>link?

>
>
> The book has only been published in French so far, the title is
> "D�veloppement d'applications avec Objective Caml". However, there is a
> preliminary translation online:
> [url]http://caml.inria.fr/oreilly-book/[/url]
>

[Paul Brannan]

On Sun, Aug 17, 2003 at 03:25:45PM +0900, mgarriss wrote:

> I love Ruby, but in defence of C++...

The OP never mentioned C++. I'm unclear as to why you feel C++ needs to
be defended here.

> ...I have to say the there is nothing quite like the C++ template...
> feature. Metaprogramming is really interesting. Doing factorial at
> no run-time cost (all at compile time), compile time parser
> generators, and such. I'm currently working on a template lib that
> allows the end user to create/genterate Alife simulators (with
> behavior and rules they define) with one (mammoth) typedef.

IMO, metaprogramming is one of the worst "features" the C++ language has
to offer. Code that makes heavy use of template or preprocessor
metaprogramming can be very slow to compile and can be very difficult to
understand. Don't get me wrong; from a tinkering standpoint,
metaprogramming is insanely cool. Metaprogramming in C++ has a strange
attraction to it, but I've seen people spend days trying to use template
metaprogramming to solve a problem that would have taken an hour to
solve with plain ordinary C++.

Nine times out of ten, I would argue that a code generator (perhaps
written in Ruby) would have equal run-time speed and much faster compile
time than an equivalent program that uses template or preprocessor
metaprogramming.

Paul

Thank you all so much for your informative comments. I saved a
few of them and read and re-read them in order so absorb all the
good info.

I especially liked Mikkel's 'article' at:
[url]http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/45787[/url]
Very informative!

I may just put off learning OCaml for the time being and
concentrate on Ruby. But I first would really like to be sure
that Ruby will meet my needs for the foreseeable future.

It has been said that OCaml integrates well with C, and the same
has been said for Ruby. How about, does Ruby integrate well
with OCaml or vice versy?

And finally, I will rephrase one of my original questions. Does
anyone know if the development plans for Ruby 2.0 still include
a VM implementation? If and when that does come about, will
Ruby still be an interperter but with byte-code compilation
abilities?

Please know that I am not trying to start any debate on the
viability of any language over another. I, for one, have had my
quota filled recently. ;-)

TIA,
Terry

[Mauricio Fernández]

On Thu, Aug 21, 2003 at 04:44:49PM +0900, [email]nospam4.me@ottomate.biz[remove.me[/email]] wrote:

> And finally, I will rephrase one of my original questions. Does
> anyone know if the development plans for Ruby 2.0 still include
> a VM implementation? If and when that does come about, will

Rite will have a VM and run bytecode.

> Ruby still be an interperter but with byte-code compilation
> abilities?

IIRC the "interpreter" (AST based) will be dumped.

> Please know that I am not trying to start any debate on the
> viability of any language over another. I, for one, have had my

;-)

--
_ _
| |__ __ _| |_ ___ _ __ ___ __ _ _ __
| '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \
| |_) | (_| | |_\__ \ | | | | | (_| | | | |
|_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

Netscape is not a newsreader, and probably never shall be.
-- Tom Christiansen

[Kurt M. Dresner]

> IIRC the "interpreter" (AST based) will be dumped.

I like the interpreter.

Does this mean we're going to have to run some compiler on our code to
compile it to bytecode? That would be annoying.

:o(

-Kurt

[Dan Doel]

Ben Giddings wrote:

> Mauricio Fernández wrote:
>

>> IIRC the "interpreter" (AST based) will be dumped.

>
>
> Hmm, will this affect the startup time? My understanding is that one
> of the reasons Java is so slow to start up is the VM setup.
>
> Ben

I think the main reason Java startup is slow is that it has to load
several megabytes of standard library classes.

The ruby standard library is quite a bit smaller, I think, so the hit
shouldn't be the same. It shouldn't really
take any more time to start up a virtual machine than an interpreter, as
the only difference is that the VM
runs bytecode (more like machine code), while the interpreter runs the
source more-or-less directly (yes,
that's a bit of a simplification).

- Dan

[Dan Doel]

MikkelFJ wrote:

>You cannot avoid C when intergrating languages unless you go to a
>wireprotocol such as XML-RPC (supported by OCaml and Ruby) or you use a
>component technology like COM (not sufficiently supported in both Ruby or
>OCaml).
>
>

This always confuses me a bit. Is the reason for needing to use C that
both OCaml and Ruby are
written in C? For example, I can understand that you can't interface
Java and Ruby without either
writing Ruby in something that compiles to JVM bytecode, or using JNI to
link to native code.

But OCaml compiles to machine code, doesn't it? Would it only be
possible to interface with
OCaml directly if you wrote Ruby in OCaml (I assume that's the main
problem)?

I guess that's a good reason for keeping Ruby written in C (that is, if
we somehow got a
compiler from Ruby to machine code, and were able to write Ruby in
Ruby), because if all
languages are implemented in C, or can interface with C easily, they can
all be linked together.

I guess I've answered my own question to some degree. :)

If I'm wrong anywhere, feel free to correct me.

- Dan

[gabriele renzi]

il Fri, 22 Aug 2003 02:38:48 +0900, "Kurt M. Dresner"
<kdresner@cs.utexas.edu> ha scritto::

>> IIRC the "interpreter" (AST based) will be dumped.

>
>I like the interpreter.
>
>Does this mean we're going to have to run some compiler on our code to
>compile it to bytecode? That would be annoying.

think it this way: you code in the usual way, cause your code can be
interpreted.
When you release you compile to bytecode, to get a performance
enhancement and (possibly) some code obfuscation..

[Kurt M. Dresner]

> think it this way: you code in the usual way, cause your code can be

> interpreted.

But I thought that the interpreter was being dumped...

-Kurt

[Hal E. Fulton]

----- Original Message -----
From: "Kurt M. Dresner" <kdresner@cs.utexas.edu>
To: "ruby-talk ML" <ruby-talk@ruby-lang.org>
Sent: Thursday, August 21, 2003 4:18 PM
Subject: Re: Rite/Ruby2.0 & Ruby vs OCaml

> > think it this way: you code in the usual way, cause your code can be
> > interpreted.

>
> But I thought that the interpreter was being dumped...

Not sure. I'd like to think bytecode compilation will
be optional.

In any case, there'll be some kind of interpreter, of course,
for the bytecodes if nothing else.

Hal

--
Hal Fulton
[email]hal9000@hypermetrics.com[/email]

[Mauricio Fernández]

On Fri, Aug 22, 2003 at 06:32:55AM +0900, Hal E. Fulton wrote:

> ----- Original Message -----
> From: "Kurt M. Dresner" <kdresner@cs.utexas.edu>
> To: "ruby-talk ML" <ruby-talk@ruby-lang.org>
> Sent: Thursday, August 21, 2003 4:18 PM
> Subject: Re: Rite/Ruby2.0 & Ruby vs OCaml
>
>

> > > think it this way: you code in the usual way, cause your code can be
> > > interpreted.

> >
> > But I thought that the interpreter was being dumped...

>
> Not sure. I'd like to think bytecode compilation will
> be optional.

It wouldn't make sense to keep an AST walker, since that would
mean duplicating the amount of code for no benefit. Indeed, bytecode
compilation could happen internally so you wouldn't notice the difference
externally (except for the speed increase :)

--
_ _
| |__ __ _| |_ ___ _ __ ___ __ _ _ __
| '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \
| |_) | (_| | |_\__ \ | | | | | (_| | | | |
|_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

We come to bury DOS, not to praise it.
-- Paul Vojta, [email]vojta@math.berkeley.edu[/email]

[Lyle Johnson]

Kurt M. Dresner wrote:

>> IIRC the "interpreter" (AST based) will be dumped.

>
> I like the interpreter.
>
> Does this mean we're going to have to run some compiler on our code to
> compile it to bytecode? That would be annoying.

Not sure, but I suspect that what batsman meant is that the current
AST-based interpreter will be replaced with a 'ruby' that first compiles
your Ruby source code to bytecode and then feeds that to a virtual
machine (VM) for interpretation. But no explicit compilation step on
your part (unlike traditionally compiled languages like C/C++).

[MikkelFJ]

Ben Giddings wrote:

> Mauricio Fernández wrote:

>> IIRC the "interpreter" (AST based) will be dumped.

>
> Hmm, will this affect the startup time? My understanding is that one of
> the reasons Java is so slow to start up is the VM setup.

No bytecode should not slow things down. Ruby har a decent sized runtime
library - this must be loaded no matter how you execute the code. An
efficient bytecode interpreter may speed up startup time because you can
skip the parsing. However, Ruby is currently loading Ruby source files on
demand. In a bytecode interpreter it might load more code than it would
have done in the current interpreter - this could affect startup time.

OCamls bytecode is very fast, its runtime engine is comparatively small and
there is no noticable startup overhead at all. I think Parrots non-stack
based VM might also be very fast but it is difficult to predict - it also
depends on the quality of the byte code generating compiler (affects
runtime not startup time). OCaml bytecode has 10 years of development
behind it or so.

Java is well ... Java. I guess they load 100-200 class libraries
unnecessarily - my guess is that recent Java implementations have improved
significantly although I'm not using Java that much. I'm trying out the
Jakarta FOP XSL-FO processor written in Java, and it starts up fast enough.

Mikkel

[Kurt M. Dresner]

> It wouldn't make sense to keep an AST walker, since that would

> mean duplicating the amount of code for no benefit. Indeed, bytecode
> compilation could happen internally so you wouldn't notice the difference
> externally (except for the speed increase :)

Ahh, ok. I see. So I can still just put #!/usr/bin/env ruby at the top
of my scripts and just run them?

<joke type="geeky" quality="low">
Also, what's all this Star Wars talk?! AT-ST walkers and such? :o)
</joke>

-Kurt