Clojure analysis
kusi
Sean Devlin
A very interesting critique. Well written, and you've got guts
posting it to this list.
There are a few very important factors you need to consider to have a
complete critique, though.
First, is the STM. This is THE killer feature of the language.
Ironically, it gives Clojure its identity, and ridiculously clean
design. Write a concurrent app with it and you'll see.
You are right, that there aren't many books about how to program in
Clojure. The current expectation is to use Lisp, Scheme, Erlang or
Haskell resources to fill in the gaps right now. The Clojure
community admittedly still filling in the gaps.
I think if you spent a month writing a lot of Clojure, you would
revise your criticism.
Feel free to post any questions you have about the language to the
list, and we'll do our best to answer them.
Hope this helps,
Sean
On Dec 11, 4:04 pm, kusi <kusim...@gmail.com> wrote:
> http://kusimari.blogspot.com/2009/12/analysing-clojure-programming-la...
Stuart Halloway
very first sentence. I hope that the author will have time to do a
more in-depth exploration of Clojure and make some modifications.
If you are looking for accurate introductory information on Clojure, I
would recommend:
* http://clojure.org/rationale
* http://clojure.org/state
* http://clojure.blip.tv
Stu
> http://kusimari.blogspot.com/2009/12/analysing-clojure-programming-language.html
Joost
> First, is the STM. This is THE killer feature of the language.
> Ironically, it gives Clojure its identity, and ridiculously clean
> design. Write a concurrent app with it and you'll see.
it's a cool feature that I've personally not used that much yet, being
a fairly recent "convert". What I like about clojure most is the
"ridiculously clean design" of the collection types, and the way it
encourages pure-functional programming without it feeling forced. It
easily kicks the ass of every other Lisp I've seen. I like Lisp, but
in Common Lisp and Scheme all the collection types other than lists
seem "bolted on". Clojure is the first programming language (not just
Lisp variant) I've seen that offers a such a clean & consistent way of
dealing with maps, lists, vectors etc.
If I had to offer critisisms of clojure pretty much all of it is due
to the JVM; off the top of my head: lack of optimized tail-calls and
threads being too expensive (I really think Erlang does this much
better) at the most annoying. Personally, I think the whole built-on-
Java thing is OK but not great, it's good to have an alternative when
there is no clojure library for *insert problem here*, and it probably
helps adoption of clojure in "enterprisy" environments, but that's
about it as far as I'm concerned - I certainly do not see clojure as a
"better Java".
Cheers,
Joost Diepenmaat - who's done Java, and didn't like it much.
Joseph Smith
---
Joseph Smith
j...@uwcreations.com
(402)601-5443
On Dec 11, 2009, at 3:04 PM, kusi <kusi...@gmail.com> wrote:
> http://kusimari.blogspot.com/2009/12/analysing-clojure-programming-language.html
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
Luc Préfontaine
I agree with Sean, the STM is a big feature also are parallelism and data immutability. These features are working now
and they make things a lot simpler.
I agree also that the lack of documentation is a barrier but even with documentation the learning curve would
not be much shorter again because the language departs from concepts carried on in most programming languages, not because of it's syntax.
Stuart has written a smart book and that as a starting point is more than enough. Hands-on is required to learn a new language and not just
for academic purposes. Having a real problem to solve is better.
You say that Clojure is a better Java... totally wrong. Java sits where it needs to be, at the bottom of the stack like assemblers in the 70s/80s.
Getting interop with Java is as obvious as being able to call an assembly routine from a higher level language or an external library.
No one would question this ability in other languages. No one wants to rewrite mundane tasks if they are already programmed.
If this makes you think that Clojure is a better Java well that relates to my comments later in this post.
Your statement that Clojure should stand apart from others is deeply wrong. It is already a breed of its own. Borrowing best ideas from
other languages does not mean that the end result is a Babel tower. If you think that Clojure is not well articulated and does not
have it's own personality that also relates to my comments following this paragraph.
You warn that you learn languages "just for the fun of it". I would be curious to know how much time you spent learning Clojure...
I personally worked with Fortran, Cobol, PL/1, Lisp, C/C++, VB, Java, JS and so many other languages to deliver working systems
in production not counting half a dozen assemblers (with systems above 20,000 code lines). Many of these were multi threaded
apps before libthread even existed. Dynamic languages were far more common 20 years ago than now btwy.
We have been working with Clojure for more than a 16 months with a message bus software in production for 11 months.
Not a simple HelloWorld app....
Just to get up to write decent production code with Clojure it took me a good 4 months. I'm a 25 years exp. guy and I have
been writing code and designing systems for that life span. I am not an "educated" manager with grey hairs.
My colleagues are younger and did not do better.
The changes that Clojure brings in the "old" ways we used to program are significantly important to make learning a steep curve
before you can write code that you can read again without shame.
So either you are a genius and went through Clojure faster than we could, learning all the features it offers, or you just skimmed the surface.
I think the later applies and that you have some "toupet" to compare a language with others without any extensive field use of most of them.
Get a few millions lines of code behind you, then you may eventually write decent critics. Meanwhile be humble...
Luc
On Fri, 2009-12-11 at 13:04 -0800, kusi wrote:
http://kusimari.blogspot.com/2009/12/analysing-clojure-programming-language.html
Dmitry Kakurin
Clojure and have managed to get every key point wrong:
> Clojure is a multi-paradigm language
no it's not, and it's most certainty not an OOP language:
http://clojure.org/rationale
> Functional programming finds its best implementation in the homoiconic language family.
very debatable statement
> The attitude of the language [...] is to be a better Java
Clojure's attitude is to be a great language for JVM platform (and
maybe CLR) _other_ than Java. With different set of goals. Granted
it's often _compared_ with Java for obvious reasons.
> one will not appreciate Clojure for being a better LISP. Instead Clojure tries to be a better Java with LISP syntax.
Not sure who the 'one' is. I for one do appreciate Clojure as a better
Lisp :-).
> Owing to the above attitude, many of the language constructs exist so that one can do what Java cannot do
Is Java some kind of "golden standard" in language design now?
> For e.g. tail calls cannot be optimized in the Java
Correction: in current version of JVM
As for tail calls, Clojure has to live with limitations of the target
platform.
> In Clojure this identity is lost, because practical implementation difficulties are put ahead of clean design.
IMHO Clojure has a rather strong and unique identity. Here is my
elevator pitch for Clojure (not any kind of analysis, just what makes
Clojure attractive to ME):
- Lisp dialect designed for JVM with transparent interop
- Better Lisp than Lisp :-) Simpler/cleaner than Common Lisp, more
practical than Scheme.
- Rich immutable collections unified by a concept of sequence
- Unique and intriguing approach to state, identity and concurrency
- Very dedicated and talented author, great community
In general I'd like to second Luc's "be humble" comment. And do your
home work before doing "analysis".
- Dmitry
Laurent PETIT
I just learned (the hard way, by being humble and asking :-) ) on #clojure that one does not say "immutable" collections but "persistent" collections, since "persistent" conveys a lot more information about what Rich has achieved than just saying "immutable".
:-p
- Unique and intriguing approach to state, identity and concurrency
- Very dedicated and talented author, great community
In general I'd like to second Luc's "be humble" comment. And do your
home work before doing "analysis".
- Dmitry
> http://kusimari.blogspot.com/2009/12/analysing-clojure-programming-la...
Richard Newman
> #clojure that one does not say "immutable" collections but
> "persistent" collections, since "persistent" conveys a lot more
> information about what Rich has achieved than just saying "immutable".
Good explanation:
http://en.wikipedia.org/wiki/Persistent_data_structure
Contrast to:
Laurent PETIT
So to be even more precise, we can say that clojure's data structures are "fully" persistent since any older version of the datastructure can still serve as the basis to create new versions.
--
Dmitry Kakurin
to my friends/colleagues when they ask me why am I so excited about
Clojure. I did it many times now and I have quickly learned that
saying "persistent data structures" gets misinterpreted by every
single person as "something you can save to file [as XML/binary]",
i.e. serialization.
So the funny thing is: by changing my tune and being imprecise, I
communicate the basic idea much better now :-).
I do understand and appreciate the difference (and I've watched all
Rich's talks :-) but the term is so overloaded that it usually
misleads "imperative" people. Only later I can introduce and use it by
giving a formal definition first and letting it settle for a while.
And only with people who wants to hear more and cares to learn the
difference :).
- Dmitry
On Dec 17, 12:24 am, Laurent PETIT <laurent.pe...@gmail.com> wrote:
> Thanks Richard for the good link.
>
> So to be even more precise, we can say that clojure's data structures are
> "fully" persistent since any older version of the datastructure can still
> serve as the basis to create new versions.
>
> 2009/12/17 Richard Newman <holyg...@gmail.com>
>
>
>
> > > I just learned (the hard way, by being humble and asking :-) ) on
> > > #clojure that one does not say "immutable" collections but
> > > "persistent" collections, since "persistent" conveys a lot more
> > > information about what Rich has achieved than just saying "immutable".
>
> > Good explanation:
>
> >http://en.wikipedia.org/wiki/Persistent_data_structure
>
> > Contrast to:
>
> >http://en.wikipedia.org/wiki/Immutable_object
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clo...@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+u...@googlegroups.com<clojure%2Bunsu...@googlegroups.com >
Laurent PETIT
Santhosh G R
> curious to know how much time you spent learning Clojure...
I have been working with Scheme for the past 5 years. Yep, I don't
have 20+ years in development; neither 12+ months in Clojure. My
learning of Clojure has been for the past 2-3 months. As I have sent
in my blog post "I am not a clojure developer. I am a programming
language enthusiast". I don't think that disqualifies from expressing
an opinion.
> We have been working with Clojure for more than a 16 months with a
> message bus software in production for 11 months.
> Not a simple HelloWorld app....
To be honest, I have not written complicated software in Clojure. I am
from the industry where dynamic languages/scripts are a no-no. I have
been trying to sell Python and now Clojure, however there never are
any takers. Even amongst the people who are enthusiastic, the fact
that Clojure the community (not the language) expects some kind of
java knowledge makes it a set back. I went through the same pains.
> So either you are a genius and went through Clojure faster than we
> could, learning all the features it offers, or you just skimmed the
> surface.
Neither a genius, nor did I skim through. By the way, isn't Clojure
meant to be a minimalist language which one should be able to pick up
quick!! Does't Clojure expect you to know more about functional/
declarative programming, than the syntax? So why would you need to be
a genius to know the language. My analysis was on the language; not on
the library.
> Meanwhile be humble...
I completely miss this. As I said "I am not a clojure developer. I am
a programming language enthusiast and have learnt multiple languages
with different programming paradigms; just for the fun of it.
Programming languages which I know are Java, Python, Scheme, okie-
dokie PERL, C# which for me is Java with a different library and
idiom, C, C++ including the (in)famous STL, COBOL & FORTRAN purely
because it was in my syllabus, Javascript both in its prototype and
functional forms. I have tried to be unbiased; if it exists it might
be due to my stronger background in Java, Python, Scheme."
Is saying that I learn languages for the fun of it being haughty? Or
saying that my bias exists because of my background in Java, Python,
Scheme being "biased"!!
For me being humble is to appreciate what should be appreciated, and
criticize what should be criticized.
>
> Luc
>
> On Fri, 2009-12-11 at 13:04 -0800, kusi wrote:
> >http://kusimari.blogspot.com/2009/12/analysing-clojure-programming-la...
Santhosh G R
> Clojure and have managed to get every key point wrong:
> > Clojure is a multi-paradigm language
> no it's not, and it's most certainty not an OOP language:http://clojure.org/rationale
I hear about this everywhere. Is Clojure not a multi-paradigm language
because that is the rationale for the language? For me - It supports
functional programming. It supports object orientation, though it does
not support object oriented constructs.
Yep, definitely it does not encourage multiple paradigms, but it
allows you to do so!
> > Functional programming finds its best implementation in the homoiconic language family.
> very debatable statement
Sorry, it should have been "one of the best implementation". In any
case having seen different implementations, I definitely feel drawn
towards homoiconic languages.
> > one will not appreciate Clojure for being a better LISP. Instead Clojure tries to be a better Java with LISP syntax.
> Not sure who the 'one' is. I for one do appreciate Clojure as a better
> Lisp :-).
I would disagree. Anyway in language preferences everything is
debatable. :-)
> > Owing to the above attitude, many of the language constructs exist so that one can do what Java cannot do
> Is Java some kind of "golden standard" in language design now?
If it was a golden standard then I and maybe you would never have
tried to learn anything else.
However, please note that Java is what opened the floodgates. Like
Fyodor Dostoevsky's "we all came from Gogol's overcoat", many of us
came from Java's overcoat.
> In general I'd like to second Luc's "be humble" comment. And do your
> home work before doing "analysis".
Again the same statement about being humble :-(
Santhosh G R
most "humble".
Even though my analysis says otherwise, I am doing the elevator pitch
for Clojure wherever I work. Of course, in an enterprise (where I
work), nobody is going to buy it; but in my own world I use Clojure
more than Python just because I can get back to Scheme!
Martin Coxall
On 17 Dec 2009, at 10:04, Dmitry Kakurin wrote:
> Please keep in mind that it is almost literally the speech that I give
> to my friends/colleagues when they ask me why am I so excited about
> Clojure. I did it many times now and I have quickly learned that
> saying "persistent data structures" gets misinterpreted by every
> single person as "something you can save to file [as XML/binary]",
> i.e. serialization.
> So the funny thing is: by changing my tune and being imprecise, I
> communicate the basic idea much better now :-).
I note that Haskellers don't refer to their data structures as "persistent", despite the fact that lazy evaluation means they get persistence of all data structures 'for free'.
They seem to use the rather vague "purely functional data structure".
Martin
Rich Hickey
There are differences in strictness in the interpretation of
"persistent". At the most basic, it just means creating a "changed"
version leaves the old version intact. But, if you use amortization in
your analysis of the cost model for the data structure, then many such
purely-functional data structures do not maintain their performance
bounds when used in a non-ephemeral, i.e. persistent way. This latter
characteristic does not come for free merely via immutability or
laziness.
The use of the term persistent for Clojure data structures is the
stricter sense, both that old versions are unchanged and available
*and* that performance guarantees are met when used persistently.
See:
Purely Functional Data Structures - Okasaki
for details.
Rich
Alex Osborne
>> > Clojure is a multi-paradigm language
>> no it's not, and it's most certainty not an OOP language:http://clojure.org/rationale
>
> I hear about this everywhere. Is Clojure not a multi-paradigm language
> because that is the rationale for the language? For me - It supports
> functional programming. It supports object orientation, though it does
> not support object oriented constructs.
Clojure's Wikipedia article calls it multi-paradigm, which may be partly
where the confusion is coming from. Funnily enough Wikipedia also claims
Java is multi-paradigm, having the four paradigms: generic, reflective,
imperative and object-oriented. I wouldn't call this multi-paradigm as
these four things are mostly orthogonal and don't really constitute
different programming styles.
> Yep, definitely it does not encourage multiple paradigms, but it
> allows you to do so!
You can do object-orientation in C (see GObject), does that make it an
object-oriented language? If so than every language is "multi-paradigm"
so the word is meaningless. ;-)
In my mind the difference between a multi-paradigm language and one that
is not is about what is idiomatic, rather than what is and is not
possible, as the latter always reduces to a Turing-completeness style
argument. Classic examples of multi-paradigm languages are Common Lisp,
Scala and Perl. Clojure is certainly not multi-paradigm in the same
sense that these languages are. Clojure has a very strong style of its
own, which is definitely not imperative or object-oriented but neither
is it purely functional, but just because it doesn't fit perfectly into
one of the traditional categories doesn't make it's multi-paradigm.
Of course that's just my interpretation. :-)
ajay gopalakrishnan
Good to know that this newbie (myself) is on the right track!
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@googlegroups.com
Mike Meyer
Santhosh G R <kusi...@gmail.com> wrote:
> > You warn that you learn languages "just for the fun of it". I would be
> > curious to know how much time you spent learning Clojure...
>
> I have been working with Scheme for the past 5 years.
I think this is a critical element!
> Yep, I don't have 20+ years in development; neither 12+ months in
> Clojure. My learning of Clojure has been for the past 2-3 months.
I expect that 5 years with Scheme is worth more than 20+ years with
C/C++/Java when it comes to learning Clojure. Clojure is, after all, a
LISP dialect. Once you've gotten your mind around the proper way to
write programs in LISPy languages - which is a non-trivial thing -
adopting to another one is fairly easy. I feel that mind-set coming
back after my absence from the language as I read through the
examples. The other unique features of Clojure should be relatively
straightforward to deal with once you've gotten past this.
> > So either you are a genius and went through Clojure faster than we
> > could, learning all the features it offers, or you just skimmed the
> > surface.
> Neither a genius, nor did I skim through.
Right. Just someone who was already familiar with programming in a
LISPy environment.
> I completely miss this. As I said "I am not a clojure developer. I am
> a programming language enthusiast and have learnt multiple languages
> with different programming paradigms; just for the fun of it.
> Programming languages which I know are Java, Python, Scheme, okie-
> dokie PERL, C# which for me is Java with a different library and
> idiom, C, C++ including the (in)famous STL, COBOL & FORTRAN purely
> because it was in my syllabus, Javascript both in its prototype and
> functional forms. I have tried to be unbiased; if it exists it might
> be due to my stronger background in Java, Python, Scheme."
Given that list of languages, I'd suggest taking a look at
Eiffel. It's imperative and statically typed, but it's a lot saner
than the C++/C#/Java languages. It has a high mechanism for dealing
with concurrency that make an interesting contrast to STM. It's the
source of the function pre/post condition facilities that Clojure has.
<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
Eric Lavigne
> It's the source of the function pre/post condition facilities that Clojure has.
I did not know that Clojure functions supported Eiffel-style pre/post
conditions. Where can I read more about this?
Sean Devlin
Eric Lavigne
Luc Préfontaine
Choosing a Lisp like syntax for a new language is a good choice because of the expressiveness,
it requires less code lines, yields a better design, easier to test, ... That's a choice between a number of options.
If it was the only sane one then we would all be coding using Lisp like syntax. That's not the case
obviously. Talk to Ruby people, they made different choices...
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.
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.
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).
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.
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.
Syntax by itself is nothing, it never made a good language implementation.
I have a few years of Lisp behind me, I started to use Lisp in the 1980s.I used to prototype software in Lisp that I had to deliver
in a more "classical" language. The main reason of this being the lack of basic librairies and incompatible Lisp implementations plus
the maintenance issue.
After my Clojure learning curve, I removed LispWorks from my desktop. I do not see the use for it anymore.
My 25 years of experience is not the same as "5 years" of Scheme, I experimented more stuff in software
in various environments than the majority of today's average developer.
I adhere to justified critics when a rationale has been exposed otherwise I call it (repeat "blablabla").
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.
The above does not mean that I will not ever critic Rich's bad decisions in the future. I do not see this likely to happen
however given its present score...
Luc
Dmitry Kakurin
> Again the same statement about being humble :-(
The "humble" comment relates to the title of your article.
Lookup (and contrast) words "analysis" and "opinion" in your favorite
dictionary.
Were your post named "My opinion about Clojure" I would not make the
"humble" comment - everyone is entitled to their opinions.
- Dmitry
Mike Meyer
Luc Préfontaine <lprefo...@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.
Martin Coxall
On 18 Dec 2009, at 06:42, Mike Meyer <mwm-keyword-goo...@mired.org
> wrote:
> On Fri, 18 Dec 2009 00:44:02 -0500
> Luc Préfontaine <lprefo...@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.
That's the price Clojure pays for S-exprs rather than using M-exprs or
even Dylan-exprs.
Clojure quacks like a lisp.
Martin
Santhosh G R
> dictionary.
Being a blog I thought that analysis would be from my perspective and
hence an opinion. Dictionaries become muddied in the blog world, and
mea culpa. If nothing else, at least I will make sure that I am
careful :-)