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 BAA26252; Tue, 20 May 2003 01:39:18 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id BAA25969 for ; Tue, 20 May 2003 01:39:16 +0200 (MET DST) Received: from mail.cql.com (jael.cql.com [216.19.209.133] (may be forged)) by nez-perce.inria.fr (8.11.1/8.11.1) with SMTP id h4JNdAT01797 for ; Tue, 20 May 2003 01:39:14 +0200 (MET DST) Received: (qmail 15953 invoked from network); 20 May 2003 00:58:51 -0000 Received: from unknown (HELO isec.us) (192.168.1.16) by mail.cql.com with SMTP; 20 May 2003 00:58:51 -0000 Date: Mon, 19 May 2003 16:39:00 -0700 Subject: Re: [Caml-list] ocaml and large development projects Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Brian Hurt , David Brown , "'caml-list@inria.fr'" To: Chris Hecker From: Seth Kurtzberg In-Reply-To: <4.3.2.7.2.20030519120753.04545700@localhost> Message-Id: <11646262-8A53-11D7-B86B-000A959AF1CE@isec.us> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam: no; 0.00; caml-list:01 hecker:01 granularity:01 compiler's:01 clue:01 relink:01 ocamlopt:01 dependencies:01 inlining:01 dlls:01 inlined:01 bug:01 faq:01 beginner's:01 beginners:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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