librelist archives

« back to archive

Project for the group

Project for the group

From:
Andrew Wagner
Date:
2013-05-18 @ 01:15
All,
I have an idea for a project the group could work on after finishing the
book. This is something that I've been pondering for a while, but don't
feel like I could make much headway on my own.

The idea is a question-answering system. You feed it text, it converts that
text into a series of facts, about which you can then ask it questions. I
can imagine a number of uses for such a capability, and clojure seems like
a good fit for it.

Thoughts?

Re: [foray] Project for the group

From:
Nico Balestra
Date:
2013-05-18 @ 07:46
Hi Andrew,
Thank you for sharing your idea with us. Just wondering... Why waiting
until we finish reading the book?  I think if we find a way to stay engaged
while reading the book it could be a great way to keep the interest alive
and participate actively in this group.
After all,  if we do things in a non idiomatic way we can still refactor
later... and refactoring Clojure code is so much easy than refactoring Java
one :)

I hope you agree :)

Nico,
From BST
On 18 May 2013 02:15, "Andrew Wagner" <wagner.andrew@gmail.com> wrote:

> All,
> I have an idea for a project the group could work on after finishing the
> book. This is something that I've been pondering for a while, but don't
> feel like I could make much headway on my own.
>
> The idea is a question-answering system. You feed it text, it converts
> that text into a series of facts, about which you can then ask it
> questions. I can imagine a number of uses for such a capability, and
> clojure seems like a good fit for it.
>
> Thoughts?
>

Re: [foray] Project for the group

From:
i-blis
Date:
2013-05-18 @ 10:03
Nice idea.

What do you have in mind for the processing? core.logic 
(https://github.com/clojure/core.logic) (for generating and querying 
facts)? Note that core.logic (kind of miniKaren) is really not easy to 
grasp.
 

How would you parse questions? With part-of-speech tokenization with, say,
OpenNLP (https://github.com/dakrone/clojure-opennlp) (link to the Clojure 
wrapper)?

The whole thing could be wrapped within a xmpp or ws bot. I tried making 
simple echo xmpp and ws bots, it was pretty straightforward (although I am
sure my Clojure code is awful).

And as Nico said, Clojure is probably easy to refactor. Another good thing
is that it seems to enforce building small blocks first. So one could 
start with those. And, yes, refactor later.

My two cents.

Greetings, i-blis. 


On Saturday, 18 May 2013 at 9:46, Nico Balestra wrote:

> Hi Andrew, 
> Thank you for sharing your idea with us. Just wondering... Why waiting 
until we finish reading the book? I think if we find a way to stay engaged
while reading the book it could be a great way to keep the interest alive 
and participate actively in this group.
> After all, if we do things in a non idiomatic way we can still refactor 
later... and refactoring Clojure code is so much easy than refactoring 
Java one :) 
> I hope you agree :)
> Nico, 
> > From BST 
> 
> On 18 May 2013 02:15, "Andrew Wagner" <wagner.andrew@gmail.com 
(mailto:wagner.andrew@gmail.com)> wrote:
> > All,
> > I have an idea for a project the group could work on after finishing 
the book. This is something that I've been pondering for a while, but 
don't feel like I could make much headway on my own.
> > 
> > The idea is a question-answering system. You feed it text, it converts
that text into a series of facts, about which you can then ask it 
questions. I can imagine a number of uses for such a capability, and 
clojure seems like a good fit for it. 
> > 
> > Thoughts? 

Re: [foray] Project for the group

From:
Andrew Wagner
Date:
2013-05-18 @ 11:20
For the data, core.logic is one thing I thought about. Another one I was
thinking of was datomic, for the scaling and querying properties. Whatever
we choose, this is one spot where I would want to try to have a layer of
abstraction, so that we can swap it out later. Another idea I had in this
area was to use the concept of provenance, as talked about by Sussman at
Strange Loop a couple years ago (
http://www.infoq.com/presentations/We-Really-Dont-Know-How-To-Compute).
That could be powerful.

In terms of parsing questions, yes, I think that OpenNLP could be useful.
One idea I had would be to have multiple algorithms processing the
question, and returning both an answer and a confidence. Along the lines of
the Watson program that played Jeopardy. Maybe with a blackboard
implementation for communication across threads.

For web access, I was thinking we might use the new Pedestal.io to build an
async service (possibly with a simpler, synchronous side, too). This would
give us the ability to hook up a number of different clients, including
your bot ideas, I think.


On Sat, May 18, 2013 at 6:03 AM, i-blis <i-blis@yandex.ru> wrote:

> Nice idea.
>
> What do you have in mind for the processing? core.logic (
> https://github.com/clojure/core.logic) (for generating and querying
> facts)? Note that core.logic (kind of miniKaren) is really not easy to
> grasp.
>
>
> How would you parse questions? With part-of-speech tokenization with, say,
> OpenNLP (https://github.com/dakrone/clojure-opennlp) (link to the Clojure
> wrapper)?
>
> The whole thing could be wrapped within a xmpp or ws bot. I tried making
> simple echo xmpp and ws bots, it was pretty straightforward (although I am
> sure my Clojure code is awful).
>
> And as Nico said, Clojure is probably easy to refactor. Another good thing
> is that it seems to enforce building small blocks first. So one could start
> with those. And, yes, refactor later.
>
> My two cents.
>
> Greetings, i-blis.
>
>
> On Saturday, 18 May 2013 at 9:46, Nico Balestra wrote:
>
> > Hi Andrew,
> > Thank you for sharing your idea with us. Just wondering... Why waiting
> until we finish reading the book? I think if we find a way to stay engaged
> while reading the book it could be a great way to keep the interest alive
> and participate actively in this group.
> > After all, if we do things in a non idiomatic way we can still refactor
> later... and refactoring Clojure code is so much easy than refactoring Java
> one :)
> > I hope you agree :)
> > Nico,
> > > From BST
> >
> > On 18 May 2013 02:15, "Andrew Wagner" <wagner.andrew@gmail.com (mailto:
> wagner.andrew@gmail.com)> wrote:
> > > All,
> > > I have an idea for a project the group could work on after finishing
> the book. This is something that I've been pondering for a while, but don't
> feel like I could make much headway on my own.
> > >
> > > The idea is a question-answering system. You feed it text, it converts
> that text into a series of facts, about which you can then ask it
> questions. I can imagine a number of uses for such a capability, and
> clojure seems like a good fit for it.
> > >
> > > Thoughts?
>
>
>

Re: [foray] Project for the group

From:
Ali Baitam
Date:
2013-05-18 @ 16:57
Andrew, i-blis,
How do you refactor Clojure code? is there a blog post on how to refactor
Clojure code you can point me to? Is there a tool you use or just paredit
in emacs?


On Sat, May 18, 2013 at 7:20 AM, Andrew Wagner <wagner.andrew@gmail.com>wrote:

> For the data, core.logic is one thing I thought about. Another one I was
> thinking of was datomic, for the scaling and querying properties. Whatever
> we choose, this is one spot where I would want to try to have a layer of
> abstraction, so that we can swap it out later. Another idea I had in this
> area was to use the concept of provenance, as talked about by Sussman at
> Strange Loop a couple years ago (
> http://www.infoq.com/presentations/We-Really-Dont-Know-How-To-Compute).
> That could be powerful.
>
> In terms of parsing questions, yes, I think that OpenNLP could be useful.
> One idea I had would be to have multiple algorithms processing the
> question, and returning both an answer and a confidence. Along the lines of
> the Watson program that played Jeopardy. Maybe with a blackboard
> implementation for communication across threads.
>
> For web access, I was thinking we might use the new Pedestal.io to build
> an async service (possibly with a simpler, synchronous side, too). This
> would give us the ability to hook up a number of different clients,
> including your bot ideas, I think.
>
>
> On Sat, May 18, 2013 at 6:03 AM, i-blis <i-blis@yandex.ru> wrote:
>
>> Nice idea.
>>
>> What do you have in mind for the processing? core.logic (
>> https://github.com/clojure/core.logic) (for generating and querying
>> facts)? Note that core.logic (kind of miniKaren) is really not easy to
>> grasp.
>>
>>
>> How would you parse questions? With part-of-speech tokenization with,
>> say, OpenNLP (https://github.com/dakrone/clojure-opennlp) (link to the
>> Clojure wrapper)?
>>
>> The whole thing could be wrapped within a xmpp or ws bot. I tried making
>> simple echo xmpp and ws bots, it was pretty straightforward (although I am
>> sure my Clojure code is awful).
>>
>> And as Nico said, Clojure is probably easy to refactor. Another good
>> thing is that it seems to enforce building small blocks first. So one could
>> start with those. And, yes, refactor later.
>>
>> My two cents.
>>
>> Greetings, i-blis.
>>
>>
>> On Saturday, 18 May 2013 at 9:46, Nico Balestra wrote:
>>
>> > Hi Andrew,
>> > Thank you for sharing your idea with us. Just wondering... Why waiting
>> until we finish reading the book? I think if we find a way to stay engaged
>> while reading the book it could be a great way to keep the interest alive
>> and participate actively in this group.
>> > After all, if we do things in a non idiomatic way we can still refactor
>> later... and refactoring Clojure code is so much easy than refactoring Java
>> one :)
>> > I hope you agree :)
>> > Nico,
>> > > From BST
>> >
>> > On 18 May 2013 02:15, "Andrew Wagner" <wagner.andrew@gmail.com (mailto:
>> wagner.andrew@gmail.com)> wrote:
>> > > All,
>> > > I have an idea for a project the group could work on after finishing
>> the book. This is something that I've been pondering for a while, but don't
>> feel like I could make much headway on my own.
>> > >
>> > > The idea is a question-answering system. You feed it text, it
>> converts that text into a series of facts, about which you can then ask it
>> questions. I can imagine a number of uses for such a capability, and
>> clojure seems like a good fit for it.
>> > >
>> > > Thoughts?
>>
>>
>>
>

Re: [foray] Project for the group

From:
i-blis
Date:
2013-05-18 @ 19:00
Hi Ali.

I think Andrew meant that refactoring is made easier by the fact that 
Clojure fosters the use of short and composable functions. Side effects 
being isolated in a small number of functions, you can easily refactor 
without breaking things. Pure functions are easily combined, swapped, 
reflowed etc.  (I don't know if this is clear at all).

All the best. 


On Saturday, 18 May 2013 at 18:57, Ali Baitam wrote:

> Andrew, i-blis,
> How do you refactor Clojure code? is there a blog post on how to 
refactor Clojure code you can point me to? Is there a tool you use or just
paredit in emacs?
> 
> 
> 
> On Sat, May 18, 2013 at 7:20 AM, Andrew Wagner <wagner.andrew@gmail.com 
(mailto:wagner.andrew@gmail.com)> wrote:
> > For the data, core.logic is one thing I thought about. Another one I 
was thinking of was datomic, for the scaling and querying properties. 
Whatever we choose, this is one spot where I would want to try to have a 
layer of abstraction, so that we can swap it out later. Another idea I had
in this area was to use the concept of provenance, as talked about by 
Sussman at Strange Loop a couple years ago 
(http://www.infoq.com/presentations/We-Really-Dont-Know-How-To-Compute). 
That could be powerful.
> > 
> > In terms of parsing questions, yes, I think that OpenNLP could be 
useful. One idea I had would be to have multiple algorithms processing the
question, and returning both an answer and a confidence. Along the lines 
of the Watson program that played Jeopardy. Maybe with a blackboard 
implementation for communication across threads. 
> > 
> > For web access, I was thinking we might use the new Pedestal.io 
(http://Pedestal.io) to build an async service (possibly with a simpler, 
synchronous side, too). This would give us the ability to hook up a number
of different clients, including your bot ideas, I think. 
> > 
> > 
> > On Sat, May 18, 2013 at 6:03 AM, i-blis <i-blis@yandex.ru 
(mailto:i-blis@yandex.ru)> wrote:
> > > Nice idea.
> > > 
> > > What do you have in mind for the processing? core.logic 
(https://github.com/clojure/core.logic) (for generating and querying 
facts)? Note that core.logic (kind of miniKaren) is really not easy to 
grasp.
> > > 
> > > 
> > > How would you parse questions? With part-of-speech tokenization 
with, say, OpenNLP (https://github.com/dakrone/clojure-opennlp) (link to 
the Clojure wrapper)?
> > > 
> > > The whole thing could be wrapped within a xmpp or ws bot. I tried 
making simple echo xmpp and ws bots, it was pretty straightforward 
(although I am sure my Clojure code is awful).
> > > 
> > > And as Nico said, Clojure is probably easy to refactor. Another good
thing is that it seems to enforce building small blocks first. So one 
could start with those. And, yes, refactor later.
> > > 
> > > My two cents.
> > > 
> > > Greetings, i-blis.
> > > 
> > > 
> > > On Saturday, 18 May 2013 at 9:46, Nico Balestra wrote:
> > > 
> > > > Hi Andrew,
> > > > Thank you for sharing your idea with us. Just wondering... Why 
waiting until we finish reading the book? I think if we find a way to stay
engaged while reading the book it could be a great way to keep the 
interest alive and participate actively in this group.
> > > > After all, if we do things in a non idiomatic way we can still 
refactor later... and refactoring Clojure code is so much easy than 
refactoring Java one :)
> > > > I hope you agree :)
> > > > Nico,
> > > > > From BST
> > > > 
> > > > 
> > > > On 18 May 2013 02:15, "Andrew Wagner" <wagner.andrew@gmail.com 
(mailto:wagner.andrew@gmail.com) (mailto:wagner.andrew@gmail.com)> wrote:
> > > > > All,
> > > > > I have an idea for a project the group could work on after 
finishing the book. This is something that I've been pondering for a 
while, but don't feel like I could make much headway on my own.
> > > > > 
> > > > > The idea is a question-answering system. You feed it text, it 
converts that text into a series of facts, about which you can then ask it
questions. I can imagine a number of uses for such a capability, and 
clojure seems like a good fit for it.
> > > > > 
> > > > > Thoughts? 

