Re: Is Clojure right for me?

[Robert Levy]

Mark,

Your comment "Clojure's namespaces are quite limited in ways that
frequently cause me pain" brings to mind Daniel Spiewak's talk on
modularity in functional languages: http://2013.flatmap.no/spiewak.html. It
might be interesting to Massimiliano as well.

Spiewak is actually criticizing Haskell's approach to modules and not
Clojure's but similar criticisms could apply to both. The gist of what he
says is that there are expressive advantages to Scala's decision to treat
modules as first class things.

He then goes on to cite Clojure's protocols as another example of an OO
abstraction improving modularity in an FP language, but that's not news
here.

Rob


On Thu, Dec 26, 2013 at 7:26 PM, Mark Engelberg wrote:

> One reason it might not be clear what I'm driving it is that in trying to
> create a minimalist example, I used grid dimensions, and in reality, you'd
> probably know right away to put something like that in a data structure,
> and pass it around to all your functions.
>
> Try to imagine that at the beginning of your project, you really do
> believe that you're only going to ever be working with 3x4 grids, and then
> later, you realize that's not the case.
>
> In the early phase, it's very easy to construct a bunch of functions that
> all refer to those shared vars (in my example `rows` and `cols`).  Later,
> when you realize rows and cols can change, making those names parameters is
> a major overhaul to the codebase.  I believe that most Clojurians try to
> delay the refactoring by using `binding` to alter those vars.  But that's a
> fragile strategy, and eventually the code typically needs to be rewritten.
>
>
>
> On Thu, Dec 26, 2013 at 7:04 PM, Mark Engelberg 
> wrote:
>
>> Does this OO pseudocode help clarify at all?
>> https://gist.github.com/Engelberg/8142000
>>
>> On Thu, Dec 26, 2013 at 6:27 PM, Stuart Halloway <
>> stuart.hallo...@gmail.com> wrote:
>>
>>> Hi Mark,
>>>
>>> I am not following your example.  Can you post (pseudocode fine) what a
>>> good OO impl would look like, and why Clojure's defrecords can't do
>>> something similar?
>>>
>>> Stu
>>>
>>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is Clojure right for me?

[Mark Engelberg]

Yes!  This is very much what I'm talking about.  When we talk about why we
don't need classes in Clojure, we're usually talking about how we have
better tools for inheritance, polymorphism, encpasulation, mutable state,
etc.  But classes are also powerful namespaces, and Clojure's namespaces
aren't rich enough to make me stop missing those sorts of useful aspects of
classes.  Spiewak gives some really great examples in his talk.  Thanks for
the link.


On Fri, Dec 27, 2013 at 2:10 AM, Robert Levy  wrote:

> Mark,
>
> Your comment "Clojure's namespaces are quite limited in ways that
> frequently cause me pain" brings to mind Daniel Spiewak's talk on
> modularity in functional languages: http://2013.flatmap.no/spiewak.html.
> It might be interesting to Massimiliano as well.
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is Clojure right for me?

[Walter van der Laan]

First, regarding OO. When programming Clojure I never think about adding 
objects to the application, I think "how can I extend the language so it is 
better tailored to my application domain?". And for a lot of domains good 
libraries are already available. So, for the example that you gave I would 
first look at core.matrix https://github.com/mikera/core.matrix. It does 
something which objects can't do; it adds matrices to the language in a 
very natural way.

Second, regarding cyclic dependencies. When programming Clojure I think 
about how data (EDN) flows through my application. Because of this my 
namespaces usually depend on the structure of the data. My namespaces 
rarely depend on namespaces other that those that provide the additional 
language elements that I need (like e.g. core.matrix, core.async, ...). 
This does raise a new problem "how do I check the validity of the data 
flowing in and out of namespaces?". There were several presentations at 
Clojure/conj that addressed this problem. But overall I find this approach 
to work very well, even for large applications, because namespaces are 
highly decoupled and easy to test.

Those are the "tricks" that I use. But I must admit that it has taken me 
many iterations to slowly improve my code. Old habits die hard.

On Friday, December 27, 2013 3:08:04 AM UTC+1, puzzler wrote:
>
> I do like the way Clojure steers you away from all sorts of unnecessary 
> OO-nonsense, and provides most of the raw capabilities of OO in other forms.
>
> However, even if you avoid mutable state, inheritance, and polymorphism, 
> Classes/objects make great namespaces, and Clojure's namespaces can't do 
> everything classes can do, for example, cyclic dependencies.  This was the 
> subject of my blog post yesterday.  Take a look at the following gist code 
> for one of the scenarios that frequently drives me up a wall:
>
> https://gist.github.com/Engelberg/8141352
>
> I'd love to hear any tricks you guys use to deal with situations like this 
> in your own code.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Finding available methods or docs for a value type

[Niels van Klaveren]

Anthony Grimes made a find-fn  that finds 
functions based on input parameters and output functions.

So something like (find-fn clojure.core [1 2] {:a 1 :b 2}) would return 
vals and (find-fn clojure.core [:a :b] {:a 1 :b 2}) would return keys.

It would be great if we would have an online version that could do that. 
The biggest problem would be how to specify which namespaces (from clojars 
available libraries ?) you'd want to have searched.


On Tuesday, December 24, 2013 2:58:29 PM UTC+1, John Kida wrote:
>
> So i am very new to Clojure and I am wondering if there are any good 
> techniques to finding available methods that will take a particular value. 
> I understand this is probably very hard to do or even impossible being 
> Clojure is a dynamic language and a lisp but for example.
>
> Lets say i have a simple map data structure. Being new to Clojure i just 
> start fiddling with the REPL, and try:
> (keys my-hmap)
> cool, got the keys from my map back. 
>
> Now how about values
> (values my-hmap)
>
> nope. wrong method name..  I was able to quickly find it in the Clojure 
> Data Structures documentation, where it had a few method names for 
> examining a Map, and linked me to the Clojure Core API, is this something I 
> should probably go through start to finish, so I have a good idea of what 
> is available.
>
> Or is there some technique I can use in the repl to tell me what methods 
> are available to work with this particular datastructure.. that sounds not 
> possible due to the dynamic lisp nature of clojure, but I wanted to ask the 
> community to see if there were some good strategies to learning and finding 
> available methods to work with a particular value.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Finding available methods or docs for a value type

[Matching Socks]

How does it do that?!

>From the README at the linked page:  "what it does is take input arguments 
and an expected output, and it tries out every function and macro in a set 
of namespaces, collecting the names of the ones that produce the output for 
the input arguments passed."

Cool!  But... let's hope they read the README before using find-fn at the 
nuclear plant.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is Clojure right for me?

[Massimiliano Tomassoli]

The point is that Clojure is not the only modern language out there. I 
can't possibly learn them all in depth just to decide which language to use 
for my production code. That would be time-inefficient because my goal in 
not to learn languages, but to pick up a new language suitable for my needs.

On Friday, December 27, 2013 3:04:18 AM UTC+1, Luc wrote:
>
> This depends strictly on your learning speed which I will 
> not comment here :) 
>
> It took me three months full time to start to feel at ease with 
> Clojure writing production code and I was around 45 years 
> old at the time. 
>
> Learning is never inefficient... when you want to learn. 
>
> Luc P 
>
>
> > On Thursday, December 26, 2013 11:04:00 PM UTC+1, Luc wrote: 
> > > 
> > > Ok I'll drop the subject. Still cannot understand why people cannot 
> > > try something new w/o sticking to the stuff they know already until 
> they 
> > > are 
> > > totally immersed in the new thing. And by that I mean use the new 
> thing as 
> > > it was intended. 
> > > 
> > > Then you can generate useful conclusions and get some benefits from 
> > > this learning process. 
> > > 
> > 
> > Learning every single language just to find the right one is not very 
> > time-efficient. 
> > 
> > -- 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@googlegroups.com 
> > Note that posts from new members are moderated - please be patient with 
> your first post. 
> > To unsubscribe from this group, send email to 
> > clojure+u...@googlegroups.com  
> > For more options, visit this group at 
> > http://groups.google.com/group/clojure?hl=en 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups "Clojure" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to clojure+u...@googlegroups.com . 
> > For more options, visit https://groups.google.com/groups/opt_out. 
> > 
> -- 
> Luc Prefontaine> sent by ibisMail! 
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is Clojure right for me?

[John Chijioke]

Words play a very important role in expressing ideas. For me, I think 
clojure is mostly about ideas. A way of doing things. For me clojure was 
intuitive from day one. The notion of programming with functions applied to 
data. So in clojure data structures are emphasized as a way of representing 
data as opposed to classes which Rich Hickey has argued as using mechanical 
things(classes) for the wrong purpose. Because of this we have words like: 
pure functions, higher order functions, which many OOP language has just 
started adopting; closures, which are analogous to objects in OOP but are 
sanely done with the help of immutability; data structures as opposed to 
using classes to track numerous variables in the name of data; composition 
rather than inheritance because the *complect* control. And a number of 
other ideas. 

You just have to take a deep breadth and accept you are about to look at 
things a bit more mathematically using functions as the major tool for 
designing machines. Don't resort to familiarity as that will prevent you 
from learning new things and trust me you have a whole lot to unlearn. But 
if you stick with the community you can learn fast seeing you already a 
programmer.

With regard to frameworks I agree it's about composition of libraries 
that's where you get the most power and less problem because of all this 
immutability thing. Dive in and start applying it on something real and 
before long you will be glad you did and ready to bring others on board. 

On Wednesday, December 25, 2013 10:06:20 PM UTC+1, Massimiliano Tomassoli 
wrote:
>
> Hi,
> I'm not sure if Clojure is the right language for me. I'd like to use 
> Clojure mainly for web development but I don't know if it's already mature 
> enough to be productive. For instance, Scala has Play, Groovy has Grails, 
> etc... If I'm not wrong, Clojure doesn't have a well-established framework 
> for web development. I'm intrigued by Clojure because I like functional 
> programming, but I need to be productive and, alas, I don't have time to 
> learn Clojure just for my pleasure.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Akka-like framework in Clojure ?

[Eric Le Goff]

Hi,

After a long background with imperative languages such as Java, I recently
spent some time learning functionnal programming, starting with Scala. I
had the opporrtunity to build a demo project based on the Akka framework.

Now I am starting learning Clojure, and would be curious to know if there
was some clojure based framework available which could implement rather
similar features to Akka.

In particular, I would be interested in an implementation of the Actor
Model [1]

Thanks.

Eric


[1] http://en.wikipedia.org/wiki/Actor_model

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Akka-like framework in Clojure ?

[Tim Visher]

Hi Eric,

On Fri, Dec 27, 2013 at 3:54 AM, Eric Le Goff  wrote:
> After a long background with imperative languages such as Java, I recently
> spent some time learning functionnal programming, starting with Scala. I had
> the opporrtunity to build a demo project based on the Akka framework.
>
> Now I am starting learning Clojure, and would be curious to know if there
> was some clojure based framework available which could implement rather
> similar features to Akka.

I know of no such library for Clojure specifically (although I did not
look and have never needed to), but it appears that Akka is a Java
library, so worst comes to worst you could use it via [interop][1].

[1]: http://clojure.org/java_interop

--

In Christ,

Timmy V.

http://blog.twonegatives.com/
http://five.sentenc.es/ -- Spend less time on mail

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is Clojure right for me?

[Luc Prefontaine]

Then we have more in common
than you may think :)

I learned Ruby first, went through
Scala which appeared in the same 
time frame,
all this to pick up the language of 
choice to replace Java and Ruby
which we used to prototype our 
product.

All this took around 9 months 
including the time to get the prototype
working.

Choose carefully... :)

Luc P.

> The point is that Clojure is not the only modern language out there. I 
> can't possibly learn them all in depth just to decide which language to use 
> for my production code. That would be time-inefficient because my goal in 
> not to learn languages, but to pick up a new language suitable for my needs.
> 
> On Friday, December 27, 2013 3:04:18 AM UTC+1, Luc wrote:
> >
> > This depends strictly on your learning speed which I will 
> > not comment here :) 
> >
> > It took me three months full time to start to feel at ease with 
> > Clojure writing production code and I was around 45 years 
> > old at the time. 
> >
> > Learning is never inefficient... when you want to learn. 
> >
> > Luc P 
> >
> >
> > > On Thursday, December 26, 2013 11:04:00 PM UTC+1, Luc wrote: 
> > > > 
> > > > Ok I'll drop the subject. Still cannot understand why people cannot 
> > > > try something new w/o sticking to the stuff they know already until 
> > they 
> > > > are 
> > > > totally immersed in the new thing. And by that I mean use the new 
> > thing as 
> > > > it was intended. 
> > > > 
> > > > Then you can generate useful conclusions and get some benefits from 
> > > > this learning process. 
> > > > 
> > > 
> > > Learning every single language just to find the right one is not very 
> > > time-efficient. 
> > > 
> > > -- 
> > > -- 
> > > You received this message because you are subscribed to the Google 
> > > Groups "Clojure" group. 
> > > To post to this group, send email to clo...@googlegroups.com 
> > > Note that posts from new members are moderated - please be patient with 
> > your first post. 
> > > To unsubscribe from this group, send email to 
> > > clojure+u...@googlegroups.com  
> > > For more options, visit this group at 
> > > http://groups.google.com/group/clojure?hl=en 
> > > --- 
> > > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > > To unsubscribe from this group and stop receiving emails from it, send 
> > an email to clojure+u...@googlegroups.com . 
> > > For more options, visit https://groups.google.com/groups/opt_out. 
> > > 
> > -- 
> > Luc Prefontaine> sent by ibisMail! 
> >
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
--
Luc Prefontaine sent by ibisMail!

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Finding available methods or docs for a value type

[Tim Visher]

On Fri, Dec 27, 2013 at 6:27 AM, Niels van Klaveren
 wrote:
> Anthony Grimes made a find-fn that finds functions based on input parameters
> and output functions.
>
> So something like (find-fn clojure.core [1 2] {:a 1 :b 2}) would return vals
> and (find-fn clojure.core [:a :b] {:a 1 :b 2}) would return keys.
>
> It would be great if we would have an online version that could do that. The
> biggest problem would be how to specify which namespaces (from clojars
> available libraries ?) you'd want to have searched.

That's the one! :)

Someone also put together a hosted version if you're looking to just
try it out.

http://findfn.herokuapp.com/

--

In Christ,

Timmy V.

http://blog.twonegatives.com/
http://five.sentenc.es/ -- Spend less time on mail

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is Clojure right for me?

[Stuart Halloway]

Yes, thanks Mark. It seems to me that you are saying "namespaces make poor
maps".  Stipulated.  So why not use records or maps?

I think that where my experience differs from yours is summarized in your
comment "In Clojure, a project often begins with a bunch of functions
sharing some immutable state or "magic constants" stored in vars." I
*never* do that.  If there are a group of related things, I put them in an
associative container (maybe just a map) on day one.

The analogy with OO is misleading here.  If you started an OO project
putting everything in static/singleton members, you would have the same
pain you attribute to Clojure's namespaces.

I find this to be a "my car doesn't have wings" argument, and the kind of
thing that leads into casually complecting everything with everything else.

Stu




On Thu, Dec 26, 2013 at 10:04 PM, Mark Engelberg
wrote:

> Does this OO pseudocode help clarify at all?
> https://gist.github.com/Engelberg/8142000
>
> On Thu, Dec 26, 2013 at 6:27 PM, Stuart Halloway <
> stuart.hallo...@gmail.com> wrote:
>
>> Hi Mark,
>>
>> I am not following your example.  Can you post (pseudocode fine) what a
>> good OO impl would look like, and why Clojure's defrecords can't do
>> something similar?
>>
>> Stu
>>
>>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is Clojure right for me?

[Luc Prefontaine]

I would add that you *need* to
write some code to get a feeling
about a new language.

Feature comparisons may help you up
to a certain degree. However deciding about how efficient
you may become using a new language requires you to dive at
least a bit into it. Not all brains are  wired the same.

Luc P.

> Then we have more in common
> than you may think :)
> 
> I learned Ruby first, went through
> Scala which appeared in the same 
> time frame,
> all this to pick up the language of 
> choice to replace Java and Ruby
> which we used to prototype our 
> product.
> 
> All this took around 9 months 
> including the time to get the prototype
> working.
> 
> Choose carefully... :)
> 
> Luc P.
> 
> > The point is that Clojure is not the only modern language out there. I 
> > can't possibly learn them all in depth just to decide which language to use 
> > for my production code. That would be time-inefficient because my goal in 
> > not to learn languages, but to pick up a new language suitable for my needs.
> > 
> > On Friday, December 27, 2013 3:04:18 AM UTC+1, Luc wrote:
> > >
> > > This depends strictly on your learning speed which I will 
> > > not comment here :) 
> > >
> > > It took me three months full time to start to feel at ease with 
> > > Clojure writing production code and I was around 45 years 
> > > old at the time. 
> > >
> > > Learning is never inefficient... when you want to learn. 
> > >
> > > Luc P 
> > >
> > >
> > > > On Thursday, December 26, 2013 11:04:00 PM UTC+1, Luc wrote: 
> > > > > 
> > > > > Ok I'll drop the subject. Still cannot understand why people cannot 
> > > > > try something new w/o sticking to the stuff they know already until 
> > > they 
> > > > > are 
> > > > > totally immersed in the new thing. And by that I mean use the new 
> > > thing as 
> > > > > it was intended. 
> > > > > 
> > > > > Then you can generate useful conclusions and get some benefits from 
> > > > > this learning process. 
> > > > > 
> > > > 
> > > > Learning every single language just to find the right one is not very 
> > > > time-efficient. 
> > > > 
> > > > -- 
> > > > -- 
> > > > You received this message because you are subscribed to the Google 
> > > > Groups "Clojure" group. 
> > > > To post to this group, send email to 
> > > > clo...@googlegroups.com 
> > > > Note that posts from new members are moderated - please be patient with 
> > > your first post. 
> > > > To unsubscribe from this group, send email to 
> > > > clojure+u...@googlegroups.com  
> > > > For more options, visit this group at 
> > > > http://groups.google.com/group/clojure?hl=en 
> > > > --- 
> > > > You received this message because you are subscribed to the Google 
> > > Groups "Clojure" group. 
> > > > To unsubscribe from this group and stop receiving emails from it, send 
> > > an email to clojure+u...@googlegroups.com . 
> > > > For more options, visit https://groups.google.com/groups/opt_out. 
> > > > 
> > > -- 
> > > Luc Prefontaine> sent by ibisMail! 
> > >
> > 
> > -- 
> > -- 
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > --- 
> > You received this message because you are subscribed to the Google Groups 
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
> > 
> --
> Luc Prefontaine sent by ibisMail!
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
--
Luc Prefontaine sent by ibisMail!

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/g

Re: Akka-like framework in Clojure ?

[Jan Herich]

Hi Eric,

Maybe pulsar  is what you are looking 
for, but i recommend you to also discover the other way of doing 
concurrency in clojure instead of the actor model -> have a look at 
CSP and 
its clojure implementation the the form of the core library called 
core.async

Dňa piatok, 27. decembra 2013 9:54:16 UTC+1 Eric Le Goff napísal(-a):
>
>
> Hi,
>
> After a long background with imperative languages such as Java, I recently 
> spent some time learning functionnal programming, starting with Scala. I 
> had the opporrtunity to build a demo project based on the Akka framework.
>
> Now I am starting learning Clojure, and would be curious to know if there 
> was some clojure based framework available which could implement rather 
> similar features to Akka. 
>
> In particular, I would be interested in an implementation of the Actor 
> Model [1]
>
> Thanks.
>
> Eric
>
>
> [1] http://en.wikipedia.org/wiki/Actor_model
>  

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is Clojure right for me?

[Massimiliano Tomassoli]

