After proper Scheme training (CS61A) Clojure looks awkward and messy but very useful, as it supposed to be due to its "productivity beats clarity/conciseness" philosophy of scripting languages, such as Ruby.
After proper Scheme training (CS61A) Clojure looks awkward and messy but very useful, as it supposed to be due to its "productivity beats clarity/conciseness" philosophy of scripting languages, such as Ruby.
The old CS61A course, of which I am huge fan, taught you the very important idea that all you need is lambda as Brian Harvey put it himself.)
The meaning is quite profound. First of all, the notion that everything could be written using just procedure calls (we will not talk about Lambda Calculus here) few special forms and list notation, which goes back to John McCarthy is the great one, and Scheme, therefore, is a result of polishing this idea.
Second very important idea related to the first - all the fundamental ideas and techniques in programming one should learn and internalize, could be easily and elegantly expressed in Scheme. This is why it was a language of choice for teaching CS. Even if it lacks some features, such as advanced module system or OO capabilities, but they teach you how easily it could be implemented, and that it is of second importance.
So, if I am promoting something here it is these realizations from Brian Harvey, and for me Clojure is something very opposite, a mess and hype and unjustified rhetoric, claiming that it is superior to something much more great and profound.
And it is not an empty pose. Even playing with its repl will teach you that it is full of special cases you must learn and know, that if something is printed as a list it might be not, that behavior of a function depends on what data-structure is given as its argument and so on. I'm also not sure that collections is such a great idea.
It's perfectly fine to not like a language, but it's inappropriate to be so over the top with it as to post in, quite literally, every story about that language.
The examples of well-chosen set of basics is Scheme R4RS, or pg's Arc. The examples of so-called natural selection are CL (an attempt to put together the best ideas and syntactic sugar from various implementations) and, surprise! Haskell, which is a product of a merge of efforts of ML/Lazy languages world.
On the other hand, there are languages created by one individual, according their own preferences, such as Perl, Ruby and Clojure.
Ruby, for example, it is a mix of features from Perl and Smalltalk, its author liked, but, of course, the resulting language is neither a dialect of Perl or Smalltalk. It is a language of its own.
Similarly, Clojure is a mix of features from various languages, notable Common Lisp, Smalltalk, ML, plus various Python-like comprehensions for vectors or hashmaps.
There are many other clever tricks, like simplified pattern matching, at the cost of sacrificing uniformity and announcing vectors as parameter lists for binding constructs, apparently from ML, and multi-method function declarations, also from ML.
The result is a language of its own, and cannot be called a Lisp, the same way Ruby cannot be called Smalltalk. The design decisions, while mostly clever, broke the uniformity and clarity of classic Lisps.
So, in my opinion, Clojure is closer to Ruby in its ideology, than to Lisp.
> After proper Scheme training (CS61A) Clojure looks awkward and messy but very useful, as it supposed to be due to its "productivity beats clarity/conciseness" philosophy of scripting languages, such as Ruby.
As someone with "proper Scheme training" (CS61A), I've found that Clojure is actually much more clear than Scheme in most cases. The code is less beautiful from a purely visual perspective because there is more syntax, but a lot of complexity gets removed when you add literals for sets, vectors, and maps.
E.g. (defn name [arg1 arg2] body). Lists are not the alpha and omega like they are in LISPs.
But I agree it has "every single characteristic that defines a lisp", even if it looks funny to experienced Lispers like myself.
Aesthetically I much prefer standard LISP syntax + indentation , but 100% support the use of literals for the non-list data structures. Many disagree on the syntax, and if no longer having a sea of pure parens brings more adaptation I'm willing to live with it. I got the impression the syntax changes were due to that reason vs. inspiration from ML, but I'm not at all sure about that. Still, Rich Hickey is an experienced Lisper with exquisite taste below the level of syntax, so I'm pretty sure he was aware of the implications of his syntax changes.
EDIT: "Criticise" is clearly the wrong word, since your description isn't perjorative. "Distinguish" would be better.
However, while I could make such a choice in CL, or modify Clojure, the standard including indentation for such a fundamental part of a language is controlling, and if I want to be part of the community I have to follow it.
Don't take me wrong, making the other collections syntactically first class and unifying them under the Seq abstraction is a really good thing, in fact when I appreciated that it was the first thing that got me really excited about Clojure, especially Clojure as "the next Lisp". But personally, if just for myself, I would have kept the vectors out of the syntax and depended on indentation in smart editors.
There are several types of first class syntax in Lisp: http://amitp.blogspot.com/2007/04/lisp-vs-python-syntax.html
I don't see how a definition of "Lisp" that excludes Common Lisp is useful. How do you find this definition useful? You bring it up with remarkable regularity when Clojure is mentioned, presumably you find some value in it?
Occasionally, a pragmatist like Hickey comes along and says "hey look how useful this can be". Another generation of programmers takes a look at Lisp. Where will it go this time?Can Lisp be saved from the Lispers?
OP clearly hasn't hacked on any Common Lisp written by a CLOS-maniac.
Schemers break out in hives if they couldn't implement their own language on a raspberry pi in a single drunken bender.