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 UAA28059; Tue, 11 Mar 2003 20:48:03 +0100 (MET) 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 UAA28569 for ; Tue, 11 Mar 2003 20:48:01 +0100 (MET) Received: from mail2.hypermall.com (mail.hypermall.net [216.241.37.118]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h2BJm0f14323 for ; Tue, 11 Mar 2003 20:48:00 +0100 (MET) Received: from [216.241.35.41] (helo=swordfish) by mail2.hypermall.com with esmtp (Exim 3.36 #1) id 18spjC-0005dU-00 for caml-list@pauillac.inria.fr; Tue, 11 Mar 2003 12:47:58 -0700 From: mgushee@havenrock.com To: caml-list@pauillac.inria.fr Date: Tue, 11 Mar 2003 12:47:56 -0700 MIME-Version: 1.0 Subject: Re: [Caml-list] OCaml popularity (long!) Message-ID: <3E6DDAFC.19000.44771B6@localhost> In-reply-to: <20030311162627.GA32188@ontosoft.com> References: <005d01c2e76f$92d0f8b0$2713f9ca@WARP> X-mailer: Pegasus Mail for Windows (v4.02) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Spam: no; 0.00; mgushee:01 havenrock:01 caml-list:01 yankowski:01 gabriel:99 prolog:01 python:01 xslt:01 real-world:01 gui:01 erlang:01 otp:99 haskell:01 conceptual:01 dominated:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On 11 Mar 2003 at 10:26, Fred Yankowski wrote: > Richard Gabriel, author of the famous "Worse is Better" paper about > C/Unix vs Lisp, makes some interesting points in his recent book while > discussing his theory of what it takes for a programming language to > be accepted and evolve: > > The second mandatory feature is that the language cannot require > mathematical sophistication from its users. Programmers are not > mathematicians, no matter how much we wish and wish for it. And I > don't mean sophisticated mathematicians, but just people who can > think precisely and rigorously in the way that mathematicians can. That's probably true as far as it goes, but I think statements about what a language can or cannot *require* miss the mark a bit. I would argue that there are very few languages that intrinsically require sophisticated thinking for basic programming (I would place Prolog among those few, but not Ocaml--more below), but that you do need that precision and rigor to write great programs in any language. But how the language is presented to the world, through documentation, teaching, advocacy, and the activities and attitude of the user community, can make a big difference. If I may illustrate from personal experience: some time early last year I decided that I wanted to learn a new language, and that it was going to be functional. My background as a programmer is mainly in Python and Java, with bits of Tcl, Perl, Ruby, and Visual Basic here and there. Oh, and I studied Asian history in college. Why functional? I guess it's because I had been working with XSLT for a couple of years. There were aspects of the language that had been very puzzling. But someone pointed out to me that XSLT was a functional language, and as I began learning what functional programming was, it all started to make sense, and I wanted more. However, this was not an academic exercise; I was and am convinced that functional programming is a powerful tool for real-world tasks. But having practical goals obviously places some constraints on your choices: you need a good selection of libraries for real-world programming tasks (database interface, GUI, text processing, graphics, system interface, and so on), and you need a language that can be learned in a reasonable time period. So Prolog was clearly out ;-) My first stop was Erlang, partly because it was developed by and for industry. But that didn't last too long. Ericsson's OTP interpreter (or VM? I can't remember) was horribly slow, the selection of libraries was poor, there doesn't seem to be a serious effort to integrate Unicode into the core platform, and the documentation was abysmal (mostly disorganized rather than incomplete, I suppose, but incoherent information isn't much better than none). Then I found Haskell. It was a good learning experience, but after a few weeks of intensive study and experimentation, my feeling was: "Yes, Haskell, you are the One True Language. Now go away and let me get some work done." Though I really appreciated Haskell on a conceptual level, there were two major reasons I gave up on it. One was that, although there is a reasonable selection of libraries, when you look closely you find that many of them are suffering from bit- rot; in fact, the Haskell community seems to be dominated by academics who feel no need to develop generally useful tools. That's fine, but not what I was looking for. My other big problem with Haskell was ... you guessed it: monads! I must have read every introduction to monads that's available on line (and there are at least half a dozen), but I still don't really understand them. Without monads, you can't do any real work in Haskell, and monads are universally acknowledged to be a difficult concept. Yet every introductory text I have seen on Haskell insists that you learn the theory of monads before you can learn how to do things like I/O. Since I don't understand monads, maybe I'm missing something, but this insistence on theory before practice seems like pure dogma to me. I've even seen two or three Haskell tutorials that open with statements to the effect that "I could teach you how to write a Hello, World program, but I won't, because then you wouldn't understand why Haskell is so great." I don't buy that argument--at least I don't accept that it's universally true. People have different learning styles, but many learn best by doing. I don't know how typical I am, but I find that a good experience working with a new language naturally leads to a desire for deeper understanding. Which brings me around, finally, to OCaml. The main reasons I like OCaml and will probably stick with it are: OCaml and its community are focused on promoting good design and good programming practices, but not on enforcing theoretical orthodoxy. Knowledge about OCaml is freely available to those who want to learn; they don't have to think in any certain way; There is a good selection of libraries available. Certainly there are some gaps, but OCaml has up-to-date tools for a wide variety of common programming tasks; and, on a related note: OCaml seems to have momentum. Though the language isn't wildly popular, useful applications and libraries are being developed all the time; there is something new almost every week. > Furthermore, types that try to do more than that are a hindrance > to understanding. For example, abstract data types allow one to > write programs in which the interface is completely separate from > the implementation. Perhaps some large programming teams care a > lot about that, but a lot of programming goes on in ones and twos, > maybe threes. Types of this variety, with complicated syntax and > baffling semantics, is a hindrance to programming for many of > these folks. I wonder. It seems to me that the need for sophisticated program design stems mainly from the complexity of the problem. He also seems to be saying that larger teams are smarter ... because they have more bodies? My experience is just the opposite: the small teams I've known are smarter because every member is highly skilled and internal communications are easier. Let me propose an alternate (and perhaps somewhat cynical) view. Companies that employ large programming teams tend to favor Java. They may or may not be aware that there are other languages that foster much higher productivity. But Java is good for large teams, partly because its rigid OO paradigm means there are relatively few ways to structure a program, so managers can assign tasks with relative ease. Also, Java keeps everyone busy. Now, suppose someone were to propose that a large team adopt a "smarter" language, such as OCaml. Well, either all team members can handle it, or they can't. If some people can't handle it, then you have to either lay them off or find other work for them to do. Big problem for management. But what if all team members *can* handle it? What if they all love their new language? That may sound good, but now suddenly you have a large team full of highly motivated developers finishing their assigned tasks in half the time it used to take them. Then what? Probably some will just get bored, but others will start wanting to get more involved with the "big picture." Also a big problem for management. However much the business press may talk about people being empowered, the reality is that most large corporations assume--even depend on the fact--that the large majority of their employees are mediocre. Too many people working too effectively would upset the status quo, and is therefore a scary thought. So I say that Java is a corporate-friendly language, and OCaml, for better or worse, is not. -- Matt Gushee Englewood, CO USA ------------------- 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