Next Official Ruby Version

[Martin DeMello]

have you used D martin?

I'm just beginning to (two days in, mostly spent discovering that I need
to get the svn version of the gtk bindings in order to get them
compiling with the latest compiler ) There are a few projects here at
work that are non-critical, but nonetheless have to be compiled to
native code (so Ruby is out); I'm experimenting with D as possibly
offering a large productivity boost over C++.

I'm slightly worried by the 'beta' status of the language, and by the
fact that the DUI developer says "One thing I learn from D: Never, ever
again invest on a project lead by one person alone!"[1], but as Lothar
says, it's pretty much the best we have. (OCaml was another possibility,
but it requires a significant investment in learning the language, the
code will almost certainly be unmaintainable by anyone else, and its C
interface is not nearly as painless as D's. Also D lets us leverage our
C++ experience.)

martin

[1] http://www.dsource.org/forums/viewtopic.php?t=784

 

[Rick Nooner]

says, it's pretty much the best we have. (OCaml was another possibility,
but it requires a significant investment in learning the language, the
code will almost certainly be unmaintainable by anyone else, and its C
interface is not nearly as painless as D's. Also D lets us leverage our
C++ experience.)

martin

While I agree that there is a significant learning curve for OCaml, I can't
beleive that the C interface would be considered painful.

For example, the lseek function in the std C library can be directly called
after this simple definition.

external lseek : int -> int -> int -> int = "lseek"

Basically, you are just giving the name of the C function, specifying the
OCaml types that map to what the C function expects and returns, then
giving the name OCaml will use to call the function. After that, you
just link in the library containing the function you just defined.
This works for any C library.

Most languages don't make it this easy.

Rick

 

[Martin DeMello]

While I agree that there is a significant learning curve for OCaml, I can't
beleive that the C interface would be considered painful.

Ah, my mistake - I was confusing it with some other language's C
interface. OCaml definitely does make it easy to call out to C.

martin

 

[Lothar Scholz]

Hello Martin,


MD> Ah, my mistake - I was confusing it with some other language's C
MD> interface. OCaml definitely does make it easy to call out to C.

And how do i call in from C to OCaml ?

But even after the third look i don't like the syntax of Ocaml. I
really don't like it.

 

[Rick Nooner]

And how do i call in from C to OCaml ?

See my article on the subject (actually how to call OCaml from Ruby but it also
demonstrates how to call OCaml from C since that is the basis of the Ruby to
OCaml code). http://sciruby.codeforpeople.com/sr.cgi/ProjectIdeas/RubyOCaml

Only the first half is applicable to C -> OCaml. More info can be found
in the OCaml docs at http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html

But even after the third look i don't like the syntax of Ocaml. I
really don't like it.

It is very different from most languages. This is in some part due to it's
functional ancestry; OCaml<-ML<-Lisp. It lost all of Lisps parens and
adopted infix notation. It also mixes functional, imperative and oo styles
using a (mostly) functional syntax. This looks very strange to people not
used to a functional programming language.

That's one reason why there are so many different languages... Pick the one
most suited to you.

Rick

 

[Martin DeMello]

But even after the third look i don't like the syntax of Ocaml. I
really don't like it.

Yeah, I'd love it if it looked more Haskellish, but syntax apart it
seems like a language well worth learning. Plus once I'm more proficient
I can always play around with the preprocessor and see what sort of DSL
support I can hack in.

martin