Version française
Home     About     Download     Resources     Contact us    
Browse thread
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: William Chesters <williamc@p...>
Subject: Re: When functional languages can be accepted by industry?
John Max Skaller writes:
 > > Wrong. You have references, which are quite better than pointers
 > > (they are typed, and necessarily initialized)
 > 	.. which is a serious problem.

   We've talked about this before ...  Yes, initialising a value
sometimes means a certain number of clock cycles "wasted", but it
seems to me that any program in which those cycles are non-negligible
compared with the cycles you are going to spend on actually using the
value in question is probably a poorly written program.  It's only if
you construct a huge array of zeroes and then discard it that
initialisation can have a serious impact (?).

 > 	Oh come on. Have a look at a real library before making
 > such non-sense claims. Considerable functionality is missing,
 > the library is inconsistent, the documentation is incomplete,
 > and it is less generic than C++ STL, which is also probably
 > more efficient on almost every operation.

   STL-completeness is not the touchstone of a library's value.  I
think most people who used Java for real work found that we hardly
ever missed it (pre-1.2, Java's libraries were very unpretentious),
and enjoyed not having to spend time explaining it to co-workers ...
The STL is yet another manifestation of the terribly 80s
more-is-better (and cleverer-is-better) philosophy which permeates the
world of C++.

   To put it succinctly: have a look at what is really used (and
useful) before making such claims.  Having said that I agree the
ocaml library could usefully be grown a bit.

 > 	Show me a functional programming language that is as fast
 > as C++ and I will give up C++. :-)

   It's perfectly true that C++ is the only language in which there is
often a way to code your solution in such a way that (a) the source is
written in concise high-level terms, and (b) the object code is as
fast as it can possibly be.  Leaving aside the fact that there are
also dozens of much slower ways to code your solution---onto which all
but the most expert C++ programmers are bound by Sod's law to
light---that's wonderful and impressive.  I agree, sometimes C++ is
the only way.  But how much of the code that gets written fails to
meet the following conditions:

   -- it can run 50% (or 3 times, whatever) slower than C and it just
doesn't matter (think Java, Perl, VB, ...); or

   -- it can be written as easily, with less palaver, in plain old C; or

   -- if it's written in C++, it's done quickly and defensively, so
there's little danger of it ending up unmaintainably clever or
unstable, but also little danger of it running fast.

   I honestly don't think it's raw speed relative to C++ that's
standing in the way of the acceptance of functional languages in
industry.  However, ...

 > One barrier to acceptance of ocaml in industry: lack of
 > programmers.

... is surely spot on.