Re: [foray] Project for the group

From:
Ali Baitam
Date:
2013-05-18 @ 19:02
It is clear; but I thought you use a refactoring tool or techniques that
you could share.

Best Regards


On Sat, May 18, 2013 at 3:00 PM, i-blis <i-blis@yandex.ru> wrote:

> Hi Ali.
>
> I think Andrew meant that refactoring is made easier by the fact that
> Clojure fosters the use of short and composable functions. Side effects
> being isolated in a small number of functions, you can easily refactor
> without breaking things. Pure functions are easily combined, swapped,
> reflowed etc.  (I don't know if this is clear at all).
>
> All the best.
>
>
> On Saturday, 18 May 2013 at 18:57, Ali Baitam wrote:
>
> > Andrew, i-blis,
> > How do you refactor Clojure code? is there a blog post on how to
> refactor Clojure code you can point me to? Is there a tool you use or just
> paredit in emacs?
> >
> >
> >
> > On Sat, May 18, 2013 at 7:20 AM, Andrew Wagner 
<wagner.andrew@gmail.com(mailto:
> wagner.andrew@gmail.com)> wrote:
> > > For the data, core.logic is one thing I thought about. Another one I
> was thinking of was datomic, for the scaling and querying properties.
> Whatever we choose, this is one spot where I would want to try to have a
> layer of abstraction, so that we can swap it out later. Another idea I had
> in this area was to use the concept of provenance, as talked about by
> Sussman at Strange Loop a couple years ago (
> http://www.infoq.com/presentations/We-Really-Dont-Know-How-To-Compute).
> That could be powerful.
> > >
> > > In terms of parsing questions, yes, I think that OpenNLP could be
> useful. One idea I had would be to have multiple algorithms processing the
> question, and returning both an answer and a confidence. Along the lines of
> the Watson program that played Jeopardy. Maybe with a blackboard
> implementation for communication across threads.
> > >
> > > For web access, I was thinking we might use the new Pedestal.io (
> http://Pedestal.io) to build an async service (possibly with a simpler,
> synchronous side, too). This would give us the ability to hook up a number
> of different clients, including your bot ideas, I think.
> > >
> > >
> > > On Sat, May 18, 2013 at 6:03 AM, i-blis <i-blis@yandex.ru (mailto:
> i-blis@yandex.ru)> wrote:
> > > > Nice idea.
> > > >
> > > > What do you have in mind for the processing? core.logic (
> https://github.com/clojure/core.logic) (for generating and querying
> facts)? Note that core.logic (kind of miniKaren) is really not easy to
> grasp.
> > > >
> > > >
> > > > How would you parse questions? With part-of-speech tokenization
> with, say, OpenNLP (https://github.com/dakrone/clojure-opennlp) (link to
> the Clojure wrapper)?
> > > >
> > > > The whole thing could be wrapped within a xmpp or ws bot. I tried
> making simple echo xmpp and ws bots, it was pretty straightforward
> (although I am sure my Clojure code is awful).
> > > >
> > > > And as Nico said, Clojure is probably easy to refactor. Another good
> thing is that it seems to enforce building small blocks first. So one could
> start with those. And, yes, refactor later.
> > > >
> > > > My two cents.
> > > >
> > > > Greetings, i-blis.
> > > >
> > > >
> > > > On Saturday, 18 May 2013 at 9:46, Nico Balestra wrote:
> > > >
> > > > > Hi Andrew,
> > > > > Thank you for sharing your idea with us. Just wondering... Why
> waiting until we finish reading the book? I think if we find a way to stay
> engaged while reading the book it could be a great way to keep the interest
> alive and participate actively in this group.
> > > > > After all, if we do things in a non idiomatic way we can still
> refactor later... and refactoring Clojure code is so much easy than
> refactoring Java one :)
> > > > > I hope you agree :)
> > > > > Nico,
> > > > > > From BST
> > > > >
> > > > >
> > > > > On 18 May 2013 02:15, "Andrew Wagner" <wagner.andrew@gmail.com(mailto:
> wagner.andrew@gmail.com) (mailto:wagner.andrew@gmail.com)> wrote:
> > > > > > All,
> > > > > > I have an idea for a project the group could work on after
> finishing the book. This is something that I've been pondering for a while,
> but don't feel like I could make much headway on my own.
> > > > > >
> > > > > > The idea is a question-answering system. You feed it text, it
> converts that text into a series of facts, about which you can then ask it
> questions. I can imagine a number of uses for such a capability, and
> clojure seems like a good fit for it.
> > > > > >
> > > > > > Thoughts?
>
>
>

Re: [foray] Project for the group

From:
David Mitchell
Date:
2013-05-19 @ 00:12
Hi Ali,

This might be obvious, but I'd say the best technique would be to do your
Clojure development and refactoring using a TDD approach.  In that case,
you should have tests for all of your functions - that way you can easily
refactor your functions and test to see if they still do what you expect.

The lack of side-effects in Clojure is key here - that's what would make
this approach so much easier/faster than in a non-functional language,
where you may have all sorts of side-effects that your tests need to deal
with.

Regards

Dave M.


On 19 May 2013 05:02, Ali Baitam <abaitam@gmail.com> wrote:

> It is clear; but I thought you use a refactoring tool or techniques that
> you could share.
>
> Best Regards
>
>
> On Sat, May 18, 2013 at 3:00 PM, i-blis <i-blis@yandex.ru> wrote:
>
>> Hi Ali.
>>
>> I think Andrew meant that refactoring is made easier by the fact that
>> Clojure fosters the use of short and composable functions. Side effects
>> being isolated in a small number of functions, you can easily refactor
>> without breaking things. Pure functions are easily combined, swapped,
>> reflowed etc.  (I don't know if this is clear at all).
>>
>> All the best.
>>
>>
>> On Saturday, 18 May 2013 at 18:57, Ali Baitam wrote:
>>
>> > Andrew, i-blis,
>> > How do you refactor Clojure code? is there a blog post on how to
>> refactor Clojure code you can point me to? Is there a tool you use or just
>> paredit in emacs?
>> >
>> >
>> >
>> > On Sat, May 18, 2013 at 7:20 AM, Andrew Wagner 
<wagner.andrew@gmail.com(mailto:
>> wagner.andrew@gmail.com)> wrote:
>> > > For the data, core.logic is one thing I thought about. Another one I
>> was thinking of was datomic, for the scaling and querying properties.
>> Whatever we choose, this is one spot where I would want to try to have a
>> layer of abstraction, so that we can swap it out later. Another idea I had
>> in this area was to use the concept of provenance, as talked about by
>> Sussman at Strange Loop a couple years ago (
>> http://www.infoq.com/presentations/We-Really-Dont-Know-How-To-Compute).
>> That could be powerful.
>> > >
>> > > In terms of parsing questions, yes, I think that OpenNLP could be
>> useful. One idea I had would be to have multiple algorithms processing the
>> question, and returning both an answer and a confidence. Along the lines of
>> the Watson program that played Jeopardy. Maybe with a blackboard
>> implementation for communication across threads.
>> > >
>> > > For web access, I was thinking we might use the new Pedestal.io (
>> http://Pedestal.io) to build an async service (possibly with a simpler,
>> synchronous side, too). This would give us the ability to hook up a number
>> of different clients, including your bot ideas, I think.
>> > >
>> > >
>> > > On Sat, May 18, 2013 at 6:03 AM, i-blis <i-blis@yandex.ru (mailto:
>> i-blis@yandex.ru)> wrote:
>> > > > Nice idea.
>> > > >
>> > > > What do you have in mind for the processing? core.logic (
>> https://github.com/clojure/core.logic) (for generating and querying
>> facts)? Note that core.logic (kind of miniKaren) is really not easy to
>> grasp.
>> > > >
>> > > >
>> > > > How would you parse questions? With part-of-speech tokenization
>> with, say, OpenNLP (https://github.com/dakrone/clojure-opennlp) (link to
>> the Clojure wrapper)?
>> > > >
>> > > > The whole thing could be wrapped within a xmpp or ws bot. I tried
>> making simple echo xmpp and ws bots, it was pretty straightforward
>> (although I am sure my Clojure code is awful).
>> > > >
>> > > > And as Nico said, Clojure is probably easy to refactor. Another
>> good thing is that it seems to enforce building small blocks first. So one
>> could start with those. And, yes, refactor later.
>> > > >
>> > > > My two cents.
>> > > >
>> > > > Greetings, i-blis.
>> > > >
>> > > >
>> > > > On Saturday, 18 May 2013 at 9:46, Nico Balestra wrote:
>> > > >
>> > > > > Hi Andrew,
>> > > > > Thank you for sharing your idea with us. Just wondering... Why
>> waiting until we finish reading the book? I think if we find a way to stay
>> engaged while reading the book it could be a great way to keep the interest
>> alive and participate actively in this group.
>> > > > > After all, if we do things in a non idiomatic way we can still
>> refactor later... and refactoring Clojure code is so much easy than
>> refactoring Java one :)
>> > > > > I hope you agree :)
>> > > > > Nico,
>> > > > > > From BST
>> > > > >
>> > > > >
>> > > > > On 18 May 2013 02:15, "Andrew Wagner" <wagner.andrew@gmail.com(mailto:
>> wagner.andrew@gmail.com) (mailto:wagner.andrew@gmail.com)> wrote:
>> > > > > > All,
>> > > > > > I have an idea for a project the group could work on after
>> finishing the book. This is something that I've been pondering for a while,
>> but don't feel like I could make much headway on my own.
>> > > > > >
>> > > > > > The idea is a question-answering system. You feed it text, it
>> converts that text into a series of facts, about which you can then ask it
>> questions. I can imagine a number of uses for such a capability, and
>> clojure seems like a good fit for it.
>> > > > > >
>> > > > > > Thoughts?
>>
>>
>>
>

Re: [foray] Project for the group

From:
Ali Baitam
Date:
2013-05-19 @ 00:29
Yes David, that's what I am doing but in a very simple way having tests
next to the function. I'll later start doing TDD properly. I just want to
get better at writing function especially in an idiomatic way.

Regards
Ali


On Sat, May 18, 2013 at 8:12 PM, David Mitchell <monch1962@gmail.com> wrote:

