Have you already switched from CL or Scheme to Clojure?


If you did, why?


If not, why not?

Javier schrieb:
> Have you already switched from CL or Scheme to Clojure?
>> If you did, why?

Yes.
I did it because it increases my productivity.
There is IMO not one single extremly important reason for that, but the
complete package, of sometimes only small things.
It begins with having only one namespace. This makes much sense for a
functional programming language, as Kent Pitman explains in one of his
essays.
Regarding this check:
http://groups.google.de/group/ruby-t...789460e5c77114

The little nice reader macros for Vectors and Hashmaps, wonderful.
Having when-not instead of unless is worth a million! As a non native
speaker "when-not" sounds a million times more familiar to me, and in
all my (six) CL years I always read (unless ...) aloud as (when-not ..).
Some weeks ago I posted other reasons. And you can find a more complete
list here:
http://www.youtube.com/watch?v=Aoeav_T1ARU&fmt=18
(1 out of 10 videos, each around 8 minutes, english language)



André

André Thieme escribió:
> Javier schrieb:
>
> Yes.
> I did it because it increases my productivity.
> There is IMO not one single extremly important reason for that, but the
> complete package, of sometimes only small things.
> It begins with having only one namespace. This makes much sense for a
> functional programming language, as Kent Pitman explains in one of his
> essays.
> Regarding this check:
> [..]


Oh, it is the famous William James. Please let me reproduce the text here:

-----8<--------8<-------8<------
Commune Lisp code is incredibly bloated, inelegant, and ugly.
Those who use it seem to delight in writing 10 lines of code
when 1 line should do.

Those who use it have no taste.

Bernard Lang:

Common Lisp did kill Lisp. Period.

(just languages take a long time dying ...)

It is to Lisp what C++ is to C. A monstrosity that totally ignores
the basics of language design, simplicity and orthogonality to begin
with.

Gilles Kahn:

To this day I have not forgotten that Common Lisp killed Lisp, and
forced us to abandon a perfectly good system, LeLisp.

Paul Graham, May 2001:

A hacker's language is terse and hackable. Common Lisp is not.

The good news is, it's not Lisp that sucks, but Common Lisp.

Jeffrey M. Jacobs:

Common LISP is the PL/I of Lisps. Too big and
too incomprehensible, with no examiniation of the real world of
software engineering.

.... The CL effort resembles a bunch of spoiled children,
each insisting "include my feature or I'll pull out, and then we'll all
go down the tubes". Everybody had vested interests, both financial
and emotional.

CL is a nightmare; it has effectively killed LISP development in this
country. It is not commercially viable and has virtually no future
outside of the traditional academic/defense/research arena.

Dick Gabriel:

Common Lisp is a significantly ugly language. If Guy and I had been
locked in a room, you can bet it wouldn't have turned out like that.

