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 UAA26614; Wed, 14 Apr 2004 20:54:03 +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 UAA27175 for ; Wed, 14 Apr 2004 20:54:02 +0200 (MET DST) Received: from gatekeeper.elmer.external.excelhustler.com (gatekeeper.excelhustler.com [68.99.114.105]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i3EIt2jq008125 for ; Wed, 14 Apr 2004 20:55:03 +0200 Received: from chatterbox.elmer.internal.excelhustler.com (unknown [192.168.0.12]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "chatterbox.elmer.internal.excelhustler.com", Issuer "excelhustler.com" (not verified)) by gatekeeper.elmer.external.excelhustler.com (Postfix) with ESMTP id BBEBDE00DC; Wed, 14 Apr 2004 13:53:59 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by chatterbox.elmer.internal.excelhustler.com (Postfix) with ESMTP id 812E05C006; Wed, 14 Apr 2004 13:53:59 -0500 (CDT) Received: from wile.internal.excelhustler.com (wile.internal.excelhustler.com [192.168.1.34]) by chatterbox.elmer.internal.excelhustler.com (Postfix) with ESMTP id 504265C005; Wed, 14 Apr 2004 13:53:59 -0500 (CDT) Received: by wile.internal.excelhustler.com (Postfix, from userid 1000) id ACD3C38063; Wed, 14 Apr 2004 13:54:00 -0500 (CDT) Date: Wed, 14 Apr 2004 13:54:00 -0500 From: John Goerzen To: "Brandon J. Van Every" Cc: caml-list Subject: Re: [Caml-list] recompiling bytecode Message-ID: <20040414185400.GD21331@excelhustler.com> References: <1081945187.20677.710.camel@pelican> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-Scanned-By: clamscan at chatterbox.elmer.internal.excelhustler.com X-Miltered: at nez-perce by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 2004:99 brandon:99 python:01 python:01 runtime:01 python's:01 ocaml's:01 infer:01 runtime:01 ocaml's:01 outset:99 forking:01 equipment:98 ocaml:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Keywords: X-UID: 347 On Wed, Apr 14, 2004 at 11:21:01AM -0700, Brandon J. Van Every wrote: > > 1990's -- 20-40 minutes (C/C++) > > 2000's -- 10-60 seconds (Ocaml) > > Because you are not compiling programs large enough and often enough for > this to become sheer hell? I've read many a postmortem in GameDeveloper > magazine where excessive compile times are a major drain on > productivity. Anecdotally, I've met too many happy Python programmers > to poo pooh the evasion of compile time. As a pretty much happy Python programmer myself, as well as a disgruntled Java programmer and an OCaml novice, let me point out that you are not providing the whole picture here. Python does not have a zero compile time. Like OCaml, it has a small compile time on modern equipment, but actually this is because its compile phase uses precompiled bytecode for just about all libraries, so all it really has to compile is the application -- and it does this as the different modules or functions are first used, rather than up front for everything. It is quite possible for an application to begin executing before it has completely compiled. (In fact, it pretty much has to, since "import" is a command that is executed at runtime.) In fact, the main difference between Python's compilation and OCaml's bytecode compilation is not how fast or what happens, but *when*. If you don't believe me, run a Python program from a writable directory and note the .pyc files that magically appear. Therefore, it is possible to have a Python program that does not actually produce a syntax error until the program has been running for some time and executes a particular code path. Now, you should be able to infer from this that there is a productivity setback with Python because certain glaring errors are not caught until runtime. If your program is such that it takes several minutes or hours of processing to be able to hit the critical section with errors, you can appreciate that this is not necessarily a good thing. (It *is* possible to compile things to bytecode in advance in most cases with Python, but this is not well supported for the average programmer) There are also entire classes of errors that even a Python compile will not catch that an OCaml compile will -- such as reversing the order of arguments in a function call when each argument has a different type. I like OCaml's typing system. It's effective at preventing mistakes without being the lumbering typing dinosaur that is Java. I have found OCaml to compile quite quickly. In one project, I compile about two dozen source files -- including ocamllex and ocamlyacc files -- to generate one library and one application. That completes in less than one second, and it has structural ineffencies (make, for one) that handicap it from the outset. I'd venture to say that the compile process spends more time forking and invoking bash than actually compiling code. (Of course, this could be optimized should I feel the need to. Suffice it to say I'm not really worred about a 1-second build time.) -- John ------------------- 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