On Friday, December 27, 2013 7:29:22 AM UTC+1, Sean Corfield wrote:
>
> On Thu, Dec 26, 2013 at 8:32 AM, Massimiliano Tomassoli 
> > How do you decompose large systems in Clojure? 
>
> I'm curious as to why you think only OOP allows you to decompose large 
> systems? Between namespaces, protocols, multimethods, ad hoc 
> hierarchies, and higher order functions, Clojure has a lot of tools 
> for organizing code... 
>
>
I've never claimed that OOP is the only way to decompose large systems, but 
since Clojure doesn't support OOP and many languages are multi-paradigm 
nowadays, I was wondering how you modularize systems in a language which is 
purely functional.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Akka-like framework in Clojure ?

[Tibor Mlynarik]

Hi Eric,

I haven't tried it's Clojure api, but Quasar/Pulsar [1] looks promising.
https://groups.google.com/forum/#!msg/clojure/1xxxTti6Vi0/m9HtBXankzUJ

cheers,

 Tibor

[1] http://puniverse.github.io/pulsar/ 

On Friday, December 27, 2013 9:54:16 AM UTC+1, Eric Le Goff wrote:
>
>
> Hi,
>
> After a long background with imperative languages such as Java, I recently 
> spent some time learning functionnal programming, starting with Scala. I 
> had the opporrtunity to build a demo project based on the Akka framework.
>
> Now I am starting learning Clojure, and would be curious to know if there 
> was some clojure based framework available which could implement rather 
> similar features to Akka. 
>
> In particular, I would be interested in an implementation of the Actor 
> Model [1]
>
> Thanks.
>
> Eric
>
>
> [1] http://en.wikipedia.org/wiki/Actor_model
>  

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is Clojure right for me?

[Massimiliano Tomassoli]

I've seen Clojure in action and I know it's extremely concise and 
expressive. What I wanted to know is how it copes with complexity when you 
develop complex systems. You can't get an idea of that just by writing some 
code and getting a feeling about the language, IMHO. When I studied OOP at 
University my professors taught me that OOP was extremely successful in 
reducing the complexity of big systems. I was given many examples of that 
in the many courses of software engineering I took. FP was relegated to 
some theoretical courses about paradigms. With such a background it's not 
easy to accept some of the things the Clojure community claim. The fact 
that I'm here asking questions should mean that I'm more open minded than 
most :) But please understand where I'm coming from.

On Friday, December 27, 2013 3:50:23 PM UTC+1, Luc wrote:
>
> I would add that you *need* to 
> write some code to get a feeling 
> about a new language. 
>
> Feature comparisons may help you up 
> to a certain degree. However deciding about how efficient 
> you may become using a new language requires you to dive at 
> least a bit into it. Not all brains are  wired the same. 
>
> Luc P. 
>
> > Then we have more in common 
> > than you may think :) 
> > 
> > I learned Ruby first, went through 
> > Scala which appeared in the same 
> > time frame, 
> > all this to pick up the language of 
> > choice to replace Java and Ruby 
> > which we used to prototype our 
> > product. 
> > 
> > All this took around 9 months 
> > including the time to get the prototype 
> > working. 
> > 
> > Choose carefully... :) 
> > 
> > Luc P. 
> > 
> > > The point is that Clojure is not the only modern language out there. I 
> > > can't possibly learn them all in depth just to decide which language 
> to use 
> > > for my production code. That would be time-inefficient because my goal 
> in 
> > > not to learn languages, but to pick up a new language suitable for my 
> needs. 
> > > 
> > > On Friday, December 27, 2013 3:04:18 AM UTC+1, Luc wrote: 
> > > > 
> > > > This depends strictly on your learning speed which I will 
> > > > not comment here :) 
> > > > 
> > > > It took me three months full time to start to feel at ease with 
> > > > Clojure writing production code and I was around 45 years 
> > > > old at the time. 
> > > > 
> > > > Learning is never inefficient... when you want to learn. 
> > > > 
> > > > Luc P 
> > > > 
> > > > 
> > > > > On Thursday, December 26, 2013 11:04:00 PM UTC+1, Luc wrote: 
> > > > > > 
> > > > > > Ok I'll drop the subject. Still cannot understand why people 
> cannot 
> > > > > > try something new w/o sticking to the stuff they know already 
> until 
> > > > they 
> > > > > > are 
> > > > > > totally immersed in the new thing. And by that I mean use the 
> new 
> > > > thing as 
> > > > > > it was intended. 
> > > > > > 
> > > > > > Then you can generate useful conclusions and get some benefits 
> from 
> > > > > > this learning process. 
> > > > > > 
> > > > > 
> > > > > Learning every single language just to find the right one is not 
> very 
> > > > > time-efficient. 
> > > > > 
> > > > > -- 
> > > > > -- 
> > > > > You received this message because you are subscribed to the Google 
> > > > > Groups "Clojure" group. 
> > > > > To post to this group, send email to 
> > > > > clo...@googlegroups.com 
>
> > > > > Note that posts from new members are moderated - please be patient 
> with 
> > > > your first post. 
> > > > > To unsubscribe from this group, send email to 
> > > > > clojure+u...@googlegroups.com  
> > > > > For more options, visit this group at 
> > > > > http://groups.google.com/group/clojure?hl=en 
> > > > > --- 
> > > > > You received this message because you are subscribed to the Google 
> > > > Groups "Clojure" group. 
> > > > > To unsubscribe from this group and stop receiving emails from it, 
> send 
> > > > an email to clojure+u...@googlegroups.com . 
> > > > > For more options, visit https://groups.google.com/groups/opt_out. 
> > > > > 
> > > > -- 
> > > > Luc Prefontaine> sent by 
> ibisMail! 
> > > > 
> > > 
> > > -- 
> > > -- 
> > > You received this message because you are subscribed to the Google 
> > > Groups "Clojure" group. 
> > > To post to this group, send email to clo...@googlegroups.com 
> > > Note that posts from new members are moderated - please be patient 
> with your first post. 
> > > To unsubscribe from this group, send email to 
> > > clojure+u...@googlegroups.com  
> > > For more options, visit this group at 
> > > http://groups.google.com/group/clojure?hl=en 
> > > --- 
> > > You received this message because you are subscribed to the Google 
> Groups "Clojure" group. 
> > > To unsubscribe from this group and stop receiving emails from it, send 
> an email to clojure+u...@googlegroups.com . 
> > > For more options, visit https://groups.google.com/groups/opt_out. 
> > > 
> > -- 
> > Luc Prefontaine> sent by 
> ibisMail! 
> > 
> > -- 
> > -- 
> > You received this message beca

Re: Is Clojure right for me?

[Malcolm Sparks]

I modularize my Clojure systems using Jig: https://github.com/juxt/jig -
it's one of many possible approaches.


On 27 December 2013 15:23, Massimiliano Tomassoli wrote:

> On Friday, December 27, 2013 7:29:22 AM UTC+1, Sean Corfield wrote:
>
>> On Thu, Dec 26, 2013 at 8:32 AM, Massimiliano Tomassoli
>> > How do you decompose large systems in Clojure?
>>
>> I'm curious as to why you think only OOP allows you to decompose large
>> systems? Between namespaces, protocols, multimethods, ad hoc
>> hierarchies, and higher order functions, Clojure has a lot of tools
>> for organizing code...
>>
>>
> I've never claimed that OOP is the only way to decompose large systems,
> but since Clojure doesn't support OOP and many languages are multi-paradigm
> nowadays, I was wondering how you modularize systems in a language which is
> purely functional.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/zwhpqptqV1A/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is Clojure right for me?

[Softaddicts]

It took us some time to structure the code at the time and now
with protocols we went under a other restructuring a year ago. 

I agree this part can be hard (structuring the code) but at the time we started 
protocols were not yet there hence some of the restructuring.
Best practices also evolved for a couple of years.
It's much more stable these days.

When I say write some code, well you need to choose a domain
aside from simple things like "hello world". Which makes it harder
to write some code :) but forces you to question yourself about
how to do this right the first time.


This is the list of my favorite  items that I keep an eye on:

a) abstractions, choose them according to your business domain, do not
try to re-invent the wheel or create alien terminology.
This is a starting point to get your name space structure right.

b) In your APIs try to stay generic by not assuming implementation details.
This step can be hard to achieve. Keep doors opened. 

c) You may want to redefine the implementations of
your abstractions or provide different flavors or some flexibility in your 
APIs.
Protocols/multimethods become handy at some point here.
This is the part that may feel a bit like OO but this is the one you have to
think last. (remember point a and b)

d) Do not hesitate to refactor. There's less code than in most other languages
that get some support for refactoring from their IDE so you should not
wait until it becomes a mess. If a name space is not rightly named anymore,
chane it. If more separation of concerns is required, add/change name
spaces accordingly and reorg the code.

e) A good indicator of the stability of your APIs is how much your test code
gets messed up when you do change something. It could be
related to implementation details leaking out, bad choice in name space
design, 

I am not an advocate of TDD but at some point when the code of a
name space is stable enough, a few test cases can be used as 
health signs. 

f) Search for existing librairies, there are enough of them out there,
   either Java libs with/wo Clojure wrappers or Clojure centric ones
   to speed you up not having to rewrite the universe.

g) Read the code of the libs you are pulling in as you go along.
This will probably light a bulb in your brain about tricks you should
apply to your code.

The above should sound familiar :) It's not that different in Clojure to me
than in many other languages.

If you have some specific concerns, send them to me off line.
I may share some code privately to answer some of your questions.
Sorry for the other folks on this thread but there are copyright issues here :)

Luc P.

> I've seen Clojure in action and I know it's extremely concise and 
> expressive. What I wanted to know is how it copes with complexity when you 
> develop complex systems. You can't get an idea of that just by writing some 
> code and getting a feeling about the language, IMHO. When I studied OOP at 
> University my professors taught me that OOP was extremely successful in 
> reducing the complexity of big systems. I was given many examples of that 
> in the many courses of software engineering I took. FP was relegated to 
> some theoretical courses about paradigms. With such a background it's not 
> easy to accept some of the things the Clojure community claim. The fact 
> that I'm here asking questions should mean that I'm more open minded than 
> most :) But please understand where I'm coming from.
> 
> On Friday, December 27, 2013 3:50:23 PM UTC+1, Luc wrote:
> >
> > I would add that you *need* to 
> > write some code to get a feeling 
> > about a new language. 
> >
> > Feature comparisons may help you up 
> > to a certain degree. However deciding about how efficient 
> > you may become using a new language requires you to dive at 
> > least a bit into it. Not all brains are  wired the same. 
> >
> > Luc P. 
> >
> > > Then we have more in common 
> > > than you may think :) 
> > > 
> > > I learned Ruby first, went through 
> > > Scala which appeared in the same 
> > > time frame, 
> > > all this to pick up the language of 
> > > choice to replace Java and Ruby 
> > > which we used to prototype our 
> > > product. 
> > > 
> > > All this took around 9 months 
> > > including the time to get the prototype 
> > > working. 
> > > 
> > > Choose carefully... :) 
> > > 
> > > Luc P. 
> > > 
> > > > The point is that Clojure is not the only modern language out there. I 
> > > > can't possibly learn them all in depth just to decide which language 
> > to use 
> > > > for my production code. That would be time-inefficient because my goal 
> > in 
> > > > not to learn languages, but to pick up a new language suitable for my 
> > needs. 
> > > > 
> > > > On Friday, December 27, 2013 3:04:18 AM UTC+1, Luc wrote: 
> > > > > 
> > > > > This depends strictly on your learning speed which I will 
> > > > > not comment here :) 
> > > > > 
> > 

Re: Is Clojure right for me?

[Mars0i]

On Friday, December 27, 2013 10:02:46 AM UTC-6, Massimiliano Tomassoli 
wrote:
>
> I've seen Clojure in action and I know it's extremely concise and 
> expressive. What I wanted to know is how it copes with complexity when you 
> develop complex systems. 
>

My intuition is that getting rid of or reducing mutable state by itself 
reduces some of the problems of complexity.  I'm not against 
mutability--some things are a lot easier with it--but it's also one of the 
motivations for modularizing code.  One of the purposes of OO is to reduce 
and constrain dependence on state elsewhere. 

This is not a full answer because there's still a need for making code 
modular even with immutability, and because although I've programmed in an 
FP spirit for a long time, it's only recently, when I started learning 
Clojure, that I've tried to be more pure about FP.  So others will have 
more insight into what I suggest above.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Namespaces [was Re: Is Clojure right for me?]

[Mark Engelberg]

I ended up accidentally injecting a completely different thread of
discussion into the "Is Clojure right for me?" thread.  I'm breaking it
into a separate thread here.

Here's where we left off:

On Fri, Dec 27, 2013 at 6:34 AM, Stuart Halloway
wrote:

> Yes, thanks Mark. It seems to me that you are saying "namespaces make poor
> maps".  Stipulated.  So why not use records or maps?
>
>
This is close, but not exactly what I'm saying.  It's not so much about
wanting namespaces to be maps.  It's about wanting a robust mechanism for
functions to share information other than threading that information
through the functions.

In Structure and Interpretation of Computer Programming, a large chunk of
the programs are written in a pseudo-object-oriented style, a style which
simulates objects by having functions' closures share the same local
context.

Sure, you could do that with maps:

For example:

(defn create-functions [init-info]
   (let [shared-info init-info]
  {:foo (fn foo [x] ... body uses shared-info in some way ...),
   :bar (fn bar [x] ... body uses shared-info in some way ..)}))

Then, to access these functions, you'd do something like this:
(def instance (create-functions default-info))
((:foo instance) 2)  ; the equivalent of instance.foo(2) in OO
((:bar instance) 3)  ; the equivalent of instance.bar(3) in OO

Of course, SICP's main point is that even bare-bones Scheme is rich enough
to simulate objects, but the other point is that it is important for
functions to be able to share stat*e* which can be initialized for a group
of functions,

*even if that state is immutable.*
The above pattern is important enough that most languages provide some kind
of mechanism for doing that. Classes are one such pattern.

In Clojure, the above code would be horribly un-idiomatic of course.
Actually, depending on the functions and definitions, it might not even be
possible to structure the code that way (because Clojure's local definition
capabilities are not as rich as what is possible at the global level, for
example, regarding mutual references -- in some contexts, letfn might help,
but not all contexts).

The above example uses associative containers for the shared-info, and
associative containers to hold the group of related functions that are
outputted, but that doesn't make this solution any more attractive --
again, emphasizing that this is not about associative containers.

I claim that Clojure only provides two idiomatic solutions to the above
problem of functions sharing the same immutable information, which might
need to be set prior to using those functions:

Solution 1:

(def ^:dynamic shared-info default-info)
(defn foo [x] ... body uses shared-info)
(defn bar [x] ... body uses shared-info)

Call these functions via:

(foo 2) and (bar 3) if you're happy with the defaults or

(binding [shared-info info] (foo 2)) and
(binding [shared-info info] (bar 3)) otherwise.

This is awkward for several reasons, and sometimes this solution isn't
really an option since functions that return lazy structures won't work
with the above mechanism.

Solution 2:

(defn foo [shared-info x] ... body uses shared-info)
(defn bar [shared-info x] ... body uses shared-info)

Call these functions via:

(foo info 2)
(bar info 3)


My argument is that both these solutions are unsatisfying.  Solution 2 is
irritating because if you use a map for shared-info, you end up having to
repeat the destructuring in every single function.  Also, you need to
thread this information through all the functions, not only the functions
that directly use, but also the functions that call other functions that
use it.  It makes all the functions bulky and awkward, and at the end of
that, you still don't have something that reflects the notion of getting
back a group of functions that share the *same* info -- instead, you have
to remember to always pass in that same info with every function call.
Also, with the threading-the-state version, you don't have a convenient
notion of "default state", unless you are willing to take cases on the
number of arguments for every single one of your functions.

My other claim is that "Solution 2" feels too heavy-handed for small
projects, or scenarios where it isn't clear you'll ever want to initialize
the shared-info to something other than the defaults, but the path of
transition from Solution 1 to Solution 2 is a painful one.


I think that where my experience differs from yours is summarized in your
> comment "In Clojure, a project often begins with a bunch of functions
> sharing some immutable state or "magic constants" stored in vars." I
> *never* do that.  If there are a group of related things, I put them in an
> associative container (maybe just a map) on day one.
>

Even if you share all those constants in an immutable container, I maintain
that the threading of that information through all the functions can be
awkward.


>
> The analogy with OO is misleading here.  If you started an OO project
> pu

Re: Namespaces [was Re: Is Clojure right for me?]

[john walker]

I posted this in response to the original gist, but it probably wasn't 
seen. Does this demonstrate the behavior you want?

https://gist.github.com/johnwalker/8142143


On Friday, December 27, 2013 1:08:49 PM UTC-5, puzzler wrote:
>
> I ended up accidentally injecting a completely different thread of 
> discussion into the "Is Clojure right for me?" thread.  I'm breaking it 
> into a separate thread here.
>
> Here's where we left off:
>
> On Fri, Dec 27, 2013 at 6:34 AM, Stuart Halloway 
> 
> > wrote:
>
>> Yes, thanks Mark. It seems to me that you are saying "namespaces make 
>> poor maps".  Stipulated.  So why not use records or maps?
>>
>>
> This is close, but not exactly what I'm saying.  It's not so much about 
> wanting namespaces to be maps.  It's about wanting a robust mechanism for 
> functions to share information other than threading that information 
> through the functions.  
>
> In Structure and Interpretation of Computer Programming, a large chunk of 
> the programs are written in a pseudo-object-oriented style, a style which 
> simulates objects by having functions' closures share the same local 
> context.
>
> Sure, you could do that with maps:
>
> For example:
>
> (defn create-functions [init-info]
>(let [shared-info init-info]
>   {:foo (fn foo [x] ... body uses shared-info in some way ...),
>:bar (fn bar [x] ... body uses shared-info in some way ..)}))
>
> Then, to access these functions, you'd do something like this:
> (def instance (create-functions default-info))
> ((:foo instance) 2)  ; the equivalent of instance.foo(2) in OO
> ((:bar instance) 3)  ; the equivalent of instance.bar(3) in OO
>
> Of course, SICP's main point is that even bare-bones Scheme is rich enough 
> to simulate objects, but the other point is that it is important for 
> functions to be able to share stat*e* which can be initialized for a 
> group of functions, 
>
> *even if that state is immutable. *
> The above pattern is important enough that most languages provide some 
> kind of mechanism for doing that. Classes are one such pattern.
>
> In Clojure, the above code would be horribly un-idiomatic of course.  
> Actually, depending on the functions and definitions, it might not even be 
> possible to structure the code that way (because Clojure's local definition 
> capabilities are not as rich as what is possible at the global level, for 
> example, regarding mutual references -- in some contexts, letfn might help, 
> but not all contexts).
>
> The above example uses associative containers for the shared-info, and 
> associative containers to hold the group of related functions that are 
> outputted, but that doesn't make this solution any more attractive -- 
> again, emphasizing that this is not about associative containers.
>
> I claim that Clojure only provides two idiomatic solutions to the above 
> problem of functions sharing the same immutable information, which might 
> need to be set prior to using those functions:
>
> Solution 1:
>
> (def ^:dynamic shared-info default-info)
> (defn foo [x] ... body uses shared-info)
> (defn bar [x] ... body uses shared-info)
>
> Call these functions via:
>
> (foo 2) and (bar 3) if you're happy with the defaults or
>
> (binding [shared-info info] (foo 2)) and
> (binding [shared-info info] (bar 3)) otherwise.
>
> This is awkward for several reasons, and sometimes this solution isn't 
> really an option since functions that return lazy structures won't work 
> with the above mechanism.  
>
> Solution 2:
>
> (defn foo [shared-info x] ... body uses shared-info)
> (defn bar [shared-info x] ... body uses shared-info)
>
> Call these functions via:
>
> (foo info 2)
> (bar info 3)
>
>
> My argument is that both these solutions are unsatisfying.  Solution 2 is 
> irritating because if you use a map for shared-info, you end up having to 
> repeat the destructuring in every single function.  Also, you need to 
> thread this information through all the functions, not only the functions 
> that directly use, but also the functions that call other functions that 
> use it.  It makes all the functions bulky and awkward, and at the end of 
> that, you still don't have something that reflects the notion of getting 
> back a group of functions that share the *same* info -- instead, you have 
> to remember to always pass in that same info with every function call.  
> Also, with the threading-the-state version, you don't have a convenient 
> notion of "default state", unless you are willing to take cases on the 
> number of arguments for every single one of your functions.
>
> My other claim is that "Solution 2" feels too heavy-handed for small 
> projects, or scenarios where it isn't clear you'll ever want to initialize 
> the shared-info to something other than the defaults, but the path of 
> transition from Solution 1 to Solution 2 is a painful one.
>
>
> I think that where my experience differs from yours is summarized in your 
>> comment "In Clojure, a project often 

