Re: [Caml-list] The boon of static type checking

[Thomas Fischbacher <Thomas.Fischbacher@Physik.Uni-Muenchen.DE>]

On Sun, 13 Feb 2005, Daniel Heck wrote:

> > Could you give a specific example, but *please* one that is not related to 
> > killing people?
> 
> Having seen you start this very discussion on another mailing list,
> would you *please* consider taking this question to a list that is
> dedicated to C++, just for a change?

(1) I had to search a bit through my memories, but you are right in this 
point: this discussion also came up once on one other list I'm active on, 
which is (a) non-public and (b) on which a very broad range of topics are 
covered. Just had a check: my last article on that list was an explanation 
from a physicist's point of view of the infeasibility of using a research 
reactor's enriched uranium to build a nuclear weapon, after that question 
arouse. The next-to-last was personal experience concerning notebook 
repairs. My last message before that was about college fees in germany. We 
would have to go back in time through considerably more than a dozen of 
other topics that came up and where I posted a comment before we
reach that single one programming language thread that arouse during 
the last five years.

Perhaps only an independent member of both lists may objectively judge 
this, but to me it seems a bit as if you just picked out that one single 
discussion out of so many I've been involved in, furthermore from a 
non-public list - so that no one can check, to make me appear in a bad 
light. I really don't want to claim that this is bad intention from your 
side, especially as I would not expect members of that other list to 
spread libel, but you should be able to understand that, taking above 
facts into account, it actually has to look a lot like such from my 
perspective.

(2) Concerning the objective claim that some of the C++ related postings 
on this list by me (and others) were a bit off-topic, you are right. Just 
as the discussion about state in Haskell, say. It might well be that some
people consider this inappropriate to a larger extent, and some to a 
lesser. My personal point of view on this issue is that ocaml is a fringe 
language, and so one cannot reasonably do "just ocaml", but it is 
important to also look left and right, see what other people who come 
from different languages are lacking, and what they find great about 
ocaml. The perl community is especially great in listening to and learning 
from other communities, incorporating useful approaches in an 
unbureaucratic way (even if they sometimes choose inappropriate approaches 
which they later have to correct). At least, that was, I'd say, the 
primary key to perl's success: the ability to listen and understand.

> Frankly, your only reason for
> subscribing to this ML seems to be to extol the virtues of Lisp and to
> bash C++, which is a nuisance for everyone who reads it in the hope of
> learning about OCaml...

If this is your personal impression, I fear, you totally must have missed 
the point in many of my postings!

Let's concentrate on "the Lisp issue": yes, I would describe myself as a 
mostly Lisp guy. Nonwithstanding, I have done existing, real, working, 
free, known, large applications in ocaml. Concerning more recent 
discussions here, I tried to give a somewhat balanced view what aspects 
of ocaml I - as a lisp hacker - both especially love and especially 
dislike - you can check that in the archive.

Ocaml is a new language, and as every new language, it first of all has to 
justify why it is appropriate to destroy synergy effects: every new
language introduces barriers. Imagine you want to solve a problem which 
has two complex aspects for which libraries exist, but unfortunately, the 
one is written in, say, python, and the other one in sml/nj. Great 
situation. Besides this, every new language requires the 
re-implementation of a lot of core functionality in the form of 
libraries, which introduces lots of opportunities for both security 
problems and bad design, and burns a lot of human work.

I think ocaml does have a score of features that justify its existence, 
see an earlier posting of mine that gives detailed reasons.

But the discussion also showed that there seem to be widespread deep 
misconceptions concerning one simple question: what ideas *truly require* 
the invention of a new language, as they can not be added on top of an 
existing system? After all, we have perl, pike, php, python, rexx, ruby, 
scheme, tom, tcl, and many many more. Typically, these started out as "a 
quick small elegant solution to a specific problem" that required full 
programming flexibility. Gradually, people realized that they needed X 
plus support for more data types, then IPC (networking), database 
access, threads, various mime support, then... So, they all became more or 
less functionally equivalent (with different ugly quirks in the different 
systems), with the one distinguishing feature of nothing more than 
their indivuduality, that is, they cannot easily talk to one another. 
I consider this quite unfortunate, but perhaps not everyone will. 
Could it have been avoided, and if, how, and what can we learn for the 
future? I think the key to all this is the question: does X really require 
the introduction of a new programming language, or can we implement X as a 
library on top of an existing system? People just too hastily jump on the 
wagon of building a new language.

As I saw it as evident in one case that practically no one would believe 
me otherwise, I showed in one posting - by explicit construction -
that it is very well possible to add pattern matching to a language 
(which happened to be lisp, as it's the most extensible one) as a library. 
Hence constructor pattern matching support evidently does *not* belong to 
the set of properties that inevitably require the construction of an 
entire new system from scratch. Was this relevant to ocaml? For the 
following reason I strongly think so: whoever wants to introduce ocaml 
for a new project usually has to give a good justification for this.
I occasionally get into precisely this situation myself. And I 
prefer to then use reasons that convince because they are true, and 
stay away from those which merely are easily believed but wrong.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)