Re: [Caml-list] Some Clarifications

[Paul Snively <psnively@mac.com>]

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


On Jul 24, 2005, at 1:08 AM, Robert Morelli wrote:

> What you've quoted here is a direct and emphatic statement that what I
> wanted to discuss is something I believe is a technical issue,  not a
> conspiracy of large corporations, not an attack on a poster's
> credibility,  not a claim that some broadly useful language is
> horrendously bad,  not rhetorical deceptions,  not advocacy,  not ad
> hominem diversions.  You didn't include it in your quote,  but I also
> pointed out that functional programmers are prone to a  
> counterproductive
> form of advocacy and focus on low level issues and that they have
> generally been unsuccessful at providing practical documentation.   
> I do
> lament that,  and it is directly relevant to the original poster's
> question,  but I primarily raised that point to underline that I  
> believe
> the lack of a "theory" of large scale design issues is not a result of
> it.
>
> You may disagree with me,  and you may find my statements  
> provocative or
> unsettling,  but you cannot claim that I attempted to use a game of
> rhetorical deception,  advocacy,  or ad hominem diversions.

Hmmm. Given your lack of supporting citations or even anecdotes from  
personal experience behind your assertions, I have to take issue with  
your claim of lack of "advocay or ad hominem diversions," if you  
accept the notion of "ad hominem" arguments against a technology.  
Still, let's accept your claim of sincerity. What can those of us who  
do functional programming, particularly because we find it pleasant  
and have come from an extensive object-oriented background, say to that?

The first observation that I would make is that, in my experience,  
object-orientation as we find it in popular programming languages  
either doesn't support large-scale software engineering without  
employing idioms that present issues of their own, such as C++ with  
its lack of a module system and the Pimpl Idiom, lack of virtual  
constructors, bizarre multiple inheritance resolution semantics,  
abstract base classes via the declaration "= 0" trick, etc.) or Java  
with its distinction between primitive types and object types,  
package system  that doesn't enforce a distinction between interface  
and implementation (but at least Java has Interface and Class; it's  
just that using them well is a matter of self-imposed discipline),  
all objects inheriting from One True Object, arrays being a subclass  
of Object but null not being, all parameter passing effectively being  
by reference (i.e. no value semantics), no polymorphic constructors,  
no enumerations, and so on. Couple this with a general lack of  
understanding of the issues in ensuring that object-oriented  
programming respects the contracts expressed in the total context at  
hand: as Peter Norvig has observed, object-oriented programming is a  
discipline that requires you to understand not only what you do  
write, but what you don't. This observation led to Betrand Meyer's  
Eiffel language and "Object-Oriented Software Construction, 2nd ed."  
It's also led to the Liskov Substitutability Principle, the  
definition of which is a question I use in interviews, and it never  
ceases to amaze me how many programmers don't know it, and even if  
they do know its definition, violate it in their code. By the way,  
OOSC is one of the handful of volumes in the OO world that lends  
credence to your claim that OO has theory behind it. Abadi and  
Cardelli's "A Calculus of Objects" is one of the few others. But the  
issues in object-orientation are very real, even if you are  
extraordinarily careful to separate interface from implementation and  
adhere to the Liskov Substitutability Principle; see <http:// 
okmij.org/ftp/Computation/Subtyping/> for details. Basically, a  
common problem in object-oriented programming is the confusion of  
subtyping and subclassing, as Oleg's explanations help clarify.

An unfortunate upshot of the poor modularization support of C++ and  
Java is that C++ and Java programmers tend to turn classes into  
structural dumping grounds. I've been guilty of this myself on rare  
occasions, and even more often have been guilty of not correcting it  
when I've been maintaining someone else's code, just because I've  
judged that schedule pressures don't allow for such refactoring  
efforts. One reason that it may seem that there's more "theory of  
large-scale design" in object-orientation is precisely because the  
industry has had to identify idioms--that is, extra-lingual localized  
coding patterns--and patterns--slightly-larger-scale combinations of  
idioms that reflect a concept that lacks direct expression in the  
language family in question--to work around the problems with object- 
orientation as we find it in these popular languages. For example,  
<http://norvig.com/design-patterns/> helps explain that "16 of 23  
patterns have qualitatively simpler implementation in Lisp or Dylan  
than in C++ for at least some uses of each pattern." It's also worth  
noting that functional programming is making its way into C++, most  
apparently thanks to the Standard Template Library and its  
"functional" header and standard algorithms, but also by way of more  
featureful libraries such as Boost Lambda, the Phoenix library hiding  
inside Boost Spirit, or <http://www.cc.gatech.edu/~yannis/fc++/>. At  
the latter site, we also find a very interesting paper, "FC++:  
Functional Tools for OO Tasks."

So what are the aspects of functional languages in general, and  
O'Caml in particular, that I find to support good large-scale  
software engineering?

1) higher-order functions
2) structural, vs. nominal, typing
3) an excellent module system, with functors
4) an excellent object system leveraging all of the above, with C++- 
level power, but much more safety
5) good libraries leveraging all of the above
6) an excellent community leveraging all of the above

Witness, e.g. the thread regarding "The right way to do this in  
O'Caml?" it deals with some subtle issues and comes up with some very  
helpful answers, while also helping to identify some outstanding  
questions.

Having said all of this, I can't help but suspect that there are some  
things that we'll just have to agree to disagree about, e.g. that  
"language tools" and "formal methods" are simple domains. I also see  
some unique benefits in functional programming for mathematics,  
whether symbolic or concrete, but there are others here who either  
have chimed in on those subjects, or can do so much more ably than I  
can. All I wanted to do what to provide some pointers to some  
explanations of what some of the issues in OO are, some of the pluses  
of functional programming are, and leave you to examine them at your  
leisure. Given your particular focus on programming-in-the-large, let  
me particularly recommend the literature on module systems. The  
papers on O'Caml's module system can serve as an excellent starting  
point.

Best regards,
Paul Snively

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

iEYEARECAAYFAkLj4zMACgkQO3fYpochAqLPGgCgv+pXvI9Sd1DuWrJXe3hV4tF2
yy8An3nBP8fhTU3Cm28YGpttZpjOXhUz
=ZDOi
-----END PGP SIGNATURE-----