Re: Namespaces [was Re: Is Clojure right for me?]

[Cedric Greevey]

On Fri, Dec 27, 2013 at 1:08 PM, Mark Engelberg wrote:
>
> Solution 2:
>
> (defn foo [shared-info x] ... body uses shared-info)
> (defn bar [shared-info x] ... body uses shared-info)
>
> Call these functions via:
>
> (foo info 2)
> (bar info 3)
>

In what way is this any worse than

info.foo(2);
info.bar(3);

which is how OO would do this with methods foo and bar of a common class
with an instance "info" having private data? Only the punctuation and VSO
vs. SVO word order differ here.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is Clojure right for me?

[Sean Corfield]

On Fri, Dec 27, 2013 at 8:02 AM, Massimiliano Tomassoli
 wrote:
> When I studied OOP at
> University my professors taught me that OOP was extremely successful in
> reducing the complexity of big systems.

That's always been the claim about OOP but big systems have an
inherent complexity and you can never reduce that - you can just push
it around in the system and give the illusion of hiding it. But it's
still there. Having done decades of OOP as well as quite a bit of FP
both before and after, I don't find OOP to be any more successful at
_reducing_ complexity in the real world.

> I was given many examples of that in
> the many courses of software engineering I took.

Hmm, I've never known any courses that deal with "big systems"
although many of them discussion the _theory_ of dealing with big
systems.

> FP was relegated to some
> theoretical courses about paradigms.

That's unfortunate. I think the shift in education from FP to OOP was
actually a bad thing.

> With such a background it's not easy to
> accept some of the things the Clojure community claim.

With my background I find it hard to accept some of the things the
educational OOP community claim :) The reality is that "big systems"
are just plain hard to work with - in any paradigm - and FP provides
tools to manage it just like OOP does. They're just _different_ tools.

I'm glad you're open minded. For now you'll just have to trust those
people who tell you that Clojure lets you deal with "big system"
complexity very well. I'm not sure why you are less trusting of their
real world experiences than what your professors told you about
(theoretical) OOP...
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

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

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Namespaces [was Re: Is Clojure right for me?]

[Softaddicts]

We use a lot of configuration information in our product and I mean lot :)
Immutable in regard to the application cycle.

We chose to remove this from each name spaces and instead use a name 
space to act as an intermediate to acces it.

It's not as pure as it should be (it's contextually outside of any fn referring 
to it)
but since it does not appear to change in the life cycle of the app it's
bearable.

It also useful because we can decide were it's stored. In prod it's in
zookeeper. When running tests, it comes from a memory based implementation
and can be stubbed at will within the tests.

It's also versionned, a change clones the current config and creates a new
one with whatever delta needs to be applied to it.

Passing this stuff around using one of the two methods you have shown
would have been cumbersome and unmaintainable. Most of the time
our configuration information comes from top level fns so the lower
layers remain even more insensitive to how this info is pulled in.

I would not however share state this way using this outside of Clojure
constructs (atom, refs, ...) to handle mutation explicitly.

When the configuration changes it's because the app ends its life cycle and
restarts anyway.

My 2 cents :)

Luc P.


> I ended up accidentally injecting a completely different thread of
> discussion into the "Is Clojure right for me?" thread.  I'm breaking it
> into a separate thread here.
> 
> Here's where we left off:
> 
> On Fri, Dec 27, 2013 at 6:34 AM, Stuart Halloway
> wrote:
> 
> > Yes, thanks Mark. It seems to me that you are saying "namespaces make poor
> > maps".  Stipulated.  So why not use records or maps?
> >
> >
> This is close, but not exactly what I'm saying.  It's not so much about
> wanting namespaces to be maps.  It's about wanting a robust mechanism for
> functions to share information other than threading that information
> through the functions.
> 
> In Structure and Interpretation of Computer Programming, a large chunk of
> the programs are written in a pseudo-object-oriented style, a style which
> simulates objects by having functions' closures share the same local
> context.
> 
> Sure, you could do that with maps:
> 
> For example:
> 
> (defn create-functions [init-info]
>(let [shared-info init-info]
>   {:foo (fn foo [x] ... body uses shared-info in some way ...),
>:bar (fn bar [x] ... body uses shared-info in some way ..)}))
> 
> Then, to access these functions, you'd do something like this:
> (def instance (create-functions default-info))
> ((:foo instance) 2)  ; the equivalent of instance.foo(2) in OO
> ((:bar instance) 3)  ; the equivalent of instance.bar(3) in OO
> 
> Of course, SICP's main point is that even bare-bones Scheme is rich enough
> to simulate objects, but the other point is that it is important for
> functions to be able to share stat*e* which can be initialized for a group
> of functions,
> 
> *even if that state is immutable.*
> The above pattern is important enough that most languages provide some kind
> of mechanism for doing that. Classes are one such pattern.
> 
> In Clojure, the above code would be horribly un-idiomatic of course.
> Actually, depending on the functions and definitions, it might not even be
> possible to structure the code that way (because Clojure's local definition
> capabilities are not as rich as what is possible at the global level, for
> example, regarding mutual references -- in some contexts, letfn might help,
> but not all contexts).
> 
> The above example uses associative containers for the shared-info, and
> associative containers to hold the group of related functions that are
> outputted, but that doesn't make this solution any more attractive --
> again, emphasizing that this is not about associative containers.
> 
> I claim that Clojure only provides two idiomatic solutions to the above
> problem of functions sharing the same immutable information, which might
> need to be set prior to using those functions:
> 
> Solution 1:
> 
> (def ^:dynamic shared-info default-info)
> (defn foo [x] ... body uses shared-info)
> (defn bar [x] ... body uses shared-info)
> 
> Call these functions via:
> 
> (foo 2) and (bar 3) if you're happy with the defaults or
> 
> (binding [shared-info info] (foo 2)) and
> (binding [shared-info info] (bar 3)) otherwise.
> 
> This is awkward for several reasons, and sometimes this solution isn't
> really an option since functions that return lazy structures won't work
> with the above mechanism.
> 
> Solution 2:
> 
> (defn foo [shared-info x] ... body uses shared-info)
> (defn bar [shared-info x] ... body uses shared-info)
> 
> Call these functions via:
> 
> (foo info 2)
> (bar info 3)
> 
> 
> My argument is that both these solutions are unsatisfying.  Solution 2 is
> irritating because if you use a map for shared-info, you end up having to
> repeat the destructuring in every single function.  Also, you need to
> thread this information through all the functions, not only the funct

Recommendations for a project with learning-friendly bugs and devs?

[Jakub Holy]

Hello,

I'd like to sharpen my Clojure skill by contributing to an open source
project and getting feedback on my patches from its developers. Can you
recommend a project that would be suitable? Preferably something where
there is plenty of beginner-friendly bugs and in the domain of web or
devops.

Thanks a lot and happy new year!


Best regards, Jakub
-- 
*Forget software. Strive to make an impact, deliver a valuable change.*

*(**Vær så snill og hjelp meg med å forbedre norsken **min –** skriftlig og
muntlig. Takk!**)*

Jakub Holy
Solutions Engineer | +47 966 23 666
Iterate AS | www.iterate.no
The Lean Software Development Consultancy
- http://theholyjava.wordpress.com/ -

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Namespaces [was Re: Is Clojure right for me?]

[Gary Trakhman]

I can think of a couple more alternatives to consider:

;; Turns out you don't need vars for everything.
(let [state {:some :data}]
  (defn do-stuff [] (func-of state)))

;; Shifts some burden to the client code
(defn do-stuff-fn [state]
  (fn [] (func-of state))

The issue as I see it is a complection of namespaces (DAG of bags of
functions) and individual object lifecycles.  The grid size stuff impl is a
function of that particular object (which starts out with a global
lifecycle), whether that's exposed in their signatures or not.  If I have
to make it explicit later, I'm willing to accept that work as stemming from
an incorrect initial design.   It doesn't bother me to refactor the old in
terms of the new, explicit, versions when I identify something like that,
deleting the old eventually (or not).

Why should functions share information?  Parameters and return values give
you inputs and outputs, and if it weren't a little cumbersome to add new
ones we'd be abusing it to bits.  Vars are easy, but wrong at times, thus
the tension.  Is there something in between the purity and the ease?

I guess I'm willing to accept the immediate costs because of a perceived
larger benefit, namely decoupled designs.

But, I think if we had more functions to dynamically modify scopes as data,
that would get us closer, like 'environment-as-a-value'.  Right now, it's
all bound up in private or complicated implementation details.




On Fri, Dec 27, 2013 at 6:35 AM, Softaddicts wrote:

> We use a lot of configuration information in our product and I mean lot :)
> Immutable in regard to the application cycle.
>
> We chose to remove this from each name spaces and instead use a name
> space to act as an intermediate to acces it.
>
> It's not as pure as it should be (it's contextually outside of any fn
> referring to it)
> but since it does not appear to change in the life cycle of the app it's
> bearable.
>
> It also useful because we can decide were it's stored. In prod it's in
> zookeeper. When running tests, it comes from a memory based implementation
> and can be stubbed at will within the tests.
>
> It's also versionned, a change clones the current config and creates a new
> one with whatever delta needs to be applied to it.
>
> Passing this stuff around using one of the two methods you have shown
> would have been cumbersome and unmaintainable. Most of the time
> our configuration information comes from top level fns so the lower
> layers remain even more insensitive to how this info is pulled in.
>
> I would not however share state this way using this outside of Clojure
> constructs (atom, refs, ...) to handle mutation explicitly.
>
> When the configuration changes it's because the app ends its life cycle and
> restarts anyway.
>
> My 2 cents :)
>
> Luc P.
>
>
> > I ended up accidentally injecting a completely different thread of
> > discussion into the "Is Clojure right for me?" thread.  I'm breaking it
> > into a separate thread here.
> >
> > Here's where we left off:
> >
> > On Fri, Dec 27, 2013 at 6:34 AM, Stuart Halloway
> > wrote:
> >
> > > Yes, thanks Mark. It seems to me that you are saying "namespaces make
> poor
> > > maps".  Stipulated.  So why not use records or maps?
> > >
> > >
> > This is close, but not exactly what I'm saying.  It's not so much about
> > wanting namespaces to be maps.  It's about wanting a robust mechanism for
> > functions to share information other than threading that information
> > through the functions.
> >
> > In Structure and Interpretation of Computer Programming, a large chunk of
> > the programs are written in a pseudo-object-oriented style, a style which
> > simulates objects by having functions' closures share the same local
> > context.
> >
> > Sure, you could do that with maps:
> >
> > For example:
> >
> > (defn create-functions [init-info]
> >(let [shared-info init-info]
> >   {:foo (fn foo [x] ... body uses shared-info in some way ...),
> >:bar (fn bar [x] ... body uses shared-info in some way ..)}))
> >
> > Then, to access these functions, you'd do something like this:
> > (def instance (create-functions default-info))
> > ((:foo instance) 2)  ; the equivalent of instance.foo(2) in OO
> > ((:bar instance) 3)  ; the equivalent of instance.bar(3) in OO
> >
> > Of course, SICP's main point is that even bare-bones Scheme is rich
> enough
> > to simulate objects, but the other point is that it is important for
> > functions to be able to share stat*e* which can be initialized for a
> group
> > of functions,
> >
> > *even if that state is immutable.*
> > The above pattern is important enough that most languages provide some
> kind
> > of mechanism for doing that. Classes are one such pattern.
> >
> > In Clojure, the above code would be horribly un-idiomatic of course.
> > Actually, depending on the functions and definitions, it might not even
> be
> > possible to structure the code that way (because Clojure's local
> definition
> > capabilities are not as rich 

Re: Namespaces [was Re: Is Clojure right for me?]

[Mark Engelberg]

The thing I like about your record/protocol example version is that all the
protocol function implementations can "see" the components of the record
and use those names in the implementation without explicit destructuring.
That adds significantly to the ease of working with multiple functions
sharing common information.

I generally haven't been able to do this kind of thing because:
1. The implementations of the functions are too long to implement inline in
the record definition.
2. Protocols are significantly more restricted than regular functions
(e.g., aren't they restricted to 4 parameters, no indefinite arities, and
no destructuring in the arguments?)


On Fri, Dec 27, 2013 at 10:19 AM, john walker wrote:

> I posted this in response to the original gist, but it probably wasn't
> seen. Does this demonstrate the behavior you want?
>
> https://gist.github.com/johnwalker/8142143
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Namespaces [was Re: Is Clojure right for me?]

[Mark Engelberg]

On Fri, Dec 27, 2013 at 10:35 AM, Softaddicts
wrote:

> Passing this stuff around using one of the two methods you have shown
> would have been cumbersome and unmaintainable. Most of the time
> our configuration information comes from top level fns so the lower
> layers remain even more insensitive to how this info is pulled in.
>

Agreed.  Now imagine that one day you realize that you have a problem that
can't be solved with one single configuration for the entire lifecycle of
the program, but somehow, you have to process and compare results from two
configurations simultaneously.  What would you do?  How painful would that
change be?  Is there something we can do to make this more feasible in
Clojure?

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Namespaces [was Re: Is Clojure right for me?]

[Mark Engelberg]

On Fri, Dec 27, 2013 at 10:27 AM, Cedric Greevey  wrote:

> On Fri, Dec 27, 2013 at 1:08 PM, Mark Engelberg 
> wrote:
>>
>>  Solution 2:
>>
>> (defn foo [shared-info x] ... body uses shared-info)
>> (defn bar [shared-info x] ... body uses shared-info)
>>
>> Call these functions via:
>>
>> (foo info 2)
>> (bar info 3)
>>
>
> In what way is this any worse than
>
> info.foo(2);
> info.bar(3);
>

In an OO implementation, the definitions of foo and bar could be
dramatically more concise because from within the object, references to the
other components of the object don't need to be prefixed with "info."  This
is a big deal.

In Clojure, the closest comparison is namespaces, which let you use other
names from within the same namespace without explicit prefixing.  But in
Clojure there's no way to combine a namespace's capability for things
referring to one another without a prefix with a problem where some of that
data can be initialized/configured to different initial values.

Contrast that with classes-as-namespaces and you see that there is a
mechanism both for things in a class to refer to one another without
prefixes, and to easily turn it into something where a constructor sets up
some initial values.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Akka-like framework in Clojure ?

[Bruno Kim Medeiros Cesar]

I haven't dabbled yet on actor-based concurrency, can someone point out (a 
blog post about) a comparison between Akka actors, Clojure agents and other 
solutions?

On Friday, December 27, 2013 6:54:16 AM UTC-2, Eric Le Goff wrote:
>
>
> Hi,
>
> After a long background with imperative languages such as Java, I recently 
> spent some time learning functionnal programming, starting with Scala. I 
> had the opporrtunity to build a demo project based on the Akka framework.
>
> Now I am starting learning Clojure, and would be curious to know if there 
> was some clojure based framework available which could implement rather 
> similar features to Akka. 
>
> In particular, I would be interested in an implementation of the Actor 
> Model [1]
>
> Thanks.
>
> Eric
>
>
> [1] http://en.wikipedia.org/wiki/Actor_model
>  

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Namespaces [was Re: Is Clojure right for me?]

[Mark Engelberg]

On Fri, Dec 27, 2013 at 11:03 AM, Gary Trakhman wrote:

> Why should functions share information?
>

Maybe I'm the odd one out, but every project I've done has at least a few
bits of info shared by many functions.  It might be something like
BUFFERSIZE or NUM-THREADS or DATABASE_URL.  Basically, they are things I
expect to be unchanged.  I separate it out as a var so that I don't have to
repeat the number 30268 everywhere, and I can easily change it for the
whole project if necessary.  In the initial design, nothing suggests to me
that {:buffer-size, :number-threads, :database-url} is some data structure
that I should be explicitly passing around and destructuring in all my
functions, just in case some day I decide I want to configurations to exist
simulatenously.

Can we create a path that makes it easier to get from the version where we
expect things to be unchanged to the version where we need to support
multiple configurations?



>  Vars are easy, but wrong at times, thus the tension.  Is there something
> in between the purity and the ease?
>

Exactly.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is Clojure right for me?

[Massimiliano Tomassoli]

That makes me think that maybe there's a need for more books about Clojure. 
There are many introductory books but nothing more advanced such as best 
practices, patterns, etc...
That's maybe a problem for someone like me who wants to "do things right" 
from the start. Should I read books about Common LISP and functional 
programming in general?

On Friday, December 27, 2013 5:55:57 PM UTC+1, Luc wrote:
>
> It took us some time to structure the code at the time and now 
> with protocols we went under a other restructuring a year ago. 
>
> I agree this part can be hard (structuring the code) but at the time we 
> started 
> protocols were not yet there hence some of the restructuring. 
> Best practices also evolved for a couple of years. 
> It's much more stable these days. 
>
> When I say write some code, well you need to choose a domain 
> aside from simple things like "hello world". Which makes it harder 
> to write some code :) but forces you to question yourself about 
> how to do this right the first time. 
>
>
> This is the list of my favorite  items that I keep an eye on: 
>
> a) abstractions, choose them according to your business domain, do not 
> try to re-invent the wheel or create alien terminology. 
> This is a starting point to get your name space structure right. 
>
> b) In your APIs try to stay generic by not assuming implementation 
> details. 
> This step can be hard to achieve. Keep doors opened. 
>
> c) You may want to redefine the implementations of 
> your abstractions or provide different flavors or some flexibility in 
> your APIs. 
> Protocols/multimethods become handy at some point here. 
> This is the part that may feel a bit like OO but this is the one you 
> have to 
> think last. (remember point a and b) 
>
> d) Do not hesitate to refactor. There's less code than in most other 
> languages 
> that get some support for refactoring from their IDE so you should not 
> wait until it becomes a mess. If a name space is not rightly named 
> anymore, 
> chane it. If more separation of concerns is required, add/change name 
> spaces accordingly and reorg the code. 
>
> e) A good indicator of the stability of your APIs is how much your test 
> code 
> gets messed up when you do change something. It could be 
> related to implementation details leaking out, bad choice in name 
> space 
> design,  
>
> I am not an advocate of TDD but at some point when the code of a 
> name space is stable enough, a few test cases can be used as 
> health signs. 
>
> f) Search for existing librairies, there are enough of them out there, 
>either Java libs with/wo Clojure wrappers or Clojure centric ones 
>to speed you up not having to rewrite the universe. 
>
> g) Read the code of the libs you are pulling in as you go along. 
> This will probably light a bulb in your brain about tricks you should 
> apply to your code. 
>
> The above should sound familiar :) It's not that different in Clojure to 
> me 
> than in many other languages. 
>
> If you have some specific concerns, send them to me off line. 
> I may share some code privately to answer some of your questions. 
> Sorry for the other folks on this thread but there are copyright issues 
> here :) 
>
> Luc P. 
>
> > I've seen Clojure in action and I know it's extremely concise and 
> > expressive. What I wanted to know is how it copes with complexity when 
> you 
> > develop complex systems. You can't get an idea of that just by writing 
> some 
> > code and getting a feeling about the language, IMHO. When I studied OOP 
> at 
> > University my professors taught me that OOP was extremely successful in 
> > reducing the complexity of big systems. I was given many examples of 
> that 
> > in the many courses of software engineering I took. FP was relegated to 
> > some theoretical courses about paradigms. With such a background it's 
> not 
> > easy to accept some of the things the Clojure community claim. The fact 
> > that I'm here asking questions should mean that I'm more open minded 
> than 
> > most :) But please understand where I'm coming from. 
> > 
> > On Friday, December 27, 2013 3:50:23 PM UTC+1, Luc wrote: 
> > > 
> > > I would add that you *need* to 
> > > write some code to get a feeling 
> > > about a new language. 
> > > 
> > > Feature comparisons may help you up 
> > > to a certain degree. However deciding about how efficient 
> > > you may become using a new language requires you to dive at 
> > > least a bit into it. Not all brains are  wired the same. 
> > > 
> > > Luc P. 
> > > 
> > > > Then we have more in common 
> > > > than you may think :) 
> > > > 
> > > > I learned Ruby first, went through 
> > > > Scala which appeared in the same 
> > > > time frame, 
> > > > all this to pick up the language of 
> > > > choice to replace Java and Ruby 
> > > > which we used to prototype our 
> > > > product. 
> > > > 
> > > > All this took around 9 month

