Re: Coverage tools in Clojure

[Korny Sietsma]

My 2c - on my last project it would have been handy to have some test
coverage tools, they can be useful to sanity check your testing.

However, it's worth noting that compared to a java project, we had far
fewer lines of code, so manually reviewing code for tests was a lot easier.

And there were cases where some careful integration tests were more useful
than unit testing everything, which ties in to Colin's point I think. And
integration tests tend to break coverage metrics.

(and I'm not sure how you'd do coverage for macros, but that's probably a
digression)

- Korny
On 4 Feb 2014 11:23, "Aaron France"  wrote:

>
> I don't want to seem rude but I think you've drank a bit too much
> kool-aid.
>
> To say that functional programming and war against state means that
> your application doesn't need to be tested thoroughly is a joke. And a
> very bad one.
>
> Coverage doesn't just aid you in seeing which parts of state caused
> which branches to be hit, it also gives you notice if there are any
> logical errors in your code which cause the branches to not be hit.
>
> Aaron
>
> On Tue, Feb 04, 2014 at 03:19:05AM -0800, Colin Yates wrote:
> > I don't know.
> >
> > But maybe the lack of coverage tools is itself interesting?  My (not
> quite
> > formed/making this up as I go) view is that maybe coverage tools are
> there
> > to address the implicit complexity in other mainstream languages and/or
> to
> > help mitigate the risk of the potentially large and hard-to-identify
> > 'impact analysis' you get in OO systems when you change state.  In other
> > words, coverage is necessary because we want to feel safe that all
> > combinations of our code are extensively tested.  Why don't we feel safe?
> >  Because the system is hard to reason about.
> >
> > Functional programming on the other hand is full of much smaller discrete
> > and independent chunks of functionality.  Ideally these small focused
> > 'bricks' are pure/referentially transparent so the *only* context you
> need
> > when reasoning about them is their parameters and the logic inside.
> >  Assembling these bricks introduces interactions that need to be tested,
> > sure, but there are very few 'call this and watch the change
> cascade'/'this
> > code is sensitive (i.e. coupled) to that data over there'.
> >
> > My ramblings are to say, maybe the root cause of coverage tools is to
> solve
> > a problem (hard to reason about systems) which shouldn't be much less of
> a
> > problem in FP when FP is done right.  OO + mutable state = hard to reason
> > about.  FP + immutable state + pure/referentially transparent functions =
> > much easier to reason about.
> >
> > Or not.  Just my 2 pence :).
> >
> > On Sunday, 2 February 2014 21:34:29 UTC, Aaron France wrote:
> > >
> > > Hi,
> > >
> > > I'm looking for coverage reporting in Clojure. I've been using
> > > Cloverage[1] but I'm just wondering if there are any other coverage
> > > tools?
> > >
> > > Aaron
> > >
> > >
> > > [1] https://github.com/lshift/cloverage
> > >
> >
> > --
> > 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/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/groups/opt_out.

Re: Coverage tools in Clojure

[Colin Yates]

Comments in line.
On Tuesday, 4 February 2014 11:23:36 UTC, Aaron France wrote:
>
>
> I don't want to seem rude but I think you've drank a bit too much 
> kool-aid. 
>
You know the phrase "I don't want to seem rude" doesn't actually do 
anything right?  :)
 

> To say that functional programming and war against state means that 
> your application doesn't need to be tested thoroughly is a joke. And a 
> very bad one. 
>
I agree, but who is saying that?  I certainly didn't cover how much testing 
is necessary.  I thoroughly test my Clojure systems using midje, which 
regularly rocks my world.  My point is that the coverage is much *much* 
easier to reason about in FP than in OO (for the reasons I gave).
 

> Coverage doesn't just aid you in seeing which parts of state caused 
> which branches to be hit, it also gives you notice if there are any 
> logical errors in your code which cause the branches to not be hit. 
>
And why are those logical errors which cause the branches to not be hit not 
immediately obvious?  Why do you need a tool to tell you that?  I know my 
Clojure code has around 100% coverage using white box testing for the 
functions and mocking the interactions.

I would challenge you to put ego/emotion to one side, stop finding 
non-existent points to argue against and re-read my post.  By all means 
come back and justify why all the points I raised which reduce the need for 
coverage are invalid.  Don't attribute stupid statements (like 'FP doesn't 
need testing') to me - I can come up with my own stupid statements thank 
you.

If it helps, my stand point is from 20 years of building non-trivial 
Enterprise applications (primarily Java) using the current best of breed 
technology stacks (i.e Spring/Hibernate/AspectJ) with the best of breed 
process (agile, TDD, DBC, BDD, most other TLAs etc.).  Using Clojure for 
the past year or so has opened my eyes to exactly how many problems we 
solve, and infrastructure we use is to pamper to complexity introduced by 
the tool-chain not the problem domain.  I am suggesting maybe coverage 
tools are one of those.


> Aaron 
>
> On Tue, Feb 04, 2014 at 03:19:05AM -0800, Colin Yates wrote: 
> > I don't know. 
> > 
> > But maybe the lack of coverage tools is itself interesting?  My (not 
> quite 
> > formed/making this up as I go) view is that maybe coverage tools are 
> there 
> > to address the implicit complexity in other mainstream languages and/or 
> to 
> > help mitigate the risk of the potentially large and hard-to-identify 
> > 'impact analysis' you get in OO systems when you change state.  In other 
> > words, coverage is necessary because we want to feel safe that all 
> > combinations of our code are extensively tested.  Why don't we feel 
> safe? 
> >  Because the system is hard to reason about. 
> > 
> > Functional programming on the other hand is full of much smaller 
> discrete 
> > and independent chunks of functionality.  Ideally these small focused 
> > 'bricks' are pure/referentially transparent so the *only* context you 
> need 
> > when reasoning about them is their parameters and the logic inside. 
> >  Assembling these bricks introduces interactions that need to be tested, 
> > sure, but there are very few 'call this and watch the change 
> cascade'/'this 
> > code is sensitive (i.e. coupled) to that data over there'. 
> > 
> > My ramblings are to say, maybe the root cause of coverage tools is to 
> solve 
> > a problem (hard to reason about systems) which shouldn't be much less of 
> a 
> > problem in FP when FP is done right.  OO + mutable state = hard to 
> reason 
> > about.  FP + immutable state + pure/referentially transparent functions 
> = 
> > much easier to reason about. 
> > 
> > Or not.  Just my 2 pence :). 
> > 
> > On Sunday, 2 February 2014 21:34:29 UTC, Aaron France wrote: 
> > > 
> > > Hi, 
> > > 
> > > I'm looking for coverage reporting in Clojure. I've been using 
> > > Cloverage[1] but I'm just wondering if there are any other coverage 
> > > tools? 
> > > 
> > > Aaron 
> > > 
> > > 
> > > [1] https://github.com/lshift/cloverage 
> > > 
> > 
> > -- 
> > 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/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 c

Re: Lessons Learned from Adopting Clojure

[Colin Yates]

Is there going to be online access during/after the event?  I would greatly 
value seeing this, but probably not enough to travel from the UK to Chicago 
:).

On Tuesday, 4 February 2014 12:06:06 UTC, Jay Fields wrote:
>
> tl; dr: I'm presenting "Lessons Learned from Adopting Clojure" in 
> Chicago on Feb 11th: 
>
> http://www.eventbrite.com/e/goto-night-with-jay-fields-tickets-10366768283?aff=eorgf
>  
>
> Five years ago DRW Trading was primarily a Java shop, and I was 
> primarily developing in Ruby. Needless to say, it wasn't a match made 
> in heaven. Fast forward five years, Clojure is the second most used 
> language in the firm, and the primary language for several teams 
> (including mine). Clojure wasn't the first language that I've 
> introduced to an organization; however, it's unquestionably the most 
> successful adoption I've ever been a part of. The use of Clojure has 
> had many impacts on the firm: culturally, politically, and 
> technically. My talk will discuss general ideas around language 
> selection and maintenance trade-offs, and specific examples of what 
> aspects of Clojure made it the correct choice for us. 
>
> A few highlights 
>
> - Where to first introduce a new language and your role as the 
> language care-taker. 
> - REPL driven development, putting TDD's 'rapid feedback' to shame. 
> - Operations impact of adding a language - i.e. get ready for some DevOps. 
> - Functional programming, the Lisp Advantage, and their impact on 
> maintainability. 
>
> Of course, no good experience report is all roses. The adoption has 
> seen several hurdles along the way, and I'll happily to describe those 
> as well. 
>

-- 
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/groups/opt_out.

Re: Coverage tools in Clojure

[Gary Trakhman]

In clojure, generally I've found

Unit-tests are often significantly harder to write than the corresponding
implementing code,
idiomatic code rarely has silly problems,
and integration tests are enough to shake out bad behavior.

So, the end result is constraining our codebase at API boundaries with
integration tests does pretty well, and unit tests are most likely to get
written only when I'm doing something weird and nasty.


On Tue, Feb 4, 2014 at 7:14 AM, Korny Sietsma  wrote:

> My 2c - on my last project it would have been handy to have some test
> coverage tools, they can be useful to sanity check your testing.
>
> However, it's worth noting that compared to a java project, we had far
> fewer lines of code, so manually reviewing code for tests was a lot easier.
>
> And there were cases where some careful integration tests were more useful
> than unit testing everything, which ties in to Colin's point I think. And
> integration tests tend to break coverage metrics.
>
> (and I'm not sure how you'd do coverage for macros, but that's probably a
> digression)
>
> - Korny
> On 4 Feb 2014 11:23, "Aaron France"  wrote:
>
>>
>> I don't want to seem rude but I think you've drank a bit too much
>> kool-aid.
>>
>> To say that functional programming and war against state means that
>> your application doesn't need to be tested thoroughly is a joke. And a
>> very bad one.
>>
>> Coverage doesn't just aid you in seeing which parts of state caused
>> which branches to be hit, it also gives you notice if there are any
>> logical errors in your code which cause the branches to not be hit.
>>
>> Aaron
>>
>> On Tue, Feb 04, 2014 at 03:19:05AM -0800, Colin Yates wrote:
>> > I don't know.
>> >
>> > But maybe the lack of coverage tools is itself interesting?  My (not
>> quite
>> > formed/making this up as I go) view is that maybe coverage tools are
>> there
>> > to address the implicit complexity in other mainstream languages and/or
>> to
>> > help mitigate the risk of the potentially large and hard-to-identify
>> > 'impact analysis' you get in OO systems when you change state.  In other
>> > words, coverage is necessary because we want to feel safe that all
>> > combinations of our code are extensively tested.  Why don't we feel
>> safe?
>> >  Because the system is hard to reason about.
>> >
>> > Functional programming on the other hand is full of much smaller
>> discrete
>> > and independent chunks of functionality.  Ideally these small focused
>> > 'bricks' are pure/referentially transparent so the *only* context you
>> need
>> > when reasoning about them is their parameters and the logic inside.
>> >  Assembling these bricks introduces interactions that need to be tested,
>> > sure, but there are very few 'call this and watch the change
>> cascade'/'this
>> > code is sensitive (i.e. coupled) to that data over there'.
>> >
>> > My ramblings are to say, maybe the root cause of coverage tools is to
>> solve
>> > a problem (hard to reason about systems) which shouldn't be much less
>> of a
>> > problem in FP when FP is done right.  OO + mutable state = hard to
>> reason
>> > about.  FP + immutable state + pure/referentially transparent functions
>> =
>> > much easier to reason about.
>> >
>> > Or not.  Just my 2 pence :).
>> >
>> > On Sunday, 2 February 2014 21:34:29 UTC, Aaron France wrote:
>> > >
>> > > Hi,
>> > >
>> > > I'm looking for coverage reporting in Clojure. I've been using
>> > > Cloverage[1] but I'm just wondering if there are any other coverage
>> > > tools?
>> > >
>> > > Aaron
>> > >
>> > >
>> > > [1] https://github.com/lshift/cloverage
>> > >
>> >
>> > --
>> > 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/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

Re: ANN: Reagent 0.3.0 - now with async rendering

[Dan Holmsand]

On Tuesday, February 4, 2014 11:24:16 AM UTC+1, Robin Heggelund Hansen 
wrote:

> Gotta ask, what's the difference between Om and  Reagent?
>

Well, I'd say that the basic functionality of the two is quite similar: 
it's all about efficiently transforming some application state into a UI 
description (that is then turned into actual UI by React). 

The differences come at both ends of that transformation. Om is much more 
ambitious when it comes to managing that application state. It helps you to 
handle changing state (and tells you how to do that), whereas with Reagent 
you're pretty much on your own there. Reagent is just about rendering a UI, 
and leaves state management to you.

At the other end, the UI description in Reagent is a vector of vectors 
(with the same structure as in Hiccup), whereas Om uses React's javascript 
"fake DOM" elements more or less directly. Reagent on the other hand keeps 
the UI description as immutable data until it really has to tell React what 
to put out there.

Then there are obviously some differences in API, but I think that these 
are more superficial.

David might disagree strongly, of course :)

/dan

-- 
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/groups/opt_out.

Re: Coverage tools in Clojure

[Colin Yates]

+1
I still force myself to write those tests simply for the confidence they give 
me in replacing my hack with idiomatic code as I/colleagues get more familiar 
down the road.
I can absolutely see dramatically reducing the number of 'safety rails' type 
tests pretty soon; most of the code uses the core abstractions. It is quite 
humbling/interesting how little new code I actually need to write as oppose to 
picking one/assembling some off the shelf. 


