]> > >Looking at Halo [1] credits, one can see that it was developed by about 10 > >programmers (there were also testers and artists involved). A single O'Caml > >programmer capable of developing such a game alone should certainly stand to > >make tons of money. Then why don't we see much software written in O'Caml? > > > >I'm not buying the argument that "O'Caml isn't used in the industry because > >investors and project managers are stupid". > > > Two major reasons. > > (1) licence uncertainty > (2) lack of programmers > As a new OCaml programmer let me describe the other barriers to entry: (3) programming style (4) development environment (5) grammar, semicolons, and other quirks (3) programming style This is related to (2). Leaving out classroom use, the majority of the target audience for a general purpose language consists of C/C++ programmers. (Some are recent CS graduates -- see below -- and maybe Microsoft Visual-whatever drones should be counted as a separate category.) At my last job we switched from C++ to Java. We had a few experienced Java programmers and an MIT professer with her new Java textbook. Two weeks were sufficient to learn the new language sufficiently well to start writing real code. Java is designed to look like C with classes and garbage collection. As a result, it is easy to find or create Java programmers. OCaml is not related to C. It doesn't look like C (see below) and it doesn't work like C. The object oriented features are harder to learn than those in C++. Moving from C to a functional language is not natural. Retraining software engineers will take longer and some will not be able to make the transition. Recent CS graduates may do better than established C programmers. They should have had recent experience with functional languages. (I hear many students have trouble with "lambda" in introductory CS courses. I assume those who graduate understand.) However, few students will come out of school knowing OCaml. This is a fundamental barrier and managers are right to be wary. I did use a non-mainstream language once in a commercial software product. I wrote the test suite for my program in Scheme. This was feasible because the group was very small and my boss liked Scheme. For the particular application it was a good choice. (4) development environment I wanted to compile the HTTP client tool from one of the ocaml web sites. Doing this required finding, compiling, and installing three or four other ocaml libraries plus a C library which I had to search elsewhere for. The core language -- the tarball from the OCaml web site -- is well packaged and seems reliable, but the surrounding chaos feels more like a hacker project than a solid development platform. A developer using C on a Unix system has more software in a standard installation. (Is it possible to do Java-style hierarchical naming or C++ namespaces in OCaml? One of these is probably essential in the long run.) (5) quirks If OCaml is to be taken seriously it needs a compiler with better error messages. I remember switching 15 years ago from pcc (the "Portable C Compiler" that came with BSD 4.2) to Metaware High C and gcc. pcc emitted a single unhelpful error message followed by a cascade of secondary messages. The newer compilers generated helpful error messages and had error recovery so any later messages were likely to be related to further code errors. My productivity substantially increased as I was able to understand what errors meant and fix more than one error per edit-compile cycle. ocamlc is like pcc, but without the cascading errors. A tool like "lint", that parses a file and looks for problems, might be adequate for this purpose. The ideal solution would be two independent language implementations. The use of semicolon as an optional statement separator rather than a mandatory statement terminator causes a lot of extra work for me. I understand the C rules about where a statement begins and ends. The OCaml rules are confusing and I often must resort to trial and error to resolve compilation errors. I want to know WHY the compiler thinks my exception handler expression should have type unit. It should tell me "the inferred type for the value expression of the try clause at line 120 (unit) does not match the inferred type for the value expression of the with clause at line 130 (string)". The lack of operator overloading makes the transition from C to OCaml harder. (I understand why type inference and overloading are difficult to reconcile, but the omission is still annoying.) Having said all that, my personal goal for this summer is to learn a new language and write a useful program in it. I chose OCaml and I will reserve judgement until I have completed that task, or failed. --John Carr (jfc@mit.edu) ------------------- 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