3 ms·

writing fast-running code in these languages can be painful/ugly Seriously? The OCaml implementation is about as fast as C and -- if you were to look at the l

writing fast-running code in these languages can be painful/ugly Seriously? The OCaml implementation is about as fast as C and -- if you were to look at the language shootout -- fast OCaml code is digestable for pretty much anyone with even minimal exposure to the language. The OCaml execution model is simple. Now, with Haskell you might have a point.

marketer 18y ago
I wouldn't use Ocaml (and, to a similar extent Haskell or Erlang), for anything beyond research projects or small prototypes. These languages are research-driven, not community driven, and they have plenty of features that nobody wants except the maintainers. In the case of Ocaml, just take a look at crap like camlp5 and polymorphic variants. Language shootouts are poor benchmarks for the quality of a languge. Better metrics are community activity and the quality of the libraries.
- Xixi 18y ago
  You are completely wrong about Erlang, which is absolutely not a research language, but when combined with OTP a very pragmatic tool designed by Erlang to answer their specific needs. Now it doesn't mean that it's the right tool for any problem, but when used for the right jobs, it is awesome : elegant, mature, rock stable and definitely production ready. And the community is growing... For more generic purpose as far as functional languages are concerned F# might have a go, if Microsoft continues to push its efforts to integrate it in Visual Studio and make it mainstream. With .net/mono under the hood the libraries are there. Not completely production ready yet in my opinion, but hopefully soon I'll be able to use it instead of C# when I have something (fast) to do on top of mono...
- daleharvey 18y ago
  I just wanted to clarify the other comment to this, erlang was was written at erickson to solve specific problems, it was driven by a business need, not communities or research.
- hassy 18y ago
  The AXD301 ATM switch, one of Ericsson's flagship products, 1.7 million of Erlang code. This is just one example of large-scale software projects written in Erlang. Your perception of it as a research language needs to be re-evaluated.
time_management 18y ago
OCaml's great, but my understanding is that you have to use imperative features in order to get C performance. For most programs, you don't care about getting C performance, and functional OCaml code does an excellent job. I should not have said that writing "fast-running" code in Ocaml is painful and ugly, since normal OCaml code runs fast enough for most purposes. What I meant to say is that writing optimized code in OCaml can be painful.
- jlouis 18y ago
  You don't need C's performance in 99% of the code. In fact, in most projects you far from need C's performance anywhere. Had it been the case, then fewer would write Ruby, Python or PHP these days. The performance of OCaml is really good if you write no imperative code. If you have a cost-centre that bothers you, it is pretty easy to get it fast: OCamls compiler does very little optimization, so a bit of manual rewriting helps a long way. There are several documents on the net that explains how to manually optimize a cost centre.

marketer 18y ago

I wouldn't use Ocaml (and, to a similar extent Haskell or Erlang), for anything beyond research projects or small prototypes. These languages are research-driven, not community driven, and they have plenty of features that nobody wants except the maintainers. In the case of Ocaml, just take a look at crap like camlp5 and polymorphic variants. Language shootouts are poor benchmarks for the quality of a languge. Better metrics are community activity and the quality of the libraries.

Xixi 18y ago
You are completely wrong about Erlang, which is absolutely not a research language, but when combined with OTP a very pragmatic tool designed by Erlang to answer their specific needs. Now it doesn't mean that it's the right tool for any problem, but when used for the right jobs, it is awesome : elegant, mature, rock stable and definitely production ready. And the community is growing... For more generic purpose as far as functional languages are concerned F# might have a go, if Microsoft continues to push its efforts to integrate it in Visual Studio and make it mainstream. With .net/mono under the hood the libraries are there. Not completely production ready yet in my opinion, but hopefully soon I'll be able to use it instead of C# when I have something (fast) to do on top of mono...
daleharvey 18y ago
I just wanted to clarify the other comment to this, erlang was was written at erickson to solve specific problems, it was driven by a business need, not communities or research.
hassy 18y ago
The AXD301 ATM switch, one of Ericsson's flagship products, 1.7 million of Erlang code. This is just one example of large-scale software projects written in Erlang. Your perception of it as a research language needs to be re-evaluated.

time_management 18y ago

OCaml's great, but my understanding is that you have to use imperative features in order to get C performance. For most programs, you don't care about getting C performance, and functional OCaml code does an excellent job. I should not have said that writing "fast-running" code in Ocaml is painful and ugly, since normal OCaml code runs fast enough for most purposes. What I meant to say is that writing optimized code in OCaml can be painful.

jlouis 18y ago
You don't need C's performance in 99% of the code. In fact, in most projects you far from need C's performance anywhere. Had it been the case, then fewer would write Ruby, Python or PHP these days. The performance of OCaml is really good if you write no imperative code. If you have a cost-centre that bothers you, it is pretty easy to get it fast: OCamls compiler does very little optimization, so a bit of manual rewriting helps a long way. There are several documents on the net that explains how to manually optimize a cost centre.