[Caml-list] Is Caml a fraud ( especially on Windows )?

[Caml-list] Is Caml a fraud ( especially on Windows )?

[Thaddeus L. Olczyk]

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

Re: [Caml-list] Is Caml a fraud ( especially on Windows )?

[Remi VANICAT]

olczyk@interaccess.com (Thaddeus L. Olczyk) writes:

> When I chose to learn OCaml as my "language of the year" it seemed
> like a good choice.
>

[...]

> 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. 

absolutely not. Ocamlc transform program into a bytecode language, and
then use c mainly for foreign interface (that is interface with
library written in C (or other language), and as the system library
are written in C, you may need it...).

By the way, ocaml have two compiler, ocamlc which generate bytecode,
and ocamlopt which generate native optimized code. If you want to go
to a speed near to C, you need ocamlopt...

> 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.

well, As i already say, you are completely wrong one the assumption
that ocaml generate intermediate C code. Then on the www.ocaml.org,
you could see that ocaml (in fact ocamlopt) is second on speed on Doug
Bagley's computer language shootout (between C and C++). I haven't
found the link saying that ocaml is quicker 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.

well ocamldebug is part of ocaml, and have nothing to do with gdb, as
it is use to debug bytecode and not native code.

by the way, you may find in the documentation that :
Windows:
  The debugger is available under the Cygwin port of Objective Caml,
  but not under the native Win32 port.

So, it seem logical you don't have it, as you seem to use the native
Win32 port.


>
> 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.

if you had look better to the camleon doc, you would have seen that it
said to work with the cygwin port of ocaml. Cl.exe is not use by the
cygwin port of ocaml (cygwin use gcc), so You have a problem
here... (may be you could make it work with the native ocaml port, but
it is not advertised).

[...]

> So now I have to wonder what other lies there are about caml.

well, lies, lies... You haven't read the documentation, you have made
false assumption, so please, continue to try to learn ocaml 

[...]


> And how can I trust caml people to tell me the truth, when they've
> lied to now?

by reading what is written, and not what you believe is written.
-- 
Rémi Vanicat
vanicat@labri.u-bordeaux.fr
http://dept-info.labri.u-bordeaux.fr/~vanicat
-------------------
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

Re: [Caml-list] Is Caml a fraud ( especially on Windows )?

[Thaddeus L. Olczyk]

On Fri, 18 Oct 2002 12:25:31 +0200, Remi VANICAT
<vanicat@labri.u-bordeaux.fr> wrote:

>olczyk@interaccess.com (Thaddeus L. Olczyk) writes:
>
Redundancies with another reply answered in replies to other reply.
( Confused yet?)
>>
>> 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.
>
>if you had look better to the camleon doc, you would have seen that it
>said to work with the cygwin port of ocaml. Cl.exe is not use by the
>cygwin port of ocaml (cygwin use gcc), so You have a problem
>here... (may be you could make it work with the native ocaml port, but
>it is not advertised).
>
I looked at the FAQ on the web page.
There it clearly says that it runs on anything that runs lablgtk. Is
there some reason why lablgtk does not work from the native port?

-------------------
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

[Caml-list] ocamlopt / ocaml -custom and C compiler

[Dmitry Bely]

Remi VANICAT <vanicat@labri.u-bordeaux.fr> writes:

> well, As i already say, you are completely wrong one the assumption
> that ocaml generate intermediate C code.

BTW, why Ocaml developers decided that ocamlopt should generate camlprim?.c
in C, but not directly in Assembler? This is especially inconvenient for
Windows users where C compiler is not the part of OS distribution and
should be bought separately...

- Dmitry Bely


-------------------
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

Re: [Caml-list] ocamlopt / ocaml -custom and C compiler

[Xavier Leroy]

> BTW, why Ocaml developers decided that ocamlopt should generate
> camlprim?.c in C, but not directly in Assembler?

Unless I'm mistaken, ocamlopt doesn't generate a camlprim.c file;
ocamlc -custom does.  The reason for going through C in this case is
that ocamlc has no knowledge of the assembly language for the
processor: ocamlc is designed to work for any system that provides an
ANSI C compiler.

> This is especially inconvenient for
> Windows users where C compiler is not the part of OS distribution and
> should be bought separately...

We have addressed this issue in at least two different ways.  One is
the dynamic loading of C/Caml stub code, as implemented since release
3.04.  Now is the time for external C libraries to use this mechanism,
especially if they are to run under Windows.  The second answer to
this problem is the Mingw port.  Don't complain about lack of options :-)

- Xavier Leroy
-------------------
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

Re: [Caml-list] ocamlopt / ocaml -custom and C compiler

[Dmitry Bely]

Xavier Leroy <xavier.leroy@inria.fr> writes:

>> BTW, why Ocaml developers decided that ocamlopt should generate
>> camlprim?.c in C, but not directly in Assembler?
>
> Unless I'm mistaken, ocamlopt doesn't generate a camlprim.c file;
> ocamlc -custom does.  The reason for going through C in this case is
> that ocamlc has no knowledge of the assembly language for the
> processor: ocamlc is designed to work for any system that provides an
> ANSI C compiler.

Sorry, my mistake. But ocamlopt uses C compiler for linking. Why not to use
the link utility itself (say, link.exe for MSVC build)?

