Hi,
On Nov 27, 11:06 pm, "Alex Osborne" <a...@meshy.org> wrote:
> > A *new* symbol? I would have thought I'm getting the original symbol
> > again.
>
> Yes, one of the differences between symbols and keywords is that symbols
> are created fresh each time while keywords are interned:
>
> (identical? 'foo 'foo) ; => false
> (identical? :foo :foo) ; => true
Whoa! Cool example. This is rather an important point, I think. I
mean it's not important, when your "only" programming with Clojure,
which will usally work, and you always have the REPL... But it
becomes more important for those, trying to understand. It's about
grokking a language's design vs. experimenting with the code long
enough so that it seems to work.
> >> Note that (perhaps suprisingly) this doesn't work:
>
> >> (meta #^{:a 1} 'greet)
>
> Perhaps I should also note that this *does* work:
>
> (meta '#^{a 1} greet)
To be honest, I think it looks even worse. There is some reader macro
which by happy accident works in a certain way together with the other
read syntax. No, I don't think it should work.
> Clojure is a very opinionated language and one of those opinions is that
> Rich tries very hard to avoid incidental complexity.
Which is a Good Idea(tm).
> At times this
> means things may at first appear more complex on the surface than in
> other languages, but this is because Clojure isn't trying to hide what's
> going on under the hood from you. It's one of the things I really enjoy
> about it: there's no "magic". Clojure simplicity is real simplicity,
> not apparent simplicity created by hiding the complexity under the bed.
Hm, is it possible you're coming from Java here? For me, coming more
from CL than Java, some things in Clojure feel very --let's say--
Perlish: there is so much syntax there. Don't get me wrong, I think
Clojure delivers what arc promised, it does a hell of a job
revolutionizing Lisp. I hardly can disagree with many of the design
principles, I just like the documentation to tell the whole story so
not everyone new to Clojure will have to figure it out for him/
herself.
> It's possible and perhaps should even be expected for most Clojure
> programmers to have a good understanding of how things work underneath.
Agreed. The docs should say so, agreed? I'd very much like to
volunteer on docs, but I just don't know how I could keep up with
development, since I am doing almost all my Clojure stuff after work
when the children are in bed.
> With other languages, even if I've been using them for years I still
> have little clue about how things actually get evaluated.
That may be related to the lesser importance of order of evaluation in
other languages. I mean, Perl has a *lot* of syntax, but usually it
all takes place at the same time, or at least, you as a developer
won't have to care. Anyway, not worth a discussion.
> As Meikel suggested, watch Rich's talks.
I do, and I really like them. One can hear, that Rich's got a story
to tell. They are very valuable for understanding the philosophy
behind many of Clojure's design decisions. The screencast/
presentation/video-thing helps learning a new language nowadays.
> I think it's important to try to understand the philosophy behind Clojure's
> design.
Wait, I've heard that before... Deja vu?
> Rich has some
> very strong messages and even if you don't agree with them, they're
> definitely worth listening to and thinking about.
There, another Deja vu. ;-)
Alex, John, Meikel, Richard,
thanks for taking your time.
Kind regards,
Stefan
--
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
