Hey everyone!
I've just released a new version of my library for testing stateful systems
with test.check!
[org.clojars.czan/stateful-check "0.3.1"]
https://github.com/czan/stateful-check
https://clojars.org/org.clojars.czan/stateful-check
Changes in this version:
+ :real/setup and :re
We've been seeing a lot of "out of office" replies on mailings for the Conj
CFP, so we've pushed back the deadline one week to Aug 21st. We'd love to
have submissions about Clojure, ClojureScript, libraries, tool, experience
reports, etc!
https://cognitect.wufoo.com/forms/clojureconj-2015-call-for
Default laziness can cause problems, but I'm not sure that they're bad
problems, necessarily. I think 'opt-out' laziness (and the headaches it can
cause) push people--especially people coming from non-FP backgrounds--to
really zero in on writing pure, focused functions.
On the other hand, from
I must agree with Lee that, IMHO, default laziness can cause unexpected
problems. I would argue that it violates the Principle of Least Surprise.
A better way would be to make laziness optional and explicit, perhaps by
adding a "z" suffix to the lazy version of each function (e.g. map -> mapz,
for
Thanks Sebastian for the thoughtful and helpful document! I like it and have
shared it with my group.
> On Aug 13, 2015, at 1:51 PM, Sebastian Bensusan wrote:
>
>
> I never thought of laziness! It's a good point. Retroactively I might add it
> to the Functional Style section :)
You did a n
Hi John,
Thanks for the heads up, I clearly didn't push the changes.
When it comes to dependencies, I find that from the user's perspective,
they are not desirable:
1. They might conflict with other modules (i.e., lein deps :tree can be a
little hell of its own).
2. They increase the size of you
Wait. If a module has dependencies, that's usually a *good* thing --- it
hopefully does one thing well, and doesn't reinvent the wheel.
Also, the article online still reads, "Does it have many dependencies?"
By the way, I enjoyed the article. Thanks! I liked the short pithy
sentences you wrote
Dave Tenny writes:
Hi Dave,
> At issue (for me), keyword arguments and maps that bundle them.
>
> user> (defn foo [a b & {:keys [c d]}]
> [a b c d])
> #'user/foo
> user> (defn bar [a b & {:keys [c d] :as options}]
> (println (apply foo a b options)))
> #'user/bar
> user> (bar 1 2
Hi Chris,
I agree that concurrency is "one useful consequence". I tried to explain
all the benefits of immutability in previous drafts and failed miserably.
It's something that comes after "enlightenment". That's why I ended up
explaining immutability only through very practical terms. On "how is
Could you use something like Redis? Use hashes as keys, fake immutability
by 'popping' kv pairs and inserting new ones keyed to the (presumably
different) hash of the updated map.
On Thursday, August 13, 2015 at 7:52:06 AM UTC-4, Christian Weilbach wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
Not to my knowledge but could be I suppose.
--
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 unsu
These inconsistencies are bugging me, I just wondered if I was missing some
standard language thing about argument passing or destructuring, so I'm
looking for comments.
At issue (for me), keyword arguments and maps that bundle them.
user> (defn foo [a b & {:keys [c d]}]
[a b c d])
#'us
It is a matter of personal style.
Note that there is a max function.
On Thursday, August 13, 2015 at 1:53:23 PM UTC+2, Herwig Hochleitner wrote:
>
> Yep, I meant the thing, `vector` is doing. Thanks!
>
> 2015-08-13 13:36 GMT+02:00 Amith George >
> :
>
>> Maybe you meant to use `vector` instead of
Yep, I meant the thing, `vector` is doing. Thanks!
2015-08-13 13:36 GMT+02:00 Amith George :
> Maybe you meant to use `vector` instead of `vec`? `vec` doesn't accept
> variable args. Hence my original question.
>
> On Thursday, 13 August 2015 16:24:43 UTC+5:30, Herwig Hochleitner wrote:
>>
>> 201
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Atamert,
sorry for replying late.
On 11.08.2015 10:29, Atamert Ölçgen wrote:
> Hi Christian,
>
> hasch looks nice, I might end up just using it. I will be hashing
> smaller collections (maps where keys are keywords and values are
> atomic data li
Maybe you meant to use `vector` instead of `vec`? `vec` doesn't accept
variable args. Hence my original question.
On Thursday, 13 August 2015 16:24:43 UTC+5:30, Herwig Hochleitner wrote:
>
> 2015-08-13 11:13 GMT+02:00 Amith George >
> :
>
>>
>> Could you please explain why is the `vec` needed? F
Hi,
I originally interpreted Erik's reply to mean -> Instead of `#(last (sort
%&))` do `#((comp last sort) %&)`. This works without any issue.
Herwig's suggestion was about replacing the entire anonymous function with
`(comp last sort vec)`. The example you gave `((comp last sort) 3 2 1)`,
ev
2015-08-13 11:13 GMT+02:00 Amith George :
>
> Could you please explain why is the `vec` needed? From what I understand,
> we are expected to treat the variadic args argument as a seq, nothing more.
>
>
What Tassilo said.
Also, it's not nessecary to use `vec`, but you need a function that creates
a
Amith George writes:
>> That's not the same function as #(last (sort %&))
>> The equivalent would be (comp last sort vec)
>
> Could you please explain why is the `vec` needed? From what I
> understand, we are expected to treat the variadic args argument as a
> seq, nothing more.
With ((comp las
Hi,
That's not the same function as #(last (sort %&))
> The equivalent would be (comp last sort vec)
Could you please explain why is the `vec` needed? From what I understand,
we are expected to treat the variadic args argument as a seq, nothing more.
On Thursday, 13 August 2015 14:02:38 UT
I enjoyed the post. It's easy for those of us who've been in the community
for a while to take such things for granted and not properly explain them
to new folks.
One suggestion - perhaps concurrency and immutability each deserve their
own section? That wouldd give you a chance to dig deeper into
2015-08-13 10:08 GMT+02:00 Eric Le Goff :
> I would be curious to know if there are difference (in terms of
> performance / elegance ) between those 2 ways of expressing functions
>
> E.g
>
> *(fn [& x] (-> x sort last))*
>
> versus
>
> *#(last (sort %&))*
>
> Both are supposedly equivalent, but w
(comp last sort)
Erik.
--
i farta
> Den 13. aug. 2015 kl. 10.08 skrev Eric Le Goff :
>
> I would be curious to know if there are difference (in terms of performance /
> elegance ) between those 2 ways of expressing functions
>
> E.g
>
> (fn [& x] (-> x sort last))
>
> versus
>
> #(last (
I would be curious to know if there are difference (in terms of performance
/ elegance ) between those 2 ways of expressing functions
E.g
*(fn [& x] (-> x sort last))*
versus
*#(last (sort %&))*
Both are supposedly equivalent, but would you recommend one preferred
syntax , or this just a matte
That was an error! The question has been corrected to "Does it have a few
dependencies? If the answer is 'No!' "
Thanks!
If you your teammates do read it, please report any feedback. Documents
like this one are sometimes appraised by converts and rejected by newcomers
which is not the point :
25 matches
Mail list logo