>> This is especially inconvenient for
>> Windows users where C compiler is not the part of OS distribution and
>> should be bought separately...
>
> We have addressed this issue in at least two different ways.  One is
> the dynamic loading of C/Caml stub code, as implemented since release
> 3.04.  Now is the time for external C libraries to use this mechanism,
> especially if they are to run under Windows.  The second answer to
> this problem is the Mingw port.  Don't complain about lack of options :-)

I am aware of MinGW port :-), but thank you for the detailed explanation.

- Dmitry Bely


-------------------
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

Re: [Caml-list] Is Caml a fraud ( especially on Windows )?

[Sven Luther]

On Fri, Oct 18, 2002 at 09:35:34AM +0000, Thaddeus L. Olczyk wrote:
> 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:

I don't understand what you are talking about, ocamlc generates
bytecode which gets interpreted in a virtual machine, not c, or
something such, and ocamlopt generates native code, that is assembly
which needs to be assembled by an assembler (gasm on linux/unix, and a
windows assembler on windows). The bytecode you compile on unix should
run without problem on the windows virtual machine (ocamlrun), provided
you don't use the -custom flag to ocamlc.

Maybe you should try using only ocamlopt.

That said, there are a few library which are only bindings to C code
(the FFI you spoke about previously) and which need a C compiler. But
once they are compiled, you can use them without problems.

> 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.

Well, since ocaml doesn't generate C that is compiled, maybe you should
revise your conclusion. Well, there was a caml->C compiler available
some time ago, but it is _not_ the same thing as ocaml.

> 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.

Check again your facts, the ocaml reference manual clearly says that :

This chapter (16) describes the Objective Caml source-level replay debugger
ocamldebug.

  Unix:
    The debugger is available on Unix systems that provides BSD sockets.
  Windows:
    The debugger is available under the Cygwin port of Objective Caml, but
    not under the native Win32 port.   

So, you would like to install the cygwin port, and you get access to the
debugger.

> The third incident was trying to get cameleon to compile on Windows.

Well, you should not judge the performance of ocaml on windows, by the
behavior of a rather recent library/app like cameleon, which had also
problems on unix/linux.

> And how can I trust caml people to tell me the truth, when they've
> lied to now?

Did they really lie ? I don't think so, 

> Am I going to discover that a prepackaged library doesn't work

And here is your error, these are _not_ prepackaged libraries.

But then, i am the debian maintainer for ocaml, and may have to big
opinions about what a packaging system is, and there is nothing such on
windows, so you are screwed and need to rebuild things, which can be
difficult. But then, there are numerous reports of other people doing
it, so you should beable to do so also.

Friendly,

Sven Luther
-------------------
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

Re: [Caml-list] Is Caml a fraud ( especially on Windows )?

[Thaddeus L. Olczyk]

On Fri, 18 Oct 2002 12:56:17 +0200, Sven Luther
<luther@dpt-info.u-strasbg.fr> wrote:

>On Fri, Oct 18, 2002 at 09:35:34AM +0000, Thaddeus L. Olczyk wrote:
>> 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:
>
>I don't understand what you are talking about, ocamlc generates
>bytecode which gets interpreted in a virtual machine, not c, or
>something such, and ocamlopt generates native code, that is assembly
>which needs to be assembled by an assembler (gasm on linux/unix, and a
>windows assembler on windows). The bytecode you compile on unix should
>run without problem on the windows virtual machine (ocamlrun), provided
>you don't use the -custom flag to ocamlc.
>
But then why does it call cl.exe?

>Maybe you should try using only ocamlopt.
>
But then why does cameleon use ocamlc?
Obviously you want to use ocamlc when debugging,
but I would think there are Debug and Release versions in
the make. If so then why is Debug the default ( and why isn't it in
the documentation)?

>That said, there are a few library which are only bindings to C code
>(the FFI you spoke about previously) and which need a C compiler. But
>once they are compiled, you can use them without problems.
What do you need the compiler for?
To build the C library or to actually build the bindings?
This seems to be adding to my rants.
When I asked about FFI, I asked whether you need to recompile ocaml.
( Something you have to do with some languages--eg Python. I'm not big
fan of recompiling things. ) I was told no. I should have been told
something like "not the whole thing, but you do need to compile the
bindings". )

>
>> 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.
>
>Well, since ocaml doesn't generate C that is compiled, maybe you should
>revise your conclusion. Well, there was a caml->C compiler available
>some time ago, but it is _not_ the same thing as ocaml.
Yes.
>
>> 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.
>
>Check again your facts, the ocaml reference manual clearly says that :
>
>This chapter (16) describes the Objective Caml source-level replay debugger
>ocamldebug.
>
>  Unix:
>    The debugger is available on Unix systems that provides BSD sockets.
>  Windows:
>    The debugger is available under the Cygwin port of Objective Caml, but
>    not under the native Win32 port.   
>
>So, you would like to install the cygwin port, and you get access to the
>debugger.
>
Ok. But why. IIRC the cygwin stuff you have to compile yourself. (
Something I am loathe to do, especially since I see some people have
had problems. )  
I can see that the Win32 port is "crippled".  When I assumed that
the compile used a C compiler, it made sense--cygwin creates code
that is significantly slower. But if ocamlopt generates native code
then the speed of the executables produced should be the same speed in
both ports. So then why distribute the Win32 port as the main port?