> Hi Ali,
>
> This might be obvious, but I'd say the best technique would be to do your
> Clojure development and refactoring using a TDD approach.  In that case,
> you should have tests for all of your functions - that way you can easily
> refactor your functions and test to see if they still do what you expect.
>
> The lack of side-effects in Clojure is key here - that's what would make
> this approach so much easier/faster than in a non-functional language,
> where you may have all sorts of side-effects that your tests need to deal
> with.
>
> Regards
>
> Dave M.
>
>
> On 19 May 2013 05:02, Ali Baitam <abaitam@gmail.com> wrote:
>
>> It is clear; but I thought you use a refactoring tool or techniques that
>> you could share.
>>
>> Best Regards
>>
>>
>> On Sat, May 18, 2013 at 3:00 PM, i-blis <i-blis@yandex.ru> wrote:
>>
>>> Hi Ali.
>>>
>>> I think Andrew meant that refactoring is made easier by the fact that
>>> Clojure fosters the use of short and composable functions. Side effects
>>> being isolated in a small number of functions, you can easily refactor
>>> without breaking things. Pure functions are easily combined, swapped,
>>> reflowed etc.  (I don't know if this is clear at all).
>>>
>>> All the best.
>>>
>>>
>>> On Saturday, 18 May 2013 at 18:57, Ali Baitam wrote:
>>>
>>> > Andrew, i-blis,
>>> > How do you refactor Clojure code? is there a blog post on how to
>>> refactor Clojure code you can point me to? Is there a tool you use or just
>>> paredit in emacs?
>>> >
>>> >
>>> >
>>> > On Sat, May 18, 2013 at 7:20 AM, Andrew Wagner <
>>> wagner.andrew@gmail.com (mailto:wagner.andrew@gmail.com)> wrote:
>>> > > For the data, core.logic is one thing I thought about. Another one I
>>> was thinking of was datomic, for the scaling and querying properties.
>>> Whatever we choose, this is one spot where I would want to try to have a
>>> layer of abstraction, so that we can swap it out later. Another idea I had
>>> in this area was to use the concept of provenance, as talked about by
>>> Sussman at Strange Loop a couple years ago (
>>> http://www.infoq.com/presentations/We-Really-Dont-Know-How-To-Compute).
>>> That could be powerful.
>>> > >
>>> > > In terms of parsing questions, yes, I think that OpenNLP could be
>>> useful. One idea I had would be to have multiple algorithms processing the
>>> question, and returning both an answer and a confidence. Along the lines of
>>> the Watson program that played Jeopardy. Maybe with a blackboard
>>> implementation for communication across threads.
>>> > >
>>> > > For web access, I was thinking we might use the new Pedestal.io (
>>> http://Pedestal.io) to build an async service (possibly with a simpler,
>>> synchronous side, too). This would give us the ability to hook up a number
>>> of different clients, including your bot ideas, I think.
>>> > >
>>> > >
>>> > > On Sat, May 18, 2013 at 6:03 AM, i-blis <i-blis@yandex.ru (mailto:
>>> i-blis@yandex.ru)> wrote:
>>> > > > Nice idea.
>>> > > >
>>> > > > What do you have in mind for the processing? core.logic (
>>> https://github.com/clojure/core.logic) (for generating and querying
>>> facts)? Note that core.logic (kind of miniKaren) is really not easy to
>>> grasp.
>>> > > >
>>> > > >
>>> > > > How would you parse questions? With part-of-speech tokenization
>>> with, say, OpenNLP (https://github.com/dakrone/clojure-opennlp) (link
>>> to the Clojure wrapper)?
>>> > > >
>>> > > > The whole thing could be wrapped within a xmpp or ws bot. I tried
>>> making simple echo xmpp and ws bots, it was pretty straightforward
>>> (although I am sure my Clojure code is awful).
>>> > > >
>>> > > > And as Nico said, Clojure is probably easy to refactor. Another
>>> good thing is that it seems to enforce building small blocks first. So one
>>> could start with those. And, yes, refactor later.
>>> > > >
>>> > > > My two cents.
>>> > > >
>>> > > > Greetings, i-blis.
>>> > > >
>>> > > >
>>> > > > On Saturday, 18 May 2013 at 9:46, Nico Balestra wrote:
>>> > > >
>>> > > > > Hi Andrew,
>>> > > > > Thank you for sharing your idea with us. Just wondering... Why
>>> waiting until we finish reading the book? I think if we find a way to stay
>>> engaged while reading the book it could be a great way to keep the interest
>>> alive and participate actively in this group.
>>> > > > > After all, if we do things in a non idiomatic way we can still
>>> refactor later... and refactoring Clojure code is so much easy than
>>> refactoring Java one :)
>>> > > > > I hope you agree :)
>>> > > > > Nico,
>>> > > > > > From BST
>>> > > > >
>>> > > > >
>>> > > > > On 18 May 2013 02:15, "Andrew Wagner" <wagner.andrew@gmail.com(mailto:
>>> wagner.andrew@gmail.com) (mailto:wagner.andrew@gmail.com)> wrote:
>>> > > > > > All,
>>> > > > > > I have an idea for a project the group could work on after
>>> finishing the book. This is something that I've been pondering for a while,
>>> but don't feel like I could make much headway on my own.
>>> > > > > >
>>> > > > > > The idea is a question-answering system. You feed it text, it
>>> converts that text into a series of facts, about which you can then ask it
>>> questions. I can imagine a number of uses for such a capability, and
>>> clojure seems like a good fit for it.
>>> > > > > >
>>> > > > > > Thoughts?
>>>
>>>
>>>
>>
>

Re: [foray] Project for the group

From:
David Mitchell
Date:
2013-05-19 @ 03:33
Hi Ali,

We're at exactly the same point then - I'm trying to work out how Leiningen
wants me to lay out my tests in the test/ directory, and what value
Leiningen gives me for TDD over and above just having my tests inline,
exactly as you're doing.

Dave M.


On 19 May 2013 10:29, Ali Baitam <abaitam@gmail.com> wrote:

> Yes David, that's what I am doing but in a very simple way having tests
> next to the function. I'll later start doing TDD properly. I just want to
> get better at writing function especially in an idiomatic way.
>
> Regards
> Ali
>
>
> On Sat, May 18, 2013 at 8:12 PM, David Mitchell <monch1962@gmail.com>wrote:
>
>> Hi Ali,
>>
>> This might be obvious, but I'd say the best technique would be to do your
>> Clojure development and refactoring using a TDD approach.  In that case,
>> you should have tests for all of your functions - that way you can easily
>> refactor your functions and test to see if they still do what you expect.
>>
>> The lack of side-effects in Clojure is key here - that's what would make
>> this approach so much easier/faster than in a non-functional language,
>> where you may have all sorts of side-effects that your tests need to deal
>> with.
>>
>> Regards
>>
>> Dave M.
>>
>>
>> On 19 May 2013 05:02, Ali Baitam <abaitam@gmail.com> wrote:
>>
>>> It is clear; but I thought you use a refactoring tool or techniques that
>>> you could share.
>>>
>>> Best Regards
>>>
>>>
>>> On Sat, May 18, 2013 at 3:00 PM, i-blis <i-blis@yandex.ru> wrote:
>>>
>>>> Hi Ali.
>>>>
>>>> I think Andrew meant that refactoring is made easier by the fact that
>>>> Clojure fosters the use of short and composable functions. Side effects
>>>> being isolated in a small number of functions, you can easily refactor
>>>> without breaking things. Pure functions are easily combined, swapped,
>>>> reflowed etc.  (I don't know if this is clear at all).
>>>>
>>>> All the best.
>>>>
>>>>
>>>> On Saturday, 18 May 2013 at 18:57, Ali Baitam wrote:
>>>>
>>>> > Andrew, i-blis,
>>>> > How do you refactor Clojure code? is there a blog post on how to
>>>> refactor Clojure code you can point me to? Is there a tool you use or just
>>>> paredit in emacs?
>>>> >
>>>> >
>>>> >
>>>> > On Sat, May 18, 2013 at 7:20 AM, Andrew Wagner <
>>>> wagner.andrew@gmail.com (mailto:wagner.andrew@gmail.com)> wrote:
>>>> > > For the data, core.logic is one thing I thought about. Another one
>>>> I was thinking of was datomic, for the scaling and querying properties.
>>>> Whatever we choose, this is one spot where I would want to try to have a
>>>> layer of abstraction, so that we can swap it out later. Another idea I had
>>>> in this area was to use the concept of provenance, as talked about by
>>>> Sussman at Strange Loop a couple years ago (
>>>> http://www.infoq.com/presentations/We-Really-Dont-Know-How-To-Compute).
>>>> That could be powerful.
>>>> > >
>>>> > > In terms of parsing questions, yes, I think that OpenNLP could be
>>>> useful. One idea I had would be to have multiple algorithms processing the
>>>> question, and returning both an answer and a confidence. Along the lines of
>>>> the Watson program that played Jeopardy. Maybe with a blackboard
>>>> implementation for communication across threads.
>>>> > >
>>>> > > For web access, I was thinking we might use the new Pedestal.io (
>>>> http://Pedestal.io) to build an async service (possibly with a
>>>> simpler, synchronous side, too). This would give us the ability to hook up
>>>> a number of different clients, including your bot ideas, I think.
>>>> > >
>>>> > >
>>>> > > On Sat, May 18, 2013 at 6:03 AM, i-blis <i-blis@yandex.ru (mailto:
>>>> i-blis@yandex.ru)> wrote:
>>>> > > > Nice idea.
>>>> > > >
>>>> > > > What do you have in mind for the processing? core.logic (
>>>> https://github.com/clojure/core.logic) (for generating and querying
>>>> facts)? Note that core.logic (kind of miniKaren) is really not easy to
>>>> grasp.
>>>> > > >
>>>> > > >
>>>> > > > How would you parse questions? With part-of-speech tokenization
>>>> with, say, OpenNLP (https://github.com/dakrone/clojure-opennlp) (link
>>>> to the Clojure wrapper)?
>>>> > > >
>>>> > > > The whole thing could be wrapped within a xmpp or ws bot. I tried
>>>> making simple echo xmpp and ws bots, it was pretty straightforward
>>>> (although I am sure my Clojure code is awful).
>>>> > > >
>>>> > > > And as Nico said, Clojure is probably easy to refactor. Another
>>>> good thing is that it seems to enforce building small blocks first. So one
>>>> could start with those. And, yes, refactor later.
>>>> > > >
>>>> > > > My two cents.
>>>> > > >
>>>> > > > Greetings, i-blis.
>>>> > > >
>>>> > > >
>>>> > > > On Saturday, 18 May 2013 at 9:46, Nico Balestra wrote:
>>>> > > >
>>>> > > > > Hi Andrew,
>>>> > > > > Thank you for sharing your idea with us. Just wondering... Why
>>>> waiting until we finish reading the book? I think if we find a way to stay
>>>> engaged while reading the book it could be a great way to keep the interest
>>>> alive and participate actively in this group.
>>>> > > > > After all, if we do things in a non idiomatic way we can still
>>>> refactor later... and refactoring Clojure code is so much easy than
>>>> refactoring Java one :)
>>>> > > > > I hope you agree :)
>>>> > > > > Nico,
>>>> > > > > > From BST
>>>> > > > >
>>>> > > > >
>>>> > > > > On 18 May 2013 02:15, "Andrew Wagner" 
<wagner.andrew@gmail.com(mailto:
>>>> wagner.andrew@gmail.com) (mailto:wagner.andrew@gmail.com)> wrote:
>>>> > > > > > All,
>>>> > > > > > I have an idea for a project the group could work on after
>>>> finishing the book. This is something that I've been pondering for a while,
>>>> but don't feel like I could make much headway on my own.
>>>> > > > > >
>>>> > > > > > The idea is a question-answering system. You feed it text, it
>>>> converts that text into a series of facts, about which you can then ask it
>>>> questions. I can imagine a number of uses for such a capability, and
>>>> clojure seems like a good fit for it.
>>>> > > > > >
>>>> > > > > > Thoughts?
>>>>
>>>>
>>>>
>>>
>>
>

Re: [foray] Project for the group

