caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Frank A. Christoph" <christo@nextsolution.co.jp>
To: "John Skaller" <skaller@maxtal.com.au>
Cc: "OCAML" <caml-list@inria.fr>
Subject: RE: convincing management to switch to Ocaml
Date: Wed, 25 Aug 1999 15:34:01 +0900	[thread overview]
Message-ID: <001b01beeec3$d148dfc0$0150ebca@nextsolution.co.jp> (raw)
In-Reply-To: <3.0.6.32.19990825135019.009a8990@mail.triode.net.au>

> >Anyone on this list can name twenty
> >signifiicant things that C++ lacks and Ocaml possesses.
>
> 	Perhaps, but:

John,

I started off writing this message as a point-by-point rebuttal of your
rebuttals, but the truth is that I'm neither prepared nor inclined to get
into a debate on the technical finer points of C++. I admit that I have
sometimes been surprised by C++'s ability to emulate some of the features of
other languages (via templates, function objects, the placement operator,
...), but in each case this is significantly mitigated by the fact that
programmer needs to share much of the burden, for example, because he must
follow some unusual or subtle programming practice, or because there is just
so much syntactic overhead associated with it, or because C++ just can't
enforce some significant static guarantee, or whatever.

For example, you suggested that C++ supports parametric polymorphism via
templates. But the truth is that templates are a far cry from true
parametricity. First, templates are only intensionally polymorphic, i.e.,
they imply code duplication. Second, they aren't parametric because the
template may silently put constraints on instantiable classes. Third, the
user must explicitly instantiate a template to use it.

I think it is silly to suggest that C++ is anywhere near as safe as Ocaml or
any ML derivative. There is a world of difference between a language that
_can_ be used safely by following good programming practices (and I am
skeptical even that C++ satisifies this claim), and one that _enforces_ them
statically. For me, at least, it is the latter fact that makes ML most
attractive.

Anyway, let me address the non-technical issues:

> >Lack of a reference: Is this really a fair criticism?
>
> 	It is irrelevant whether it is FAIR or not.
> The issue at hand related to whether management should choose
> C++ or ocaml. Fairness is relevant only by relation to
> the requirements, not the background of the product.
>
> 	I could say it is NOT fair to say C++ is overly complex,
> since it is designed as an extension of the woeful C language.
> But I won't say that, because it isn't relevant: C++ really
> is complex, and the 'why' of it isn't important.

OK, that's sensible. Then let me suggest this: although there is no
(English) literature on Ocaml per se, there is certainly a significant
amount of literature on functional programming in general, and a huge amount
on the mathematical foundations of functional programming. I've always found
that, although the details are of course different, the important points
carry across very well. That's one reason I don't find this such a big
problem, personally. If you know Haskell, or Scheme, or lambda-calculus, or
universal algebra, or type theory... you essentially know Ocaml.

Of course, more literature never hurts either.

> >Lack of ISO standardization: Who cares?
>
> 	A very large number of organisations.
> I do too because either I can tell the vendor that their
> product doesn't meet specifications,
> or I can lodge a Defect Report, saying the specifications are unclear or
incorrect.
> I can't do that for ocaml -- although I can appeal
> to this newsgroup for help.

Sure you can. You can write the implementors. They read this list anyway.

> >I don't think it is logical to criticize a _language_ for not being
widely
> >used, not having third-party publications, or lacking ISO
standardization.
> >That sounds more like a criticism of language _users_. :)
>
> 	I wan't being critical of the language per se, I was pointing
> out that there are arguments in favour of management using C++:
> clearly there are more arguments than just technical ones,
> and they cannot be dismissed.
>
> 	I'm just commencing an IT project where the implementation
> language will be C/C++. Much as I _personally_ would like to use
> ocaml, I'm not even going to suggest it. All the other programmers
> use C/C++ and there simply isn't time for them to learn ocaml.
> The customer wants C/C++ too. He may have reasons beyond
> mere 'programmer availability' -- such as being able to
> read the code himself, and being able to sell the product
> to clients that may require C++, or even an ISO Standardised
> language (most government agencies seem to require that).
>
> 	These arguments are not technical: they're social.

And political.

> 	I should say: I have reasons for liking ocaml
> other than the language. It is based on category theory,
> and is developed by mathematicians. THAT gives me
> much more faith than anything else.

Me too. Although I like Standard ML better from this perspective, since for
example it has a published semantics.

--FC




  reply	other threads:[~1999-08-26 17:36 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-07-28 14:47 STARYNKEVITCH Basile
1999-07-30  9:00 ` Markus Mottl
1999-08-13 10:32   ` John Skaller
1999-08-25  1:51     ` Frank A. Christoph
1999-08-25  3:50       ` John Skaller
1999-08-25  6:34         ` Frank A. Christoph [this message]
1999-08-26 18:36         ` Stefan Monnier
1999-08-29  6:08           ` John Skaller
1999-08-27 10:00         ` Andreas Rossberg
1999-08-28  6:24           ` John Skaller
1999-08-30 15:59             ` Sylvain BOULM'E
1999-08-31  5:50             ` Brian Rogoff
1999-08-28 19:51           ` Dave Mason
1999-08-30 19:05             ` Xavier Leroy
1999-08-30  8:02           ` Pierre Weis
1999-08-30 19:35             ` John Skaller
1999-08-31 17:10               ` Pierre Weis
1999-09-03  6:56                 ` John Skaller
1999-08-31 19:03               ` Stefan Monnier
1999-09-03  7:28                 ` John Skaller
1999-08-31  0:13             ` John Prevost
1999-08-31  5:19               ` John Skaller
1999-08-31  6:35                 ` John Prevost
1999-09-03  5:42                   ` John Skaller
1999-08-31 16:24           ` Gerard Huet
1999-07-30 14:42 ` John Skaller
1999-07-30 18:49 ` Gerd Stolpmann
1999-07-30 21:30 ` Francois Rouaix
1999-08-12 10:36 ` Reply to: " Jens Olsson
1999-08-16 18:33   ` Chris Tilt
1999-08-12 12:15 ` Frank A. Christoph
1999-08-15  8:14   ` Friedman Roy
  -- strict thread matches above, loose matches on Subject: below --
1999-09-07  7:24 TommyHallgren
     [not found] <John Skaller's message of "Tue, 31 Aug 1999 15:19:48 +1000">

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='001b01beeec3$d148dfc0$0150ebca@nextsolution.co.jp' \
    --to=christo@nextsolution.co.jp \
    --cc=caml-list@inria.fr \
    --cc=skaller@maxtal.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).