On Fri, 18 Dec 2009 00:44:02 -0500
Luc Préfontaine <lprefonta...@softaddicts.ca> wrote:
> Mike, I think that the whole issue about Lisp creates a big cloud about
> Clojure.
Yes, it does. When I mention that, people tend to shudder.
> If you sum up Clojure as being a Lisp because of what it look likes and
> use only this to compare it to other
> languages then you are missing the forest and looking at a single tree.
I agree with that as well. My point wasn't that Clojure is "just
another LISP", it's that a good grasp on writing LISP well gets you
over the biggest hurdle in going from C-family languages to Clojure.
> If you code in a Lisp like language using setq or set! or alike then you
> can get very far away from functional
> programming and end up writing procedural code with parenthesis. You
> will eventually face the issues that Clojure avoids.
Yup, but those were considered bad style in the places I learned
LISP. If you avoided those - as I was taught to do - the code you
wrote looks a lot like most of the Clojure code I've seen to date.
> Clojure takes a brutal approach, forget the left-right assignment that
> almost every language eventually
> supports, forget variable mutations visible to everyone, forget
> procedural code...
> Oups these are the real show stoppers independently of the syntax used.
> There's no escapes in Clojure while in other languages you can still
> cheat (setq/set! and similar).
Why don't you consider ref's and atoms escapes in Clojure? I can use
those to write C code with Clojure syntax, just like I can use setters
to write C code with Scheme syntax. The point isn't how easy/hard it
is to write C code with that syntax; it's that well-written LISP looks
an awful lot like well-written Clojure.
> What I found non-trivial in Clojure were these "restrictions", no the
> syntax. As soon as I understood
> the decisions behind these choices, my mental blockage vanished.
Again, I agree. The real issue isn't the syntax, it's the
*mindset*. Well-written LISP is functional, and tends to avoid set,
and dynamically scoped variables, and macros that capture variables,
and all such things. Sure, they're available if you find yourself
stuck, but they shouldn't be your first choice.
> Immutable data structures, transparent iterations over a variety of
> structures, lazy sequences, a workable STM implementation,
> parallel processing capabilities ridiculously simple to use, huge set of
> Java librairies available, easy to use, ...
> These are the real features that make Clojure distinct from other
> languages. All the choices made are sound and the
> sum of these decisions is coherent. Nothing looks like it's been added
> late to fill a gap like a nose in a face.
Yes, but it's the sum of those choices that make Clojure
distinct. Each of them exist in one or more other languages.
My point was that of all of those features, the hardest to get used to
if you haven't seen it before is the LISP-like functional programming
aspect. That's a fundamental change in the way you program. The rest
of them - well, they may be major improvements in the areas they touch
upon, but they don't change they way you think about programming much
outside of that area. Those others are like switching from playing
cornerback to safety, or defensive end to tackle. Getting used to pure
functional programming the first time is like switching from defensive
end to wicket-keeper.
> I adhere to justified critics when a rationale has been exposed
> otherwise I call it (repeat "blablabla").
I wasn't claiming that the original analysis was anywhere near
correct. I was responding to the claim that two or three months wasn't
enough time to learn Clojure well. I don't see anything here that
someone who's already got their head around writing pure functional
code should have a lot of trouble with in that amount of time. Sure,
there are other pure functional languages with loopholes - and even
some with high-level concurrency features - but those are all even
less popular than LISP when it comes to real-world programming.
> To expose some rationale it implies that you understand the subject you
> are talking about. If you don't then you should
> be cautious about what you state or you state it conditionally.
You state that as if there were hard scientific facts behind any of
this. When was the last time you saw a serious scientific study of how
any of these features - or pretty much any set of features - affect
programmer productivity? All we've got is hearsay and personal
experience, possibly gussied up as "case studies" to make them sound
respectable.
So would it make you happy if I point out that my conclusions are
based on my experiences? I think comparing peni.. uh, years of
experience is a silly thing. A fool with lots of experience is still a
fool. However, I've managed to deal with every feature you mentioned
above, and every feature I've found so far in Clojure, in some form or
another during my career. The only one that make me have to stop and
do a complete mental reset - that makes me feel like I'm suddenly
trying to code upside down, or backwards, or both - is pure functional
programming. The only thing even remotely comparable to that was
learning how to write horizontal microcode.
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