On Tuesday, 4 February 2014 12:22:57 UTC, Gary Trakhman wrote:
>
> In clojure, generally I've found
>
> Unit-tests are often significantly harder to write than the corresponding 
> implementing code,
> idiomatic code rarely has silly problems,
> and integration tests are enough to shake out bad behavior.
>
> So, the end result is constraining our codebase at API boundaries with 
> integration tests does pretty well, and unit tests are most likely to get 
> written only when I'm doing something weird and nasty.
>
>
> On Tue, Feb 4, 2014 at 7:14 AM, Korny Sietsma 
> > wrote:
>
>> My 2c - on my last project it would have been handy to have some test 
>> coverage tools, they can be useful to sanity check your testing. 
>>
>> However, it's worth noting that compared to a java project, we had far 
>> fewer lines of code, so manually reviewing code for tests was a lot easier. 
>>
>> And there were cases where some careful integration tests were more 
>> useful than unit testing everything, which ties in to Colin's point I 
>> think. And integration tests tend to break coverage metrics. 
>>
>> (and I'm not sure how you'd do coverage for macros, but that's probably a 
>> digression) 
>>
>> - Korny 
>> On 4 Feb 2014 11:23, "Aaron France" > 
>> wrote:
>>
>>>
>>> I don't want to seem rude but I think you've drank a bit too much
>>> kool-aid.
>>>
>>> To say that functional programming and war against state means that
>>> your application doesn't need to be tested thoroughly is a joke. And a
>>> very bad one.
>>>
>>> Coverage doesn't just aid you in seeing which parts of state caused
>>> which branches to be hit, it also gives you notice if there are any
>>> logical errors in your code which cause the branches to not be hit.
>>>
>>> Aaron
>>>
>>> On Tue, Feb 04, 2014 at 03:19:05AM -0800, Colin Yates wrote:
>>> > I don't know.
>>> >
>>> > But maybe the lack of coverage tools is itself interesting?  My (not 
>>> quite
>>> > formed/making this up as I go) view is that maybe coverage tools are 
>>> there
>>> > to address the implicit complexity in other mainstream languages 
>>> and/or to
>>> > help mitigate the risk of the potentially large and hard-to-identify
>>> > 'impact analysis' you get in OO systems when you change state.  In 
>>> other
>>> > words, coverage is necessary because we want to feel safe that all
>>> > combinations of our code are extensively tested.  Why don't we feel 
>>> safe?
>>> >  Because the system is hard to reason about.
>>> >
>>> > Functional programming on the other hand is full of much smaller 
>>> discrete
>>> > and independent chunks of functionality.  Ideally these small focused
>>> > 'bricks' are pure/referentially transparent so the *only* context you 
>>> need
>>> > when reasoning about them is their parameters and the logic inside.
>>> >  Assembling these bricks introduces interactions that need to be 
>>> tested,
>>> > sure, but there are very few 'call this and watch the change 
>>> cascade'/'this
>>> > code is sensitive (i.e. coupled) to that data over there'.
>>> >
>>> > My ramblings are to say, maybe the root cause of coverage tools is to 
>>> solve
>>> > a problem (hard to reason about systems) which shouldn't be much less 
>>> of a
>>> > problem in FP when FP is done right.  OO + mutable state = hard to 
>>> reason
>>> > about.  FP + immutable state + pure/referentially transparent 
>>> functions =
>>> > much easier to reason about.
>>> >
>>> > Or not.  Just my 2 pence :).
>>> >
>>> > On Sunday, 2 February 2014 21:34:29 UTC, Aaron France wrote:
>>> > >
>>> > > Hi,
>>> > >
>>> > > I'm looking for coverage reporting in Clojure. I've been using
>>> > > Cloverage[1] but I'm just wondering if there are any other coverage
>>> > > tools?
>>> > >
>>> > > Aaron
>>> > >
>>> > >
>>> > > [1] https://github.com/lshift/cloverage
>>> > >
>>> >
>>> > --
>>> > 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 mo

Re: Lessons Learned from Adopting Clojure

[Angel Java Lopez]

Interesting!

A question: did you abandon TDD? why?
IMO, TDD is a workflow that pushes for simplicity


On Tue, Feb 4, 2014 at 9:22 AM, Colin Yates  wrote:

> Is there going to be online access during/after the event?  I would
> greatly value seeing this, but probably not enough to travel from the UK to
> Chicago :).
>
>
> On Tuesday, 4 February 2014 12:06:06 UTC, Jay Fields wrote:
>>
>> tl; dr: I'm presenting "Lessons Learned from Adopting Clojure" in
>> Chicago on Feb 11th:
>> http://www.eventbrite.com/e/goto-night-with-jay-fields-
>> tickets-10366768283?aff=eorgf
>>
>> Five years ago DRW Trading was primarily a Java shop, and I was
>> primarily developing in Ruby. Needless to say, it wasn't a match made
>> in heaven. Fast forward five years, Clojure is the second most used
>> language in the firm, and the primary language for several teams
>> (including mine). Clojure wasn't the first language that I've
>> introduced to an organization; however, it's unquestionably the most
>> successful adoption I've ever been a part of. The use of Clojure has
>> had many impacts on the firm: culturally, politically, and
>> technically. My talk will discuss general ideas around language
>> selection and maintenance trade-offs, and specific examples of what
>> aspects of Clojure made it the correct choice for us.
>>
>> A few highlights
>>
>> - Where to first introduce a new language and your role as the
>> language care-taker.
>> - REPL driven development, putting TDD's 'rapid feedback' to shame.
>> - Operations impact of adding a language - i.e. get ready for some
>> DevOps.
>> - Functional programming, the Lisp Advantage, and their impact on
>> maintainability.
>>
>> Of course, no good experience report is all roses. The adoption has
>> seen several hurdles along the way, and I'll happily to describe those
>> as well.
>>
>  --
> 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/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/groups/opt_out.

Re: Lessons Learned from Adopting Clojure

[Rafael Peixoto de Azevedo]

+1 from Melbourne :)


On 4 February 2014 23:22, Colin Yates  wrote:

> Is there going to be online access during/after the event?  I would
> greatly value seeing this, but probably not enough to travel from the UK to
> Chicago :).
>
>
> On Tuesday, 4 February 2014 12:06:06 UTC, Jay Fields wrote:
>>
>> tl; dr: I'm presenting "Lessons Learned from Adopting Clojure" in
>> Chicago on Feb 11th:
>> http://www.eventbrite.com/e/goto-night-with-jay-fields-
>> tickets-10366768283?aff=eorgf
>>
>> Five years ago DRW Trading was primarily a Java shop, and I was
>> primarily developing in Ruby. Needless to say, it wasn't a match made
>> in heaven. Fast forward five years, Clojure is the second most used
>> language in the firm, and the primary language for several teams
>> (including mine). Clojure wasn't the first language that I've
>> introduced to an organization; however, it's unquestionably the most
>> successful adoption I've ever been a part of. The use of Clojure has
>> had many impacts on the firm: culturally, politically, and
>> technically. My talk will discuss general ideas around language
>> selection and maintenance trade-offs, and specific examples of what
>> aspects of Clojure made it the correct choice for us.
>>
>> A few highlights
>>
>> - Where to first introduce a new language and your role as the
>> language care-taker.
>> - REPL driven development, putting TDD's 'rapid feedback' to shame.
>> - Operations impact of adding a language - i.e. get ready for some
>> DevOps.
>> - Functional programming, the Lisp Advantage, and their impact on
>> maintainability.
>>
>> Of course, no good experience report is all roses. The adoption has
>> seen several hurdles along the way, and I'll happily to describe those
>> as well.
>>
>  --
> 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/groups/opt_out.
>



-- 
Cheers,
Rafael Peixoto de Azevedo
http://www.symprise.net
@RPAzevedo

-- 
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/groups/opt_out.

Re: Lessons Learned from Adopting Clojure

[Mimmo Cosenza]

On Feb 4, 2014, at 1:06 PM, Jay Fields  wrote:

Hi Jay,
thanks for the report.  I only have few doubts about REPL making TDD to shame. 

I'm not a TDD practitioner, but I would not be so "tranchant" with it. 

The REPL is great, that's for sure, but IMHO it does not relegate TDD 
feedback/loop in a niche, because you can complement one with the other. 

I'm a fan of http://www.youtube.com/user/Misophistful?feature=watch stuff. he's 
able to be very clear and deep at the same time and if you take a look at his 
screencasts you would see that he uses both the REPL and the TDD at the same 
time. And he uses both unit test and simple-check tests as well. 

It is true that at  the moment the feedback-loop in clojurescript is not 
feasible, but the REPL experience with cljs has to be improved too to make it 
comparable with the clj REPL experience (at least with a nREPL compliant 
editor/ide).

Cheers

mimmo


> 
> - REPL driven development, putting TDD's 'rapid feedback' to shame.
> - Operations impact of adding a language - i.e. get ready for some DevOps.
> - Functional programming, the Lisp Advantage, and their impact on
> maintainability.
> 
> Of course, no good experience report is all roses. The adoption has
> seen several hurdles along the way, and I'll happily to describe those
> as well.
> 
> -- 
> 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/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/groups/opt_out.

Re: GSoC 2014: org applications now open

[Alex Miller]

Daniel, I'd be happy to help as an administrator, particularly if you can 
provide some guidance from previous years. I can also help re getting 
students to conferences.

Alex


On Monday, February 3, 2014 1:59:24 PM UTC-6, Daniel Solano Gómez wrote:
>
> Hello, all, 
>
> Apparently, it's already time for organisations to apply for Google Summer 
> of Coder 2014 [1].   This is a great program, and there have been several 
> notable projects that have benefited as a result.  For example, last year's 
> successful projects included: 
>
> * Enhance Neko for Android, Alexander Yakushev 
> * core.typed: Extensions and Documentation, Ambrose Bonnaire-Sergeant 
> * Clojure Compiler port to Clojure (CinC), Bronsa 
> * Implementation of core.matrix-compatible multidimensional array in 
> Clojure, Dmitry Groshev 
> * Algebraic Expressions, Maik Schünemann 
> * ClojureScript optimization and source maps support, Michal Marczyk 
>
> I would love to see Clojure participate again this year.  In order to do 
> so, we need to start our application which is due in less than two weeks. 
>  We need volunteers to help prepare our application, and in particular it 
> would be great to have administrators that can help lead the process.  I am 
> certainly willing to help out, but if there is someone who wants to lead up 
> this effort, I would happy to assist. 
>
> Ideally, we could have multiple administrators to spread out the following 
> duties: 
>
> * Updating the community wiki for the year [2] 
> * Recruiting potential mentors 
> * Raising the profile of GSoC within the community 
>
> If we are accepted as a GSoC organisation, administrator duties include: 
>
> * Ensuring we meet the deadlines 
> * Arranging for travel to the mentor submit 
> * Arranging for students' travel to conferences 
> * If necessary, solve problems 
>
> I am afraid that last year I let the ball drop a bit with the mentor 
> summit and getting students to conferences.  With multiple administrators 
> to help spread the work around, I am sure we can make GSoC an even better 
> experience for everyone involved. 
>
> If you are interested in helping out in this effort, please set up a 
> profile on Melange [3] and e-mail me your profile name.   
>
> Thanks for your help. 
>
> Sincerely, 
>
> Daniel 
>
>
> [1]: 
> http://google-opensource.blogspot.com/2014/02/mentoring-organization-applications-now.html
>  
> [2]: http://dev.clojure.org/display/community/Google+Summer+of+Code+2013 
> [3]: http://en.flossmanuals.net/melange/ 
>

-- 
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/groups/opt_out.

Re: Coverage tools in Clojure

[Aaron France]

On Tue, Feb 04, 2014 at 04:18:30AM -0800, Colin Yates wrote:
> Comments in line.
> On Tuesday, 4 February 2014 11:23:36 UTC, Aaron France wrote:
> >
> >
> > I don't want to seem rude but I think you've drank a bit too much 
> > kool-aid. 
> >
> You know the phrase "I don't want to seem rude" doesn't actually do 
> anything right?  :)
>  
>

I genuinely don't want to offend. People allow themselves to become
vested in their viewpoint. If that has happened to you, I'm sorry.

> > To say that functional programming and war against state means that 
> > your application doesn't need to be tested thoroughly is a joke. And a 
> > very bad one. 
> >
> I agree, but who is saying that?  I certainly didn't cover how much testing 
> is necessary.  I thoroughly test my Clojure systems using midje, which 
> regularly rocks my world.  My point is that the coverage is much *much* 
> easier to reason about in FP than in OO (for the reasons I gave).

I'm not following how you translate this into information which
explains how your system is being tested.

>  
> 
> > Coverage doesn't just aid you in seeing which parts of state caused 
> > which branches to be hit, it also gives you notice if there are any 
> > logical errors in your code which cause the branches to not be hit. 
> >
> And why are those logical errors which cause the branches to not be hit not 
> immediately obvious?  Why do you need a tool to tell you that?  I know my 
> Clojure code has around 100% coverage using white box testing for the 
> functions and mocking the interactions.

And what's the harm in getting this information from an automated
tool? With your 20 years industry knowledge you should know that you
cannot rely on humans to think and act reliably. It's just not a good
way to plan systems. *Especially* when it comes to asking someone how
correct their system is.
> 
> I would challenge you to put ego/emotion to one side, stop finding 
> non-existent points to argue against and re-read my post.  By all means 
> come back and justify why all the points I raised which reduce the need for 
> coverage are invalid.  Don't attribute stupid statements (like 'FP doesn't 
> need testing') to me - I can come up with my own stupid statements thank 
> you.

You hand waved the need to use tools such as coverage reports simply
on the virtue of some hard to quantify statements. I find that
unscientific.
> 
> If it helps, my stand point is from 20 years of building non-trivial 
> Enterprise applications (primarily Java) using the current best of breed 
> technology stacks (i.e Spring/Hibernate/AspectJ) with the best of breed 
> process (agile, TDD, DBC, BDD, most otherTLAs etc.).

Arguments from authority mean nothing on the internet.

> Using Clojure for the past year or so has opened my eyes to exactly
> how many problems we solve, and infrastructure we use is to pamper
> to complexity introduced by the tool-chain not the problem domain.
> I am suggesting maybe coverage tools are one of those.
>

Coverage helps nothing on its own. It's a tool to aid in knowing which
aspects of your system remain untested. It's fine to *believe* you're
testing 100% of your system, but how do you actually know this?

If you wander into a codebase you're not familiar with, what's the
coverage? How do you know you're hitting all codepaths? You just
cannot know this without reading all the code and the tests. Coverage
helps to discover this information.

My point isn't to eschew all other forms of testing in favour of
coverage reports but to use them in tandem with the others to aid me
in *knowing* which parts of the system are being tested and which are not.

Aaron

> 
> > Aaron 
> >
> > On Tue, Feb 04, 2014 at 03:19:05AM -0800, Colin Yates wrote: 
> > > I don't know. 
> > > 
> > > But maybe the lack of coverage tools is itself interesting?  My (not 
> > quite 
> > > formed/making this up as I go) view is that maybe coverage tools are 
> > there 
> > > to address the implicit complexity in other mainstream languages and/or 
> > to 
> > > help mitigate the risk of the potentially large and hard-to-identify 
> > > 'impact analysis' you get in OO systems when you change state.  In other 
> > > words, coverage is necessary because we want to feel safe that all 
> > > combinations of our code are extensively tested.  Why don't we feel 
> > safe? 
> > >  Because the system is hard to reason about. 
> > > 
> > > Functional programming on the other hand is full of much smaller 
> > discrete 
> > > and independent chunks of functionality.  Ideally these small focused 
> > > 'bricks' are pure/referentially transparent so the *only* context you 
> > need 
> > > when reasoning about them is their parameters and the logic inside. 
> > >  Assembling these bricks introduces interactions that need to be tested, 
> > > sure, but there are very few 'call this and watch the change 
> > cascade'/'this 
> > > code is sensitive (i.e. coupled) to that data over there'. 
> > > 
> > > My ramblings are to