Having separate "value cells" and "function cells" (to use the "street
language" way of saying it) was one of the most unfortuanate issues.
We did not want to break pre-existing programs that had a global
variable named "foo" and a global function named "foo" that were
distinct. We at Symbolics were forced to insist on this, in the face
of everyone's knowing that it was not what we would have done absent
compatibility constraints. It's hard for me to remember all the
specific things like this, but if we had had fewer compatibility
issues, I think it would have come out looking more like Scheme in
general. --- Daniel Weinreb, 24 Feb 2003

I have found that the disciples of Commune Lisp (CL) are literally
that---disciples. They are completely irrational in their
religious devotion to the language. I suspect that to them,
CL stands for the name of their god: Commode Lord.

If you want to use a Lisp, I suggest Clojure.

-----8<--------8<-------8<------


>
> The little nice reader macros for Vectors and Hashmaps, wonderful.
> Having when-not instead of unless is worth a million! As a non native
> speaker "when-not" sounds a million times more familiar to me, and in
> all my (six) CL years I always read (unless ...) aloud as (when-not ..).
> Some weeks ago I posted other reasons. And you can find a more complete
> list here:
> [..]
> (1 out of 10 videos, each around 8 minutes, english language)

Apart from this videos and the wiki on clojure.org, is there any serious
free book I can read in order to fully learn and understand Clojure?

On Mar 7, 11:16 pm, Javier <javu> wrote:

[regurgitation of ruby-guy noise mercifully snipped]

>
> is there any serious
> free book I can read in order to fully learn and understand Clojure?

If you were really serious, you wouldn't insist on free.

There's Programming Clojure, by Stuart Holloway, but he's <gasp!>
actually asking to be paid for his work:
<http://www.pragprog.com/titles/shcloj/programming-clojure>

Raffael Cavallaro escribió:
> On Mar 7, 11:16 pm, Javier <javu> wrote:
>
> [regurgitation of ruby-guy noise mercifully snipped]
>
>> is there any serious
>> free book I can read in order to fully learn and understand Clojure?
>
> If you were really serious, you wouldn't insist on free.
>
> There's Programming Clojure, by Stuart Holloway, but he's <gasp!>
> actually asking to be paid for his work:
> <http://www.pragprog.com/titles/shcloj/programming-clojure>
>

You're right, I'm not serious, I only intend to have fun for the moment,
but looking for a "serious" free book, which is a different thing.

So all right, I change the question, is there any good free book,
serious or not, about Clojure?

On Mar 8, 1:24 am, Javier <javu> wrote:
> Have you already switched from CL or Scheme to Clojure?

No

>
> If you did, why?
>
> If not, why not?

Too many things lacking at the language level and no significant
advantages library wise. The JVM and threading niceties are not a
concern for me right now and I think this is the only relative
competitive advantage.

Cheers

On Mar 8, 8:54 am, Javier <javu> wrote:
> So all right, I change the question, is there any good free book,
> serious or not, about Clojure?

You might find the following link interesting (even if it's not a
book):
http://www.ociweb.com/mark/clojure/article.html

Cheers,

Carlos

On Mar 8, 12:54 am, Javier <javu> wrote:
> So all right, I change the question, is there any good free book,
> serious or not, about Clojure?

Here's the free and good one: http://ociweb.com/jnb/jnbMar2009.html

On Mar 8, 1:10 am, Marco Antoniotti <marc> wrote:
> Too many things lacking at the language level

Care to elaborate ?

Vagif Verdi schrieb:
> On Mar 8, 1:10 am, Marco Antoniotti <marc> wrote:
>> Too many things lacking at the language level
>
> Care to elaborate ?

I suppose he means something like defstruct and defclass, plus the
metaobject protocol. So, built in mechanisms for oop.
Also he may mean: lack of reader macros and some few macro special ops,
such as symbol-macrolet.
I personally see it as a strong advantage of not having built-in support
for OOP. I like that Clojure concentrates more on functional programming.
OOP had enough years, now functional programming has its turn.
Concentrating on a main paradigm can produce more compatible code, and
will make it easier for teams to work together.

Not having (user definable) reader macros.. well, I would like to have
them, but can understand that they may do more harm than good.


André

Javier <javuchi> writes:

> So all right, I change the question, is there any good free book,
> serious or not, about Clojure?

Have you tried http://clojure.org/ yet? On the left bar, there's a
section called "Reference." The first chapter is "Getting started".
The remaining chapter cover the language, written by the author of the
language. Does that work for you?

On Mar 8, 7:21 pm, André Thieme <address.good.until.
2009.may...@justmail.de> wrote:
[..]
> OOP had enough years, now functional programming has its turn.
> Concentrating on a main paradigm can produce more compatible code, and
> will make it easier for teams to work together.
>
> Not having (user definable) reader macros.. well, I would like to have
> them, but can understand that they may do more harm than good.
>
> André
> --
> Lisp is not dead. It’s just the URL that has changed:[..]

Funny, that you see absence of such a powerful think like CLOS an
advantage because it's "OOP" (albeit the best OO system used in
practice), and with the same breath you don't mind buying Java
libraries "advantage" and Java interop (main selling point of
Clojure), not bothering that it's built on the very most crippled
"object" system ever designed.

neptundancer schrieb:
> On Mar 8, 7:21 pm, André Thieme <address.good.until.
> 2009.may...@justmail.de> wrote:
>
> Funny, that you see absence of such a powerful think like CLOS an
> advantage because it's "OOP" (albeit the best OO system used in
> practice), and with the same breath you don't mind buying Java
> libraries "advantage" and Java interop (main selling point of
> Clojure), not bothering that it's built on the very most crippled
> "object" system ever designed.