Re: Namespaces [was Re: Is Clojure right for me?]

[john walker]

I investigated a few of these. Variable arity functions don't some to work, 
but destructuring and parameter number seem unaffected.

https://gist.github.com/johnwalker/8151474

I suspect that what I wrote below is possible with multimethods.

(defrecord foobarrecord
foobarprotocol
:declare foo)

(defn :foobarrecord foo [...] ...)

This is an excellent issue you've brought up.

On Friday, December 27, 2013 2:14:54 PM UTC-5, puzzler wrote:
>
> The thing I like about your record/protocol example version is that all 
> the protocol function implementations can "see" the components of the 
> record and use those names in the implementation without explicit 
> destructuring.  That adds significantly to the ease of working with 
> multiple functions sharing common information.
>
> I generally haven't been able to do this kind of thing because:
> 1. The implementations of the functions are too long to implement inline 
> in the record definition.
> 2. Protocols are significantly more restricted than regular functions 
> (e.g., aren't they restricted to 4 parameters, no indefinite arities, and 
> no destructuring in the arguments?)
>
>
> On Fri, Dec 27, 2013 at 10:19 AM, john walker 
> 
> > wrote:
>
>> I posted this in response to the original gist, but it probably wasn't 
>> seen. Does this demonstrate the behavior you want?
>>
>> https://gist.github.com/johnwalker/8142143
>>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Namespaces [was Re: Is Clojure right for me?]

[Luc Prefontaine]

We have a good basis with
versioning. 

99% of the time, workers are the
ones accessing the configuration.
They are at the top level.

It happens that they do access
configuration through
the workers service name space.
In fact through a single fn ... 

Passing a version number when
pulling out a resource is feasible.
This could override the default
(the current config established at
startup).

I want to make it clear, we never
intended to do this BUT it happens
that we need a way to compare
configs. It's not implemented yet.
It maybe more or less an
 unconscious design decision that
makes it easy to implement.

Versioning is mainly a way for us to 
revert back to previous configs but it's
also a way to fake an immutable
config state. It's an operational
requirement more than a code
or design issue.

Luc P.

> On Fri, Dec 27, 2013 at 10:35 AM, Softaddicts
> wrote:
> 
> > Passing this stuff around using one of the two methods you have shown
> > would have been cumbersome and unmaintainable. Most of the time
> > our configuration information comes from top level fns so the lower
> > layers remain even more insensitive to how this info is pulled in.
> >
> 
> Agreed.  Now imagine that one day you realize that you have a problem that
> can't be solved with one single configuration for the entire lifecycle of
> the program, but somehow, you have to process and compare results from two
> configurations simultaneously.  What would you do?  How painful would that
> change be?  Is there something we can do to make this more feasible in
> Clojure?
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
--
Luc Prefontaine sent by ibisMail!

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Namespaces [was Re: Is Clojure right for me?]

[kovas boguta]

On Fri, Dec 27, 2013 at 2:03 PM, Gary Trakhman  wrote:

> The issue as I see it is a complection of namespaces (DAG of bags of
> functions) and individual object lifecycles.  The grid size stuff impl is a

This is a very fair point, and something people have worked on

Check out

https://github.com/juxt/jig
https://github.com/stuartsierra/component

and

http://www.infoq.com/presentations/Clojure-Large-scale-patterns-techniques
http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Namespaces [was Re: Is Clojure right for me?]

[guns]

On Fri 27 Dec 2013 at 11:40:45AM -0800, Mark Engelberg wrote:
> On Fri, Dec 27, 2013 at 11:03 AM, Gary Trakhman 
> wrote:
>
> > Why should functions share information?
>
> Maybe I'm the odd one out, but every project I've done has at least a few
> bits of info shared by many functions.  It might be something like
> BUFFERSIZE or NUM-THREADS or DATABASE_URL.

In OO systems we typically have an Application class with a constructor
that receives a map of configuration values. This allows more
flexibility than defining static constants as the methods of our
Application class close over the instance values.

We can achieve the same thing in Clojure, but creating closures over
dynamic configuration values is difficult to reconcile with REPL driven
development. Typically then, the Clojurist chooses to store these
instance values in vars, which creates the tension described in this
thread.

Stuart Sierra has been thinking quite a bit about this issue, and I
think he's developed a great solution:

https://github.com/stuartsierra/component/

Designing a system as outlined above results in a modular application
with the benefits of an instance constructor, while still allowing easy
access from the REPL via a single var bound to the current running
instance of the application.

I encourage everyone to look into it; I have had great success with it
so far. (Thanks Stuart!)

guns


pgp8B_Qd2JTzv.pgp
Description: PGP signature

Re: Namespaces [was Re: Is Clojure right for me?]

[Cedric Greevey]

On Fri, Dec 27, 2013 at 2:32 PM, Mark Engelberg wrote:

> On Fri, Dec 27, 2013 at 10:27 AM, Cedric Greevey wrote:
>
>> On Fri, Dec 27, 2013 at 1:08 PM, Mark Engelberg > > wrote:
>>>
>>>  Solution 2:
>>>
>>> (defn foo [shared-info x] ... body uses shared-info)
>>> (defn bar [shared-info x] ... body uses shared-info)
>>>
>>> Call these functions via:
>>>
>>> (foo info 2)
>>> (bar info 3)
>>>
>>
>> In what way is this any worse than
>>
>> info.foo(2);
>> info.bar(3);
>>
>
> In an OO implementation, the definitions of foo and bar could be
> dramatically more concise because from within the object, references to the
> other components of the object don't need to be prefixed with "info."  This
> is a big deal.
>

Erm,

(defn foo [{:keys [thingy mumble fiddly]} x]
  (...thingy ... mumble ... fiddly ... mumble ... mumble ... x ... thingy
...))

After from one brief incantation in the parameter list you can just go
ahead and refer to the "fields" like in an OO method body.


There's also protocol + defrecord and record fields referenced in the
function bodies in the defrecord.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Namespaces [was Re: Is Clojure right for me?]

[john walker]

This works (clever hack!), but you would have to reduplicate the keys in 
(defn bar [..]...), (defn baz [...] ...) etc.

On Friday, December 27, 2013 3:05:24 PM UTC-5, Cedric Greevey wrote:
>
> On Fri, Dec 27, 2013 at 2:32 PM, Mark Engelberg 
> 
> > wrote:
>
>> On Fri, Dec 27, 2013 at 10:27 AM, Cedric Greevey 
>> 
>> > wrote:
>>  
>>> On Fri, Dec 27, 2013 at 1:08 PM, Mark Engelberg 
>>> 
>>> > wrote:

  Solution 2:

 (defn foo [shared-info x] ... body uses shared-info)
 (defn bar [shared-info x] ... body uses shared-info)

 Call these functions via:

 (foo info 2)
 (bar info 3)

>>>
>>> In what way is this any worse than
>>>
>>> info.foo(2);
>>> info.bar(3);
>>>
>>
>> In an OO implementation, the definitions of foo and bar could be 
>> dramatically more concise because from within the object, references to the 
>> other components of the object don't need to be prefixed with "info."  This 
>> is a big deal.
>>
>
> Erm,
>
> (defn foo [{:keys [thingy mumble fiddly]} x]
>   (...thingy ... mumble ... fiddly ... mumble ... mumble ... x ... thingy 
> ...))
>
> After from one brief incantation in the parameter list you can just go 
> ahead and refer to the "fields" like in an OO method body.
>
>
> There's also protocol + defrecord and record fields referenced in the 
> function bodies in the defrecord.
>  

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is Clojure right for me?

[Massimiliano Tomassoli]

On Friday, December 27, 2013 7:31:25 PM UTC+1, Sean Corfield wrote:
>
> I'm not sure why you are less trusting of their 
> real world experiences than what your professors told you about 
> (theoretical) OOP... 
>

First, someone said that OOP doesn't alleviate the problems that it's 
supposed to solve and this I don't believe.
Then, someone else claimed that OOP is useless in presence of immutability. 
I don't agree with that. It would also imply that Scala's developers are 
just plain stupid.
So I was under the impression that you were criticizing something you 
didn't fully understand.
Also, it's difficult to trust someone who claim that LISP is the best 
language there is and everybody else is just stupid for not realizing that.
I only tend to trust people who realize that their language is not perfect 
and is just one of the many languages available. 

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Namespaces [was Re: Is Clojure right for me?]

[Cedric Greevey]

On Fri, Dec 27, 2013 at 3:13 PM, john walker wrote:

> This works (clever hack!), but you would have to reduplicate the keys in
> (defn bar [..]...), (defn baz [...] ...) etc.
>

(defmacro defthingyfn [name arglist & body]
  `(defn name ~(vec (cons '{:keys [thingy mumble fiddly]} arglist)) ~@body))

(defthingyfn foo [x]
  (...thingy ... mumble ... fiddly ... mumble ... mumble ... x ... thingy
...))

(defthingyfn bar [x]
  (...mumble ... thingy ... mumble ... mumble ... x ... thingy ... fiddly
... thingy ...))

...

(Extending that to cope with docstrings and multiple arities is left as an
exercise for the reader. :))

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is Clojure right for me?

[Sean Corfield]

On Fri, Dec 27, 2013 at 12:24 PM, Massimiliano Tomassoli
 wrote:
> First, someone said that OOP doesn't alleviate the problems that it's
> supposed to solve and this I don't believe.

There is no silver bullet: OOP helps with some problems in some ways
but it's not perfect. The folks who pioneered OOP didn't imagine it
would turn into C++ or Java...

> Then, someone else claimed that OOP is useless in presence of immutability.

I don't think anyone claimed that. There was a comment that
encapsulation is less important in the presence of immutability.
Encapsulation is only one aspect of OOP - and Clojure provides several
ways to encapsulate data if you want to do that.

> So I was under the impression that you were criticizing something you didn't
> fully understand.

Perhaps you've been convinced otherwise now? I feel that I understand
OOP pretty well after two decades of using several OOP languages to
deliver production systems - and helping to design parts of C++, and
building a C++ compiler :)

> Also, it's difficult to trust someone who claim that LISP is the best
> language there is and everybody else is just stupid for not realizing that.

Well, that's the Smug Lisp Weenie and part of the Lisp Curse [1]. I
think there's an OOP equivalent but it doesn't get written about very
much because OOP is so mainstream, despite its flaws.

[1] http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

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

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is Clojure right for me?

[Luc Prefontaine]

I am kind of old school.
To me these things come through
practice...

Which I understand maybe of little
help to you in the immediate
future :)

When I was young we had
many books that had little to
do with the ones mostly
available today.
(Learn xxx in nnn days)

Looks to me that this is the missing
piece in the puzzle. Not sure that
this kind of book would be popular
these days.

Luc P.


> That makes me think that maybe there's a need for more books about Clojure. 
> There are many introductory books but nothing more advanced such as best 
> practices, patterns, etc...
> That's maybe a problem for someone like me who wants to "do things right" 
> from the start. Should I read books about Common LISP and functional 
> programming in general?
> 
> On Friday, December 27, 2013 5:55:57 PM UTC+1, Luc wrote:
> >
> > It took us some time to structure the code at the time and now 
> > with protocols we went under a other restructuring a year ago. 
> >
> > I agree this part can be hard (structuring the code) but at the time we 
> > started 
> > protocols were not yet there hence some of the restructuring. 
> > Best practices also evolved for a couple of years. 
> > It's much more stable these days. 
> >
> > When I say write some code, well you need to choose a domain 
> > aside from simple things like "hello world". Which makes it harder 
> > to write some code :) but forces you to question yourself about 
> > how to do this right the first time. 
> >
> >
> > This is the list of my favorite  items that I keep an eye on: 
> >
> > a) abstractions, choose them according to your business domain, do not 
> > try to re-invent the wheel or create alien terminology. 
> > This is a starting point to get your name space structure right. 
> >
> > b) In your APIs try to stay generic by not assuming implementation 
> > details. 
> > This step can be hard to achieve. Keep doors opened. 
> >
> > c) You may want to redefine the implementations of 
> > your abstractions or provide different flavors or some flexibility in 
> > your APIs. 
> > Protocols/multimethods become handy at some point here. 
> > This is the part that may feel a bit like OO but this is the one you 
> > have to 
> > think last. (remember point a and b) 
> >
> > d) Do not hesitate to refactor. There's less code than in most other 
> > languages 
> > that get some support for refactoring from their IDE so you should not 
> > wait until it becomes a mess. If a name space is not rightly named 
> > anymore, 
> > chane it. If more separation of concerns is required, add/change name 
> > spaces accordingly and reorg the code. 
> >
> > e) A good indicator of the stability of your APIs is how much your test 
> > code 
> > gets messed up when you do change something. It could be 
> > related to implementation details leaking out, bad choice in name 
> > space 
> > design,  
> >
> > I am not an advocate of TDD but at some point when the code of a 
> > name space is stable enough, a few test cases can be used as 
> > health signs. 
> >
> > f) Search for existing librairies, there are enough of them out there, 
> >either Java libs with/wo Clojure wrappers or Clojure centric ones 
> >to speed you up not having to rewrite the universe. 
> >
> > g) Read the code of the libs you are pulling in as you go along. 
> > This will probably light a bulb in your brain about tricks you should 
> > apply to your code. 
> >
> > The above should sound familiar :) It's not that different in Clojure to 
> > me 
> > than in many other languages. 
> >
> > If you have some specific concerns, send them to me off line. 
> > I may share some code privately to answer some of your questions. 
> > Sorry for the other folks on this thread but there are copyright issues 
> > here :) 
> >
> > Luc P. 
> >
> > > I've seen Clojure in action and I know it's extremely concise and 
> > > expressive. What I wanted to know is how it copes with complexity when 
> > you 
> > > develop complex systems. You can't get an idea of that just by writing 
> > some 
> > > code and getting a feeling about the language, IMHO. When I studied OOP 
> > at 
> > > University my professors taught me that OOP was extremely successful in 
> > > reducing the complexity of big systems. I was given many examples of 
> > that 
> > > in the many courses of software engineering I took. FP was relegated to 
> > > some theoretical courses about paradigms. With such a background it's 
> > not 
> > > easy to accept some of the things the Clojure community claim. The fact 
> > > that I'm here asking questions should mean that I'm more open minded 
> > than 
> > > most :) But please understand where I'm coming from. 
> > > 
> > > On Friday, December 27, 2013 3:50:23 PM UTC+1, Luc wrote: 
> > > > 
> > > > I would add that you *need* to 
> > > > write some code to get a feeling 
> > > > about a new language. 
> > > > 
> > > > Feature comparisons may help y

Re: Is Clojure right for me?

[Mark Engelberg]

With a little searching, you can find several papers like this one that
research the question of whether OO has lived up to the hype:
http://scholarworks.gvsu.edu/cgi/viewcontent.cgi?article=1129&context=cistechlib

Feel free to jump straight to the conclusion, i.e., "object-oriented
technology has only partly kept its promises."

If you want to use OO in its traditional form, there are many languages
that will support you in doing that.  Clojure is not one of them.  If you
want to join a community of people who are dissatisfied with OO, and feel
they are working towards a better way, with better tools for reuse and
managing complexity, give Clojure a try.  It's entirely your choice.  No
one's making you do anything.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is Clojure right for me?

[john walker]

Err, a lot of these questions are quite open in nature. I don't think 
anyone in software engineering has great answers - see "Everything is an 
Object" for Javaland and then some of the proposals in Doug Hoyte's Let 
Over Lambda (an excellent read if you're after Common Lisp books and 
recognize the high-mindedness). These topics should then probably be 
reframed with additional context.

I probably sound like a broken record, but I strongly feel that you should 
ask for examples of large projects and look for yourself to see how they're 
engineered.

Umm, I hope that no one actually said that Lisp is the perfect language and 
everyone else is stupid or that OOP is useless with immutability. 

What are some flaws that you think Clojure has? : )

On Friday, December 27, 2013 3:24:56 PM UTC-5, Massimiliano Tomassoli wrote:
>
> On Friday, December 27, 2013 7:31:25 PM UTC+1, Sean Corfield wrote:
>>
>> I'm not sure why you are less trusting of their 
>> real world experiences than what your professors told you about 
>> (theoretical) OOP... 
>>
>
> First, someone said that OOP doesn't alleviate the problems that it's 
> supposed to solve and this I don't believe.
> Then, someone else claimed that OOP is useless in presence of 
> immutability. I don't agree with that. It would also imply that Scala's 
> developers are just plain stupid.
> So I was under the impression that you were criticizing something you 
> didn't fully understand.
> Also, it's difficult to trust someone who claim that LISP is the best 
> language there is and everybody else is just stupid for not realizing that.
> I only tend to trust people who realize that their language is not perfect 
> and is just one of the many languages available. 
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is Clojure right for me?

[Mark Engelberg]

Luc, I've just got to say, your tiny margin widths always make me think
your message is some kind of haiku :)


On Fri, Dec 27, 2013 at 1:08 PM, Luc Prefontaine <
lprefonta...@softaddicts.ca> wrote:

> I am kind of old school.
> To me these things come through
> practice...
>
> Which I understand maybe of little
> help to you in the immediate
> future :)
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is Clojure right for me?

[Gary Trakhman]

brain-dump TLDR: I like clojure's costs-to-benefits.. and it's successful
because it's what the industry needs.




I wouldn't say lisp family langs are the 'best' languages, but I would say
its tradeoffs maximize the power of the individual, which interests me
since I am one :-).

Talking about tradeoffs can get very verbose, but I find it helpful to make
an analogy for things like mutability/immutability as a number line.

Let's think of some tradeoffs and virtues, it's not always black/white or
bad/good:
regularity/expressiveness
type-safety/dynamicity
mutability/immutability
speed
code size (language implementation or generated)
'weight of an abstraction' (ie how hard/big is it to jump a level of
expressiveness)
orthogonality of feature-set (pay for what you use)
popularity
blub-ability (do you need to be an expert to program in it?)
team-suitability

Then we can start to think of it as quantities, a vector.
We can subjectively normalize these for orthogonality, eg.. for some
languages, some tradeoffs will interact more with others in practice, and
we can come up with a cost-model according to our usage.

Then programming in this language can be thought of as a projection
(dot-product) of our minds along this vector space over time.

These tradeoffs affect 'costs', ie time/money/effort.  There is a fixed
cost to learning clojure well enough (IME the time it takes to grok Joy of
Clojure, implementation details like core.clj and Compiler.java, learning
enough emacs to get by), and little recurring costs along the way (like how
hard it is to refactor something).

In my opinion, I love clojure because of the orthogonality of its
feature-set (design by decoupling) and because of the expressivity of lisp
itself, that outweighs everything else.  Its code has a high SNR because of
it.

I think s-expressions are the closest thing to how brains actually work, ie
it's an efficient way to 'project' at any level of abstraction, and the
cost of traversing abstractions up and down is low due to the regularity of
the syntax.  Scheme makes a good teaching language because there are
benefits to seeing the structure directly.  We know from experience that
restricting abstraction is bad (java).

So, I'm pretty satisfied with it, I might learn other languages for
specific use-cases, but I think time spent in lisp isn't wasted, since it's
easy to pull an abstraction out of anything repetitive, and we as users can
steal ideas from other languages more effectively without involvement from
compiler writers.  A new language becomes necessary when we have to revisit
core primitives, which we will be compelled to do once we identify certain
costs are too high for too many people.

People might have different ideals, use-cases or costs based on their
experience or situation.'

I think the curation approach of 'design by decoupling' turned out to be a
great idea simply because of the huge amount of stuff that's been written
by many people in isolation over the last decades.  If we took it to an
extreme, then it would also cease to be a good idea.  I think
C++/Java-style OO has already been taken as far as it needs to go.  We've
reached the point where the costs-to-benefits are well-understood and felt
to be lacking for many current and future use-cases.


On Fri, Dec 27, 2013 at 8:24 AM, Massimiliano Tomassoli
wrote:

> On Friday, December 27, 2013 7:31:25 PM UTC+1, Sean Corfield wrote:
>>
>> I'm not sure why you are less trusting of their
>> real world experiences than what your professors told you about
>> (theoretical) OOP...
>>
>
> First, someone said that OOP doesn't alleviate the problems that it's
> supposed to solve and this I don't believe.
> Then, someone else claimed that OOP is useless in presence of
> immutability. I don't agree with that. It would also imply that Scala's
> developers are just plain stupid.
> So I was under the impression that you were criticizing something you
> didn't fully understand.
> Also, it's difficult to trust someone who claim that LISP is the best
> language there is and everybody else is just stupid for not realizing that.
> I only tend to trust people who realize that their language is not perfect
> and is just one of the many languages available.
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
You received

In your opinion, what's the best, and what's the worst aspects of using Clojure?

[Kelker Ryan]

In your opinion, what's the best, and what's the worst aspects of using Clojure?

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is Clojure right for me?

[Patrick Kristiansen]

Maybe it would be helpful to define what exactly you mean by OOP. Use this list:

http://www.paulgraham.com/reesoo.html

Clojure supports some of the constructs that people typically relate to OOP.

Decomposing large systems: How do you decompose large systems with OOP? By 
using classes and objects? I don't believe that classes and objects tell you 
much about how to structure systems (comprised of multiple subsystems). It 
tells you more about how to view the software you are writing at a small scale, 
and it tells you how to build a mental image of your programs. 

In any case, you can use established principles in Clojure programming that 
transcends language paradigms, e.g., hiding implementation details, creating 
well-defined interfaces and data structures, separating concerns (making things 
simple, as they say in the Clojure community). 

If you are hoping to find a feature set in Clojure that matches what you are 
already familiar with, you may end up disappointed. Is Clojure the right 
language for you? It probably depends mostly on personal taste and willingness 
to change perspective.

Best regards,
Patrick

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is Clojure right for me?

[Jeff Heon]

Given your goals of evaluating the language quickly, not having a lot of 
free time to devote to it, and having to get productive fast in a web 
environment,
I think a better avenue to explore would be 
Groovyalongside Spring 
Bootor
 
Ratpack .

It's concise, close to Java OO, and yet have functional programming 
features and metaprogramming facilities.

On Friday, December 27, 2013 7:54:44 AM UTC-5, Massimiliano Tomassoli wrote:
>
> The point is that Clojure is not the only modern language out there. I 
> can't possibly learn them all in depth just to decide which language to use 
> for my production code. That would be time-inefficient because my goal in 
> not to learn languages, but to pick up a new language suitable for my needs.
>
>>
>>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is Clojure right for me?

[Luc Prefontaine]

Been writing these on my iPhone most of the day and if I do not cut
lines myself, it looks pretty ugly
on my side :)

I am pretty bad at writing poetry,
glad to see I could fake at it :)

Luc P.


> Luc, I've just got to say, your tiny margin widths always make me think
> your message is some kind of haiku :)
> 
> 
> On Fri, Dec 27, 2013 at 1:08 PM, Luc Prefontaine <
> lprefonta...@softaddicts.ca> wrote:
> 
> > I am kind of old school.
> > To me these things come through
> > practice...
> >
> > Which I understand maybe of little
> > help to you in the immediate
> > future :)
> >
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
--
Luc Prefontaine sent by ibisMail!

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Clojure can't import some Java classes

[Zach Oakes]

Yeah I tried this with RoboVM, but there are so many classes that needed to 
be stubbed that it turned into an endless rabbit hole, so I gave up. It may 
be a good solution for those who just have one or two problematic classes, 
though.

On Thursday, December 26, 2013 8:37:44 PM UTC-5, Colin Fleming wrote:
>
> In case anyone is interested in a workaround for this, I managed to "fix" 
> my compilation by stubbing out the problematic classes and putting the 
> stubs ahead of the real classes in the classpath when I compile. Where 
> those stubs return other objects that are required during static 
> initialisation, I create those classes with Mockito. I feel dirty all over 
> but it does work.
>
> I'm also tinkering with a fork of Clojure in the background that uses ASM 
> Types instead of Class objects. It's still a long way from done but it's 
> looking like that might provide a solution for compilation, at least. I'll 
> report back if I ever get it working.
>
>
> On 15 December 2013 14:05, Colin Fleming 
> > wrote:
>
>> I've just spent some time today looking at the compiler code, and 
>> unfortunately I think the answer is "no". When a symbol is imported, 
>> Clojure currently instantiates the Class object using Class.forName() and 
>> stores that in the namespace's mapping. At the point the Class is 
>> instantiated, static initializers are run. So the only way to avoid that is 
>> not instantiate the Class and store something else in the mapping. 
>>
>> Alex's suggestion above to store the string representing the class name 
>> and load the class on demand might work for REPL style development but 
>> won't work for AOT compilation since reflection is used to find fields, 
>> methods etc on the class during compilation. The only solution that I can 
>> see that would work for AOT would be to store some sort of class wrapper 
>> object which reads the class bytecode to get that information without 
>> instantiating the class.
>>
>> However both of these suggestions break a fairly fundamental assumption - 
>> that importing a class creates a mapping from its name to a Class object. I 
>> have no idea what sort of code might be out there making that assumption, 
>> but it's probably fair to assume there could be a lot of it. At some point 
>> I might look into creating a fork of Clojure I just use to AOT compile.
>>
>>
>> On 12 December 2013 03:41, Robin Heggelund Hansen 
>> 
>> > wrote:
>>
>>> Is this something that is fixable?
>>>
>>> -- 
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com 
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com .
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Namespaces [was Re: Is Clojure right for me?]

[Timothy Baldridge]

+1 for Stuart's component lib. I've been using it a lot in my day job and
it works quite well. It also serves as a reminder not to throw global
config values into vars. Building code that works well with the library
makes it less natural to put random state values in globals.

Timothy



On Fri, Dec 27, 2013 at 1:25 PM, Cedric Greevey  wrote:

> On Fri, Dec 27, 2013 at 3:13 PM, john walker wrote:
>
>> This works (clever hack!), but you would have to reduplicate the keys in
>> (defn bar [..]...), (defn baz [...] ...) etc.
>>
>
> (defmacro defthingyfn [name arglist & body]
>   `(defn name ~(vec (cons '{:keys [thingy mumble fiddly]} arglist))
> ~@body))
>
> (defthingyfn foo [x]
>
>   (...thingy ... mumble ... fiddly ... mumble ... mumble ... x ... thingy
> ...))
>
> (defthingyfn bar [x]
>   (...mumble ... thingy ... mumble ... mumble ... x ... thingy ... fiddly
> ... thingy ...))
>
> ...
>
> (Extending that to cope with docstrings and multiple arities is left as an
> exercise for the reader. :))
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: In your opinion, what's the best, and what's the worst aspects of using Clojure?

[Daniel]

Best: Language & Community
Worst: Error Reporting

On Friday, December 27, 2013 3:17:48 PM UTC-6, Kelker Ryan wrote:
>
> In your opinion, what's the best, and what's the worst aspects of using 
> Clojure? 
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Akka-like framework in Clojure ?

[Paulo Suzart]

Hi,

Am I wrong or Galaxy project (behind pulsar) is quite inactive? Does
anybody know how promising are they?

Cheers


On 27 December 2013 17:32, Bruno Kim Medeiros Cesar
wrote:

> I haven't dabbled yet on actor-based concurrency, can someone point out (a
> blog post about) a comparison between Akka actors, Clojure agents and other
> solutions?
>
>
> On Friday, December 27, 2013 6:54:16 AM UTC-2, Eric Le Goff wrote:
>>
>>
>> Hi,
>>
>> After a long background with imperative languages such as Java, I
>> recently spent some time learning functionnal programming, starting with
>> Scala. I had the opporrtunity to build a demo project based on the Akka
>> framework.
>>
>> Now I am starting learning Clojure, and would be curious to know if there
>> was some clojure based framework available which could implement rather
>> similar features to Akka.
>>
>> In particular, I would be interested in an implementation of the Actor
>> Model [1]
>>
>> Thanks.
>>
>> Eric
>>
>>
>> [1] http://en.wikipedia.org/wiki/Actor_model
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
Paulo Suzart
@paulosuzart

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Akka-like framework in Clojure ?

