Best compiled language for extending Ruby

I want to write my core logics in a compiled language for 1) performance
and 2) protecting my source code -- in case I will be selling my product
to a customer.

What would be the most natural-supported-easy-fast language to do this
in, given the many choices of language bridges?

I am particularly interested in,

1) C
2) Objective C
3) Ocaml
4) Lisp (SBCL)
5) Scheme

Does anyone have experience and would like to share?

I will be coding in OS X and deploying in FreeBSD mostly.

Thanks

Shark

···

--
Posted via http://www.ruby-forum.com/.

Sharkie Landshark wrote:

I want to write my core logics in a compiled language for 1) performance
and 2) protecting my source code -- in case I will be selling my product
to a customer.

What would be the most natural-supported-easy-fast language to do this
in, given the many choices of language bridges?

I am particularly interested in,

1) C
2) Objective C
3) Ocaml
4) Lisp (SBCL)
5) Scheme

Does anyone have experience and would like to share?

I will be coding in OS X and deploying in FreeBSD mostly.

The only one of these for which a well-documented interface exists is C. C++ can be made to work, but Ruby itself is written in C.

I'm sure it's possible to write extensions in the other four languages and build a C interface, so if your algorithms are more naturally expressed in one of them, by all means use one of them. By the way, which Scheme(s) were you considering? Quite a few of them compile to C now, so that might make a Ruby interface easier.

···

Thanks

Shark

There's rocaml: http://eigenclass.org/hiki/rocaml . Never used it,
but thought I'd mention it.

JM

···

On Dec 17, 11:32 pm, Sharkie Landshark <shark.fin.s...@mac.com> wrote:

I want to write my core logics in a compiled language for 1) performance
and 2) protecting my source code -- in case I will be selling my product
to a customer.

What would be the most natural-supported-easy-fast language to do this
in, given the many choices of language bridges?

I am particularly interested in,

1) C
2) Objective C
3) Ocaml
4) Lisp (SBCL)
5) Scheme

Does anyone have experience and would like to share?

I will be coding in OS X and deploying in FreeBSD mostly.

Thanks

Shark
--
Posted viahttp://www.ruby-forum.com/.

Quoth M. Edward (Ed) Borasky:

Sharkie Landshark wrote:
> I want to write my core logics in a compiled language for 1) performance
> and 2) protecting my source code -- in case I will be selling my product
> to a customer.
>
> What would be the most natural-supported-easy-fast language to do this
> in, given the many choices of language bridges?
>
> I am particularly interested in,
>
> 3) Ocaml

For OCaml there is rocaml. http://eigenclass.org/repos/rocaml/head/

Regards,

···

--
Konrad Meyer <konrad@tylerc.org> http://konrad.sobertillnoon.com/

I am thinking of Stalin Scheme, and that is because I hear it is fast.
My first programming language is Scheme, and that is still my favorite.
I like Ruby because I find it similar to Lisp/Scheme -- in a strange
way.

Anyway, can I compile Stalin Scheme to C, or is there a high performance
scheme that will compile to C? It will allow me to get my work done
fastest, and most naturally suite my logics. I am very excited in
hearing that it can compile to C.

···

--
Posted via http://www.ruby-forum.com/.

I had developed some applications using smalltalk but they are small utility
programs. I would prefer smalltalk for utility programs but I am not sure if
this is a good choice for getting good performance.

Kiran

···

On Dec 18, 2007 8:49 PM, jwmerrill@gmail.com <jwmerrill@gmail.com> wrote:

On Dec 17, 11:32 pm, Sharkie Landshark <shark.fin.s...@mac.com> wrote:
> I want to write my core logics in a compiled language for 1) performance
> and 2) protecting my source code -- in case I will be selling my product
> to a customer.
>
> What would be the most natural-supported-easy-fast language to do this
> in, given the many choices of language bridges?
>
> I am particularly interested in,
>
> 1) C
> 2) Objective C
> 3) Ocaml
> 4) Lisp (SBCL)
> 5) Scheme
>
> Does anyone have experience and would like to share?
>
> I will be coding in OS X and deploying in FreeBSD mostly.
>
> Thanks
>
> Shark
> --
> Posted viahttp://www.ruby-forum.com/.

