Re: [Caml-list] Dynamically evaluating OCaml code

[John Goerzen <jgoerzen@complete.org>]

On Thu, Apr 08, 2004 at 01:24:45AM -0500, Brian Hurt wrote:
> majority of that in the eval function- so you're talking north of a
> megabyte of code.  As an application, that's small.  As a library, that's
> huge.  It's of the same size as linking in libgtk (1.3M).  No, you want a 
> small, simple language.  Although this might not be so bad- libperl.so on 
> my machine weighs in at 3.2M.

Indeed, and in fact:

-rw-r--r--    1 root     root      1073392 Feb 24 02:34 /usr/lib/libpython2.3.so.1.0

Python is often used as an embedded extension language as well.

> As a side note, I don't see Ocaml as a science project.  It's a pragmatic
> language, in that it doesn't automatically assume it knows what's best,
> but instead provides the programmer the tools he needs to get the job
> done.  As reflected in it's design decisions, the people designing Ocaml

Careful; that sounds like you're describing Perl :-)

[snip]

> Wandering into the arena of suspect analogy, if C and C++ are the blue
> collar assembly line workers, tightening bolts by hand, than Ocaml is the
> robot repairman maintaining the whole factory of robots.  He's every bit
> as blue collar and about getting real work done, but more educated and a
> heck of lot more productive.

I agree with most of your analogy here.  I'm still relatively new to
OCaml, having been using it for only a couple of months, but you've
touched on one of my pet peeves: the OCaml standard library is really
sub-par for doing real work.  Don't get me wrong; I'm still using OCaml,
but have to do a lot more wheel reinventing than with, say, Python.
Even basic functions that I've found in *every* other langauge I've used
are missing (here I'm thinking of things like asctime(), strptime(), and
many things relating to sockets and DNS [*especially* the complete lack
of IPv6 support).  The standard I/O functions miss out on trivial things
that I could do way back on DOS with Turbo Pascal, such as opening a
file for both read and write.  (I'd have to go through the Unix module
and some pain to do that in OCaml.)

Basic string processing is also more difficult than a language such as,
say, Python, where I can say, for instance:

y = x[2:-1]

In OCaml, I would write -- I think:

let y = String.sub x 2 ((String.length x) - 3))

Also, there is no string_of_char function (I'd have to use fill).
Things like splitting a string have to rely on str and regexps, an
unnecessary complexity for 90% of what I do.

Similar complaints exist for working with subsets of lists; it's really
too hard to say "replace elements 4 through 9 with this", "delete
elements 4 through 9", "return elements 4 through 9", etc.  (While we're
at it, I think it's silly that there is a list and an array type).  Yes,
I could write functions to do all of this, but my point is that I
shouldn't have to.

This library problem hurts productivity, and in some cases makes OCaml
less productive than even C.

One other thing to mention is that installing libraries is much more
difficult than it should be, and writing library build systems (and even
app build systems) is much more complex than it should be.  Part of this
is due to a lack of a standardized build system (think Perl's MakeMaker
or Python's setup.py).  Part of it is due to the complex array of OCaml
options -- for instance, some platforms do not support ocamlopt, so
while a library might normally build both native and byte-code versions,
it has to not try to if ocamlopt is missing.  (Something which, I have
found, many OCaml authors fail to consider.)  I've been toying with the
idea of writing a generic build system for OCaml to address this point
though.

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