Re: Decomplecting Clojure
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 binding. The other gotcha is when collecting metrics and timing data. I find it easier to write good abstractions around my data when I don't have to worry about the cost of doing work that is not needed. If you are writing accessors than this may not be so apparent, but when you are just using maps for your data, the default laziness means I an define a whole map at once, and only pay for the parts I use. With the very large data structures we deal with, that's essential. On Fri, Aug 14, 2015 at 12:56 PM, John Gabriele jmg3...@gmail.com wrote: 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 feedback, You're welcome! -- 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. -- 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.
Re: Decomplecting Clojure
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 feedback, You're welcome! -- 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.
Re: Decomplecting Clojure
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 immutability and perhaps cover structural sharing, which is the answer to many Clojure newcomers' puzzlement as to how immutability can be memory efficient. The current immutability/concurrency paragraph reads to me like concurrency is the main point of immutability, where in my experience it's just one useful consequence. On 13 August 2015 at 08:44, Sebastian Bensusan sbe...@gmail.com wrote: 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 :) Best Sebastian On Thu, Aug 13, 2015 at 2:45 AM, Andrew Cristina acris...@gmail.com wrote: 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 No, that piece of software should be discarded. My question is about the second provided question, Does it have many dependencies? Wouldn't many dependencies be a bad thing? If the question (and expected answer) are correct, can you go into a bit more detail on why having many dependencies is a positive quality? On Wednesday, August 12, 2015 at 11:52:39 AM UTC-7, Sebastian Bensusan wrote: 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 the initial draft, specially Jeff Kayser, Colin Fleming, and Viktor Eriksson. Best, Sebastian -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/6Rqa5CE6Hb8/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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. -- 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.
Re: Decomplecting Clojure
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 :) Best Sebastian On Thu, Aug 13, 2015 at 2:45 AM, Andrew Cristina acris...@gmail.com wrote: 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 No, that piece of software should be discarded. My question is about the second provided question, Does it have many dependencies? Wouldn't many dependencies be a bad thing? If the question (and expected answer) are correct, can you go into a bit more detail on why having many dependencies is a positive quality? On Wednesday, August 12, 2015 at 11:52:39 AM UTC-7, Sebastian Bensusan wrote: 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 the initial draft, specially Jeff Kayser, Colin Fleming, and Viktor Eriksson. Best, Sebastian -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/6Rqa5CE6Hb8/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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.
Re: Decomplecting Clojure
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 efficient?, I decided to edit it out for two reasons: first, not everybody asks that, since there are many (specially younger programmers) that naively trust tools. Secondly, I figured that if they do ask the question, it might lead them into research, which is the whole point! Thanks for the feedback, Sebastian On Thu, Aug 13, 2015 at 10:35 AM, Chris Ford christophertf...@gmail.com wrote: 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 immutability and perhaps cover structural sharing, which is the answer to many Clojure newcomers' puzzlement as to how immutability can be memory efficient. The current immutability/concurrency paragraph reads to me like concurrency is the main point of immutability, where in my experience it's just one useful consequence. On 13 August 2015 at 08:44, Sebastian Bensusan sbe...@gmail.com wrote: 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 :) Best Sebastian On Thu, Aug 13, 2015 at 2:45 AM, Andrew Cristina acris...@gmail.com wrote: 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 No, that piece of software should be discarded. My question is about the second provided question, Does it have many dependencies? Wouldn't many dependencies be a bad thing? If the question (and expected answer) are correct, can you go into a bit more detail on why having many dependencies is a positive quality? On Wednesday, August 12, 2015 at 11:52:39 AM UTC-7, Sebastian Bensusan wrote: 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 the initial draft, specially Jeff Kayser, Colin Fleming, and Viktor Eriksson. Best, Sebastian -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/6Rqa5CE6Hb8/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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. -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit
Re: Decomplecting Clojure
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 throughout: The JVM makes Clojure *practical*. A functional style makes Clojure *elegant*. Lisp makes Clojure *powerful*. Data as Data makes Clojure *simple*. Immutability makes Clojure programs *easy to reason about*. Oooh, looking at that list, I wonder if one about laziness is missing... -- John On Thursday, August 13, 2015 at 3:45:23 AM UTC-4, Sebastian Bensusan wrote: 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 :) Best Sebastian On Thu, Aug 13, 2015 at 2:45 AM, Andrew Cristina acri...@gmail.com javascript: wrote: 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 No, that piece of software should be discarded. My question is about the second provided question, Does it have many dependencies? Wouldn't many dependencies be a bad thing? If the question (and expected answer) are correct, can you go into a bit more detail on why having many dependencies is a positive quality? -- 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.
Re: Decomplecting Clojure
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 a 'marketing' perspective, I'd talk more about transducers than laziness--they're more exotic, at least. On Thursday, August 13, 2015 at 2:27:21 PM UTC-4, Alan Thompson wrote: 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 - forz, etc). Then lazy behavior would be available whenever it was desired, but the code would explicitly indicate when laziness was being employed. Alan On Thu, Aug 13, 2015 at 11:01 AM, Lee Spector lspe...@hampshire.edu javascript: wrote: 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 javascript: wrote: I never thought of laziness! It's a good point. Retroactively I might add it to the Functional Style section :) You did a nice job of presenting both pros and cons for the other features of Clojure, and I expect there would be something similar for your entry on laziness but FWIW from my perspective the cons here are more significant than for any other feature (and I know that opinions will vary on this!). I know that no language is perfect for everyone or every purpose, but at least from my perspective pervasive laziness is one of Clojure's very few true mistakes (sort of like my father-in-law says that eggplant is one of god's very few true mistakes). Laziness is often glorious and elegant, and the way that it's everywhere by default in Clojure is quite cool. But in a not-purely-functional environment it can cause weird problems at unexpected times and in unexpected places. There are several ways to get into trouble -- there was a nice blog post on some of them years ago, maybe by Chas Emerick? -- but I think most of my own come from the not-purely-functional nature of synchronization, awaiting the completion of tasks dispatched to agents. Symptoms that I get include the saturation of only one core when I expect to be saturating all of them, and sometimes out-of-memory errors. I think the former are due to delayed lazy computations taking place at unexpected times, and that the latter come from GC not collecting things that it would know it could collect if the deferred computations were completed in a non-lazy way. It has been hard to replicate or track down the sources of these problems, but they do always go away when I un-lazify everything -- coercing sequences to vectors, calling doall, changing every call to map to mapv, etc. Because these problems are so hard to diagnose and think about, I've taken to pre-emptively avoiding laziness whenever possible, unless I really want it (which is relatively rare, for me). This can be a bit awkward, and it's one of the very few things that I feel like I have to apologize for when I introduce Clojure to students. -Lee -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- 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.
Re: Decomplecting Clojure
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 your artifacts (very relevant in browsers). Now, I do agree that they are a good heuristic of good code: a module that uses dependencies wisely and doesn't reinvent the wheel is better than one that does. So, there are two conflicting forces, and we are left with compromise: we should use modules that use dependencies in a balanced way. That is why I broke the questions into few dependencies and does one thing well to tackle the issues separately. I never thought of laziness! It's a good point. Retroactively I might add it to the Functional Style section :) Thanks for the feedback, Sebastian On Thu, Aug 13, 2015 at 5:09 PM, John Gabriele jmg3...@gmail.com wrote: 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 throughout: The JVM makes Clojure *practical*. A functional style makes Clojure *elegant*. Lisp makes Clojure *powerful*. Data as Data makes Clojure *simple*. Immutability makes Clojure programs *easy to reason about*. Oooh, looking at that list, I wonder if one about laziness is missing... -- John On Thursday, August 13, 2015 at 3:45:23 AM UTC-4, Sebastian Bensusan wrote: 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 :) Best Sebastian On Thu, Aug 13, 2015 at 2:45 AM, Andrew Cristina acri...@gmail.com wrote: 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 No, that piece of software should be discarded. My question is about the second provided question, Does it have many dependencies? Wouldn't many dependencies be a bad thing? If the question (and expected answer) are correct, can you go into a bit more detail on why having many dependencies is a positive quality? -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/6Rqa5CE6Hb8/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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.
Re: Decomplecting Clojure
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 - forz, etc). Then lazy behavior would be available whenever it was desired, but the code would explicitly indicate when laziness was being employed. Alan On Thu, Aug 13, 2015 at 11:01 AM, Lee Spector lspec...@hampshire.edu wrote: 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 :) You did a nice job of presenting both pros and cons for the other features of Clojure, and I expect there would be something similar for your entry on laziness but FWIW from my perspective the cons here are more significant than for any other feature (and I know that opinions will vary on this!). I know that no language is perfect for everyone or every purpose, but at least from my perspective pervasive laziness is one of Clojure's very few true mistakes (sort of like my father-in-law says that eggplant is one of god's very few true mistakes). Laziness is often glorious and elegant, and the way that it's everywhere by default in Clojure is quite cool. But in a not-purely-functional environment it can cause weird problems at unexpected times and in unexpected places. There are several ways to get into trouble -- there was a nice blog post on some of them years ago, maybe by Chas Emerick? -- but I think most of my own come from the not-purely-functional nature of synchronization, awaiting the completion of tasks dispatched to agents. Symptoms that I get include the saturation of only one core when I expect to be saturating all of them, and sometimes out-of-memory errors. I think the former are due to delayed lazy computations taking place at unexpected times, and that the latter come from GC not collecting things that it would know it could collect if the deferred computations were completed in a non-lazy way. It has been hard to replicate or track down the sources of these problems, but they do always go away when I un-lazify everything -- coercing sequences to vectors, calling doall, changing every call to map to mapv, etc. Because these problems are so hard to diagnose and think about, I've taken to pre-emptively avoiding laziness whenever possible, unless I really want it (which is relatively rare, for me). This can be a bit awkward, and it's one of the very few things that I feel like I have to apologize for when I introduce Clojure to students. -Lee -- 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. -- 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.
Re: Decomplecting Clojure
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 :) You did a nice job of presenting both pros and cons for the other features of Clojure, and I expect there would be something similar for your entry on laziness but FWIW from my perspective the cons here are more significant than for any other feature (and I know that opinions will vary on this!). I know that no language is perfect for everyone or every purpose, but at least from my perspective pervasive laziness is one of Clojure's very few true mistakes (sort of like my father-in-law says that eggplant is one of god's very few true mistakes). Laziness is often glorious and elegant, and the way that it's everywhere by default in Clojure is quite cool. But in a not-purely-functional environment it can cause weird problems at unexpected times and in unexpected places. There are several ways to get into trouble -- there was a nice blog post on some of them years ago, maybe by Chas Emerick? -- but I think most of my own come from the not-purely-functional nature of synchronization, awaiting the completion of tasks dispatched to agents. Symptoms that I get include the saturation of only one core when I expect to be saturating all of them, and sometimes out-of-memory errors. I think the former are due to delayed lazy computations taking place at unexpected times, and that the latter come from GC not collecting things that it would know it could collect if the deferred computations were completed in a non-lazy way. It has been hard to replicate or track down the sources of these problems, but they do always go away when I un-lazify everything -- coercing sequences to vectors, calling doall, changing every call to map to mapv, etc. Because these problems are so hard to diagnose and think about, I've taken to pre-emptively avoiding laziness whenever possible, unless I really want it (which is relatively rare, for me). This can be a bit awkward, and it's one of the very few things that I feel like I have to apologize for when I introduce Clojure to students. -Lee -- 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.
Re: Decomplecting Clojure
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 reloading in mind,” and you probably meant “is not design*ed*”? At least, that would read more naturally to me. The end of the Immutability section reads: Immutability makes Clojure programs *easy to reason about it*. I suspect you did not mean to include that final “it”. In the Principles and Community section, there is a sentence “The standard settings apply to your system and are easy to setup since they come modules that fit together.” I feel like there is a word or two missing at the end there, I am not sure what it is trying to say. Perhaps “come *with* modules”? But again, thanks so much for this wonderful document! -James On Wednesday, August 12, 2015 at 1:52:39 PM UTC-5, Sebastian Bensusan wrote: 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 the initial draft, specially Jeff Kayser, Colin Fleming, and Viktor Eriksson. Best, Sebastian -- 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.
Re: Decomplecting Clojure
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 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 the initial draft, specially Jeff Kayser, Colin Fleming, and Viktor Eriksson. Best, Sebastian -- 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. -- 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.
Re: Decomplecting Clojure
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 No, that piece of software should be discarded. My question is about the second provided question, Does it have many dependencies? Wouldn't many dependencies be a bad thing? If the question (and expected answer) are correct, can you go into a bit more detail on why having many dependencies is a positive quality? On Wednesday, August 12, 2015 at 11:52:39 AM UTC-7, Sebastian Bensusan wrote: 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 the initial draft, specially Jeff Kayser, Colin Fleming, and Viktor Eriksson. Best, Sebastian -- 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.
Decomplecting Clojure
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 the initial draft, specially Jeff Kayser, Colin Fleming, and Viktor Eriksson. Best, Sebastian -- 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.