There's rocaml: http://eigenclass.org/hiki/rocaml . Never used it,
but thought I'd mention it.

JM

I've been using rocaml lately, and I like it. OCaml isn't Haskell, but
nobody's perfect! :stuck_out_tongue: Seriously though, OCaml fits very well (imho)
with the style of ruby (Hindley-Milner type inference + structural
typing is very similar to duck typing), and rocaml makes it easy to
write extensions since it auto-generates all the glue code for you
(similar to SWIG). You basically write a .ml file as you normally
would, declare a few things about the interface, and rocaml does the
rest. Doesn't work on windows yet I don't think (OCaml does, just not
rocaml).

Regards,
Jordan

···

On Dec 18, 9:17 am, "jwmerr...@gmail.com" <jwmerr...@gmail.com> wrote:

On Dec 17, 11:32 pm, Sharkie Landshark <shark.fin.s...@mac.com> wrote:

> I want to write my core logics in a compiled language for 1) performance
> and 2) protecting my source code -- in case I will be selling my product
> to a customer.

> What would be the most natural-supported-easy-fast language to do this
> in, given the many choices of language bridges?

> I am particularly interested in,

> 1) C
> 2) Objective C
> 3) Ocaml
> 4) Lisp (SBCL)
> 5) Scheme

> Does anyone have experience and would like to share?

> I will be coding in OS X and deploying in FreeBSD mostly.

> Thanks

> Shark
> --
> Posted viahttp://www.ruby-forum.com/.

There's rocaml:http://eigenclass.org/hiki/rocaml\. Never used it,
but thought I'd mention it.

JM

Sharkie Landshark wrote:

I am thinking of Stalin Scheme, and that is because I hear it is fast. My first programming language is Scheme, and that is still my favorite. I like Ruby because I find it similar to Lisp/Scheme -- in a strange way.

Anyway, can I compile Stalin Scheme to C, or is there a high performance scheme that will compile to C? It will allow me to get my work done fastest, and most naturally suite my logics. I am very excited in hearing that it can compile to C.

There are several Scheme-to-C processors that I know of, and there are lots of published speed benchmarks. The ones I can recall off the top of my head are bigloo, larceny, gambit-c and chicken. I personally like gambit-c because it has an Erlang-like lightweight process extension called Termite. And I'm pretty sure Chicken has a SWIG interface, which means you could drive common C libraries from both Chicken and Ruby via SWIG.

If you head over to comp.lang.scheme, I think you'll get plenty of answers.

I am very excited in hearing that it can compile to C.

You can also compile ruby to C. Does this mean the code is in general
as
efficient as hand-coded C? No. Maybe for certain purposes.

Why would you combine Scheme and Ruby? If you like Scheme, use it.

BTW there are quite a few Scheme implementations that compile to
native
code. MzScheme (PLT), Chicken, Bigloo (which compiles also to Java),
Larency (which I have never tried) etc.

because I hear it is fast.

Frankly, I'd suggest to actually test it and ask again later.

Stalin is great, and all, but it isn't a full Scheme implementation (AFAIK
it's mostly R4RS compatible). It's fast, indeed, but if you're thinking of
enjoying Scheme in its entirety, I don't think it's the best choice.

···

On Dec 18, 2007 4:10 AM, Sharkie Landshark <shark.fin.soup@mac.com> wrote:

I am thinking of Stalin Scheme, and that is because I hear it is fast.
My first programming language is Scheme, and that is still my favorite.
I like Ruby because I find it similar to Lisp/Scheme -- in a strange
way.

--
Vitor Peres (dodecaphonic)
------------------------------------
http://twitter.com/dodecaphonic