From:
Ali Baitam
Date:
2013-05-19 @ 03:43
Hi David,
You are ahead of me :) I am not doing TDD my way. What I meant to say is
that I am trying to concentrate on the language itself and will come back
to do TDD later. I just write a function, say to solve a 4Clojure problem,
and write tests "expressions" (from 4Clojure also, below the function and
evaluate them manually. I am not using clojure.test. Actually, I have like
thirty problems so far in one file (extreme newbie here)!! All I want to do
is to "think" the Clojure way; mechanics come later.

Are you new to Clojure?

Ali

On Sat, May 18, 2013 at 11:33 PM, David Mitchell <monch1962@gmail.com>wrote:

> Hi Ali,
>
> We're at exactly the same point then - I'm trying to work out how
> Leiningen wants me to lay out my tests in the test/ directory, and what
> value Leiningen gives me for TDD over and above just having my tests
> inline, exactly as you're doing.
>
> Dave M.
>
>
> On 19 May 2013 10:29, Ali Baitam <abaitam@gmail.com> wrote:
>
>> Yes David, that's what I am doing but in a very simple way having tests
>> next to the function. I'll later start doing TDD properly. I just want to
>> get better at writing function especially in an idiomatic way.
>>
>> Regards
>> Ali
>>
>>
>> On Sat, May 18, 2013 at 8:12 PM, David Mitchell <monch1962@gmail.com>wrote:
>>
>>> Hi Ali,
>>>
>>> This might be obvious, but I'd say the best technique would be to do
>>> your Clojure development and refactoring using a TDD approach.  In that
>>> case, you should have tests for all of your functions - that way you can
>>> easily refactor your functions and test to see if they still do what you
>>> expect.
>>>
>>> The lack of side-effects in Clojure is key here - that's what would make
>>> this approach so much easier/faster than in a non-functional language,
>>> where you may have all sorts of side-effects that your tests need to deal
>>> with.
>>>
>>> Regards
>>>
>>> Dave M.
>>>
>>>
>>> On 19 May 2013 05:02, Ali Baitam <abaitam@gmail.com> wrote:
>>>
>>>> It is clear; but I thought you use a refactoring tool or techniques
>>>> that you could share.
>>>>
>>>> Best Regards
>>>>
>>>>
>>>> On Sat, May 18, 2013 at 3:00 PM, i-blis <i-blis@yandex.ru> wrote:
>>>>
>>>>> Hi Ali.
>>>>>
>>>>> I think Andrew meant that refactoring is made easier by the fact that
>>>>> Clojure fosters the use of short and composable functions. Side effects
>>>>> being isolated in a small number of functions, you can easily refactor
>>>>> without breaking things. Pure functions are easily combined, swapped,
>>>>> reflowed etc.  (I don't know if this is clear at all).
>>>>>
>>>>> All the best.
>>>>>
>>>>>
>>>>> On Saturday, 18 May 2013 at 18:57, Ali Baitam wrote:
>>>>>
>>>>> > Andrew, i-blis,
>>>>> > How do you refactor Clojure code? is there a blog post on how to
>>>>> refactor Clojure code you can point me to? Is there a tool you use or just
>>>>> paredit in emacs?
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Sat, May 18, 2013 at 7:20 AM, Andrew Wagner <
>>>>> wagner.andrew@gmail.com (mailto:wagner.andrew@gmail.com)> wrote:
>>>>> > > For the data, core.logic is one thing I thought about. Another one
>>>>> I was thinking of was datomic, for the scaling and querying properties.
>>>>> Whatever we choose, this is one spot where I would want to try to have a
>>>>> layer of abstraction, so that we can swap it out later. Another idea I had
>>>>> in this area was to use the concept of provenance, as talked about by
>>>>> Sussman at Strange Loop a couple years ago (
>>>>> http://www.infoq.com/presentations/We-Really-Dont-Know-How-To-Compute).
>>>>> That could be powerful.
>>>>> > >
>>>>> > > In terms of parsing questions, yes, I think that OpenNLP could be
>>>>> useful. One idea I had would be to have multiple algorithms processing the
>>>>> question, and returning both an answer and a confidence. Along the lines of
>>>>> the Watson program that played Jeopardy. Maybe with a blackboard
>>>>> implementation for communication across threads.
>>>>> > >
>>>>> > > For web access, I was thinking we might use the new Pedestal.io (
>>>>> http://Pedestal.io) to build an async service (possibly with a
>>>>> simpler, synchronous side, too). This would give us the ability to hook up
>>>>> a number of different clients, including your bot ideas, I think.
>>>>> > >
>>>>> > >
>>>>> > > On Sat, May 18, 2013 at 6:03 AM, i-blis <i-blis@yandex.ru (mailto:
>>>>> i-blis@yandex.ru)> wrote:
>>>>> > > > Nice idea.
>>>>> > > >
>>>>> > > > What do you have in mind for the processing? core.logic (
>>>>> https://github.com/clojure/core.logic) (for generating and querying
>>>>> facts)? Note that core.logic (kind of miniKaren) is really not easy to
>>>>> grasp.
>>>>> > > >
>>>>> > > >
>>>>> > > > How would you parse questions? With part-of-speech tokenization
>>>>> with, say, OpenNLP (https://github.com/dakrone/clojure-opennlp) (link
>>>>> to the Clojure wrapper)?
>>>>> > > >
>>>>> > > > The whole thing could be wrapped within a xmpp or ws bot. I
>>>>> tried making simple echo xmpp and ws bots, it was pretty straightforward
>>>>> (although I am sure my Clojure code is awful).
>>>>> > > >
>>>>> > > > And as Nico said, Clojure is probably easy to refactor. Another
>>>>> good thing is that it seems to enforce building small blocks first. So one
>>>>> could start with those. And, yes, refactor later.
>>>>> > > >
>>>>> > > > My two cents.
>>>>> > > >
>>>>> > > > Greetings, i-blis.
>>>>> > > >
>>>>> > > >
>>>>> > > > On Saturday, 18 May 2013 at 9:46, Nico Balestra wrote:
>>>>> > > >
>>>>> > > > > Hi Andrew,
>>>>> > > > > Thank you for sharing your idea with us. Just wondering... Why
>>>>> waiting until we finish reading the book? I think if we find a way to stay
>>>>> engaged while reading the book it could be a great way to keep the interest
>>>>> alive and participate actively in this group.
>>>>> > > > > After all, if we do things in a non idiomatic way we can still
>>>>> refactor later... and refactoring Clojure code is so much easy than
>>>>> refactoring Java one :)
>>>>> > > > > I hope you agree :)
>>>>> > > > > Nico,
>>>>> > > > > > From BST
>>>>> > > > >
>>>>> > > > >
>>>>> > > > > On 18 May 2013 02:15, "Andrew Wagner" 
<wagner.andrew@gmail.com(mailto:
>>>>> wagner.andrew@gmail.com) (mailto:wagner.andrew@gmail.com)> wrote:
>>>>> > > > > > All,
>>>>> > > > > > I have an idea for a project the group could work on after
>>>>> finishing the book. This is something that I've been pondering for a while,
>>>>> but don't feel like I could make much headway on my own.
>>>>> > > > > >
>>>>> > > > > > The idea is a question-answering system. You feed it text,
>>>>> it converts that text into a series of facts, about which you can then ask
>>>>> it questions. I can imagine a number of uses for such a capability, and
>>>>> clojure seems like a good fit for it.
>>>>> > > > > >
>>>>> > > > > > Thoughts?
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [foray] Project for the group

From:
David Mitchell
Date:
2013-05-19 @ 04:43
Hi Ali,

I'm new to Clojure, but I'm jumping in the deep end and rewriting a fairly
complex Python web app I wrote a couple of years ago.  It works OK as is,
but is very slow because it's full of matrix data calculations and I wasn't
able to write it using Python's numpy library at the time.  As a result,
there's lots of nested for loops as it iterates through tables of data.
 While a full Clojure rewrite might sound like a big challenge for a first
project, I already know exactly what my Python app does, so I can first
concentrate on simply porting it to Clojure, then later refactor my clunky
Clojure code as I find out more about the language.

I'd be surprised if the Clojure rewrite wasn't at least 5-10x faster than
the Python version, and the parts I've already rewritten are about 1/2 the
number of lines of code.

The Python version was written using TDD to a point, but the complexity of
some of the calculations meant that I have tests for about 70-80% of the
code - getting to 100% would've required test code that was many times the
size of the code being tested, so I didn't bother with it.  Clojure looks
like a particularly good fit though, because I can just break down the
functionality into lots of little standalone functions and build tests for
each.  Leiningen looks like it's probably got a very handy way to run tests
against the code base, but I haven't yet gotten my head around how to use
it properly.


On 19 May 2013 13:43, Ali Baitam <abaitam@gmail.com> wrote:

> Hi David,
> You are ahead of me :) I am not doing TDD my way. What I meant to say is
> that I am trying to concentrate on the language itself and will come back
> to do TDD later. I just write a function, say to solve a 4Clojure problem,
> and write tests "expressions" (from 4Clojure also, below the function and
> evaluate them manually. I am not using clojure.test. Actually, I have like
> thirty problems so far in one file (extreme newbie here)!! All I want to do
> is to "think" the Clojure way; mechanics come later.
>
> Are you new to Clojure?
>
> Ali
>
>
> On Sat, May 18, 2013 at 11:33 PM, David Mitchell <monch1962@gmail.com>wrote:
>
>> Hi Ali,
>>
>> We're at exactly the same point then - I'm trying to work out how
>> Leiningen wants me to lay out my tests in the test/ directory, and what
>> value Leiningen gives me for TDD over and above just having my tests
>> inline, exactly as you're doing.
>>
>> Dave M.
>>
>>
>> On 19 May 2013 10:29, Ali Baitam <abaitam@gmail.com> wrote:
>>
>>> Yes David, that's what I am doing but in a very simple way having tests
>>> next to the function. I'll later start doing TDD properly. I just want to
>>> get better at writing function especially in an idiomatic way.
>>>
>>> Regards
>>> Ali
>>>
>>>
>>> On Sat, May 18, 2013 at 8:12 PM, David Mitchell <monch1962@gmail.com>wrote:
>>>
>>>> Hi Ali,
>>>>
>>>> This might be obvious, but I'd say the best technique would be to do
>>>> your Clojure development and refactoring using a TDD approach.  In that
>>>> case, you should have tests for all of your functions - that way you can
>>>> easily refactor your functions and test to see if they still do what you
>>>> expect.
>>>>
>>>> The lack of side-effects in Clojure is key here - that's what would
>>>> make this approach so much easier/faster than in a non-functional language,
>>>> where you may have all sorts of side-effects that your tests need to deal
>>>> with.
>>>>
>>>> Regards
>>>>
>>>> Dave M.
>>>>
>>>>
>>>> On 19 May 2013 05:02, Ali Baitam <abaitam@gmail.com> wrote:
>>>>
>>>>> It is clear; but I thought you use a refactoring tool or techniques
>>>>> that you could share.
>>>>>
>>>>> Best Regards
>>>>>
>>>>>
>>>>> On Sat, May 18, 2013 at 3:00 PM, i-blis <i-blis@yandex.ru> wrote:
>>>>>
>>>>>> Hi Ali.
>>>>>>
>>>>>> I think Andrew meant that refactoring is made easier by the fact that
>>>>>> Clojure fosters the use of short and composable functions. Side effects
>>>>>> being isolated in a small number of functions, you can easily refactor
>>>>>> without breaking things. Pure functions are easily combined, swapped,
>>>>>> reflowed etc.  (I don't know if this is clear at all).
>>>>>>
>>>>>> All the best.
>>>>>>
>>>>>>
>>>>>> On Saturday, 18 May 2013 at 18:57, Ali Baitam wrote:
>>>>>>
>>>>>> > Andrew, i-blis,
>>>>>> > How do you refactor Clojure code? is there a blog post on how to
>>>>>> refactor Clojure code you can point me to? Is there a tool you use or just
>>>>>> paredit in emacs?
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > On Sat, May 18, 2013 at 7:20 AM, Andrew Wagner <
>>>>>> wagner.andrew@gmail.com (mailto:wagner.andrew@gmail.com)> wrote:
>>>>>> > > For the data, core.logic is one thing I thought about. Another
>>>>>> one I was thinking of was datomic, for the scaling and querying properties.
>>>>>> Whatever we choose, this is one spot where I would want to try to have a
>>>>>> layer of abstraction, so that we can swap it out later. Another idea I had
>>>>>> in this area was to use the concept of provenance, as talked about by
>>>>>> Sussman at Strange Loop a couple years ago (
>>>>>> http://www.infoq.com/presentations/We-Really-Dont-Know-How-To-Compute).
>>>>>> That could be powerful.
>>>>>> > >
>>>>>> > > In terms of parsing questions, yes, I think that OpenNLP could be
>>>>>> useful. One idea I had would be to have multiple algorithms processing the
>>>>>> question, and returning both an answer and a confidence. Along the lines of
>>>>>> the Watson program that played Jeopardy. Maybe with a blackboard
>>>>>> implementation for communication across threads.
>>>>>> > >
>>>>>> > > For web access, I was thinking we might use the new Pedestal.io (
>>>>>> http://Pedestal.io) to build an async service (possibly with a
>>>>>> simpler, synchronous side, too). This would give us the ability to hook up
>>>>>> a number of different clients, including your bot ideas, I think.
>>>>>> > >
>>>>>> > >
>>>>>> > > On Sat, May 18, 2013 at 6:03 AM, i-blis <i-blis@yandex.ru(mailto:
>>>>>> i-blis@yandex.ru)> wrote:
>>>>>> > > > Nice idea.
>>>>>> > > >
>>>>>> > > > What do you have in mind for the processing? core.logic (
>>>>>> https://github.com/clojure/core.logic) (for generating and querying
>>>>>> facts)? Note that core.logic (kind of miniKaren) is really not easy to
>>>>>> grasp.
>>>>>> > > >
>>>>>> > > >
>>>>>> > > > How would you parse questions? With part-of-speech tokenization
>>>>>> with, say, OpenNLP (https://github.com/dakrone/clojure-opennlp)
>>>>>> (link to the Clojure wrapper)?
>>>>>> > > >
>>>>>> > > > The whole thing could be wrapped within a xmpp or ws bot. I
>>>>>> tried making simple echo xmpp and ws bots, it was pretty straightforward
>>>>>> (although I am sure my Clojure code is awful).
>>>>>> > > >
>>>>>> > > > And as Nico said, Clojure is probably easy to refactor. Another
>>>>>> good thing is that it seems to enforce building small blocks first. So one
>>>>>> could start with those. And, yes, refactor later.
>>>>>> > > >
>>>>>> > > > My two cents.
>>>>>> > > >
>>>>>> > > > Greetings, i-blis.
>>>>>> > > >
>>>>>> > > >
>>>>>> > > > On Saturday, 18 May 2013 at 9:46, Nico Balestra wrote:
>>>>>> > > >
>>>>>> > > > > Hi Andrew,
>>>>>> > > > > Thank you for sharing your idea with us. Just wondering...
>>>>>> Why waiting until we finish reading the book? I think if we find a way to
>>>>>> stay engaged while reading the book it could be a great way to keep the
>>>>>> interest alive and participate actively in this group.
>>>>>> > > > > After all, if we do things in a non idiomatic way we can
>>>>>> still refactor later... and refactoring Clojure code is so much easy than
>>>>>> refactoring Java one :)
>>>>>> > > > > I hope you agree :)
>>>>>> > > > > Nico,
>>>>>> > > > > > From BST
>>>>>> > > > >
>>>>>> > > > >
>>>>>> > > > > On 18 May 2013 02:15, "Andrew Wagner" <
>>>>>> wagner.andrew@gmail.com (mailto:wagner.andrew@gmail.com) (mailto:
>>>>>> wagner.andrew@gmail.com)> wrote:
>>>>>> > > > > > All,
>>>>>> > > > > > I have an idea for a project the group could work on after
>>>>>> finishing the book. This is something that I've been pondering for a while,
>>>>>> but don't feel like I could make much headway on my own.
>>>>>> > > > > >
>>>>>> > > > > > The idea is a question-answering system. You feed it text,
>>>>>> it converts that text into a series of facts, about which you can then ask
>>>>>> it questions. I can imagine a number of uses for such a capability, and
>>>>>> clojure seems like a good fit for it.
>>>>>> > > > > >
>>>>>> > > > > > Thoughts?
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [foray] Project for the group

From:
Sean Corfield
Date:
2013-05-20 @ 15:36
On May 18, 2013, at 9:43 PM, David Mitchell wrote:
> Clojure looks like a particularly good fit though, because I can just 
break down the functionality into lots of little standalone functions and 
build tests for each.  Leiningen looks like it's probably got a very handy
way to run tests against the code base, but I haven't yet gotten my head 
around how to use it properly.

When you create a new project with Leiningen, it automatically creates a 
test stub:

lein new myproject
cd myproject
lein test

The project structure is:

.
|____.gitignore
|____doc
| |____intro.md
|____project.clj
|____README.md
|____resources
|____src
| |____myproject
| | |____core.clj
|____test
| |____myproject
| | |____core_test.clj

so your initial "main" code is in src/myproject/core.clj with a namespace 
of myproject.core and you test code is in test/myproject/core_test.clj 
with a namespace of myproject.core-test

For TDD, add your test(s) to code in the test/ tree, run `lein test` to 
see them fail as expected, write code in files in your src/ tree and run 
`lein test` and see them pass (hopefully). Refactor, run `lein test`. 
Rinse and repeat.

I don't know if there's an actively maintained plugin for lein that 
watches src/ and test/ and automatically re-runs the tests, but if you use
either Expectations or Midje instead of the built-in clojure.test, then 
there are definitely "continuous testing" plugins.

I like Expectations for the BDD-style language and the simplicity of 
tests. The lein-expectations plugin allows me to have my tests run 
automatically as soon as I save changes to any file in the project.

https://github.com/jaycfields/expectations

Sean A 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)



Re: [foray] Project for the group

From:
Ali Baitam
Date:
2013-05-19 @ 05:17
Very cool. I am sure with such an application you'll find Clojure's data
structures very helpful.

I guess some of the recipes in the recently released book would probably be
useful to you: Clojure Data Analysis
Cookbook<http://www.packtpub.com/clojure-data-analysis-cookbook/book>

Good luck
Ali


On Sun, May 19, 2013 at 12:43 AM, David Mitchell <monch1962@gmail.com>wrote:

> Hi Ali,
>
> I'm new to Clojure, but I'm jumping in the deep end and rewriting a fairly
> complex Python web app I wrote a couple of years ago.  It works OK as is,
> but is very slow because it's full of matrix data calculations and I wasn't
> able to write it using Python's numpy library at the time.  As a result,
> there's lots of nested for loops as it iterates through tables of data.
>  While a full Clojure rewrite might sound like a big challenge for a first
> project, I already know exactly what my Python app does, so I can first
> concentrate on simply porting it to Clojure, then later refactor my clunky
> Clojure code as I find out more about the language.
>
> I'd be surprised if the Clojure rewrite wasn't at least 5-10x faster than
> the Python version, and the parts I've already rewritten are about 1/2 the
> number of lines of code.
>
> The Python version was written using TDD to a point, but the complexity of
> some of the calculations meant that I have tests for about 70-80% of the
> code - getting to 100% would've required test code that was many times the
> size of the code being tested, so I didn't bother with it.  Clojure looks
> like a particularly good fit though, because I can just break down the
> functionality into lots of little standalone functions and build tests for
> each.  Leiningen looks like it's probably got a very handy way to run tests
> against the code base, but I haven't yet gotten my head around how to use
> it properly.
>
>
> On 19 May 2013 13:43, Ali Baitam <abaitam@gmail.com> wrote:
>
>> Hi David,
>> You are ahead of me :) I am not doing TDD my way. What I meant to say is
>> that I am trying to concentrate on the language itself and will come back
>> to do TDD later. I just write a function, say to solve a 4Clojure problem,
>> and write tests "expressions" (from 4Clojure also, below the function and
>> evaluate them manually. I am not using clojure.test. Actually, I have like
>> thirty problems so far in one file (extreme newbie here)!! All I want to do
>> is to "think" the Clojure way; mechanics come later.
>>
>> Are you new to Clojure?
>>
>> Ali
>>
>>
>> On Sat, May 18, 2013 at 11:33 PM, David Mitchell <monch1962@gmail.com>wrote:
>>
>>> Hi Ali,
>>>
>>> We're at exactly the same point then - I'm trying to work out how
>>> Leiningen wants me to lay out my tests in the test/ directory, and what
>>> value Leiningen gives me for TDD over and above just having my tests
>>> inline, exactly as you're doing.
>>>
>>> Dave M.
>>>
>>>
>>> On 19 May 2013 10:29, Ali Baitam <abaitam@gmail.com> wrote:
>>>
>>>> Yes David, that's what I am doing but in a very simple way having tests
>>>> next to the function. I'll later start doing TDD properly. I just want to
>>>> get better at writing function especially in an idiomatic way.
>>>>
>>>> Regards
>>>> Ali
>>>>
>>>>
>>>> On Sat, May 18, 2013 at 8:12 PM, David Mitchell <monch1962@gmail.com>wrote:
>>>>
>>>>> Hi Ali,
>>>>>
>>>>> This might be obvious, but I'd say the best technique would be to do
>>>>> your Clojure development and refactoring using a TDD approach.  In that
>>>>> case, you should have tests for all of your functions - that way you can
>>>>> easily refactor your functions and test to see if they still do what you
>>>>> expect.
>>>>>
>>>>> The lack of side-effects in Clojure is key here - that's what would
>>>>> make this approach so much easier/faster than in a non-functional language,
>>>>> where you may have all sorts of side-effects that your tests need to deal
>>>>> with.
>>>>>
>>>>> Regards
>>>>>
>>>>> Dave M.
>>>>>
>>>>>
>>>>> On 19 May 2013 05:02, Ali Baitam <abaitam@gmail.com> wrote:
>>>>>
>>>>>> It is clear; but I thought you use a refactoring tool or techniques
>>>>>> that you could share.
>>>>>>
>>>>>> Best Regards
>>>>>>
>>>>>>
>>>>>> On Sat, May 18, 2013 at 3:00 PM, i-blis <i-blis@yandex.ru> wrote:
>>>>>>
>>>>>>> Hi Ali.
>>>>>>>
>>>>>>> I think Andrew meant that refactoring is made easier by the fact
>>>>>>> that Clojure fosters the use of short and composable functions. Side
>>>>>>> effects being isolated in a small number of functions, you can easily
>>>>>>> refactor without breaking things. Pure functions are easily combined,
>>>>>>> swapped, reflowed etc.  (I don't know if this is clear at all).
>>>>>>>
>>>>>>> All the best.
>>>>>>>
>>>>>>>
>>>>>>> On Saturday, 18 May 2013 at 18:57, Ali Baitam wrote:
>>>>>>>
>>>>>>> > Andrew, i-blis,
>>>>>>> > How do you refactor Clojure code? is there a blog post on how to
>>>>>>> refactor Clojure code you can point me to? Is there a tool you use or just
>>>>>>> paredit in emacs?
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > On Sat, May 18, 2013 at 7:20 AM, Andrew Wagner <
>>>>>>> wagner.andrew@gmail.com (mailto:wagner.andrew@gmail.com)> wrote:
>>>>>>> > > For the data, core.logic is one thing I thought about. Another
>>>>>>> one I was thinking of was datomic, for the scaling and querying 
properties.
>>>>>>> Whatever we choose, this is one spot where I would want to try to have a
>>>>>>> layer of abstraction, so that we can swap it out later. Another idea I had
>>>>>>> in this area was to use the concept of provenance, as talked about by
>>>>>>> Sussman at Strange Loop a couple years ago (
>>>>>>> http://www.infoq.com/presentations/We-Really-Dont-Know-How-To-Compute).
>>>>>>> That could be powerful.
>>>>>>> > >
>>>>>>> > > In terms of parsing questions, yes, I think that OpenNLP could
>>>>>>> be useful. One idea I had would be to have multiple algorithms processing
>>>>>>> the question, and returning both an answer and a confidence. Along the
>>>>>>> lines of the Watson program that played Jeopardy. Maybe with a blackboard
>>>>>>> implementation for communication across threads.
>>>>>>> > >
>>>>>>> > > For web access, I was thinking we might use the new Pedestal.io (
>>>>>>> http://Pedestal.io) to build an async service (possibly with a
>>>>>>> simpler, synchronous side, too). This would give us the ability to hook up
>>>>>>> a number of different clients, including your bot ideas, I think.
>>>>>>> > >
>>>>>>> > >
>>>>>>> > > On Sat, May 18, 2013 at 6:03 AM, i-blis <i-blis@yandex.ru(mailto:
>>>>>>> i-blis@yandex.ru)> wrote:
>>>>>>> > > > Nice idea.
>>>>>>> > > >
>>>>>>> > > > What do you have in mind for the processing? core.logic (
>>>>>>> https://github.com/clojure/core.logic) (for generating and querying
>>>>>>> facts)? Note that core.logic (kind of miniKaren) is really not easy to
>>>>>>> grasp.
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > > How would you parse questions? With part-of-speech
>>>>>>> tokenization with, say, OpenNLP (
>>>>>>> https://github.com/dakrone/clojure-opennlp) (link to the Clojure
>>>>>>> wrapper)?
>>>>>>> > > >
>>>>>>> > > > The whole thing could be wrapped within a xmpp or ws bot. I
>>>>>>> tried making simple echo xmpp and ws bots, it was pretty straightforward
>>>>>>> (although I am sure my Clojure code is awful).
>>>>>>> > > >
>>>>>>> > > > And as Nico said, Clojure is probably easy to refactor.
>>>>>>> Another good thing is that it seems to enforce building small 
blocks first.
>>>>>>> So one could start with those. And, yes, refactor later.
>>>>>>> > > >
>>>>>>> > > > My two cents.
>>>>>>> > > >
>>>>>>> > > > Greetings, i-blis.
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > > On Saturday, 18 May 2013 at 9:46, Nico Balestra wrote:
>>>>>>> > > >
>>>>>>> > > > > Hi Andrew,
>>>>>>> > > > > Thank you for sharing your idea with us. Just wondering...
>>>>>>> Why waiting until we finish reading the book? I think if we find a way to
>>>>>>> stay engaged while reading the book it could be a great way to keep the
>>>>>>> interest alive and participate actively in this group.
>>>>>>> > > > > After all, if we do things in a non idiomatic way we can
>>>>>>> still refactor later... and refactoring Clojure code is so much easy than
>>>>>>> refactoring Java one :)
>>>>>>> > > > > I hope you agree :)
>>>>>>> > > > > Nico,
>>>>>>> > > > > > From BST
>>>>>>> > > > >
>>>>>>> > > > >
>>>>>>> > > > > On 18 May 2013 02:15, "Andrew Wagner" <
>>>>>>> wagner.andrew@gmail.com (mailto:wagner.andrew@gmail.com) (mailto:
>>>>>>> wagner.andrew@gmail.com)> wrote:
>>>>>>> > > > > > All,
>>>>>>> > > > > > I have an idea for a project the group could work on after
>>>>>>> finishing the book. This is something that I've been pondering for
a while,
>>>>>>> but don't feel like I could make much headway on my own.
>>>>>>> > > > > >
>>>>>>> > > > > > The idea is a question-answering system. You feed it text,
>>>>>>> it converts that text into a series of facts, about which you can then ask
>>>>>>> it questions. I can imagine a number of uses for such a capability, and
>>>>>>> clojure seems like a good fit for it.
>>>>>>> > > > > >
>>>>>>> > > > > > Thoughts?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [foray] Project for the group

From:
David Mitchell
Date:
2013-05-19 @ 08:46
Yep, got that book, and the "Clojure Inside Out" videos are pretty good as
well.  It's nice to hear experts (Stu Holloway in this case) actually talk
about how to do stuff in Clojure; sometimes a few words from an expert in a
video convey what I've failed to pick up by reading about the same topic
several times.

I do a lot of work in R as well as Python (and Erlang, and Ruby, and C, and
now Clojure), so the Incanter library for Clojure is of particular interest
to me.

The "Clojure Inside Out" videos list for $US70, but you can always find
some OReilly discount codes if you look for them


On 19 May 2013 15:17, Ali Baitam <abaitam@gmail.com> wrote:

> Very cool. I am sure with such an application you'll find Clojure's data
> structures very helpful.
>
> I guess some of the recipes in the recently released book would probably
> be useful to you: Clojure Data Analysis 
Cookbook<http://www.packtpub.com/clojure-data-analysis-cookbook/book>
>
> Good luck
> Ali
>
>
> On Sun, May 19, 2013 at 12:43 AM, David Mitchell <monch1962@gmail.com>wrote:
>
>> Hi Ali,
>>
>> I'm new to Clojure, but I'm jumping in the deep end and rewriting a
>> fairly complex Python web app I wrote a couple of years ago.  It works OK
>> as is, but is very slow because it's full of matrix data calculations and I
>> wasn't able to write it using Python's numpy library at the time.  As a
>> result, there's lots of nested for loops as it iterates through tables of
>> data.  While a full Clojure rewrite might sound like a big challenge for a
>> first project, I already know exactly what my Python app does, so I can
>> first concentrate on simply porting it to Clojure, then later refactor my
>> clunky Clojure code as I find out more about the language.
>>
>> I'd be surprised if the Clojure rewrite wasn't at least 5-10x faster than
>> the Python version, and the parts I've already rewritten are about 1/2 the
>> number of lines of code.
>>
>> The Python version was written using TDD to a point, but the complexity
>> of some of the calculations meant that I have tests for about 70-80% of the
>> code - getting to 100% would've required test code that was many times the
>> size of the code being tested, so I didn't bother with it.  Clojure looks
>> like a particularly good fit though, because I can just break down the
>> functionality into lots of little standalone functions and build tests for
>> each.  Leiningen looks like it's probably got a very handy way to run tests
>> against the code base, but I haven't yet gotten my head around how to use
>> it properly.
>>
>>
>> On 19 May 2013 13:43, Ali Baitam <abaitam@gmail.com> wrote:
>>
>>> Hi David,
>>> You are ahead of me :) I am not doing TDD my way. What I meant to say is
>>> that I am trying to concentrate on the language itself and will come back
>>> to do TDD later. I just write a function, say to solve a 4Clojure problem,
>>> and write tests "expressions" (from 4Clojure also, below the function and
>>> evaluate them manually. I am not using clojure.test. Actually, I have like
>>> thirty problems so far in one file (extreme newbie here)!! All I want to do
>>> is to "think" the Clojure way; mechanics come later.
>>>
>>> Are you new to Clojure?
>>>
>>> Ali
>>>
>>>
>>> On Sat, May 18, 2013 at 11:33 PM, David Mitchell <monch1962@gmail.com>wrote:
>>>
>>>> Hi Ali,
>>>>
>>>> We're at exactly the same point then - I'm trying to work out how
>>>> Leiningen wants me to lay out my tests in the test/ directory, and what
>>>> value Leiningen gives me for TDD over and above just having my tests
>>>> inline, exactly as you're doing.
>>>>
>>>> Dave M.
>>>>
>>>>
>>>> On 19 May 2013 10:29, Ali Baitam <abaitam@gmail.com> wrote:
>>>>
>>>>> Yes David, that's what I am doing but in a very simple way having
>>>>> tests next to the function. I'll later start doing TDD properly. I just
>>>>> want to get better at writing function especially in an idiomatic way.
>>>>>
>>>>> Regards
>>>>> Ali
>>>>>
>>>>>
>>>>> On Sat, May 18, 2013 at 8:12 PM, David Mitchell <monch1962@gmail.com>wrote:
>>>>>
>>>>>> Hi Ali,
>>>>>>
>>>>>> This might be obvious, but I'd say the best technique would be to do
>>>>>> your Clojure development and refactoring using a TDD approach.  In that
>>>>>> case, you should have tests for all of your functions - that way you can
>>>>>> easily refactor your functions and test to see if they still do what you
>>>>>> expect.
>>>>>>
>>>>>> The lack of side-effects in Clojure is key here - that's what would
>>>>>> make this approach so much easier/faster than in a non-functional language,
>>>>>> where you may have all sorts of side-effects that your tests need to deal
>>>>>> with.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Dave M.
>>>>>>
>>>>>>
>>>>>> On 19 May 2013 05:02, Ali Baitam <abaitam@gmail.com> wrote:
>>>>>>
>>>>>>> It is clear; but I thought you use a refactoring tool or techniques
>>>>>>> that you could share.
>>>>>>>
>>>>>>> Best Regards
>>>>>>>
>>>>>>>
>>>>>>> On Sat, May 18, 2013 at 3:00 PM, i-blis <i-blis@yandex.ru> wrote:
>>>>>>>
>>>>>>>> Hi Ali.
>>>>>>>>
>>>>>>>> I think Andrew meant that refactoring is made easier by the fact
>>>>>>>> that Clojure fosters the use of short and composable functions. Side
>>>>>>>> effects being isolated in a small number of functions, you can easily
>>>>>>>> refactor without breaking things. Pure functions are easily combined,
>>>>>>>> swapped, reflowed etc.  (I don't know if this is clear at all).
>>>>>>>>
>>>>>>>> All the best.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Saturday, 18 May 2013 at 18:57, Ali Baitam wrote:
>>>>>>>>
>>>>>>>> > Andrew, i-blis,
>>>>>>>> > How do you refactor Clojure code? is there a blog post on how to
>>>>>>>> refactor Clojure code you can point me to? Is there a tool you 
use or just
>>>>>>>> paredit in emacs?
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > On Sat, May 18, 2013 at 7:20 AM, Andrew Wagner <
>>>>>>>> wagner.andrew@gmail.com (mailto:wagner.andrew@gmail.com)> wrote:
>>>>>>>> > > For the data, core.logic is one thing I thought about. Another
>>>>>>>> one I was thinking of was datomic, for the scaling and querying 
properties.
>>>>>>>> Whatever we choose, this is one spot where I would want to try to have a
>>>>>>>> layer of abstraction, so that we can swap it out later. Another 
idea I had
>>>>>>>> in this area was to use the concept of provenance, as talked about by
>>>>>>>> Sussman at Strange Loop a couple years ago (
>>>>>>>> http://www.infoq.com/presentations/We-Really-Dont-Know-How-To-Compute).
>>>>>>>> That could be powerful.
>>>>>>>> > >
>>>>>>>> > > In terms of parsing questions, yes, I think that OpenNLP could
>>>>>>>> be useful. One idea I had would be to have multiple algorithms processing
>>>>>>>> the question, and returning both an answer and a confidence. Along the
>>>>>>>> lines of the Watson program that played Jeopardy. Maybe with a blackboard
>>>>>>>> implementation for communication across threads.
>>>>>>>> > >
>>>>>>>> > > For web access, I was thinking we might use the new Pedestal.io
>>>>>>>> (http://Pedestal.io) to build an async service (possibly with a
>>>>>>>> simpler, synchronous side, too). This would give us the ability 
to hook up
>>>>>>>> a number of different clients, including your bot ideas, I think.
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>> > > On Sat, May 18, 2013 at 6:03 AM, i-blis <i-blis@yandex.ru(mailto:
>>>>>>>> i-blis@yandex.ru)> wrote:
>>>>>>>> > > > Nice idea.
>>>>>>>> > > >
>>>>>>>> > > > What do you have in mind for the processing? core.logic (
>>>>>>>> https://github.com/clojure/core.logic) (for generating and
>>>>>>>> querying facts)? Note that core.logic (kind of miniKaren) is really not
>>>>>>>> easy to grasp.
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > > How would you parse questions? With part-of-speech
>>>>>>>> tokenization with, say, OpenNLP (
>>>>>>>> https://github.com/dakrone/clojure-opennlp) (link to the Clojure
>>>>>>>> wrapper)?
>>>>>>>> > > >
>>>>>>>> > > > The whole thing could be wrapped within a xmpp or ws bot. I
>>>>>>>> tried making simple echo xmpp and ws bots, it was pretty straightforward
>>>>>>>> (although I am sure my Clojure code is awful).
>>>>>>>> > > >
>>>>>>>> > > > And as Nico said, Clojure is probably easy to refactor.
>>>>>>>> Another good thing is that it seems to enforce building small 
blocks first.
>>>>>>>> So one could start with those. And, yes, refactor later.
>>>>>>>> > > >
>>>>>>>> > > > My two cents.
>>>>>>>> > > >
>>>>>>>> > > > Greetings, i-blis.
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > > On Saturday, 18 May 2013 at 9:46, Nico Balestra wrote:
>>>>>>>> > > >
>>>>>>>> > > > > Hi Andrew,
>>>>>>>> > > > > Thank you for sharing your idea with us. Just wondering...
>>>>>>>> Why waiting until we finish reading the book? I think if we find a way to
>>>>>>>> stay engaged while reading the book it could be a great way to keep the
>>>>>>>> interest alive and participate actively in this group.
>>>>>>>> > > > > After all, if we do things in a non idiomatic way we can
>>>>>>>> still refactor later... and refactoring Clojure code is so much easy than
>>>>>>>> refactoring Java one :)
>>>>>>>> > > > > I hope you agree :)
>>>>>>>> > > > > Nico,
>>>>>>>> > > > > > From BST
>>>>>>>> > > > >
>>>>>>>> > > > >
>>>>>>>> > > > > On 18 May 2013 02:15, "Andrew Wagner" <
>>>>>>>> wagner.andrew@gmail.com (mailto:wagner.andrew@gmail.com) (mailto:
>>>>>>>> wagner.andrew@gmail.com)> wrote:
>>>>>>>> > > > > > All,
>>>>>>>> > > > > > I have an idea for a project the group could work on
>>>>>>>> after finishing the book. This is something that I've been 
pondering for a
>>>>>>>> while, but don't feel like I could make much headway on my own.
>>>>>>>> > > > > >
>>>>>>>> > > > > > The idea is a question-answering system. You feed it
>>>>>>>> text, it converts that text into a series of facts, about which you can
>>>>>>>> then ask it questions. I can imagine a number of uses for such a
>>>>>>>> capability, and clojure seems like a good fit for it.
>>>>>>>> > > > > >
>>>>>>>> > > > > > Thoughts?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [foray] Project for the group

From:
Adrian Gruntkowski
Date:
2013-05-19 @ 21:18
Although the original project idea is very cool, I'm concerned about the
cognitive load that it can put on people just starting out in Clojure and
not too familiar with NLP. Some are struggling with emacs and clojure at
the same time - adding another thing which people have to wrap their heads
around may be too much for some ;) Maybe some more run-of-the-mill web
application could be a better fit? Of course, if there's a group that is
perfectly fine with the current concept, there's nothing in the way of
starting more than one project.

