Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Dynamically evaluating OCaml code
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Brandon J. Van Every <vanevery@i...>
Subject: [Caml-list] build tools - good vs. fast, both cheap
Kenneth Knowles wrote:
> On Thu, Apr 15, 2004 at 04:58:47PM -0700, Brandon J. Van Every wrote:
> >
> > Productive would be, you go do your thing, we'll go do ours.  Enough
> > talk.  We know where our lines of disagreement are.
>
> Actually I don't know at all.  All I know at this point is
> that we agree that
> current tools are inadequate (many times over).  If we "go
> our separate ways"
> it'd be stopping the discussion before it starts, and each
> party certainly has a
> right to do that, it's just a bummer.

Ok, if you want to discuss, then let's please everybody refrain from
labeling other people's lines of discussion as offtopic rants,
uninteresting, etc.  I don't mind hearing when someone says they think
such-and-such tool or approach sucks.  They might, after all, be
partially or even wholly correct.  I do mind when someone says our
opinions aren't worth expressing.  It's a quick way to kill a
discussion.

So where are we?  We're having the age old engineering argument, "good,
fast, cheap, pick any two."  We're all open source developers so we're
all cheap.  :-)  We've got one camp that sees an all-OCaml build +
package management system as the goal.  Count me in on that, and I will
label it the "GOOD AND CHEAP" camp.  We've got another camp that sees
getting any build + package management system together as quickly as
possible from readily available parts as the goal.  I will label it the
"FAST AND CHEAP" camp.

We know that good will not be fast.  Ideal solutions take a long time to
develop.  We've got plenty of starting points and interim scaffolding
available though.

Will fast be any good?

What is the ultimate goal?  I say, the ultimate goal is total ease of
use for an OCaml developer.  The OCaml developer should have a major
platform advantage over everyone else.  It should be a helluva lot
easier for OCaml guys to get their packaging and dependency job done
than anyone else out there.  The tool should be completely
cross-platform.  I would like to think that somehow, OCaml would analyze
lotsa stuff and automagically figure tons of things out.  It should
seriously leverage the power of the language.  It should be a heavy duty
value add to the developer, a big incentive to join the OCaml community
because We Do Things Better [TM].  Makefiles and autoconf cannot achieve
that ultimate goal.  I've worked with them plenty, back in the day I was
an autoconf guru.  Now when I get back into it I just scream, "The
horror!  The horror!" before I die.  We shouldn't be aspiring to the
manual labor of Make and company.

My philosophy is, if it is not an advanced build and package management
system, there is no point in pursuing it.  The ad hoc methods already
suffice for lesser goals.  So, with that in mind, what is currently the
most advanced build and package management system known to Humankind, in
any language?  That is where we should be looking for design reuse.

After that, then we ask what kinds of expertise we already have among
us.  Some have already been mentioned: OCamake, OCamlconf, GODI,
Interscript.  Any / all of these things could potentially provide
components, designs, or scaffolding.  It is quite possible that what is
actually needed, has not yet been built by any one person.  In that case
it would be best if people recognize personal inadequacy and agree to
work together for the common good.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

When no one else sells courage, supply and demand take hold.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.643 / Virus Database: 411 - Release Date: 3/25/2004

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