>
> > I want to write my core logics in a compiled language for 1) performance
> > and 2) protecting my source code -- in case I will be selling my product
> > to a customer.
>
> > What would be the most natural-supported-easy-fast language to do this
> > in, given the many choices of language bridges?
>
> > I am particularly interested in,
>
> > 1) C
> > 2) Objective C
> > 3) Ocaml
> > 4) Lisp (SBCL)
> > 5) Scheme

[...]

···

On Wed, Dec 19, 2007 at 08:29:59AM +0900, MonkeeSage wrote:

On Dec 18, 9:17 am, "jwmerr...@gmail.com" <jwmerr...@gmail.com> wrote:
> On Dec 17, 11:32 pm, Sharkie Landshark <shark.fin.s...@mac.com> wrote:
> There's rocaml:http://eigenclass.org/hiki/rocaml\. Never used it,
> but thought I'd mention it.

I've been using rocaml lately, and I like it. OCaml isn't Haskell, but
nobody's perfect! :stuck_out_tongue: Seriously though, OCaml fits very well (imho) with the
style of ruby (Hindley-Milner type inference + structural typing is very

                 =========================================================

similar to duck typing), and rocaml makes it easy to

  ======================

Yes! I wish more people knew this. If anything, it would make the periodic
static vs. dynamic typing threads less boring. I've often started to write
about this for eigenclass.org, but I'm dropping more and more posts as of late
(I must be around ~75% rejection rate or so, and worsening).

write extensions since it auto-generates all the glue code for you
(similar to SWIG). You basically write a .ml file as you normally
would, declare a few things about the interface, and rocaml does the
rest. Doesn't work on windows yet I don't think (OCaml does, just not
rocaml).

"Non-pure-Ruby" development on Windows is often difficult; even a plain old C
extension can be challenging. AFAIK, rocaml could in principle[1] work on
Win32, at least with the MinGW and cygwin builds of Ruby and OCaml (maybe with
the MSVC ones too, if the same compiler is used for both). So I believe that
rocaml should be usable on Win32 after some work in the Makefile generation
magic. I don't use Win32 myself so it will be up to some brave Win32 developer
to clear the path.

By the way,

I've been using rocaml lately, and I like it. OCaml isn't Haskell, but
nobody's perfect! :stuck_out_tongue:

What do you miss when you're doing OCaml instead of Haskell (apart from the
syntax, I assume :)? I sometimes ache for ad-hoc polymorphism; I'm looking
forward to the result of the attempt to bring type classes to OCaml.
How do you feel about the strict vs. non-strict semantics? One thing I love
about OCaml is that I can know what is happening under the hood and there are
no bad surprises (bad performance or unexpectedly high memory consumption).

[1] The inability of ocamlopt (up to 3.09.2 or so, 3.10.0 can on some
platforms) to generate PIC code is not a problem on win32, see [274896].
The next release of OCaml will feature dynamic loading of native code.

--
Mauricio Fernandez - http://eigenclass.org

(perhaps slightly off-topic)

What tool(s) would you recommend for that?

···

On Tue, Dec 18, 2007 at 03:35:10PM +0900, tho_mica_l wrote:

You can also compile ruby to C.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Amazon.com interview candidate: "When C++ is your hammer, everything starts
to look like your thumb."

Stalin is great,

I would never imagine to read such a sentence in this mailing-list.

and all, but it isn't a full Scheme implementation (AFAIK
it's mostly R4RS compatible). It's fast, indeed, but if you're thinking of
enjoying Scheme in its entirety, I don't think it's the best choice.

Thinking about the importance of context...

   -- Jean-François.

···

2007/12/18, Vitor Peres <dodecaphonic@gmail.com>:

AFAIK, rocaml could in principle[1] work on
Win32, at least with the MinGW and cygwin builds of Ruby and OCaml

May I ask if somebody has succeeded in building rocaml on cygwin?

What do you miss when you're doing OCaml instead of Haskell

Eager vs lazy evaluation makes some difference, I'd suppose.

> > > I want to write my core logics in a compiled language for 1) performance
> > > and 2) protecting my source code -- in case I will be selling my product
> > > to a customer.

> > > What would be the most natural-supported-easy-fast language to do this
> > > in, given the many choices of language bridges?