>> Am I going to discover that a prepackaged library doesn't work
>
>And here is your error, these are _not_ prepackaged libraries.
>
No but about nine months ago I tried ocaml very briefly. I had
a set of programs I had to write which basically encapsulated
database with little processing. It seemed like the perfect
opportunity to try out a new language because it involved little
actual coding. At the time the dbm library was unavaile ( on Linux ).

-------------------
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

Re: [Caml-list] Is Caml a fraud ( especially on Windows )?

[Sven Luther]

On Fri, Oct 18, 2002 at 03:42:05PM +0000, Thaddeus L. Olczyk wrote:
> On Fri, 18 Oct 2002 12:56:17 +0200, Sven Luther
> <luther@dpt-info.u-strasbg.fr> wrote:
> 
> >On Fri, Oct 18, 2002 at 09:35:34AM +0000, Thaddeus L. Olczyk wrote:
> >> 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:
> >
> >I don't understand what you are talking about, ocamlc generates
> >bytecode which gets interpreted in a virtual machine, not c, or
> >something such, and ocamlopt generates native code, that is assembly
> >which needs to be assembled by an assembler (gasm on linux/unix, and a
> >windows assembler on windows). The bytecode you compile on unix should
> >run without problem on the windows virtual machine (ocamlrun), provided
> >you don't use the -custom flag to ocamlc.
> >
> But then why does it call cl.exe?

As was explained in another mail, it is used to build C files. When you
interface with a C library, you first have to write something called a
stub library, which is a kind of smallish C code which wraps the C
library calls to interact correctly with ocaml.
D> 
> >Maybe you should try using only ocamlopt.
> >
> But then why does cameleon use ocamlc?
> Obviously you want to use ocamlc when debugging,
> but I would think there are Debug and Release versions in
> the make. If so then why is Debug the default ( and why isn't it in
> the documentation)?

Well, the debugger only works on bytecode.

But if you would use a normal build system, you would just have to
change a variable or something such to rebuild the same source to
bytecode or nativecode. I use two different makefile targets to do so.
so you can run the bytecode version, it works well most of the time, and
if you really need the extra performance, you can rebuild with ocamlopt.

> >That said, there are a few library which are only bindings to C code
> >(the FFI you spoke about previously) and which need a C compiler. But
> >once they are compiled, you can use them without problems.
> What do you need the compiler for?
> To build the C library or to actually build the bindings?

Explained above, and please read the chapter of the ocaml doc about C
binding, and you will understand this.

> This seems to be adding to my rants.

Please, make informed rants, you were told two times already to read the
docs before ranting, why do you not do it ?

> When I asked about FFI, I asked whether you need to recompile ocaml.
> ( Something you have to do with some languages--eg Python. I'm not big
> fan of recompiling things. ) I was told no. I should have been told
> something like "not the whole thing, but you do need to compile the
> bindings". )

This is stupid.

The ocaml suite is composed of the two compilers and the toplevel plus
assorted tools. In addition there is the pervasive library (builtin) and
the standard library. All of this is built with ocaml, and don't need
any kind of C, except for the bootstraping phase (well you need an ocaml
compiler to compile ocaml).

Additionally there is a serie of libraries included in the ocaml suite
(otherlibs) where some may need C for performance or compatibility or
what have you.

If you want to add support for another C library, like gtk+ for example,
you need to write the stubs, which are C function wrapping the C
library, and then have the ocaml library making calls to this stups. 

This is all done externally, no need to rebuild the ocaml compiler to do
it.

> >Check again your facts, the ocaml reference manual clearly says that :
> >
> >This chapter (16) describes the Objective Caml source-level replay debugger
> >ocamldebug.
> >
> >  Unix:
> >    The debugger is available on Unix systems that provides BSD sockets.
> >  Windows:
> >    The debugger is available under the Cygwin port of Objective Caml, but
> >    not under the native Win32 port.   
> >
> >So, you would like to install the cygwin port, and you get access to the
> >debugger.
> >
> Ok. But why. IIRC the cygwin stuff you have to compile yourself. (
> Something I am loathe to do, especially since I see some people have
> had problems. )  

Yes, i think INRIA could make a cygwin binary distribution available for
download.

> I can see that the Win32 port is "crippled".  When I assumed that

Because windows is an inferior plateform which does not provide all the
stuff needed to easily port all of the unix libraries and
functionalities, not to speak about the assembler. So it is much easier
to use cygwin.

> the compile used a C compiler, it made sense--cygwin creates code
> that is significantly slower. But if ocamlopt generates native code
> then the speed of the executables produced should be the same speed in
> both ports. So then why distribute the Win32 port as the main port?

Because people like to use MSVC++ as their IDE, because the cygwin port
is more recent than the native port.

> >> Am I going to discover that a prepackaged library doesn't work
> >
> >And here is your error, these are _not_ prepackaged libraries.
> >
> No but about nine months ago I tried ocaml very briefly. I had
> a set of programs I had to write which basically encapsulated
> database with little processing. It seemed like the perfect
> opportunity to try out a new language because it involved little
> actual coding. At the time the dbm library was unavaile ( on Linux ).

Well, that is totally wrong.

