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 EAA20368; Mon, 6 Sep 2004 04:02:05 +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 EAA18665 for ; Mon, 6 Sep 2004 04:02:03 +0200 (MET DST) Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id i86223Sh008417 for ; Mon, 6 Sep 2004 04:02:03 +0200 Received: from [80.4.70.84] by mta03-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040906020031.MESA4727.mta03-svc.ntlworld.com@[80.4.70.84]>; Mon, 6 Sep 2004 03:00:31 +0100 Message-ID: <413BC51A.1030009@ntlworld.com> Date: Mon, 06 Sep 2004 03:02:02 +0100 From: "chris.danx" User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Brandon J. Van Every" CC: caml Subject: Re: [Caml-list] build tools with critical mass? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 413BC51B.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; ntlworld:99 caml-list:01 brandon:99 amusing:01 deploying:01 funky:01 zealots:01 erlang:01 disasterous:01 natively:01 get's:01 realised:01 configuring:01 autoconf:01 automake:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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