Re: Coverage tools in Clojure

[Colin Yates]

This has turned into an unconstructive argument and for whatever reason we 
don't seem to be communicating clearly.  Shame as I (and probably most 
people on here) only want to help.  You seem to be reacting quite strongly 
to my thoughts - not sure why.

If I may, I will just make/rephrase two points:
 - I think you would find value in watching Rick Hickey's videos on "Simple 
Made Easy" and also the one where he talks about "Hammock Driven 
Development".
 - when I started using Clojure I immediately looked for equivalents of all 
the supporting infrastructure I used in good old Java land.  I have no idea 
of your situation, but if you are there you have a wonderful opportunity to 
re-examine and build up a whole new toolchain/approach to development that 
IME is significantly lighter and more powerful.  

Peace.

On Tuesday, 4 February 2014 13:49:49 UTC, Aaron France wrote:
>
> On Tue, Feb 04, 2014 at 04:18:30AM -0800, Colin Yates wrote: 
> > Comments in line. 
> > On Tuesday, 4 February 2014 11:23:36 UTC, Aaron France wrote: 
> > > 
> > > 
> > > I don't want to seem rude but I think you've drank a bit too much 
> > > kool-aid. 
> > > 
> > You know the phrase "I don't want to seem rude" doesn't actually do 
> > anything right?  :) 
> >   
> > 
>
> I genuinely don't want to offend. People allow themselves to become 
> vested in their viewpoint. If that has happened to you, I'm sorry. 
>
> > > To say that functional programming and war against state means that 
> > > your application doesn't need to be tested thoroughly is a joke. And a 
> > > very bad one. 
> > > 
> > I agree, but who is saying that?  I certainly didn't cover how much 
> testing 
> > is necessary.  I thoroughly test my Clojure systems using midje, which 
> > regularly rocks my world.  My point is that the coverage is much *much* 
> > easier to reason about in FP than in OO (for the reasons I gave). 
>
> I'm not following how you translate this into information which 
> explains how your system is being tested. 
>
> >   
> > 
> > > Coverage doesn't just aid you in seeing which parts of state caused 
> > > which branches to be hit, it also gives you notice if there are any 
> > > logical errors in your code which cause the branches to not be hit. 
> > > 
> > And why are those logical errors which cause the branches to not be hit 
> not 
> > immediately obvious?  Why do you need a tool to tell you that?  I know 
> my 
> > Clojure code has around 100% coverage using white box testing for the 
> > functions and mocking the interactions. 
>
> And what's the harm in getting this information from an automated 
> tool? With your 20 years industry knowledge you should know that you 
> cannot rely on humans to think and act reliably. It's just not a good 
> way to plan systems. *Especially* when it comes to asking someone how 
> correct their system is. 
> > 
> > I would challenge you to put ego/emotion to one side, stop finding 
> > non-existent points to argue against and re-read my post.  By all means 
> > come back and justify why all the points I raised which reduce the need 
> for 
> > coverage are invalid.  Don't attribute stupid statements (like 'FP 
> doesn't 
> > need testing') to me - I can come up with my own stupid statements thank 
> > you. 
>
> You hand waved the need to use tools such as coverage reports simply 
> on the virtue of some hard to quantify statements. I find that 
> unscientific. 
> > 
> > If it helps, my stand point is from 20 years of building non-trivial 
> > Enterprise applications (primarily Java) using the current best of breed 
> > technology stacks (i.e Spring/Hibernate/AspectJ) with the best of breed 
> > process (agile, TDD, DBC, BDD, most otherTLAs etc.). 
>
> Arguments from authority mean nothing on the internet. 
>
> > Using Clojure for the past year or so has opened my eyes to exactly 
> > how many problems we solve, and infrastructure we use is to pamper 
> > to complexity introduced by the tool-chain not the problem domain. 
> > I am suggesting maybe coverage tools are one of those. 
> > 
>
> Coverage helps nothing on its own. It's a tool to aid in knowing which 
> aspects of your system remain untested. It's fine to *believe* you're 
> testing 100% of your system, but how do you actually know this? 
>
> If you wander into a codebase you're not familiar with, what's the 
> coverage? How do you know you're hitting all codepaths? You just 
> cannot know this without reading all the code and the tests. Coverage 
> helps to discover this information. 
>
> My point isn't to eschew all other forms of testing in favour of 
> coverage reports but to use them in tandem with the others to aid me 
> in *knowing* which parts of the system are being tested and which are not. 
>
> Aaron 
>
> > 
> > > Aaron 
> > > 
> > > On Tue, Feb 04, 2014 at 03:19:05AM -0800, Colin Yates wrote: 
> > > > I don't know. 
> > > > 
> > > > But maybe the lack of coverage tools is itself interesting?  My (not 
> > > quite 
> > > > formed/ma

Re: Coverage tools in Clojure

[Aaron France]

I don't come from 'Java-land'. I'm primarily an Erlang developer,
which already is a very similar language to Clojure. Perhaps this is
why I'm not gushing about functional programming's panacea?

Aaron

On Tue, Feb 04, 2014 at 06:12:18AM -0800, Colin Yates wrote:
> This has turned into an unconstructive argument and for whatever reason we 
> don't seem to be communicating clearly.  Shame as I (and probably most 
> people on here) only want to help.  You seem to be reacting quite strongly 
> to my thoughts - not sure why.
> 
> If I may, I will just make/rephrase two points:
>  - I think you would find value in watching Rick Hickey's videos on "Simple 
> Made Easy" and also the one where he talks about "Hammock Driven 
> Development".
>  - when I started using Clojure I immediately looked for equivalents of all 
> the supporting infrastructure I used in good old Java land.  I have no idea 
> of your situation, but if you are there you have a wonderful opportunity to 
> re-examine and build up a whole new toolchain/approach to development that 
> IME is significantly lighter and more powerful.  
> 
> Peace.
> 
> On Tuesday, 4 February 2014 13:49:49 UTC, Aaron France wrote:
> >
> > On Tue, Feb 04, 2014 at 04:18:30AM -0800, Colin Yates wrote: 
> > > Comments in line. 
> > > On Tuesday, 4 February 2014 11:23:36 UTC, Aaron France wrote: 
> > > > 
> > > > 
> > > > I don't want to seem rude but I think you've drank a bit too much 
> > > > kool-aid. 
> > > > 
> > > You know the phrase "I don't want to seem rude" doesn't actually do 
> > > anything right?  :) 
> > >   
> > > 
> >
> > I genuinely don't want to offend. People allow themselves to become 
> > vested in their viewpoint. If that has happened to you, I'm sorry. 
> >
> > > > To say that functional programming and war against state means that 
> > > > your application doesn't need to be tested thoroughly is a joke. And a 
> > > > very bad one. 
> > > > 
> > > I agree, but who is saying that?  I certainly didn't cover how much 
> > testing 
> > > is necessary.  I thoroughly test my Clojure systems using midje, which 
> > > regularly rocks my world.  My point is that the coverage is much *much* 
> > > easier to reason about in FP than in OO (for the reasons I gave). 
> >
> > I'm not following how you translate this into information which 
> > explains how your system is being tested. 
> >
> > >   
> > > 
> > > > Coverage doesn't just aid you in seeing which parts of state caused 
> > > > which branches to be hit, it also gives you notice if there are any 
> > > > logical errors in your code which cause the branches to not be hit. 
> > > > 
> > > And why are those logical errors which cause the branches to not be hit 
> > not 
> > > immediately obvious?  Why do you need a tool to tell you that?  I know 
> > my 
> > > Clojure code has around 100% coverage using white box testing for the 
> > > functions and mocking the interactions. 
> >
> > And what's the harm in getting this information from an automated 
> > tool? With your 20 years industry knowledge you should know that you 
> > cannot rely on humans to think and act reliably. It's just not a good 
> > way to plan systems. *Especially* when it comes to asking someone how 
> > correct their system is. 
> > > 
> > > I would challenge you to put ego/emotion to one side, stop finding 
> > > non-existent points to argue against and re-read my post.  By all means 
> > > come back and justify why all the points I raised which reduce the need 
> > for 
> > > coverage are invalid.  Don't attribute stupid statements (like 'FP 
> > doesn't 
> > > need testing') to me - I can come up with my own stupid statements thank 
> > > you. 
> >
> > You hand waved the need to use tools such as coverage reports simply 
> > on the virtue of some hard to quantify statements. I find that 
> > unscientific. 
> > > 
> > > If it helps, my stand point is from 20 years of building non-trivial 
> > > Enterprise applications (primarily Java) using the current best of breed 
> > > technology stacks (i.e Spring/Hibernate/AspectJ) with the best of breed 
> > > process (agile, TDD, DBC, BDD, most otherTLAs etc.). 
> >
> > Arguments from authority mean nothing on the internet. 
> >
> > > Using Clojure for the past year or so has opened my eyes to exactly 
> > > how many problems we solve, and infrastructure we use is to pamper 
> > > to complexity introduced by the tool-chain not the problem domain. 
> > > I am suggesting maybe coverage tools are one of those. 
> > > 
> >
> > Coverage helps nothing on its own. It's a tool to aid in knowing which 
> > aspects of your system remain untested. It's fine to *believe* you're 
> > testing 100% of your system, but how do you actually know this? 
> >
> > If you wander into a codebase you're not familiar with, what's the 
> > coverage? How do you know you're hitting all codepaths? You just 
> > cannot know this without reading all the code and the tests. Coverage 
> > helps to discover this information. 

Re: Coverage tools in Clojure

[Colin Yates]

I have no idea why you aren't gushing.  I'm not gushing, and haven't gushed 
about anything technical for years because everything is a trade off and 
has its own compromises/ceremony.  I can see (and highly value) the 
benefits of Clojure, sure.

If you want to write of my point of view as 'gushing' and not bother to 
read it correctly then fine.  However, what is your objective in posting 
your statement to a public forum if not to start an argument?  

If you insist on sending more flame bait/trying to get a rise then let's 
take this offline and keep this list low noise.  My email address is colin 
full stop yates @ Google's mailing servers.com.

On Tuesday, 4 February 2014 14:17:25 UTC, Aaron France wrote:
>
> I don't come from 'Java-land'. I'm primarily an Erlang developer, 
> which already is a very similar language to Clojure. Perhaps this is 
> why I'm not gushing about functional programming's panacea? 
>
> Aaron 
>
> On Tue, Feb 04, 2014 at 06:12:18AM -0800, Colin Yates wrote: 
> > This has turned into an unconstructive argument and for whatever reason 
> we 
> > don't seem to be communicating clearly.  Shame as I (and probably most 
> > people on here) only want to help.  You seem to be reacting quite 
> strongly 
> > to my thoughts - not sure why. 
> > 
> > If I may, I will just make/rephrase two points: 
> >  - I think you would find value in watching Rick Hickey's videos on 
> "Simple 
> > Made Easy" and also the one where he talks about "Hammock Driven 
> > Development". 
> >  - when I started using Clojure I immediately looked for equivalents of 
> all 
> > the supporting infrastructure I used in good old Java land.  I have no 
> idea 
> > of your situation, but if you are there you have a wonderful opportunity 
> to 
> > re-examine and build up a whole new toolchain/approach to development 
> that 
> > IME is significantly lighter and more powerful.   
> > 
> > Peace. 
> > 
> > On Tuesday, 4 February 2014 13:49:49 UTC, Aaron France wrote: 
> > > 
> > > On Tue, Feb 04, 2014 at 04:18:30AM -0800, Colin Yates wrote: 
> > > > Comments in line. 
> > > > On Tuesday, 4 February 2014 11:23:36 UTC, Aaron France wrote: 
> > > > > 
> > > > > 
> > > > > I don't want to seem rude but I think you've drank a bit too much 
> > > > > kool-aid. 
> > > > > 
> > > > You know the phrase "I don't want to seem rude" doesn't actually do 
> > > > anything right?  :) 
> > > >   
> > > > 
> > > 
> > > I genuinely don't want to offend. People allow themselves to become 
> > > vested in their viewpoint. If that has happened to you, I'm sorry. 
> > > 
> > > > > To say that functional programming and war against state means 
> that 
> > > > > your application doesn't need to be tested thoroughly is a joke. 
> And a 
> > > > > very bad one. 
> > > > > 
> > > > I agree, but who is saying that?  I certainly didn't cover how much 
> > > testing 
> > > > is necessary.  I thoroughly test my Clojure systems using midje, 
> which 
> > > > regularly rocks my world.  My point is that the coverage is much 
> *much* 
> > > > easier to reason about in FP than in OO (for the reasons I gave). 
> > > 
> > > I'm not following how you translate this into information which 
> > > explains how your system is being tested. 
> > > 
> > > >   
> > > > 
> > > > > Coverage doesn't just aid you in seeing which parts of state 
> caused 
> > > > > which branches to be hit, it also gives you notice if there are 
> any 
> > > > > logical errors in your code which cause the branches to not be 
> hit. 
> > > > > 
> > > > And why are those logical errors which cause the branches to not be 
> hit 
> > > not 
> > > > immediately obvious?  Why do you need a tool to tell you that?  I 
> know 
> > > my 
> > > > Clojure code has around 100% coverage using white box testing for 
> the 
> > > > functions and mocking the interactions. 
> > > 
> > > And what's the harm in getting this information from an automated 
> > > tool? With your 20 years industry knowledge you should know that you 
> > > cannot rely on humans to think and act reliably. It's just not a good 
> > > way to plan systems. *Especially* when it comes to asking someone how 
> > > correct their system is. 
> > > > 
> > > > I would challenge you to put ego/emotion to one side, stop finding 
> > > > non-existent points to argue against and re-read my post.  By all 
> means 
> > > > come back and justify why all the points I raised which reduce the 
> need 
> > > for 
> > > > coverage are invalid.  Don't attribute stupid statements (like 'FP 
> > > doesn't 
> > > > need testing') to me - I can come up with my own stupid statements 
> thank 
> > > > you. 
> > > 
> > > You hand waved the need to use tools such as coverage reports simply 
> > > on the virtue of some hard to quantify statements. I find that 
> > > unscientific. 
> > > > 
> > > > If it helps, my stand point is from 20 years of building non-trivial 
> > > > Enterprise applications (primarily Java) using the current best of 
> breed 
> > >

Re: Coverage tools in Clojure

[Aaron France]

I took issue with you maintaining that Clojure automatically somehow
gives you insight into the coverage of your tests. Which it does not.

You still maintain this.

