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 bin
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
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
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
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 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
James, I just pushed your suggested corrections.
Erik, after working mostly with ClojureScript I no longer see it as a part
of Clojure the language but as a part of the Clojure community. I'll
probably write something similar for ClojureScript at some point :)
Thanks both for the feedback.
On
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 wrote:
>
> Hi everybody!
>
> I've written a short
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
14 matches
Mail list logo
