James G. Sack (jim) wrote:
I have to say that the propaganda is pretty persuasive (at least to a
lisp-novice such as me even given my relative java-ignoramushood),
leading me to believe that maybe:
- clojure is a better lisp than (say) CLOS/scheme .. largely because of
a broader abstraction of data and operations on "sequences" instead of
(simply) lists, and an absolute definition of immutability, and
syntactically enforced control of those things that have to be mutable
(see next).
Meh. It's different, but probably not better.
What's different seems to be the *community* surrounding it. The folks
working with/on Clojure don't seem to be allergic to doing the grubby
things that Lispers normally can't be bothered with: testing,
interfacing with libraries and documentation. Beginner documentation is
lacking, but Clojure is *way* ahead of where other new languages were at
similar stages.
- clojure has a very simple and robust concurrency support, thus making
it a more practical (or at least more general purpose) functional
language than say ML/haskell/erlang .. as well as a prime candidate for
making best use of multi-core environments.
I don't know about simple, but it is one of the few languages that has
actually even *THOUGHT* about concurrency. That gets my attention.
- clojure's design approach that JVM is _the platform_ seems to be a win
on several fronts: platform-supplied GC, exceptions, libraries.
Well, it gets you libraries. That's a big deal.
The rest is probably a wash.
- clojure's tight integration with JVM-as-platform gives performance
benefits without sacrificing functional goals, and it also allows total
access to java classes and libraries (although skill is required to
avoid doing damage to the immutability behavior, I gather).
Not sure I swallow this. Clojure doesn't seem like it really hews to
much to "functional goals". It doesn't do functional to be pure--it
does functional because immutability pretty much demands it.
I am trying to determine whether clojure might be suitable to use as the
environment for an intro to programming course
NO! Dear Diety, no!
The problem with Clojure is that it is immature. You need to be good
enough at programming that when you get bit in the ass, you can sort out
whether it's:
A) PEBKAC--you being stupid
B) PEBKAC--not quite understanding Clojure's abstractions
C) Clojure--incorrect semantics
D) Clojure--incorrect code generation
E) JVM--corner case that Java doesn't hit
That's too tall an order for someone new to programming.
A side note about clojure is that it quite completely dismisses OO as a
_general_ solution (not that OO doesn't fit _some_ things well). In the
process clojure offers other ways to do function overloading without
requiring classes and inheritance. I'm kind-of thinking it's time to
give some serious consideration to this approach.
Well, it's the standard multimethod-type dispatch familiar to people who
use CLOS. Multimethod has it's uses and benefits, but, most of the
time, you really do only want single method dispatch (a set of functions
operate on a single data structure).
His OO anti-bias may be a problem. You quite often do need some way to
bind together related functions and their data structure.
However, Clojure seems to offer some namespace/package-type support
which is what most people use OO clases for anyhow.
Yeah, it's on my list. I just haven't yet had time to pull it down and
use it for something in anger.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