On Tue, Feb 04, 2014 at 06:28:51AM -0800, Colin Yates wrote:
> I have no idea why you aren't gushing.  I'm not gushing, and haven't gushed 
> about anything technical for years because everything is a trade off and 
> has its own compromises/ceremony.  I can see (and highly value) the 
> benefits of Clojure, sure.
> 
> If you want to write of my point of view as 'gushing' and not bother to 
> read it correctly then fine.  However, what is your objective in posting 
> your statement to a public forum if not to start an argument?  
> 
> If you insist on sending more flame bait/trying to get a rise then let's 
> take this offline and keep this list low noise.  My email address is colin 
> full stop yates @ Google's mailing servers.com.
> 
> On Tuesday, 4 February 2014 14:17:25 UTC, Aaron France wrote:
> >
> > I don't come from 'Java-land'. I'm primarily an Erlang developer, 
> > which already is a very similar language to Clojure. Perhaps this is 
> > why I'm not gushing about functional programming's panacea? 
> >
> > Aaron 
> >
> > On Tue, Feb 04, 2014 at 06:12:18AM -0800, Colin Yates wrote: 
> > > This has turned into an unconstructive argument and for whatever reason 
> > we 
> > > don't seem to be communicating clearly.  Shame as I (and probably most 
> > > people on here) only want to help.  You seem to be reacting quite 
> > strongly 
> > > to my thoughts - not sure why. 
> > > 
> > > If I may, I will just make/rephrase two points: 
> > >  - I think you would find value in watching Rick Hickey's videos on 
> > "Simple 
> > > Made Easy" and also the one where he talks about "Hammock Driven 
> > > Development". 
> > >  - when I started using Clojure I immediately looked for equivalents of 
> > all 
> > > the supporting infrastructure I used in good old Java land.  I have no 
> > idea 
> > > of your situation, but if you are there you have a wonderful opportunity 
> > to 
> > > re-examine and build up a whole new toolchain/approach to development 
> > that 
> > > IME is significantly lighter and more powerful.   
> > > 
> > > Peace. 
> > > 
> > > On Tuesday, 4 February 2014 13:49:49 UTC, Aaron France wrote: 
> > > > 
> > > > On Tue, Feb 04, 2014 at 04:18:30AM -0800, Colin Yates wrote: 
> > > > > Comments in line. 
> > > > > On Tuesday, 4 February 2014 11:23:36 UTC, Aaron France wrote: 
> > > > > > 
> > > > > > 
> > > > > > I don't want to seem rude but I think you've drank a bit too much 
> > > > > > kool-aid. 
> > > > > > 
> > > > > You know the phrase "I don't want to seem rude" doesn't actually do 
> > > > > anything right?  :) 
> > > > >   
> > > > > 
> > > > 
> > > > I genuinely don't want to offend. People allow themselves to become 
> > > > vested in their viewpoint. If that has happened to you, I'm sorry. 
> > > > 
> > > > > > To say that functional programming and war against state means 
> > that 
> > > > > > your application doesn't need to be tested thoroughly is a joke. 
> > And a 
> > > > > > very bad one. 
> > > > > > 
> > > > > I agree, but who is saying that?  I certainly didn't cover how much 
> > > > testing 
> > > > > is necessary.  I thoroughly test my Clojure systems using midje, 
> > which 
> > > > > regularly rocks my world.  My point is that the coverage is much 
> > *much* 
> > > > > easier to reason about in FP than in OO (for the reasons I gave). 
> > > > 
> > > > I'm not following how you translate this into information which 
> > > > explains how your system is being tested. 
> > > > 
> > > > >   
> > > > > 
> > > > > > Coverage doesn't just aid you in seeing which parts of state 
> > caused 
> > > > > > which branches to be hit, it also gives you notice if there are 
> > any 
> > > > > > logical errors in your code which cause the branches to not be 
> > hit. 
> > > > > > 
> > > > > And why are those logical errors which cause the branches to not be 
> > hit 
> > > > not 
> > > > > immediately obvious?  Why do you need a tool to tell you that?  I 
> > know 
> > > > my 
> > > > > Clojure code has around 100% coverage using white box testing for 
> > the 
> > > > > functions and mocking the interactions. 
> > > > 
> > > > And what's the harm in getting this information from an automated 
> > > > tool? With your 20 years industry knowledge you should know that you 
> > > > cannot rely on humans to think and act reliably. It's just not a good 
> > > > way to plan systems. *Especially* when it comes to asking someone how 
> > > > correct their system is. 
> > > > > 
> > > > > I would challenge you to put ego/emotion to one side, stop finding 
> > > > > non-existent points to argue against and re-read my post.  By all 
> > means 
> > > > > come back and justify why all the points I raised which reduce the 
> > need 
> > > > for 
> > > > > coverage are invalid.  Don't attribute stupid statements (like 'FP 
> > > > does

Re: Coverage tools in Clojure

[Colin Yates]

I said that coverage tools answer a specific question; 'how much of my code 
is executed when I do this', where 'this' is typically running a set of 
tests.  People use that answer to infer how 'safe' their system is because 
they equate test coverage and safety (which is often a flawed inference).  

In some environments there is so much incidental complexity that these 
metrics are hard to calculate by hand (mutating state, deep object 
hierarchies etc.).  FP has a number of different design decisions which can 
significantly reduce that incidental complexity, so if a tool is still 
needed maybe the cause is somewhere else - too much coupling/not enough 
ignorance etc.  

I think we fundamentally come from different places as I do think you can 
trust people and I would choose a couple of decent engineers (although they 
are as rare as hen's teeth) without any tools over all the tools in the 
world.

To be clear, I am not saying I don't see the need for code coverage, I am 
saying it should be much easier to keep track of code coverage in an FP 
system done well primarily due to the wonderfully low level of influence 
referential transparency gives you (for example).  On the other hand I 
absolutely see the need for an automated tool in other environments because 
of the implicit complexity.  

If you thoroughly test all your code when you write it why do you need a 
tool to tell you you missed something?  

Again, note I am talking only about calculating test coverage and not about 
testing or how much there should be.

Not sure how many ways I can say the same thing, but let's try one more; I 
never said it was Clojure automatically doing anything, I said it is 
possible for a good engineer to know the coverage and safety of their 
systems themselves in a well designed and implemented system.  Some 
environments are full of complexity which make it heard, hence the need for 
a tool.  I am not categorically saying I can't imagine a world where I 
would need said tool in a FP system, but my first question would be am I 
using a tool to solve a symptom of poor design.

In terms of analysing a new system?  When I was a consultant reviewing 
other's work the best tool I used was a whiteboard, a pen and their 
architect.  I found that if their system *needed* a coverage tool the tests 
were probably so poorly written as to add very little value.

I would genuinely like you/others to prove/disprove these points as this is 
an area I am still thinking/learning about (as evidenced by my first and 
last sentence in the original post) and would love to have a useful 
discussion.  You haven't bought anything to the table other than little 
jibes and emotive statements unfortunately.

Let's agree to disagree, and if you can resist having a dig on a public 
forum (feel free to continue over personal email) let's draw this to a 
close.

On Tuesday, 4 February 2014 14:30:29 UTC, Aaron France wrote:
>
> I took issue with you maintaining that Clojure automatically somehow 
> gives you insight into the coverage of your tests. Which it does not. 
>
> You still maintain this. 
>
> On Tue, Feb 04, 2014 at 06:28:51AM -0800, Colin Yates wrote: 
> > I have no idea why you aren't gushing.  I'm not gushing, and haven't 
> gushed 
> > about anything technical for years because everything is a trade off and 
> > has its own compromises/ceremony.  I can see (and highly value) the 
> > benefits of Clojure, sure. 
> > 
> > If you want to write of my point of view as 'gushing' and not bother to 
> > read it correctly then fine.  However, what is your objective in posting 
> > your statement to a public forum if not to start an argument?   
> > 
> > If you insist on sending more flame bait/trying to get a rise then let's 
> > take this offline and keep this list low noise.  My email address is 
> colin 
> > full stop yates @ Google's mailing servers.com. 
> > 
> > On Tuesday, 4 February 2014 14:17:25 UTC, Aaron France wrote: 
> > > 
> > > I don't come from 'Java-land'. I'm primarily an Erlang developer, 
> > > which already is a very similar language to Clojure. Perhaps this is 
> > > why I'm not gushing about functional programming's panacea? 
> > > 
> > > Aaron 
> > > 
> > > On Tue, Feb 04, 2014 at 06:12:18AM -0800, Colin Yates wrote: 
> > > > This has turned into an unconstructive argument and for whatever 
> reason 
> > > we 
> > > > don't seem to be communicating clearly.  Shame as I (and probably 
> most 
> > > > people on here) only want to help.  You seem to be reacting quite 
> > > strongly 
> > > > to my thoughts - not sure why. 
> > > > 
> > > > If I may, I will just make/rephrase two points: 
> > > >  - I think you would find value in watching Rick Hickey's videos on 
> > > "Simple 
> > > > Made Easy" and also the one where he talks about "Hammock Driven 
> > > > Development". 
> > > >  - when I started using Clojure I immediately looked for equivalents 
> of 
> > > all 
> > > > the supporting infrastructure I used in good 

Re: lispy.el - a vi-like Paredit. Some Clojure features added.

[Oleh]

OK, I've added a second screencast as both video and gif:
https://raw.github.com/abo-abo/lispy/master/doc/screencast-2.ogv
https://raw.github.com/abo-abo/lispy/master/doc/screencast-2.gif

Oleh

On Tuesday, February 4, 2014 7:41:15 AM UTC+1, Benjamin Peter wrote:
>
> Thanks but it is playing way too fast considering you have to monitor two 
> windows. (buffer and keys).

-- 
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/groups/opt_out.

Re: lispy.el - a vi-like Paredit. Some Clojure features added.

[Colin Yates]

This looks excellent!  Desperately trying to suppress the whole emacs/vi 
battle raging inside which has is now rising up again :).

On Sunday, 2 February 2014 13:44:12 UTC, Oleh wrote:
>
> Hi all,
>
> I've recently added some Clojure support to
> https://github.com/abo-abo/lispy.
>
> A short description of the package is that it's all the Paredit
> functions (and more) bound to unprefixed keys, e.g. "a", "c", "1", "2"
> etc. Nothing to do with evil package. Keys call commands instead
> of self-inserting when the point is in positions called special
> (marked here with |):
>
> |(defn sqr |[x]| |(* x x)|)|
>
> This comes together nicely since you rarely want to self-insert in those 
> positions.
>
> Just to show how succinct the usage can be, you can transform
> from this:
>
> |(defn sqr [x] (* x x))
>
> with just "4c" to this:
>
> |(defn sqr [x] (* x x))
> (defn sqr [x] (* x x))
> (defn sqr [x] (* x x))
> (defn sqr [x] (* x x))
> (defn sqr [x] (* x x))
>
> and further with "3j" to this:
>
> (defn sqr [x] (* x x))
> (defn sqr [x] (* x x))
> (defn sqr [x] (* x x))
> |(defn sqr [x] (* x x))
> (defn sqr [x] (* x x))
>
> and further with "2;" to this:
>
> (defn sqr [x] (* x x))
> (defn sqr [x] (* x x))
> (defn sqr [x] (* x x))
> ;; (defn sqr [x] (* x x))
> ;; (defn sqr [x] (* x x))
>
> Here's another example that shows how to transform
>
> |(map sqr (filter odd? [1 2 3 4 5]))
>
> to
>
> (->> [1 2 3 4 5]
>  (map sqr)
>  (filter odd?))|
>
> I show it in a run-able test form (many more tests at github):
>
> (should
>  (string=
>   (lispy-with
>"|(map sqr (filter odd? [1 2 3 4 5]))" "2(->>]<]<]wwlM")
>   "(->> [1 2 3 4 5]\n  (map sqr)\n  (filter odd?))|"))
>
> The steps are:
>
> 1. "2(" - wrap with parens. 
> 2. "->>" - self-insert (because point isn't special).
> 3. "]" - forward list - point becomes special.
> 4. "<" - barf.
> 5. "]<]" - forward, barf, forward.
> 6. "ww" - move sexp up twice.
> 7. "l" - exit list forwards.
> 8. "M" - transform sexp to multi-line.
> 9. you can "e" - eval to see if code works.
> 
> Full description and some screenshots can be found at 
> https://github.com/abo-abo/lispy.
>
> Here's a list of Clojure-specific features (cider is used for most):
>
> - look up doc inline in an overlay with "C-1"
> - look up function arguments inline with "C-2"
> - eval with "e"
> - eval and insert with "E"
> - goto symbol in file with "g" (clojure-semantic required)
> - goto definition with "F"
>
> The package is available in MELPA if you want to give it a go.
> Feedback welcome.
>
> regards,
> Oleh
>
>
>
>

-- 
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/groups/opt_out.

Re: Lessons Learned from Adopting Clojure

[Jay Fields]

On Tuesday, February 4, 2014 8:17:44 AM UTC-5, Magomimmo wrote:

> thanks for the report.  I only have few doubts about REPL making TDD to 
> shame. 
>

In this blog entry - 
http://blog.jayfields.com/2014/01/repl-driven-development.html - I 
demonstrate (very briefly, by design) my workflow. I also give my thoughts 
on TDD.

On Tuesday, February 4, 2014 7:24:21 AM UTC-5, Rafael Peixoto de Azevedo 
wrote:
>
> +1 from Melbourne :)
>

I actually gave the talk in Melbourne, as part of YOW!. It was recorded and 
will be online at some point.

On Tuesday, February 4, 2014 7:22:06 AM UTC-5, Colin Yates wrote:
>
> Is there going to be online access during/after the event?  I would 
> greatly value seeing this, but probably not enough to travel from the UK to 
> Chicago :).
>

This talk will not be recorded (afaik), but it's the same as the YOW! 
version, and that should be online soon. 

On Tuesday, February 4, 2014 8:02:28 AM UTC-5, ajlopez wrote:
>
> A question: did you abandon TDD? why?
> IMO, TDD is a workflow that pushes for simplicity
>

TDD, yes, for the most part. However, I still write a large number of 
tests. YMMV though, as you may find that TDD gives you better design 
direction. Assuming that's the case, I'd never try to convince you to do 
something else. This is an experience report, not a prescription for 
adopting Clojure. =) 


-- 
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/groups/opt_out.

Re: Lessons Learned from Adopting Clojure

[Colin Yates]

Jay - in your demo I can't determine whether the (+ 2 2) expression is 
evaluated and the results pasted inline or whether you have manually pasted 
them?

I see you are using emacs, can you detail how you have configured emacs?

On Tuesday, 4 February 2014 16:33:44 UTC, Jay Fields wrote:
>
> On Tuesday, February 4, 2014 8:17:44 AM UTC-5, Magomimmo wrote:
>
>> thanks for the report.  I only have few doubts about REPL making TDD to 
>> shame. 
>>
>
> In this blog entry - 
> http://blog.jayfields.com/2014/01/repl-driven-development.html - I 
> demonstrate (very briefly, by design) my workflow. I also give my thoughts 
> on TDD.
>
> On Tuesday, February 4, 2014 7:24:21 AM UTC-5, Rafael Peixoto de Azevedo 
> wrote:
>>
>> +1 from Melbourne :)
>>
>
> I actually gave the talk in Melbourne, as part of YOW!. It was recorded 
> and will be online at some point.
>
> On Tuesday, February 4, 2014 7:22:06 AM UTC-5, Colin Yates wrote:
>>
>> Is there going to be online access during/after the event?  I would 
>> greatly value seeing this, but probably not enough to travel from the UK to 
>> Chicago :).
>>
>
> This talk will not be recorded (afaik), but it's the same as the YOW! 
> version, and that should be online soon. 
>
> On Tuesday, February 4, 2014 8:02:28 AM UTC-5, ajlopez wrote:
>>
>> A question: did you abandon TDD? why?
>> IMO, TDD is a workflow that pushes for simplicity
>>
>
> TDD, yes, for the most part. However, I still write a large number of 
> tests. YMMV though, as you may find that TDD gives you better design 
> direction. Assuming that's the case, I'd never try to convince you to do 
> something else. This is an experience report, not a prescription for 
> adopting Clojure. =) 
>
>
>

-- 
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/groups/opt_out.

Re: Lessons Learned from Adopting Clojure

[Mimmo Cosenza]

On Feb 4, 2014, at 5:33 PM, Jay Fields  wrote:

> On Tuesday, February 4, 2014 8:17:44 AM UTC-5, Magomimmo wrote:
> thanks for the report.  I only have few doubts about REPL making TDD to 
> shame. 
> 
> In this blog entry - 
> http://blog.jayfields.com/2014/01/repl-driven-development.html - I 
> demonstrate (very briefly, by design) my workflow. I also give my thoughts on 
> TDD.

Thanks Jay, in the post you were less "tranchant" about TDD. As I said I'm not 
a TDD practitioner, but recently I started to appreciated it by mixing my REPL 
based workflow, mostly when I'm writing portable CLJ/CLJS code (you can't image 
how many subtle differences I discovered between CLJ and CLJS in this way.

Thanks again

mimmo


-- 
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/groups/opt_out.

Re: Lessons Learned from Adopting Clojure

[Jay Fields]

Colin, I'm using emacs-live: http://overtone.github.io/emacs-live/

To evaluate (+ 2 2) and spit the results I'm using C-u C-x C-e

It's definitely an evaluation, not a copy paste of the results.

Cheers, Jay

On Tue, Feb 4, 2014 at 11:43 AM, Colin Yates  wrote:
> Jay - in your demo I can't determine whether the (+ 2 2) expression is
> evaluated and the results pasted inline or whether you have manually pasted
> them?
>
> I see you are using emacs, can you detail how you have configured emacs?
>
>
> On Tuesday, 4 February 2014 16:33:44 UTC, Jay Fields wrote:
>>
>> On Tuesday, February 4, 2014 8:17:44 AM UTC-5, Magomimmo wrote:
>>>
>>> thanks for the report.  I only have few doubts about REPL making TDD to
>>> shame.
>>
>>
>> In this blog entry -
>> http://blog.jayfields.com/2014/01/repl-driven-development.html - I
>> demonstrate (very briefly, by design) my workflow. I also give my thoughts
>> on TDD.
>>
>> On Tuesday, February 4, 2014 7:24:21 AM UTC-5, Rafael Peixoto de Azevedo
>> wrote:
>>>
>>> +1 from Melbourne :)
>>
>>
>> I actually gave the talk in Melbourne, as part of YOW!. It was recorded
>> and will be online at some point.
>>
>> On Tuesday, February 4, 2014 7:22:06 AM UTC-5, Colin Yates wrote:
>>>
>>> Is there going to be online access during/after the event?  I would
>>> greatly value seeing this, but probably not enough to travel from the UK to
>>> Chicago :).
>>
>>
>> This talk will not be recorded (afaik), but it's the same as the YOW!
>> version, and that should be online soon.
>>
>> On Tuesday, February 4, 2014 8:02:28 AM UTC-5, ajlopez wrote:
>>>
>>> A question: did you abandon TDD? why?
>>> IMO, TDD is a workflow that pushes for simplicity
>>
>>
>> TDD, yes, for the most part. However, I still write a large number of
>> tests. YMMV though, as you may find that TDD gives you better design
>> direction. Assuming that's the case, I'd never try to convince you to do
>> something else. This is an experience report, not a prescription for
>> adopting Clojure. =)
>>
>>
> --
> 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/huwg05Vl2RY/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/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/groups/opt_out.

Re: Lessons Learned from Adopting Clojure

[Sean Corfield]

Discussions around TDD / RDD (REPL-Driven-Development) probably need a separate 
thread but...

On Feb 4, 2014, at 5:17 AM, Mimmo Cosenza  wrote:
> thanks for the report.  I only have few doubts about REPL making TDD to shame.

I'm a strong advocate of TDD (well, BDD specifically) and I agree with Jay's 
comment insofar as you write a "test" expression in the REPL and it evaluates 
immediately. That's always faster than writing a test and running a test, by 
definition. That's all I took his comment to mean.

> The REPL is great, that's for sure, but IMHO it does not relegate TDD 
> feedback/loop in a niche, because you can complement one with the other.

Indeed you can - and Jay does - and so do I. Especially now I'm using 
LightTable and can evaluate code in place in amongst my production code in one 
tabset and my expectations in another tabset. I have C-c , bound to evaluate a 
"run-tests" expression in my namespace so I can quickly evaluate and execute 
tests. Even so, live evaluation of "test code" is still a faster feedback loop.

Many of my test expressions become long-lived unit tests (expectations). Or 
they become production code. I still write expectations to clarify how to 
design APIs in the small (and APIs in the large as needed), but most of the 
red-green-refactor loop of TDD/BDD now comes from the REPL experiments for me.

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

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Should predicates always have one argument?

[Ryan]

Thank you all for your answers, they helped me a lot :)

Cheers

On Saturday, February 1, 2014 12:10:42 AM UTC+2, Ivan L wrote:
>
> I typically wrap stuff with (partial) for easier reading.  In your example 
> you might use something like following.
>
> (defn are-valid
>   [maps validator]
>   (let [valid? (partial validator)]
> (map valid? maps)))
>
> On Friday, January 31, 2014 11:44:38 AM UTC-5, Ryan wrote:
>>
>> Hello,
>>
>> I am wondering if all my predicates should be one argument functions 
>> because I run into a couple of cases where I needed more than one.
>>
>> For example, I have a function called valid-params? which takes two 
>> parameters; the validator to use and a maps parameter.
>> Is this approach wrong/not the clojure way?
>>
>> What are my alternatives? Should I just use a different function name 
>> which does not have a question mark at the end that implies that is a 
>> predicate?
>>
>> Cheers,
>>
>> Ryan
>>
>

-- 
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/groups/opt_out.

Re: Lessons Learned from Adopting Clojure

[Mimmo Cosenza]

On Feb 4, 2014, at 6:13 PM, Sean Corfield  wrote:

> 
>> The REPL is great, that's for sure, but IMHO it does not relegate TDD 
>> feedback/loop in a niche, because you can complement one with the other.
> 
> Indeed you can - and Jay does - and so do I.


And me too. So we are all in the same boat :-).

mimmo

-- 
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/groups/opt_out.

Re: Why do I get stackoverflow error?

[Sean Corfield]

Another option is:

