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 RAA29755; Sat, 15 Mar 2003 17:30:09 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA03480 for ; Sat, 15 Mar 2003 17:30:08 +0100 (MET) Received: from hirsch.in-berlin.de (hirsch.in-berlin.de [192.109.42.6]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h2FGU7X10287 for ; Sat, 15 Mar 2003 17:30:07 +0100 (MET) Received: from hirsch.in-berlin.de (localhost [127.0.0.1]) by hirsch.in-berlin.de (8.12.8/8.12.8/Debian-2) with ESMTP id h2FGU7sn000379 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Sat, 15 Mar 2003 17:30:07 +0100 Received: from first.UUCP (uucp@localhost) by hirsch.in-berlin.de (8.12.8/8.12.8/Debian-2) with UUCP id h2FGU3Yh000354 for inria.fr!caml-list; Sat, 15 Mar 2003 17:30:03 +0100 X-Envelope-From: oliver@first.in-berlin.de X-Envelope-To: inria.fr!caml-list Received: by first.in-berlin.de via sendmail from stdin id (Debian Smail3.2.0.114) Sat, 15 Mar 2003 17:27:43 +0100 (CET) From: oliver@first.in-berlin.de (Oliver Bandel) Date: Sat, 15 Mar 2003 17:27:43 +0100 To: caml-list@inria.fr Subject: Re: [Caml-list] OCaml popularity Message-ID: <20030315162743.GA428@first.in-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Spam: no; 0.00; oliver:01 in-berlin:01 bandel:01 caml-list:01 0600,:01 pierre:01 weis:01 inference:01 avoids:01 struct:01 criticize:01 o'reilley:01 didier:01 ocaml:01 caml:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Fri, Mar 14, 2003 at 07:43:53PM -0600, Tushar Samant wrote: > 02003-03-11 | Pierre Weis writes: > > have to learn it. This may be the main drawback of Objective Caml: > > there is no ``Objective Caml for dummies''. That may be the price to > > Well said. I have had haphazard formal training in programming, > and until I arrived at the idea of informally reasoning out type > inference I essentially could not go beyond print_string(). This > is a type of thing which can go in "Ocaml for Dummies". As another > example, take type constructors. Here is their first occurrence in > the proposed O'Reilly book: > > In contrast with tuples or records, which correspond to a Cartesian > product, the declaration of a sum type corresponds to a union of sets. > Different types (for example integers or character strings) are gathered > into a single type. The various members of the sum are distinguished by > -constructors-, which support on the one hand, as their name indicates, > construction of values of this type and on the other hand, thanks to > pattern matching, access to the components of these values. To apply > a constructor to an argument is to indicate that the value returned > belongs to this new type. > > A programmer who is constantly asked to parse xml, make database > queries etc at work is not going to be sympathetic to this. Well, maybe it's better that he is not. :) > And > no considerations of why other ways of doing it lead to a stronger > or weaker system are going to sway him. But a Dummies book, hand- > waving a constructor away as a flag or label, might. The third and > last example is the introduction of structures in the reference manual: > > A primary motivation for modules is to package together related > definitions (such as the definitions of a data type and associated > operations over that type) and enforce a consistent naming scheme > for these definitions. This avoids running out of names or acci- > dentally confusing names. Such a package is called a -structure- > and is introduced by the struct...end construct, which contains > an arbitrary sequence of definitions. The structure is usually > given a name with the module binding. Well, I don't think it's a good idea to throw such (imho hard) stuff away. A better presentation will be a way to go. I'm happy to have books like the O'Reilley-book (even if it sometimes sounds different, when I criticize it). They use the language, which is necessary to explain something. But it sometimes (or often) could be more well explained to peiople who are not so familiar with this sort of thinking. It's IMHO not a problem that there is to learn a lot. The only problem IMHO is, if there are no texts and/or people, who I can ask to go further. When things are complicated,and different and unknown, then it is not a good idea to oversimplify. It's better, when explaining the complicated/new/unknown in more detail. So I had found some papers, not all covering my knowledge-level, but each of them is interesting (some has helped me, others may will help me later, when I have more experience/knowledge in the FP-area). These texts I have found: - The documentation, coming with OCaml (Reference != learning papers) - Tutorial: stephan.html (very good intro to start first steps!) - Caml quick reference guide (good idea, but layout could be better) - An introductional text, which has helped me a lot before the OCaml book in english was put on the server. I don't know who has written it, because the author has not written his name/mailaddres into it. The first two sentences in this paper: "This documentation is an introduction to ML programming, specifically for the OCaml implementation. In CS134a, we used C (and variations) to specify processes, monitors, semaphores, devices and more." (and so on) (Could be better, with a table of content and an index; but to start it's much better than the O'Reilley book, because of a lot of examples.) - O'Reilley-OCaml-book (good for gaining an overview on the language) - Didier Remy: Using, Understanding, and Unraveling The OCaml Language (Sometimes I understand some paragraphs. Good work, but is more a paper for the OCaml-gurus with theoretical background, but neverheless interesting and some example code is used there too.) If there are books, explaining how to go from imperative non-computer-studied person to a person who understands this text fully, please let me know... There are a lot of papers, but there are too much gaps between the one knowledge (and it's representation) and the other. Filling the gaps would be a way, nut dumbing down! Ciao, Oliver ------------------- 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