I have been building debian ocaml packages since 1997, and gdbm has been
available since then, the first dated changelog entry of the libgdbm1
debian packages even goes back to version 1.7.3-11.1 on Fri, 13 Dec 1996.
Earlier dates are lost because the changelog entries were not dated
previous to this one.

Anyway, what linux distribution are you using, and are you sure you set
it up correctly ? I would strongly suggest you install debian, and try :

apt-get install ocaml liblablgtk-ocaml-dev cameleon

(you have to track unstable though for cameleon, since it was just
packaged) 
And you will have a working setup and no need to bother everyone by
petty complaints.

Friendly,

Sven Luther
-------------------
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

Re: [Caml-list] Is Caml a fraud ( especially on Windows )?

[Alessandro Baretta]

Thaddeus L. Olczyk wrote:
> On Fri, 18 Oct 2002 12:56:17 +0200, Sven Luther
> <luther@dpt-info.u-strasbg.fr> wrote:
> 
>>
> 
> But then why does it call cl.exe?

To support linking with C libraries.

>>Maybe you should try using only ocamlopt.
>>
> 
> But then why does cameleon use ocamlc?
> Obviously you want to use ocamlc when debugging,
> but I would think there are Debug and Release versions in
> the make. If so then why is Debug the default ( and why isn't it in
> the documentation)?

This has nothing to do with debugging: ocamlc compiles to 
bytecode, which is fast and guarantees a very high degree of 
portability; ocamlopt produces native code. This requires an 
assembler and a linker from a C compiler. The linker is 
platform-specific and makes native executables not portable, 
although the code can be recompiled with absolutely no 
differences on all supported platforms.

>>That said, there are a few library which are only bindings to C code
>>(the FFI you spoke about previously) and which need a C compiler. But
>>once they are compiled, you can use them without problems.
> 
> What do you need the compiler for?
> To build the C library or to actually build the bindings?
> This seems to be adding to my rants.

In order to link to C code you must first write special C 
functions called "stubs" (Java might be a good choice as 
your next language, so that you may discover that such 
functions exist elsewhere, too). Stubs are necessary to pass 
data back and forth from caml functions in a way compatible 
with the caml runtime, debugger and calling conventions.

> Ok. But why. IIRC the cygwin stuff you have to compile yourself. (
> Something I am loathe to do, especially since I see some people have
> had problems. )

Very well. If you are unable to use Cygwin get yourself a 
Debian distro and you won't have to compile anything at all. 
Sven is the one who does the job for you.

> I can see that the Win32 port is "crippled".  When I assumed that
> the compile used a C compiler, it made sense--cygwin creates code
> that is significantly slower. But if ocamlopt generates native code
> then the speed of the executables produced should be the same speed in
> both ports. So then why distribute the Win32 port as the main port?

Don't blame the Caml team if Windows is crippled OS. Cygwin 
uses gcc to generate code. So Cygwin code is neither faster 
nor slower than equivalent gcc code under Linux. However, 
Cygwin code is linked with a POSIX emulation library which 
runs on top of the standard Win32 C library and kernel. This 
  is less efficient than linking directly with a POSIX 
conformat c library like glibc.

>>>Am I going to discover that a prepackaged library doesn't work
>>
>>And here is your error, these are _not_ prepackaged libraries.
>>
> 
> No but about nine months ago I tried ocaml very briefly. I had
> a set of programs I had to write which basically encapsulated
> database with little processing. It seemed like the perfect
> opportunity to try out a new language because it involved little
> actual coding. At the time the dbm library was unavaile ( on Linux ).

You want the a library? Then, please, go on and write the 
stubs for it. Everybody will be thankful to you. You wanna 
rant about it. Then go on ranting till you please, but it's 
not going to serve much, either to you or to anybody else.

Alex

-------------------
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

Re: [Caml-list] Is Caml a fraud ( especially on Windows )?

[Maxence Guesdon]

Hi,
 
> 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.

I created the cameleon-list because, suddenly, there seemed to be various users having problems compiling cameleon, and the caml-list is NOT the place to discuss about it. The cameleon-list is the good place to post such messages, as you won't bother caml-list subscribers not interested in cameleon.
You may think it's stupid, it's your opinion. But I think that people on this list will agree with me. 
BTW, sending error reports just saying "it fails" IS stupid : I had to ask you for the error messages...

> 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.

AS replied by Remi, I don't claim Cameleon works on Windows, but should work on Cygwin under Windows, which is different.

As you may have read on the cameleon-list, if someone wants to port the building system of Cameleon to Windows, i'll be happy to add it to the cameleon distrib. I can't do everything. Please don't blame people for not doing something YOU need.

> 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.

I know I should not say that but here it comes : What about spending some time reading docs ?


-- 
Maxence Guesdon
-------------------
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

[Caml-list] Re: "ocaml_beginners"::[] Is Caml a fraud ( especially on Windows )?

[Joaquin Cuenca Abela]

--- olczyk@interaccess.com wrote:
>
> So when I hear developers saying that their language
> is the best I
> imediately begin to wonder about it's deficiencies
> are.

You will have a hard time looking for a language
developer that don't states that its language is the
best one.

Stroustup prefers C++ to any other language for most
tasks, Ritchie said that if he was only allowed to
keep one language on a desert island, it will be C,
etc.

It's not a shock to me to discover that Caml creators
prefer Caml over other languages...

> 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.

