From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id UAA22986; Fri, 18 Oct 2002 20:53:06 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id UAA23170 for caml-list@pauillac.inria.fr; Fri, 18 Oct 2002 20:53:05 +0200 (MET DST) 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 UAA18903 for ; Fri, 18 Oct 2002 20:43:30 +0200 (MET DST) Received: from pop9.ucdavis.edu (pop9.ucdavis.edu [169.237.105.19]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g9IIhS518474 for ; Fri, 18 Oct 2002 20:43:28 +0200 (MET DST) Received: from beech (mail@[128.120.141.217]) by pop9.ucdavis.edu (8.11.6/8.11.0/IT4.6.2) with ESMTP id g9IIhQ622562 for ; Fri, 18 Oct 2002 11:43:26 -0700 (PDT) Received: from issac by beech with local (Exim 3.35 #1 (Debian)) id 182c6G-0001JX-00 for ; Fri, 18 Oct 2002 11:43:56 -0700 Date: Fri, 18 Oct 2002 11:43:56 -0700 To: OCaml Mailing List Subject: Re: [Caml-list] Is Caml a fraud ( especially on Windows )? Message-ID: <20021018184356.GA2828@beech> References: <3daf2a4f.865261093@smtp.interaccess.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3daf2a4f.865261093@smtp.interaccess.com> User-Agent: Mutt/1.3.28i From: Issac Trotts Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk [ snip ] > The second incident involves ocamlc and cameleon. Trying to get > cameleon to compile ( more on that later ), I discovered that ocamlc > called cl.exe ( MS C/C++ compiler ). The reason is obvious. ocamlc > translates ocaml to c and then passes it to the compiler. This creates > two things I have difficulties with: You can see that ocamlopt directly produces assembly code by running ocamlopt -S some_program.ml and looking at some_program.s > 1) There is from the main caml page a link to a page where the person > claims to have benchmarked C vs caml and caml wins. I had several > > problems with that page, ( The main one, he uses goto's to > optimise his code. The problem is that the optimiser in a C > compiler has a much harder time with goto's present [ they are > nonlocal branches ]. So I have to trust he does a better job at > optimisation than the compiler would do. Yeah sure. ) but > learning that caml generates C code as an intermediate language > makes his statement false. If caml generates C that creates an > executable, then caml code can never run faster than C. > 2) After a bit of thought I realised something. If the compiler > generates C code which gets compiled, then odds are that the > debugger is a wrapper of gdb. Big problems on Windows. This > may indicate that there is no debugger for Windows. Sure enough > ocamldebug is not present. There is the source for ocamldebug in > cameleon, but who knows if it compiles. The premise of (2) is false, at least on Linux. I don't see why it would be any different on Windows. Have you looked at what's being sent to cl.exe? > The third incident was trying to get cameleon to compile on Windows. > At the time I tried this, several other people were asking about > cameleon problems, so one of the creators did something incredibly > stupid. He created a seperate mailing list for cameleon problems. > It was incredibly stupid because the two major problems I had were: > 1) A camlp4 problem, and 2) the path of cl.exe. These were two > problems where the problem was with caml in general, and it would > help to have the input of the people on the mailing list. I suspect > many cameleon problems are like that. Then post them on the ocaml list or send a bug report to the ocaml developers. Do you expect the author of cameleon to predict your problems and use this prediction to decide whether he will start a mailing list? > But worse. I have to build cameleon in order to get ocamldebug. That's not true of any OCaml distribution I've ever downloaded. What makes you think this? > Even if I get it to build I am likely to have troubles, if as I > suspect it is gdb based. So I'm likely to spend a lot of time trying > to get something to work that will probably fail anyway. Time I could > and should spend learning a programming language. Why not take the time to verify what you're claiming? > The more I play with it the more I get the feeling that I am working > with a Lexus system on Unix and a Yugo on Windows. This is not > what I meant when I said it must run on both Windows and Linux. > And the people who told me it runs on both probably understood this. > In other words they LIED about the current condition of Caml. > Just as the people who are responsible for cameleon LIED about it's > status on Windows. I've written some small OCaml programs in Windows so I know it can be done. It's easier in Unix, but Unix makes a lot of things easier for programmers so why would anyone be surprised? If you want OCaml to be easier to work with in Windows, why not roll up your sleeves and do something about it? > So now I have to wonder what other lies there are about caml. > Let's say that I decide to keep learning caml and a year later > have an opportunity to use it on a job. Are the libraries that > the documentation says are there going to be there? Are they > going to work correctly? What about stuff on the hump? > Am I going to find myself high and dry and having to implement > some library to get my application to run. Am I going to have to > adjust my estimates. How would I explain taking twice as long to > complete an application when I promised half as long? > > And how can I trust caml people to tell me the truth, when they've > lied to now? You haven't done your homework. Don't blame the OCaml community for that. OCaml takes longer to learn than some other languages, but if you have the patience to stick with it I think you'll find that it pays off. Issac ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners