Re: Upgrading to Clojure 1.8 (direct linking)

[Mars0i]

I think I got a big speed boost going from 1.6 to 1.7, and a smaller boost 
going from 1.7 to 1.8.

On Wednesday, April 6, 2016 at 3:38:07 PM UTC-5, Piyush Katariya wrote:
>
>
> Has anybody experienced the performance boost by switching to Clojure 
> version 1.8 (and direct linking) ?
>

-- 
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: Cross platform date/time libarary

[Sean Corfield]

Michael Klishin and I discussed this and didn’t think it was going to be worth 
it due to the high level of Java interop in the Clojure version. If someone 
believes they can do it without producing a maintenance nightmare, Pull 
Requests are always welcome! 

 

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


 

On 4/6/16, 6:31 PM, "Michael Blume"  wrote:

 

Within your library you could probably use cljc to import one or the other, 
though.

 

On Mon, Apr 4, 2016 at 9:04 AM Sean Corfield  wrote:

On 4/3/16, 11:41 PM, "JvJ"  wrote:
> OK.  As long as a single import in a cljc will suffice.

Nope. The Clojure time libraries all lean very heavily on Java interop so a 
single source solution really is not feasible.


 

-- 
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: Cross platform date/time libarary

[Michael Blume]

Within your library you could probably use cljc to import one or the other,
though.

On Mon, Apr 4, 2016 at 9:04 AM Sean Corfield  wrote:

> On 4/3/16, 11:41 PM, "JvJ"  kfjwhee...@gmail.com> wrote:
> > OK.  As long as a single import in a cljc will suffice.
>
> Nope. The Clojure time libraries all lean very heavily on Java interop so
> a single source solution really is not feasible.
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>
>
>
>
> --
> 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: Upgrading to Clojure 1.8 (direct linking)

[Rostislav Svoboda]

I think I have. But I didn't do any particular measurements around it.
I have a habit of living on a rather bleeding edge.
So it might be a bunch cumulative performance improvements starting in
linux-kernel going all the way through
java 1.8, clojure 1.8, emacs-25, cider and I dunno what else resulting
in "Huh we're bit faster than before. Nice. Thx."

2016-04-06 22:21 GMT+02:00 Piyush Katariya :
>
> Has anybody experienced the performance boost by switching to Clojure
> version 1.8 (and direct linking) ?
>
> --
> 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.

Upgrading to Clojure 1.8 (direct linking)

[Piyush Katariya]

Has anybody experienced the performance boost by switching to Clojure 
version 1.8 (and direct linking) ?

-- 
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: Core.async performance with many channels

[JvJ]

It seems to do rather well.

On Wednesday, 6 April 2016 08:29:07 UTC-7, Francis Avila wrote:
>
> On Monday, April 4, 2016 at 6:30:07 PM UTC-5, Howard M. Lewis Ship wrote:
>>
>> David Nolen had an early ClojureScript core.async demo with thousands of 
>> channels, controlling individual pixels.
>>
>
> This is the demo you are referring to: 
> http://swannodette.github.io/2013/08/02/10-processes/
>  
>

-- 
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.

[JOB] Software Developer (clojure) @ OpinionLab in Chicago

[Brave Clojure Jobs]

Permanent position

"The OpinionLab backend data team is responsible for creating and 
maintaining applications and services for processing large amounts of 
customer feedback data from some of the largest companies in the world. Our 
ongoing challenge is to transform streams of independent comments into 
actionable intelligence for our customers in real time. We primarily use 
Clojure on AWS to build microservices and data pipelines to handle and 
enrich this data. If you are interested in applying functional programming 
techniques to help uncover the secrets hidden in our data, we have plenty 
of work for you."

Read more at 
https://jobs.braveclojure.com/jobs/17592186045868/software-developer-clojure-chicago-opinionlab-inc

-- 
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: Core.async performance with many channels

[Francis Avila]

On Monday, April 4, 2016 at 6:30:07 PM UTC-5, Howard M. Lewis Ship wrote:
>
> David Nolen had an early ClojureScript core.async demo with thousands of 
> channels, controlling individual pixels.
>

This is the demo you are referring to: 
http://swannodette.github.io/2013/08/02/10-processes/
 

-- 
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: Macro for quickly switching libraries

[Francis Avila]

The backtick namespace-qualifies symbols automatically:

