From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA26576 for caml-redist; Fri, 21 Apr 2000 19:23:29 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA12800 for ; Thu, 20 Apr 2000 19:59:04 +0200 (MET DST) Received: from shell5.ba.best.com (shell5.ba.best.com [206.184.139.136]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id TAA26287 for ; Thu, 20 Apr 2000 19:59:03 +0200 (MET DST) Received: from localhost (bpr@localhost) by shell5.ba.best.com (8.9.3/8.9.2/best.sh) with ESMTP id KAA13299; Thu, 20 Apr 2000 10:58:55 -0700 (PDT) Date: Thu, 20 Apr 2000 10:58:55 -0700 (PDT) From: Brian Rogoff To: Markus Mottl cc: caml-list@inria.fr Subject: Re: When functional languages can be accepted by industry? In-Reply-To: <200004201640.SAA05607@miss.wu-wien.ac.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: weis 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