Re: [Caml-list] Some Clarifications

[Paul Snively <psnively@mac.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jul 27, 2005, at 1:33 PM, skaller wrote:

> On Wed, 2005-07-27 at 09:37 -0600, Robert Morelli wrote:
>
>
>> My contention is simply that the program is incomplete;  there's
>> more to be discovered by implementing more of mathematics.  The
>> attitude that OCaml is some kind of pinnacle of language development,
>> already capable of dealing with all problems (and anyone who fails to
>> agree must simply be ignorant),  is quite depressing to me.
>>
>
> Good heavens, no one here believes that!

Yes, that's quite a straw man. I'd also point out that examples like  
Axiom and its Aldor language don't support the assertion that OO is  
somehow better suited to the domain than FP is; on the contrary, they  
point out that even today, the best research into the automation of  
mathematics takes place in even richer functional languages with  
richer type systems than O'Caml's. I think most of us on the list are  
aware that, e.g. even plain ol' Haskell 98, with its typeclasses, has  
some advantages over O'Caml, nevermind GHC 6.4 with its GADTs, and  
nevermind Aldor or Cayenne or Epigram or DML or any of the other  
languages with one kind or another of dependent types.

But as John said, many of us appreciate that O'Caml runs on several  
platforms, generates plenty good-enough native code for many of those  
targets most of the time, pays some attention to representation  
issues in arrays and records, doesn't slavishly abstract from the  
underlying hardware but is nevertheless memory safe, has a nice time- 
travel debugger, a profiler for native code, syntactic extensibility  
that rivals Lisp's, a rapidly growing set of impressive libraries,  
good foreign-function interfaces, and a top-notch community. O'Caml  
is the language that I think of as "the obvious alternative to C++,"  
and I wouldn't hesitate to use it commercially on real-world  
projects, if only it had bindings to Carbon or Cocoa on Mac OS X. :-)

Also, as others here have pointed out, O'Caml programmers aren't  
necessarily averse to using objects when they actually buy us  
something, but O'Caml doesn't use objects as an organizational  
dumping ground the way C++ or Java do, since O'Caml has an actual  
module system, parametric polymorphism, and higher-order functions  
(yes, I know you know all of this). So perhaps your (Robert) argument  
is better levied against Haskell programmers, or Concurrent Clean  
programmers, or Standard ML programmers, than O'Caml programmers? In  
any case, to the extent that your point is that O'Caml isn't the end  
of the language design road, I think we're in vehement agreement.  
However, if your argument is also that object-oriented languages  
taken apart from features such as higher-order functions, module  
systems, parametric polymorphism (or, these days, even with  
parametric polymorphism bolted on), somehow have a clearer  
evolutionary path than functional languages, I'll have to disagree  
wholeheartedly. However, it's not clear to me, actually, what your  
argument is at this point, so I'll stop here.

Best regards,
Paul Snively

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iEYEARECAAYFAkLoHTwACgkQO3fYpochAqJLKwCfSruR2rr1CxUGa2D4659yyzk1
4WEAoLh0FDRvr36r3Uaaw7DsveHN4nWo
=ufoe
-----END PGP SIGNATURE-----