((fn pascal ([n] (pascal n [1M])) ([n row] (if (= n 1) row (recur (dec n) (mapv 
(partial reduce +) (partition 2 1 (cons 0 (conj row 0 500)

Because row is a vector you can conj 0 to the end (quickly) and cons 0 to the 
front (quickly) and then mapv makes sure you get a vector back.

Sean

On Feb 4, 2014, at 2:39 AM, Andy Smith  wrote:

> Ok thanks, thats really helpful. The second link suggests using doall, which 
> seems to do the trick :
> 
> ((fn pascal ([n] (pascal n [1M])) ([n row] (if (= n 1) row (recur (dec n) 
> (map (partial reduce +) (doall (partition 2 1 (concat [0] row [0] 500)
> 
> However you do lose the laziness, but here the laziness is not needed ...
> 




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Coverage tools in Clojure

[Aaron France]

On Tue, Feb 04, 2014 at 07:01:31AM -0800, Colin Yates wrote:
> I said that coverage tools answer a specific question; 'how much of my code 
> is executed when I do this', where 'this' is typically running a set of 
> tests.  People use that answer to infer how 'safe' their system is because 
> they equate test coverage and safety (which is often a flawed inference).  


I certainly don't connotate high coverage with a safe system. No-one
said that.

I use coverage to answer two questions:

* Which lines of code are being hit during testing?
* Which lines of code are not being hit during testing?

You'll be surprised at how many times I've discovered dead code,
needless checks, error handling etc just simply looking at what code
was used when. A functional programming language allows you to write
code which isn't used.

> 
> In some environments there is so much incidental complexity that these 
> metrics are hard to calculate by hand (mutating state, deep object 
> hierarchies etc.).  FP has a number of different design decisions which can 
> significantly reduce that incidental complexity, so if a tool is still 
> needed maybe the cause is somewhere else - too much coupling/not enough 
> ignorance etc.  
> 
> I think we fundamentally come from different places as I do think you can 
> trust people and I would choose a couple of decent engineers (although they 
> are as rare as hen's teeth) without any tools over all the tools in the 
> world.

You present a false dichotomy here. You can have both. Good engineers
aren't afraid to use tools where they make sense.

> To be clear, I am not saying I don't see the need for code coverage, I am 
> saying it should be much easier to keep track of code coverage in an FP 
> system done well primarily due to the wonderfully low level of influence 
> referential transparency gives you (for example).  On the other hand I 
> absolutely see the need for an automated tool in other environments because 
> of the implicit complexity.  

You used the words "should be", therefore I will assume you haven't
conducted any scientific studies to show these facts. May we ignore
this point?

These kinds of things are hard to quantify.

> If you thoroughly test all your code when you write it why do you need a 
> tool to tell you you missed something?

This is just so brain-dead stupid.

How do you *know* that you thoroughly tested your code? Where do you
get these metrics? There are various methods you need to employ before
you can even beging to feel comfortable about saying you have
'thoroughly' tested code. Coverage is one method amongst many.

> 
> Again, note I am talking only about calculating test coverage and not about 
> testing or how much there should be.
> 
> Not sure how many ways I can say the same thing, but let's try one more; I 
> never said it was Clojure automatically doing anything, I said it is 
> possible for a good engineer to know the coverage and safety of their 
> systems themselves in a well designed and implemented system.  Some 
> environments are full of complexity which make it heard, hence the need for 
> a tool.  I am not categorically saying I can't imagine a world where I 
> would need said tool in a FP system, but my first question would be am I 
> using a tool to solve a symptom of poor design.

You ask me to disprove things like this? Are you kidding? This is just
hand-wavey and pulled out of the air. To say a good engineer can
calculate complexity themselves is just asking for trouble. The less
you rely on human behaviour the closer you get to doing science.

> 
> In terms of analysing a new system?  When I was a consultant reviewing 
> other's work the best tool I used was a whiteboard, a pen and their 
> architect.

And what happens to this data? Did you store it? Did you write it
down? Could you pass that data onto other people easily?

It seems that institutional knowledge such as this is a bigger cause
for concern than simply using coverage tools.

> I found that if their system *needed* a coverage tool the tests were
> probably so poorly written as to add very little value.

At this point I'm beginning to suspect you've never really used a
coverage tool properly. Coverage is used in conjunction with other
methods to gain knowledge about your system, if you rely on coverage
alone (and don't act on the results so long that you *continually*
need it) then you have bigger problems than poor tests.

> 
> I would genuinely like you/others to prove/disprove these points as this is 
> an area I am still thinking/learning about (as evidenced by my first and 
> last sentence in the original post) and would love to have a useful 
> discussion.  You haven't bought anything to the table other than little 
> jibes and emotive statements unfortunately.

> 
> Let's agree to disagree, and if you can resist having a dig on a public 
> forum (feel free to continue over personal email) let's draw this to a 
> close.
> 
> On Tuesday, 4 February 2014 14:30:29 

Live coding with Clojure and Emacs

[Daniel Szmulewicz]

A blog post  meant to demonstrate the symbiosis between powerful 
interactive programming environments such as Clojure and Emacs.

http://danielsz.github.io/2014/01/20/Live-coding-with-Clojure-and-Emacs/

-- 
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/groups/opt_out.

jvm.tools.analyzer 0.6.1

[Ambrose Bonnaire-Sergeant]

Hi,

jvm.tools.analyzer 0.6.1 now supports ClojureScript 0.0-2138.

[org.clojure/jvm.tools.analyzer "0.6.1"]

README 
CHANGELOG

Thanks,
Ambrose

-- 
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/groups/opt_out.

Re: Lessons Learned from Adopting Clojure

[Colin Yates]

Without starting a flame war - how are you finding LightTable for 
production?  Moving away from emacs and paredit would be quite hard and 
every time I look at LightTable I get really excited until I actually 
download and try it...  That is almost certainly because I don't have the 
time to invest in learning it and I expect it to do everything out of the 
box immediately and just the way I like it :)

On Tuesday, 4 February 2014 17:13:04 UTC, Sean Corfield wrote:
>
> Discussions around TDD / RDD (REPL-Driven-Development) probably need a 
> separate thread but... 
>
> On Feb 4, 2014, at 5:17 AM, Mimmo Cosenza > 
> wrote: 
> > thanks for the report.  I only have few doubts about REPL making TDD to 
> shame. 
>
> I'm a strong advocate of TDD (well, BDD specifically) and I agree with 
> Jay's comment insofar as you write a "test" expression in the REPL and it 
> evaluates immediately. That's always faster than writing a test and running 
> a test, by definition. That's all I took his comment to mean. 
>
> > The REPL is great, that's for sure, but IMHO it does not relegate TDD 
> feedback/loop in a niche, because you can complement one with the other. 
>
> Indeed you can - and Jay does - and so do I. Especially now I'm using 
> LightTable and can evaluate code in place in amongst my production code in 
> one tabset and my expectations in another tabset. I have C-c , bound to 
> evaluate a "run-tests" expression in my namespace so I can quickly evaluate 
> and execute tests. Even so, live evaluation of "test code" is still a 
> faster feedback loop. 
>
> Many of my test expressions become long-lived unit tests (expectations). 
> Or they become production code. I still write expectations to clarify how 
> to design APIs in the small (and APIs in the large as needed), but most of 
> the red-green-refactor loop of TDD/BDD now comes from the REPL experiments 
> for me. 
>
> Sean Corfield -- (904) 302-SEAN 
> An Architect's View -- http://corfield.org/ 
>
> "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/groups/opt_out.

Re: Lessons Learned from Adopting Clojure

[Göktuğ Kayaalp]

Colin Yates  writes:

AFAIK LightTable has paredit or sth. similar.  Also, a great deal of
customisation is available via ClojureScript.  I am personally favouring
Emacs as I am a polyglot programmer and do not only use Emacs as an
editor, but the programming and computing environment: This post is sent
via Emacs (Gnus), I write my blog posts with it, run shells, use git
(magit) and even view photos and PDFs.

If all you look is an editor/IDE-ish though, Emacs and LightTable are
quite the same thing indeed, except for the fact that Emacs has better
community and more packages.

> Without starting a flame war - how are you finding LightTable for 
> production?  Moving away from emacs and paredit would be quite hard and 
> every time I look at LightTable I get really excited until I actually 
> download and try it...  That is almost certainly because I don't have the 
> time to invest in learning it and I expect it to do everything out of ethe 
> box immediately and just the way I like it :)
>
> On Tuesday, 4 February 2014 17:13:04 UTC, Sean Corfield wrote:
>>
>> Discussions around TDD / RDD (REPL-Driven-Development) probably need a 
>> separate thread but... 
>>
>> On Feb 4, 2014, at 5:17 AM, Mimmo Cosenza > 
>> wrote: 
>> > thanks for the report.  I only have few doubts about REPL making TDD to 
>> shame. 
>>
>> I'm a strong advocate of TDD (well, BDD specifically) and I agree with 
>> Jay's comment insofar as you write a "test" expression in the REPL and it 
>> evaluates immediately. That's always faster than writing a test and running 
>> a test, by definition. That's all I took his comment to mean. 
>>
>> > The REPL is great, that's for sure, but IMHO it does not relegate TDD 
>> feedback/loop in a niche, because you can complement one with the other. 
>>
>> Indeed you can - and Jay does - and so do I. Especially now I'm using 
>> LightTable and can evaluate code in place in amongst my production code in 
>> one tabset and my expectations in another tabset. I have C-c , bound to 
>> evaluate a "run-tests" expression in my namespace so I can quickly evaluate 
>> and execute tests. Even so, live evaluation of "test code" is still a 
>> faster feedback loop. 
>>
>> Many of my test expressions become long-lived unit tests (expectations). 
>> Or they become production code. I still write expectations to clarify how 
>> to design APIs in the small (and APIs in the large as needed), but most of 
>> the red-green-refactor loop of TDD/BDD now comes from the REPL experiments 
>> for me. 
>>
>> Sean Corfield -- (904) 302-SEAN 
>> An Architect's View -- http://corfield.org/ 
>>
>> "Perfection is the enemy of the good." 
>> -- Gustave Flaubert, French realist novelist (1821-1880) 
>>
>>
>>
>>

-- 
 — gk

-- 
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/groups/opt_out.

Re: Why does Clojure at times use Java classes as their base type?

[Brian Craft]

On Sunday, February 2, 2014 3:07:27 PM UTC-8, Aaron France wrote:
>
> What's the benefit of hiding/abstracting the underlying platform away? 
>
>
The obvious answer to this is it limits exposure to the complexity of the 
underlying platform, and provides a stable platform. That's usually why 
people abstract platforms.

The trade-off of embracing the platform is that the complexity of using 
clojure is not just the complexity of clojure. It is the complexity of the 
jvm plus the complexity of java plus the complexity of clojure plus the 
complexity of the interface between clojure and java, which is intricate. 
Thus, you need to know that in java 6 you have to make defensive copies of 
substrings, but on java 7 you don't; that on some jvm you will have 
abstract path manipulation, on others you won't; that (map #(+ 1 %) 
(float-array [1 2 3])) will run but (map #(+ 1 %) (byte-array [1 2 3])) 
will throw an error, and so-on, in unending detail.

Probably the size of this looks different if you've already internalized 
the complexity of the platform from previous experience.

-- 
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/groups/opt_out.

how does source work?

[t x]

Hi,

user> (source source)
(defmacro source
  "Prints the source code for the given symbol, if it can find it.
  This requires that the symbol resolve to a Var defined in a
  namespace for which the .clj is in the classpath.

  Example: (source filter)"
  [n]
  `(println (or (source-fn '~n) (str "Source not found"
nil
user> (source source-fn)
Source not found
nil


Is there a way, from pure-clojure that I can implement my-def +
my-source (without using def+source) which behaves as def+source does
... or does doing so require writing Java code?

Thanks!

-- 
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/groups/opt_out.

How to transform one data structure to another data structure?

[Thomas]

Hi all,

I was wondering how I can convert the following data structure to the one 
below:

from:

[[:a 123]
 [:b 124]
 [:a 125]
 [:c 126]
 [:b 127]
 [:a 100]]

to

{:a [123 125 100] :b [124 127] :c [126]}

All the names here are arbitrary, but there are potentially a lot more keys 
and certainly a lot more numbers. The order of things is not important.

TIA,
Thomas

-- 
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/groups/opt_out.

Re: how does source work?

[Michał Marczyk]

source-fn is a private Var in the clojure.repl namespace; you can
still use source to display its definition, but you'll have to use the
fully qualified name:

user=> (source clojure.repl/source-fn)
(defn source-fn
  "Returns a string of the source code for the given symbol, if it can
  find it.  This requires that the symbol resolve to a Var defined in
  a namespace for which the .clj is in the classpath.  Returns nil if
  it can't find the source.  For most REPL usage, 'source' is more
  convenient.

  Example: (source-fn 'filter)"
  [x]
  (when-let [v (resolve x)]
(when-let [filepath (:file (meta v))]
  (when-let [strm (.getResourceAsStream (RT/baseLoader) filepath)]
(with-open [rdr (LineNumberReader. (InputStreamReader. strm))]
  (dotimes [_ (dec (:line (meta v)))] (.readLine rdr))
  (let [text (StringBuilder.)
pbr (proxy [PushbackReader] [rdr]
  (read [] (let [i (proxy-super read)]
 (.append text (char i))
 i)))]
(read (PushbackReader. pbr))
(str text)))

Cheers,
Michał


On 4 February 2014 21:34, t x  wrote:
> Hi,
>
> user> (source source)
> (defmacro source
>   "Prints the source code for the given symbol, if it can find it.
>   This requires that the symbol resolve to a Var defined in a
>   namespace for which the .clj is in the classpath.
>
>   Example: (source filter)"
>   [n]
>   `(println (or (source-fn '~n) (str "Source not found"
> nil
> user> (source source-fn)
> Source not found
> nil
>
>
> Is there a way, from pure-clojure that I can implement my-def +
> my-source (without using def+source) which behaves as def+source does
> ... or does doing so require writing Java code?
>
> Thanks!
>
> --
> 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/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/groups/opt_out.

Re: How to transform one data structure to another data structure?

[Sean Grove]

One way:

user> (reduce (fn [s [k v]]
(merge-with concat s {k [v]}))
  {} [[:a 123]
  [:b 124]
  [:a 125]
  [:c 126]
  [:b 127]
  [:a 100]])

=> {:c [126], :b (124 127), :a (123 125 100)}


On Tue, Feb 4, 2014 at 1:06 PM, Thomas  wrote:

> Hi all,
>
> I was wondering how I can convert the following data structure to the one
> below:
>
> from:
>
> [[:a 123]
>  [:b 124]
>  [:a 125]
>  [:c 126]
>  [:b 127]
>  [:a 100]]
>
> to
>
> {:a [123 125 100] :b [124 127] :c [126]}
>
> All the names here are arbitrary, but there are potentially a lot more
> keys and certainly a lot more numbers. The order of things is not important.
>
> TIA,
> Thomas
>
> --
> 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/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/groups/opt_out.

Re: How to transform one data structure to another data structure?

[rrs]

You can start here http://clojuredocs.org/clojure_core/clojure.core/group-by
 
it should be pretty easy to get it working from there.

On Tuesday, February 4, 2014 4:06:14 PM UTC-5, Thomas wrote:
>
> Hi all,
>
> I was wondering how I can convert the following data structure to the one 
> below:
>
> from:
>
> [[:a 123]
>  [:b 124]
>  [:a 125]
>  [:c 126]
>  [:b 127]
>  [:a 100]]
>
> to
>
> {:a [123 125 100] :b [124 127] :c [126]}
>
> All the names here are arbitrary, but there are potentially a lot more 
> keys and certainly a lot more numbers. The order of things is not important.
>
> TIA,
> Thomas
>

-- 
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/groups/opt_out.

LightTable (for the Emacs guy) was: Lessons Learned from Adopting Clojure

[Sean Corfield]

On Feb 4, 2014, at 10:21 AM, Colin Yates  wrote:
> Without starting a flame war - how are you finding LightTable for production? 
>  Moving away from emacs and paredit would be quite hard and every time I look 
> at LightTable I get really excited until I actually download and try it...  
> That is almost certainly because I don't have the time to invest in learning 
> it and I expect it to do everything out of the box immediately and just the 
> way I like it :)

Like Emacs, it has its quirks(!) and it takes some adjustment after two years 
of using Emacs daily (and several years using Emacs twenty years back!).

I use the Emacs plugin, the Emacs mode (from the underlying CodeMirror editor), 
and the Paredit plugin. Plus some custom key mappings. It's not perfect but I'm 
getting used to the differences. Being able to customize it via Clojure 
(technically ClojureScript data structures) is a plus and a minus and whilst 
I've written one plugin, I based it heavily on someone else's so I haven't yet 
learned much about the LT internals... but the customization capabilities are 
VERY impressive.

At the moment, the biggest lack for me is something like magit but some folks 
are working on Git plugins so think that's just a short-term lack.

I really like LT's eval-in-place approach now I've gotten used to it - it's 
like having a REPL that's a 2D sketchpad rather than a linear sequence of 
evaluation "commands". I like that I can just try a bit of code out in the 
middle of my existing function definitions without having to switch to a REPL, 
so I'm finding I'm "growing" code directly inside my namespaces and then just 
wrapping each piece in defn and naming it once it does what I want, all on one 
"canvas".

I really like having a full-featured browser in my editor (that works 
cross-platform) and can act as a live evaluation target for .cljs and .js files 
(and .css and .html and so on).

I still keep Emacs open as my Git "client" and as my IRC client, but I don't 
edit anything with it.

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

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: LightTable (for the Emacs guy) was: Lessons Learned from Adopting Clojure

[Norman Richards]

On Tue, Feb 4, 2014 at 5:20 PM, Sean Corfield  wrote:

> On Feb 4, 2014, at 10:21 AM, Colin Yates  wrote:
> > Without starting a flame war - how are you finding LightTable for
> production?  Moving away from emacs and paredit would be quite hard and
> every time I look at LightTable I get really excited until I actually
> download and try it...  That is almost certainly because I don't have the
> time to invest in learning it and I expect it to do everything out of the
> box immediately and just the way I like it :)
>
> Like Emacs, it has its quirks(!) and it takes some adjustment after two
> years of using Emacs daily (and several years using Emacs twenty years
> back!).
>


I'll provide a counterpoint to that.  Let me preface by saying I do not
hate Light Table.  I supported the kickstarter, and I continue to follow
the development as one of the best hopes for future Clojure development.  I
am now using Light Table for Clojurescript development on our
not-small-but-not-massive Clojure/Clojurescript UI at Threatgrid.  I find
the live browser REPL interaction to be invaluable and finally makes me
willing to invest more into the Clojurescript UI.  Up until now I've found
the Clojurescript REPL support to be lacking.  Austin is promising, but
I've still yet to find anyone who can demonstrate it functioning correctly
in a non-demo environment.  Light Table works for this, and it works quite
well.

That being said, Light Table is barely usable as text editor and is a
really terrible editor for Clojure in specific.  I hope (and believe) this
will improve over time.  The token paredit barf/slurp shows some attention
to details, and work is ongoing for an extended paredit mode.  But, I find
that I spend a troubling large portion of my time in Light Table wrangling
parenthesis and fighting the editor compared to the time I spend actually
writing code.  The exact opposite is true in emacs. I spend almost no
mental effort on the syntax/structure.  When I want to move an expression
around or make a structural change, I can effect that change almost
trivially with no distraction from the coding task at hand.  Obvious,
there's a lot of practice and experience goes into that, but it's only
because emacs has those capabilities in the first place.

While every developer is different, I have a hard time imaging any
emacs/paredit user would find editing in Light Table a pleasurable
experience, so far as the act of writing the code is concerned.  There are
many, many reasons to like Light Table and to use Light Table for now, but
for day to day Clojure development, it's not even close to being ready for
serious use. (only my opinion)  Still, everyone should give it a try, if
you approach it from the perspective of being a tool that might be able to
provide some unique value in certain situations, I don't think you'll be
disappointed.

-- 
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/groups/opt_out.

[ANN] hiccup-watch

[Timothy Washington]

*hiccup-watch * is just a
leiningen watcher plugin that monitors for changes in your Hiccup source
files.

While building some web apps, I found that I like to treat my
*hiccup.edn*forms as separate files. So this is akin to something like
guard-haml  (or
guard-sass).
Ie, I like to serve up just raw HTML files and templates. So I needed a
tool like this. And hiccup-watch fits nicely, into my workflow. This is
still a new project, so feel free modify, make pull requests, etc.

   - [hiccup-watch "0.1.1"]
   - Github 
   - Clojars 


Tim Washington
Interruptsoftware.com 

-- 
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/groups/opt_out.

Re: GSoC 2014: org applications now open

[Daniel Solano Gómez]

Thanks, Alex and Ambrose,

I really appreciate the help.

On Tue Feb  4 05:41 2014, Alex Miller wrote:
> Daniel, I'd be happy to help as an administrator, particularly if you can 
> provide some guidance from previous years. I can also help re getting 
> students to conferences.

This would be a big help.  To get started as an admin, the first step is
to go to Melage  and sign in with a
Google account.  Once you've done that, you'll need to create a profile.
I need the username of at least one other person so that I can open our
application.

I'll be making edits to the community wiki soon, and as soon as its
ready, I'll post a message to the mailing lists letting people know it's
time to populate the project ideas page and review our answers for the
org application.

Thanks again.

Sincerely,

Daniel

-- 
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/groups/opt_out.

Re: how does source work?

[t x]

Issue resolved. Thanks!

On Tue, Feb 4, 2014 at 1:09 PM, Michał Marczyk  wrote:
> source-fn is a private Var in the clojure.repl namespace; you can
> still use source to display its definition, but you'll have to use the
> fully qualified name:
>
> user=> (source clojure.repl/source-fn)
> (defn source-fn
>   "Returns a string of the source code for the given symbol, if it can
>   find it.  This requires that the symbol resolve to a Var defined in
>   a namespace for which the .clj is in the classpath.  Returns nil if
>   it can't find the source.  For most REPL usage, 'source' is more
>   convenient.
>
>   Example: (source-fn 'filter)"
>   [x]
>   (when-let [v (resolve x)]
> (when-let [filepath (:file (meta v))]
>   (when-let [strm (.getResourceAsStream (RT/baseLoader) filepath)]
> (with-open [rdr (LineNumberReader. (InputStreamReader. strm))]
>   (dotimes [_ (dec (:line (meta v)))] (.readLine rdr))
>   (let [text (StringBuilder.)
> pbr (proxy [PushbackReader] [rdr]
>   (read [] (let [i (proxy-super read)]
>  (.append text (char i))
>  i)))]
> (read (PushbackReader. pbr))
> (str text)))
>
> Cheers,
> Michał
>
>
> On 4 February 2014 21:34, t x  wrote:
>> Hi,
>>
>> user> (source source)
>> (defmacro source
>>   "Prints the source code for the given symbol, if it can find it.
>>   This requires that the symbol resolve to a Var defined in a
>>   namespace for which the .clj is in the classpath.
>>
>>   Example: (source filter)"
>>   [n]
>>   `(println (or (source-fn '~n) (str "Source not found"
>> nil
>> user> (source source-fn)
>> Source not found
>> nil
>>
>>
>> Is there a way, from pure-clojure that I can implement my-def +
>> my-source (without using def+source) which behaves as def+source does
>> ... or does doing so require writing Java code?
>>
>> Thanks!
>>
>> --
>> 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/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/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/groups/opt_out.

Re: Coverage tools in Clojure

[Brian Marick]

On Feb 4, 2014, at 11:20 AM, Aaron France  wrote:

>> If you thoroughly test all your code when you write it why do you need a 
>> tool to tell you you missed something?
> 
> This is just so brain-dead stupid.
> 
> How do you *know* that you thoroughly tested your code? Where do you
> get these metrics? There are various methods you need to employ before
> you can even beging to feel comfortable about saying you have
> 'thoroughly' tested code. Coverage is one method amongst many.

If you practice test-driven design in its strict form, it's relatively easy to 
show that you'll get 100% multicondition coverage (which is a bit stronger than 
branch coverage). 

In practice, you don't really achieve that because (1) humans err, and (2) it's 
fairly easy to degrade the coverage of a test suite as you evolve the system.

Nevertheless, reasonably disciplined testing gets high enough coverage that I 
consider missing coverage a third-order problem. The first order problem is 
faults of omission, which coverage doesn't speak to at all. 
(http://www.exampler.com/testing-com/writings/omissions.html)

In my own coding practice, it's not common that I later find a bug that a 
coverage tool would have forced me to find. I wouldn't mind having a Clojure 
code coverage tool, but not having one isn't much of a problem.

> 
> At this point I'm beginning to suspect you've never really used a
> coverage tool properly. 

I don't know about Colin, but I've written or supervised the writing of four 
coverage tools (3 for C, 1 for Java). That in itself doesn't show that I've 
used them properly, but a number of people have appreciated my writings on 
coverage. Such as: 

http://www.exampler.com/testing-com/writings/coverage.pdf
http://www.exampler.com/testing-com/writings/experience.pdf


Latest book: /Functional Programming for the Object-Oriented Programmer/
https://leanpub.com/fp-oo

-- 
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/groups/opt_out.

[ANN] garden-watch

[Timothy Washington]

*garden-watch*  is very similar
to hiccup-watch  (previous
ann).
But this time, we're compiling down to CSS, using the
Gardenlibrary. Again, this is just
a leiningen watcher plugin that monitors for
changes in your Garden source files.

And again, this is new software. So feel free to use, modify and make
suggestions and / or pull requests. Treat this tool the same way you would
treat guard-sass . I like to serve up
just raw HTML files and templates. So both these tools fit nicely into my
toolbox.

   - [garden-watch "0.1.1"]
   - Github 
   - Clojars 


Tim Washington
Interruptsoftware.com 

-- 
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/groups/opt_out.

Re: Lessons Learned from Adopting Clojure

[Brian Marick]

On Feb 4, 2014, at 6:06 AM, Jay Fields  wrote:

> - REPL driven development, putting TDD's 'rapid feedback' to shame.

Pity I'll miss this, but I only come up to Chicago W-F. 

What I've found is that having autotest in the REPL dissolves most conflict 
between TDD and REPL-driven development. Or to put it differently: having a 
REPL autotest makes writing a test less hassle than working in the repl - maybe 
80% of the time. In the other 20%, the REPL is invaluable, though I always 
grate at the need to then "immortalize" the core of what I did in the REPL in 
repeatable tests.

(Actually, making clear distinctions like "80% doing this vs 20% doing that" 
feels like a poor reflection of my lived experience. I spend my time with four 
emacs windows open: a repl, the source, the tests of the source, and the 
miscellaneous window. I move very fluidly between them. Whatever 
source-of-immediate-gratification works best in the moment is always 
ready-to-hand.)


Latest book: /Functional Programming for the Object-Oriented Programmer/
https://leanpub.com/fp-oo

-- 
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/groups/opt_out.

Code re-use in Speclj

[david]

"context" might be what you're looking for.

-- 
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/groups/opt_out.

Code re-use in Speclj

[david]

You can also use let instead of with.  If you have multiple tests inside let 
wrap them in a context call.

-- 
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/groups/opt_out.

ANN: [lein-describe 0.1.0] plugin for displaying detailed information about Clojure projects

[david]

Looks cool. I'll be sure to check it 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/groups/opt_out.

Re: Coverage tools in Clojure

[Daniel]

This is a very specific "coverage" tool which I think lots of Clojure libraries 
could benefit from. https://github.com/ztellman/collection-check

-- 
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/groups/opt_out.

Re: Lessons Learned from Adopting Clojure

[Sean Corfield]

On Tue, Feb 4, 2014 at 6:07 PM, Brian Marick  wrote:
> I always grate at the need to then "immortalize" the core of what I did in 
> the REPL in repeatable tests.

That's actually one of the things that bothered me in the Emacs REPL
world: working in the REPL was separate from working in my production
source and my test source. It's one of the things that has me really
hooked on LightTable. I have my source and test namespaces both open.
I have them both connected to a "REPL". I can evaluate any code, in
place, in either file. If I grow some code in the source file, I can
put (defn some-name [args]) in front of it and M-) slurps it into a
function - done! If I grow some code in the test file, I can put
(expect result-value) in front of it and M-) slurps it into a test -
done!

Since I moved to LightTable, I've found myself doing even more
REPL-Driven-Development than before because it's so much easier to
turn the experiments into code - or tests - in place.
-- 
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/groups/opt_out.

Re: [ANN] garden-watch

[Dave Sann]

FYI, I think lein garden does this already. is there a particular 
difference?

On Wednesday, 5 February 2014 13:03:55 UTC+11, frye wrote:
>
> *garden-watch*  is very similar 
> to hiccup-watch  (previous 
> ann). 
> But this time, we're compiling down to CSS, using the 
> Gardenlibrary. Again, this is just a 
> leiningen watcher plugin that monitors for 
> changes in your Garden source files. 
>
> And again, this is new software. So feel free to use, modify and make 
> suggestions and / or pull requests. Treat this tool the same way you would 
> treat guard-sass . I like to serve up 
> just raw HTML files and templates. So both these tools fit nicely into my 
> toolbox.
>
>- [garden-watch "0.1.1"]
>- Github  
>- Clojars 
>
>
> Tim Washington 
> Interruptsoftware.com 
>  

-- 
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/groups/opt_out.

Re: ANN: Reagent 0.3.0 - now with async rendering

[Henrik Eneroth]

Cheers, Dan!


I'm doing experiments with both Reagent and Om at the moment, and I'm very 
excited about this way of rendering changes to a webpage. I particularly 
enjoy how easy it is to work with Reagent's API, and appreciate the time 
you are putting into this project. 

One of the major wins is how explicit I can be with where I put state. My 
current experimental design puts state squarely in two places only: an atom 
in the client, and the database (Datomic, for the time being). The server 
essentially behaves like a pure function only. I don't have time to 
enumerate all the benefits of this design as opposed to the mess I usually 
encounter, where state is stored absolutely everywhere.



On Monday, February 3, 2014 3:24:25 PM UTC+1, Dan Holmsand wrote:
>
> Reagent, a minimalistic interface between React.js and ClojureScript, is 
> now at 0.3.0. 
>
> The new release adds a couple of bugfixes, and async rendering. Read more 
> here: 
>
> http://holmsand.github.io/reagent/news/reagent-is-async.html 
>
> The project page is here: 
>
> https://github.com/holmsand/reagent 
>
> Cheers, 
>
> /dan 
>
>

-- 
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/groups/opt_out.

Caribou: Unable to create a model that has a self reference!

[David Baldin]

Hey!

i hope this is the right place to ask this question! Here it goes: I want 
to create a simple model with cariou that references itself to generate a 
tree-structure. Like this:

(defn category []
(model/create :model {:name "category" 
:fields [{:name "Label" :type "string"}
 {:name "related-categories" :type "link"
   :target-id (model/models :category :id)
   :reciprocal-name 
"relating-categories"}]}))

This results in a:

DEBUG :db insert into field values dependent = false, slug = 
'relating-categories', position = 201, map = false, localized = false, name 
= 'relating-categories', locked = false, model-id = '', target-id = 22, 
uuid = '13776b59-7359-4412-850f-ffaa619665e0', type = 'link', updated-at = 
'2014-02-04 09:53:48.578', model-position = 201, link-id = 380, 
status-position = 139
Exception in thread "main" org.h2.jdbc.JdbcSQLException: NULL not allowed 
for column "MODEL_ID"; SQL statement:
INSERT INTO field 
(dependent,slug,position,map,localized,name,locked,model_id,target_id,uuid,type,updated_at,model_position,link_id,status_position)
 
VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) [23502-170]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
at org.h2.message.DbException.get(DbException.java:169)
at org.h2.message.DbException.get(DbException.java:146)
at org.h2.table.Column.validateConvertUpdateSequence(Column.java:293)...

Because the category to be reference is not yet available. Is there a way 
to create a model and afterwards update it with constraints (Like you would 
do in SQL)!?

Btw. naturally the other way around will dont work either:

(defn category []
(model/create :model {:name "category" 
:fields [{:name "Label" :type "string"}
 {:name "keywords" :type "string"}
 {:name "parent-category" :type "part"
   :target-id (model/models :category :id)
   :reciprocal-name "child-categories"}]}))

And the bidirectional (or in caribou-speech: "reciprocal") also not: 

(defn category []
(model/create :model {:name "category" 
:fields [{:name "Label" :type "string"}
 {:name "keywords" :type "string"}
 {:name "parent-category" :type "link"
   :target-id (model/models :category 
:id)}]}))

Any hints? Btw. Caribou is really pragmatic, fast and clean, love it! 
NoSQL/Riak support would awesome too!

Thanks and regards,
David

-- 
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/groups/opt_out.

Re: Caribou: Unable to create a model that has a self reference!

[David Baldin]

... one step closer:

(defn category []
  ((model/create :model {:name "category" 
   :fields [{:name "Label" :type "string"}
{:name "keywords" :type "string"}
{:name "parent-id" :type "integer"}]})
(db/add-reference :field :parent-id :category :destroy)))

now i have to touch the model-table somehow.

Am Dienstag, 4. Februar 2014 10:11:06 UTC+1 schrieb David Baldin:
>
> Hey!
>
> i hope this is the right place to ask this question! Here it goes: I want 
> to create a simple model with cariou that references itself to generate a 
> tree-structure. Like this:
>
> (defn category []
> (model/create :model {:name "category" 
> :fields [{:name "Label" :type "string"}
>  {:name "related-categories" :type "link"
>:target-id (model/models :category :id)
>:reciprocal-name 
> "relating-categories"}]}))
>
> This results in a:
>
> DEBUG :db insert into field values dependent = false, slug = 
> 'relating-categories', position = 201, map = false, localized = false, name 
> = 'relating-categories', locked = false, model-id = '', target-id = 22, 
> uuid = '13776b59-7359-4412-850f-ffaa619665e0', type = 'link', updated-at = 
> '2014-02-04 09:53:48.578', model-position = 201, link-id = 380, 
> status-position = 139
> Exception in thread "main" org.h2.jdbc.JdbcSQLException: NULL not allowed 
> for column "MODEL_ID"; SQL statement:
> INSERT INTO field 
> (dependent,slug,position,map,localized,name,locked,model_id,target_id,uuid,type,updated_at,model_position,link_id,status_position)
>  
> VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) [23502-170]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
> at org.h2.message.DbException.get(DbException.java:169)
> at org.h2.message.DbException.get(DbException.java:146)
> at org.h2.table.Column.validateConvertUpdateSequence(Column.java:293)...
>
> Because the category to be reference is not yet available. Is there a way 
> to create a model and afterwards update it with constraints (Like you would 
> do in SQL)!?
>
> Btw. naturally the other way around will dont work either:
>
> (defn category []
> (model/create :model {:name "category" 
> :fields [{:name "Label" :type "string"}
>  {:name "keywords" :type "string"}
>  {:name "parent-category" :type "part"
>:target-id (model/models :category :id)
>:reciprocal-name "child-categories"}]}))
>
> And the bidirectional (or in caribou-speech: "reciprocal") also not: 
>
> (defn category []
> (model/create :model {:name "category" 
> :fields [{:name "Label" :type "string"}
>  {:name "keywords" :type "string"}
>  {:name "parent-category" :type "link"
>:target-id (model/models :category 
> :id)}]}))
>
> Any hints? Btw. Caribou is really pragmatic, fast and clean, love it! 
> NoSQL/Riak support would awesome too!
>
> Thanks and regards,
> David
>

-- 
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/groups/opt_out.

Re: Caribou: Unable to create a model that has a self reference!

[David Baldin]

Well, source-code is the best documentation:

(defn category []
  ((model/create :model {:name "category" 
   :fields [{:name "Label" :type "string"}]})
(let [category-model-id (model/models :category :id)]
  (model/update :model category-model-id {:name "category" 
  :fields [{:name "parent-category" 
:type "part" 
:target-id prod-model-id
:reciprocal-name 
"sub-categories"}]}

Documentation of caribou.model/create and caribou.model/update describes it 
all!

Have a nice day!

Am Dienstag, 4. Februar 2014 10:11:06 UTC+1 schrieb David Baldin:
>
> Hey!
>
> i hope this is the right place to ask this question! Here it goes: I want 
> to create a simple model with cariou that references itself to generate a 
> tree-structure. Like this:
>
> (defn category []
> (model/create :model {:name "category" 
> :fields [{:name "Label" :type "string"}
>  {:name "related-categories" :type "link"
>:target-id (model/models :category :id)
>:reciprocal-name 
> "relating-categories"}]}))
>
> This results in a:
>
> DEBUG :db insert into field values dependent = false, slug = 
> 'relating-categories', position = 201, map = false, localized = false, name 
> = 'relating-categories', locked = false, model-id = '', target-id = 22, 
> uuid = '13776b59-7359-4412-850f-ffaa619665e0', type = 'link', updated-at = 
> '2014-02-04 09:53:48.578', model-position = 201, link-id = 380, 
> status-position = 139
> Exception in thread "main" org.h2.jdbc.JdbcSQLException: NULL not allowed 
> for column "MODEL_ID"; SQL statement:
> INSERT INTO field 
> (dependent,slug,position,map,localized,name,locked,model_id,target_id,uuid,type,updated_at,model_position,link_id,status_position)
>  
> VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) [23502-170]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
> at org.h2.message.DbException.get(DbException.java:169)
> at org.h2.message.DbException.get(DbException.java:146)
> at org.h2.table.Column.validateConvertUpdateSequence(Column.java:293)...
>
> Because the category to be reference is not yet available. Is there a way 
> to create a model and afterwards update it with constraints (Like you would 
> do in SQL)!?
>
> Btw. naturally the other way around will dont work either:
>
> (defn category []
> (model/create :model {:name "category" 
> :fields [{:name "Label" :type "string"}
>  {:name "keywords" :type "string"}
>  {:name "parent-category" :type "part"
>:target-id (model/models :category :id)
>:reciprocal-name "child-categories"}]}))
>
> And the bidirectional (or in caribou-speech: "reciprocal") also not: 
>
> (defn category []
> (model/create :model {:name "category" 
> :fields [{:name "Label" :type "string"}
>  {:name "keywords" :type "string"}
>  {:name "parent-category" :type "link"
>:target-id (model/models :category 
> :id)}]}))
>
> Any hints? Btw. Caribou is really pragmatic, fast and clean, love it! 
> NoSQL/Riak support would awesome too!
>
> Thanks and regards,
> David
>

-- 
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/groups/opt_out.

Re: ANN: Reagent 0.3.0 - now with async rendering

[Robin Heggelund Hansen]

Gotta ask, what's the difference between Om and  Reagent?

-- 
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/groups/opt_out.

Re: ANN: Another binary parser combinator - this time for java's streams

[Stathis Sideris]

Thanks, header seems very useful and relevant to what I was doing, but I 
ended up doing something slightly different because I needed to include the 
information retrieved using the chunk header codec in the final result 
(specifically, the type of the chunk). Here is some code:

https://gist.github.com/stathissideris/8801295

select-codec is almost identical to header (didn't bother with writing in 
this case), but it also merges the result of the "decision-codec" with the 
result of the selected codec. Of course it's less generic than header 
because it makes the assumption that we're dealing with maps. Also, note 
the use of core.match to decide on what codec to use.

Stathis


On Monday, 3 February 2014 16:50:12 UTC, Steffen Dienst wrote:
>
> I would use header for this:
>
> (def chunk 
>   (header :int-be
>   #(ordered-map 
>   :type (b/repeated :byte :length 4)
>   :data (b/repeated :byte :length %)
>   :crc (b/repeated :byte :length 4))
>   #(count (:data %
>
> The resulting data structure would not contain the field length in this 
> case. Length only gets used to configure the inner codec for the body (the 
> map with :type, :data and :crc). You can read this codec as: "Read a 
> big-endian integer, then use this value to construct a new codec to read 
> the body. When writing, count the :data field, write the length using :type 
> and then write the body".
>
> Steffen
>
>
> 2014-02-03 Stathis Sideris >:
>
>> Hello,
>>
>> Is it possible to use 'repeated with a dynamic size if the 
>> length-defining prefix does not directly precede the content? For example, 
>> see PNG chunks:
>>
>>
>> http://en.wikipedia.org/wiki/Portable_Network_Graphics#.22Chunks.22_within_the_file
>>
>> The codec would be:
>>
>> (def chunk
>>   (b/ordered-map
>>:length :int-be
>>:type (b/repeated :byte :length 4)
>>:data (b/repeated :byte :length ???)
>>:crc (b/repeated :byte :length 4)))
>>
>> What do I put in the place of "???"
>>
>> Thanks,
>>
>> Stathis
>>
>>
>> On Friday, 31 January 2014 08:12:23 UTC, Steffen Dienst wrote:
>>>
>>> Thanks, I fixed the documentation issues. Feel free to share your id3 
>>> tags parser, if you like :) You can see that mine is still stuck at the 
>>> very beginning..
>>>
>>>
>>>  -- 
>> 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 a topic in the 
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/clojure/2c9-oXfKlp0/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> clojure+u...@googlegroups.com .
>> 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/groups/opt_out.

Re: Why do I get stackoverflow error?

[Andy Smith]

Ok thanks, thats really helpful. The second link suggests using doall, 
which seems to do the trick :

((fn pascal ([n] (pascal n [1M])) ([n row] (if (= n 1) row (recur (dec n) 
(map (partial reduce +) (doall (partition 2 1 (concat [0] row [0] 
500)

However you do lose the laziness, but here the laziness is not needed ...

-- 
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/groups/opt_out.

Re: Why do I get stackoverflow error?

[Andy Smith]

Similarly this works for my non-recursive effort, which I think is more 
concise :

(fn [n] (nth (iterate (fn [r] (map (partial reduce +) (doall (partition 2 1 
(concat [0N] r [0]) [1]) (dec n)))

-- 
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/groups/opt_out.

Re: How to organize clojure functions? A clojure newbie here...

[Colin Yates]

I think the "right" (or maybe idiomatic is a better word) organisation is 
an effect of a very important cause - changing the way you think about a 
software system.  Simplistically, OO promises to be a world full of chunks 
of knowledge and behaviour that politely ask other chunks to behave in a 
certain way.  You have relatively narrow but very deep 'shapes' as levels 
of abstraction increase.  Realistically we all know how that goes :).  

In FP the form the structure of the knowledge itself is your primary chunk 
with a many little chunks of functionality that all know how to transform 
one shape to another.  You have a relatively wide and shallow 'shapes' that 
all work on a few core chunks of knowledge (i.e. state).  To put it another 
way, I find it really helpful in Clojure to phrase the question 'what shape 
data do I need and which transformations are necessary'.  It isn't quite on 
its head, but close.  You can absolutely still address encapsulation, 
domain abstractions etc. 
(http://thinkrelevance.com/blog/2009/08/12/rifle-oriented-programming-with-clojure-2)
 
but start with the shapes of knowledge.

All of the above is incredibly simplistic, 'wrong' for some definition of 
wrong but it is something I wish somebody had told me when I was first 
starting out :).

On Monday, 3 February 2014 08:47:09 UTC, Aravindh S wrote:
>
> Hi All,
> I am new to clojure and have been working with the language for the 
> past one week. I have got a basic hold of the constructs in clojure. I have 
> been programming for 4 years in C# now. One thing I am not able to 
> comprehend is how clojure programs are structured. In an OO world, I know 
> what are the entities that the program should have, how they will be 
> related etc. I am not able to do the same wit clojure. I agree that words 
> like classes, methods dont make much sense in functional programming. I am 
> precisely looking for a program written in clojure ( A medium level program 
> say about 200 - 300 LOC) which clearly tells how a problem domain should be 
> approached in a functional manner using clojure, how the functions should 
> be organized. A specific solution for specific problem will be helpful.
>
>
> Thanks
> Aravindh.S
>

-- 
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/groups/opt_out.

Re: Coverage tools in Clojure

[Colin Yates]

I don't know.

But maybe the lack of coverage tools is itself interesting?  My (not quite 
formed/making this up as I go) view is that maybe coverage tools are there 
to address the implicit complexity in other mainstream languages and/or to 
help mitigate the risk of the potentially large and hard-to-identify 
'impact analysis' you get in OO systems when you change state.  In other 
words, coverage is necessary because we want to feel safe that all 
combinations of our code are extensively tested.  Why don't we feel safe? 
 Because the system is hard to reason about.

Functional programming on the other hand is full of much smaller discrete 
and independent chunks of functionality.  Ideally these small focused 
'bricks' are pure/referentially transparent so the *only* context you need 
when reasoning about them is their parameters and the logic inside. 
 Assembling these bricks introduces interactions that need to be tested, 
sure, but there are very few 'call this and watch the change cascade'/'this 
code is sensitive (i.e. coupled) to that data over there'.

My ramblings are to say, maybe the root cause of coverage tools is to solve 
a problem (hard to reason about systems) which shouldn't be much less of a 
problem in FP when FP is done right.  OO + mutable state = hard to reason 
about.  FP + immutable state + pure/referentially transparent functions = 
much easier to reason about.

Or not.  Just my 2 pence :).

On Sunday, 2 February 2014 21:34:29 UTC, Aaron France wrote:
>
> Hi, 
>
> I'm looking for coverage reporting in Clojure. I've been using 
> Cloverage[1] but I'm just wondering if there are any other coverage 
> tools? 
>
> Aaron 
>
>
> [1] https://github.com/lshift/cloverage 
>

-- 
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/groups/opt_out.

Re: Coverage tools in Clojure

[Aaron France]

I don't want to seem rude but I think you've drank a bit too much
kool-aid.

To say that functional programming and war against state means that
your application doesn't need to be tested thoroughly is a joke. And a
very bad one.

Coverage doesn't just aid you in seeing which parts of state caused
which branches to be hit, it also gives you notice if there are any
logical errors in your code which cause the branches to not be hit.

Aaron

On Tue, Feb 04, 2014 at 03:19:05AM -0800, Colin Yates wrote:
> I don't know.
> 
> But maybe the lack of coverage tools is itself interesting?  My (not quite 
> formed/making this up as I go) view is that maybe coverage tools are there 
> to address the implicit complexity in other mainstream languages and/or to 
> help mitigate the risk of the potentially large and hard-to-identify 
> 'impact analysis' you get in OO systems when you change state.  In other 
> words, coverage is necessary because we want to feel safe that all 
> combinations of our code are extensively tested.  Why don't we feel safe? 
>  Because the system is hard to reason about.
> 
> Functional programming on the other hand is full of much smaller discrete 
> and independent chunks of functionality.  Ideally these small focused 
> 'bricks' are pure/referentially transparent so the *only* context you need 
> when reasoning about them is their parameters and the logic inside. 
>  Assembling these bricks introduces interactions that need to be tested, 
> sure, but there are very few 'call this and watch the change cascade'/'this 
> code is sensitive (i.e. coupled) to that data over there'.
> 
> My ramblings are to say, maybe the root cause of coverage tools is to solve 
> a problem (hard to reason about systems) which shouldn't be much less of a 
> problem in FP when FP is done right.  OO + mutable state = hard to reason 
> about.  FP + immutable state + pure/referentially transparent functions = 
> much easier to reason about.
> 
> Or not.  Just my 2 pence :).
> 
> On Sunday, 2 February 2014 21:34:29 UTC, Aaron France wrote:
> >
> > Hi, 
> >
> > I'm looking for coverage reporting in Clojure. I've been using 
> > Cloverage[1] but I'm just wondering if there are any other coverage 
> > tools? 
> >
> > Aaron 
> >
> >
> > [1] https://github.com/lshift/cloverage 
> >
> 
> -- 
> 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/groups/opt_out.


pgpVKilgv_syW.pgp
Description: PGP signature

Re: [ClojureScript] ANN: Reagent 0.3.0 - now with async rendering

[Dan Holmsand]

Thanks, I enjoy writing it!

ClojureScript is such a delight to use (except, of course, when Closure's 
advanced compilation bites you where it hurts). :)

/dan

On 4 feb 2014, at 09:09, Henrik Eneroth  wrote:

> Cheers, Dan!
> 
> 
> I'm doing experiments with both Reagent and Om at the moment, and I'm very 
> excited about this way of rendering changes to a webpage. I particularly 
> enjoy how easy it is to work with Reagent's API, and appreciate the time you 
> are putting into this project. 
> 
> One of the major wins is how explicit I can be with where I put state. My 
> current experimental design puts state squarely in two places only: an atom 
> in the client, and the database (Datomic, for the time being). The server 
> essentially behaves like a pure function only. I don't have time to enumerate 
> all the benefits of this design as opposed to the mess I usually encounter, 
> where state is stored absolutely everywhere.
> 
> 
> 
> On Monday, February 3, 2014 3:24:25 PM UTC+1, Dan Holmsand wrote:
> Reagent, a minimalistic interface between React.js and ClojureScript, is now 
> at 0.3.0. 
> 
> The new release adds a couple of bugfixes, and async rendering. Read more 
> here: 
> 
> http://holmsand.github.io/reagent/news/reagent-is-async.html 
> 
> The project page is here: 
> 
> https://github.com/holmsand/reagent 
> 
> Cheers, 
> 
> /dan 
> 
> 
> -- 
> Note that posts from new members are moderated - please be patient with your 
> first post.
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "ClojureScript" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojurescript/tWHJg7xcnbg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.

-- 
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/groups/opt_out.

Lessons Learned from Adopting Clojure

[Jay Fields]

tl; dr: I'm presenting "Lessons Learned from Adopting Clojure" in
Chicago on Feb 11th:
http://www.eventbrite.com/e/goto-night-with-jay-fields-tickets-10366768283?aff=eorgf

Five years ago DRW Trading was primarily a Java shop, and I was
primarily developing in Ruby. Needless to say, it wasn't a match made
in heaven. Fast forward five years, Clojure is the second most used
language in the firm, and the primary language for several teams
(including mine). Clojure wasn't the first language that I've
introduced to an organization; however, it's unquestionably the most
successful adoption I've ever been a part of. The use of Clojure has
had many impacts on the firm: culturally, politically, and
technically. My talk will discuss general ideas around language
selection and maintenance trade-offs, and specific examples of what
aspects of Clojure made it the correct choice for us.

A few highlights

- Where to first introduce a new language and your role as the
language care-taker.
- REPL driven development, putting TDD's 'rapid feedback' to shame.
- Operations impact of adding a language - i.e. get ready for some DevOps.
- Functional programming, the Lisp Advantage, and their impact on
maintainability.

Of course, no good experience report is all roses. The adoption has
seen several hurdles along the way, and I'll happily to describe those
as well.

-- 
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/groups/opt_out.