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
[http://www.bagley.org/~doug/shootout/] 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

prosys@chartermi.net 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.

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

Could someone please offer a comparison between OCaml and Ruby?

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

James

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],,_ → (if(w=s) then (rS w) else (rT w);if(x=s) then (wS x) else
(wT x):wink:
[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. :slight_smile:

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
[http://www.bagley.org/~doug/shootout/] 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

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
[http://www.bagley.org/~doug/shootout/] 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.

Last I checked, the person running that site had left it frozen in
time. It is not current. IIRC, it reflects neither the best Ruby
implementation of the tests, nor the current version of Ruby.

Performance is relative in many ways. When I rewrote our C/bash shell
scripts for building Mac OS X installer packages & disk images in Ruby,
time to build a complete installer metapackage went from about 5
minutes to about 20 seconds. I did the rewrite just to make the scripts
modular and maintainable, the performance increase was an unexpected
and hugely positive side effect.

My personal impression is that Ruby is already the best of both worlds.

Chris

···


Can’t you feel the peace and contentment in this block of code? Ruby is
the language Buddha would have programmed in.

On Saturday, August 16, 2003, at 7:30 PM, prosys@chartermi.net 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.

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
[http://www.bagley.org/~doug/shootout/] 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

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

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

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

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

[…]

I looked at the comparison of various computer programming
languages at The Great Computer Language Shootout
[http://www.bagley.org/~doug/shootout/] 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.
[…]

FWIW, i tried some of the shoutout benchmarks
and i have very different results.

For example, he claims ocaml to be faster than gcc in
the Fibonacci test (0.18 vs. 0.24), while
on any sytem that i tested C is much faster (e.g. 1.8 to 0.19).

buggs

···

On Sun, Aug 17, 2003 at 11:30:09AM +0900, prosys@chartermi.net wrote:

Rich wrote:

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],,_ → (if(w=s) then (rS w) else (rT w);if(x=s) then (wS x) else
(wT x):wink:
[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. :slight_smile:

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

I love Ruby, but in defence of C++ 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.

Michael

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

8-< snip

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

Learning a new language never hurts:-) And by the way C is not really such
a complex language. After started writing C-extensions for Ruby (which
really is simple) I enjoy Ruby programming even more. You’ll get the speed
of C when neaded, and the ease of Ruby for the rest of your program.

And I’ll have to take a look at OCaml :wink:

···

On Sun, 17 Aug 2003 14:40:14 +0900, Rich wrote:

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:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/45787
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. :wink:

TIA,
Terry

“Andreas Hauser” buggs-ruby@splashground.de skrev i en meddelelse
news:20030823222718.GA6306@splashground.de

[snip OCaml not as fast as Bagley claims]

FWIW, i tried some of the shoutout benchmarks
and i have very different results.

For example, he claims ocaml to be faster than gcc in
the Fibonacci test (0.18 vs. 0.24), while
on any sytem that i tested C is much faster (e.g. 1.8 to 0.19).

Did you use ocamlopt instead of ocamlc and did you repeat the tests a few
times to eliminate the load overhead?

Mikkel

“Andreas Hauser” buggs-ruby@splashground.de skrev i en meddelelse
news:20030823222718.GA6306@splashground.de

[snip OCaml not as fast as Bagley claims]

FWIW, i tried some of the shoutout benchmarks
and i have very different results.

For example, he claims ocaml to be faster than gcc in
the Fibonacci test (0.18 vs. 0.24), while
on any sytem that i tested C is much faster (e.g. 1.8 to 0.19).

Did you use ocamlopt instead of ocamlc and did you repeat the tests a few
times to eliminate the load overhead?

Mikkel

on those systems I tried (x86, m68k) the ocaml version is faster.
The margin is small but I am still surprised something is faster
than gcc :slight_smile:

Richard

···

On Sun, Aug 24, 2003 at 07:27:23AM +0900, Andreas Hauser wrote:

FWIW, i tried some of the shoutout benchmarks
and i have very different results.

For example, he claims ocaml to be faster than gcc in
the Fibonacci test (0.18 vs. 0.24), while
on any sytem that i tested C is much faster (e.g. 1.8 to 0.19).

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.

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

···

On Sun, Aug 17, 2003 at 03:25:45PM +0900, mgarriss 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

:wink:

···

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


_ _

__ __ | | ___ _ __ ___ __ _ _ __
'_ \ / | __/ __| '_ _ \ / ` | ’ \
) | (| | |
__ \ | | | | | (| | | | |
.__/ _,
|_|/| || ||_,|| |_|
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

<nospam4.me@ottomate.biz[remove.me]> wrote in message
news:200308210345.49888.nospam4.me@ottomate.biz…

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:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/45787
Very informative!
thanks

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?

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

If you just want to have the occasional data exchange XML-RPC may be a fine
choice. I think Ruby has good SOAP support as well. OCaml has SOAP but I
don’t think it is mature. You can however build SOAP around OCaml using the
C/C++ library gSOAP and map the SOAP interface to OCaml functions - but this
is only interesting if you generally want to use SOAP.

I know a wireprotocol isn’t the fastest solution but it is interesting
because it gives distributed internet operation and language independence.
In particular OCaml is very good at parsing so you can make a small command
language and do many operations at once for each cross language call.

You can also integrate Ruby and OCaml more closely via a C-core. I haven’t
tried this but I’m confident that it is possible. The only major obstacle is
interference between OCamls garbage collection and Ruby’s garbage collector.
Therefore it is best to avoid having long lived data references from both
languages - at least unless you manage the lifetime manually. Threading may
also be an issue but it doesn’t have to be.

In order to intergrate to languages you load both languages from a common
C-Core. Normally Ruby would be in charge and load C-extensions (for example
a TCP-IP library), but you can also embed Ruby in a C application. This C
application can be linked statically with OCaml modules, or it can load
dynamic link libraries containing OCaml. You could also write a Ruby
extension in mixed C and OCaml and have Ruby run the show. This would be a
good for plugging in a parser written in OCaml. I guess this would be the
easiest option.
There is a number of possibilities and it would be a lengthy discussion -
but it isn’t all that difficult. I have written a bit of Glue code that
makes it possible to expose OCaml as a DLL and so have others.

In conclusion it is always messy to integrate components but if you have a
project that is large enough to justify it, it is definitely possible.

Before anything else I look at how I can integrate a language into a larger
project. If a language can only be used when it is in full control of the
program, you can’t really use it for serious development. I believe both
Ruby and Ocaml are well suited for integration.

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?

I don’t think much is known except Matz presented some visions including a
VM on a slideshow and that he has been busy on 1.8 - perhaps now that 1.8 is
out this will make a VM more of a reality. I’m pretty sure Ruby will
eventually get a VM. Even if it is not Rite, there is also the Parrot
project (the future Perl VM engine).

If and when that does come about, will
Ruby still be an interperter but with byte-code compilation
abilities?

Ruby can’t function without an intepreter, bytecode or not, because of the
eval statement. But If you think of an interactive interpreter like IRB,
this is a separate question. I can’t answer this but I also can’t imagine
Ruby without IRB.

Mikkel

mgarriss mgarriss@earthlink.net wrote in message news:3F3F1FE5.1030600@earthlink.net

I love Ruby, but in defence of C++ 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.

But metaprogramming in C++ is a side-effect of the template
system that was originally designed for something else. That’s
why metaprogramming in C++ is awkward, hard and damn slow
for the compiler. So I wonder why you’re so attracted to it. You
should see Lisp’s macro system – Metaprogramming done
correctly. If you’re interested, download Paul Graham’s On Lisp
for free:
http://www.paulgraham.com/onlisp.html

In Lisp metaprogramming, everything that is available at
run-time is also available at compile-time. So you could
do a macro that reads some file, generates code from it and
does some optimizations with parameters known at compile-time.
Meanwhile the C++ template lovers praise snippets that can
calculate something trivial like factorials or logarithms
in base 2 ;).

FWIW, i tried some of the shoutout benchmarks
and i have very different results.

For example, he claims ocaml to be faster than gcc in
the Fibonacci test (0.18 vs. 0.24), while
on any sytem that i tested C is much faster (e.g. 1.8 to 0.19).

C != gcc.

on those systems I tried (x86, m68k) the ocaml version is faster.
The margin is small but I am still surprised something is faster
than gcc :slight_smile:

You talk as if gcc was a good compiler :slight_smile: just try the bloated 3.3
against intel’s compiler on x86 or the fine 2.95 on the x86 against
the intel compiler and you’ll approach what is a good compiler (at
least on x86). Yes I know gcc is portable (and thus fine) but it’s
basically the worst-choice-common-denominator you have available for
most platforms…

I’m not surprised stuff is faster than gcc. I’m surprised so many
things build on gcc really.

-Martin

···

On Mon, Aug 25, 2003 at 05:26:54AM +0900, Richard Zidlicky wrote:

On Sun, Aug 24, 2003 at 07:27:23AM +0900, Andreas Hauser wrote:

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:
http://caml.inria.fr/oreilly-book/

···

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

Paul Brannan wrote:

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

In C++ I once tried to extend the STL string template for a very specific,
project-dependent purpose. After 3 days I gave up. I’m no slouch when it
comes to development, but I will say that for non-trivial templates like
STL, they are extremely difficult to grok.

Curt