> > > I am particularly interested in,

> > > 1) C
> > > 2) Objective C
> > > 3) Ocaml
> > > 4) Lisp (SBCL)
> > > 5) Scheme
[...]
> > There's rocaml:http://eigenclass.org/hiki/rocaml\. Never used it,
> > but thought I'd mention it.

> I've been using rocaml lately, and I like it. OCaml isn't Haskell, but
> nobody's perfect! :stuck_out_tongue: Seriously though, OCaml fits very well (imho) with the
> style of ruby (Hindley-Milner type inference + structural typing is very

                 =========================================================> similar to duck typing), and rocaml makes it easy to

  ======================

Yes! I wish more people knew this. If anything, it would make the periodic
static vs. dynamic typing threads less boring. I've often started to write
about this for eigenclass.org, but I'm dropping more and more posts as of late
(I must be around ~75% rejection rate or so, and worsening).

Heh. Just don't let it get to 100%. I enjoy reading your blog.

> write extensions since it auto-generates all the glue code for you
> (similar to SWIG). You basically write a .ml file as you normally
> would, declare a few things about the interface, and rocaml does the
> rest. Doesn't work on windows yet I don't think (OCaml does, just not
> rocaml).

"Non-pure-Ruby" development on Windows is often difficult; even a plain old C
extension can be challenging. AFAIK, rocaml could in principle[1] work on
Win32, at least with the MinGW and cygwin builds of Ruby and OCaml (maybe with
the MSVC ones too, if the same compiler is used for both). So I believe that
rocaml should be usable on Win32 after some work in the Makefile generation
magic. I don't use Win32 myself so it will be up to some brave Win32 developer
to clear the path.

By the way,

> I've been using rocaml lately, and I like it. OCaml isn't Haskell, but
> nobody's perfect! :stuck_out_tongue:

What do you miss when you're doing OCaml instead of Haskell (apart from the
syntax, I assume :)? I sometimes ache for ad-hoc polymorphism; I'm looking
forward to the result of the attempt to bring type classes to OCaml.
How do you feel about the strict vs. non-strict semantics? One thing I love
about OCaml is that I can know what is happening under the hood and there are
no bad surprises (bad performance or unexpectedly high memory consumption).

