Re: [Caml-list] build tools with critical mass?

["chris.danx" <chris.danx@ntlworld.com>]

Brandon J. Van Every wrote:
> The discussion of build technologies is amusing... I can imagine all
> sorts of wonderful problems I might try to solve, if only I didn't have
> more pressing problems to solve.  :-)  The problem I'm more interested
> in solving is deploying OCaml to a greater number of people.

I don't think you can promote a language using a funky a build tool to 
people convincingly, other than by rule of law.  The only way (IMO) that 
a language can be sold is by writing software in it to solve real 
problems (or problems that people percieve to be necessary or cool, even 
if they're not).

I pass over language marketting and zealots all the time on the web (of 
which there are literally millions).  It's not interesting and is 
actually quite a turn off!  There are lots of functional concurrent lazy 
languages out there but I'm not interested in functional programming, 
demand driven execution or concurrency for it's own sake, more solving 
problems appropriately (I use OCaml alot because it allows the most 
scope in design solutions with good speed performance when speed 
matters.  For distributed problems I'll use Oz or erlang, probably Oz 
morem again because of the flexibility in design).

Ocaml will get noticed from software written in it!  Even if most of the 
end users don't know it's written in Ocaml, the users who are also 
programmers may.  This seems to be the key to the success of a language, 
solving real problems in real software with noticable abundance.  So 
long as the language is consistent with itself (or mostly) it doesn't 
really matter how nice it is (although this has been changing over the 
past 15 years, more attention is paid to languages that stop the 
programmer messing up in disasterous yet simple ways).

You can talk about how to popularise a language until doomsday (lots of 
people do) but talking isn't doing.  What is the point in marketing a 
language anyway?  Sun and M$ do it to make money.  Other than that I 
don't get it.  What does it do for you as a developer?  (I understand 
why the language designer would - there are many different reasons - but 
don't get what a language user gets out of it).

It has taken me a while to find languages that fit my needs, but the 
more languages I learned the more it became obvious that so long as a 
language doesn't pigeon hole a problem into an innappropriate design 
solution the language is usuable for that problem.  Of course it maybe 
that some part of the implementation is not desirable in which case you 
either make do or find something else. e.g. mOzart/Oz isn't natively 
compiled and doesn't have the performance I need for graphics apps, but 
it is suitable for distributed or concurrent applications.  Ocaml is my 
choice for graphics because of it provides good performance and doesn't 
pigeon hole the problem to an "imperative", "object orientated" or 
"functional" solution.  You get the flexibility of combinationn of 
almost all the models in "Concepts, Techniques and Models of Computer 
Programming" with the slight loss of some of techniques (which may or 
may not be relevant to a problem - it's a trade off), but speed too 
which is appropriate for the *current problem*.

Hopping between languages looking for the magic catch all solution is 
folly.  Eventually you have to stop and pick one appropriate otherwise 
nothing get's done.  If you keep going and don't realise it's the 
concepts that matter you may never stop.  Once I realised what was 
really important, the choice of language was much easier - I stopped 
brute forcing it and made an informed search so to speak.  The 
popularity of a language isn't a major factor anymore and I now don't 
get the "market the language I use thing".  There are more important 
things to be getting on with, like developing software and going out on 
the pull.

I would like a nice build aid as would many people, but it's not a 
crucial language selling point.


> Several years down the road, maybe the more experimental build tools
> will gain enough adherants that they might become a basis for
> industrialization of OCaml.  But right now, I think we need something
> that's closer to being ready for prime time.  That, in my book, means
> it's been used by a pile of people and the results are encouraging.  So,
> what build tools fit this criterion?

I'm getting by with OcamlConf just now.  It handles the problem of 
configuring a build and doing so is less painful than autoconf/automake 
or SCons.  Not sure about omake, but will look at it later.


Chris

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