RE: [Caml-list] 32 bit floats, SSE instructions

[Brian Hurt <bhurt@spnz.org>]

Dropping into advocacy here.  I'd have taken this off-list but your email 
server doesn't like me.

On Tue, 8 Jun 2004, Brandon J. Van Every wrote:

> 
> Well hand me a general purpose GPU with an incredible 2-way memory bus,
> smart guy.  Hint: commodity 3D graphics cards are fast when you write to
> them, damn slow when you read them, by design.  Shader programming is
> exceedingly limited in scope, it is not a general computational
> facility.
> 
> > In the case of OCaml, the language is there because it is a research
> > project. Adding 32-bit floats doesn't count as research these
> > days. Not even in France. ;-)
> 
> OCaml has a somewhat practical focus, but maybe it's not sufficiently
> practical for me.  I do find myself re-evaluating languages in terms of
> 3 overriding problems:
> 
> - the available C++ migration path and its efficiency

No language I am aware of that isn't specifically designed to be 
interfaced with C++ can interface with C++.  I'd imply that C++ was 
specifically deisgned to be hostile to other languages, but that would 
imply the standards committee was actually thinking through the 
implications of their decisions.  This includes, by the way, C.

Heck, even C++ compilers have trouble with C++.  Take a look at this paper 
comparing the conformance levels of various C++ compilers:
http://www.cs.clemson.edu/~malloy/projects/ddj/paper.pdf
The *best* compilers are still only 90% compliant.  And this isn't even 
touching the issue of name mangling differences.

I'll go a step farther than that, and state that it is *impossible* to 
write correct code in C++.  What gets churned out is reams of C++ code 
that simply isn't obviously broken.  Let's play a game, spot the bug.  Can 
you spot the bug hidding in these two lines of C++ code?  (and yes, 
Virginia, this bug *has* bitten me)
	char * buf1 = new char[100];
	char * buf2 = new char[100];

Interface with *C*, no problem.  Heck, how can a language do even the 
simplest of I/O without interfacing to C?  But C++?  I'm not sure I'd want 
to program in a language with a good interface to C++.

Oh, and by the way, in the opinion of every C++ advocate I know, you're 
not programming in C++ unless you're using both templates and the STL.  C 
with classes, after all, is just too much like C.

If the library you absolutely need (and can't rewrite) is written in C++,
then you probably should write the program in C++.  If you can use J2EE,
you should probably use Java.

> - the support of basic 3D graphics types, i.e. 32 bit floats

Hmm.  Silly me, I thought the basic 3D graphics types were vectors, 
matricies, and quaternions.

> OCaml currently has 1 out of 3.
> See for point of reference, "Why No One Uses Functional Languages."
> http://cm.bell-labs.com/cm/cs/who/wadler/papers/sigplan-why/sigplan-why.
> ps.gz

Let's see.  Been a while since I've read this paper.  His reasons are:

1) Compatibility.  By which he means with C and C++, and mainly, it seems, 
with C.  Ocaml is quite compatible with C.  As for C++, see above.

2) Libraries.  This is primarily a function of either a) rampant 
popularity, or b) major corporate backing.  In other words, functional 
languages are not popular because they're not popular.

3) Portability.  Having actually written portable C-89 code that ran
unmodified and without #ifdefs on everything from 8-bit embedded
controllers to supercomputers, this isn't as easy as people think it is.  
Of course, throw C99 into the mix and this level of portability goes out
the window (pop quiz: without ifdef's, how do you print out a size_t value
without truncation that works on both C89 and C99?  Remember that on C89
you doen't have inttypes.h, and on C99 sizeof(size_t) > sizeof(unsigned
long) is a distinct possibility- in fact, on 64 bits windows that is the
case). 

Note that this is for a language in which 100% conformance to the standard
is basically assumed.  C code isn't *portable*, it's simply *ported*.  
Where the mines are in this particular minefield are simply well known to 
those of who've ported C code.

4) Availability.  This seems to break down into three complaints: first, 
that installing Haskell is hard (it may very well be, I've never tried it.  
Compiling and installing Ocaml from scratch was a breeze even the first 
time I tried it).  Second is that there isn't a company to give money to.  
Which, I bet, is a function of popularity.  Were an open source compiler 
to become popular (like, oh, say GCC), companies would no doubt spring up 
to support it for money (like, oh, say, Cygnus).  And third, that the 
languages are still under active development.  Given C++'s history with 
standards, I'd consider C++ more of a moving target than Ocaml.

5) Packability.  Ocaml has it.  So does Haskell, by the way.

6) Tools.  Ocaml has a debugger and a profiler.  Fancy tools that cost 
$2000 a seat Ocaml doesn't have yet (and I question wether Ocaml needs).  
But the existence of $2000 a seat tools is a function of popularity- which 
means holding this lack against Ocaml is yet another case of Ocaml not 
being popular because Ocaml isn't popular already.

7) Training.  Most programmers don't already know functional programming 
languages, so they refuse to learn them.  Yet another variation on Ocaml 
not being popular because Ocaml isn't popular already.

8) Popularity.  Where he comes out and says Functional languages aren't 
popular because they aren't popular already.

Which raises the question of why *isn't* Ocaml more popular than it is?  
My theory is the following reasons:

1) Big words.  Most of the Ocaml books I've seen so far introduce topics 
like currying, higher order functions, and lambda calculus way to early.  
This scares off your average programmer.

2) Not Invented Here.  Specifically, Not Invented in Industry.  Eww-
research cooties!  The implicit assumption of your average programmer is
that people in academia never do "real" work, and wouldn't know it or
understand it if it bit them on the ass.  Never mind that writting and
maintaining a cross-platform optimizing compiler qualifies as real work,
they're certain that no one in academia would ever do something like that.  
At most, they think, an academic would just write a proof of concept,
allowing them to handwave past minor problems, and then promptly abandon
the code and return to writting proofs and journal papers.

3) Marketing.


> That's not automated C++ migration, 

When I was thinking of C++ integration, I wasn't even thinking 
automatically C++ integration.  I'm not sure that's possible in any sort 
of sane way even to C-  consider the memory management aspects.  Plus all 
the C++ specific problems, like templates.

> "We live in a world of very bright people building
> crappy software with total shit for tools and process."
>                                 - Ed Mckenzie

... and who are violent opposed to improving them.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners