Re: When functional languages can be accepted by industry?

[Brian Rogoff <bpr@best.com>]

On Thu, 20 Apr 2000, Markus Mottl wrote:
> > 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. 

In another life I wrote lots of numerical linear algebra programs, and I 
find that a little overloading would make the code a lot nicer. It's also 
the case that lots of prefix functions, like "print", are perfectly fine 
to overload, and I hate having to explicitly tag these names with their
type, probably the way fans of type inference hate writing explicit types. 
Can't we have the best of both worlds?

Also, I suspect that many people who are negative about overloading are 
coming from C++, where the combination of overloading and implicit
coercion is nightmarish. Coming from Ada, I haven't had any such problems, 
so I still miss overloading. 

> However, there is one application domain where I really feel
> "bitten" by not being allowed to overload operators: monads.

Funny that you should say that, I've been spending a bit more of my spare 
time hacking Haskell for the same reasons you describe below. I translated 
almost all of the monads in Wadler's "Essence of FP" paper to OCaml but 
ended up using regular prefix syntax. Yes, if you use different monads 
simultaneously you have to use qualified names. Bummer.

No, I haven't got to Hughes "arrows" yet; its taking enough effort to get 
comfortable with 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...

... snip ...

> 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.

Absolutely! This is a point I have been making for a while, that the point 
of comparison should be Perl, Python, and even Java. OCaml performance is 
excellent when compared to these languages.

The main problems here are 

(1) The enormous number of existing libraries (and tools for managing them) 
    for these other languages
(2) The extensive documentation they have
(3) The OCaml error messaging, which makes worse the problem most people 
    already have with the unfamiliar type system

> > > 	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...

Fortunately for me, my employer really likes OCaml :-)

-- Brian