Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: [Caml-list] OCaml compared as a scripting language
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Brian Hurt <bhurt@s...>
Subject: Re: [Caml-list] OCaml compared as a scripting language
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