On Thursday, July 19, 2018 at 10:04:39 AM UTC-5, Benoît Fleury wrote:
>
> I agree with Alex. It is important to understand the rationale behind the
> behavior of conj. conj is for adding an element to a collection. It doesn't
> say anything about ordering. It has been chosen as an operation, as
> opposed to append/prepend, because it can be implemented with the
> same time complexity for a lot of data structures.
>
>
Yes and that's important for real hardcore work. But beginners don't
necessarily need to be burdened with complexity
concerns immediately. Eventually yes but not immediately. And it really
does has to be hardcore before
that matters...otherwise Python wouldn't be taking over the world and
running strong for 20+ years.
> To convince myself that time complexity mattered in programming, I take
> the example of a stack. If you give me an implementation of a stack that
> push and pop items in linear time, I will write very inefficient programs
> very quickly. To the point of not working at all. So it makes sense to me
> that space/time complexity should be part of the signature of an operation.
>
See above.
>
> Now, I think the problem here comes from the fact that we have a tendency
> to infer the semantic of an operation from its behavior on certain types.
> We
> see that (conj [1 2] 3) returns [1 2 3] so we conclude that conj is for
> adding
> an item at the end of a collection. And then we get surprised when the
> behavior is "different" for other types. As Clojure programmers, it is
> something
> we need to be careful about and make sure we understand the actual
> semantic of the operations.
>
> However, I think it is easier said than done. I would be ready to bet that
> a
> lot of Clojure programs rely on the fact that conj *appends* to a vector or
> *prepends* to a list. I agree that it is problematic. First, it makes the
> understanding of the code harder because you need to remember the behavior
> of conj on each type. And it prevents the implementation of conj to change
> because so many programs rely on implementation details. But to all expert
> Clojure programmers here, can you honestly think about what mental model
> you
> use when using conj on vectors and lists? Are you really thinking: I'm
> adding
> this element to this collection. I don't really care where it ends up :) ?
>
> So my questions are:
>
> 1. Am I wrong in thinking that most Clojure programmers use append/prepend
> as mental models for the different implementations of conj?
>
> 2. Am I wrong in thinking that they shouldn't?
>
> 3. And if I'm not wrong, how could we make it easier for programmers to
> make
> sure they code against the semantic of an operation and not its
> implementation
> details? Is there methods, tools or tests that could help us with that?
>
>>
>>
My suggestion is to just use the natural polymorphic comb-ining function
below until performance
is an issue. At that point students will be motivated to learn about
complexity....
(defn comb [& args]
(let [comb_ (apply concat args)]
(cond (string? (first args)) (apply str comb_)
(vector? (first args)) (into [] comb_)
(list? (first args)) comb_)))
(prn (comb [1 2] [3 4]))
(prn (comb '(1 2) '(3 4)))
(prn (comb [1 2] [3 4] '(5 6)))
(prn (comb '(1 2) '(3 4) [5 6]))
(prn (comb "abc" "def" "ghi"))
gives this...
[1 2 3 4]
(1 2 3 4)
[1 2 3 4 5 6]
(1 2 3 4 5 6)
"abcdefghi"
--
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.