? From what I know, ocamlc only calls cl.exe to
compile C code.  That's, if you do:

ocamlc test.c

and test.c is a C program, then it will compile it
using (surprise) a C compiler.  That's all.  It
compiles itself Caml code.

> 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. )

performance tests are almost always crap.  Specially
language related ones.  To me the only important thing
is that Caml creates programs that run at an
acceptable speed, that's all.
 
> 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

Dude, you seem to have done a false assumption, and
then you're building a big chain of false deductions
(and at the same time, you're insulting Caml
developers).

The debugger is not a wrapper of gdb.  And it's one of
the best debuggers that I've had the pleasure to use.
Some months ago I was doing a little project for the
university.

I first did it in perl, and then I tried to do it in
Caml (I wanted to learn a bit of Caml).  The final
Caml version was half in size than the perl version,
and the debugger has a hell of help when I need it. 
Specially the possibility to *go back* in the program
flow was a life-safer (why this feature does not
appears in big bold letters in the main ocaml page?).

I'm not member of a Caml fan club or something, but
when I'm learning a new language (and I try to do that
as regularly as possible), I always keep in mind two
things:

1) I'm a newbie.  If something is going bad, it's
probably my fault.
2) Don't insult people that try to help.

You're welcome to dislike Caml, but don't flame
others' work in the process.

Cheers,


=====
Joaquin Cuenca Abela
e98cuenc@yahoo.com

__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
-------------------
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

[Caml-list] Re: "ocaml_beginners"::[] Is Caml a fraud ( especially on Windows )?

[Thaddeus L. Olczyk]

On Fri, 18 Oct 2002 04:44:55 -0700 (PDT), Joaquin Cuenca Abela
<e98cuenc@yahoo.com> wrote:

>
>--- olczyk@interaccess.com wrote:
>>
>> So when I hear developers saying that their language
>> is the best I
>> imediately begin to wonder about it's deficiencies
>> are.
>
>You will have a hard time looking for a language
>developer that don't states that its language is the
>best one.
>
>Stroustup prefers C++ to any other language for most
>tasks, Ritchie said that if he was only allowed to
>keep one language on a desert island, it will be C,
>etc.
>
And Pierre  Weis says that I shouldn't call people liars, but when
I see a post like this...

There is a big difference between saying " if I could only use one
language it would be C", and saying "C is the best language".

Stroustrup has said  and continues to say that he refuses to get
into the debate about what the best language is. Last I looked it
was the stated on the FAQ on his web page. 
>
>? From what I know, ocamlc only calls cl.exe to
>compile C code.  That's, if you do:
>
>ocamlc test.c
>
>and test.c is a C program, then it will compile it
>using (surprise) a C compiler.  That's all.  It
>compiles itself Caml code.
>
Uhmmm. If you look at the line of the build that I have posted,
there are no C or C++ source files in the compile that uses
cl.exe.

>performance tests are almost always crap.  Specially
>language related ones.  To me the only important thing
>is that Caml creates programs that run at an
>acceptable speed, that's all.
> 
Indeed. As I pointed out the guy who did the test is
not exactly the person I would want to write efficient C code.
Which is usually why such preformance tests comparing
two languages suck. The person is either an expert in one
language and lacking in the other.


>
>Dude, you seem to have done a false assumption, and
>then you're building a big chain of false deductions
>(and at the same time, you're insulting Caml
>developers).
>
>The debugger is not a wrapper of gdb.  And it's one of
>the best debuggers that I've had the pleasure to use.
>Some months ago I was doing a little project for the
>university.
>
>I first did it in perl, and then I tried to do it in
>Caml (I wanted to learn a bit of Caml).  The final
>Caml version was half in size than the perl version,
>and the debugger has a hell of help when I need it. 
>Specially the possibility to *go back* in the program
>flow was a life-safer (why this feature does not
>appears in big bold letters in the main ocaml page?).
>
Actually this is the perfect example of the kind of tunnel
vision that those clueless exhibit. (With the caveat that I have
not yet used the debugger, so go by what I read, and not the actual
feel) CL/Scheme and Smalltalk both have debuggers with this 
feature ( I also suspect that Dylan has it too ) and they have had
it for a *long. long time* , predating OCaml ( almost predating ML
as an implemented language).

In fact both languages have another feature which AFAIK OCaml does
not. They both support core/images, which allow you to checkpoint 
a run and restart "close to the bug" even when you've pushed the go
back feature to much.

>I'm not member of a Caml fan club or something, but
>when I'm learning a new language (and I try to do that
>as regularly as possible), I always keep in mind two
>things:
>
>1) I'm a newbie.  If something is going bad, it's
>probably my fault.
>2) Don't insult people that try to help.
>
I don't read the C/C++ Users Journal much any more. But I still
get it and read the editorials.
Today the next one arrived with this comment:
"If you're like me, you tire easily of hype machines that cry wolf
about this or that whiz-bang tool."
-------------------
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

Re: [Caml-list] Re: "ocaml_beginners"::[] Is Caml a fraud ( especially on Windows )?

[Oleg]