Yes, again criticism of one of those experts who never even wrote
a single line of Clojure code, great.
I smell the turing argument here, which makes no sense.
You know that under the hood all is machine language, yes?
Zeros and Ones.
Many Java libs get more testing each year than all CL libs
together since they began to exist. I don’t care at all if those
people implemented it in Java, Delphi or Assembler.
Fact is, those libs are there. They are usable, mature and have
several orders of magnitude more testing than all of what CL
ever had.

The Java stuff is used in Clojure nearly exclusively to communicate
with the world. Reading/writing data from/to disk, network, DB, etc.
It’s not typical that you run into oop from the Java world when you
write Clojure programs. Of course, you can’t know this since you
don’t know much about Clojure. Just enough to feel the need to post
here.


If there were an oop mechanism built in into Clojure then some people
would give oop solutions while other would follow the route that makes
more sense, i.e. the functional route. That would lead to more
incompatibility. In CL you ask ten people to solve a problem and you’ll
get eleven solutions. All incompatible to each other. That just makes
not much sense.
CLOS just was not fit enough to become more popular. I don’t want to
talk about better/worse, as this is very subjective. But obviously it
was not fit, in an evolutionary way.
We CLers (many of us, yes, including me) tried for years to put lipstick
on the pig. We tried to rationalize every time when someone said:
„Hey, if CL is that good, why are not more people using it”.
It’s nearly 2010 and we should realize that it simply is not that good.

Try out Clojure. Work a few months with it, write a few hundred or
thousand LOC and report were/if you truly miss oop.


André

A couple of things I'm wondering about clojure?

1. Is the fact that CLOS is missing intentional? I.e., do you want to
prevent it being added? or is it more a matter of priority? And does
the architecture of clojure prevent its being added later?

2. Clojure seems to be missing some powerful lambda list specification
facilities which other lisps have such as &key and &optional. It
seems like users are responsible to boilerplate these capabilities out
of the existing & (basically an &rest). How can I do the equivalent
of (apply fun 1 2 3 others) in clojure?

3. The recure construct seems interesting but quite incomplete. Maybe
it is a limitation of java, but wouldn't tail call optimization
actually be much more useful that tail recursion? Tail-recursion
would then simply be a special case. Tail calls occur in every
function, but recursion in only a few.

4. I did not see anything about backquote, comma, and commat-at.
Macros would be possible but pretty difficult without them (maybe I
just overlooked them). And doesn't having to deal with vectors and
lists make macros again more difficult. In other lisps, the fact that
the lambda list and the local bindings inside the LET are represented
as lists, makes them it easy to manipulate in macros. Do we loose
that simplicity with clojure?

5. Having a <small> language sounds like it has some nice advantages
but only if users can add libraries which look native. Having macros
seems to enable this, but I wonder how possible it really is to extend
the language at the application level? Maybe I'm wrong but the
feeling I get is that the language has been intentionally designed to
be restrictive rather than liberating in order to make it interface
well with Java. If that is the case then there are indeed some
advantages, but it is sad at the same time. :-( Maybe I'm wrong? I
hope so.

-jim

> > Funny, that you see absence of such a powerful think like CLOS an
>
> Yes, again criticism of one of those experts who never even wrote
> a single line of Clojure code, great.
> I smell the turing argument here, which makes no sense.
> You know that under the hood all is machine language, yes?
> Zeros and Ones.
> Many Java libs get more testing each year than all CL libs
> together since they began to exist. I don’t care at all if those
> people implemented it in Java, Delphi or Assembler.
> Fact is, those libs are there. They are usable, mature and have
> several orders of magnitude more testing than all of what CL
> ever had.
>
I worked for Java shop. You wouldn't believe how many troubles and
surprises wait behind almost every corner when you want to do
something a bit different than written in manual. Never again.

> CLOS just was not fit enough to become more popular.
Great. Let's buy all Britney Spears now! A man is intelligent. A mass
of people is as much intelligent as the loudest of them. Popularity of
Java is mostly because of marketing targeted at management, not
because of quality.

> Try out Clojure. Work a few months with it, write a few hundred or
> thousand LOC and report were/if you truly miss oop.
>
I program daily in Erlang for years. I know a bit about functional
programming and also about concurrent programming. I don't think
Clojure has the right approach to concurrency.