On Wed, 16 Aug 2000 08:13:16 -0700
"Craig Dickson" <[EMAIL PROTECTED]> wrote:
> <stuff deleted></stuff deleted>
>
> Ketil Z. Malde wrote:
>
> > : functions, while pretty first class objects, reside
> in
> > their own namespace, and need special operators.
> > : iteration and side effects are not particularly
> discouraged,
> > and is probably as common as recursion and purity in
> actual
> > code.
>
> I agree, and would add (if I'm recalling correctly) that
> LISP lacks lexical
> scoping, which may not be an absolute requirement for
> functional programming
> but certainly enhances it, and is a common feature of
> functional languages.
Actually, I meant "lexical scoping" when I mentioned "closure properties" earlier (in
comparing CL and Scheme--again, another reason to keep my copy of _Structure and
Interpretation of Computer Programs,_ by Abelson, Sussman, and Sussman, around at all
times :-) ).
> Friedrich Dominicus wrote:
>
> > But saying Lisp isn't functional (to some extend) is
> > simply not true.
>
> Well, it's that "to some exten[t]" that is the crux here,
> I think. If you
> are going to say that LISP "is" or "is not" a functional
> language (an overly
> simplistic, binary distinction), then you have to decide
> where to draw the
> line between "functional languages" and other languages
> that may, to some
> degree, include support for functional programming. LISP
> has much more
> support for FP than C++ or Perl, but not as much as
> Scheme, which in turn is
> less "pure" than Haskell or Erlang. So whether you want
> to say that it "is"
> functional or not is just a matter of where you draw the
> line. Scheme, which
> is undeniably more "functional" than LISP, is about the
> least purely
> functional language I would call "functional". So that's
> where I draw the
> line. Your mileage may vary.
One measure of functionality may also be how languages tend to be used.
At least where I studied it, Scheme usage tended to emphasize functional programming
and de-emphasize side-effects more than CL usage.
Haskell usage emphasized functional programming even more than Scheme.
>From what I've seen, language usage tends to be based on two factors:
1. How the language is designed.
2. How people are already using it.
Simply adding features to a language does not necessarily automatically change how
people use it. If programmers are already used to writing functions (or methods,
depending on the language) in a certain way in a given language, then just adding
features will not necessarily change how they program in it unless the new features
are significant enough to warrant the learning curve.
For example, maybe the newer varieties of CL now have lexical scoping. However, when
I learned it, it apparently didn't. In any case, the structure of CL then encouraged
me to try to master the myriad built-in functions to use side-effects to maximum
benefit, so this affected how I learned to program in CL, so my CL programs were far
from functional in style.
In contrast, when I learned Scheme, the compactness of the language encouraged me to
write my own functions for almost everything. Since I found it easier to follow the
functional style when writing my own functions than to use side-effects extensively,
my Scheme programs much more closely approached the functional style overall than my
CL programs.
When I studied Haskell before, the structure of the language encouraged me to follow
the functional style even more.
When many programmers have this kind of experience, it can change the direction that
the language, overall, becomes headed.
IMHO, this seems to be one reason that Haskell tends to be more "functional" than
Scheme, and Scheme than CL.
Going back to C# vs. Java, simply requiring unsafe code to be labelled as such is not
necessarily going to keep former C/C++ programmers from writing unsafe code to the
hilt in C#--any more than having classes built-in to C++ kept former C programmers
from following the old procedural style straight into C++.
The reason that Java programmers tend to write safer, more object-oriented code is
that Java makes it difficult, if not impossible, for them to do otherwise. The
learning curve for writing safe, object-oriented code in Java is actually lower than
for writing unsafe, procedural code.
If C# again makes it easy to write unsafe code, then in order to avoid the learning
curve, many current C/C++ programmers are likely to continue programming in The Old
Way. The trick lies in the learning curve.
--Ben
--
Benjamin L. Russell
[EMAIL PROTECTED]
[EMAIL PROTECTED]
"Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho
