Re: [Caml-list] ocaml and large development projects

[Chris Hecker <checker@d6.com>]

>Except C++ has *exactly* the same problem.  Change a private member of a
>base class, and watch *everything* recompile.  I've seen this more often
>then I want to remember.  This is, of course, assuming you don't have an
>"everything.h" include file, which is quite common if you precompile
>headers.  At which point, change anything in a header and watch everything
>recompile.

It would be silly to turn this thread into a language war, but this 
statement is just false, in practice.  C++ sucks, for sure, and a naive 
programmer can easily make a mess.  But, there are well known and heavily 
used techniques to avoid these problems, and they work.  It's a waste of 
time to debate that.  You can (and most people who have a clue do) make it 
so that you have interfaces and implementation, and touching the latter 
doesn't require anything more than a recompile of that file and a relink.

It does not appear that this is even possible now with ocamlopt.  That is 
the problem I'm talking about.  In C++ you can give up some features and 
get highly encapsulated code with minimal build dependencies.  I don't 
think this is possible now with ocamlopt regardless of whether you're 
willing to give up features or not, given my understanding of the 
situation.  I would love to hear differently, or have someone from the caml 
team comment on this.

>Maybe.  C++ and Java are toy languages, then.

This statement plays well on a mailing list for an alternative language, 
but the reality is fairly different and most people writing large software 
in C++ would write you off as a loon if you said this to them.  There's an 
important difference between a sucky language and a toy language.

Still flabbergasted,
Chris

PS.  A related issue is going to come up with respect to disabling 
cross-file inlining when we get native DLLs.  You want to be able to 
control what gets made available for inlining when building a DLL, since 
one of the uses of DLLs is to be able to supply a new version of code and 
so you can't have it be already inlined in the client application.


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