Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: When functional languages can be accepted by industry?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Markus Mottl <mottl@m...>
Subject: Re: When functional languages can be accepted by industry?
> In order to get an STL-like library in OCaml, I think we'd need some form
> of overloading. This comes up on this list every now and again, and it is 
> clear that the Caml team is working on it, so we'll see. I particularly
> liked the last discussion here on type classes where Pierre Weis mentioned 
> that he was interested in an overloading scheme which could unify the 
> notations for array and string access; I'd be overjoyed if he is
> successful!

Over the time I have adapted to the "lack" of overloading and do not find
it so missing for arithmetic operations. However, there is one application
domain where I really feel "bitten" by not being allowed to overload
operators: monads.

I would like to use them more often for structuring code and trying out
some new styles of functional programming, but it's a pain using different
kinds of monads at the same time: you'd always have to specify module names
for "bind"-operators, which puts the otherwise very convenient infix
operators quite out of the question. But I wonder whether this specific
application justifies a complication of the type system...

> I presume that a similar compiler for an ML variant could be written. Given 
> that the Caml team has limited resources, I'd rather they spend them
> elsewhere, as I am satisfied with the performance of OCaml for the problems 
> I apply it to. I realize that others have different priorities.

What concerns me, I also consider the performance of OCaml programs fair
enough for nearly all purposes. Since interfacing to C-code is so easy, one
can always eliminate bottlenecks on a lower level.

> There are probably other places in the implementation where choosing a 
> different strategy could close the gap with C++ in speed, at the cost of 
> code bloat. 

I do not think that C++ is competing with OCaml in the same niche so there
is probably no point in addressing differences here. In fact, although it
was surely not designed for this purpose, I believe that OCaml could be a
serious threat to some scripting languages: partly due to its high
performance, partly, because it is much saner = easier to maintain, and
highly portable! The Unix-library is very complete and would also play an
important role here.

> Also, the claim is made that C++ with templates generates code with run
> time performance comparable to hand coded C. Several studies that I've
> read call that into question; Richard O'Keefe's usenet comparison of a few 
> years ago, the book by Kernighan and Pike "The Practice of Programming" and 
> Anh Vo's papers on the Cdt library which compare it with the STL.

Programs on modern architectures depend so heavily on cache behaviour that
performance claims for code-bloating techniques seem to be rather
suspicious. I'd also like to see substantial benchmarks that prove the
merits...

> > 	Sorry. You lose HEAPS. Even 10% is significant, CAML can
> > be over a decimal order of magnitude slower. C++ generics are 
> > generally much faster (being automatically specialised -- which
> > also causes code bloat :-(
> 
> I don't think you see an order of magnitude for the most part though...

Considering the improvements on the hardware side in terms of processor
performance, 10% seems very insignificant to me (a few months of hardware
development at most), especially if you take into account that for many
non-numeric applications the limiting factor is most often I/O-bandwidth.
Correctness, maintainability and portability are (well, should be) the
primary concerns in a world that changes fast - not "fast" programs...

If your employer says that you should switch to lower-level, unsafe
programming languages to get 10% more performance, tell him that he
should rather buy new hardware (if you dare to! ;-)
If he doesn't want, present him an estimate of the costs of more errors...

Best regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl