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 WAA05163; Tue, 15 Jun 2004 22:01:26 +0200 (MET DST) 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 WAA06172 for ; Tue, 15 Jun 2004 22:01:25 +0200 (MET DST) Received: from herd.plethora.net (herd.plethora.net [205.166.146.1]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i5FK1NEV027793 for ; Tue, 15 Jun 2004 22:01:24 +0200 Received: from bhurt.plethora.net (bhurt.plethora.net [205.166.146.49]) by herd.plethora.net (8.11.6/8.10.1) with ESMTP id i5FK1Ji01221; Tue, 15 Jun 2004 15:01:19 -0500 (CDT) Date: Tue, 15 Jun 2004 15:07:31 -0500 (CDT) From: Brian Hurt X-X-Sender: bhurt@localhost.localdomain To: Hellflame cc: Ocaml Mailing List Subject: Re: [Caml-list] OCaml compared as a scripting language In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at nez-perce with ID 40CF5593.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 nuts:01 python:01 fanatics:01 smalltalk:01 fanatics:01 langauges:01 reinventing:01 goto's:01 disadvantage:01 hacks:01 stdin:01 get's:01 intentional:01 not-:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Tue, 15 Jun 2004, Hellflame wrote: I said: > > I disbeleive that any language can be the one perfect language for all > > tasks. > > I think the Lisp camp would take exception to your comment. Most of the > Lisp hackers I know think it is the perfect language for all things and > is the best language out there. I tend to regard them as nuts and go > about my work though. :-) Actually, that was a pointed barb at the C++ camp, large numbers of whom beleive that C++ is the way, the truth, and the light. although perl, python, and ruby fanatics are just as bad. Both smalltalk fanatics I've met had it, as had a large number of Java fanatics. In days past, I knew people who said that about C, Pascal, assembly language, PL/1, and FORTRAN. Let me use PL/1 as an example, as it's less likely to stir up emotions. PL/1 was the first language that I know that was explicitly designed to be all things to all people. The problem that developed with PL/1 was that, to be all things to all people, it had 18 gazillion features. Which meant that you started getting people programming in different subsets of the language not being able to even understand each other's code. The "modernist" (to use Larry Wall's teminology) theory of programming languages arose largely as a reaction to the "pre-modernist" languages before them- which share a lot of philosophical with the "post-modernist" langauges Wall touts (the most striking of which is untrammelled complexity). At which point the whole debate turns into yet another instance of programmers reinventing the wheel (but this time we'll make it with four sides, instead of just three!). Actually, I could argue this is third time around this block. Consider "Goto's Considered Harmfull" and procedural programming (which gave rise to PL/1) was a reaction to the goto-heavy sphagetti programming paradigm, which still had adherents into the seventies. Modernism leads to post-modernism leads to post-post-modernism which looks an awful lot like the original modernism. The way to get off this rollercoaster is to realize that efficiency in the small is not the same as efficiency in the large. In fact, what may be an advantage at one level may be a disadvantage at another level. And that therefor efficiency in the large cannot be acheived with a large number of efficiencies in the small. An example of this is implicit sideeffects side-effects- something Perl does a lot of. This is actually an efficiency in the small, and it lets you write quick hacks like (if I recall my Perl correctly): while (<>) { $count += $_; } The equivelent Ocaml code might look something like: let sumfile = let rec loop cnt = let line, eof = try (input_line stdin), false with | End_of_file -> "", true in if eof then cnt else loop (cnt + (int_of_string line)) in loop 0 ;; I just quintupled the lines of code there- 3 lines to 15 lines. But the problem is that Perl get's in brevity (in part) by sideeffects- it sets the (effectively) global and widely used $_ variable. If the code got modified to: while (<>) { do_something(1, 2, 3); $count += $_; } Now if $_ is modified by the function do_something, the whole routine is broken. This code and the do_something() routine now have a dependency- intentional or not- between them. For small programs (for a sufficiently loose definition of small), this isn't a problem- just don't do that, or handle the interaction. For large programs, these "unintentional" dependencies are more likely to crop up unexpectedly, and be harder to track down. The technical term for these unintentional, unexpected interactions is "bugs". Now, the whole situation has reversed. Ocaml's feature of immutability/functional programming becomes an advantage in the large, while Perl's feature of side effects becomes a disadvantage. -- "Usenet is like a herd of performing elephants with diarrhea -- massive, difficult to redirect, awe-inspiring, entertaining, and a source of mind-boggling amounts of excrement when you least expect it." - Gene Spafford Brian ------------------- 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