On 6 September 2015 at 15:38, Timothy Baldridge <tbaldri...@gmail.com>
wrote:
> >> I'm not sure why you think that it "complicates the code, and makes it
> harder to understand".
>
> Alright, I'll use the phrase: using vectors as variants complects order
> with data. If you hand me a vector that says [:name "tim"] I have to know
> that "the first thing in this vector is the name of the thing, the second
> thing is the value of the thing". In addition, I have to know that you
> passed me a variant. But if you simply passed me either #my.app.Name["tim"]
> or #my.app.Variant{:key :name :value "tim"} I can programmatically
> deconstruct that value into something usable by my system.
>
How? What can your program reasonably infer from that? If you remove the
semantic information from your examples (which is only meaningful to
humans), you get:
#xxx.yyy["zzz"]
#xxx.yyy{:aaa :www, :bbb "zzz"}
What does that allow us to programmatically infer? That the type is
"xxx.yyy" and that it may contain strings and keywords, but that's about
it. What good is that?
If the type satisfies known protocols, then you have more information, but
if you don't use polymorphism the only benefit is that you know the type,
which is almost meaningless by itself.
In fact, one could argue that it hampers programmatic analysis if you're
using maps. For instance, if you have a variant to set an expiry date:
[:cache/expires #inst "2016-01-01T00:00:00.000Z"]
Then you can fold this into a map:
{:cache/resource #url "http://example.com/foo";
:cache/expires #inst "2016-01-01T00:00:00.000Z"}
If you use a custom type instead of a variant:
#cache/Expires [#inst "2016-01-01T00:00:00.000Z"]
Then the software can no longer infer that this is related to the key on
the map.
I also disagree that variants "complect order with data". By that logic, a
coordinate of:
[4 3]
Should be better expressed as:
#coord2d {:x 4, :y 3}
And a function like:
(swap! a inc)
Should be expressed as:
(swap! :atom a, :function inc)
Keywords have their place, but I don't think using positional indexes to
look up data is necessarily bad, assuming that the vector or list is very
small.
It's worth noting that Datomic uses vectors to represent transactions,
rather than maps or records, so presumably Rich and the other folks at
Cognitect are not above using positional indexing in certain cases.
> As far as performance goes, this is normally the sort of thing that gets
> baked into an app at a pretty low level, that's why I suggest it should be
> as fast as possible. If you're going to be processing millions of these
> things during the life of an app, and transforming them from one format to
> another, a little tweaking here and there may save you some pain in the
> end.
>
I was curious as to whether records really were faster than a vector
lookup. It turns out that vectors are faster:
=> (defrecord Foo [x y])
user.Foo
=> (let [f (->Foo 1 2)] (quick-bench (:x f)))
Execution time mean : 6.592069 ns
=> (let [f [1 2]] (quick-bench (f 0)))
Execution time mean : 4.758705 ns
=> (let [f [1 2]] (quick-bench (let [[x y] f] (+ x y))))
Execution time mean : 19.388727 ns
=> (let [f (->Foo 1 2)] (quick-bench (let [{:keys [x y]} f] (+ x y))))
Execution time mean : 68.845332 ns
That said, a core.match is still going to be slower than a protocol lookup,
so depending on your use-case using a record might still be quicker, but in
terms of actually pulling information out, vectors are quicker.
- James
--
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
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