In case of web app development in general, I'm also a bit concerned about
pushing pedestal.io from the beginning. It requires substantial amount of
time to get familiar with it. It also represents a quite opinionated view
of how web app development should look like. I think that starting with
plain simple ring with lightweight wrappers (compojure) and necessary
libraries would be a better start.

Some middle ground between a full blown application and 4Clojure one-liners
could be some sort of a series of assignments - the problem is that
somebody would have to prepare them. Ages ago, there was an online Clojure
course on RubyLearning.org (
http://rubylearning.com/blog/2010/03/09/clojure-101-a-new-course/ ) which I
took part in. The assignments there were of reasonable scope and even
touched on real world aspects (maybe not as exciting as NLP but still),
like webserver log parsing. I will try to dig out materials from that
course, however I'm afraid that I could have lost them while moving to new
hardware.

Just my 2 cents.

--
Adrian


2013/5/19 David Mitchell <monch1962@gmail.com>

> Yep, got that book, and the "Clojure Inside Out" videos are pretty good as
> well.  It's nice to hear experts (Stu Holloway in this case) actually talk
> about how to do stuff in Clojure; sometimes a few words from an expert in a
> video convey what I've failed to pick up by reading about the same topic
> several times.
>
> I do a lot of work in R as well as Python (and Erlang, and Ruby, and C,
> and now Clojure), so the Incanter library for Clojure is of particular
> interest to me.
>
> The "Clojure Inside Out" videos list for $US70, but you can always find
> some OReilly discount codes if you look for them
>
>
> On 19 May 2013 15:17, Ali Baitam <abaitam@gmail.com> wrote:
>
>> Very cool. I am sure with such an application you'll find Clojure's data
>> structures very helpful.
>>
>> I guess some of the recipes in the recently released book would probably
>> be useful to you: Clojure Data Analysis 
Cookbook<http://www.packtpub.com/clojure-data-analysis-cookbook/book>
>>
>> Good luck
>> Ali
>>
>>
>> On Sun, May 19, 2013 at 12:43 AM, David Mitchell <monch1962@gmail.com>wrote:
>>
>>> Hi Ali,
>>>
>>> I'm new to Clojure, but I'm jumping in the deep end and rewriting a
>>> fairly complex Python web app I wrote a couple of years ago.  It works OK
>>> as is, but is very slow because it's full of matrix data calculations and I
>>> wasn't able to write it using Python's numpy library at the time.  As a
>>> result, there's lots of nested for loops as it iterates through tables of
>>> data.  While a full Clojure rewrite might sound like a big challenge for a
>>> first project, I already know exactly what my Python app does, so I can
>>> first concentrate on simply porting it to Clojure, then later refactor my
>>> clunky Clojure code as I find out more about the language.
>>>
>>> I'd be surprised if the Clojure rewrite wasn't at least 5-10x faster
>>> than the Python version, and the parts I've already rewritten are about 1/2
>>> the number of lines of code.
>>>
>>> The Python version was written using TDD to a point, but the complexity
>>> of some of the calculations meant that I have tests for about 70-80% of the
>>> code - getting to 100% would've required test code that was many times the
>>> size of the code being tested, so I didn't bother with it.  Clojure looks
>>> like a particularly good fit though, because I can just break down the
>>> functionality into lots of little standalone functions and build tests for
>>> each.  Leiningen looks like it's probably got a very handy way to run tests
>>> against the code base, but I haven't yet gotten my head around how to use
>>> it properly.
>>>
>>>
>>> On 19 May 2013 13:43, Ali Baitam <abaitam@gmail.com> wrote:
>>>
>>>> Hi David,
>>>> You are ahead of me :) I am not doing TDD my way. What I meant to say
>>>> is that I am trying to concentrate on the language itself and will come
>>>> back to do TDD later. I just write a function, say to solve a 4Clojure
>>>> problem, and write tests "expressions" (from 4Clojure also, below the
>>>> function and evaluate them manually. I am not using clojure.test. Actually,
>>>> I have like thirty problems so far in one file (extreme newbie here)!! All
>>>> I want to do is to "think" the Clojure way; mechanics come later.
>>>>
>>>> Are you new to Clojure?
>>>>
>>>> Ali
>>>>
>>>>
>>>> On Sat, May 18, 2013 at 11:33 PM, David Mitchell <monch1962@gmail.com>wrote:
>>>>
>>>>> Hi Ali,
>>>>>
>>>>> We're at exactly the same point then - I'm trying to work out how
>>>>> Leiningen wants me to lay out my tests in the test/ directory, and what
>>>>> value Leiningen gives me for TDD over and above just having my tests
>>>>> inline, exactly as you're doing.
>>>>>
>>>>> Dave M.
>>>>>
>>>>>
>>>>> On 19 May 2013 10:29, Ali Baitam <abaitam@gmail.com> wrote:
>>>>>
>>>>>> Yes David, that's what I am doing but in a very simple way having
>>>>>> tests next to the function. I'll later start doing TDD properly. I just
>>>>>> want to get better at writing function especially in an idiomatic way.
>>>>>>
>>>>>> Regards
>>>>>> Ali
>>>>>>
>>>>>>
>>>>>> On Sat, May 18, 2013 at 8:12 PM, David Mitchell <monch1962@gmail.com>wrote:
>>>>>>
>>>>>>> Hi Ali,
>>>>>>>
>>>>>>> This might be obvious, but I'd say the best technique would be to do
>>>>>>> your Clojure development and refactoring using a TDD approach.  In that
>>>>>>> case, you should have tests for all of your functions - that way you can
>>>>>>> easily refactor your functions and test to see if they still do what you
>>>>>>> expect.
>>>>>>>
>>>>>>> The lack of side-effects in Clojure is key here - that's what would
>>>>>>> make this approach so much easier/faster than in a non-functional 
language,
>>>>>>> where you may have all sorts of side-effects that your tests need to deal
>>>>>>> with.
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Dave M.
>>>>>>>
>>>>>>>
>>>>>>> On 19 May 2013 05:02, Ali Baitam <abaitam@gmail.com> wrote:
>>>>>>>
>>>>>>>> It is clear; but I thought you use a refactoring tool or techniques
>>>>>>>> that you could share.
>>>>>>>>
>>>>>>>> Best Regards
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, May 18, 2013 at 3:00 PM, i-blis <i-blis@yandex.ru> wrote:
>>>>>>>>
>>>>>>>>> Hi Ali.
>>>>>>>>>
>>>>>>>>> I think Andrew meant that refactoring is made easier by the fact
>>>>>>>>> that Clojure fosters the use of short and composable functions. Side
>>>>>>>>> effects being isolated in a small number of functions, you can easily
>>>>>>>>> refactor without breaking things. Pure functions are easily combined,
>>>>>>>>> swapped, reflowed etc.  (I don't know if this is clear at all).
>>>>>>>>>
>>>>>>>>> All the best.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Saturday, 18 May 2013 at 18:57, Ali Baitam wrote:
>>>>>>>>>
>>>>>>>>> > Andrew, i-blis,
>>>>>>>>> > How do you refactor Clojure code? is there a blog post on how to
>>>>>>>>> refactor Clojure code you can point me to? Is there a tool you 
use or just
>>>>>>>>> paredit in emacs?
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > On Sat, May 18, 2013 at 7:20 AM, Andrew Wagner <
>>>>>>>>> wagner.andrew@gmail.com (mailto:wagner.andrew@gmail.com)> wrote:
>>>>>>>>> > > For the data, core.logic is one thing I thought about. Another
>>>>>>>>> one I was thinking of was datomic, for the scaling and querying 
properties.
>>>>>>>>> Whatever we choose, this is one spot where I would want to try to have a
>>>>>>>>> layer of abstraction, so that we can swap it out later. Another 
idea I had
>>>>>>>>> in this area was to use the concept of provenance, as talked about by
>>>>>>>>> Sussman at Strange Loop a couple years ago (
>>>>>>>>> http://www.infoq.com/presentations/We-Really-Dont-Know-How-To-Compute).
>>>>>>>>> That could be powerful.
>>>>>>>>> > >
>>>>>>>>> > > In terms of parsing questions, yes, I think that OpenNLP could
>>>>>>>>> be useful. One idea I had would be to have multiple algorithms 
processing
>>>>>>>>> the question, and returning both an answer and a confidence. Along the
>>>>>>>>> lines of the Watson program that played Jeopardy. Maybe with a 
blackboard
>>>>>>>>> implementation for communication across threads.
>>>>>>>>> > >
>>>>>>>>> > > For web access, I was thinking we might use the new
>>>>>>>>> Pedestal.io (http://Pedestal.io) to build an async service
>>>>>>>>> (possibly with a simpler, synchronous side, too). This would give us the
>>>>>>>>> ability to hook up a number of different clients, including your
bot ideas,
>>>>>>>>> I think.
>>>>>>>>> > >
>>>>>>>>> > >
>>>>>>>>> > > On Sat, May 18, 2013 at 6:03 AM, i-blis <i-blis@yandex.ru(mailto:
>>>>>>>>> i-blis@yandex.ru)> wrote:
>>>>>>>>> > > > Nice idea.
>>>>>>>>> > > >
>>>>>>>>> > > > What do you have in mind for the processing? core.logic (
>>>>>>>>> https://github.com/clojure/core.logic) (for generating and
>>>>>>>>> querying facts)? Note that core.logic (kind of miniKaren) is really not
>>>>>>>>> easy to grasp.
>>>>>>>>> > > >
>>>>>>>>> > > >
>>>>>>>>> > > > How would you parse questions? With part-of-speech
>>>>>>>>> tokenization with, say, OpenNLP (
>>>>>>>>> https://github.com/dakrone/clojure-opennlp) (link to the Clojure
>>>>>>>>> wrapper)?
>>>>>>>>> > > >
>>>>>>>>> > > > The whole thing could be wrapped within a xmpp or ws bot. I
>>>>>>>>> tried making simple echo xmpp and ws bots, it was pretty straightforward
>>>>>>>>> (although I am sure my Clojure code is awful).
>>>>>>>>> > > >
>>>>>>>>> > > > And as Nico said, Clojure is probably easy to refactor.
>>>>>>>>> Another good thing is that it seems to enforce building small 
blocks first.
>>>>>>>>> So one could start with those. And, yes, refactor later.
>>>>>>>>> > > >
>>>>>>>>> > > > My two cents.
>>>>>>>>> > > >
>>>>>>>>> > > > Greetings, i-blis.
>>>>>>>>> > > >
>>>>>>>>> > > >
>>>>>>>>> > > > On Saturday, 18 May 2013 at 9:46, Nico Balestra wrote:
>>>>>>>>> > > >
>>>>>>>>> > > > > Hi Andrew,
>>>>>>>>> > > > > Thank you for sharing your idea with us. Just wondering...
>>>>>>>>> Why waiting until we finish reading the book? I think if we find
a way to
>>>>>>>>> stay engaged while reading the book it could be a great way to keep the
>>>>>>>>> interest alive and participate actively in this group.
>>>>>>>>> > > > > After all, if we do things in a non idiomatic way we can
>>>>>>>>> still refactor later... and refactoring Clojure code is so much 
easy than
>>>>>>>>> refactoring Java one :)
>>>>>>>>> > > > > I hope you agree :)
>>>>>>>>> > > > > Nico,
>>>>>>>>> > > > > > From BST
>>>>>>>>> > > > >
>>>>>>>>> > > > >
>>>>>>>>> > > > > On 18 May 2013 02:15, "Andrew Wagner" <
>>>>>>>>> wagner.andrew@gmail.com (mailto:wagner.andrew@gmail.com) (mailto:
>>>>>>>>> wagner.andrew@gmail.com)> wrote:
>>>>>>>>> > > > > > All,
>>>>>>>>> > > > > > I have an idea for a project the group could work on
>>>>>>>>> after finishing the book. This is something that I've been 
pondering for a
>>>>>>>>> while, but don't feel like I could make much headway on my own.
>>>>>>>>> > > > > >
>>>>>>>>> > > > > > The idea is a question-answering system. You feed it
>>>>>>>>> text, it converts that text into a series of facts, about which you can
>>>>>>>>> then ask it questions. I can imagine a number of uses for such a
>>>>>>>>> capability, and clojure seems like a good fit for it.
>>>>>>>>> > > > > >
>>>>>>>>> > > > > > Thoughts?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [foray] Project for the group

From:
Sean Corfield
Date:
2013-05-21 @ 23:05
On May 19, 2013, at 2:18 PM, Adrian Gruntkowski wrote:
> In case of web app development in general, I'm also a bit concerned 
about pushing pedestal.io from the beginning. It requires substantial 
amount of time to get familiar with it.

It also requires quite a bit of familiarity with ClojureScript and how to 
build/run such code (as well as server-side Clojure). It's definitely cool
- I was at Clojure/West where it was launched - but it's quite the cliff 
to climb.

> It also represents a quite opinionated view of how web app development 
should look like. I think that starting with plain simple ring with 
lightweight wrappers (compojure) and necessary libraries would be a better
start.

I'll toot my own horn here and suggest FW/1 for Clojure as a very simple, 
convention-based MVC framework:

https://github.com/framework-one/fw1-clj

It's a port to Clojure of a very popular framework that I wrote for CFML 
four years ago (which is actively maintained and widely used). It's based 
on Ring and Enlive (HTML templating library).

The easiest way to create a FW/1 app and get it running is the Leiningen 
template, explained here:

https://github.com/seancorfield/fw1-template

If you have Leiningen installed, just type:

	lein new fw1 foray
	cd foray
	PORT=8888 lein run

now you have a minimal FW/1 app running on port 8888. Edit your (HTML) 
views and your controllers, add ?reload=secret to the URL to pick up the 
changes (you can configure the framework to reload on every request if you
want).

The usermanager example should get you going but the documentation right 
now is a bit minimal and routes are currently only documented in the 
source itself:

https://github.com/framework-one/fw1-clj/blob/master/src/framework/one.clj#L249

The CFML framework on which it is based is documented here: 
https://github.com/framework-one/fw1/wiki

Subsystems, environment control and DI / services are not in the Clojure 
version (the latter because it isn't needed in a functional version; the 
former two just because I haven't felt the need for them yet).

Sean A 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)



Re: [foray] Project for the group

From:
Andrew Wagner
Date:
2013-05-19 @ 21:59
I think you make really good points across the board. I was probably a 
little biased in wanting to see progress on my own project.

The only rebuttal comment I would make is about pedestal being 
opinionated. I think you're right, but I think its opinion is very much in
line with that of things like datomic, and even clojure itself. I think 
the community, and certainly a core group centered around Relevance and 
Rich Hickey, are forming a very consistent philosophy about state 
management and separation of concerns, and you see the same philosophy 
clearly in Pedestal. 

On May 19, 2013, at 5:18 PM, Adrian Gruntkowski 
<adrian.gruntkowski@gmail.com> wrote:

> Although the original project idea is very cool, I'm concerned about the
cognitive load that it can put on people just starting out in Clojure and 
not too familiar with NLP. Some are struggling with emacs and clojure at 
the same time - adding another thing which people have to wrap their heads
around may be too much for some ;) Maybe some more run-of-the-mill web 
application could be a better fit? Of course, if there's a group that is 
perfectly fine with the current concept, there's nothing in the way of 
starting more than one project.
> 
> In case of web app development in general, I'm also a bit concerned 
about pushing pedestal.io from the beginning. It requires substantial 
amount of time to get familiar with it. It also represents a quite 
opinionated view of how web app development should look like. I think that
starting with plain simple ring with lightweight wrappers (compojure) and 
necessary libraries would be a better start.
> 
> Some middle ground between a full blown application and 4Clojure 
one-liners could be some sort of a series of assignments - the problem is 
that somebody would have to prepare them. Ages ago, there was an online 
Clojure course on RubyLearning.org ( 
http://rubylearning.com/blog/2010/03/09/clojure-101-a-new-course/ ) which 
I took part in. The assignments there were of reasonable scope and even 
touched on real world aspects (maybe not as exciting as NLP but still), 
like webserver log parsing. I will try to dig out materials from that 
course, however I'm afraid that I could have lost them while moving to new
hardware. 
> 
> Just my 2 cents.
> 
> --
> Adrian
> 
> 
> 2013/5/19 David Mitchell <monch1962@gmail.com>
>> Yep, got that book, and the "Clojure Inside Out" videos are pretty good
as well.  It's nice to hear experts (Stu Holloway in this case) actually 
talk about how to do stuff in Clojure; sometimes a few words from an 
expert in a video convey what I've failed to pick up by reading about the 
same topic several times.
>> 
>> I do a lot of work in R as well as Python (and Erlang, and Ruby, and C,
and now Clojure), so the Incanter library for Clojure is of particular 
interest to me.
>> 
>> The "Clojure Inside Out" videos list for $US70, but you can always find
some OReilly discount codes if you look for them
>> 
>> 
>> On 19 May 2013 15:17, Ali Baitam <abaitam@gmail.com> wrote:
>>> Very cool. I am sure with such an application you'll find Clojure's 
data structures very helpful.
>>> 
>>> I guess some of the recipes in the recently released book would 
probably be useful to you: Clojure Data Analysis Cookbook
>>> 
>>> Good luck
>>> Ali
>>> 
>>> 
>>> On Sun, May 19, 2013 at 12:43 AM, David Mitchell <monch1962@gmail.com> wrote:
>>>> Hi Ali,
>>>> 
>>>> I'm new to Clojure, but I'm jumping in the deep end and rewriting a 
fairly complex Python web app I wrote a couple of years ago.  It works OK 
as is, but is very slow because it's full of matrix data calculations and 
I wasn't able to write it using Python's numpy library at the time.  As a 
result, there's lots of nested for loops as it iterates through tables of 
data.  While a full Clojure rewrite might sound like a big challenge for a
first project, I already know exactly what my Python app does, so I can 
first concentrate on simply porting it to Clojure, then later refactor my 
clunky Clojure code as I find out more about the language.
>>>> 
>>>> I'd be surprised if the Clojure rewrite wasn't at least 5-10x faster 
than the Python version, and the parts I've already rewritten are about 
1/2 the number of lines of code.
>>>> 
>>>> The Python version was written using TDD to a point, but the 
complexity of some of the calculations meant that I have tests for about 
70-80% of the code - getting to 100% would've required test code that was 
many times the size of the code being tested, so I didn't bother with it.
Clojure looks like a particularly good fit though, because I can just 
break down the functionality into lots of little standalone functions and 
build tests for each.  Leiningen looks like it's probably got a very handy
way to run tests against the code base, but I haven't yet gotten my head 
around how to use it properly.
>>>> 
>>>> 
>>>> On 19 May 2013 13:43, Ali Baitam <abaitam@gmail.com> wrote:
>>>>> Hi David,
>>>>> You are ahead of me :) I am not doing TDD my way. What I meant to 
say is that I am trying to concentrate on the language itself and will 
come back to do TDD later. I just write a function, say to solve a 
4Clojure problem, and write tests "expressions" (from 4Clojure also, below
the function and evaluate them manually. I am not using clojure.test. 
Actually, I have like thirty problems so far in one file (extreme newbie 
here)!! All I want to do is to "think" the Clojure way; mechanics come 
later.
>>>>> 
>>>>> Are you new to Clojure?
>>>>> 
>>>>> Ali
>>>>> 
>>>>> 
>>>>> On Sat, May 18, 2013 at 11:33 PM, David Mitchell 
<monch1962@gmail.com> wrote:
>>>>>> Hi Ali,
>>>>>> 
>>>>>> We're at exactly the same point then - I'm trying to work out how 
Leiningen wants me to lay out my tests in the test/ directory, and what 
value Leiningen gives me for TDD over and above just having my tests 
inline, exactly as you're doing.
>>>>>> 
>>>>>> Dave M.
>>>>>> 
>>>>>> 
>>>>>> On 19 May 2013 10:29, Ali Baitam <abaitam@gmail.com> wrote:
>>>>>>> Yes David, that's what I am doing but in a very simple way having 
tests next to the function. I'll later start doing TDD properly. I just 
want to get better at writing function especially in an idiomatic way.
>>>>>>> 
>>>>>>> Regards
>>>>>>> Ali
>>>>>>> 
>>>>>>> 
>>>>>>> On Sat, May 18, 2013 at 8:12 PM, David Mitchell 
<monch1962@gmail.com> wrote:
>>>>>>>> Hi Ali,
>>>>>>>> 
>>>>>>>> This might be obvious, but I'd say the best technique would be to
do your Clojure development and refactoring using a TDD approach.  In that
case, you should have tests for all of your functions - that way you can 
easily refactor your functions and test to see if they still do what you 
expect.
>>>>>>>> 
>>>>>>>> The lack of side-effects in Clojure is key here - that's what 
would make this approach so much easier/faster than in a non-functional 
language, where you may have all sorts of side-effects that your tests 
need to deal with.
>>>>>>>> 
>>>>>>>> Regards
>>>>>>>> 
>>>>>>>> Dave M.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 19 May 2013 05:02, Ali Baitam <abaitam@gmail.com> wrote:
>>>>>>>>> It is clear; but I thought you use a refactoring tool or 
techniques that you could share.
>>>>>>>>> 
>>>>>>>>> Best Regards
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Sat, May 18, 2013 at 3:00 PM, i-blis <i-blis@yandex.ru> wrote:
>>>>>>>>>> Hi Ali.
>>>>>>>>>> 
>>>>>>>>>> I think Andrew meant that refactoring is made easier by the 
fact that Clojure fosters the use of short and composable functions. Side 
effects being isolated in a small number of functions, you can easily 
refactor without breaking things. Pure functions are easily combined, 
swapped, reflowed etc.  (I don't know if this is clear at all).
>>>>>>>>>> 
>>>>>>>>>> All the best.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Saturday, 18 May 2013 at 18:57, Ali Baitam wrote:
>>>>>>>>>> 
>>>>>>>>>> > Andrew, i-blis,
>>>>>>>>>> > How do you refactor Clojure code? is there a blog post on how
to refactor Clojure code you can point me to? Is there a tool you use or 
just paredit in emacs?
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > On Sat, May 18, 2013 at 7:20 AM, Andrew Wagner 
<wagner.andrew@gmail.com (mailto:wagner.andrew@gmail.com)> wrote:
>>>>>>>>>> > > For the data, core.logic is one thing I thought about. 
Another one I was thinking of was datomic, for the scaling and querying 
properties. Whatever we choose, this is one spot where I would want to try
to have a layer of abstraction, so that we can swap it out later. Another 
idea I had in this area was to use the concept of provenance, as talked 
about by Sussman at Strange Loop a couple years ago 
(http://www.infoq.com/presentations/We-Really-Dont-Know-How-To-Compute). 
That could be powerful.
>>>>>>>>>> > >
>>>>>>>>>> > > In terms of parsing questions, yes, I think that OpenNLP 
could be useful. One idea I had would be to have multiple algorithms 
processing the question, and returning both an answer and a confidence. 
Along the lines of the Watson program that played Jeopardy. Maybe with a 
blackboard implementation for communication across threads.
>>>>>>>>>> > >
>>>>>>>>>> > > For web access, I was thinking we might use the new 
Pedestal.io (http://Pedestal.io) to build an async service (possibly with 
a simpler, synchronous side, too). This would give us the ability to hook 
up a number of different clients, including your bot ideas, I think.
>>>>>>>>>> > >
>>>>>>>>>> > >
>>>>>>>>>> > > On Sat, May 18, 2013 at 6:03 AM, i-blis <i-blis@yandex.ru 
(mailto:i-blis@yandex.ru)> wrote:
>>>>>>>>>> > > > Nice idea.
>>>>>>>>>> > > >
>>>>>>>>>> > > > What do you have in mind for the processing? core.logic 
(https://github.com/clojure/core.logic) (for generating and querying 
facts)? Note that core.logic (kind of miniKaren) is really not easy to 
grasp.
>>>>>>>>>> > > >
>>>>>>>>>> > > >
>>>>>>>>>> > > > How would you parse questions? With part-of-speech 
tokenization with, say, OpenNLP 
(https://github.com/dakrone/clojure-opennlp) (link to the Clojure 
wrapper)?
>>>>>>>>>> > > >
>>>>>>>>>> > > > The whole thing could be wrapped within a xmpp or ws bot.
I tried making simple echo xmpp and ws bots, it was pretty straightforward
(although I am sure my Clojure code is awful).
>>>>>>>>>> > > >
>>>>>>>>>> > > > And as Nico said, Clojure is probably easy to refactor. 
Another good thing is that it seems to enforce building small blocks 
first. So one could start with those. And, yes, refactor later.
>>>>>>>>>> > > >
>>>>>>>>>> > > > My two cents.
>>>>>>>>>> > > >
>>>>>>>>>> > > > Greetings, i-blis.
>>>>>>>>>> > > >
>>>>>>>>>> > > >
>>>>>>>>>> > > > On Saturday, 18 May 2013 at 9:46, Nico Balestra wrote:
>>>>>>>>>> > > >
>>>>>>>>>> > > > > Hi Andrew,
>>>>>>>>>> > > > > Thank you for sharing your idea with us. Just 
wondering... Why waiting until we finish reading the book? I think if we 
find a way to stay engaged while reading the book it could be a great way 
to keep the interest alive and participate actively in this group.
>>>>>>>>>> > > > > After all, if we do things in a non idiomatic way we 
can still refactor later... and refactoring Clojure code is so much easy 
than refactoring Java one :)
>>>>>>>>>> > > > > I hope you agree :)
>>>>>>>>>> > > > > Nico,
>>>>>>>>>> > > > > > From BST
>>>>>>>>>> > > > >
>>>>>>>>>> > > > >
>>>>>>>>>> > > > > On 18 May 2013 02:15, "Andrew Wagner" 
<wagner.andrew@gmail.com (mailto:wagner.andrew@gmail.com) 
(mailto:wagner.andrew@gmail.com)> wrote:
>>>>>>>>>> > > > > > All,
>>>>>>>>>> > > > > > I have an idea for a project the group could work on 
after finishing the book. This is something that I've been pondering for a
while, but don't feel like I could make much headway on my own.
>>>>>>>>>> > > > > >
>>>>>>>>>> > > > > > The idea is a question-answering system. You feed it 
text, it converts that text into a series of facts, about which you can 
then ask it questions. I can imagine a number of uses for such a 
capability, and clojure seems like a good fit for it.
>>>>>>>>>> > > > > >
>>>>>>>>>> > > > > > Thoughts?
> 

Re: [foray] Project for the group

From:
Andrew Wagner
Date:
2013-05-18 @ 11:08
Well, I just didn't want to undermine the process of going through the 
book. Other than that, I'm totally cool with starting right away.

On May 18, 2013, at 3:46 AM, Nico Balestra <nicobalestra@gmail.com> wrote:

> Hi Andrew, 
> Thank you for sharing your idea with us. Just wondering... Why waiting 
until we finish reading the book?  I think if we find a way to stay 
engaged while reading the book it could be a great way to keep the 
interest alive and participate actively in this group.
> After all,  if we do things in a non idiomatic way we can still refactor
later... and refactoring Clojure code is so much easy than refactoring 
Java one :)
> 
> I hope you agree :)
> 
> Nico, 
> >From BST
> 
> On 18 May 2013 02:15, "Andrew Wagner" <wagner.andrew@gmail.com> wrote:
>> All,
>> I have an idea for a project the group could work on after finishing 
the book. This is something that I've been pondering for a while, but 
don't feel like I could make much headway on my own.
>> 
>> The idea is a question-answering system. You feed it text, it converts 
that text into a series of facts, about which you can then ask it 
questions. I can imagine a number of uses for such a capability, and 
clojure seems like a good fit for it. 
>> 
>> Thoughts?