ANN Monger 3.0.0 is released
Monger [1] is a modern Clojure MongoDB client. 3.0 has breaking API changes. Release notes: http://blog.clojurewerkz.org/blog/2015/07/16/monger-3-dot-0-0-is-released/ 1. http://clojuremongodb.info -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- 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.
#{:rant} Questions about contribution policy and clojure compiler source.
Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little bit opaque... An other question: Why the great amount of clojure compiler code has no indentation style and bunch of commented code. It is indented like a freshman. Sorry, I don't want offend any one, but eyes hurt when reading the code compiler clojure (obviously I'm speaking about the look and feel, and no the quality of the code). Some examples: Indentation (or maybe no indentation): https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86 Bunch of commented code and also no indentation: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AMapEntry.java#L60 If you compare some clojure compiler code with different code snippets from other languages, the indentation is clearly more cared: Kotlin: https://github.com/JetBrains/kotlin/blob/master/core/descriptors/src/org/jetbrains/kotlin/types/AbstractClassTypeConstructor.java#L44 Rust: https://github.com/rust-lang/rust/blob/master/src/libstd/io/buffered.rs#L165 Ceylon: https://github.com/ceylon/ceylon-compiler/blob/master/src/com/redhat/ceylon/compiler/java/codegen/AttributeDefinitionBuilder.java#L233 This is a random list of code snippets from different compilers with indentation that is more human friendly. I don't intend judge any one, but when a I learn Clojure compiler I expect something different. I expect something more carefully done. No body thinks the same thing that me? I think that have a sane, more open contribution policy, with clear and more cared code formatting, is not very complicated thing and is going to favor the clojure and its community. Andrey -- Andrey Antukh - Андрей Антух - n...@niwi.nz http://www.niwi.nz https://github.com/niwinz -- 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.
#{:eduction :performance} Trying to understand when to use eduction
My understanding was that if I pass an eduction to a process using reduce, I can save the computer time and space because the per step overhead of lazy sequences is gone and also the entire sequence does not have to reside in memory at once. When I time the difference between (apply max (map inc (range 10))) and (apply max (eduction (map inc) (range 10))), the lazy-seq variant wins. I'd like to understand why, and when eductions should be used instead. -- 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: Advice on introducing a Java dev to Clojure
I have tried various different approaches from convincing of Clojure advantages in the Java devs concrete domain, showing off incredibly awesome toy projects, larger projects, not tryng to sell, trying to sell, sending ClojureTV videos and what not approach you can think of. I have not managed to introduce one Java dev to Clojure in a way that he picked it up and had no interest before. I have spent many hours thinking about how I could improve my evangelizing skills. And today I believe that what you can do is very little and your approach does not affect the outcome a lot. There is enough motivating and introductional content about Clojure on the web. If someone isn't motivated by all this and your initial impulse, he is simply not able to upgrade. It might be a lack of time, a lack of interest in programming altogether aka silent burnout, the fear of having to learn new things, the fear of forgetting old things, the fear of not wanting to leave a comfort zone, the fear of not being able to autocompleteprogram or the fact that someone is simply happy with clicking classes together and writing a new group by implementation every few days and being paid for it very well and many other reasons. In many cases an existing comfort zone is an obstacle that you can't change. Almost nobody leaves his comfort zone only because you told him about something else outside of it, even if its gold and he believes you. OTOH people who leave their comfort zone on purpose every now and then do it because they are intrinsically motivated to do so. If they are out of ideas where to go, they will ask you for one and then selling Clojure is about as easy as mentioning between one and three interesting facts about it. They will be watching Rich Hickey talks in a minute. Unless a programmer is adventureous and likes to try out new languages or has decided that he wants to learn something new, there is little you can do. In the other case there is little that you have to do. Personally I have simply decided not to waste time on trying to convince programmers to learn Clojure, instead I try to help those who are. OTOH spending time on improving evangelizing and elevator pitching is still well spent if you want to convince managers. I find Rich Hickeys rationale on the Clojure page is a great starting point and there is also a great talk by Paul deGrandis (Clojure minimizes risk). On Friday, July 10, 2015 at 12:20:23 AM UTC+2, Johanna Belanger wrote: Hi :) I've recently broached the subject of Clojure with another dev in my organization, and his response was basically What's Clojure? and I'm not sure how to answer that in a way that might inspire him. It's a dynamically-typed functional Lisp with persistent immutable data structures that runs on the JVM doesn't seem like it will grab his interest. =) I work primarily in .NET, and he does enterprise Java. I don't know him well enough to know how happy he is with it. He did express interest in learning .Net. I came to an appreciation of Clojure through -CQRS (the power of decomplection!) -Sussman and Abelson's SICP class at MIT online (the power of homoiconicity and functions!) -the death of Silverlight (alternatives to Javascript in the browser?) By the time I found Rich Hickey's talks (eg Simple Made Easy) I was pretty well primed to love Clojure. I've been using it for little personal projects and prototyping for a couple of years, but I haven't put it in production because no one else here knows it. Could anyone tell me how they got from enterprise Java to Clojure? Thanks very much, Johanna -- 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: Advice on introducing a Java dev to Clojure
I have tried various different approaches from convincing of Clojure advantages in the Java devs concrete domain, showing off incredibly awesome toy projects, larger projects, not tryng to sell, trying to sell, sending ClojureTV videos and what not approach you can think of. I have not managed to introduce one Java dev to Clojure in a way that he picked it up and had no interest before. I have spent many hours thinking about how I could improve my evangelizing skills. And today I believe that what you can do is very little and your approach does not affect the outcome a lot. There is enough motivating and introductional content about Clojure on the web. If someone isn't motivated by all this and your initial impulse, he is simply not able to upgrade. It might be a lack of time, a lack of interest in programming altogether aka silent burnout, the fear of having to learn new things, the fear of forgetting old things, the fear of not wanting to leave a comfort zone, the fear of not being able to autocompleteprogram or the fact that someone is simply happy with clicking classes together and writing a new group by implementation every few days and being paid for it very well and many other reasons. In many cases an existing comfort zone is an obstacle that you can't change. Almost nobody leaves his comfort zone only because you told him about something else outside of it, even if its gold and he believes you. OTOH people who leave their comfort zone on purpose every now and then do it because they are intrinsically motivated to do so. If they are out of ideas where to go, they will ask you for one and then selling Clojure is about as easy as mentioning between one and three interesting facts about it. They will be watching Rich Hickey talks in a minute. Unless a programmer is adventureous and likes to try out new languages or has decided that he wants to learn something new, there is little you can do. In the other case there is little that you have to do. Personally I have simply decided not to waste time on trying to convince programmers to learn Clojure, instead I try to help those who are. OTOH spending time on improving evangelizing and elevator pitching is still well spent if you want to convince managers. I find Rich Hickeys rationale on the Clojure page is a great starting point and there is also a great talk by Paul deGrandis (Clojure minimizes risk). On Friday, July 10, 2015 at 12:20:23 AM UTC+2, Johanna Belanger wrote: Hi :) I've recently broached the subject of Clojure with another dev in my organization, and his response was basically What's Clojure? and I'm not sure how to answer that in a way that might inspire him. It's a dynamically-typed functional Lisp with persistent immutable data structures that runs on the JVM doesn't seem like it will grab his interest. =) I work primarily in .NET, and he does enterprise Java. I don't know him well enough to know how happy he is with it. He did express interest in learning .Net. I came to an appreciation of Clojure through -CQRS (the power of decomplection!) -Sussman and Abelson's SICP class at MIT online (the power of homoiconicity and functions!) -the death of Silverlight (alternatives to Javascript in the browser?) By the time I found Rich Hickey's talks (eg Simple Made Easy) I was pretty well primed to love Clojure. I've been using it for little personal projects and prototyping for a couple of years, but I haven't put it in production because no one else here knows it. Could anyone tell me how they got from enterprise Java to Clojure? Thanks very much, Johanna -- 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.
[ANN] Clojure 1.8.0-alpha2
Clojure 1.8.0-alpha1 and 1.8.0-alpha2 are now available. Try it via - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-alpha2 - Leiningen: [org.clojure/clojure 1.8.0-alpha2] 1.8.0-alpha1 includes support for tuples (optimized small vectors) inspired by Zach Tellman's work. 1.8.0-alpha2 has an additional set of bug fixes and enhancements: CLJ-703 Improve writeClassFile performance CLJ-1659 compile leaks files CLJ-1761 clojure.core/run! does not always return nil CLJ-1645 'javap -v' on protocol class reveals no source file CLJ-1644 into-array fails for sequences starting with nil CLJ-1588 StackOverflow in clojure.test macroexpand with `are` and anonymous `fn` CLJ-1565 pprint issues infinite output for a protocol CLJ-1562 some-,some-,cond-,cond- and as- doesn't work with (recur) CLJ-1533 Oddity in type tag usage for primInvoke CLJ-1528 clojure.test/inc-report-counter is not thread safe CLJ-1399 missing field munging when recreating deftypes serialized into byte code CLJ-1313 Correct a few unit tests CLJ-1250 Reducer (and folder) instances hold onto the head of seqs CLJ-1208 Namespace is not loaded on defrecord class init Our current plans for 1.8 are to feature freeze on October 1st (typically that is beta 1) and then work through a release in time for the Clojure/Conj in late November. We expect 1.8 to include the Socket Server REPL work (http://dev.clojure.org/display/design/Socket+Server+REPL) and possibly other things to be determined. - Alex -- 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: #{:rant} Questions about contribution policy and clojure compiler source.
On 18 July 2015 at 14:13, Andrey Antukh n...@niwi.nz wrote: Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little bit opaque... Many people feel this way, but ultimately Clojure is Rich's project and I guess Cognitect's to some extent. If they don't want to run it like other more open contribution-friendly OSS projects this is obviously their right. An other question: Why the great amount of clojure compiler code has no indentation style and bunch of commented code. It is indented like a freshman. Sorry, I don't want offend any one, but eyes hurt when reading the code compiler clojure (obviously I'm speaking about the look and feel, and no the quality of the code). Some examples: Indentation (or maybe no indentation): https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86 Bunch of commented code and also no indentation: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AMapEntry.java#L60 If you compare some clojure compiler code with different code snippets from other languages, the indentation is clearly more cared: Kotlin: https://github.com/JetBrains/kotlin/blob/master/core/descriptors/src/org/jetbrains/kotlin/types/AbstractClassTypeConstructor.java#L44 Rust: https://github.com/rust-lang/rust/blob/master/src/libstd/io/buffered.rs#L165 Ceylon: https://github.com/ceylon/ceylon-compiler/blob/master/src/com/redhat/ceylon/compiler/java/codegen/AttributeDefinitionBuilder.java#L233 This is a random list of code snippets from different compilers with indentation that is more human friendly. I don't intend judge any one, but when a I learn Clojure compiler I expect something different. I expect something more carefully done. No body thinks the same thing that me? This topic resurfaces all the time. I'd certainly like to see the Java code fixed, as its layout is highly unidiomatic (not to mention somewhat confusing). I doubt this will happen though - seems Rich doesn't think this is a big problem and AFAIK he's concerned that fixing the layout will affect currently submitted patches. Knowing all the hoops one has to jump to get a patch into Clojure, this doesn't sound like a pretty strong argument, but once again - his project, his rules. People seem to undervalue the value of polish in a project, as good style and overall tidiness set apart the good from the great. I think that have a sane, more open contribution policy, with clear and more cared code formatting, is not very complicated thing and is going to favor the clojure and its community. Certainly. As far basic things go, I think it's also discouraging to see commit messages like: * tuples * tuning tuples * tuning tuples * fix And don't get me started on commented out code and Javadoc/Clojure docstrings. It'd be nice if at least improvements of cosmetic nature where easier to contribute, but alas - this also doesn't seem likely to happen. Andrey -- Andrey Antukh - Андрей Антух - n...@niwi.nz http://www.niwi.nz https://github.com/niwinz -- 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: #{:rant} Questions about contribution policy and clojure compiler source.
Btw, here's a bit more colour on the inclusion of tuples, Zack's own thoughts on the subject https://gist.github.com/ztellman/9ded0b77281f48942b68 On Saturday, July 18, 2015 at 2:14:02 PM UTC+3, Andrey Antukh wrote: Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little bit opaque... An other question: Why the great amount of clojure compiler code has no indentation style and bunch of commented code. It is indented like a freshman. Sorry, I don't want offend any one, but eyes hurt when reading the code compiler clojure (obviously I'm speaking about the look and feel, and no the quality of the code). Some examples: Indentation (or maybe no indentation): https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86 Bunch of commented code and also no indentation: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AMapEntry.java#L60 If you compare some clojure compiler code with different code snippets from other languages, the indentation is clearly more cared: Kotlin: https://github.com/JetBrains/kotlin/blob/master/core/descriptors/src/org/jetbrains/kotlin/types/AbstractClassTypeConstructor.java#L44 Rust: https://github.com/rust-lang/rust/blob/master/src/libstd/io/buffered.rs#L165 Ceylon: https://github.com/ceylon/ceylon-compiler/blob/master/src/com/redhat/ceylon/compiler/java/codegen/AttributeDefinitionBuilder.java#L233 This is a random list of code snippets from different compilers with indentation that is more human friendly. I don't intend judge any one, but when a I learn Clojure compiler I expect something different. I expect something more carefully done. No body thinks the same thing that me? I think that have a sane, more open contribution policy, with clear and more cared code formatting, is not very complicated thing and is going to favor the clojure and its community. Andrey -- Andrey Antukh - Андрей Антух - ni...@niwi.nz javascript: http://www.niwi.nz https://github.com/niwinz -- 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: #{:rant} Questions about contribution policy and clojure compiler source.
On Sat, Jul 18, 2015 at 6:48 PM, Colin Yates colin.ya...@gmail.com wrote: +1 (although I maybe wouldn’t be so mocking in my tone ;-). Since when did software design by committee work; anyone remember J2EE? (and yes, that does deserve my mocking tone). I have no idea about the details being discussed here/why people’s noses are out of joint, but I can think of as many success with a single overlord in place as there are failures caused by political infighting. In general, I'm pretty happy with the benevolent dictator approach. But some openness would be awesome. As first think that comes in my mind is: have a clear roadmap for Clojure and its core libraries such as core.async. Some channel for requesting features, and the ability to know a opinion of the clojure core team about the possibility of the inclusion of some requested feature. Also would be awesome have more painless contribution process. I'm ok for signing CA, but using patches instead of something like pull requests (with or without additional review tool) is very arcane and uncomfortable process. I don't suggest to change to something similar to design by committee. I only suggest that make some facilities for contribute may attract more interesting people. And will make more happy excellent contributors like Zach Tellman or Aphyr. I think that things like this are not very complicated to adopt and has a lot of benefit. My two cents! On 18 Jul 2015, at 16:44, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Sure, indentation is what gets the code running on metal :)) Not ranting here, just my abs dying from the pain as I laugh :)) As for the contrib process, go have a look at Linux. You'll be happy that Rich is cool by every meaning of the word. There's this misconception about open source that we should all wear flower collars and sing Kumbaya. Mostly a 60's view of human collaboration. That ain't the way to get it done. It works for ants and termites, they work as groups but we are human beings with our strong individuality. Some form of central control is needed. Opposed by traction from some individuals that would like to move faster or in other directions. This is ok but not at the expense of the cohesion of the end result. Hence this tensed balance. Rich created Clojure, he knows were he wants to go with it. Any ideas we bring in the process is evaluated. However not all of them make sense or are worth the effort to implement. Aside from our respective ego being hurt because our ideas are not retained or our contribs vetted in the first pass there's little damage done. If it was not the case Clojure would have zero traction and Linux likewise. Search for Linus rants about contributors and try to relate this with the level of success of Linux. They are not so many open source projects that have the same stability from release to release as Clojure or Linux. Control and absence of complacency are key factors to achieve this kind of success. Luc P. Sent from my iPhone On Jul 18, 2015, at 07:13, Andrey Antukh n...@niwi.nz wrote: Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little bit opaque... An other question: Why the great amount of clojure compiler code has no indentation style and bunch of commented code. It is indented like a freshman. Sorry, I don't want offend any one, but eyes hurt when reading the code compiler clojure (obviously I'm speaking about the look and feel, and no the quality of the code). Some examples: Indentation (or maybe no indentation): https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86 Bunch of commented code and also no indentation: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AMapEntry.java#L60 If you compare some clojure compiler code with different code snippets from other languages, the indentation is clearly more cared: Kotlin: https://github.com/JetBrains/kotlin/blob/master/core/descriptors/src/org/jetbrains/kotlin/types/AbstractClassTypeConstructor.java#L44 Rust: https://github.com/rust-lang/rust/blob/master/src/libstd/io/buffered.rs#L165 Ceylon: https://github.com/ceylon/ceylon-compiler/blob/master/src/com/redhat/ceylon/compiler/java/codegen/AttributeDefinitionBuilder.java#L233 This is a random list of code snippets from different compilers with indentation that is more human friendly. I don't intend judge any one, but when a I learn Clojure compiler I expect something different. I expect something more
Re: #{:rant} Questions about contribution policy and clojure compiler source.
On 18 July 2015 at 18:48, Colin Yates colin.ya...@gmail.com wrote: +1 (although I maybe wouldn’t be so mocking in my tone ;-). Since when did software design by committee work; anyone remember J2EE? (and yes, that does deserve my mocking tone). Why do people always say that a committee is the only alternative of having a BDFL? That's clearly not the case. Would it be so bad of Alex Miller had the power to vet and merge certain clear-cut things himself? Or someone else like him? While create artificial bottlenecks when we can do without them? I have no idea about the details being discussed here/why people’s noses are out of joint, but I can think of as many success with a single overlord in place as there are failures caused by political infighting. On 18 Jul 2015, at 16:44, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Sure, indentation is what gets the code running on metal :)) Not ranting here, just my abs dying from the pain as I laugh :)) As for the contrib process, go have a look at Linux. You'll be happy that Rich is cool by every meaning of the word. There's this misconception about open source that we should all wear flower collars and sing Kumbaya. Mostly a 60's view of human collaboration. That ain't the way to get it done. It works for ants and termites, they work as groups but we are human beings with our strong individuality. Some form of central control is needed. Opposed by traction from some individuals that would like to move faster or in other directions. This is ok but not at the expense of the cohesion of the end result. Hence this tensed balance. Rich created Clojure, he knows were he wants to go with it. Any ideas we bring in the process is evaluated. However not all of them make sense or are worth the effort to implement. Aside from our respective ego being hurt because our ideas are not retained or our contribs vetted in the first pass there's little damage done. If it was not the case Clojure would have zero traction and Linux likewise. Search for Linus rants about contributors and try to relate this with the level of success of Linux. They are not so many open source projects that have the same stability from release to release as Clojure or Linux. Control and absence of complacency are key factors to achieve this kind of success. Luc P. Sent from my iPhone On Jul 18, 2015, at 07:13, Andrey Antukh n...@niwi.nz wrote: Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little bit opaque... An other question: Why the great amount of clojure compiler code has no indentation style and bunch of commented code. It is indented like a freshman. Sorry, I don't want offend any one, but eyes hurt when reading the code compiler clojure (obviously I'm speaking about the look and feel, and no the quality of the code). Some examples: Indentation (or maybe no indentation): https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86 Bunch of commented code and also no indentation: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AMapEntry.java#L60 If you compare some clojure compiler code with different code snippets from other languages, the indentation is clearly more cared: Kotlin: https://github.com/JetBrains/kotlin/blob/master/core/descriptors/src/org/jetbrains/kotlin/types/AbstractClassTypeConstructor.java#L44 Rust: https://github.com/rust-lang/rust/blob/master/src/libstd/io/buffered.rs#L165 Ceylon: https://github.com/ceylon/ceylon-compiler/blob/master/src/com/redhat/ceylon/compiler/java/codegen/AttributeDefinitionBuilder.java#L233 This is a random list of code snippets from different compilers with indentation that is more human friendly. I don't intend judge any one, but when a I learn Clojure compiler I expect something different. I expect something more carefully done. No body thinks the same thing that me? I think that have a sane, more open contribution policy, with clear and more cared code formatting, is not very complicated thing and is going to favor the clojure and its community. Andrey -- Andrey Antukh - Андрей Антух - n...@niwi.nz http://www.niwi.nz https://github.com/niwinz -- 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
Re: #{:rant} Questions about contribution policy and clojure compiler source.
On 18 July 2015 at 20:18, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. So, Ruby on Rails is a small project, right? And if we have many contributors we should show no respect for their time - we should actually make it harder to contribute, so it'd be easier on us, right? Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Many projects predate GitHub, yet they eventually adopted it. And it's never about GitHub in particular - it's only about making things efficient and pleasant for everyone involved. I work with JIRA for a living and my team mostly hates it, I can only imagine the willingness of casual contributors to deal with it. How do you do an inline patch review in JIRA? How do you update patches automatically? It's never about particular tools, it's all about making smart choices. Once that choice is done, moving out to something else requires a significant effort, you need to pull all this history you built about your software into your new bug tracking solution. You can't loose this, it's your software collective memory. All this discussion around pull request IMO is more an expression of human lazyness. Having to document is always seen as a chore by most developpers. This is not an arcane human trait, it has been known for decades. Laziness? Time is our most important resource and we should always be mindful of the time people have to invest (waste) to contribute to our projects. For me lowering the bar to entry is the same as respecting the time of the person on the other end of the ticket/patch/whatever. If you take a look at my profile on GitHub you'll see I maintain a few projects and I go to great lengths to make sure all the projects are inviting and it's easy for people to start a conversation or pitch in. This pays off big time in the long run. Anything else requires a discussion forum if you want to maintain a minimal level of quality and allow some discussions around the issue being fixed in a large team effort/critical piece of software. A mailing list is not at par with a bug tracking system in this regard. Curiously, linux has a bug tracking system and people submit patches or links are made to patches. Take a walk on launchpad. Curiously, most of the people who work on Linux are on the payroll of a corporation like Red Hat. If I was getting paid to do something, I'd definitely be more willing to through more hurdles - after all that's part of my job, right? No serious software business would drive their dev without a tracking system. Open source projects are no different if they want to attain some level of success. If critical open source is to be used by businesses, it has to play with similar tools. Clojure too me is critical to my business and to many others. It cannot fail on us. It would be like building pyramids on moving sand. Again there's no Kumbaya song playing here. As a last note, Alex Miller must dream about the emails exchanged on the mailing list. Suggestions are certainly looked upon and discussed upstream. It does not mean that they will be considered worth to investigate/implement or they may come out differently (that ego thing looming again). Alex is an amazing fellow, there's no denying this. I only wish we could clone him somehow. :-) +1 for Jira and patches. Luc P. On Sat, 18 Jul 2015 19:05:16 +0300 Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 6:48 PM, Colin Yates colin.ya...@gmail.com wrote: +1 (although I maybe wouldn’t be so mocking in my tone ;-). Since when did software design by committee work; anyone remember J2EE? (and yes, that does deserve my mocking tone). I have no idea about the details being discussed here/why people’s noses are out of joint, but I can think of as many success with a single overlord in place as there are failures caused by political infighting. In general, I'm pretty happy with the benevolent dictator approach. But some openness would be awesome. As first think that comes in my mind is: have a clear roadmap for Clojure and its core libraries such as core.async. Some channel for requesting features, and the ability to know a opinion of the clojure core team about the possibility of the inclusion of some requested
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Each linux kernel release involves hundreds of people. Many release had above a thousand contributors. This is for your enlightenment and are old figures: http://royal.pingdom.com/2012/04/16/linux-kernel-development-numbers/ There are as many people not officially hired to work for linux operating system focused businesses that submit patches through the ticketing system. As for the development lifecycle of the linux kernel: http://www.linuxfoundation.org/content/22-lifecycle-patch You can read the other sections, if you find the Clojure dev. lifecycle arcane, you will freak at this one. Obviously, these guys must all be old fashion outdated folks in this era of instant communication and snapchat like media, there's no other explanation for such a bureaucratic process :) How much pain is it to upgrade to a new Clojure version ? Nil. How much pain is it to upgrade to a new linux kernel ? Not nil but considering the size of this project, its ramifications and the hardware changing every 6 months, not big. On par with Clojure I would say. How much pain to upgrade to a new version of Ruby on Rails ? Huge. I know, I have been through this a number of times. Not just major releases, even maintenance ones are a nightmare to upgrade. Disclaimer: I am not saying that Rails has a bad lifecycle, I am just stating feedback from me and other people that actually lived this. Gee, I sound like Mallard Fillmore... That's for the political correctness of this post. And to avoid being harassed, sued, whatever. I would like us to compare carrots with carrots, not with apples or strawberries but if you insist To me the result is utterly important. We deliver 24/7 software under linux using Clojure. We have up times of more than 300 days. One upgrade a year. This is the world that live into. Making it 'harder to contribute' like you state is the price to pay for some form of quality control. Contributing to something that eventually crumbles because of a lack of QA is of no value. To us all. Stuart has made this evaluation. Since it models by some aspect how a successful project like Linux is managed, I find it hard to throw a stone at the current lifecycle. That may look to you as an ultra-conservative approach. Let's put it this way, I would use Linux and Clojure to control a nuclear plant anytime. I am quite certain sure I would not use Rails or Ruby for this purpose. Luc P. Luc P. Sent from my iPad On Jul 18, 2015, at 14:32, Bozhidar Batsov bozhi...@batsov.com wrote: On 18 July 2015 at 20:18, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. So, Ruby on Rails is a small project, right? And if we have many contributors we should show no respect for their time - we should actually make it harder to contribute, so it'd be easier on us, right? Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Many projects predate GitHub, yet they eventually adopted it. And it's never about GitHub in particular - it's only about making things efficient and pleasant for everyone involved. I work with JIRA for a living and my team mostly hates it, I can only imagine the willingness of casual contributors to deal with it. How do you do an inline patch review in JIRA? How do you update patches automatically? It's never about particular tools, it's all about making smart choices. Once that choice is done, moving out to something else requires a significant effort, you need to pull all this history you built about your software into your new bug tracking solution. You can't loose this, it's your software collective memory. All this discussion around pull request IMO is more an expression of human lazyness. Having to document is always seen as a chore by most developpers. This is not an arcane human trait, it has been known for decades. Laziness? Time is our most important resource and we should always be mindful of the time people have to invest (waste) to contribute to our projects. For me lowering the bar to entry is the same as respecting the time of the person on the other end of the ticket/patch/whatever. If you take a look at my profile on GitHub you'll see I maintain a few projects and I go to great lengths to make sure all the projects are inviting and
Re: #{:rant} Questions about contribution policy and clojure compiler source.
On 18 July 2015 at 22:52, Luc Préfontaine lprefonta...@softaddicts.ca wrote: Each linux kernel release involves hundreds of people. Many release had above a thousand contributors. This is for your enlightenment and are old figures: http://royal.pingdom.com/2012/04/16/linux-kernel-development-numbers/ Did you even read this article? 75% – The share of all kernel development that is done by developers who are being paid for their work. This doesn't exactly contract what I said. There are as many people not officially hired to work for linux operating system focused businesses that submit patches through the ticketing system. As for the development lifecycle of the linux kernel: http://www.linuxfoundation.org/content/22-lifecycle-patch You can read the other sections, if you find the Clojure dev. lifecycle arcane, you will freak at this one. Obviously, these guys must all be old fashion outdated folks in this era of instant communication and snapchat like media, there's no other explanation for such a bureaucratic process :) How much pain is it to upgrade to a new Clojure version ? Nil. How much pain is it to upgrade to a new linux kernel ? Not nil but considering the size of this project, its ramifications and the hardware changing every 6 months, not big. On par with Clojure I would say. How much pain to upgrade to a new version of Ruby on Rails ? Huge. I know, I have been through this a number of times. Not just major releases, even maintenance ones are a nightmare to upgrade. Disclaimer: I am not saying that Rails has a bad lifecycle, I am just stating feedback from me and other people that actually lived this. Gee, I sound like Mallard Fillmore... That's for the political correctness of this post. And to avoid being harassed, sued, whatever. I would like us to compare carrots with carrots, not with apples or strawberries but if you insist To me the result is utterly important. We deliver 24/7 software under linux using Clojure. We have up times of more than 300 days. One upgrade a year. This is the world that live into. Making it 'harder to contribute' like you state is the price to pay for some form of quality control. Contributing to something that eventually crumbles because of a lack of QA is of no value. To us all. Stuart has made this evaluation. Since it models by some aspect how a successful project like Linux is managed, I find it hard to throw a stone at the current lifecycle. That may look to you as an ultra-conservative approach. Let's put it this way, I would use Linux and Clojure to control a nuclear plant anytime. I am quite certain sure I would not use Rails or Ruby for this purpose. As this conversation isn't really going anywhere I'll keep my thoughts to myself. Luc P. Luc P. Sent from my iPad On Jul 18, 2015, at 14:32, Bozhidar Batsov bozhi...@batsov.com wrote: On 18 July 2015 at 20:18, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. So, Ruby on Rails is a small project, right? And if we have many contributors we should show no respect for their time - we should actually make it harder to contribute, so it'd be easier on us, right? Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Many projects predate GitHub, yet they eventually adopted it. And it's never about GitHub in particular - it's only about making things efficient and pleasant for everyone involved. I work with JIRA for a living and my team mostly hates it, I can only imagine the willingness of casual contributors to deal with it. How do you do an inline patch review in JIRA? How do you update patches automatically? It's never about particular tools, it's all about making smart choices. Once that choice is done, moving out to something else requires a significant effort, you need to pull all this history you built about your software into your new bug tracking solution. You can't loose this, it's your software collective memory. All this discussion around pull request IMO is more an expression of human lazyness. Having to document is always seen as a chore by most developpers. This is not an arcane human trait, it has been known for decades. Laziness? Time is our most important resource and we should always be mindful of the
Re: How to implement a distributed and concurrent system in Clojure?
David, Have your opinion on Akka changed since 2013 now that you have seen its progress ? I am very interested in your opinion. Regards, Mateusz W dniu czwartek, 4 lipca 2013 11:39:46 UTC+2 użytkownik David Pollak napisał: Please keep in mind that Scala's Actor Model is a very thin piece of code that is not inherently distributed. There are a ton of issues in Scala related to crossing address spaces. Scala is not nearly as biased to immutability as Clojure. Sure, there are case classes, but case classes can easily contain mutable data. When I wrote Goat Rodeo (http://goatrodeo.org), I wrote a compiler plugin that guaranteed immutability and serializability of the data structures used for Goat Rodeo's Actor-based messaging... and this lead to the second issue... Having a class-based design means that one has to deal with serializing/deserializing class-based data structures. This is a huge problem. It means that the inter-process data structures must contain class signatures... and for distributed systems that are going to have 100% uptime, that means version and class signatures so that a message sent from a version 1 system can be deserialized on a version 2 system even if the class has changed. Long story short... Akka, the only popular distributed system in Scala, is marginally better than RMI/J/EE, so for enterprise java shops, it's great (much like Spring was.) But it's not something to aspire to. If I get some time, I'll work on a distributed version of core.async. The only real challenge I can see is marshalling a Channel identifier across address spaces. Everything else should be a walk in the park. On Wed, Jul 3, 2013 at 5:26 PM, Hussein B. hubag...@gmail.com javascript: wrote: Hi, I read recently on the internet that Clojure concurrency tools make it easy to implement a highly concurrent system but on a single machine. But how to implement a highly concurrent system that runs on a multiple machines? Erlang, Elixir and Scala have the Actors model. Please correct me if I'm wrong. Thanks for help and time. -- -- 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/groups/opt_out. -- 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: #{:rant} Questions about contribution policy and clojure compiler source.
Andrey: Pull requests have come up many times before, but since it has been quite some time since the last time, perhaps most people have not seen Rich's answer the last time he responded to it. Below is a direct link, if you want to read it. The short answer is that he prefers the work flow of reviewing submitted patches. It is easier for him. He is not doing it to try to make it harder on others. https://groups.google.com/forum/#!msg/clojure/jWMaop_eVaQ/3M4gddaXDZoJ Andy On Sat, Jul 18, 2015 at 10:32 AM, Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 8:18 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Once that choice is done, moving out to something else requires a significant effort, you need to pull all this history you built about your software into your new bug tracking solution. You can't loose this, it's your software collective memory. All this discussion around pull request IMO is more an expression of human lazyness. Having to document is always seen as a chore by most developpers. This is not an arcane human trait, it has been known for decades. Anything else requires a discussion forum if you want to maintain a minimal level of quality and allow some discussions around the issue being fixed in a large team effort/critical piece of software. A mailing list is not at par with a bug tracking system in this regard. Curiously, linux has a bug tracking system and people submit patches or links are made to patches. Take a walk on launchpad. No serious software business would drive their dev without a tracking system. Open source projects are no different if they want to attain some level of success. If critical open source is to be used by businesses, it has to play with similar tools. Clojure too me is critical to my business and to many others. It cannot fail on us. It would be like building pyramids on moving sand. Again there's no Kumbaya song playing here. As a last note, Alex Miller must dream about the emails exchanged on the mailing list. Suggestions are certainly looked upon and discussed upstream. It does not mean that they will be considered worth to investigate/implement or they may come out differently (that ego thing looming again). +1 for Jira and patches. The django community works with both tools. Pull request are just for code review and patch attachment mechanism, and bug tracking system for coordinate the efforts. Both them are not incompatible. And django core team is not precisely small. The Pull-Request is not about laziness, is about eliminate friction. And allow better and more human friendly code review process. I'm only try improve the contribution process and IMHO your tone is a little bit out of place. Luc P. On Sat, 18 Jul 2015 19:05:16 +0300 Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 6:48 PM, Colin Yates colin.ya...@gmail.com wrote: +1 (although I maybe wouldn’t be so mocking in my tone ;-). Since when did software design by committee work; anyone remember J2EE? (and yes, that does deserve my mocking tone). I have no idea about the details being discussed here/why people’s noses are out of joint, but I can think of as many success with a single overlord in place as there are failures caused by political infighting. In general, I'm pretty happy with the benevolent dictator approach. But some openness would be awesome. As first think that comes in my mind is: have a clear roadmap for Clojure and its core libraries such as core.async. Some channel for requesting features, and the ability to know a opinion of the clojure core team about the possibility of the inclusion of some requested feature. Also would be awesome have more painless contribution process. I'm ok for signing CA, but using patches instead of something like pull requests (with or without additional review tool) is very arcane and uncomfortable process. I don't suggest to change to something similar to design by committee. I only suggest that make some facilities for contribute may attract more interesting people. And will make more happy excellent contributors like Zach Tellman or Aphyr. I
Re: #{:rant} Questions about contribution policy and clojure compiler source.
You mentionned RedHat Linux centric type corporations. There are a lot more businesses that are not Linux centric business wise. They use it but provide something else on top. Did you even read this article against your own statement ? :) A huge number of occasional contributors were not reluctant to log a ticket and submit a patch instead of ranting about it. This is the main point you missed. That 'entry barrier' of yours does not stand with Linux. I would think hard about the reasons behind these numbers. There has to be some value added in the process of submitting patches. Luc P. On Sat, 18 Jul 2015 23:02:30 +0300 Bozhidar Batsov bozhi...@batsov.com wrote: On 18 July 2015 at 22:52, Luc Préfontaine lprefonta...@softaddicts.ca wrote: Each linux kernel release involves hundreds of people. Many release had above a thousand contributors. This is for your enlightenment and are old figures: http://royal.pingdom.com/2012/04/16/linux-kernel-development-numbers/ Did you even read this article? 75% – The share of all kernel development that is done by developers who are being paid for their work. This doesn't exactly contract what I said. There are as many people not officially hired to work for linux operating system focused businesses that submit patches through the ticketing system. As for the development lifecycle of the linux kernel: http://www.linuxfoundation.org/content/22-lifecycle-patch You can read the other sections, if you find the Clojure dev. lifecycle arcane, you will freak at this one. Obviously, these guys must all be old fashion outdated folks in this era of instant communication and snapchat like media, there's no other explanation for such a bureaucratic process :) How much pain is it to upgrade to a new Clojure version ? Nil. How much pain is it to upgrade to a new linux kernel ? Not nil but considering the size of this project, its ramifications and the hardware changing every 6 months, not big. On par with Clojure I would say. How much pain to upgrade to a new version of Ruby on Rails ? Huge. I know, I have been through this a number of times. Not just major releases, even maintenance ones are a nightmare to upgrade. Disclaimer: I am not saying that Rails has a bad lifecycle, I am just stating feedback from me and other people that actually lived this. Gee, I sound like Mallard Fillmore... That's for the political correctness of this post. And to avoid being harassed, sued, whatever. I would like us to compare carrots with carrots, not with apples or strawberries but if you insist To me the result is utterly important. We deliver 24/7 software under linux using Clojure. We have up times of more than 300 days. One upgrade a year. This is the world that live into. Making it 'harder to contribute' like you state is the price to pay for some form of quality control. Contributing to something that eventually crumbles because of a lack of QA is of no value. To us all. Stuart has made this evaluation. Since it models by some aspect how a successful project like Linux is managed, I find it hard to throw a stone at the current lifecycle. That may look to you as an ultra-conservative approach. Let's put it this way, I would use Linux and Clojure to control a nuclear plant anytime. I am quite certain sure I would not use Rails or Ruby for this purpose. As this conversation isn't really going anywhere I'll keep my thoughts to myself. Luc P. Luc P. Sent from my iPad On Jul 18, 2015, at 14:32, Bozhidar Batsov bozhi...@batsov.com wrote: On 18 July 2015 at 20:18, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. So, Ruby on Rails is a small project, right? And if we have many contributors we should show no respect for their time - we should actually make it harder to contribute, so it'd be easier on us, right? Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Many projects predate GitHub, yet they eventually adopted it. And it's never about GitHub in particular - it's only about making things efficient and pleasant for everyone involved. I work with JIRA for a living and my team mostly hates
Re: #{:rant} Questions about contribution policy and clojure compiler source.
I don't think the tweets you link are the 'normal approach'. I would call them pretty unusual in several aspects. For one, I think that for the vast majority of Clojure tickets created, no on asks and gets Rich's comments on them before they are created. Second, most end up being committed as the submitter created them, with fewer rounds of review and updates. Most of them are a lot less work on the part of the contributor than the two examples mentioned. Note: I am not saying that those two examples didn't happen, or that there are no others like that. I am saying they are unusual examples, as compared to the great majority of Clojure tickets. Most tickets that have a change committed for them end up being committed as a patch submitted by a contributor, without being implemented differently. It is fairly common for there to be months or years of waiting time for a ticket to be considered. Rich is one person, and like most people, he gets to choose how much time he spends on volunteer projects, and what projects those are. Alex Miller spends a significant fraction of his time tending to tickets and commenting on and reviewing patches. As for indentation of Java code, it is called Whitesmiths style: https://en.wikipedia.org/wiki/Indent_style#Whitesmiths_style Clojure was the first project I came across using this indentation style, but Rich isn't the only one to use it. A few bits of code have crept in over the years using other indentation styles, usually contributed by others. Andy On Sat, Jul 18, 2015 at 4:13 AM, Andrey Antukh n...@niwi.nz wrote: Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little bit opaque... An other question: Why the great amount of clojure compiler code has no indentation style and bunch of commented code. It is indented like a freshman. Sorry, I don't want offend any one, but eyes hurt when reading the code compiler clojure (obviously I'm speaking about the look and feel, and no the quality of the code). Some examples: Indentation (or maybe no indentation): https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86 Bunch of commented code and also no indentation: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AMapEntry.java#L60 If you compare some clojure compiler code with different code snippets from other languages, the indentation is clearly more cared: Kotlin: https://github.com/JetBrains/kotlin/blob/master/core/descriptors/src/org/jetbrains/kotlin/types/AbstractClassTypeConstructor.java#L44 Rust: https://github.com/rust-lang/rust/blob/master/src/libstd/io/buffered.rs#L165 Ceylon: https://github.com/ceylon/ceylon-compiler/blob/master/src/com/redhat/ceylon/compiler/java/codegen/AttributeDefinitionBuilder.java#L233 This is a random list of code snippets from different compilers with indentation that is more human friendly. I don't intend judge any one, but when a I learn Clojure compiler I expect something different. I expect something more carefully done. No body thinks the same thing that me? I think that have a sane, more open contribution policy, with clear and more cared code formatting, is not very complicated thing and is going to favor the clojure and its community. Andrey -- Andrey Antukh - Андрей Антух - n...@niwi.nz http://www.niwi.nz https://github.com/niwinz -- 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
Re: #{:rant} Questions about contribution policy and clojure compiler source.
On Sat, Jul 18, 2015 at 6:21 AM, Bozhidar Batsov bozhi...@batsov.com wrote: On 18 July 2015 at 14:13, Andrey Antukh n...@niwi.nz wrote: Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little bit opaque... Many people feel this way, but ultimately Clojure is Rich's project and I guess Cognitect's to some extent. If they don't want to run it like other more open contribution-friendly OSS projects this is obviously their right. This is a line of response I don't really understand; sure, it's within Rich's/Cognitect's rights to run the project as they please, but I don't think any of the aggrieved parties is claiming that Rich did something he had no *right* to do. One can still suggest that the way the project's run (or the way these specific issues were handled) is unwise or shabby or otherwise capable of improvement. No one has to take the suggestion, but it might be better if they did. -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- 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: #{:rant} Questions about contribution policy and clojure compiler source.
On Sat, Jul 18, 2015 at 8:18 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Once that choice is done, moving out to something else requires a significant effort, you need to pull all this history you built about your software into your new bug tracking solution. You can't loose this, it's your software collective memory. All this discussion around pull request IMO is more an expression of human lazyness. Having to document is always seen as a chore by most developpers. This is not an arcane human trait, it has been known for decades. Anything else requires a discussion forum if you want to maintain a minimal level of quality and allow some discussions around the issue being fixed in a large team effort/critical piece of software. A mailing list is not at par with a bug tracking system in this regard. Curiously, linux has a bug tracking system and people submit patches or links are made to patches. Take a walk on launchpad. No serious software business would drive their dev without a tracking system. Open source projects are no different if they want to attain some level of success. If critical open source is to be used by businesses, it has to play with similar tools. Clojure too me is critical to my business and to many others. It cannot fail on us. It would be like building pyramids on moving sand. Again there's no Kumbaya song playing here. As a last note, Alex Miller must dream about the emails exchanged on the mailing list. Suggestions are certainly looked upon and discussed upstream. It does not mean that they will be considered worth to investigate/implement or they may come out differently (that ego thing looming again). +1 for Jira and patches. The django community works with both tools. Pull request are just for code review and patch attachment mechanism, and bug tracking system for coordinate the efforts. Both them are not incompatible. And django core team is not precisely small. The Pull-Request is not about laziness, is about eliminate friction. And allow better and more human friendly code review process. I'm only try improve the contribution process and IMHO your tone is a little bit out of place. Luc P. On Sat, 18 Jul 2015 19:05:16 +0300 Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 6:48 PM, Colin Yates colin.ya...@gmail.com wrote: +1 (although I maybe wouldn’t be so mocking in my tone ;-). Since when did software design by committee work; anyone remember J2EE? (and yes, that does deserve my mocking tone). I have no idea about the details being discussed here/why people’s noses are out of joint, but I can think of as many success with a single overlord in place as there are failures caused by political infighting. In general, I'm pretty happy with the benevolent dictator approach. But some openness would be awesome. As first think that comes in my mind is: have a clear roadmap for Clojure and its core libraries such as core.async. Some channel for requesting features, and the ability to know a opinion of the clojure core team about the possibility of the inclusion of some requested feature. Also would be awesome have more painless contribution process. I'm ok for signing CA, but using patches instead of something like pull requests (with or without additional review tool) is very arcane and uncomfortable process. I don't suggest to change to something similar to design by committee. I only suggest that make some facilities for contribute may attract more interesting people. And will make more happy excellent contributors like Zach Tellman or Aphyr. I think that things like this are not very complicated to adopt and has a lot of benefit. My two cents! On 18 Jul 2015, at 16:44, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Sure, indentation is what gets the code running on metal :)) Not ranting here, just my abs dying from the pain as I laugh :)) As for the contrib process, go have a look at Linux. You'll be happy that Rich is cool by every meaning of the word. There's this misconception about open source that we should all wear flower collars and sing Kumbaya.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Excuse-me if I hurt your personal feelings but most of the proponents of pull requests so far have been in fact extremely allergic to report problems/improvements in Jira first before submitting a code change. I was addressing this audience because this subject comes back over and over again. My tone does not please you ? It could be worse and I reserve my right to free speech. Have a look at some Linus rants. I am far from that level. I restrain myself as much as I can :) Believe me. There's nothing that makes me shiver more than political correctness. Now back to real issues: a) If you have a ticket in Jira and no patch attached to it, how do you link that with your code base ? How can you avoid issuing a patch ? How can a reviewer figure out exactly the scope of your changes if they are no patches attached to it ? b) You can propose improvements through Jira plus the mailing list. What would be a better alternative ? c) How do you preserve history of changes and code mutations throughout this process ? These are practical workflow issues. If you can shed some light on this and suggest an improved workflow, there are people listening. There's no free lunch but many people would like one. To me it boils down to this question: Can the needs of one person compromise a group effort ? I don't think so. But this is only my opinion. Luc P. Sent from my iPad On Jul 18, 2015, at 13:32, Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 8:18 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Once that choice is done, moving out to something else requires a significant effort, you need to pull all this history you built about your software into your new bug tracking solution. You can't loose this, it's your software collective memory. All this discussion around pull request IMO is more an expression of human lazyness. Having to document is always seen as a chore by most developpers. This is not an arcane human trait, it has been known for decades. Anything else requires a discussion forum if you want to maintain a minimal level of quality and allow some discussions around the issue being fixed in a large team effort/critical piece of software. A mailing list is not at par with a bug tracking system in this regard. Curiously, linux has a bug tracking system and people submit patches or links are made to patches. Take a walk on launchpad. No serious software business would drive their dev without a tracking system. Open source projects are no different if they want to attain some level of success. If critical open source is to be used by businesses, it has to play with similar tools. Clojure too me is critical to my business and to many others. It cannot fail on us. It would be like building pyramids on moving sand. Again there's no Kumbaya song playing here. As a last note, Alex Miller must dream about the emails exchanged on the mailing list. Suggestions are certainly looked upon and discussed upstream. It does not mean that they will be considered worth to investigate/implement or they may come out differently (that ego thing looming again). +1 for Jira and patches. The django community works with both tools. Pull request are just for code review and patch attachment mechanism, and bug tracking system for coordinate the efforts. Both them are not incompatible. And django core team is not precisely small. The Pull-Request is not about laziness, is about eliminate friction. And allow better and more human friendly code review process. I'm only try improve the contribution process and IMHO your tone is a little bit out of place. Luc P. On Sat, 18 Jul 2015 19:05:16 +0300 Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 6:48 PM, Colin Yates colin.ya...@gmail.com wrote: +1 (although I maybe wouldn’t be so mocking in my tone ;-). Since when did software design by committee work; anyone remember J2EE? (and yes, that does deserve my mocking tone). I have no idea about the details being discussed here/why people’s noses are out of joint, but I can think of as many success with a single overlord in
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Once that choice is done, moving out to something else requires a significant effort, you need to pull all this history you built about your software into your new bug tracking solution. You can't loose this, it's your software collective memory. All this discussion around pull request IMO is more an expression of human lazyness. Having to document is always seen as a chore by most developpers. This is not an arcane human trait, it has been known for decades. Anything else requires a discussion forum if you want to maintain a minimal level of quality and allow some discussions around the issue being fixed in a large team effort/critical piece of software. A mailing list is not at par with a bug tracking system in this regard. Curiously, linux has a bug tracking system and people submit patches or links are made to patches. Take a walk on launchpad. No serious software business would drive their dev without a tracking system. Open source projects are no different if they want to attain some level of success. If critical open source is to be used by businesses, it has to play with similar tools. Clojure too me is critical to my business and to many others. It cannot fail on us. It would be like building pyramids on moving sand. Again there's no Kumbaya song playing here. As a last note, Alex Miller must dream about the emails exchanged on the mailing list. Suggestions are certainly looked upon and discussed upstream. It does not mean that they will be considered worth to investigate/implement or they may come out differently (that ego thing looming again). +1 for Jira and patches. Luc P. On Sat, 18 Jul 2015 19:05:16 +0300 Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 6:48 PM, Colin Yates colin.ya...@gmail.com wrote: +1 (although I maybe wouldn’t be so mocking in my tone ;-). Since when did software design by committee work; anyone remember J2EE? (and yes, that does deserve my mocking tone). I have no idea about the details being discussed here/why people’s noses are out of joint, but I can think of as many success with a single overlord in place as there are failures caused by political infighting. In general, I'm pretty happy with the benevolent dictator approach. But some openness would be awesome. As first think that comes in my mind is: have a clear roadmap for Clojure and its core libraries such as core.async. Some channel for requesting features, and the ability to know a opinion of the clojure core team about the possibility of the inclusion of some requested feature. Also would be awesome have more painless contribution process. I'm ok for signing CA, but using patches instead of something like pull requests (with or without additional review tool) is very arcane and uncomfortable process. I don't suggest to change to something similar to design by committee. I only suggest that make some facilities for contribute may attract more interesting people. And will make more happy excellent contributors like Zach Tellman or Aphyr. I think that things like this are not very complicated to adopt and has a lot of benefit. My two cents! On 18 Jul 2015, at 16:44, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Sure, indentation is what gets the code running on metal :)) Not ranting here, just my abs dying from the pain as I laugh :)) As for the contrib process, go have a look at Linux. You'll be happy that Rich is cool by every meaning of the word. There's this misconception about open source that we should all wear flower collars and sing Kumbaya. Mostly a 60's view of human collaboration. That ain't the way to get it done. It works for ants and termites, they work as groups but we are human beings with our strong individuality. Some form of central control is needed. Opposed by traction from some individuals that would like to move faster or in other directions. This is ok but not at the expense of the cohesion of the end result. Hence this tensed balance. Rich created Clojure, he knows were he wants to go with it. Any ideas we bring in the process is evaluated. However not all of them make sense or are worth the effort to implement.
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Everyone: let's keep the tone civil. Andrey: thanks for your workflow suggestions. I politely re-decline all of them, having considered all your points multiple times over several years and having chosen approaches that I believe are better matched with my objectives. The objective of Clojure contributions is Clojure, not contribution. The proof is in the pudding. Sent from my iPad On Jul 18, 2015, at 1:32 PM, Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 8:18 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may work for a very small team. The # of clojure contributors far excess that size. Pull requests/gitbhub issues are used by Clojure library maintainers outside of the core, their respective contributor team size makes this usable. Choosing one tracking system is a feat by itself, Jira does everything albeit it may be a beast to configure. I think that the choice of Jira predates moving the Clojure code from google to github but I may be wrong. The github tracking system was not at par with Jira features at that time anyway. Once that choice is done, moving out to something else requires a significant effort, you need to pull all this history you built about your software into your new bug tracking solution. You can't loose this, it's your software collective memory. All this discussion around pull request IMO is more an expression of human lazyness. Having to document is always seen as a chore by most developpers. This is not an arcane human trait, it has been known for decades. Anything else requires a discussion forum if you want to maintain a minimal level of quality and allow some discussions around the issue being fixed in a large team effort/critical piece of software. A mailing list is not at par with a bug tracking system in this regard. Curiously, linux has a bug tracking system and people submit patches or links are made to patches. Take a walk on launchpad. No serious software business would drive their dev without a tracking system. Open source projects are no different if they want to attain some level of success. If critical open source is to be used by businesses, it has to play with similar tools. Clojure too me is critical to my business and to many others. It cannot fail on us. It would be like building pyramids on moving sand. Again there's no Kumbaya song playing here. As a last note, Alex Miller must dream about the emails exchanged on the mailing list. Suggestions are certainly looked upon and discussed upstream. It does not mean that they will be considered worth to investigate/implement or they may come out differently (that ego thing looming again). +1 for Jira and patches. The django community works with both tools. Pull request are just for code review and patch attachment mechanism, and bug tracking system for coordinate the efforts. Both them are not incompatible. And django core team is not precisely small. The Pull-Request is not about laziness, is about eliminate friction. And allow better and more human friendly code review process. I'm only try improve the contribution process and IMHO your tone is a little bit out of place. Luc P. On Sat, 18 Jul 2015 19:05:16 +0300 Andrey Antukh n...@niwi.nz wrote: On Sat, Jul 18, 2015 at 6:48 PM, Colin Yates colin.ya...@gmail.com wrote: +1 (although I maybe wouldn’t be so mocking in my tone ;-). Since when did software design by committee work; anyone remember J2EE? (and yes, that does deserve my mocking tone). I have no idea about the details being discussed here/why people’s noses are out of joint, but I can think of as many success with a single overlord in place as there are failures caused by political infighting. In general, I'm pretty happy with the benevolent dictator approach. But some openness would be awesome. As first think that comes in my mind is: have a clear roadmap for Clojure and its core libraries such as core.async. Some channel for requesting features, and the ability to know a opinion of the clojure core team about the possibility of the inclusion of some requested feature. Also would be awesome have more painless contribution process. I'm ok for signing CA, but using patches instead of something like pull requests (with or without additional review tool) is very arcane and uncomfortable process. I don't suggest to change to something similar to design by committee. I only suggest that make some facilities for contribute may attract more interesting people. And will make more happy excellent contributors like Zach Tellman or Aphyr. I think that things like this are not very complicated
Re: #{:rant} Questions about contribution policy and clojure compiler source.
+1 (although I maybe wouldn’t be so mocking in my tone ;-). Since when did software design by committee work; anyone remember J2EE? (and yes, that does deserve my mocking tone). I have no idea about the details being discussed here/why people’s noses are out of joint, but I can think of as many success with a single overlord in place as there are failures caused by political infighting. On 18 Jul 2015, at 16:44, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Sure, indentation is what gets the code running on metal :)) Not ranting here, just my abs dying from the pain as I laugh :)) As for the contrib process, go have a look at Linux. You'll be happy that Rich is cool by every meaning of the word. There's this misconception about open source that we should all wear flower collars and sing Kumbaya. Mostly a 60's view of human collaboration. That ain't the way to get it done. It works for ants and termites, they work as groups but we are human beings with our strong individuality. Some form of central control is needed. Opposed by traction from some individuals that would like to move faster or in other directions. This is ok but not at the expense of the cohesion of the end result. Hence this tensed balance. Rich created Clojure, he knows were he wants to go with it. Any ideas we bring in the process is evaluated. However not all of them make sense or are worth the effort to implement. Aside from our respective ego being hurt because our ideas are not retained or our contribs vetted in the first pass there's little damage done. If it was not the case Clojure would have zero traction and Linux likewise. Search for Linus rants about contributors and try to relate this with the level of success of Linux. They are not so many open source projects that have the same stability from release to release as Clojure or Linux. Control and absence of complacency are key factors to achieve this kind of success. Luc P. Sent from my iPhone On Jul 18, 2015, at 07:13, Andrey Antukh n...@niwi.nz mailto:n...@niwi.nz wrote: Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little bit opaque... An other question: Why the great amount of clojure compiler code has no indentation style and bunch of commented code. It is indented like a freshman. Sorry, I don't want offend any one, but eyes hurt when reading the code compiler clojure (obviously I'm speaking about the look and feel, and no the quality of the code). Some examples: Indentation (or maybe no indentation): https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86 https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86 Bunch of commented code and also no indentation: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AMapEntry.java#L60 https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AMapEntry.java#L60 If you compare some clojure compiler code with different code snippets from other languages, the indentation is clearly more cared: Kotlin: https://github.com/JetBrains/kotlin/blob/master/core/descriptors/src/org/jetbrains/kotlin/types/AbstractClassTypeConstructor.java#L44 https://github.com/JetBrains/kotlin/blob/master/core/descriptors/src/org/jetbrains/kotlin/types/AbstractClassTypeConstructor.java#L44 Rust: https://github.com/rust-lang/rust/blob/master/src/libstd/io/buffered.rs#L165 https://github.com/rust-lang/rust/blob/master/src/libstd/io/buffered.rs#L165 Ceylon: https://github.com/ceylon/ceylon-compiler/blob/master/src/com/redhat/ceylon/compiler/java/codegen/AttributeDefinitionBuilder.java#L233 https://github.com/ceylon/ceylon-compiler/blob/master/src/com/redhat/ceylon/compiler/java/codegen/AttributeDefinitionBuilder.java#L233 This is a random list of code snippets from different compilers with indentation that is more human friendly. I don't intend judge any one, but when a I learn Clojure compiler I expect something different. I expect something more carefully done. No body thinks the same thing that me? I think that have a sane, more open contribution policy, with clear and more cared code formatting, is not very complicated thing and is going to favor the clojure and its community. Andrey -- Andrey Antukh - Андрей Антух - n...@niwi.nz mailto:n...@niwi.nz
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Sure, indentation is what gets the code running on metal :)) Not ranting here, just my abs dying from the pain as I laugh :)) As for the contrib process, go have a look at Linux. You'll be happy that Rich is cool by every meaning of the word. There's this misconception about open source that we should all wear flower collars and sing Kumbaya. Mostly a 60's view of human collaboration. That ain't the way to get it done. It works for ants and termites, they work as groups but we are human beings with our strong individuality. Some form of central control is needed. Opposed by traction from some individuals that would like to move faster or in other directions. This is ok but not at the expense of the cohesion of the end result. Hence this tensed balance. Rich created Clojure, he knows were he wants to go with it. Any ideas we bring in the process is evaluated. However not all of them make sense or are worth the effort to implement. Aside from our respective ego being hurt because our ideas are not retained or our contribs vetted in the first pass there's little damage done. If it was not the case Clojure would have zero traction and Linux likewise. Search for Linus rants about contributors and try to relate this with the level of success of Linux. They are not so many open source projects that have the same stability from release to release as Clojure or Linux. Control and absence of complacency are key factors to achieve this kind of success. Luc P. Sent from my iPhone On Jul 18, 2015, at 07:13, Andrey Antukh n...@niwi.nz wrote: Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little bit opaque... An other question: Why the great amount of clojure compiler code has no indentation style and bunch of commented code. It is indented like a freshman. Sorry, I don't want offend any one, but eyes hurt when reading the code compiler clojure (obviously I'm speaking about the look and feel, and no the quality of the code). Some examples: Indentation (or maybe no indentation): https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86 Bunch of commented code and also no indentation: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AMapEntry.java#L60 If you compare some clojure compiler code with different code snippets from other languages, the indentation is clearly more cared: Kotlin: https://github.com/JetBrains/kotlin/blob/master/core/descriptors/src/org/jetbrains/kotlin/types/AbstractClassTypeConstructor.java#L44 Rust: https://github.com/rust-lang/rust/blob/master/src/libstd/io/buffered.rs#L165 Ceylon: https://github.com/ceylon/ceylon-compiler/blob/master/src/com/redhat/ceylon/compiler/java/codegen/AttributeDefinitionBuilder.java#L233 This is a random list of code snippets from different compilers with indentation that is more human friendly. I don't intend judge any one, but when a I learn Clojure compiler I expect something different. I expect something more carefully done. No body thinks the same thing that me? I think that have a sane, more open contribution policy, with clear and more cared code formatting, is not very complicated thing and is going to favor the clojure and its community. Andrey -- Andrey Antukh - Андрей Антух - n...@niwi.nz http://www.niwi.nz https://github.com/niwinz -- 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
Re: #{:rant} Questions about contribution policy and clojure compiler source.
Re jira: we have started the process to upgrade some of the current infrastructure. This will take a while (likely months) as it involves contracts, purchases, and upgrades (where jira does not have a stellar reputation). Even jira from N years ago is significantly more capable than the github issues of today, for those of us that use it every hour of the day. Re PRs: this has been rehashed a zillion times. It may change in the future. It's not changing right now. I believe the newer jira versions have the ability to do interesting things with patches/PRs and that's something we will look at. Re contribution process: I appreciate Andy's comments and largely agree. The majority of small tickets flow through the existing system just fine and are applied as they were created by the submitter (and/or updated based on review). It's particularly nice to see lots of new names in the commits for 1.8.0-alpha2 (https://github.com/clojure/clojure/commits/master). Re releases and ticket delays: The 1.7 release took an unexpectedly long time to close out. There are many reasons for that, but they're irrelevant. We have published (for the first time ever) a target freeze date for the 1.8 date and are actively moving dozens of tickets through the process (see the Screened report for the next batch). It's hard to see, but a lot of attention has been paid by me to putting highly voted tickets high in this queue (this was done even during the 1.7 close-out, in some cases pulling high desire tickets late in the release). Re bigger features and in particular the comments at the top of this thread: Zach's comments are available. You can see Rich's view in the ticket comments http://dev.clojure.org/jira/browse/CLJ-1517?focusedCommentId=39972page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-39972. We will try to set better expectations for these bigger changes in the future. Alex -- 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: #{:rant} Questions about contribution policy and clojure compiler source.
I'm speaking very much as a passenger in this community, and I've had the privilege of meeting just a few of you people, but that may be no handicap. It's a worthwhile debate to have, but this is very much an edge case. Rich has kindly and wisely reduced his own bum-print in the ecosystem so much that the majority of what other languages include is found in higher velocity libraries. For small changes to core (and core libs) as Andy said, contribs are often incorporated whole after feedback. This change by Zach is by these standards enormous, so it's not going to follow that route. Again, for small or cosmetic changes, credit is sufficient feedback for most (otherwise do something else), but in this case there is a question to be answered about the manner by which Zach's hand-wrought (and iterated by request) code was effectively redone unilaterally. I agree with Luc and Colin on the link between the success of Clojure and Rich's insistence on doing things his way. We are all here because this is the case and Clojure the language is as clean and simple as Rich can keep it. However, this example proves that Rich is not omniscient (though we do all love him dearly). It took months of work by Zach to turn a belief into a provable case to make fundamental changes to the implementation of small data structures. We all need to foster such dedication to improving the language many of us have bet our careers on. This episode is not likely to encourage the next girl to do that work. Alex has put ZT front and centre for credit for the update, and made it the centrepiece of the new release, and that's great. But I think some comments from someone inside the temple might also be of use. Who knows, maybe this prompts a rethink of how the pipeline works in the future.. That perhaps would be a suitable response to Zach's contribution to both language and community. -- Fergal Byrne, Brenter IT Author, Real Machine Intelligence with Clortex and NuPIC https://leanpub.com/realsmartmachines Speaking on Clortex and HTM/CLA at euroClojure Krakow, June 2014: http://euroclojure.com/2014/ and at LambdaJam Chicago, July 2014: http://www.lambdajam.com http://inbits.com - Better Living through Thoughtful Technology http://ie.linkedin.com/in/fergbyrne/ - https://github.com/fergalbyrne e:fergalbyrnedub...@gmail.com t:+353 83 4214179 Join the quest for Machine Intelligence at http://numenta.org Formerly of Adnet edi...@adnet.ie http://www.adnet.ie On Saturday 18 Jul 2015 at 17:17, Ben Wolfson wolf...@gmail.com, wrote: On Sat, Jul 18, 2015 at 6:21 AM, Bozhidar Batsov bozhi...@batsov.com wrote: On 18 July 2015 at 14:13, Andrey Antukh n...@niwi.nz wrote: Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little bit opaque... Many people feel this way, but ultimately Clojure is Rich's project and I guess Cognitect's to some extent. If they don't want to run it like other more open contribution-friendly OSS projects this is obviously their right. This is a line of response I don't really understand; sure, it's within Rich's/Cognitect's rights to run the project as they please, but I don't think any of the aggrieved parties is claiming that Rich did something he had no *right* to do. One can still suggest that the way the project's run (or the way these specific issues were handled) is unwise or shabby or otherwise capable of improvement. No one has to take the suggestion, but it might be better if they did. -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- 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
Re: #{:rant} Questions about contribution policy and clojure compiler source.
On 18 July 2015 at 18:44, Luc Prefontaine lprefonta...@softaddicts.ca wrote: Sure, indentation is what gets the code running on metal :)) That remark is wrong on so many levels... In the words of the legendary SICP authors - Programs must be written for people to read, and only incidentally for machines to execute. Not ranting here, just my abs dying from the pain as I laugh :)) As for the contrib process, go have a look at Linux. You'll be happy that Rich is cool by every meaning of the word. I've been involved in many OSS project and certainly there are projects where the contribution process is worse than Clojure's. I do believe, however, that pointing that things could be worse in not the right attitude. There's always room for improvement. There's this misconception about open source that we should all wear flower collars and sing Kumbaya. Mostly a 60's view of human collaboration. That ain't the way to get it done. It works for ants and termites, they work as groups but we are human beings with our strong individuality. Some form of central control is needed. Opposed by traction from some individuals that would like to move faster or in other directions. Central control is not the same as dictator. It's not uncommon for projects to have several leaders. Sure, having less people on the top makes it easier to make decisions, but it also makes it easier to make mistakes (not to mention it creates bottlenecks here and there). This is ok but not at the expense of the cohesion of the end result. Hence this tensed balance. Rich created Clojure, he knows were he wants to go with it. Any ideas we bring in the process is evaluated. However not all of them make sense or are worth the effort to implement. Aside from our respective ego being hurt because our ideas are not retained or our contribs vetted in the first pass there's little damage done. I doubt anyone thinks something like this is a big problem. After all it's common for some ideas to be shot down and complex ideas require a lot of time to reach maturity. If there's something I dislike it's that sometimes important bugfixes are delayed for quite a while. Especially in the absense of bugfix releases. If it was not the case Clojure would have zero traction and Linux likewise. Search for Linus rants about contributors and try to relate this with the level of success of Linux. They are not so many open source projects that have the same stability from release to release as Clojure or Linux. You're comparing apples to oranges here. Linux is not a one-man show - most subsystems have their own maintainers and Linus monitors the development there only cursory. Not to mention there's no company acting as the steward of the language. I'm not saying one of the approaches is better/worse, I'm just saying that's a poor base for such a comparison. Control and absence of complacency are key factors to achieve this kind of success. Luc P. Sent from my iPhone On Jul 18, 2015, at 07:13, Andrey Antukh n...@niwi.nz wrote: Hi! I have some, maybe controversial, questions... A little bit of context: https://twitter.com/aphyr/status/621806683908542464 Why this is like a normal approach for managing third party contributions to clojure core? This kind of things the only discourages the contributions. Maybe I don't have more context about this concrete case, but seems is not a unique. And in general, I have the perception that the clojure development process is a little bit opaque... An other question: Why the great amount of clojure compiler code has no indentation style and bunch of commented code. It is indented like a freshman. Sorry, I don't want offend any one, but eyes hurt when reading the code compiler clojure (obviously I'm speaking about the look and feel, and no the quality of the code). Some examples: Indentation (or maybe no indentation): https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/jvm/clojure/lang/APersistentVector.java#L86 Bunch of commented code and also no indentation: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/AMapEntry.java#L60 If you compare some clojure compiler code with different code snippets from other languages, the indentation is clearly more cared: Kotlin: https://github.com/JetBrains/kotlin/blob/master/core/descriptors/src/org/jetbrains/kotlin/types/AbstractClassTypeConstructor.java#L44 Rust: https://github.com/rust-lang/rust/blob/master/src/libstd/io/buffered.rs#L165 Ceylon: https://github.com/ceylon/ceylon-compiler/blob/master/src/com/redhat/ceylon/compiler/java/codegen/AttributeDefinitionBuilder.java#L233 This is a random list of code snippets from different compilers with indentation that is more human friendly. I don't intend judge any one, but when a I learn Clojure compiler I expect something different. I expect something more carefully done. No body thinks the
Project Better Clojure/Android integration
Hello I am a master's student and would like to contribute to the clojure/android platform. I found this project http://dev.clojure.org/display/community/Project+Ideas#ProjectIdeas-BetterClojureAndroidintegration on the project ideas site for GSoC 2015. I was hoping to submit the project proposal, however could not submit the proposal. I was wondering, if I still take up the project, will anyone be able to mentor me (very little time, by answering my questions on google groups). I checked the GSoC 2015 website and this is not something that's done by any student for GSoC 15. I also would like to take this project as my master's project, if that's OK to do so. I know Clojure (decent), Android(pretty good), Leiningen(used it for Clojure programming) and Gradle (beginner). Can someone please help me getting started and also comment on this? Thank you. Devang -- 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: [ANN] Clojure 1.8.0-alpha2
Wow, that's a fast timeline. Thank you. We'll upgrade to Alpha 2 this week. We may go to production with it fairly quickly. Sean On Sat, Jul 18, 2015 at 6:11 AM, Alex Miller a...@puredanger.com wrote: Clojure 1.8.0-alpha1 and 1.8.0-alpha2 are now available. Try it via - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.8.0-alpha2 - Leiningen: [org.clojure/clojure 1.8.0-alpha2] 1.8.0-alpha1 includes support for tuples (optimized small vectors) inspired by Zach Tellman's work. 1.8.0-alpha2 has an additional set of bug fixes and enhancements: CLJ-703 Improve writeClassFile performance CLJ-1659 compile leaks files CLJ-1761 clojure.core/run! does not always return nil CLJ-1645 'javap -v' on protocol class reveals no source file CLJ-1644 into-array fails for sequences starting with nil CLJ-1588 StackOverflow in clojure.test macroexpand with `are` and anonymous `fn` CLJ-1565 pprint issues infinite output for a protocol CLJ-1562 some-,some-,cond-,cond- and as- doesn't work with (recur) CLJ-1533 Oddity in type tag usage for primInvoke CLJ-1528 clojure.test/inc-report-counter is not thread safe CLJ-1399 missing field munging when recreating deftypes serialized into byte code CLJ-1313 Correct a few unit tests CLJ-1250 Reducer (and folder) instances hold onto the head of seqs CLJ-1208 Namespace is not loaded on defrecord class init Our current plans for 1.8 are to feature freeze on October 1st (typically that is beta 1) and then work through a release in time for the Clojure/Conj in late November. We expect 1.8 to include the Socket Server REPL work (http://dev.clojure.org/display/design/Socket+Server+REPL) and possibly other things to be determined. - Alex -- 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. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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: #{:rant} Questions about contribution policy and clojure compiler source.
Linux and Linus? Github vs Jira? Enough of these distractions. The issue here is that brilliant people like Zach Tellman is strongly disinclined to make contributions to the core Clojure implementation in the future. That Kyle Kingsbury, another brilliant developer, feels stonewalled - and even tho he loves Clojure the language and the community - is considering moving on. Because of the way the contribution process works. Or does not work, in these cases. I think Zach summed it up nicely in his gist. I don't think the sky is falling in any way. But don't try to boil this down to a patches vs pull request bike shedding. It is certainly a much more important topic than that. On Saturday, July 18, 2015 at 11:14:58 PM UTC+2, Luc wrote: You mentionned RedHat Linux centric type corporations. There are a lot more businesses that are not Linux centric business wise. They use it but provide something else on top. Did you even read this article against your own statement ? :) A huge number of occasional contributors were not reluctant to log a ticket and submit a patch instead of ranting about it. This is the main point you missed. That 'entry barrier' of yours does not stand with Linux. I would think hard about the reasons behind these numbers. There has to be some value added in the process of submitting patches. Luc P. On Sat, 18 Jul 2015 23:02:30 +0300 Bozhidar Batsov bozh...@batsov.com javascript: wrote: On 18 July 2015 at 22:52, Luc Préfontaine lprefo...@softaddicts.ca javascript: wrote: Each linux kernel release involves hundreds of people. Many release had above a thousand contributors. This is for your enlightenment and are old figures: http://royal.pingdom.com/2012/04/16/linux-kernel-development-numbers/ Did you even read this article? 75% – The share of all kernel development that is done by developers who are being paid for their work. This doesn't exactly contract what I said. There are as many people not officially hired to work for linux operating system focused businesses that submit patches through the ticketing system. As for the development lifecycle of the linux kernel: http://www.linuxfoundation.org/content/22-lifecycle-patch You can read the other sections, if you find the Clojure dev. lifecycle arcane, you will freak at this one. Obviously, these guys must all be old fashion outdated folks in this era of instant communication and snapchat like media, there's no other explanation for such a bureaucratic process :) How much pain is it to upgrade to a new Clojure version ? Nil. How much pain is it to upgrade to a new linux kernel ? Not nil but considering the size of this project, its ramifications and the hardware changing every 6 months, not big. On par with Clojure I would say. How much pain to upgrade to a new version of Ruby on Rails ? Huge. I know, I have been through this a number of times. Not just major releases, even maintenance ones are a nightmare to upgrade. Disclaimer: I am not saying that Rails has a bad lifecycle, I am just stating feedback from me and other people that actually lived this. Gee, I sound like Mallard Fillmore... That's for the political correctness of this post. And to avoid being harassed, sued, whatever. I would like us to compare carrots with carrots, not with apples or strawberries but if you insist To me the result is utterly important. We deliver 24/7 software under linux using Clojure. We have up times of more than 300 days. One upgrade a year. This is the world that live into. Making it 'harder to contribute' like you state is the price to pay for some form of quality control. Contributing to something that eventually crumbles because of a lack of QA is of no value. To us all. Stuart has made this evaluation. Since it models by some aspect how a successful project like Linux is managed, I find it hard to throw a stone at the current lifecycle. That may look to you as an ultra-conservative approach. Let's put it this way, I would use Linux and Clojure to control a nuclear plant anytime. I am quite certain sure I would not use Rails or Ruby for this purpose. As this conversation isn't really going anywhere I'll keep my thoughts to myself. Luc P. Luc P. Sent from my iPad On Jul 18, 2015, at 14:32, Bozhidar Batsov bozh...@batsov.com javascript: wrote: On 18 July 2015 at 20:18, Luc Prefontaine lprefo...@softaddicts.ca javascript: wrote: Aaah ! The pull request looms again :) A bug tracking system is essentialy to coordinate efforts, pull request are not a mechanism to track fixes/improvements and discuss about them. That may
Re: #{:rant} Questions about contribution policy and clojure compiler source.
On Saturday, July 18, 2015 at 9:16:39 PM UTC-4, Linus Ericsson wrote: Dear Mr/Ms/Mme/PhD Dynamics, I have this epic joke I would like yo send you, please fill in your fax number in the boxes below (please write clearly and use a pen with black ink, make sure the two carbon papers are correctly aligned). [_|_|_|_|_|_|_|_|_|_] *Carbon* papers? Sounds like the goddamned Spanish Inquisition! -- 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: #{:rant} Questions about contribution policy and clojure compiler source.
It is sad that Zach and Kyle thinks they spent time in vain. Clojure is less about code and more about holistic considerations and intentions than most other software projects. Jira (and mail chains such as this) are probably the worst possible hammers on communicating intentions and more holistic considerations in a focused way which IMHO seem to be what erred here. In cases like these I would strongly suggest Zach, Kyle and the Clojure Core-team to strive to communicate by phone or video-calls, and spend less time misinterpreting each other in asynchronous ticket comments. When in doubt, try to call each other ASAP and sort things out. I do optimistically assume that the Clojure Core team would gladly strive to set away some amount of time to discuss considerations for - not every incoming issue - but such exceptional, clear and well explained issues as these, where there's an overwhelming risk that a lot of work would end up being in vain. Thanks all for your exceptional work, Linus On Sunday, July 19, 2015 at 1:09:17 AM UTC+2, Magnar Sveen wrote: Linux and Linus? Github vs Jira? Enough of these distractions. The issue here is that brilliant people like Zach Tellman is strongly disinclined to make contributions to the core Clojure implementation in the future. That Kyle Kingsbury, another brilliant developer, feels stonewalled - and even tho he loves Clojure the language and the community - is considering moving on. Because of the way the contribution process works. Or does not work, in these cases. I think Zach summed it up nicely in his gist. I don't think the sky is falling in any way. But don't try to boil this down to a patches vs pull request bike shedding. It is certainly a much more important topic than that. On Saturday, July 18, 2015 at 11:14:58 PM UTC+2, Luc wrote: You mentionned RedHat Linux centric type corporations. There are a lot more businesses that are not Linux centric business wise. They use it but provide something else on top. Did you even read this article against your own statement ? :) A huge number of occasional contributors were not reluctant to log a ticket and submit a patch instead of ranting about it. This is the main point you missed. That 'entry barrier' of yours does not stand with Linux. I would think hard about the reasons behind these numbers. There has to be some value added in the process of submitting patches. Luc P. On Sat, 18 Jul 2015 23:02:30 +0300 Bozhidar Batsov bozh...@batsov.com wrote: On 18 July 2015 at 22:52, Luc Préfontaine lprefo...@softaddicts.ca wrote: Each linux kernel release involves hundreds of people. Many release had above a thousand contributors. This is for your enlightenment and are old figures: http://royal.pingdom.com/2012/04/16/linux-kernel-development-numbers/ Did you even read this article? 75% – The share of all kernel development that is done by developers who are being paid for their work. This doesn't exactly contract what I said. There are as many people not officially hired to work for linux operating system focused businesses that submit patches through the ticketing system. As for the development lifecycle of the linux kernel: http://www.linuxfoundation.org/content/22-lifecycle-patch You can read the other sections, if you find the Clojure dev. lifecycle arcane, you will freak at this one. Obviously, these guys must all be old fashion outdated folks in this era of instant communication and snapchat like media, there's no other explanation for such a bureaucratic process :) How much pain is it to upgrade to a new Clojure version ? Nil. How much pain is it to upgrade to a new linux kernel ? Not nil but considering the size of this project, its ramifications and the hardware changing every 6 months, not big. On par with Clojure I would say. How much pain to upgrade to a new version of Ruby on Rails ? Huge. I know, I have been through this a number of times. Not just major releases, even maintenance ones are a nightmare to upgrade. Disclaimer: I am not saying that Rails has a bad lifecycle, I am just stating feedback from me and other people that actually lived this. Gee, I sound like Mallard Fillmore... That's for the political correctness of this post. And to avoid being harassed, sued, whatever. I would like us to compare carrots with carrots, not with apples or strawberries but if you insist To me the result is utterly important. We deliver 24/7 software under linux using Clojure. We have up times of more than 300 days. One upgrade a year. This is the world that live into. Making it 'harder to contribute' like you state is the price to pay for some form of quality control. Contributing to something that eventually
Re: Port of simple Scala match to Clojure core.match
Great :) thanks :)
On Friday, July 17, 2015 at 2:14:50 AM UTC+2, Jonathan Winandy wrote:
Hello !
I think, this branch (without : empty?))
(match [l prefix]
*[_ ([] :seq)] true*
is already checking that prefix is empty.
Have a nice day,
Jon
On 16 July 2015 at 23:06, Rastko Soskic rss...@gmail.com javascript:
wrote:
Hi, I am getting familiar with Clojure's core.match and
simply starting with something simple and familar (some Scala match
expressions)
and translating that to core.match variant:
Check out this function which checks whether sequence starts with another:
def startsWith[A](l: List[A], prefix: List[A]): Boolean = (l,prefix)
match {
case (_,Nil) = true
case (Cons(h,t),Cons(h2,t2)) if h == h2 = startsWith(t, t2)
case _ = false
}
and my core.match attempt which works but I am not really sure
about it as wiki page is not yet exhaustive enough:
(defn starts-with [l prefix]
(match [l prefix]
*[_ ([] :seq : empty?)] true*
[([h t] :seq) ([h2 t2] :seq)] (if (= h h2)
(starts-with t t2)
false)
:else false))
second and third one are nothing special, former is just match
continuation.
First one is of particular interest for me...
Matching to Nil sequence in clojure is not appropriate as empty sequence
simply is not nil
whereas it is handled differently in scala.
What I wanted here is to check with empty? function if second argument
(prefix)
is empty sequence... Like I said...it works but I am not sure if there is
better
way to achieve function application to :seq pattern. I don't need to
destructure or bind
that to any particular var just to check if it is empty.
Any tip, suggestion or critic is welcome and appreciated.
Thanks in advance.
--
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: #{:rant} Questions about contribution policy and clojure compiler source.
On Saturday, July 18, 2015 at 8:22:35 PM UTC-4, Linus Ericsson wrote: In cases like these I would strongly suggest Zach, Kyle and the Clojure Core-team to strive to communicate by phone My God. First contributor agreements that have to be submitted by Pony Express, and now *phone calls*? What is this, the Dark Ages? We're dealing with medievalism here, Jim! -- 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: #{:rant} Questions about contribution policy and clojure compiler source.
Dear Mr/Ms/Mme/PhD Dynamics, I have this epic joke I would like yo send you, please fill in your fax number in the boxes below (please write clearly and use a pen with black ink, make sure the two carbon papers are correctly aligned). [_|_|_|_|_|_|_|_|_|_] Thanks, Linus Sent from my Ericsson Hotline Combi 450 Mobile Telephone Den 19 jul 2015 02:56 skrev Fluid Dynamics a2093...@trbvm.com: On Saturday, July 18, 2015 at 8:22:35 PM UTC-4, Linus Ericsson wrote: In cases like these I would strongly suggest Zach, Kyle and the Clojure Core-team to strive to communicate by phone My God. First contributor agreements that have to be submitted by Pony Express, and now *phone calls*? What is this, the Dark Ages? We're dealing with medievalism here, Jim! -- 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/IXKll8tgAXA/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.