[Alex Baranosky]

You can just use Akka directly w/ Clojure's excellent Java interop.


On Fri, Dec 27, 2013 at 3:48 PM, Paulo Suzart  wrote:

> Hi,
>
> Am I wrong or Galaxy project (behind pulsar) is quite inactive? Does
> anybody know how promising are they?
>
> Cheers
>
>
> On 27 December 2013 17:32, Bruno Kim Medeiros Cesar  > wrote:
>
>> I haven't dabbled yet on actor-based concurrency, can someone point out
>> (a blog post about) a comparison between Akka actors, Clojure agents and
>> other solutions?
>>
>>
>> On Friday, December 27, 2013 6:54:16 AM UTC-2, Eric Le Goff wrote:
>>>
>>>
>>> Hi,
>>>
>>> After a long background with imperative languages such as Java, I
>>> recently spent some time learning functionnal programming, starting with
>>> Scala. I had the opporrtunity to build a demo project based on the Akka
>>> framework.
>>>
>>> Now I am starting learning Clojure, and would be curious to know if
>>> there was some clojure based framework available which could implement
>>> rather similar features to Akka.
>>>
>>> In particular, I would be interested in an implementation of the Actor
>>> Model [1]
>>>
>>> Thanks.
>>>
>>> Eric
>>>
>>>
>>> [1] http://en.wikipedia.org/wiki/Actor_model
>>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> --
> Paulo Suzart
> @paulosuzart
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Akka-like framework in Clojure ?

[Sean Corfield]

I got the impression - from talking to someone who tried to wrap Akka
in Clojure - that Akka's API was pretty nasty to use from Clojure?

Sean

On Fri, Dec 27, 2013 at 3:54 PM, Alex Baranosky
 wrote:
> You can just use Akka directly w/ Clojure's excellent Java interop.
>
>
> On Fri, Dec 27, 2013 at 3:48 PM, Paulo Suzart  wrote:
>>
>> Hi,
>>
>> Am I wrong or Galaxy project (behind pulsar) is quite inactive? Does
>> anybody know how promising are they?
>>
>> Cheers
>>
>>
>> On 27 December 2013 17:32, Bruno Kim Medeiros Cesar
>>  wrote:
>>>
>>> I haven't dabbled yet on actor-based concurrency, can someone point out
>>> (a blog post about) a comparison between Akka actors, Clojure agents and
>>> other solutions?
>>>
>>>
>>> On Friday, December 27, 2013 6:54:16 AM UTC-2, Eric Le Goff wrote:


 Hi,

 After a long background with imperative languages such as Java, I
 recently spent some time learning functionnal programming, starting with
 Scala. I had the opporrtunity to build a demo project based on the Akka
 framework.

 Now I am starting learning Clojure, and would be curious to know if
 there was some clojure based framework available which could implement
 rather similar features to Akka.

 In particular, I would be interested in an implementation of the Actor
 Model [1]

 Thanks.

 Eric


 [1] http://en.wikipedia.org/wiki/Actor_model
>>>
>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google Groups
>>> "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>>
>> --
>> Paulo Suzart
>> @paulosuzart
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.



-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

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

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Namespaces [was Re: Is Clojure right for me?]

[James Reeves]

On 27 December 2013 18:08, Mark Engelberg  wrote:
>
> On Fri, Dec 27, 2013 at 6:34 AM, Stuart Halloway <
> stuart.hallo...@gmail.com> wrote:
>
>> Yes, thanks Mark. It seems to me that you are saying "namespaces make
>> poor maps".  Stipulated.  So why not use records or maps?
>>
>
> This is close, but not exactly what I'm saying.  It's not so much about
> wanting namespaces to be maps.  It's about wanting a robust mechanism for
> functions to share information other than threading that information
> through the functions.
>
> In Structure and Interpretation of Computer Programming, a large chunk of
> the programs are written in a pseudo-object-oriented style, a style which
> simulates objects by having functions' closures share the same local
> context.
>

What sort of local context did you imagine sharing?

I can't think of any instance where I've needed to share the *same* context
between functions. I find that internal functions will typically end up
with a small subset of the configuration passed to a top-level component.

It's also fairly rare that I find any configuration placed in var, as
generally the configuration I deal with are specific to a particular
deployment, such as database URLs, API keys and the like.

- James

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How do I serve clojure pages with nginx

[Zeynel]

Thank you, this is great, exactly what I was looking for. I had a few 
issues but I solved them and it is all set as you described, but I am 
unable to run it with $ start .

I created /etc/init/nomilkfor.me.conf (this is the domain name) and this is 
what is in the file:

description "ubuntu 13.10 on Samsung laptop"
author "zeynel"
   
start on startup
stop on shutdown
   
setuid deploy
chdir /deploy
console log
   
env PORT=4000
exec java -jar my-webapp-0.1.0-standalone.jar

I reload nginx with

$ sudo nginx -s reload

and I try

$ start nomilkfor.me

but I get 

start: Unknown job: nomilkfor.me

It looks like I am doing something wrong with the conf file. Any ideas? 
Thanks again. I hope this will work.


On Wednesday, December 25, 2013 10:06:58 AM UTC-4, James Reeves wrote:
>
> I currently serve a web app on a Ubuntu server. Here's the configuration I 
> use:
>
> In "/etc/nginx/sites-available/":
>
> server {
> listen 80;
>
> location / {
> proxy_set_header  X-Real-IP$remote_addr;
> proxy_set_header  X-Forwarded-For  $proxy_add_x_forwarded_for;
> proxy_set_header  Host $http_host;
> proxy_redirectoff;
>  proxy_passhttp://127.0.0.1:4000;
> }
> }
>
>
> Then I enable this configuration by adding a symbolic link:
>
> cd /etc/nginx/sites-enabled
> ln -s  ../sites-available/
>
>
> Then I create an upstart job to run the server in 
> "/etc/init/.conf:
>
> description ""
> author ""
>
> start on startup
> stop on shutdown
>
> setuid deploy
> chdir /deploy
> console log
>
> env PORT=4000
> exec java -jar .jar
>
>
> The jar file I place in "/deploy", a directory I've added in at the top 
> level.
>
> If all goes according to plan, then I can reload nginx and start my server:
>
> reload nginx
>
> start 
>
>
> Hope that helps.
>
> - James
>
>
>
> On 25 December 2013 11:42, Zeynel > wrote:
>
>> Ok, I worked through the tutorial referenced 
>> http://clojure-doc.org/articles/tutorials/basic_web_development.html#build-and-run-itand
>>  I created a jar file and ran it with $ java -jar -my-webapp.jar. This 
>> works. But my understanding is that this is would not work for production. 
>> I need to use nginx as proxy to jetty (or immutant?). I am trying to figure 
>> out the correct configuration for jetty and nginx. Each tutorial appears to 
>> be different and so far I couldn't make it work.
>>
>>
>> On Friday, December 20, 2013 9:39:07 AM UTC-4, David Della Costa wrote:
>>
>>> Hi Zeynel, 
>>>
>>> I don't know if setting things up the way I've laid out there is such a 
>>> great idea.  What I would do instead is set the port and whatnot in the 
>>> jetty configuration inside of ring, assuming that's what you're using 
>>> (this assumes a lot about how your app is set up, so let me know if this 
>>> doesn't match your setup): 
>>>
>>> http://ring-clojure.github.io/ring/ring.adapter.jetty.html 
>>>
>>> Then, I would compile an uberjar with lein, like so: 
>>>
>>> $ lein uberjar 
>>>
>>> In your startup script, as Curtis laid out, call the jar file using 
>>> something like: 
>>>
>>> /path/to/java -jar /path/to/uberjar 
>>>
>>> That will be much simpler than what I have in my tutorial...which I 
>>> should really update, now that you mention it! 
>>>
>>> DD 
>>>
>>> (2013/12/19 9:28), Zeynel wrote: 
>>> > I am following your tutorial, but I am stuck with Jetty configuration. 
>>> > My installation does not seem to have a /contexts directory. Where is 
>>> it? 
>>> > 
>>> > On Tuesday, December 17, 2013 9:02:19 AM UTC-4, David Della Costa 
>>> wrote: 
>>> > 
>>> > I have not done this specifically with Nginx but I suspect you 
>>> probably 
>>> > want something like what I set up with Apache + Jetty: 
>>> > 
>>> > https://github.com/ddellacosta/Clojure-under-
>>> Jetty-and-Apache#setting-up-jetty-with-apache-httpd 
>>> > >> Jetty-and-Apache#setting-up-jetty-with-apache-httpd> 
>>> > 
>>> > 
>>> > That is, set up Nginx to act as a proxy for Jetty: 
>>> > 
>>> > http://nginx.org/en/docs/beginners_guide.html#proxy 
>>> >  
>>> > 
>>> > One difference with how I would do it these days (vs. what I wrote 
>>> in 
>>> > the piece above) is that I would probably simply push out an 
>>> uberjar 
>>> > with lein which I would run with Java via an init script--for 
>>> example, 
>>> > if using Ubuntu: 
>>> > 
>>> > http://upstart.ubuntu.com/cookbook/#run-a-java-application 
>>> >  
>>> > 
>>> > So, I would imagine the basic construction would be something 
>>> like: 
>>> > ring 
>>> > app w/jetty or http-kit, packaged as an uberjar (lein uberjar), 
>>> then 
>>> > set 
>>> > up to

Re: Is Clojure right for me?

[Massimiliano Tomassoli]

On Friday, December 27, 2013 10:07:14 PM UTC+1, Sean Corfield wrote:
>
> On Fri, Dec 27, 2013 at 12:24 PM, Massimiliano Tomassoli 
> > So I was under the impression that you were criticizing something you 
> didn't 
> > fully understand. 
>
> Perhaps you've been convinced otherwise now? I feel that I understand 
> OOP pretty well after two decades of using several OOP languages to 
> deliver production systems - and helping to design parts of C++, and 
> building a C++ compiler :) 
>

Yes. I wasn't speaking of you in particular and mine was just a first 
impression.
Now I'm ready to start learning Clojure and find out if it is really as 
powerful as you say. I must admit I don't like its syntax (or absence of 
it), but I hope to get used to it.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is Clojure right for me?

[Massimiliano Tomassoli]

On Friday, December 27, 2013 10:12:06 PM UTC+1, john walker wrote:
>
> What are some flaws that you think Clojure has? : )
>

I don't even know the language yet! :)

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Clojure can't import some Java classes

[Aaron Cohen]

I have the sneaking suspicion that this may be as simple as changing

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L697

to:

final static Method forNameMethod = Method.getMethod("Class
*classForNameNonLoading*(String)");


and making "classForNameNonLoading" public at
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L2074

static *public *Class classForNameNonLoading(String name)


I should try it myself, but may not get to it this weekend.


On Fri, Dec 27, 2013 at 5:19 PM, Zach Oakes  wrote:

> Yeah I tried this with RoboVM, but there are so many classes that needed
> to be stubbed that it turned into an endless rabbit hole, so I gave up. It
> may be a good solution for those who just have one or two problematic
> classes, though.
>
>
> On Thursday, December 26, 2013 8:37:44 PM UTC-5, Colin Fleming wrote:
>
>> In case anyone is interested in a workaround for this, I managed to "fix"
>> my compilation by stubbing out the problematic classes and putting the
>> stubs ahead of the real classes in the classpath when I compile. Where
>> those stubs return other objects that are required during static
>> initialisation, I create those classes with Mockito. I feel dirty all over
>> but it does work.
>>
>> I'm also tinkering with a fork of Clojure in the background that uses ASM
>> Types instead of Class objects. It's still a long way from done but it's
>> looking like that might provide a solution for compilation, at least. I'll
>> report back if I ever get it working.
>>
>>
>> On 15 December 2013 14:05, Colin Fleming  wrote:
>>
>>> I've just spent some time today looking at the compiler code, and
>>> unfortunately I think the answer is "no". When a symbol is imported,
>>> Clojure currently instantiates the Class object using Class.forName() and
>>> stores that in the namespace's mapping. At the point the Class is
>>> instantiated, static initializers are run. So the only way to avoid that is
>>> not instantiate the Class and store something else in the mapping.
>>>
>>> Alex's suggestion above to store the string representing the class name
>>> and load the class on demand might work for REPL style development but
>>> won't work for AOT compilation since reflection is used to find fields,
>>> methods etc on the class during compilation. The only solution that I can
>>> see that would work for AOT would be to store some sort of class wrapper
>>> object which reads the class bytecode to get that information without
>>> instantiating the class.
>>>
>>> However both of these suggestions break a fairly fundamental assumption
>>> - that importing a class creates a mapping from its name to a Class object.
>>> I have no idea what sort of code might be out there making that assumption,
>>> but it's probably fair to assume there could be a lot of it. At some point
>>> I might look into creating a fork of Clojure I just use to AOT compile.
>>>
>>>
>>> On 12 December 2013 03:41, Robin Heggelund Hansen wrote:
>>>
 Is this something that is fixable?

 --
 --
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To post to this group, send email to clo...@googlegroups.com

 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+u...@googlegroups.com

 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to clojure+u...@googlegroups.com.

 For more options, visit https://groups.google.com/groups/opt_out.

>>>
>>>
>>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?h

Re: How do I serve clojure pages with nginx

[James Reeves]

Perhaps try nomilkforme.conf instead of nomilkfor.me.conf ?

- James


On 28 December 2013 00:27, Zeynel  wrote:

> Thank you, this is great, exactly what I was looking for. I had a few
> issues but I solved them and it is all set as you described, but I am
> unable to run it with $ start .
>
> I created /etc/init/nomilkfor.me.conf (this is the domain name) and this
> is what is in the file:
>
> description "ubuntu 13.10 on Samsung laptop"
> author "zeynel"
>
> start on startup
> stop on shutdown
>
> setuid deploy
> chdir /deploy
> console log
>
> env PORT=4000
> exec java -jar my-webapp-0.1.0-standalone.jar
>
> I reload nginx with
>
> $ sudo nginx -s reload
>
> and I try
>
> $ start nomilkfor.me
>
> but I get
>
> start: Unknown job: nomilkfor.me
>
> It looks like I am doing something wrong with the conf file. Any ideas?
> Thanks again. I hope this will work.
>
>
> On Wednesday, December 25, 2013 10:06:58 AM UTC-4, James Reeves wrote:
>
>> I currently serve a web app on a Ubuntu server. Here's the configuration
>> I use:
>>
>> In "/etc/nginx/sites-available/":
>>
>>  server {
>> listen 80;
>>
>> location / {
>> proxy_set_header  X-Real-IP$remote_addr;
>> proxy_set_header  X-Forwarded-For  $proxy_add_x_forwarded_for;
>> proxy_set_header  Host $http_host;
>> proxy_redirectoff;
>>  proxy_passhttp://127.0.0.1:4000;
>> }
>>  }
>>
>>
>> Then I enable this configuration by adding a symbolic link:
>>
>> cd /etc/nginx/sites-enabled
>> ln -s  ../sites-available/
>>
>>
>> Then I create an upstart job to run the server in
>> "/etc/init/.conf:
>>
>> description ""
>> author ""
>>
>> start on startup
>> stop on shutdown
>>
>> setuid deploy
>> chdir /deploy
>> console log
>>
>> env PORT=4000
>> exec java -jar .jar
>>
>>
>> The jar file I place in "/deploy", a directory I've added in at the top
>> level.
>>
>> If all goes according to plan, then I can reload nginx and start my
>> server:
>>
>> reload nginx
>>
>> start 
>>
>>
>> Hope that helps.
>>
>> - James
>>
>>
>>
>> On 25 December 2013 11:42, Zeynel  wrote:
>>
>>> Ok, I worked through the tutorial referenced http://clojure-doc.
>>> org/articles/tutorials/basic_web_development.html#build-and-run-it and
>>> I created a jar file and ran it with $ java -jar -my-webapp.jar. This
>>> works. But my understanding is that this is would not work for production.
>>> I need to use nginx as proxy to jetty (or immutant?). I am trying to figure
>>> out the correct configuration for jetty and nginx. Each tutorial appears to
>>> be different and so far I couldn't make it work.
>>>
>>>
>>> On Friday, December 20, 2013 9:39:07 AM UTC-4, David Della Costa wrote:
>>>
 Hi Zeynel,

 I don't know if setting things up the way I've laid out there is such a
 great idea.  What I would do instead is set the port and whatnot in the
 jetty configuration inside of ring, assuming that's what you're using
 (this assumes a lot about how your app is set up, so let me know if
 this
 doesn't match your setup):

 http://ring-clojure.github.io/ring/ring.adapter.jetty.html

 Then, I would compile an uberjar with lein, like so:

 $ lein uberjar

 In your startup script, as Curtis laid out, call the jar file using
 something like:

 /path/to/java -jar /path/to/uberjar

 That will be much simpler than what I have in my tutorial...which I
 should really update, now that you mention it!

 DD

 (2013/12/19 9:28), Zeynel wrote:
 > I am following your tutorial, but I am stuck with Jetty
 configuration.
 > My installation does not seem to have a /contexts directory. Where is
 it?
 >
 > On Tuesday, December 17, 2013 9:02:19 AM UTC-4, David Della Costa
 wrote:
 >
 > I have not done this specifically with Nginx but I suspect you
 probably
 > want something like what I set up with Apache + Jetty:
 >
 > https://github.com/ddellacosta/Clojure-under-Jetty-and-
 Apache#setting-up-jetty-with-apache-httpd
 > 
 >
 >
 > That is, set up Nginx to act as a proxy for Jetty:
 >
 > http://nginx.org/en/docs/beginners_guide.html#proxy
 > 
 >
 > One difference with how I would do it these days (vs. what I
 wrote in
 > the piece above) is that I would probably simply push out an
 uberjar
 > with lein which I would run with Java via an init script--for
 example,
 > if using Ubuntu:
 >
 > http://upstart.ubuntu.com/cookbook/#run-a-java-application
 > 
 >
 > So, I would imagine the basic construction would be something
 like:
 > ring
 > 

Re: Is Clojure right for me?

[Massimiliano Tomassoli]

On Friday, December 27, 2013 10:47:35 PM UTC+1, Jeff Heon wrote:
>
> Given your goals of evaluating the language quickly, not having a lot of 
> free time to devote to it, and having to get productive fast in a web 
> environment,
> I think a better avenue to explore would be 
> Groovyalongside Spring 
> Bootor
>  
> Ratpack .
>
> It's concise, close to Java OO, and yet have functional programming 
> features and metaprogramming facilities.
>
>
I already know Python. As my next language I want to try something 
radically different like F#, Scala or Clojure, but thanks for the 
suggestion.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is Clojure right for me?

[Mars0i]

On Friday, December 27, 2013 6:27:34 PM UTC-6, Massimiliano Tomassoli wrote:
>
> I must admit I don't like its syntax (or absence of it), but I hope to get 
>> used to it.
>>
>
This is understandable.   I think that the things that are most important 
for becoming comfortable with the syntax, other than experience, are using 
an editor that matches parentheses, and learning (Clojure-style) Lisp 
pretty-printing.  If you can use an editor that has a plugin that will do 
the pretty-printing for you, that's even better.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How do I serve clojure pages with nginx

[Ahmet Zeynel]

I just tried it but I got the same error. Do I need to add exec or script
in the conf file? Thanks.


On Fri, Dec 27, 2013 at 9:20 PM, James Reeves  wrote:

> Perhaps try nomilkforme.conf instead of nomilkfor.me.conf ?
>
> - James
>
>
> On 28 December 2013 00:27, Zeynel  wrote:
>
>> Thank you, this is great, exactly what I was looking for. I had a few
>> issues but I solved them and it is all set as you described, but I am
>> unable to run it with $ start .
>>
>> I created /etc/init/nomilkfor.me.conf (this is the domain name) and this
>> is what is in the file:
>>
>> description "ubuntu 13.10 on Samsung laptop"
>> author "zeynel"
>>
>> start on startup
>> stop on shutdown
>>
>> setuid deploy
>> chdir /deploy
>> console log
>>
>> env PORT=4000
>> exec java -jar my-webapp-0.1.0-standalone.jar
>>
>> I reload nginx with
>>
>> $ sudo nginx -s reload
>>
>> and I try
>>
>> $ start nomilkfor.me
>>
>> but I get
>>
>> start: Unknown job: nomilkfor.me
>>
>> It looks like I am doing something wrong with the conf file. Any ideas?
>> Thanks again. I hope this will work.
>>
>>
>> On Wednesday, December 25, 2013 10:06:58 AM UTC-4, James Reeves wrote:
>>
>>> I currently serve a web app on a Ubuntu server. Here's the configuration
>>> I use:
>>>
>>> In "/etc/nginx/sites-available/":
>>>
>>>  server {
>>> listen 80;
>>>
>>> location / {
>>> proxy_set_header  X-Real-IP$remote_addr;
>>> proxy_set_header  X-Forwarded-For  $proxy_add_x_forwarded_for;
>>> proxy_set_header  Host $http_host;
>>> proxy_redirectoff;
>>>  proxy_passhttp://127.0.0.1:4000;
>>> }
>>>  }
>>>
>>>
>>> Then I enable this configuration by adding a symbolic link:
>>>
>>> cd /etc/nginx/sites-enabled
>>> ln -s  ../sites-available/
>>>
>>>
>>> Then I create an upstart job to run the server in
>>> "/etc/init/.conf:
>>>
>>> description ""
>>> author ""
>>>
>>> start on startup
>>> stop on shutdown
>>>
>>> setuid deploy
>>> chdir /deploy
>>> console log
>>>
>>> env PORT=4000
>>> exec java -jar .jar
>>>
>>>
>>> The jar file I place in "/deploy", a directory I've added in at the top
>>> level.
>>>
>>> If all goes according to plan, then I can reload nginx and start my
>>> server:
>>>
>>> reload nginx
>>>
>>> start 
>>>
>>>
>>> Hope that helps.
>>>
>>> - James
>>>
>>>
>>>
>>> On 25 December 2013 11:42, Zeynel  wrote:
>>>
 Ok, I worked through the tutorial referenced http://clojure-doc.
 org/articles/tutorials/basic_web_development.html#build-and-run-it and
 I created a jar file and ran it with $ java -jar -my-webapp.jar. This
 works. But my understanding is that this is would not work for production.
 I need to use nginx as proxy to jetty (or immutant?). I am trying to figure
 out the correct configuration for jetty and nginx. Each tutorial appears to
 be different and so far I couldn't make it work.


 On Friday, December 20, 2013 9:39:07 AM UTC-4, David Della Costa wrote:

> Hi Zeynel,
>
> I don't know if setting things up the way I've laid out there is such
> a
> great idea.  What I would do instead is set the port and whatnot in
> the
> jetty configuration inside of ring, assuming that's what you're using
> (this assumes a lot about how your app is set up, so let me know if
> this
> doesn't match your setup):
>
> http://ring-clojure.github.io/ring/ring.adapter.jetty.html
>
> Then, I would compile an uberjar with lein, like so:
>
> $ lein uberjar
>
> In your startup script, as Curtis laid out, call the jar file using
> something like:
>
> /path/to/java -jar /path/to/uberjar
>
> That will be much simpler than what I have in my tutorial...which I
> should really update, now that you mention it!
>
> DD
>
> (2013/12/19 9:28), Zeynel wrote:
> > I am following your tutorial, but I am stuck with Jetty
> configuration.
> > My installation does not seem to have a /contexts directory. Where
> is it?
> >
> > On Tuesday, December 17, 2013 9:02:19 AM UTC-4, David Della Costa
> wrote:
> >
> > I have not done this specifically with Nginx but I suspect you
> probably
> > want something like what I set up with Apache + Jetty:
> >
> > https://github.com/ddellacosta/Clojure-under-Jetty-and-
> Apache#setting-up-jetty-with-apache-httpd
> >  Apache#setting-up-jetty-with-apache-httpd>
> >
> >
> > That is, set up Nginx to act as a proxy for Jetty:
> >
> > http://nginx.org/en/docs/beginners_guide.html#proxy
> > 
> >
> > One difference with how I would do it these days (vs. what I
> wrote in
> > the piece above) is that I would probably simply push out an
> uberjar
> > with lein which I would run w

Re: How do I serve clojure pages with nginx

[James Reeves]

The script looks fine... Are you executing "start nomilkforme" as root or
with sudo? Do you have a "deploy" user and a "/deploy" directory?

- James


On 28 December 2013 01:33, Ahmet Zeynel  wrote:

> I just tried it but I got the same error. Do I need to add exec or script
> in the conf file? Thanks.
>
>
> On Fri, Dec 27, 2013 at 9:20 PM, James Reeves wrote:
>
>> Perhaps try nomilkforme.conf instead of nomilkfor.me.conf ?
>>
>> - James
>>
>>
>> On 28 December 2013 00:27, Zeynel  wrote:
>>
>>> Thank you, this is great, exactly what I was looking for. I had a few
>>> issues but I solved them and it is all set as you described, but I am
>>> unable to run it with $ start .
>>>
>>> I created /etc/init/nomilkfor.me.conf (this is the domain name) and this
>>> is what is in the file:
>>>
>>> description "ubuntu 13.10 on Samsung laptop"
>>> author "zeynel"
>>>
>>> start on startup
>>> stop on shutdown
>>>
>>> setuid deploy
>>> chdir /deploy
>>> console log
>>>
>>> env PORT=4000
>>> exec java -jar my-webapp-0.1.0-standalone.jar
>>>
>>> I reload nginx with
>>>
>>> $ sudo nginx -s reload
>>>
>>> and I try
>>>
>>> $ start nomilkfor.me
>>>
>>> but I get
>>>
>>> start: Unknown job: nomilkfor.me
>>>
>>> It looks like I am doing something wrong with the conf file. Any ideas?
>>> Thanks again. I hope this will work.
>>>
>>>
>>> On Wednesday, December 25, 2013 10:06:58 AM UTC-4, James Reeves wrote:
>>>
 I currently serve a web app on a Ubuntu server. Here's the
 configuration I use:

 In "/etc/nginx/sites-available/":

  server {
 listen 80;

 location / {
 proxy_set_header  X-Real-IP$remote_addr;
 proxy_set_header  X-Forwarded-For  $proxy_add_x_forwarded_for;
 proxy_set_header  Host $http_host;
 proxy_redirectoff;
  proxy_passhttp://127.0.0.1:4000;
 }
  }


 Then I enable this configuration by adding a symbolic link:

 cd /etc/nginx/sites-enabled
 ln -s  ../sites-available/


 Then I create an upstart job to run the server in
 "/etc/init/.conf:

 description ""
 author ""

 start on startup
 stop on shutdown

 setuid deploy
 chdir /deploy
 console log

 env PORT=4000
 exec java -jar .jar


 The jar file I place in "/deploy", a directory I've added in at the top
 level.

 If all goes according to plan, then I can reload nginx and start my
 server:

 reload nginx

 start 


 Hope that helps.

 - James



 On 25 December 2013 11:42, Zeynel  wrote:

> Ok, I worked through the tutorial referenced http://clojure-doc.
> org/articles/tutorials/basic_web_development.html#build-and-run-itand I 
> created a jar file and ran it with $ java -jar -my-webapp.jar. This
> works. But my understanding is that this is would not work for production.
> I need to use nginx as proxy to jetty (or immutant?). I am trying to 
> figure
> out the correct configuration for jetty and nginx. Each tutorial appears 
> to
> be different and so far I couldn't make it work.
>
>
> On Friday, December 20, 2013 9:39:07 AM UTC-4, David Della Costa wrote:
>
>> Hi Zeynel,
>>
>> I don't know if setting things up the way I've laid out there is such
>> a
>> great idea.  What I would do instead is set the port and whatnot in
>> the
>> jetty configuration inside of ring, assuming that's what you're using
>> (this assumes a lot about how your app is set up, so let me know if
>> this
>> doesn't match your setup):
>>
>> http://ring-clojure.github.io/ring/ring.adapter.jetty.html
>>
>> Then, I would compile an uberjar with lein, like so:
>>
>> $ lein uberjar
>>
>> In your startup script, as Curtis laid out, call the jar file using
>> something like:
>>
>> /path/to/java -jar /path/to/uberjar
>>
>> That will be much simpler than what I have in my tutorial...which I
>> should really update, now that you mention it!
>>
>> DD
>>
>> (2013/12/19 9:28), Zeynel wrote:
>> > I am following your tutorial, but I am stuck with Jetty
>> configuration.
>> > My installation does not seem to have a /contexts directory. Where
>> is it?
>> >
>> > On Tuesday, December 17, 2013 9:02:19 AM UTC-4, David Della Costa
>> wrote:
>> >
>> > I have not done this specifically with Nginx but I suspect you
>> probably
>> > want something like what I set up with Apache + Jetty:
>> >
>> > https://github.com/ddellacosta/Clojure-under-Jetty-and-
>> Apache#setting-up-jetty-with-apache-httpd
>> > > Apache#setting-up-jetty-with-apache-httpd>
>> >
>> >
>> > That is, set up Nginx to act

Re: Is Clojure right for me?

[Massimiliano Tomassoli]

On Saturday, December 28, 2013 2:26:17 AM UTC+1, Mars0i wrote:
>
> On Friday, December 27, 2013 6:27:34 PM UTC-6, Massimiliano Tomassoli 
> wrote:
>>
>> I must admit I don't like its syntax (or absence of it), but I hope to 
>>> get used to it.
>>>
>>
> This is understandable.   I think that the things that are most important 
> for becoming comfortable with the syntax, other than experience, are using 
> an editor that matches parentheses, and learning (Clojure-style) Lisp 
> pretty-printing.  If you can use an editor that has a plugin that will do 
> the pretty-printing for you, that's even better.
>

I'm using eclipse + counterclockwise. 

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: In your opinion, what's the best, and what's the worst aspects of using Clojure?

[Guru Devanla]

Seconded on Error reporting.

I have been playing around with Clojure for sometime now and also completed
almost 150 of the 4clojure problems. What still scars me in terms of
incorporating Clojure as a language of choice in more complicated projects
I work on in my other life, is the error reporting facility. The errors
sometimes might as well just say 'I just cannot run!'.  It would be nice if
there was some facility to approximately point to some s-exp or line
numbers.

May be I am missing some workflow used by other expert users. Can someone
throw more light on this.


Thanks
Guru


On Fri, Dec 27, 2013 at 3:44 PM, Daniel  wrote:

> Best: Language & Community
> Worst: Error Reporting
>
>
> On Friday, December 27, 2013 3:17:48 PM UTC-6, Kelker Ryan wrote:
>>
>> In your opinion, what's the best, and what's the worst aspects of using
>> Clojure?
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: In your opinion, what's the best, and what's the worst aspects of using Clojure?

[Guru Devanla]

Ok, wanted to be clear that I do support the Best part of language so far
has been the Language itself and community!


On Fri, Dec 27, 2013 at 5:48 PM, Guru Devanla  wrote:

> Seconded on Error reporting.
>
> I have been playing around with Clojure for sometime now and also
> completed almost 150 of the 4clojure problems. What still scars me in terms
> of incorporating Clojure as a language of choice in more complicated
> projects I work on in my other life, is the error reporting facility. The
> errors sometimes might as well just say 'I just cannot run!'.  It would be
> nice if there was some facility to approximately point to some s-exp or
> line numbers.
>
> May be I am missing some workflow used by other expert users. Can someone
> throw more light on this.
>
>
> Thanks
> Guru
>
>
> On Fri, Dec 27, 2013 at 3:44 PM, Daniel  wrote:
>
>> Best: Language & Community
>> Worst: Error Reporting
>>
>>
>> On Friday, December 27, 2013 3:17:48 PM UTC-6, Kelker Ryan wrote:
>>>
>>> In your opinion, what's the best, and what's the worst aspects of using
>>> Clojure?
>>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How do I serve clojure pages with nginx

[Ahmet Zeynel]

I don't think I have a "deploy" user but I have a /deploy directory with
the following content:

z@ubuntu:/deploy$ ll
total 8164
drwxr-xr-x  2 zz   4096 Dec 27 08:20 ./
drwxr-xr-x 24 root root4096 Dec 27 08:09 ../
-rw-r--r--  1 zz8351715 Dec 27 08:20 my-webapp-0.1.0-standalone.jar

I tried "start nomilkforme" both with sudo and as root, I got the same
error with both. Thanks!


On Fri, Dec 27, 2013 at 9:44 PM, James Reeves  wrote:

> The script looks fine... Are you executing "start nomilkforme" as root or
> with sudo? Do you have a "deploy" user and a "/deploy" directory?
>
> - James
>
>
> On 28 December 2013 01:33, Ahmet Zeynel  wrote:
>
>> I just tried it but I got the same error. Do I need to add exec or script
>> in the conf file? Thanks.
>>
>>
>> On Fri, Dec 27, 2013 at 9:20 PM, James Reeves wrote:
>>
>>> Perhaps try nomilkforme.conf instead of nomilkfor.me.conf ?
>>>
>>> - James
>>>
>>>
>>> On 28 December 2013 00:27, Zeynel  wrote:
>>>
 Thank you, this is great, exactly what I was looking for. I had a few
 issues but I solved them and it is all set as you described, but I am
 unable to run it with $ start .

 I created /etc/init/nomilkfor.me.conf (this is the domain name) and
 this is what is in the file:

 description "ubuntu 13.10 on Samsung laptop"
 author "zeynel"

 start on startup
 stop on shutdown

 setuid deploy
 chdir /deploy
 console log

 env PORT=4000
 exec java -jar my-webapp-0.1.0-standalone.jar

 I reload nginx with

 $ sudo nginx -s reload

 and I try

 $ start nomilkfor.me

 but I get

 start: Unknown job: nomilkfor.me

 It looks like I am doing something wrong with the conf file. Any ideas?
 Thanks again. I hope this will work.


 On Wednesday, December 25, 2013 10:06:58 AM UTC-4, James Reeves wrote:

> I currently serve a web app on a Ubuntu server. Here's the
> configuration I use:
>
> In "/etc/nginx/sites-available/":
>
>  server {
> listen 80;
>
> location / {
> proxy_set_header  X-Real-IP$remote_addr;
> proxy_set_header  X-Forwarded-For  $proxy_add_x_forwarded_for;
> proxy_set_header  Host $http_host;
> proxy_redirectoff;
>  proxy_passhttp://127.0.0.1:4000;
> }
>  }
>
>
> Then I enable this configuration by adding a symbolic link:
>
> cd /etc/nginx/sites-enabled
> ln -s  ../sites-available/
>
>
> Then I create an upstart job to run the server in
> "/etc/init/.conf:
>
> description ""
> author ""
>
> start on startup
> stop on shutdown
>
> setuid deploy
> chdir /deploy
> console log
>
> env PORT=4000
> exec java -jar .jar
>
>
> The jar file I place in "/deploy", a directory I've added in at the
> top level.
>
> If all goes according to plan, then I can reload nginx and start my
> server:
>
> reload nginx
>
> start 
>
>
> Hope that helps.
>
> - James
>
>
>
> On 25 December 2013 11:42, Zeynel  wrote:
>
>> Ok, I worked through the tutorial referenced http://clojure-doc.
>> org/articles/tutorials/basic_web_development.html#build-and-run-itand I 
>> created a jar file and ran it with $ java -jar -my-webapp.jar. This
>> works. But my understanding is that this is would not work for 
>> production.
>> I need to use nginx as proxy to jetty (or immutant?). I am trying to 
>> figure
>> out the correct configuration for jetty and nginx. Each tutorial appears 
>> to
>> be different and so far I couldn't make it work.
>>
>>
>> On Friday, December 20, 2013 9:39:07 AM UTC-4, David Della Costa
>> wrote:
>>
>>> Hi Zeynel,
>>>
>>> I don't know if setting things up the way I've laid out there is
>>> such a
>>> great idea.  What I would do instead is set the port and whatnot in
>>> the
>>> jetty configuration inside of ring, assuming that's what you're
>>> using
>>> (this assumes a lot about how your app is set up, so let me know if
>>> this
>>> doesn't match your setup):
>>>
>>> http://ring-clojure.github.io/ring/ring.adapter.jetty.html
>>>
>>> Then, I would compile an uberjar with lein, like so:
>>>
>>> $ lein uberjar
>>>
>>> In your startup script, as Curtis laid out, call the jar file using
>>> something like:
>>>
>>> /path/to/java -jar /path/to/uberjar
>>>
>>> That will be much simpler than what I have in my tutorial...which I
>>> should really update, now that you mention it!
>>>
>>> DD
>>>
>>> (2013/12/19 9:28), Zeynel wrote:
>>> > I am following your tutorial, but I am stuck with Jetty
>>> configuration.
>>> > My insta

Re: Is Clojure right for me?

[Alexis Gallagher]

Hi Massimiliano,

Perhaps I'm a bit late to this thread but let me offer an opinion going in 
the opposite direction.

Basically, if the web development you have in mind fits squarely within the 
use case addressed by RoR or Django or something like that, then I expect 
you will find one of those frameworks is more productive than the Clojure 
web stack. The reason has nothing to do with FP vs OOP, or anything so 
grand. It's just that the Clojure web dev ecosystem doesn't offer the same 
depth of mature, ready-to-go components. I'm thinking of meat and potatoes 
things like administrative interfaces, user account management, user 
authentication systems, forgot-my-password workflows, etc.. Yes you can 
build what you need yourself. And, quite possibly, maybe you can build it 
from scratch in Clojure faster than in another language. But building it 
from scratch in Clojure will still be slower than downloading a widely-used 
framework in another language.

I expect this difference will be especially strong if you're working on 
relatively small projects with conventional requirements, since those are 
most likely to be handled by frameworks in other languages. As projects 
become larger and more customized, then Clojure becomes a better choice 
because of the strength of the language fundamentals.

All of this is not because Clojure is immature. It's just because it's not 
what most people are using the language for. I have the impression (I could 
be wrong) that more people use Clojure to build API endpoints, or to 
perform some kind of compute service behind an endpoint.

If you do want to go ahead with Clojure for web development, then there are 
a number of great projects that give good examples of the current state of 
things: luminusweb, caribou, pedestal, etc.. I also found that the books 
Clojure Programming and Web Development in Clojure both had good 
discussions of how to do it.

Anyway, this is the opinion I came to over the last couple months, diving 
into Clojure web development on a real project for the first time, after 
already being familiar with the language but new to its web stack. But I 
could be wrong. For instance, I've never used RoR seriously, so it may be 
I'm overestimating the quality of what you get "out of the box" doing it 
that way.

A

On Wednesday, December 25, 2013 1:06:20 PM UTC-8, Massimiliano Tomassoli 
wrote:
>
> Hi,
> I'm not sure if Clojure is the right language for me. I'd like to use 
> Clojure mainly for web development but I don't know if it's already mature 
> enough to be productive. For instance, Scala has Play, Groovy has Grails, 
> etc... If I'm not wrong, Clojure doesn't have a well-established framework 
> for web development. I'm intrigued by Clojure because I like functional 
> programming, but I need to be productive and, alas, I don't have time to 
> learn Clojure just for my pleasure.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How do I serve clojure pages with nginx

[Alexis Gallagher]

It's not free, but Kevin Lynagh sells a collection of nicely packaged and 
documented examples of basic dev ops setups. The package on server config 
illustrates exactly what you are asking for: deploying a Clojure web app 
behind nginx, with some monitoring, server-hardening, etc.. It's 
at: https://thedevop.com

A


On Tuesday, December 17, 2013 4:44:34 AM UTC-8, Zeynel wrote:
>
> I've set up a home server with ubuntu and nginx and I can serve static 
> pages. Now I want to add clojure but I am not sure what I need to do. I 
> asked the same question in StackOverflow but for some reason it is voted to 
> be closed: 
> http://stackoverflow.com/questions/20632987/how-to-serve-clojure-pages-with-nginx
>
> Can you please direct me to documentation where I can read about this? 
> Some issues that I don't understand are: how do I tell nginx that I am 
> using clojure? Where do I install clojure, in the server? Where do I create 
> the clojure files? Thanks.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

The SEO Holy Grail: shared client- and server-side rendering using Om/React.js

[Brendan Younger]

Hi all,

With David Nolen's recent announcement of Om, he hinted that it might be 
possible to some day use the same templating/rendering logic on the server 
as on the client.  I was inspired to see how possible this was and, after a 
few days of hacking on it, I'd like to share 
Omkara 
(https://github.com/brendanyounger/omkara) 
which shows how it can be done.

I'm hoping this repo can be a starting-off place for people looking to 
build a web-app based on Om/React.  This was my first serious foray into 
ClojureScript development, so bear with me if I did some things less than 
optimally.  That said, if you have any suggestions for improvement or 
clarification, please file a pull request.

Enjoy,
Brendan Younger

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Clojure can't import some Java classes

[Colin Fleming]

Wow, that works! You just saved me an extraordinary amount of pain - thank
you!

I had to make one further small change, to invoke the method on RT instead
of Class, but that was it.


On 28 December 2013 14:16, Aaron Cohen  wrote:

> I have the sneaking suspicion that this may be as simple as changing
>
>
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L697
>
> to:
>
> final static Method forNameMethod = Method.getMethod("Class
> *classForNameNonLoading*(String)");
>
>
> and making "classForNameNonLoading" public at
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L2074
>
> static *public *Class classForNameNonLoading(String name)
>
>
> I should try it myself, but may not get to it this weekend.
>
>
> On Fri, Dec 27, 2013 at 5:19 PM, Zach Oakes  wrote:
>
>> Yeah I tried this with RoboVM, but there are so many classes that needed
>> to be stubbed that it turned into an endless rabbit hole, so I gave up. It
>> may be a good solution for those who just have one or two problematic
>> classes, though.
>>
>>
>> On Thursday, December 26, 2013 8:37:44 PM UTC-5, Colin Fleming wrote:
>>
>>> In case anyone is interested in a workaround for this, I managed to
>>> "fix" my compilation by stubbing out the problematic classes and putting
>>> the stubs ahead of the real classes in the classpath when I compile. Where
>>> those stubs return other objects that are required during static
>>> initialisation, I create those classes with Mockito. I feel dirty all over
>>> but it does work.
>>>
>>> I'm also tinkering with a fork of Clojure in the background that uses
>>> ASM Types instead of Class objects. It's still a long way from done but
>>> it's looking like that might provide a solution for compilation, at least.
>>> I'll report back if I ever get it working.
>>>
>>>
>>> On 15 December 2013 14:05, Colin Fleming  wrote:
>>>
 I've just spent some time today looking at the compiler code, and
 unfortunately I think the answer is "no". When a symbol is imported,
 Clojure currently instantiates the Class object using Class.forName() and
 stores that in the namespace's mapping. At the point the Class is
 instantiated, static initializers are run. So the only way to avoid that is
 not instantiate the Class and store something else in the mapping.

 Alex's suggestion above to store the string representing the class name
 and load the class on demand might work for REPL style development but
 won't work for AOT compilation since reflection is used to find fields,
 methods etc on the class during compilation. The only solution that I can
 see that would work for AOT would be to store some sort of class wrapper
 object which reads the class bytecode to get that information without
 instantiating the class.

 However both of these suggestions break a fairly fundamental assumption
 - that importing a class creates a mapping from its name to a Class object.
 I have no idea what sort of code might be out there making that assumption,
 but it's probably fair to assume there could be a lot of it. At some point
 I might look into creating a fork of Clojure I just use to AOT compile.


 On 12 December 2013 03:41, Robin Heggelund Hansen 
 wrote:

> Is this something that is fixable?
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
>
> Note that posts from new members are moderated - please be patient
> with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
>
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+u...@googlegroups.com.
>
> For more options, visit https://groups.google.com/groups/opt_out.
>


>>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> --
> You received this message because yo

Re: In your opinion, what's the best, and what's the worst aspects of using Clojure?

[Sean Corfield]

Whilst the stacktraces can be pretty painful at times - esp. if you're
dealing with lazy sequences - they do include filenames and line
numbers, at least when you're outside the REPL. There are also a
number of tools to clean up stack traces to show only Clojure-related
entries and/or color-code them etc (e.g.,
clojure.stacktrace/print-stack-trace which is part of the core Clojure
download).

That said, yes, debugging errors is probably the worst aspect of using
Clojure :)

And +1 on the language/community as best!

Sean

On Fri, Dec 27, 2013 at 5:48 PM, Guru Devanla  wrote:
> Seconded on Error reporting.
>
> I have been playing around with Clojure for sometime now and also completed
> almost 150 of the 4clojure problems. What still scars me in terms of
> incorporating Clojure as a language of choice in more complicated projects I
> work on in my other life, is the error reporting facility. The errors
> sometimes might as well just say 'I just cannot run!'.  It would be nice if
> there was some facility to approximately point to some s-exp or line
> numbers.
>
> May be I am missing some workflow used by other expert users. Can someone
> throw more light on this.
>
>
> Thanks
> Guru
>
>
> On Fri, Dec 27, 2013 at 3:44 PM, Daniel  wrote:
>>
>> Best: Language & Community
>> Worst: Error Reporting
>>
>>
>> On Friday, December 27, 2013 3:17:48 PM UTC-6, Kelker Ryan wrote:
>>>
>>> In your opinion, what's the best, and what's the worst aspects of using
>>> Clojure?
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.



-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

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

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: In your opinion, what's the best, and what's the worst aspects of using Clojure?

[Alex Baranosky]

I always hear people say that the errors are bad, but I just don't see it.
 The stacktraces say exactly what went wrong and at what line of the
source. To me that's all I can hope for.

I think there may have been some more obtuse errors that came up in older
versions of Clojure that have since been improved in newer versions, though.


On Fri, Dec 27, 2013 at 7:44 PM, Sean Corfield wrote:

> Whilst the stacktraces can be pretty painful at times - esp. if you're
> dealing with lazy sequences - they do include filenames and line
> numbers, at least when you're outside the REPL. There are also a
> number of tools to clean up stack traces to show only Clojure-related
> entries and/or color-code them etc (e.g.,
> clojure.stacktrace/print-stack-trace which is part of the core Clojure
> download).
>
> That said, yes, debugging errors is probably the worst aspect of using
> Clojure :)
>
> And +1 on the language/community as best!
>
> Sean
>
> On Fri, Dec 27, 2013 at 5:48 PM, Guru Devanla  wrote:
> > Seconded on Error reporting.
> >
> > I have been playing around with Clojure for sometime now and also
> completed
> > almost 150 of the 4clojure problems. What still scars me in terms of
> > incorporating Clojure as a language of choice in more complicated
> projects I
> > work on in my other life, is the error reporting facility. The errors
> > sometimes might as well just say 'I just cannot run!'.  It would be nice
> if
> > there was some facility to approximately point to some s-exp or line
> > numbers.
> >
> > May be I am missing some workflow used by other expert users. Can someone
> > throw more light on this.
> >
> >
> > Thanks
> > Guru
> >
> >
> > On Fri, Dec 27, 2013 at 3:44 PM, Daniel  wrote:
> >>
> >> Best: Language & Community
> >> Worst: Error Reporting
> >>
> >>
> >> On Friday, December 27, 2013 3:17:48 PM UTC-6, Kelker Ryan wrote:
> >>>
> >>> In your opinion, what's the best, and what's the worst aspects of using
> >>> Clojure?
> >>
> >> --
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clojure@googlegroups.com
> >> Note that posts from new members are moderated - please be patient with
> >> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+unsubscr...@googlegroups.com
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=en
> >> ---
> >> You received this message because you are subscribed to the Google
> Groups
> >> "Clojure" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an
> >> email to clojure+unsubscr...@googlegroups.com.
> >> For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
> > --
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google 

Re: In your opinion, what's the best, and what's the worst aspects of using Clojure?

[Lee Spector]

On Dec 27, 2013, at 10:53 PM, Alex Baranosky wrote:
> I always hear people say that the errors are bad, but I just don't see it.  
> The stacktraces say exactly what went wrong and at what line of the source. 
> To me that's all I can hope for.

One can hope to see the values of locals, which for me would make a big 
difference. This is apparently possible (through some combination of nrepl-ritz 
and avoiding locals clearing, I think), but not at all easy. In other parts of 
the Lisp universe this has been standard for decades and, I think, central to 
common debugging practices.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Akka-like framework in Clojure ?

[kovas boguta]

The bottom line is that the definitive clojure distributed computing
solution is yet to be invented, but there are a number of things out
there including the aforementioned.

1. clojure wrappers for Akka, for instance

https://github.com/jasongustafson/akka-clojure

(there are several others, of varying quality.. just search github / google)

2. solutions implementing the idea of supervisor hierarchies, for instance

https://github.com/MichaelDrogalis/dire

(I believe there are other contenders in this category also)

3. RPC libraries, like https://github.com/sunng87/slacker

4. Batteries-included cluster-aware computing: http://immutant.org/




On Fri, Dec 27, 2013 at 7:13 PM, Sean Corfield  wrote:
> I got the impression - from talking to someone who tried to wrap Akka
> in Clojure - that Akka's API was pretty nasty to use from Clojure?
>
> Sean
>
> On Fri, Dec 27, 2013 at 3:54 PM, Alex Baranosky
>  wrote:
>> You can just use Akka directly w/ Clojure's excellent Java interop.
>>
>>
>> On Fri, Dec 27, 2013 at 3:48 PM, Paulo Suzart  wrote:
>>>
>>> Hi,
>>>
>>> Am I wrong or Galaxy project (behind pulsar) is quite inactive? Does
>>> anybody know how promising are they?
>>>
>>> Cheers
>>>
>>>
>>> On 27 December 2013 17:32, Bruno Kim Medeiros Cesar
>>>  wrote:

 I haven't dabbled yet on actor-based concurrency, can someone point out
 (a blog post about) a comparison between Akka actors, Clojure agents and
 other solutions?


 On Friday, December 27, 2013 6:54:16 AM UTC-2, Eric Le Goff wrote:
>
>
> Hi,
>
> After a long background with imperative languages such as Java, I
> recently spent some time learning functionnal programming, starting with
> Scala. I had the opporrtunity to build a demo project based on the Akka
> framework.
>
> Now I am starting learning Clojure, and would be curious to know if
> there was some clojure based framework available which could implement
> rather similar features to Akka.
>
> In particular, I would be interested in an implementation of the Actor
> Model [1]
>
> Thanks.
>
> Eric
>
>
> [1] http://en.wikipedia.org/wiki/Actor_model

 --
 --
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 You received this message because you are subscribed to the Google Groups
 "Clojure" group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to clojure+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>>
>>> --
>>> Paulo Suzart
>>> @paulosuzart
>>>
>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google Groups
>>> "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with your
>> first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note th

Re: In your opinion, what's the best, and what's the worst aspects of using Clojure?

[Alex Baranosky]

Lee,

Sure, it'd be nice to have a functioning debugger, I'll give you that.


On Fri, Dec 27, 2013 at 8:03 PM, Lee Spector  wrote:

>
> On Dec 27, 2013, at 10:53 PM, Alex Baranosky wrote:
> > I always hear people say that the errors are bad, but I just don't see
> it.  The stacktraces say exactly what went wrong and at what line of the
> source. To me that's all I can hope for.
>
> One can hope to see the values of locals, which for me would make a big
> difference. This is apparently possible (through some combination of
> nrepl-ritz and avoiding locals clearing, I think), but not at all easy. In
> other parts of the Lisp universe this has been standard for decades and, I
> think, central to common debugging practices.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: In your opinion, what's the best, and what's the worst aspects of using Clojure?

[guns]

On Fri 27 Dec 2013 at 11:03:20PM -0500, Lee Spector wrote:

> On Dec 27, 2013, at 10:53 PM, Alex Baranosky wrote:
>
> > I always hear people say that the errors are bad, but I just don't
> > see it. The stacktraces say exactly what went wrong and at what line
> > of the source. To me that's all I can hope for.

I'll have to agree with Alex, I've never really had that much of a
problem with Clojure errors. A stacktrace is certainly better than
"Segmentation fault".

> One can hope to see the values of locals, which for me would make a
> big difference. This is apparently possible (through some combination
> of nrepl-ritz and avoiding locals clearing, I think), but not at all
> easy. In other parts of the Lisp universe this has been standard for
> decades and, I think, central to common debugging practices.

I personally use the following macro from my user.clj:

(defmacro dump-locals []
  `(clojure.pprint/pprint
 ~(into {} (map (fn [l] [`'~l l]) (reverse (keys &env))

It's not the automatic break-on-exception-and-start-local-repl of CL +
Emacs, but it's editor agnostic and usually does the trick.

I find that my desires for a stepping debugger are mostly absent with
Clojure as data is immutable, and the reference types may be monitored
with add-watch.

guns


pgpGmxZq3WqAn.pgp
Description: PGP signature

Re: In your opinion, what's the best, and what's the worst aspects of using Clojure?

[Lee Spector]

On Dec 27, 2013, at 11:18 PM, guns wrote:
> 
> I personally use the following macro from my user.clj:
> 
> (defmacro dump-locals []
>  `(clojure.pprint/pprint
> ~(into {} (map (fn [l] [`'~l l]) (reverse (keys &env))
> 
> It's not the automatic break-on-exception-and-start-local-repl of CL +
> Emacs, but it's editor agnostic and usually does the trick.


When and where do you call this?

I can live without the local REPL (although I'll always miss it), but what I 
want is to see the locals when I hit an exception somewhere that I didn't 
expect one. I'd like every exception to dump locals, all up the stack if 
possible. Can this, or something like it, do that?

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: In your opinion, what's the best, and what's the worst aspects of using Clojure?

[guns]

On Fri 27 Dec 2013 at 11:23:22PM -0500, Lee Spector wrote:
>
> On Dec 27, 2013, at 11:18 PM, guns wrote:
> >
> > I personally use the following macro from my user.clj:
> >
> > (defmacro dump-locals []
> >  `(clojure.pprint/pprint
> > ~(into {} (map (fn [l] [`'~l l]) (reverse (keys &env))
> >
> > It's not the automatic break-on-exception-and-start-local-repl of CL +
> > Emacs, but it's editor agnostic and usually does the trick.
>
>
> When and where do you call this?

I call this inside of the closest function that raised the exception.

> I can live without the local REPL (although I'll always miss it), but
> what I want is to see the locals when I hit an exception somewhere
> that I didn't expect one. I'd like every exception to dump locals, all
> up the stack if possible. Can this, or something like it, do that?

Like you mentioned, I've heard nrepl-ritz does this in emacs, and David
Greenberg has something like this set up for vim:

https://github.com/dgrnbrg/vim-redl

I don't use this myself, however. The dump-locals macro is essentially a
fancy way to do printf debugging, which I have found sufficient.

guns


pgpIhJDs6U1gr.pgp
Description: PGP signature

Re: Namespaces [was Re: Is Clojure right for me?]

[John Chijioke]

James Reeves has got it. It's same for me. All this boils down to really 
knowing the language. Knowing how to make music with the instruments 
provided. For me Clojure's namespaces has been one of the most wonderful 
things that has happened to me in programming. It has facilitated all kinds 
of evaluation environments. I've never had such issues as yours. 
Configuration management is one of the easiest things to do in Clojure. I 
think what I would offer in this case is the word, Refactor. One thing I 
noticed about your examples is that your functions lack composition. Think 
that way and maybe you'll stop having the problems you're having because if 
you're not careful it won't be long before you start thinking of 
inheritance as well.

On Friday, December 27, 2013 7:08:49 PM UTC+1, puzzler wrote:
>
> I ended up accidentally injecting a completely different thread of 
> discussion into the "Is Clojure right for me?" thread.  I'm breaking it 
> into a separate thread here.
>
> Here's where we left off:
>
> On Fri, Dec 27, 2013 at 6:34 AM, Stuart Halloway 
> 
> > wrote:
>
>> Yes, thanks Mark. It seems to me that you are saying "namespaces make 
>> poor maps".  Stipulated.  So why not use records or maps?
>>
>>
> This is close, but not exactly what I'm saying.  It's not so much about 
> wanting namespaces to be maps.  It's about wanting a robust mechanism for 
> functions to share information other than threading that information 
> through the functions.  
>
> In Structure and Interpretation of Computer Programming, a large chunk of 
> the programs are written in a pseudo-object-oriented style, a style which 
> simulates objects by having functions' closures share the same local 
> context.
>
> Sure, you could do that with maps:
>
> For example:
>
> (defn create-functions [init-info]
>(let [shared-info init-info]
>   {:foo (fn foo [x] ... body uses shared-info in some way ...),
>:bar (fn bar [x] ... body uses shared-info in some way ..)}))
>
> Then, to access these functions, you'd do something like this:
> (def instance (create-functions default-info))
> ((:foo instance) 2)  ; the equivalent of instance.foo(2) in OO
> ((:bar instance) 3)  ; the equivalent of instance.bar(3) in OO
>
> Of course, SICP's main point is that even bare-bones Scheme is rich enough 
> to simulate objects, but the other point is that it is important for 
> functions to be able to share stat*e* which can be initialized for a 
> group of functions, 
>
> *even if that state is immutable. *
> The above pattern is important enough that most languages provide some 
> kind of mechanism for doing that. Classes are one such pattern.
>
> In Clojure, the above code would be horribly un-idiomatic of course.  
> Actually, depending on the functions and definitions, it might not even be 
> possible to structure the code that way (because Clojure's local definition 
> capabilities are not as rich as what is possible at the global level, for 
> example, regarding mutual references -- in some contexts, letfn might help, 
> but not all contexts).
>
> The above example uses associative containers for the shared-info, and 
> associative containers to hold the group of related functions that are 
> outputted, but that doesn't make this solution any more attractive -- 
> again, emphasizing that this is not about associative containers.
>
> I claim that Clojure only provides two idiomatic solutions to the above 
> problem of functions sharing the same immutable information, which might 
> need to be set prior to using those functions:
>
> Solution 1:
>
> (def ^:dynamic shared-info default-info)
> (defn foo [x] ... body uses shared-info)
> (defn bar [x] ... body uses shared-info)
>
> Call these functions via:
>
> (foo 2) and (bar 3) if you're happy with the defaults or
>
> (binding [shared-info info] (foo 2)) and
> (binding [shared-info info] (bar 3)) otherwise.
>
> This is awkward for several reasons, and sometimes this solution isn't 
> really an option since functions that return lazy structures won't work 
> with the above mechanism.  
>
> Solution 2:
>
> (defn foo [shared-info x] ... body uses shared-info)
> (defn bar [shared-info x] ... body uses shared-info)
>
> Call these functions via:
>
> (foo info 2)
> (bar info 3)
>
>
> My argument is that both these solutions are unsatisfying.  Solution 2 is 
> irritating because if you use a map for shared-info, you end up having to 
> repeat the destructuring in every single function.  Also, you need to 
> thread this information through all the functions, not only the functions 
> that directly use, but also the functions that call other functions that 
> use it.  It makes all the functions bulky and awkward, and at the end of 
> that, you still don't have something that reflects the notion of getting 
> back a group of functions that share the *same* info -- instead, you have 
> to remember to always pass in that same info with every function call.  
> Also, with the threading-the-state

Re: Clojure can't import some Java classes

[Zach Oakes]

Definitely exciting to hear that it works. Is this something you could 
propose as a patch on the Clojure JIRA?

On Friday, December 27, 2013 9:52:04 PM UTC-5, Colin Fleming wrote:
>
> Wow, that works! You just saved me an extraordinary amount of pain - thank 
> you!
>
> I had to make one further small change, to invoke the method on RT instead 
> of Class, but that was it.
>
>
> On 28 December 2013 14:16, Aaron Cohen  >wrote:
>
>> I have the sneaking suspicion that this may be as simple as changing 
>>
>>
>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L697
>>
>> to:
>>
>> final static Method forNameMethod = Method.getMethod("Class 
>> *classForNameNonLoading*(String)");
>>
>>
>> and making "classForNameNonLoading" public at 
>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L2074
>>
>> static *public *Class classForNameNonLoading(String name)
>>
>>
>> I should try it myself, but may not get to it this weekend.
>>
>>
>> On Fri, Dec 27, 2013 at 5:19 PM, Zach Oakes 
>> > wrote:
>>
>>> Yeah I tried this with RoboVM, but there are so many classes that needed 
>>> to be stubbed that it turned into an endless rabbit hole, so I gave up. It 
>>> may be a good solution for those who just have one or two problematic 
>>> classes, though.
>>>
>>>
>>> On Thursday, December 26, 2013 8:37:44 PM UTC-5, Colin Fleming wrote:
>>>
 In case anyone is interested in a workaround for this, I managed to 
 "fix" my compilation by stubbing out the problematic classes and putting 
 the stubs ahead of the real classes in the classpath when I compile. Where 
 those stubs return other objects that are required during static 
 initialisation, I create those classes with Mockito. I feel dirty all over 
 but it does work.

 I'm also tinkering with a fork of Clojure in the background that uses 
 ASM Types instead of Class objects. It's still a long way from done but 
 it's looking like that might provide a solution for compilation, at least. 
 I'll report back if I ever get it working.


 On 15 December 2013 14:05, Colin Fleming  wrote:

> I've just spent some time today looking at the compiler code, and 
> unfortunately I think the answer is "no". When a symbol is imported, 
> Clojure currently instantiates the Class object using Class.forName() and 
> stores that in the namespace's mapping. At the point the Class is 
> instantiated, static initializers are run. So the only way to avoid that 
> is 
> not instantiate the Class and store something else in the mapping. 
>
> Alex's suggestion above to store the string representing the class 
> name and load the class on demand might work for REPL style development 
> but 
> won't work for AOT compilation since reflection is used to find fields, 
> methods etc on the class during compilation. The only solution that I can 
> see that would work for AOT would be to store some sort of class wrapper 
> object which reads the class bytecode to get that information without 
> instantiating the class.
>
> However both of these suggestions break a fairly fundamental 
> assumption - that importing a class creates a mapping from its name to a 
> Class object. I have no idea what sort of code might be out there making 
> that assumption, but it's probably fair to assume there could be a lot of 
> it. At some point I might look into creating a fork of Clojure I just use 
> to AOT compile.
>
>
> On 12 December 2013 03:41, Robin Heggelund Hansen 
> wrote:
>
>> Is this something that is fixable?
>>
>> -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>>
>> Note that posts from new members are moderated - please be patient 
>> with your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com
>>
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google 
>> Groups "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, 
>> send an email to clojure+u...@googlegroups.com.
>>
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
  -- 
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com 
>>> For more options, visit this group at
>>> http://groups.google.com/group/cloj

Re: In your opinion, what's the best, and what's the worst aspects of using Clojure?

[Colin Fleming]

I think the error complaints are generally more about the errors when you
have something wrong in your code. Things like parsing of ns forms has
little to no error checking, and you can get some extremely obscure errors.
For example if you (or some tool) places an :import clause ahead of your NS
docstring, you get an error like: "java.lang.Character cannot be cast to
clojure.lang.Named" and it's generally attributed to a different namespace.
This sort of thing is terribly demoralising for newcomers, and occasionally
to seasoned pros too.


On 28 December 2013 16:53, Alex Baranosky wrote:

> I always hear people say that the errors are bad, but I just don't see it.
>  The stacktraces say exactly what went wrong and at what line of the
> source. To me that's all I can hope for.
>
> I think there may have been some more obtuse errors that came up in older
> versions of Clojure that have since been improved in newer versions, though.
>
>
> On Fri, Dec 27, 2013 at 7:44 PM, Sean Corfield wrote:
>
>> Whilst the stacktraces can be pretty painful at times - esp. if you're
>> dealing with lazy sequences - they do include filenames and line
>> numbers, at least when you're outside the REPL. There are also a
>> number of tools to clean up stack traces to show only Clojure-related
>> entries and/or color-code them etc (e.g.,
>> clojure.stacktrace/print-stack-trace which is part of the core Clojure
>> download).
>>
>> That said, yes, debugging errors is probably the worst aspect of using
>> Clojure :)
>>
>> And +1 on the language/community as best!
>>
>> Sean
>>
>> On Fri, Dec 27, 2013 at 5:48 PM, Guru Devanla  wrote:
>> > Seconded on Error reporting.
>> >
>> > I have been playing around with Clojure for sometime now and also
>> completed
>> > almost 150 of the 4clojure problems. What still scars me in terms of
>> > incorporating Clojure as a language of choice in more complicated
>> projects I
>> > work on in my other life, is the error reporting facility. The errors
>> > sometimes might as well just say 'I just cannot run!'.  It would be
>> nice if
>> > there was some facility to approximately point to some s-exp or line
>> > numbers.
>> >
>> > May be I am missing some workflow used by other expert users. Can
>> someone
>> > throw more light on this.
>> >
>> >
>> > Thanks
>> > Guru
>> >
>> >
>> > On Fri, Dec 27, 2013 at 3:44 PM, Daniel 
>> wrote:
>> >>
>> >> Best: Language & Community
>> >> Worst: Error Reporting
>> >>
>> >>
>> >> On Friday, December 27, 2013 3:17:48 PM UTC-6, Kelker Ryan wrote:
>> >>>
>> >>> In your opinion, what's the best, and what's the worst aspects of
>> using
>> >>> Clojure?
>> >>
>> >> --
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups "Clojure" group.
>> >> To post to this group, send email to clojure@googlegroups.com
>> >> Note that posts from new members are moderated - please be patient with
>> >> your first post.
>> >> To unsubscribe from this group, send email to
>> >> clojure+unsubscr...@googlegroups.com
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/clojure?hl=en
>> >> ---
>> >> You received this message because you are subscribed to the Google
>> Groups
>> >> "Clojure" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> an
>> >> email to clojure+unsubscr...@googlegroups.com.
>> >> For more options, visit https://groups.google.com/groups/opt_out.
>> >
>> >
>> > --
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, send email to clojure@googlegroups.com
>> > Note that posts from new members are moderated - please be patient with
>> your
>> > first post.
>> > To unsubscribe from this group, send email to
>> > clojure+unsubscr...@googlegroups.com
>> > For more options, visit this group at
>> > http://groups.google.com/group/clojure?hl=en
>> > ---
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "Clojure" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to clojure+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>> --
>> Sean A Corfield -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>> World Singles, LLC. -- http://worldsingles.com/
>>
>> "Perfection is the enemy of the good."
>> -- Gustave Flaubert, French realist novelist (1821-1880)
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you ar

Re: Clojure can't import some Java classes

[Colin Fleming]

Absolutely, although with this fix execution doesn't work properly (for
example, the tests fail because when you import a gen-class'ed class its
namespace isn't loaded). However it would be good to be able to toggle it
via a system property or something for compilation purposes. It's possible
that that example is an incorrect use of such a class, but given that it's
in the core Clojure test suite it's reasonable to assume that this would be
a fairly breaking change for other code as well.

I'll mail clojure-dev and see what everyone thinks.


On 28 December 2013 20:24, Zach Oakes  wrote:

> Definitely exciting to hear that it works. Is this something you could
> propose as a patch on the Clojure JIRA?
>
>
> On Friday, December 27, 2013 9:52:04 PM UTC-5, Colin Fleming wrote:
>
>> Wow, that works! You just saved me an extraordinary amount of pain -
>> thank you!
>>
>> I had to make one further small change, to invoke the method on RT
>> instead of Class, but that was it.
>>
>>
>> On 28 December 2013 14:16, Aaron Cohen  wrote:
>>
>>> I have the sneaking suspicion that this may be as simple as changing
>>>
>>> https://github.com/clojure/clojure/blob/master/src/jvm/
>>> clojure/lang/Compiler.java#L697
>>>
>>> to:
>>>
>>> final static Method forNameMethod = Method.getMethod("Class
>>> *classForNameNonLoading*(String)");
>>>
>>>
>>> and making "classForNameNonLoading" public at
>>> https://github.com/clojure/clojure/blob/master/src/jvm/
>>> clojure/lang/RT.java#L2074
>>>
>>> static *public *Class classForNameNonLoading(String name)
>>>
>>>
>>> I should try it myself, but may not get to it this weekend.
>>>
>>>
>>> On Fri, Dec 27, 2013 at 5:19 PM, Zach Oakes  wrote:
>>>
 Yeah I tried this with RoboVM, but there are so many classes that
 needed to be stubbed that it turned into an endless rabbit hole, so I gave
 up. It may be a good solution for those who just have one or two
 problematic classes, though.


 On Thursday, December 26, 2013 8:37:44 PM UTC-5, Colin Fleming wrote:

> In case anyone is interested in a workaround for this, I managed to
> "fix" my compilation by stubbing out the problematic classes and putting
> the stubs ahead of the real classes in the classpath when I compile. Where
> those stubs return other objects that are required during static
> initialisation, I create those classes with Mockito. I feel dirty all over
> but it does work.
>
> I'm also tinkering with a fork of Clojure in the background that uses
> ASM Types instead of Class objects. It's still a long way from done but
> it's looking like that might provide a solution for compilation, at least.
> I'll report back if I ever get it working.
>
>
> On 15 December 2013 14:05, Colin Fleming wrote:
>
>> I've just spent some time today looking at the compiler code, and
>> unfortunately I think the answer is "no". When a symbol is imported,
>> Clojure currently instantiates the Class object using Class.forName() and
>> stores that in the namespace's mapping. At the point the Class is
>> instantiated, static initializers are run. So the only way to avoid that 
>> is
>> not instantiate the Class and store something else in the mapping.
>>
>> Alex's suggestion above to store the string representing the class
>> name and load the class on demand might work for REPL style development 
>> but
>> won't work for AOT compilation since reflection is used to find fields,
>> methods etc on the class during compilation. The only solution that I can
>> see that would work for AOT would be to store some sort of class wrapper
>> object which reads the class bytecode to get that information without
>> instantiating the class.
>>
>> However both of these suggestions break a fairly fundamental
>> assumption - that importing a class creates a mapping from its name to a
>> Class object. I have no idea what sort of code might be out there making
>> that assumption, but it's probably fair to assume there could be a lot of
>> it. At some point I might look into creating a fork of Clojure I just use
>> to AOT compile.
>>
>>
>> On 12 December 2013 03:41, Robin Heggelund Hansen > > wrote:
>>
>>> Is this something that is fixable?
>>>
>>> --
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>>
>>> Note that posts from new members are moderated - please be patient
>>> with your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>>
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> T