On Friday 18 October 2002 03:03 pm, Thaddeus L. Olczyk wrote:
> >Stroustup prefers C++ to any other language for most
> >tasks, Ritchie said that if he was only allowed to
> >keep one language on a desert island, it will be C,
> >etc.
>
> And Pierre  Weis says that I shouldn't call people liars, but when
> I see a post like this...
>
> There is a big difference between saying " if I could only use one
> language it would be C", and saying "C is the best language".
>
> Stroustrup has said  and continues to say that he refuses to get
> into the debate about what the best language is. Last I looked it
> was the stated on the FAQ on his web page.

The fact that he "refuses to get into the debate" does not mean he has no 
clear language preferences.  Common sense suggests that he uses C++ for at 
least 51% of his programming. 

BTW, good luck with your quest to find your favorite language. It would be 
nice though if you didn't cross-post discussions started on one list to 
another, no matter how all-important your replies may seem to you.

Oleg
-------------------
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

Re: [Caml-list] Re: "ocaml_beginners"::[] Is Caml a fraud ( especially on Windows )?

[Thaddeus L. Olczyk]

On Fri, 18 Oct 2002 20:08:15 -0400, Oleg <oleg_inconnu@myrealbox.com>
wrote:

>On Friday 18 October 2002 03:03 pm, Thaddeus L. Olczyk wrote:
>> >Stroustup prefers C++ to any other language for most
>> >tasks, Ritchie said that if he was only allowed to
>> >keep one language on a desert island, it will be C,
>> >etc.
>>
>> And Pierre  Weis says that I shouldn't call people liars, but when
>> I see a post like this...
>>
>> There is a big difference between saying " if I could only use one
>> language it would be C", and saying "C is the best language".
>>
>> Stroustrup has said  and continues to say that he refuses to get
>> into the debate about what the best language is. Last I looked it
>> was the stated on the FAQ on his web page.
>
>The fact that he "refuses to get into the debate" does not mean he has no 
>clear language preferences.  Common sense suggests that he uses C++ for at 
>least 51% of his programming. 
>
Well of course. After all he probably knows it better then any other
language ;) , and we all tend to lean towards the language we know the
best.

That's not what the claim was though. The original claim by me was
that when I hear people ( especially people close to the progress of
the language ) go around saying things like "X is the greatest
language of all time" or  "once you learn X you will never want to
program in anything else" then I start wondering if  "the Emperor
has no clothes". 

The reply was that all major actors in a language act as rabid
proponents of the language. They use the examples of Ritchie and
Stroustrup. I don't know whether or not it's true of Ritchie.  But I
know that Stroustrup does not follow that example.
that language

>BTW, good luck with your quest to find your favorite language.
It's not about finding a "favorite language". Its about learning 
a new language each year. Part of that entails spending time
working with the language. It also entails avoiding getting bogged 
down in installing things.

> It would be 
>nice though if you didn't cross-post discussions started on one list to 
>another, no matter how all-important your replies may seem to you.
I already decided not to. If all the posts ( assuming people don't
change the topic ) stayed within one thread, it would be OK. What
I failed to take into account is that the mailing lists append the
name. So things tend to get out of threads. My mistake. Sorry.
-------------------
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

Re: [Caml-list] Is Caml a fraud ( especially on Windows )?

[Pierre Weis]

Hi,

[...]
> 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.

I suppose I am responsible of ``the first thing that happened'' since
you are refering to my answer to your message announcing urbi et orbi
that Objective Caml would be your «language of the year».

So, let me first recall here what was my message:

     I must warn you that Caml is a bit special: it is known as extremely
     addictive. Many people that learnt it seriously, just don't want to
     give it up and go back to real programming with *p++ or
     null pointers ...

     You have to consider that before trying Caml: it could very well be
     your last attempt to learn a new language.

     A better (and more cautious) approach would be to try all other
     languages first (it ensures that the process will long for years) and
     at the end, last but not least, try Caml :)

     All the best for trying to learn Caml!

