caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Brian Hurt <bhurt@spnz.org>
To: Hellflame <hellflame@hotmail.com>
Cc: Ocaml Mailing List <caml-list@inria.fr>
Subject: Re: [Caml-list] OCaml compared as a scripting language
Date: Tue, 15 Jun 2004 15:07:31 -0500 (CDT)	[thread overview]
Message-ID: <Pine.LNX.4.44.0406151359560.4243-100000@localhost.localdomain> (raw)
In-Reply-To: <BAY22-DAV17tKZpFqIZ0000e909@hotmail.com>

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


  reply	other threads:[~2004-06-15 20:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-15 18:27 Hellflame
2004-06-15 20:07 ` Brian Hurt [this message]
2004-06-16  2:26   ` skaller
2004-06-16 11:00   ` sejourne kevin
  -- strict thread matches above, loose matches on Subject: below --
2004-06-14  9:52 Richard Jones
2004-06-14 15:55 ` Brian Hurt
2004-06-14 16:29   ` Richard Jones
2004-06-15  6:40     ` Florian Hars
2004-06-15 16:13       ` Bruno.Verlyck
2004-06-15 17:15         ` Richard Jones
2004-06-15 17:35           ` John Goerzen
2004-06-15 18:16             ` Karl Zilles
2004-06-15 19:23               ` John Goerzen
2004-06-15 21:17                 ` Alex Baretta
2004-06-16  2:12             ` skaller
2004-06-15 17:41           ` Jon Harrop
2004-06-15 17:42           ` William D. Neumann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44.0406151359560.4243-100000@localhost.localdomain \
    --to=bhurt@spnz.org \
    --cc=caml-list@inria.fr \
    --cc=hellflame@hotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).