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 RAA18102; Mon, 6 Sep 2004 17:01:38 +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 RAA17594 for ; Mon, 6 Sep 2004 17:01:37 +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 i86F1alc004546 for ; Mon, 6 Sep 2004 17:01:37 +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 <20040906150005.EZWR4727.mta03-svc.ntlworld.com@[80.4.70.84]>; Mon, 6 Sep 2004 16:00:05 +0100 Message-ID: <413C7BD0.8090109@ntlworld.com> Date: Mon, 06 Sep 2004 16:01:36 +0100 From: "chris.danx" User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: skaller@users.sourceforge.net CC: "Brandon J. Van Every" , caml-list Subject: Re: [Caml-list] build tools with critical mass? References: <413BC51A.1030009@ntlworld.com> <1094462464.3352.1043.camel@pelican.wigram> In-Reply-To: <1094462464.3352.1043.camel@pelican.wigram> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 413C7BD0.001 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 2004:99 dynamically:01 statically:01 dynamically:01 fence:01 meets:99 meets:99 constrain:01 ditch:01 clue:01 chris:01 chris:01 ocaml:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk skaller wrote: > On Mon, 2004-09-06 at 12:02, chris.danx wrote: > >> 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. > > Yes but if you look at the reason you can do this, you'll > find answers like 'sound type system', and then you can > start to use that as a way to judge the capabilities of > other languages. It's almost a certainty that when someone brings up a discussion on type systems there will be a flame war and no consensus at the end. This is one reason why I did not mention that Oz was dynamically typed. The other is a language being statically or dynamically typed is not a big thing for me. I understand the impact this choice has, what the advantages and disadvantages are and how they will affect the outcome. Then I choose the right tool for the job at hand. I don't sit on one side of the fence screaming x typed languages are better than y typed ones. Similarly for other aspects of languages. Discussing such things is important for understanding them, but championing one over another with a closed mind (which IME is the case for a lot of people) is not imo helpful. > in that case 'it meets my needs' isn't so much of an argument, > since the *real* requirement isn't that it meets you needs, > but that it meets you needs *and will continue to do so > in the face of change*. This is true if you want a language for lots of problems. So long as a language is appropriate for the design solution and doesn't constrain it in ways that make the design ugly, that language is likely to be ok for that problem. So I'm perfectly happy to ditch Ocaml in favour of X when X allows a better design for a particular problem though will continue to use OCaml and Oz as general purpose languages. > In other words to predict the true productivity benefits > of a language you really do need to examine the mathematical > fundamentals. I don't see how this follows. The fact that OCaml has or does not have a Milner-Hindley type system is not all that relevant to me because I have no clue what that is, nor do I care to learn it. I will learn the practical effects of the type system by programming in Ocaml and reading the documentation. Ditto other parts of the mathematical forumaltion of Ocaml. They help, but I don't want to spend hours distracting myself learning theory from the task of developing. In practice I learn enough theory to get by in practice and more theory from practice. That works for me. If the problem requires knowlege I don't have, I ask and learn it. 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