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