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 SAA22031; Thu, 8 Apr 2004 18:10:02 +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 SAA22048 for ; Thu, 8 Apr 2004 18:10:00 +0200 (MET DST) Received: from herd.plethora.net (herd.plethora.net [205.166.146.1]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i38G9xYM007601 for ; Thu, 8 Apr 2004 18:09:59 +0200 Received: from bhurt.plethora.net (bhurt.plethora.net [205.166.146.49]) by herd.plethora.net (8.11.6/8.10.1) with ESMTP id i38G9kQ03363; Thu, 8 Apr 2004 11:09:48 -0500 (CDT) Date: Thu, 8 Apr 2004 12:15:52 -0500 (CDT) From: Brian Hurt X-X-Sender: bhurt@localhost.localdomain To: John Goerzen cc: Issac Trotts , Ocaml Mailing List Subject: Re: [Caml-list] Dynamically evaluating OCaml code In-Reply-To: <20040408133727.GC29195@excelhustler.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 dynamically:01 2004:99 function-:01 -rw-r--r--:01 usr:01 python:01 pragmatic:01 analogy:01 analogy:01 posix:01 add-on:01 non-standard:01 connectivity:99 gui:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 160 On Thu, 8 Apr 2004, John Goerzen wrote: > 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. I think I've talked myself into that Ocaml, at least the VM part, should be embeddable. > > > 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 :-) I've heard that used to describe Perl, C++, and Java, in different ways. As such, I'm using it as a benchmark for what a "usable" language is. > > 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. Heh. It's orders of magnitude better than the C or C++ standard libraries. Which explains why those languages never went anywhere :-). Note that POSIX is an add-on layer, not gaurenteed to be there. So all socket communication is optional and non-standard. As is all database connectivity, GUI handling, etc. The thing is, almost no one actually programs the "standard" C/C++ environment. Every C/C++ environment comes with a whole collection of add-on libraries- POSIX at a minimum. Generally a whole lot more. I think the problem here isn't technical, it's social- marketing, to be specific. Having a language with a very minimialistic standard library isn't the problem- the problem is have a standard development environment with a minimialistic library. The "core" language and libraries distribution should be, if not hidden, then at least not obvious. Instead, the "default" Ocaml distribution should be something more like CDK (is that project still alive?). There shouldn't be links from the home page to the core, the home page should link to CDK *only*. And we need to get the Linux distros up to speed and distributing CDK instead of only Ocaml-core. While we're kvetching, here's my list of desires to be in the default development environment (note that I don't think any of these belong in the standard libraries): - OUnit - ExtLib (OK, this should perhaps become part of the standard) - BLAS/LAPACK, GMP, and MPI bindings - Regular expressions - ocamlexc - Camllisp (or similiar) - compression, encryption, etc. filters for I/O Certain things can be moved out of the standard distribution and moved into the development environment in this case- pcaml, ocamldoc, ocamlex, ocamlyacc, etc. Of course, the other advantage that the standard distribution has, in addition to being the default, is coherent documentation. There is one book, and everything in the standard distribution is more or less equally well documented (ocamllex and ocamlyacc could use some help). The same thing should be true for the development environment. > 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. They aren't hard to write, the problem is that they're O(N). To replace element 9 in a list, you also end up replacing elements 0-8 as well. I would argue that if you're wanting to do this routinely and efficiently, you shouldn't be using lists. I'd recommend Map or Set myself. > 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. There have been several swings taken at this already- the relevent developers should be letting you know about them. If you're regularly having to install more than one or two libraries for your development environment, that's a problem. I mean, think about it. You install Linux, how many libraries do you generally need to add to do C/C++ programming? Or Visual Studio? You don't realize how much of the stuff is "optional" because it's all installed automatically. -- "Usenet is like a herd of performing elephants with diarrhea -- massive, difficult to redirect, awe-inspiring, entertaining, and a source of mind-boggling amounts of excrement when you least expect it." - Gene Spafford Brian ------------------- 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