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

[Seth Kurtzberg <research@isec.us>]

On Monday, May 19, 2003, at 12:31 PM, Chris Hecker wrote:

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

What does an "everything.h" header file have to do with anything?  The 
compilers that support precompiled headers are smart enough to do with 
per header file granularity.  In addition, if one of my programmers 
organized header files based on the compiler's behavior W.R.T. 
precompiled headers, that programmer would soon halt any such behavior 
or start pounding the pavement.

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

This is true although I would argue that use of such techniques is 
unwise due because they impose a huge cost in errors that the compiler 
is unable to detect.  I agree with the general thrust of what Chris has 
been saying, and I don't think he is suggesting that such strategies 
are things that ocaml might emulate; I'm just stating for emphasis that 
this would be a bad thing.

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

I agree; I don't know of any such techniques but please correct that 
impression if it is incorrect.

>
>> 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
>
>
-----------------------------------------------------------------
Seth Kurtzberg
CTO
ISEC Research and Network Operations Center
480-314-1540
888-879-5206
seth@isec.us
-----------------------------------------------------------------

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