I was just being silly, since Haskell is "pure" (and "pure" ==
"greatest" :wink: because it separates functions and "actions". In
actuality, I like the fact that OCaml lets me use reference types and
imperative programming when I feel it best suites the problem.

I've only been using Haskell for about six months, and I've not delved
too deeply into theory (Curry-Howard isomorphism, existential types,
and so forth). So I can't really say on any technical level what I'd
be missing (if anything) by using OCaml rather than Haskell.

List comprehensions are nice, but not essential (there is a camlp4
module for list comps in OCaml [1], but I've not tried it). Syntax
isn't a big deal, and the "revised syntax" is pretty close to Haskell
(there is also Mike Lin's preprocessor [2] for using the off-side rule
rather than parens / begin...end for statement grouping). One big
difference is obviously type classes, but so far I've found generic
functions provide enough polymorphism for what I've been doing, and
haven't needed overloading. However, I do miss it for the overloaded
functions defined in the Prelude, which save from explicit type
conversions and and type-specific operators -- it's nice to be able to
say "10 / 2.0" and get "5.0" instead of "this has type float but is
used with type int". :wink:

I agree about laziness having fangs (and I almost always use the
strict Data.ByteString.Char8 for example), but over-all I like it for
the reasons given by SPJ [3] (my favorite of which is: "Laziness is
jolly convenient", heh). But (aside from implementation details) since
I can generate a thunk in OCaml with the lazy keyword and can build
the same kind of lazy data structures [4], strict vs. non-strict
semantics seems like a moot point. In Haskell you have to explicitly
tell a function to be strict, in OCaml you have to explicitly tell it
to be lazy. Six of one, half-dozen of the other. :slight_smile:

[1] http://www.univ-orleans.fr/lifo/Members/David.Teller/software/comprehension/
[2] "The Whitespace Thing" for OCaml
[3] Wearing the hair shirt: a retrospective on Haskell (2003) - Microsoft Research
[4] http://enfranchisedmind.com/blog/2007/01/01/ocaml-lazy-lists-an-introduction/

[1] The inability of ocamlopt (up to 3.09.2 or so, 3.10.0 can on some
platforms) to generate PIC code is not a problem on win32, see [274896].
The next release of OCaml will feature dynamic loading of native code.

--
Mauricio Fernandez - http://eigenclass.org

Regards,
Jordan

···

On Dec 19, 4:58 am, Mauricio Fernandez <m...@acm.org> wrote:

On Wed, Dec 19, 2007 at 08:29:59AM +0900, MonkeeSage wrote:
> On Dec 18, 9:17 am, "jwmerr...@gmail.com" <jwmerr...@gmail.com> wrote:
> > On Dec 17, 11:32 pm, Sharkie Landshark <shark.fin.s...@mac.com> wrote:

What tool(s) would you recommend for that?

The full sentence probably should have been: There are a few scripts
that translate a subset of ruby to C. I don't think they are ready for
prime time.

With respect to "stalin", IIRC early editions of the language shootout
included timings for this compiler.

I guess I should have padded that statement with disclaimers. And I guess
locking my door against those damn KGB agents would have helped, as well.
Alas, I have to smile every time they walk by and make me swear allegiance.

···

On Dec 18, 2007 2:43 PM, Jean-François Trân <jftran@rubyfrance.org> wrote:

2007/12/18, Vitor Peres <dodecaphonic@gmail.com>:

> Stalin is great,

I would never imagine to read such a sentence in this mailing-list.

--
Vitor Peres (dodecaphonic)
------------------------------------
http://twitter.com/dodecaphonic

Since Haskell creates stubs for C, how difficult would it be to write a
Ruby Wrapper around it? Wouldn't that be a better solution in that case?

···

--
Posted via http://www.ruby-forum.com/.

> AFAIK, rocaml could in principle[1] work on
> Win32, at least with the MinGW and cygwin builds of Ruby and OCaml

May I ask if somebody has succeeded in building rocaml on cygwin?

Well, you don't actually build rocaml itself, but rather use it to build Ruby
extensions written in OCaml. rocaml does essentially two things: generate the
C wrappers and create a Makefile. The logic behind the latter is what needs to
be adapted to the platform.

I'm not aware of anybody having used rocaml on cygwin. Some changes to
rocaml_extconf.rb (think of it as an extension to the common extconf.rb and
mkmf.rb) would be required in things like:

ocaml_native_lib_path = %w[
  /usr/lib/ocaml/**/libasmrun.a
  /usr/local/lib/ocaml/**/libasmrun.a
].map{|glob| Dir[glob]}.flatten.sort.map{|x| File.dirname(x)}.last

As you see, it's just a matter of adjusting paths, compiler flags and so on:
fairly easy work that requires access to the platform, however.

> What do you miss when you're doing OCaml instead of Haskell

Eager vs lazy evaluation makes some difference, I'd suppose.

Yes; what I wanted to know is in which direction :). I understand that lazy
evaluation is not something you necessarily miss, as it's got some associated
costs (as MonkeeSage said, if Haskell has strictness annotations, OCaml has
got lazy expressions, so we're concerned with the default evaluation
strategy). I've found contradicting opinions about the difficulty of analyzing
the behavior of programs under lazy evaluation: some people say only newbies
are bitten by that, others reply that even Haskell experts bump into puzzling
cases where seemingly minor changes can affect performance greatly, in both
directions.

Likewise, I was wondering if somebody versed in Haskell will find impure
languages painful, or if some side effects here and there will be considered
acceptable.

···

On Wed, Dec 19, 2007 at 08:45:04PM +0900, tho_mica_l wrote:

--
Mauricio Fernandez - http://eigenclass.org

There is a backward way of using Objective-C
You create a lib in Objective-C and then use the RubyCocoa approach...
Of course, this isn't very portable...