Stefan Kamphausen <ska2...@googlemail.com> writes:
>> I don't think the documentation is *wrong* per se, it just only seems to
>> cover the immutable types.
>
> Which is kind of wrong, isn't it? I strongly believe that this should
> be changed.
Indeed.
> While I understand that the mutating functions will not apply to
> immutable types, I don't get why I can't create the metadata using the
> same interface.
Because the two operations have completely different semantics. With
immutables a new object is created, with mutables an existing object is
changed. Clojure could hide this behind the same function name, but
you'd still need to know the distinction anyway to work with these two
types of objects. Clojure makes this explicit. See what I say below on
Rich's avoidance of "apparent simplicity but hidden complexity".
> 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
Both are immutable, thus symbols can have metadata (as you can have two
symbols that differ only by their metadata) but keywords can't, as two
keywords with the same name are the same object.
>> 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)
As it becomes:
(meta (quote greet)) ; <-- this greet symbol has metadata
> This is subtle! It really feels like one of those things that will
> still feel creepy another 50 years from now.
> I'll have to meditate on this a bit.
Clojure is a very opinionated language and one of those opinions is that
Rich tries very hard to avoid incidental complexity. 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.
It's possible and perhaps should even be expected for most Clojure
programmers to have a good understanding of how things work underneath.
With other languages, even if I've been using them for years I still
have little clue about how things actually get evaluated. If I've taken
a course in compiler writing, I might know about things like abstract
syntax trees, parsers and lexers and all the special cases involved in
parsing if-then-else statements, but how it works in a particular
language is going to be a mystery unless I've written my own compiler.
As Meikel suggested, watch Rich's talks. I think it's important to try
to understand the philosophy behind Clojure's design. Rich has some
very strong messages and even if you don't agree with them, they're
definitely worth listening to and thinking about.
Cheers,
Alex
--
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
