From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id VAA19872; Mon, 19 May 2003 21:35:48 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id VAA20184 for ; Mon, 19 May 2003 21:35:47 +0200 (MET DST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id h4JJZjH02620 for ; Mon, 19 May 2003 21:35:46 +0200 (MET DST) Received: (qmail 43241 invoked from network); 19 May 2003 19:35:44 -0000 Received: from arda.pair.com (HELO compaqreview.d6.com) (209.68.1.133) by relay.pair.com with SMTP; 19 May 2003 19:35:44 -0000 X-pair-Authenticated: 209.68.1.133 Message-Id: <4.3.2.7.2.20030519120753.04545700@localhost> X-Sender: checker@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 May 2003 12:31:34 -0700 To: Brian Hurt From: Chris Hecker Subject: Re: [Caml-list] ocaml and large development projects Cc: David Brown , "'caml-list@inria.fr'" In-Reply-To: References: <4.3.2.7.2.20030517225010.04b748a0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam: no; 0.00; hecker:01 checker:01 caml-list:01 clue:01 relink:01 ocamlopt:01 dependencies:01 inlining:01 dlls:01 inlined:01 chris:01 ocaml:01 caml:01 recompile:01 interfaces:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >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