I thaught it was clear that this was a kind of joke (given the
expressiosn "a bit special", "extremely addictive", "your last
attempt", "it ensures that the process will long for years") and a
sort of warm encouragement to keep on learning Caml, as testified by
the smiley and the last phrase.

However, even if you have no sense of humor at all (which is perfectly
admissible), this message, even read with no ``grano salis'' at all,
was in no mean telling you that you were making a mistake by starting with
Caml.

I would have been glad if you had understood: ``cool, he says I will
spare years by choosing at once the right language to learn'', and if
you had answered in the same humoristic manner.

Furthermore, there is no lie in this message, it just told you the
truth: the phrase

   "Many people that learnt it seriously, just don't want to
    give it up and go back to real programming with *p++ or null
    pointers ..."

is just a fact that we routinely observe.

O please, read the phrase carefully: it says ``people ... dont' WANT
to give it up''; in practice, even if they don't want to, Caml
programmers often have to go back to X++ or Y#, just to earn their
living...

> 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. 

I suggest, you should not state such fact without justification: I
mean, you don't even know the emperor, nor where he lives or what he
looks like.

Second, if I am one of the ``people who lack diversity of experience
in other programming languages'' that you mentioned, I'm just
wandering if you know some facts about me, that could let you say so ?

To my own knowledge, I have a pretty good experience on other
programming languages, having written programs in a large number of
them and having studied for years their syntax, static and dynamic
semantics. I also have taught a lot of them to hordes of students.

> 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. 

I think you may have overlooked the capabilities of our debugger and
you may just ignore our language features, their orthogonality and
strength.

Also: don't forget that we have nothing to sell. Everything is free
here. The implementors team is made of programmers that are top-class
computer scientists. They never lie! In the first place for ethical
reasons, but I agree that you may not buy this esoteric reason. So,
may be more convincing to you, they do not lie just because lying is
highly counterproductive for them: they will instantaneously loose
their credibility in the scientific communauty (that also carefully
reads this public mailing list). Credibility is of tremendous
importance for computer scientists since it is so incredibly difficult
to obtain.

So please, refrain from saying that we are lying: this is insulting
and just plain wrong.

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


-------------------
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

Re: [Caml-list] Is Caml a fraud ( especially on Windows )?

[AC]

> Also: don't forget that we have nothing to sell. Everything is free
> here. The implementors team is made of programmers that are top-class
> computer scientists. They never lie! In the first place for ethical

But you computer scientists are way too gullible.
Cant you smell a troll when you see one ?
Olczyk deserves Naggum.
-------------------
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

Re: [Caml-list] Is Caml a fraud ( especially on Windows )?

[Thaddeus L. Olczyk]

On Fri, 18 Oct 2002 15:23:47 +0200 (MET DST), Pierre Weis
<pierre.weis@inria.fr> wrote:

>I thaught it was clear that this was a kind of joke (given the
>expressiosn "a bit special", "extremely addictive", "your last
>attempt", "it ensures that the process will long for years") and a
>sort of warm encouragement to keep on learning Caml, as testified by
>the smiley and the last phrase.
>
And yet most people who make jokes like these are just hiding their
arrogance behind humor.

>
>I would have been glad if you had understood: ``cool, he says I will
>spare years by choosing at once the right language to learn'', and if
>you had answered in the same humoristic manner.
>
Which is exactly the problem. Are you seriously saying that by
learning Caml, you have learned everything there is to learn
about programming? Maybe just the important stuff. ( It's clearly
obvious that you don't know what the idea behind "language of the
year" is. ) So are Monads and Arrows and ( what does Clean use for
output? ) are not worth learning? Goo's object model is insignificant?
BTW what kind of MOP does Caml use? What support does
it have for AOP?

>Furthermore, there is no lie in this message, it just told you the
>truth: the phrase
>
>   "Many people that learnt it seriously, just don't want to
>    give it up and go back to real programming with *p++ or null
>    pointers ..."
>
Or writing "advice"? This response alone shows the kind of tunnel
vision I mentioned.

BTW the people who I've met who hate *p++ and null pointers are
people who do use VB and *think* they are programmers. They then
go on to C++ and create huge messes by missusing *p++ and null
pointers. They then blame thed language instead of admitting their own
incompetence.
>
>> 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. 
>
>I suggest, you should not state such fact without justification: I
>mean, you don't even know the emperor, nor where he lives or what he
>looks like.
>
Maybe, maybe not. But when I see the emporer naked, I know he's naked.

>Second, if I am one of the ``people who lack diversity of experience
>in other programming languages'' that you mentioned, I'm just
>wandering if you know some facts about me, that could let you say so ?
>
>To my own knowledge, I have a pretty good experience on other
>programming languages, having written programs in a large number of
>them and having studied for years their syntax, static and dynamic
>semantics. I also have taught a lot of them to hordes of students.
>
Those who know do. Those who don't teach.
There is a big difference between "knowing" a language
snd having written code in it. Especially real world applications.

>> 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. 
>
>I think you may have overlooked the capabilities of our debugger and
>you may just ignore our language features, their orthogonality and
>strength.
Perhaps like Joaquin Cuenca Abela you are not familiar with the power
of debuggers in other languages.

As for language features, well that's the point of learning a
language. For now  I have to go by what others say. And from what you
say I feel that I have to take the "power of OCaml" with a grain of
salt.
-------------------
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

Re: [Caml-list] Is Caml a fraud ( especially on Windows )?

[Pierre Weis]

[...]
> And yet most people who make jokes like these are just hiding their
> arrogance behind humor.

OK. I am not most people then.

[...]
> Which is exactly the problem. Are you seriously saying that by
> learning Caml, you have learned everything there is to learn
> about programming?

Are you serious at pretending I sais so ?

 Maybe just the important stuff. ( It's clearly
> obvious that you don't know what the idea behind "language of the
> year" is. ) So are Monads and Arrows and ( what does Clean use for
> output? ) are not worth learning? Goo's object model is insignificant?
> BTW what kind of MOP does Caml use? What support does
> it have for AOP?

Monads can be useful but are in no ways superior to Caml's more
traditional constructs (I consider monads as a clever encoding of
language constructs denotational semantics). If you want, you can also
define monads in Caml, but ...

Arrows have the same drawbacks as Backus's FPs: the absence of
variables (variables in the Caml sense of immutable bindings, not in
the C or Ada sense of left values).

Caml is not CLOS; yes Goo is an immature language (not clearly better
than scheme); you gave me the word: AOP seems to me ``insignifiant''.

By the way, what do you know of Caml's object system, modules, fonctors,
lazy features, etc ? What do you know of caml theoretical fundations
and solid implementations choices ?

> >Furthermore, there is no lie in this message, it just told you the
> >truth: the phrase
> >
> >   "Many people that learnt it seriously, just don't want to
> >    give it up and go back to real programming with *p++ or null
> >    pointers ..."
> >
> Or writing "advice"? This response alone shows the kind of tunnel
> vision I mentioned.

This is not a response: I was just stating a fact! How a fact could be
a tunnel vision ?

> BTW the people who I've met who hate *p++ and null pointers are
> people who do use VB and *think* they are programmers. They then
> go on to C++ and create huge messes by missusing *p++ and null
> pointers. They then blame thed language instead of admitting their own
> incompetence.

You are very right: a lot of people ``blame the language instead of
admitting their own incompetence.''

[...]
> Maybe, maybe not. But when I see the emporer naked, I know he's naked.

I'm not sure you really saw the emperor!

[...]
> Those who know do. Those who don't teach.

There may be people that know, do, and teach. That's our way at INRIA,
believe me.

> There is a big difference between "knowing" a language
> snd having written code in it. Especially real world applications.

How many compilers have you ever written ?

[...]
> Perhaps like Joaquin Cuenca Abela you are not familiar with the power
> of debuggers in other languages.

Perhaps you don't know me and never spent days with me debugging lisp,
Pascal, C, or assembly code for various processors ...

If you ever come to write some Caml code and become familiar with the
language, you will certainly discover how powerful is the compiler
(and the toplevel interactive system) as a debugger. In fact, the
language itself helps you to debug your programs, since the constructs
imply automatic sanity checks that find bugs when they statically fail.

> As for language features, well that's the point of learning a
> language. For now  I have to go by what others say. And from what you
> say I feel that I have to take the "power of OCaml" with a grain of
> salt.

Feel free to feel as you like.

The power of Caml is not a feeling or a dream.

Give it a try, and you will see!

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


-------------------
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

Re: [Caml-list] Is Caml a fraud ( especially on Windows )?

[Alessandro Baretta]

Thaddeus L. Olczyk wrote:
> <a big big rant...>

In Italy we respond to such bullshit by asking, "Did you 
drink your brain?" What in the world makes you think caml 
generates C code? Did you ever notice Caml gets compiled to 
bytecode? Good lord, wake up! You can't wake up one fine 
morning and start ranting about what other people like in 
their own parlor!

You don't like Caml. You have no clue what caml is about. 
You don't give a damn about caml. Fine. Who cares?

Alex

-------------------
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

Re: [Caml-list] Is Caml a fraud ( especially on Windows )?

[Issac Trotts]

[ 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

Re: [Caml-list] Is Caml a fraud ( especially on Windows )?

[Damien Doligez]

On Friday, Oct 18, 2002, at 11:35 Europe/Paris, Thaddeus L. Olczyk 
wrote:

> So now I have to wonder what other lies there are about caml.

Yes, O'Caml is a fraud.  All the people who replied to you are in fact
bogus accounts created by me.  You should do yourself a favor and give
up on this joke language.  Try INTERCAL [1] instead.  And stop talking 
to
people who don't exist: unsubscribe from the mailing list.

References:
[1] <http://www.muppetlabs.com/~breadbox/intercal-man/home.html>

-- Damien

P.S. Everything in this mail is a lie.

-------------------
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

Re: [Caml-list] Is Caml a fraud ( especially on Windows )?

[Maxence Guesdon]

> >I created the cameleon-list because, suddenly, there seemed to be various users 
> >having problems compiling cameleon, and the caml-list is NOT the place to discuss about it. 
> No. The best place probably was/is the caml beginners list. But it
> seems that not many people bother with that list. When I didn't get
> a reply I posted here. AFAICS that's the same state with the cameleon
> list.

Can you imagine how the mailing lists (beginners' of caml-list) would be polluted if anybody having problems compiling a caml software posted to these lists ? What next ? You will ask Linux questions because you develop a software in OCaml under Linux ?
I tried to reply to you, and I posted a message on the cameleon-list to say I would not make a port to windows (though I would add such a port if someone makes it). But you did not make any effort. You're just waiting for people to work for you ? Well, if you give me root/admin access to your machine, I may help you .. ;-)

> Lie. I posted the steps I took to try to get the errors. I detail
> several different approaches I took to try and remedy the errors.
> I then posted the offending line in the build of the approach most 
> likely to suceed along with the error message.

Now you are the lier. I made you a suggestion to compile and you just replied to me : "It fails". Then I had to ask you for details...

Well, the point is that you should not try to develop software if you can't make some effort. The best you can do is to use Visual Basic, I think... Then Microsoft will be very happy too reply to your phone calls and e-mails, with your credit card number of course :-)

> >AS replied by Remi, I don't claim Cameleon works on Windows, 
> >but should work on Cygwin under Windows, which is different.
> >
> Actually in the FAQ you claim that it runs on anything that runs
> lablgtk ( along with some other condition that is trivially attained
> ).
> Are you saying that lablgtk doesn't work with the Win32 port?

I don't know. I don't even care, in fact. There's a lablgtk list, you know.

> Well as noticed above, I seem to be more familiar with some of the
> docs then you are. As for why I don't read the docs inside
> and out. That's because I prefer to read the language description. 

Now you're really bothering me, kid.

I send a copy of this message to the caml-list, because I don't want to hide anything about my decision about you : I'll kick you out of the cameleon-list.

Please, unsubscribe from the caml-list. 

-- 
Maxence Guesdon
-------------------
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