From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 33C17D15E for ; Sun, 24 Jul 2005 20:51:50 +0200 (CEST) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.86]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j6OIpmeX020345 for ; Sun, 24 Jul 2005 20:51:49 +0200 Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/8.12.11/smtpout04/MantshX 4.0) with ESMTP id j6OIpgZI003931; Sun, 24 Jul 2005 11:51:42 -0700 (PDT) Received: from [192.168.0.100] (dsl092-032-215.lax1.dsl.speakeasy.net [66.92.32.215]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id j6OIpccg013076 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 24 Jul 2005 11:51:41 -0700 (PDT) In-Reply-To: <42E34C83.1090402@cs.utah.edu> References: <9cc3782b05071411004b27b6a4@mail.gmail.com> <42DB6161.4030507@cs.utah.edu> <42DD5F41.8060801@cs.utah.edu> <42DDECC6.8010209@exomi.com> <42E2DB1E.2010508@cs.utah.edu> <81A4F491-183D-46C4-B8A8-5DD4799B45C4@mac.com> <42E34C83.1090402@cs.utah.edu> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Ville-Pertti Keinonen , Kyle Consalus , caml-list@yquem.inria.fr Content-Transfer-Encoding: 7bit From: Paul Snively Subject: Re: [Caml-list] Some Clarifications Date: Sun, 24 Jul 2005 11:51:16 -0700 To: Robert Morelli X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Gpgmail-State: signed X-Mailer: Apple Mail (2.733) X-Miltered: at concorde with ID 42E3E344.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 hash:01 morelli:01 hmmm:01 idioms:01 constructors:01 semantics:01 arrays:01 semantics:01 constructors:01 violate:01 lends:01 abadi:01 subtyping:01 subtyping:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 -----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 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, 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 . 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-----