Functional compilers in the mainstream 
Author Message
 Functional compilers in the mainstream

Quote:
> Erlang is a special case.....stuff removed....
> ....And it is obviously geared toward telephony applications.

Not really. Of course Ericsson is using Erlang to build
Telephony stuff, but I can't recall one single library,
or tool delivered together with Erlang, which is particular
aimed at telephony (perhaps with the exception of the ASN.1
compiler). Instead you'll find a Distributed Database, a CORBA
interface, a Web-server, etc + lots of libraries to support
the building of complex and robust control systems.

/Tobbe
+---------------------------------------------------+
| Torbj?rn T?rnkvist                                |
| WWW:   http://www.*-*-*.com/ ~tobbe         |
+---------------------------------------------------+



Mon, 05 Feb 2001 03:00:00 GMT  
 Functional compilers in the mainstream

Quote:

> Much of the issue, as I see it, is that there are relatively small groups
> focused on each language (Haskell, Clean, SML, Ocaml) with usually a
> single option when it comes to selecting a compiler.  As a result, the
> choice of language is tied-up in the choice of compiler.  

In SML's case, I believe that there is already healthy competition
between compiler producers. Take a look at the FAQ for comp.lang.ml and
you'll see a number of implementations, including:

   SML/NJ (SML to native code, implementing the full SML'97 standard +
extensions)

   MLWorks (SML to native code, again implementing the full SML'97
standard)

   Moscow ML (bytecode interpreter implementing core SML + limited
modules)

   MLJ (SML to Java bytecodes implementing SML'97 except for functors --
but these are coming)

As a member of the MLJ team, I can certainly confirm that we're looking
at the competition. We put every iteration of MLJ through our benchmark
suite, together with some other compilers, comparing code size, compile
times and run times. We've got the additional `problem' that run time
(and memory allocation behaviour) is hugely dependent on the JVM
implementation used to run the code (with a factor of 10 even between
different so-called JITs).

It's not just performance that matters of course. All of the above
implementations have their pros and cons. SML/NJ has some useful
extensions (concurrency, call/cc, higher-order modules), MLWorks has a
GUI-based programming environment, Moscow ML produces small executables,
and MLJ has language extensions for invoking Java methods and writing
Java classes in ML.

Quote:
> And there's a circle:
> with no one pushing the implementors to increase the quality of their
> tools, there won't be any feedback as to what is needed.

We're actually rather disappointed at the lack of feedback from MLJ
users. Come on everyone, tell us what you want!

Quote:
> One suggestion I have is that I'd like to see web pages added to the
> key compiler sites discussing the methods used for code generation,
> the types of optimizations being done, examples of good and bad cases,
> and some benchmarks comparing different versions of a compiler.  This
> can be fairly informal; I think I might feel better about using a
> particular functional compiler if I could see how it worked on a
> somewhat nitty-gritty level and how it was being improved.

We certainly plan to do this for MLJ. For now, you can download a
preprint of a paper to be presented at ICFP'98:

  http://research.persimmon.co.uk/papers/icfp98.ps.gz

This covers some of the optimisations and data representation choices
that we have made in the MLJ compiler. For the compiler itself, see

  http://research.persimmon.co.uk/mlj/

There are a number of ML benchmark programs that are getting quite long
in the tooth now (boyer, fft, knuth-bendix, simple, etc.). We use these
in our benchmark suite, along with some others of our own. But I would
like to point out three problems with these programs:

