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 LAA31923; Fri, 18 Oct 2002 11:35:07 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 LAA31937 for ; Fri, 18 Oct 2002 11:35:06 +0200 (MET DST) Received: from chimta03.algx.net (chimta03.algx.net [216.99.233.78]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g9I9Z5516300 for ; Fri, 18 Oct 2002 11:35:05 +0200 (MET DST) Received: from d11.focal10.interaccess.com (d11.focal10.interaccess.com [207.208.141.11]) by chimmx03.algx.net (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug 5 2002)) with SMTP id <0H4600DZL7V503@chimmx03.algx.net> for caml-list@inria.fr; Fri, 18 Oct 2002 04:33:09 -0500 (CDT) Date: Fri, 18 Oct 2002 09:35:34 +0000 (GMT) From: olczyk@interaccess.com (Thaddeus L. Olczyk) Subject: [Caml-list] Is Caml a fraud ( especially on Windows )? To: caml-list@inria.fr Cc: pragprog@yahoogroups.com, ocaml_beginners@yahoogroups.com Reply-to: olczyk@interaccess.com Message-id: <3daf2a4f.865261093@smtp.interaccess.com> Organization: stickit@nospammers.com MIME-version: 1.0 X-Mailer: Forte Agent 1.5/32.451 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk When I chose to learn OCaml as my "language of the year" it seemed like a good choice. I had some basic requirements for a language: 1) There be a free ( for noncommercial use ) implementation. ( Having more people know a language is a plus for that language. I don't think it is appropriate for implementors to ask for money for the right to learn their language. Once you are actually making money using a language is a different thing. ) 2) The implementation has to produce stand alone applications. ( Scripting languages are OK. As long as the interpreter is free. ) Part of the processes of learning is to write applications. To save time I want to write applications that I need around the house. I use "database of MP3s" as the prototypical application. 3) The implementation have a generally complete library. Everything from matrix library to internet libraries. 4) The implementation must run on both Linux and Windows. I don't want to have to rewrite applications just because they run on different platforms. I don't want two different implementations, as often the portability is poor. 5) The standalones run fairly efficiently. One thing I want to do ( my final exam, so to speak ) is use the implementation for ICFP. Usually there is a soft limit on speed of executable. Also many of the applications I write tend to be CPU intensive. 6) A debugger is not required but considered a big plus. 7) An emacs mode for the language. 8) A good FFI. Caml pretty much seemed to meet all these conditions. Further it seemed like a gateway into the world of ( more advanced ) FPLs like Haskell, Curry, Clean etc. But then I started to do preliminary studies. Since I was busy with other things it would be about 2 months before I could start to seriously study it. In the mean time I was going to set up the programming environments in my spare time. The first thing that happened was a comment made in the Caml mailing list. The comment basically said that I was making a mistake starting with Caml because it was so "special" that I would never go onto the next language. I found this to be a terribly worrying comment. Especially since it came from one of the OCaml developers. Often times when you see proponents say things like this, you soon discover the emperor has no clothes. Such statements are often made by people who lack diversity of experience in other programming languages. This causes a certain sort of tunnel vision in the way they perceive things. Tools like debuggers are overestimated in their capabilities. Languages features are touted way beyond their benefit. For about six weeks before I chose OCaml as my language I had decided to use another language. This language had a Lisp like syntax and a relatively good IDE. But it also had two major problems. It's debugger sucked and it's editor sucked ( while at the same time it did not use text files, so that you almost had to use their debugger ). The people who use this language believe that all functions and methods should be small, mostly smaller than 10-20 lines. Their environment was designed almost to force you to stick to routines of that size. [ One of the things I wanted to do was implement algorithms for doing things like calculating Vornoi diagrams. It may be possible to reduce such algorithms to ten line routines, but my experience is that at least in the begining such algorithms need large routine. Perhaps once it is working, you can reduce it to small routines, but you still need the capabilities to create large functions. ] The syntax was complicated (compared to Lisp) and matching the begining and ending of blocks ( and there were multiple ways of doing this ) was about four or five times as hard as it was in Lisp. The IDE editor had no syntax highlighting, ways to match or move around beginings/ends of block, no automated indenting.Yet it was virtually impossible to produce files to be used with a text editors. In the end I wrote a simple emacs mode and cut and pasted back and forth from the IDE and Emacs. It was possible to make something better for emacs, but it would take much more effort than I was ready to expend. The debugger could barely single step. [ In the most recent version, the debugger is improved and you can install breakpoints in the code. In the previous version, you had to install the breakpoint by putting a command in the code. ] After continuing or single stepping the debugger would reset itself. As one example of how it was inferior, often times I discover that a certain variable can point to where a bug is. It is supposed to be one value, but is another. I find a point in the code where it's value is correct, then I step through code untill I find a place where it's value changes through an incorrect one. I find this to be a powerful technique. In this debugger, I had to open up the window that displayed the variable each time I stepped, because the debugger reset itself. This made the technique much more cumbersome to use. A final example of shortcomings of this language. The proponents all claim that this language is as fast, and sometimes faster than C++. They base this on papers describing how features of the language are implemented in a way that works faster than the equivalent C++. Just one problem. It doesn't work. While programs in this language preform fairly well, they do run perceivably slower than C++. This leaves me wonder what other features they are wrong about. The point of this description is not to razz on a language. ( If I wanted to do that, I would tell you what language it was. ) The point is the oblivousness of what was going on in other languages hid from them the weaknesses of what they would claim was "the Worlds Greatest Language". Playing with emacs and ilisp would have shown them ways they could have favorably integrated access outside editors with the IDE. It would also have shown them the value of syntax highlighting, block beginning/ending awareness, automated indenting. Playing with the Visual C++ debugger would have shown them what a good debugger works like. Yet these were people who stuck to thier language because it was the greatest. So when I hear developers saying that their language is the best I imediately begin to wonder about it's deficiencies are. ( I will grant that it does not prove that the language is deficient, but at this time in my life, I want proof that something is worth my time before taking it up. ) 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: 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 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. These problems don't stop there though. The cameleon web page claims that it runs on both Unix and Windows. But I've had several major problems getting it to compile on Windows. The final one came when I finally got the compiler to run on a file, only to be told that there were some invalid parameters. Upon examination I discover that the parameters are library parameters for a C compiler, so now it looks like I will have to rewrite pretty much the whole build system for cameleon. Frankly I don't particularly like rewriting build systems for systems that I am not that familiar with. But worse. I have to build cameleon in order to get ocamldebug. 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. 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. 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? Am I going to discover that a prepackaged library doesn't work What ------------------- 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