After working for several years in a large clojure code-base, and having
been bitten by laziness a few times, I think I am still a fan of lazy by
default.
I have not been bitten by issues related to agents and laziness. Mostly
it's resources going out of scope because I was using a dynamic
On Thursday, August 13, 2015 at 1:51:32 PM UTC-4, Sebastian Bensusan wrote:
I never thought of laziness! It's a good point. Retroactively I might add
it to the Functional Style section :)
I think of laziness as often going together with (possibly-) infinite lists.
Thanks for the
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
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 :)
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 it
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
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,
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
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 sbe...@gmail.com wrote:
I never thought of laziness! It's a good point. Retroactively I might add it
to the Functional Style section :)
Wow, this is fantastic, I now have a new link to send anyone who asks me
why I find Clojure valuable. Thanks so much!
As a small return of favor, may I point a few small things that look like
editing errors?
The last limitation bullet in the JVM section states “The JVM is not design
with code
Cool!
It would be nice mentioning Clojurescript as well, especially with the recent
development in http://github.com/mfikes/planck, which delivers a super fast
Clojurescript for commands.
Erik.
On 12. aug. 2015, at 20.52, Sebastian Bensusan sbe...@gmail.com wrote:
Hi everybody!
I've
Hi Sebastian,
Thanks for sharing! I'm enjoying read this document, and I plan to share
it with a few teammates. I do have a question about one section however:
Near the end, under Principles and Community you list three questions,
and then state that if the answer to any of the questions is
Hi everybody!
I've written a short post on my interpretation of Clojure. It is meant for
people that are curious about the language and want to understand what the
language is about.
http://bensu.github.io/decomplecting_clojure/
Any feedback is welcome.
Thanks to the folks at Slack that read
Nice :)
On Sunday, December 9, 2012 1:17:48 AM UTC+1, Michał Marczyk wrote:
Better yet,
(defmacro iff [test {:keys [then else]}]
`(if ~test ~then ~else))
(that's doing the lookup for then and else in the map constructing
from the macro's rest argument at compilation time rather
(defmacro iff [test {:keys [then else]}]
You probably want a different name for this, 'iff' already has a well
understood meaning as 'if and only if'
See
http://en.m.wikipedia.org/wiki/If_and_only_if
--
You received this message because you are subscribed to the Google
Groups Clojure
You could add check for other keys than :then and :else being used.
For documentation, I'd add a docstring Macro, similar to if but with
branches labeled by keywords :then, :else. + the usage examples you posted.
Also, have you looked at cond and if-not?
Using cond to me feels like labeling the
Cool thanks!
On Sunday, December 9, 2012 11:52:32 AM UTC+1, Alex Baranosky wrote:
The version I just posted also has the benefit that it does not cause
multiple evaluations of its branches.
On Sun, Dec 9, 2012 at 2:39 AM, Herwig Hochleitner
hhochl...@gmail.comjavascript:
wrote:
How about cond?
(cond
test true
:else false)
BTW I personally don't consider if complected. If reverse order is more
appropriate, I use if-not.
On Sunday, December 9, 2012 12:02:54 AM UTC+1, Thomas Goossens wrote:
One of the issues i had and still have with the if function is that
Yeah, cond will probably do the trick as well.
I do consider if complex (and yeah my argument is true for a lot of
functions)
What i'm talking about is some accidental complexity of the language. That
I must constantly be aware of what parameter of the function I'm looking
at.
My point is not so
One of the issues i had and still have with the if function is that
because it has ordered arguments, makes things more complex.
For small functions this is no so much of a problem.
(if test 1 0)
But when things get larger, that extra complexity of order without
explicit information can get
You may want to use some delays to prevent evaluation of untaken branches:
user= (iff true :else (println 1) :then (println 3))
3
1
nil
user=
On Sat, Dec 8, 2012 at 3:02 PM, Thomas Goossens
cont...@thomasgoossens.be wrote:
One of the issues i had and still have with the if function is that
Better yet,
(defmacro iff [test {:keys [then else]}]
`(if ~test ~then ~else))
(that's doing the lookup for then and else in the map constructing
from the macro's rest argument at compilation time rather than in an
evaluated map including both at run time).
Cheers,
Michał
On 9 December 2012
23 matches
Mail list logo
