> > > This looks pretty simple. What makes you think the program is a > > > compelling evidence of O'Caml superior productivity? > > 197 lines of code, including whitespace and commments. I > > think it is a pretty clear example of how you can write cool > > software in O'Caml in a very short time. If you had not been > > "lazy", as you said, and had tried implementing the same > > language in C++, I strongly doubt you could have written a > > more compact source. > 109 LOC in C++ counting blank lines and lines containing a single > '}'. See atttached files. > A few notes about the differences between your O'Caml program and > my C++ > program: > 1) I'm not using Yacc or Lex for parsing, because I'm not familiar > with these > tools, so ugly parsing takes up most of those 109 LOC (Parsing > things is > peripheral to my professional interests right now. I don't write > compilers) I think that the difference of parsing code illustrates the difference between imperative and functional programming: C++ code has no clear structure and it's parts do not have simple meanings. In O'Caml code, the parser is combined from smaller parts and every parser has a simple meaning. Same kind of code could be written in C++ too, but C++ doesn't support functional style good enough to make this normal. > 2) I decided not to implement the "simple" keyword, because I did > not understand what it was supposed to mean (a depth limit on > deduction, I'm guessing, but what for?) I think you misunderstood the specification of the language. (It was not very clear). The meaning of "a and b" should not be "a is reachable and b is reachable" (additive and), but "a and b are true at the same time" (multiplicative and). Of course I could be mistaken too, but the multiplicative case is more interesting. > 4) The algorithms are different I think, resulting in, for example, > about 200x speed improvement for the attached test.input file on my > P3-800MHz (g++-3.0 vs ocamlopt) (The output is identical). The O'Caml > program convergence seems to be quite unstable. Sometimes it is as > fast or even faster than the C++ program. The examples are too simple to show the difference. I have made a new example that can detect the difference, and also has a big enough search space. > I can see how the same algorithm can be implemented in ~100 LOC of > O'Caml too. However, IMO as this and the previous examples show, reports > about extreme LOC ratios are premature. The previous example shows that converting simple pattern matching to C++ makes it twice as long, unreadable, and still doesn't implement all the functionality. Anyway, problems in memory management and modularity only appear when the programs become big. Usually big programs are not written in two languages, so comparison is hard. But the example of Horus vs. Ensemble shows that there is very large improvement. Ensemble and other big O'Caml programs could probably be converted to C without making them much bigger, but they would become unreadable and unmaintainable. Here is a question: in C you can hack in all the object oriented features, so why are you using C++? Many claim that OOP in C is better than in C++, so what would you say to these people? Perhaps we could then tell you why you should use O'Caml. All I can say now is that O'Caml has been a massive productivity improvement for me.