Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Is Caml a fraud ( especially on Windows )?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: olczyk@i...
Subject: [Caml-list] Is Caml a fraud ( especially on Windows )?
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