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

[Michael Walter <michael.walter@gmail.com>]

Your argument regarding Lisp and O'caml ignores the fact that
programming languages are to a large part about syntax - for obviously
valid reasons like accessability, maintainability, expressiveness,
etc.

I feel I've mentioned that so many times it should be in some FAQ ;o)

Michael


On Sun, 13 Feb 2005 19:28:42 +0100 (CET), Thomas Fischbacher
<Thomas.Fischbacher@physik.uni-muenchen.de> wrote:
> 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)
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>