(1) They're quite small. Naive static analyses don't scale well, so
compilers may produce excellent code on small programs but not on large
ones. For example, in a small program the function map might be applied
only to functions taking pairs of values as arguments. (e.g. map (fn
(x,y) => x+y)). The compiler could then arity-raise the argument
functions. But as soon as map is used (even just once) with a function
*not* taking a pair the arity-raising is prevented (Simon Peyton Jones
calls this the `poisoning' problem). A more sophisticated compiler might
decide to specialise map into two versions -- one for arity-raised
functions, one for others. The naive compiler and sophisticated compiler
would both look good on small programs but the sophisticated compiler
would win on large programs that re-use functions such as map in many
ways.

(2) Many compilers are sensitive to the modular structure of the code.
For instance, a compiler that shall remain nameless (not MLJ) performed
badly on the life benchmark but improved its run-time by a factor of 10
when the single-module program was constrained by a signature that
exposed only the "main" function. One explanation may be that there were
a number of polymorphic functions defined by the structure (including
re-implementations of map, fold, etc.). Without a signature, the
separate compilation methodology of the compiler forced these functions
to use some kind of boxing for their arguments. When the structure was
constrained by a signature, the polymorphic functions did not need to be
exported and so could be specialised (they were probably used at only
one type inside the structure anyway!). The opposite can happen: in a
multi-module program, a structure may include a type definition that is
declared abstract by the signature and so values of that type will be
boxed by a compiler that uses traditional separate compilation. Without
the signature, the concrete type is exposed to the rest of the program
and so need not be boxed.

Anecdotally, on some compilers the modular structure of even small
benchmark programs can be seen to affect compile time and run time. The
finer the granularity of modularisation, the faster the compile time and
the slower the run time (notwithstanding the remarks about the life
benchmark above). Presumably the compiler has a good stab at optimising
programs divided into large chunks, thus increasing compile time and
decreasing run time.

By the way, MLJ takes a whole-program approach to compilation (though it
parses, type checks and partially optimises modules separately) so the
modular structure of a program has *no* influence on performance.

(3) Although the canonical benchmark programs have been `converted' to
comply with the SML'97 standard and to use the new Standard Basis
Library, they are *not* the programs that a programmer with a good
knowledge of the Standard Basis would have written. I've already
mentioned that the life benchmark reimplements functions such as map and
fold. Other benchmarks manipulate strings by first exploding them into a
list of single-character strings, applying some list functions, and then
imploding them back. Instead, one could use the more sophisticated
functionality of the String and Substring structures in the new Standard
Basis. This could be regarded as more `typical' code that a proficient
SML programmer would write.

This is turning into a plea for good benchmark programs. Of course, such
things don't exist, but I hope that the above points make people wary of
tables of benchmark figures. They're a guide, but really the best test
is your own code.

-- Andrew.
----------------------------------------------------------------------
Dr Andrew Kennedy, Research Scientist | fax:   +44 1223 322501
Persimmon IT                          | phone: +44 1223 578770

Cambridge, CB4 1YG, UK                |



Mon, 05 Feb 2001 03:00:00 GMT  
 Functional compilers in the mainstream

Quote:

> I'd like to start some discussion on the current state of functional
> language compilers, specifically when will they start being used for
> mainstream work.  Note that I don't say "When will functional languages be
> used..." because I believe they're already more than good enough.  There's
> just the usual resistance to "new" ideas.

  Define "mainstream".

  FP has been used for profitable industrial applications for several
years.

  In my world "mainstream" means telecomms products. Erlang was first
used in a profitable product (the mobility server) in 1995. This is
now selling well (I cannot reveal the sales figures).

  The AXD301 (ATM switch written in Erlang) was released in 1997 -
sales figures are encouraging.

   http://www.ericsson.se/Eripress/19980819-0005.html

   (Issued Yesterday!) is the latest press release about a USD 10
Million contract for 13 AXD301's to for the *backbone* of a Chinese
ATM network. This was won in face of heavy competion.

   10M$ might not qualify for mainstream, but we're getting there.
What does it take to convince people that FP is in the mainstream
100M$ contracts, 1B$? - wait and see ... :-)

Quote:
> Much of the issue, as I see it, is that there are relatively small groups
> focused on each language (Haskell, Clean, SML, Ocaml) with usually a
> single option when it comes to selecting a compiler.  As a result, the
> choice of language is tied-up in the choice of compiler.  If, say, the
> Glascow Haskell Compiler generate horrendous code (I don't know if it
> does; this is just an example), then Haskell is ruled out for many types
> of work, regardless of how nice the language it.  And there's a circle:
> with no one pushing the implementors to increase the quality of their
> tools, there won't be any feedback as to what is needed.

> Erlang is a special case, IMO, because there are strong commercial
> interests behind it.  Judging from the "send email for pricing" tag on the
> Erlang web site, I suspect it is priced for use in large-scale
> applications.  And it is obviously geared toward telephony applications.

  False.

  Erlang is not geared towards telephony applications - it is geared
towards fault-tolerant soft real-time distributed multi-platform
applications (like telephony :-). But you can equally well use it for
real-time train controllers (ask Robert for the code!).

  The free version can be used for very small scale applications.

  The "send email for pricing" is for the full "kit" (the full
libraries, design patterns etc.).

        /Joe



Mon, 05 Feb 2001 03:00:00 GMT  
 Functional compilers in the mainstream

Quote:

> I'd like to start some discussion on the current state of functional
> language compilers, specifically when will they start being used for
> mainstream work.  Note that I don't say "When will functional languages be

Old ideas receive as much resistance as do new ones. This
is particularly true today, when fashion trends have taken over
from technological soundness in the computer/language biz.

Specifically, APL ( andJ and K and ...) continues to be hounded by the
"Oh, that Old Language. Do people still use it?" school of, umm,
"thought".

APL continues to be used by people who need rapid solutions to
problems so that they can make rude amounts of money. These
include:
  actuaries -- in a recent poll taken by the Society of Actuaries,
               APL was the language most frequently used by them.

  merchant bankers/traders -- big banks such as Morgan Stanley,
               Credit Suisse, Deutsche Bank, Bank of Montreal,
               and others use APL extensively for applications
               where they need instantaneous development of
               models or analytics tools.

My favorite example of the latter's value was a large trading or
analysis (not sure which) system used at Morgan Stanley. This
system, written in APL, was in use over Black Monday. My understanding
of what happened on Wall St that day was:

a. Some banks' systems died due to overflow on money and/or trading
   volumes, leaving their traders to guess what the market was doing.

b. Other systems got bogged down, running hours late, and giving
   traders hopelessly out-of-date information so that they traded
   themselves in deeper and deeper holes.

c. The APL system at Morgan Stanley kept running, didn't fall
   behind, didn't break, and Morgan actually made a (small) amount
   of money that day.

APL is also heavily used at pharmacutical firms and petrochemical
companies, for modelling and analysis.

With suitable compilers (shameless plug
here: http://home.ican.net/~bernecky), APL can match or beat
fortran code, so your comments about performance are correct.

SAC and SISAL have also made excellent progress on the performance
of functional array languages. What we need now is to make one
of those robust enough to serve as a generic intermediate language
for array compilers, so that we don't all have to reinvent the
same optimizers.

Bob



Mon, 05 Feb 2001 03:00:00 GMT  
 Functional compilers in the mainstream


Quote:
>I'd like to start some discussion on the current state of functional
>language compilers, specifically when will they start being used for
>mainstream work.

There are at least two functional languages that are used routinely
for commercial work: Erlang and Ocaml.  Although there are many
other fp systems available, these two have robust and clean
implementations, with good code generators and convenient,
full facilities.  Not to disparage Clean, SML/NJ, Hugs, Haskell,
and so forth, which all have their proponents and advantages ...
Erlang and Ocaml are proven for mission-critical work, I think.

My compiler for the actuarial language "Alfa" is completely
implemented in Ocaml, and has been delivered to many
commercial clients.  It is as fast as a C/C++ implementation
(that is, it compiles most user programs in one second on a
Pentium 233, and the longest compilation on record is 6
seconds).  There have been few bugs and no support problems
with the Ocaml tools, which was rather surprising to me in
the beginning of the project, although I've come to expect it
from Xavier Leroy and Pierre Weis, the main Ocaml contacts.
All in all, Ocaml is the finest language implementation I've ever
had the pleasure to use in my 32 years of programming.  

I would try Erlang, except that it's not free for commercial
use.  I would try Clean, except that it too is not free ... and
I wish it were, because I am fascinated by the language
and would really like to be using it.  I have tried hugs/
gofer/Haskell but I find that I prefer strict evaluation to
lazy; it makes my understanding of what a function is
doing simpler, so there are fewer misunderstandings in
my way when I'm designing and debugging. ( Also, the
versions I tried were not as fast as Ocaml.)   I've tried
SML/NJ and would probably be using it if Ocaml weren't
around.  Ocaml seems a lot cleaner and easier to work
with, for me than SML/NJ; plus, I like the new object
stuff in Ocaml - it has a class language that is quite
innovative.  But as far as delivering a runtime product
to a commercial Win/NT client - SML/NJ is a little klunky in this
area, compared to Ocaml, I think.

I would try MLWorks, but again, it's proprietary.  If you're
going to stretch the field a bit and write an application in
an fp language, you don't want to tie yourself to a single
vendor.  What if they go out of business, or get bought out,
or change focus?  What if you have a bug and  it's in your
way for an imminent release of your product?  If you're
bound to a commercial non-source-released product,
then you have to wait for the vendor, and if you're not a
big multi-licensed client, your request goes to the bottom
of the queue.  Why not MLWorks?  Well, let's say that it
was 1989 and you wanted to write a commercial fp app and
you chose Miranda, a great language, but one that was
commercial, although not very much money to buy.  So you
wrote your 50,000 lines of Miranda code and delivered
your app.  Now here we are a few years later, and the author
has decided to drop support.  There aren't all that many
users, so he wants to make some money on something
else; what do you do?  You're stuck with an aging app
that you now have to call "legacy."  Not good.

Such might be the scenario if I were to choose Clean or
MLWorks.  Not worth the risk.  If Clean were free, like Ocaml
is free, well then, we'd have a whole new ballgame.  You'd
see a few hundred new users in the blink of an eye, and
Ocaml might have some competition.  (And the authors
might make more money on it than they are now, from the
additional consulting and perhaps book sales, were they
to write great references and guides.  It's the standard
Cathedral-vs-Bazaar software development argument;
see mozilla.org for the original paper.)

Erlang is a special case.  My issues with it are that it was
designed early on, and there is a lot of code written using
its idiosyncracies.  So it's not the language that Ocaml is,
unfortunately, IMHO.  On the other hand, there's nothing
like success:  at last count, 2.37 bazillion lines of Erlang
code were deployed in serious commercial applications.
It's fast, pretty clean, and well debugged.  But they want
money for it, if you really want to use it; and I don't know
if they let the sources out.

Dwight



Mon, 05 Feb 2001 03:00:00 GMT  
 Functional compilers in the mainstream

Quote:

> Suppose I were a contractor, and I had the following array of
> projects before me:

> 1. a networked scheduling program for use by travel agencies
> 2. a compiler for a custom language
> 3. a GUI-heavy word processor for Linux
> 4. a realtime 3D game for Windows 95

> [...] Most functional languages would be just
> fine for the first two.  But I don't think anyone would choose Ocaml or
> Erlang or Haskell for the last two

The forthcoming ML Workshop '98 has a paper by Fran?ois Pessaux on a
Doom-style 3D graphics engine written in Objective Caml.  Amazingly,
performance is about 80% of that of a similar implementation written
in C, and the high-level features of ML allow a very clean handling
of the basic data structure (BSP tree) of that kind of engines.

In addition to performance-critical parts such as the graphics engine
and the sound engine, modern games also have significant amounts of
AI-like code to handle e.g. "intelligent" monster behavior, and I
would expect a functional language to be better suited than C or
Pascal for programming this.

As for GUI-intensive applications, some functional language
implementations come with very decent GUI toolkits -- see e.g. CamlTk
for OCaml.  It is easier to write a decent GUI in CamlTk than in Motif,
for instance.  While I haven't heard about any word processor written
in a functional language, the MMM Web browser
(http://pauillac.inria.fr/mmm/index-eng.htm) is entirely written in
OCaml/CamlTk.

- Xavier Leroy
--

This is a protection against junk mail. Apologies for the inconvenience.
Home page: http://pauillac.inria.fr/~xleroy/



Mon, 05 Feb 2001 03:00:00 GMT  
 Functional compilers in the mainstream

Quote:

> By "mainstream," I mean "a feasible choice for most applications one would
> encounter."  Suppose I were a contractor, and I had the following array of
> projects before me:

I don't know if "mainstream" captures what you want as much as
"universal"; something that one could use for both low-level bit sloshing
as well as high level stuff. My own feeling on this is that it is OK to
use different languages for different tasks, hence good foreign function
interfaces are important for tasks which span high and low levels of
abstraction.

Quote:
> 1. a networked scheduling program for use by travel agencies
> 2. a compiler for a custom language
> 3. a GUI-heavy word processor for Linux
> 4. a realtime 3D game for Windows 95

> C, C++, or Pascal would be feasible--though not necessarily the best
> choice--for all four options.  Most functional languages would be just
> fine for the first two.  But I don't think anyone would choose Ocaml or
> Erlang or Haskell for the last two, even though they are wonderful
> languages to program in.

I don't think 3 is a problem for Ocaml. 4 definitely is; I'd have to
write an OpenGL interface (or worse!), and then I'd worry about the GC
kicking in of course. Still, if you're willing to code large chunks in C
or assembly, you might be able to get away with it, though I'd choose an
imperative language myself for 4.

Quote:
> Why is this?  Is it because very visual
> applications--with all of their state dependencies--aren't a good match
> for the functional style?

Neither Erlang nor OCaml are "pure" functional languages, so this issue
about dealing with state is a red herring. I think the real issues have
more to do with the overhead of GC (*) , the fact that most real programs
will require some C coding (at least to deal with available APIs), and
most importantly, the fact that few programmers at all are familiar with
any functional languages.

Quote:
> Or is it simply because desktop systems live in
> a rapidly changing fad-following environment, and the relatively small
> teams of compiler developers can't keep up?

At least in the case of OCaml, the small developer team has done an
amazing job. Besides, I think only a fairly small minority of programmers
is working on programs that require real-time rendering, hard real time
control systems, balls-to-the-wall numeric simulations, etc. Huge numbers
of programmers are using tools like Python, Perl, Visual Basic, Tcl, and
other languages which are not known for being lightning fast.

The best way to change the situation is to write code, and preferably give
it away, of course!

-- Brian

(*) What I meant here was that a GC pause in the middle of rendering would
    make for an unpleasant game; I know that some GCs don't do this but
    some compilers don't let you choose your GC implemenattion :-(



Mon, 05 Feb 2001 03:00:00 GMT  
 Functional compilers in the mainstream

Quote:

> The forthcoming ML Workshop '98 has a paper by Fran?ois Pessaux on a
> Doom-style 3D graphics engine written in Objective Caml.  Amazingly,
> performance is about 80% of that of a similar implementation written
> in C

I like Caml, but I'm always worried when I hear these sorts of
comparisons being made.

You say "Doom-style", so what is the performance compared to Doom
itself?  In other words, two similar, slow, programs don't tell us
anything with respect to the actual state of the art for games written
in C, which is what the original question was.

Moreover, does "80% performance" include memory and working set, or is
this the usual "assume infinite RAM" oversimplification.



Mon, 05 Feb 2001 03:00:00 GMT  
 Functional compilers in the mainstream

Quote:


> >Define "mainstream".
> >...
> >In my world "mainstream" means telecomms products. Erlang was
> >first used in a profitable product (the mobility server) in
> >1995. This is now selling well (I cannot reveal the sales
> >figures).

> Very encouraging!

> Of course, Ericsson has also written tens of millions of lines of PLEX
> which have been used in commercial products for twenty years or more, but
> I'd hardly call PLEX mainstream.

> By "mainstream," I mean "a feasible choice for most applications one would
> encounter."  Suppose I were a contractor, and I had the following array of
> projects before me:

> 1. a networked scheduling program for use by travel agencies
> 2. a compiler for a custom language
> 3. a GUI-heavy word processor for Linux
> 4. a realtime 3D game for Windows 95

> C, C++, or Pascal would be feasible--though not necessarily the best
> choice--for all four options.  Most functional languages would be just
> fine for the first two.  But I don't think anyone would choose Ocaml or
> Erlang or Haskell for the last two, even though they are wonderful
> languages to program in.  Why is this?  Is it because very visual
> applications--with all of their state dependencies--aren't a good match
> for the functional style?  Or is it simply because desktop systems live in
> a rapidly changing fad-following environment, and the relatively small
> teams of compiler developers can't keep up?

    Personally, I don't think  any one langage will  be good for a lot
of different applications.

    From your above list I'd choose

        Erlang for 1)
        Prolog for 2)
        C & Xlib or Motif for 3)
        C++ for 4)

    The programming langauges I  use are Erlang  (lots) C (a bit)  and
Visual Basic (a  bit). I choose the  most appropriate language for the
job.

    Instead of asking "is FP mainstream" I'd like to ask.

    1) Can FP earn lots of money for the companies that invest in it and
       can they earn more money using FPLs for their applications
       than if they were to use Java or C++

    2) Can I learn a decent living as a programmer if I learn FP

 [[ answers Yes and Yes - but then I'm biased ]]

        /Joe



Tue, 06 Feb 2001 03:00:00 GMT  
 Functional compilers in the mainstream

Quote:

> Erlang is a special case.  My issues with it are that it was
> designed early on, and there is a lot of code written using
> its idiosyncracies.  So it's not the language that Ocaml is,
> unfortunately, IMHO.  On the other hand, there's nothing
> like success:  at last count, 2.37 bazillion lines of Erlang
> code were deployed in serious commercial applications.
> It's fast, pretty clean, and well debugged.  But they want
> money for it, if you really want to use it; and I don't know
> if they let the sources out.

    The position is as follows:

    1) There  are at least 35.345  teragodzillion lines of  Erlang out
there.

    2) There is a free release but you can't do commercial things with
it - it's the full language so don't worry. You  can try it out for as
long as you  like and  for free. If  you  want  to make  a  commercial
application then you need a licence.

    3) There are 7 different Erlang implementations either ready or on
the way.

    4)  Marc  Feely (Gambit scheme,   Montreal Univ.) is collaborating
with us  to make a 100% free  100% complient Erlang  system. This will
not have a single line of proprietry code in it.

    So while Erlang is not  free for  commercial applications *at  the
moment* free   implementations  will be available  from   2'nd sources
(i.e. NOT Ericsson) real soon.

        /Joe



Tue, 06 Feb 2001 03:00:00 GMT  
 Functional compilers in the mainstream

: > 3. a GUI-heavy word processor for Linux

:     From your above list I'd choose

:       C & Xlib or Motif for 3)

Why wouldn't you choose something like Squeak Smalltalk or the free
Linux version of ObjectShare's Visual Smalltalk? Xlib and Motif
programming has to be one of the least productive activities. These
Smalltalk's have fantastic GUIs, good performance for word processors,
and are not much different from Lisp, Erlang, and other
semi-functional languages.

--


                 http://www.gemstone.com



Tue, 06 Feb 2001 03:00:00 GMT  
 Functional compilers in the mainstream

Quote:


> : > 3. a GUI-heavy word processor for Linux

> :     From your above list I'd choose

> :  C & Xlib or Motif for 3)

> Why wouldn't you choose something like Squeak Smalltalk or the free
> Linux version of ObjectShare's Visual Smalltalk? Xlib and Motif
> programming has to be one of the least productive activities. These
> Smalltalk's have fantastic GUIs, good performance for word processors,
> and are not much different from Lisp, Erlang, and other
> semi-functional languages.

    'Cos I'd never heard of it don't like smalltalk and don't like OO.

    (Just to show that I'd not biased I don't like Xlib and Motif as
well)

    I also don't like using GUIs (though writing them can be fun!) -
and I'd never write a GUI-heavy word processor for Linux 'cos there
are lots already. What interests me at the moment is trying to factor
large composite numbers that might happen to be the products of two
large primes. Now *that's* a mainstream application!

        /Joe



Tue, 06 Feb 2001 03:00:00 GMT  
 Functional compilers in the mainstream
[Sending courtesy Cc: to Dwight VendenBerghe, plus Cc: to the
current Grand High Poomba of Open Source(tm)ness, esr.]

Dwight, thanks for your thoughtful and informative article
(quoted below in its entirety).

You suggest that your readers see mozilla.org for more
information about the business case for Open Source(tm), and
i thought that you should know that the canonical site is
http://opensource.org/.  (Frankly, i find this web site to be
somewhat...  amateurish in aspect and tone.  This is
unfortunate, but i still recommend it, as it is the official,
most comprehensive, and best-maintained site of Open Source(tm)
advocacy.)

The "Businessperson's Case" for Open Source(tm) as elucidated
on the web site doesn't emphasize what i believe is the most
compelling argument for the makers of Clean -- that by making
Clean Open Source(tm) they would gain a great boost in
publicity and wide distribution, probably helping them to
create a large and active user base.

Personally, when shopping for new tools to adopt, i start at
http://www.debian.org/, which has both a nice categorized
catalog of packages with (truthful(!)) advertising blurbs plus
a utility that downloads and seamlessly installs the software
into your (Debian) system.

Soon, and in part because of your letter, Dwight, i'm going to
click on the "Install Ocaml" button.

("http://www.debian.org/Packages/unstable/devel/ocaml.html")

I sincerely hope that the makers of Clean will give
consideration to your suggestion, as i would like to learn
Clean, but don't want to invest the effort into a proprietary
technology, for many of the same reasons that you enumerate
below.

Regards,

Zane

P.S.  This is the first time i've tried to use the "(tm)" marks
after "Open Source" and it produces, i think, an ugly result.
I'll probably abandon the practice.

-------


Quote:
>I'd like to start some discussion on the current state of functional
>language compilers, specifically when will they start being used for
>mainstream work.

There are at least two functional languages that are used routinely
for commercial work: Erlang and Ocaml.  Although there are many
other fp systems available, these two have robust and clean
implementations, with good code generators and convenient,
full facilities.  Not to disparage Clean, SML/NJ, Hugs, Haskell,
and so forth, which all have their proponents and advantages ...
Erlang and Ocaml are proven for mission-critical work, I think.

My compiler for the actuarial language "Alfa" is completely
implemented in Ocaml, and has been delivered to many
commercial clients.  It is as fast as a C/C++ implementation
(that is, it compiles most user programs in one second on a
Pentium 233, and the longest compilation on record is 6
seconds).  There have been few bugs and no support problems
with the Ocaml tools, which was rather surprising to me in
the beginning of the project, although I've come to expect it
from Xavier Leroy and Pierre Weis, the main Ocaml contacts.
All in all, Ocaml is the finest language implementation I've ever
had the pleasure to use in my 32 years of programming.  

I would try Erlang, except that it's not free for commercial
use.  I would try Clean, except that it too is not free ... and
I wish it were, because I am fascinated by the language
and would really like to be using it.  I have tried hugs/
gofer/Haskell but I find that I prefer strict evaluation to
lazy; it makes my understanding of what a function is
doing simpler, so there are fewer misunderstandings in
my way when I'm designing and debugging. ( Also, the
versions I tried were not as fast as Ocaml.)   I've tried
SML/NJ and would probably be using it if Ocaml weren't
around.  Ocaml seems a lot cleaner and easier to work
with, for me than SML/NJ; plus, I like the new object
stuff in Ocaml - it has a class language that is quite
innovative.  But as far as delivering a runtime product
to a commercial Win/NT client - SML/NJ is a little klunky in this
area, compared to Ocaml, I think.

I would try MLWorks, but again, it's proprietary.  If you're
going to stretch the field a bit and write an application in
an fp language, you don't want to tie yourself to a single
vendor.  What if they go out of business, or get bought out,
or change focus?  What if you have a bug and  it's in your
way for an imminent release of your product?  If you're
bound to a commercial non-source-released product,
then you have to wait for the vendor, and if you're not a
big multi-licensed client, your request goes to the bottom
of the queue.  Why not MLWorks?  Well, let's say that it
was 1989 and you wanted to write a commercial fp app and
you chose Miranda, a great language, but one that was
commercial, although not very much money to buy.  So you
wrote your 50,000 lines of Miranda code and delivered
your app.  Now here we are a few years later, and the author
has decided to drop support.  There aren't all that many
users, so he wants to make some money on something
else; what do you do?  You're stuck with an aging app
That you now have to call "legacy."  Not good.

Such might be the scenario if I were to choose Clean or
MLWorks.  Not worth the risk.  If Clean were free, like Ocaml
is free, well then, we'd have a whole new ballgame.  You'd
see a few hundred new users in the blink of an eye, and
Ocaml might have some competition.  (And the authors
might make more money on it than they are now, from the
additional consulting and perhaps book sales, were they
to write great references and guides.  It's the standard
Cathedral-vs-Bazaar software development argument;
see mozilla.org for the original paper.)

Erlang is a special case.  My issues with it are that it was
designed early on, and there is a lot of code written using
its idiosyncracies.  So it's not the language that Ocaml is,
unfortunately, IMHO.  On the other hand, there's nothing
like success:  at last count, 2.37 bazillion lines of Erlang
code were deployed in serious commercial applications.
It's fast, pretty clean, and well debugged.  But they want
money for it, if you really want to use it; and I don't know
if they let the sources out.

Dwight



Thu, 08 Feb 2001 03:00:00 GMT  
 
 [ 26 post ]  Go to page: [1] [2]

 Relevant Pages 

1. commerce, fp, Open Source Software(tm) (was: Re: Functional , compilers in the mainstream)

2. Why aren't functional languages mainstream?

3. Why functional programming will never be in the mainstream

4. A compiler / interpreter for a functional language?

5. dissertion titel for compiler for functional lang

6. IRs for functional language compiler !

7. FAQ pointer for functional language compilers.

8. Parsers, compilers in functional languages

9. Implementing Functional Compilers/Interpreters

10. functional decompostion (was Dos Ada Compiler)

11. But Smalltalk isn't mainstream - response

12. Mainstream K URL & New K User Group

 

 
Powered by phpBB® Forum Software