(macroexpand-1 '(switch-foo-library! x))
;=>
(clojure.core/defn
 user/foo
 [y__3652__auto__]
 ((clojure.core/resolve (clojure.core/symbol (clojure.core/str x "/foo")))
  y__3652__auto__))

The error is about the "user/foo" name of the defn.

You can fix this by quoting the symbol then immediately unquoting it:


(defmacro switch-foo-library! [x]
  `(defn ~'foo [y#] ((resolve (symbol (str ~x "/foo"))) y#)))
;=> #'user/switch-foo-library!
(macroexpand-1 '(switch-foo-library! x))

;=>
(clojure.core/defn
 foo
 [y__3946__auto__]
 ((clojure.core/resolve (clojure.core/symbol (clojure.core/str x "/foo")))
  y__3946__auto__))


However what you really want probably something with with-redefs 

:

(defmacro with-ns [ns vars & body]
  {:pre [(symbol? ns) (nil? (namespace ns))
 (every? #(and (symbol? %) (nil? (namespace %))) vars)]}
  (let [bindings (vec (mapcat #(do [% (symbol (str ns) (str %))]) vars))]
`(with-redefs ~bindings ~@body)))
;=> #'user/with-ns
(ns alt)
;=> nil
(def juxt (constantly (constantly "NEW JUXT")))
;WARNING: juxt already refers to: #'clojure.core/juxt in namespace: alt, 
being replaced by: #'alt/juxt
;=> #'alt/juxt
(in-ns 'user)
;=> #object[clojure.lang.Namespace 0x77b2abef "user"]
(with-ns alt [juxt] (map (juxt :a :b) (repeat 4 {:a 1 :b 2})))
;=> ("NEW JUXT" "NEW JUXT" "NEW JUXT" "NEW JUXT")
((juxt :a) {:a 1})
;=> [1]



If you want to make the var change permanent (i.e. not requiring your body 
be inside with-redefs), you can use alter-var-root 
, but you have to take 
care to allow the vars to be restored somehow, e.g. by storing the old 
mappings somewhere and providing a macro to save and restore them.

It's possible someone has scratched this itch before, too: there might be a 
utility library out there somewhere that does something like this.

On Tuesday, April 5, 2016 at 9:10:15 PM UTC-5, Will Bridewell wrote:
>
> I'm working on some code where I want to evaluate different 
> implementations of the same functionality. Each implementation of a 
> function lives in its own namespace. For example, suppose that I have the 
> following simplified code.
>
> (ns tst1)
> (defn foo [x] (+ x 1))
>
> (ns tst2)
> (defn foo [x] (+ x 2))
>
> (ns tst3)
> (defn foo [x] (+ x 3))
>
> (in-ns 'user)
>
> What I'd like to do is call a macro that binds the function name in user 
> to the function in one of the libraries. The call would look like one of 
> these. 
>
> (switch-library! 'tst1 'foo)
>
> (switch-foo-library! 'tst1)
>
> The closest that I got was to do 
>
> (defmacro switch-foo-library! [x]
>   `(defn foo [y#] ((resolve (symbol (str ~x "/foo"))) y#)))
>
> That's kind of embarrassing, but I think it does what I want. However, 
> suppose I do
>
> (ns-unmap 'user 'juxt)
> (defmacro switch-juxt-library! [x]
>   `(defn juxt [y#] ((resolve (symbol (str ~x "/juxt"))) y#)))
>
> Now I get 
>
> CompilerException java.lang.RuntimeException: Can't create defs outside 
> of current ns, compiling:
>
> Well, gosh. I can't play around with symbols in clojure.core? What's 
> happening here?
>
>
>

-- 
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] Aleph 0.4.1

[Sander]

Zach Tellman wrote (ao):
> I'm not sure I'll have time to look at the spec you linked anytime
> soon, but I think it's reasonable to have some UDP-related code in the
> literate examples. I'll think about what would be a decent use case.

Very simple chatserver/client with mosh (mobile shell) like capabilities?

Sander

-- 
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] components.md

[Timothy Baldridge]

Thanks for replying.

>> (with-redefs [bootstrap/system {:rabbit “my stub”}] )

That would possibly do the trick, but I really don't like using redefs, it
assumes a mutable environment, and then also locks me into a
single-threaded testing system, one where all uses of a var must refer to
the same thing. In short, I don't want to configure my system using code, I
want my system to be configured with data. Onyx is a good example of this,
define components and name them, then wire them up together with data. Not
only does this allow for programatic configuration of a system, but also
programatic introspection (https://github.com/walmartlabs/system-viz).

>> What I’m trying to say is that I’m not big fan of libraries of
components for clojure

I completely agree there. Such libraries have very limited use.

>> I would have some hard time convincing a Java team to just use JDBC and
a db driver to connect to a DB. So we’ll use Spring and whatnot. In Clojure
we have the luxury that the language doesn’t need framework patching. So I
think I shouldn’t have said OOP, but more precisely Java

I like the way a co-worker put it once: "Ask yourself, will I ever need
more than one of these?". Will I ever need more than one database
connection? Will I ever need more than one queue? Will I ever need more
than one image server, etc. I'd say that 50% of the time the answer is
"yes" and another 49% of the time you are in denial and will say "yes"
sometime in the future :). In that case I'd like my system to talk via a
common interface that is fairly easy to swap out, perhaps even on a
sub-project basis.

Now these components are often very application specific, so I don't
advocate some central library of components, but with a single company
there could be dozens of components that are all wired together to compose
the systems that create the application as a whole.

So that's what I have worked with for years now at some fairly large
companies, and I have found to give me the biggest "bang for the buck":
Non-singleton components that express themselves via a well defined
abstract protocol, wired together via data.

On Wed, Apr 6, 2016 at 4:59 AM, Renzo Borgatti  wrote:

> Thanks Tim for reading down till the last line!
>
> > On 5 Apr 2016, at 19:09, Timothy Baldridge  wrote:
> >
> > The thing that this doc also advocates (and I am against) is manual
> dependency management, your app start function must call start on its
> dependencies. This not only hardcodes the dependency, but also requires the
> user to think about the startup order of components on every usage.
>
> This “every usage” is roughly every time a new component is added (in my
> experience). Of the total number of components, around 80% is added at the
> very beginning and a few more during the lifetime of the app. Last time I
> had the ordering problem with one component I fixed it in the app start
> function and never touched it again. So I’m not sure if the user is
> required any special effort after the very first setup.
>
> > In addition this approach doesn't support substituting alternate
> implementations. During testing I often want to use a in-memory queue vs
> RabbitMQ. Or perhaps I want to wire an entire system up with in-memory
> queues to perform limited integration testing. Hardcoding dependencies
> limits the flexibility of the app.
>
> Good point about stubbing out sometimes. But shouldn’t something like
> (with-redefs [bootstrap/system {:rabbit “my stub”}] ) solve the
> problem easily? As of running the app with a different configuration, you
> could get away by “TESTING=true java -jar target/uberapp.jar” and put a
> conditional in system.clj to wire-up the app with in-memory queues.
>
> > And this part of the doc:
> >
> > "A: You see, this all idea of reusable libraries of components never
> worked and it gets complicated pretty fast. See the past 20 years of OO
> frameworks. Do you really want a Spring/J2EE in your beautiful Clojure app?"
> >
> > Is just wrong. Perhaps across multiple projects and multiple companies
> component re-use isn't as common as some would think. but within the same
> company/project components are re-used a lot. Not only does this quote it
> present a false dichotomy (either you have a nice Clojure app or you have
> reusable components). But it is also little more than an ad-homiem attack:
> "This looks like OOP, OOP is bad, therefore doing this is bad!”
>
> You are right, I’ll re-phrase that to be more precise: "This looks like
> Java, Java is bad, therefore doing this is bad!”
>
> What I’m trying to say is that I’m not big fan of libraries of components
> for clojure: https://github.com/danielsz/system or https://modularity.org/
> comes to mind. Those are meant to be cross-organization. Even internally
> tho, I don’t like to build and grow our own library of components. At the
> beginning it sounds like a good idea, in the long term it doesn’t scale.
> There are several reasons that doesn’t work well:
>
> 1. one p

Re: Advice getting started with concurrency and parallelism in Clojure

[Mars0i]

Maybe people forget about pmap , 
pcalls , and pvalues 
 because they're just too easy.

On Tuesday, April 5, 2016 at 8:51:59 PM UTC-5, tbc++ wrote:
>
> If it all seems confusing, do not despair, there's two things that will 
> handle the vast majority of the use cases you may have: 
>
> 1) `future` - spawns a thread that runs the body of the future (
> https://clojuredocs.org/clojure.core/future)
> 2) `atom` and `swap!` - Used to store data that needs to be shared between 
> threads and updated concurrently (
> https://clojuredocs.org/clojure.core/atom) these are built on top of CAS, 
> which itself is foundation upon which most of concurrent programming is 
> built. (https://en.wikipedia.org/wiki/Compare-and-swap)
>
> Those two primitives alone will handle 90% of the use cases you will run 
> into as a new clojure developer. The rest of the stuff (agents, thread 
> pools, refs, vars, cps/core.async) can all come in time, but you will use 
> them much less often than threads and atoms. So read up on those two and 
> feel free to come back with any questions you may have. 
>
> Timothy
>
>
> On Tue, Apr 5, 2016 at 7:24 PM, Chris White  > wrote:
>
>> I was doing some reading of code recently to help me get up to speed with 
>> Clojure. One of the libraries I randomly came across dealt with parallelism 
>> and I had a hard time following along with it. To try and wrap my head 
>> around things I did a quick search and found this article:
>>
>>
>> http://www.thattommyhall.com/2014/02/24/concurrency-and-parallelism-in-clojure/
>>
>> I'm not sure how authoritative this is based on my current experience, 
>> but needless to say I was a bit overwhelmed. That said is there any sort of 
>> introductory material that list members have used to help get them into how 
>> Clojure deals with concurrency and parallelism? I also don't mind anything 
>> that's not specifically using Clojure but will at least help me understand 
>> the concepts behind how Clojure does it. Thanks again for any and all help!
>>
>> - Chris White (@cwgem)
>>
>> -- 
>> 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 
>> 
>> 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 
>> 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 .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.”
> (Robert Firth) 
>

-- 
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] components.md

[Renzo Borgatti]

Thanks Tim for reading down till the last line!

> On 5 Apr 2016, at 19:09, Timothy Baldridge  wrote:
> 
> The thing that this doc also advocates (and I am against) is manual 
> dependency management, your app start function must call start on its 
> dependencies. This not only hardcodes the dependency, but also requires the 
> user to think about the startup order of components on every usage.

This “every usage” is roughly every time a new component is added (in my 
experience). Of the total number of components, around 80% is added at the very 
beginning and a few more during the lifetime of the app. Last time I had the 
ordering problem with one component I fixed it in the app start function and 
never touched it again. So I’m not sure if the user is required any special 
effort after the very first setup.

> In addition this approach doesn't support substituting alternate 
> implementations. During testing I often want to use a in-memory queue vs 
> RabbitMQ. Or perhaps I want to wire an entire system up with in-memory queues 
> to perform limited integration testing. Hardcoding dependencies limits the 
> flexibility of the app. 

Good point about stubbing out sometimes. But shouldn’t something like 
(with-redefs [bootstrap/system {:rabbit “my stub”}] ) solve the 
problem easily? As of running the app with a different configuration, you could 
get away by “TESTING=true java -jar target/uberapp.jar” and put a conditional 
in system.clj to wire-up the app with in-memory queues.

> And this part of the doc:
> 
> "A: You see, this all idea of reusable libraries of components never worked 
> and it gets complicated pretty fast. See the past 20 years of OO frameworks. 
> Do you really want a Spring/J2EE in your beautiful Clojure app?"
> 
> Is just wrong. Perhaps across multiple projects and multiple companies 
> component re-use isn't as common as some would think. but within the same 
> company/project components are re-used a lot. Not only does this quote it 
> present a false dichotomy (either you have a nice Clojure app or you have 
> reusable components). But it is also little more than an ad-homiem attack: 
> "This looks like OOP, OOP is bad, therefore doing this is bad!”

You are right, I’ll re-phrase that to be more precise: "This looks like Java, 
Java is bad, therefore doing this is bad!”

What I’m trying to say is that I’m not big fan of libraries of components for 
clojure: https://github.com/danielsz/system or https://modularity.org/ comes to 
mind. Those are meant to be cross-organization. Even internally tho, I don’t 
like to build and grow our own library of components. At the beginning it 
sounds like a good idea, in the long term it doesn’t scale. There are several 
reasons that doesn’t work well: 

1. one project need component #1 of X in the library and suddenly you find 
yourself with ActiveMQ client (and many others) in your classpath when you 
don’t use them. You can deal with it at the cost of an increase of the 
complexity of the library of components.
2. if internal library, it requires additional release cycle effort: an 
internal repo to host the lib, a snapshot/concrete builds management, in 
general doing changes in two projects at once.
3. if a project requires the component to act differently (say I need 
elasticsearch native client but all the rest can stay on the REST client) I 
bump the component library version +1 and add some config. Now on, I need to 
remember why there is a version difference and to pay attention when I update 
other projects. Still something you can handle with some additional effort.

So I noticed that if I just copy paste what I need in each project, it works as 
intended and scales just fine. 

Now more on the Java bashing. My thinking is the following: if a language 
ecosystem constantly pushes you to depend on frameworks to maintain sanity 
developing an app there is something wrong. I would have some hard time 
convincing a Java team to just use JDBC and a db driver to connect to a DB. So 
we’ll use Spring and whatnot. In Clojure we have the luxury that the language 
doesn’t need framework patching. So I think I shouldn’t have said OOP, but more 
precisely Java.

Thanks
Renzo

> 
> 
> 
> On Tue, Apr 5, 2016 at 11:31 AM, James Reeves  wrote:
> On 5 April 2016 at 17:23,  wrote:
> Not sure it's worth to depend on a library for a defprotocol with two 
> functions. Also, still need to double check, but I think I can get rid of 
> that defprotocol.
> 
> Well, the advantage with using the Lifecycle protocol from Component is that 
> you can make use of existing libraries.
> 
> - James
> 
> -- 
> 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