From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 8AB6BBC32 for ; Wed, 16 Mar 2005 11:25:12 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j2GAPC03030653 for ; Wed, 16 Mar 2005 11:25:12 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id LAA11408 for ; Wed, 16 Mar 2005 11:25:11 +0100 (MET) Received: from first.in-berlin.de (dialin-145-254-053-183.arcor-ip.net [145.254.53.183]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j2GAP9pL026066 for ; Wed, 16 Mar 2005 11:25:09 +0100 Received: by first.in-berlin.de (Postfix, from userid 501) id 4FA73BBFDC; Wed, 16 Mar 2005 03:55:33 +0100 (CET) Date: Wed, 16 Mar 2005 03:55:32 +0100 From: Oliver Bandel To: caml-list@inria.fr Subject: Re: [Caml-list] OCaml troll on Slashdot Message-ID: <20050316025532.GA593@first.in-berlin.de> References: <42363A86.6010309@1969.ws> <200503150859.55997.jon@ffconsultancy.com> <200503152036.45894.jon@ffconsultancy.com> <32977.131.254.50.45.1110920621.squirrel@mail.irisa.fr> <172f01077499b3d417604d0ad31f2bdb@cs.unm.edu> <20050316001819.GB347@first.in-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Miltered: at nez-perce with ID 42380988.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 42380985.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; oliver:01 bandel:01 oliver:01 in-berlin:01 caml-list:01 ocaml:01 bandel:01 in-berlin:01 toplevel:01 ocaml:01 imho:01 toplevel:01 recursive:01 rec:01 recursive:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.2 X-Spam-Level: On Wed, Mar 16, 2005 at 02:05:43AM +0100, Yoann Padioleau wrote: > Oliver Bandel writes: > > > But with > > > > let columnSize = 5;; > > and with > > let numRows = 7;; > > > > (look at the ";;" it seems he had used it in the toplevel... :)) > > And ? Only nice to see. Nothing more. ;-) It's only that I think about it, because he talks with seemingly bad intentions about OCaml. (a kind of C++ dogmatism) > First, I dont think it is a good idea to make fun of people who try to use caml. I don't do that. But I can't see that there is really an interest in exploring OCaml. If he only would be cynic about "well I tried it, but it has proven it's a crap language... but I give you (experienced OCaml programmers) the chance to show me that it isn't bad (and *I* have o learn the language)" then this woul be ok. But it seems that he's saying: "well, OCaml never can compete with C++". Maybe I'm wrong here and he's a good guy. But IMHO it seems he's looking for proved Ocaml-failure (and not for "well, I tried it, it seems OCaml sucks, but please tell me it does not!", which I could accept). > Second, many people I know still put ";;" cos they were taught that way Hey, that was the way I started too! :) That comment from me only shows: Well, it seems he's an absolute beginner. To be a beginner is not wrong. It's good! To be a beginner every day and every time means: to be open for new things every time! That's good! :) But as stated above: Would be nice if the OCaml-bashing would contain at least a bit of "maybe I'm wrong, and I only use cynism, because I thaught it performed better (or It's easier to learn). Maybe I've overlooked that positive-thinking approach behind his harsh words?! > (at the very beginning with caml-light I think you were forced to put those ";;", it > became optional later, and habits are hard to change for many people :) ) > Third, doing stuff at the toplevel is a good idea. Yes. So, what are we talking about? Do you think *I'm the bad guy*?! "mea culpa" ?!!!???? > > > which does not really looks tail recursive. > > > > Called more than 2 * 10^6 times... > > > > And many other examples... > > > > > > e.g. this one: > > > > (* applies a list of functions to an argument *) > > let rec applyFunctionList functions argument = > > (* 267386 *) match functions with > > | [] -> (* 9782 *) [] > > | f::rest -> (* 257604 *) (f argument)::(applyFunctionList rest argument);; > > > > "only" called 267386 times, but when looking how the arguments > > are used: also applyFunctionList is not tail recursive... > > ...and even if called less than 10^6 times... it's a function that > > creates a list in a non-tailrec way. > > > > IMHO this is the reason, why the program performs so badly! > > IMHO the reason it was slow is because it used associative list (instead of Map) > for associative access, Maybe it is. I don't say it is *not*. I have not loked into the code in so much detail that I could see that the associative map is the problem or is not. If the list is short, an associative list may not perform so badly. (Correct me, if I'm wrong.) But IMHO creating the environment for a function that is non tail-rec needs more ressources than using assoc-lists ionstead of maps in that application (Correct me, if I'm wrong). (And maybe - if it is always the case - that all depends on the amount of data/how often functions are called and so on. > and list of list (instead of array) for storing the grid. Yes, that also seems to be a problem. > I am not sure that making the function tail-recursive would have been the big > hit in this example. But as long as nobody tried it / analzed it, your assumption is only an assumption, as my assumption is only an assumotion too! ... IMHO it makes sense in a field where THE solution is not already known, to come out with ideas that are *possibly* solutions to a problem. So, nothing else is "use map instead of..." and "use arrays instead of...". The real freaks doesn't post to that thread, as it maybe is trivial to them, to talk about that stuff...?! > I often transform my functions to make them tail-recursive because of stack overflow pb, not > that much because of speed pbs > (and many functions in the standard library are not tail-recursive, such as map) Well, maybe I have overestimated the tailrec-point, but as long as there is not a proven counter-example, the opposite of what I stated seems to be only an assumption too. Maybe such freaks like the OCaml core-team, or M.Mottl will see in milliseconds what is going on... but the whole thread on slashdot (and here) seems to be guessing from many people. If I'm wrong, please show me. !!! To see different results it would be nice to have different implementations !!! to compare them all! > > > > > Ths stuff of tail recursion - even if it took a while > > until I got it - was one of the first things on this list, > > that people told me that it is necessary.... > > I am not sure it is the first optimisation trick to give to a fresh ocaml programmer. That is a thing what special studied computer science people gave me as one of the first hints on that list. (And wehen looking in SICP, it seems, that it's very necessary to think abot it in more detail.) Would be interesting to have different variations of the code, using different ways of coding some special tasks in different ways.... and maybe oe implementation, that uses *all* suggestions. To do it in the language shootout, as on Jon stated it, seems to be a veryg good idea. > > This tail-recursion stuff is one of the thing I hate the most with fp because it forces > you to change your code to adapt to the machine whereas it should be the > inverse. But only because you hate it does not mean that changing the code will not result in better performance. At least for that list-creating stuff I have (e.g. reading in a file and write it to a list of lines) I have seen the advantages (in speed!) when using tailrec versions or imperative versions) instead of simple recursion. And some of that troll-code's functions are really doing that! Build lists by building lists non-tailrec. > I don't understand why the compiler don't do himself those transformations. Well I understand, why a compile does not do that job: because it's too complicate for a programmer of a compiler to implement that feature. ;-) But on the other side I think the same: Why not implementing such stuff directly into the compiler?! Would be nice... (... or not, because we never would think about what we are doing then...) > Why is it so hard to take a non-tail-recursive-function and make it a tail-recursive-one ? It's not hard, it's only "practise, practise, practise" or "exercise, exercise, exercise..." ;-) One of the people on this list once shwed a way of how to change a loop into tailrevc-stuff in general (shown for two or three args of a func). (Remi Vacant?!). Maybe I have somewhere a printed page of it and can look for it / find it... Ciao, Oliver P.S.: Well... too much beer this night... :(