"Todd Gillespie" <toddg / linux127.ma.utexas.edu> wrote in message news:9jkqck$m74$1 / geraldo.cc.utexas.edu... > Steve Tuckner <SAT / multitech.com> wrote: > : I was recently introduced to Objective Caml ( http://www.ocaml.org > : <http://www.ocaml.org> ) but haven't had the time to understand it yet. I thought I had already posted - I was just about to post a request on Ruby vs. OCaml. At the great shootout editorial, you'll find OCaml, then Ruby mentioned: http://www.bagley.org/~doug/shootout/editorial.shtml (what should I do without Google :) > : * Its very fast - many times it is as fast as straight C (I think speed is a .... > Can you back this one up? It is true that pure functionals allow for some Since I just did my research: It has a rather fast bytecode, and on many platforms there a native pipeline optimized assembler. But there is, of course, more to speed than that. > : * It is a functional language and thus the programs written in it are more > : possible to prove correct What really matters here, is whether the tools for doing that is readily available. For practical purposes this is therefore irrelevant, for theoretical purposes, Haskell is probably a better choice. > This is true. But pure functionals (Haskell in particular) can be > notoriously difficult to use with foreign data, as integrating with the > type system can be troublesome. Actually OCaml has a very clean C language interface _linker_. It goes both ways, and certainly is cleaner than the Ruby approach - despite the Ruby API is cleaner than most other interfaces. OCaml also has COM intergration, although I can say how well that is. > : * It is interpreted so it can be easily run everywhere Or compiled - whatever you choose. Very flexible runtime. > : * With object extensions, it can do all the things that object languages can > : do Yes, but is it really better. How does it manage large projects. How does the includes work? How well does this integrate with the functional programming? I certainly do like the object approach. I'm looking hard for something more powerful than C++. Ruby is a hard contender, also in expressiveness, although Haskell and the likes are hart to beat. Not sure about OCaml though. Haskell with lazy evaluation has some supernatural features I'm not sure that I'm prepared for yet. It *knows* all prime numbers in the world. It least it does after two lines of code. > This may be true, but one of the pleasing things about Ruby is its > clean object syntax. Extensions onto a language tend not to be as clean. Oh yes - many of the examples I were looking it kept me wondering - but that would have been at least as easy in Ruby. I guess the not-easily understood higherlevel functions and functor stuff is where you really see the difference. But then Ruby also has something similar - but I reckon that part of Ruby is not nearly as clean as the equivalent functional languages. I may be wrong. > You have an interesting omission -- the ML type system, which is IMOH, the > most valuable thing about the ML family. It's a sophisticated static type > system that infers all types -- no type declarations. As this is > traditionally what draws people to the MLs, you should look into it. It's strange but I like strong typing, and I like weak typing. Strong typing often prevents you from doing things, or if you get to do them, you loose flexibility or typesafety (say Java / C++). A language that gives me typesafety without the effort and gives me real expressive power is most welcome (if it is also fast in runtime). > : Downsides? I don't know enough about it to know. One may be that it is > : difficult to learn but that may just be my ignorance of the functional > : programming paradigm. Downside: there are other languages that could possibly be more expressive, and the support lib may be to small by comparison. Other languages I just went over this evening: Clean, Erlang, Haskell. Erlang is a giant to install. You don't compile it into your C++ app for certain. But might be very strong serverside. Clean - just started look at it. They claim to be on par with C in performance. > : My question to the list is: Are object-oriented functional languages the > : future instead of Ruby? With the added computing power, combined with much improved compiler technology may well make the change. But Ruby is not far from these languages. If you took a look at my interfaces? post recently, I had a case expression based on the type of a list member. Functional programming has a lot of cases, called guards and referred to as pattern matching. You do not need to write an awful lot more code than these functional languages to do similar things in Ruby. Ruby has pattern matching for strings, this could be extended to datatypes. What about regular type expressions on arrays? The greatest disadvantage of Ruby vs. functional programming is that Matz do not have enough hours in the day to write an optimized compiler that will implement functional style efficiently. He may also not have the necessary skills since optimized functional compilers are the fruits of years of advanced research. I think overall, Ruby is one of the best languages around even if it is not as powerful as some. But OCaml seem to have better compiler / runtime capabilities, which really matters a lot in software development. But just improved runtime performance of Ruby as it is, combined with faster XML processing, and you have a strong server platform. However, for the time being, Ruby lives in the realms of scripting languages where it could be so much more. But what is it with these Lisp macros? Mikkel language comparison links http://starbase.neosoft.com/~claird/comp.lang.misc/language_comparisons.html