Scala/Clojure/F# - Functional Programming Advocates - New York/Chicago/San Fran

[alex]

Hey All,

 

I am currently working with some of the worlds most talented FP teams in 
the US to help them build out there Clojure, F# and Scala teams.

 

If you are looking for a new gig within the Functional Space and want to 
work alongside some of the best engineers then drop me a line! 
a...@functionalworks.com 

 

Paying up to $180,000 + Benefits + Bonus + Stock! 

 

Look forward to hearing from you.

 

thanks,

Alex Mesropians

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

Re: Scala/Clojure/F# - Functional Programming Advocates - New York/Chicago/San Fran

[Colin Fleming]

Just this afternoon I was looking at the HN Who's Hiring
<https://news.ycombinator.com/item?id=11012044> thread for February. 621
comments there, mostly job postings with the occasional question comment,
so perhaps 500-550 actual postings. 15 postings mention Clojure, with 9
being what looks like a full time Clojure position. So better than
indeed.com (which probably tends towards the mainstream languages) although
still not a huge number of positions. However I see more companies hiring
at conferences etc than I see ads for, so I do think there's more work out
there. Obviously it won't be taking over from Java (or even Scala) any time
soon though.

On 2 February 2016 at 16:32, gvim <gvi...@gmail.com> wrote:

> Alex
>
> I was looking at Indeed.com for U.S. FP job stats and I found for "United
> States" by title:
>
> Java: 12,125
> Scala: 336
> Clojure: 28
>
> Considering Clojure 1.0 has been around for nearly 7 years and Scala 2.0
> is almost a decade old is it fair to conclude that FP and Clojure in
> particular are likely to remain niche as far as paid work goes? It seems
> the OO juggernaut just rolls on regardless :(
>
> gvim
>
>
>
> On 01/02/2016 20:54, a...@functionalworks.com wrote:
>
>> Hey All,
>>
>> I am currently working with some of the worlds most talented FP teams in
>> the US to help them build out there Clojure, F# and Scala teams.
>>
>> If you are looking for a new gig within the Functional Space and want to
>> work alongside some of the best engineers then drop me a line!
>> a...@functionalworks.com <mailto:a...@functionalworks.com>
>>
>> Paying up to $180,000 + Benefits + Bonus + Stock!
>>
>> Look forward to hearing from you.
>>
>> thanks,
>>
>> Alex Mesropians
>>
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Scala/Clojure/F# - Functional Programming Advocates - New York/Chicago/San Fran

[gvim]

Alex

I was looking at Indeed.com for U.S. FP job stats and I found for 
"United States" by title:


Java: 12,125
Scala: 336
Clojure: 28

Considering Clojure 1.0 has been around for nearly 7 years and Scala 2.0 
is almost a decade old is it fair to conclude that FP and Clojure in 
particular are likely to remain niche as far as paid work goes? It seems 
the OO juggernaut just rolls on regardless :(


gvim



On 01/02/2016 20:54, a...@functionalworks.com wrote:

Hey All,

I am currently working with some of the worlds most talented FP teams in
the US to help them build out there Clojure, F# and Scala teams.

If you are looking for a new gig within the Functional Space and want to
work alongside some of the best engineers then drop me a line!
a...@functionalworks.com <mailto:a...@functionalworks.com>

Paying up to $180,000 + Benefits + Bonus + Stock!

Look forward to hearing from you.

thanks,

Alex Mesropians



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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Scala for-comprehension to Clojure

[Mark Engelberg]

Most Scala `for` examples translate over to Clojure's `for`.  The biggest
difference is that Scala produces a collection matching the type of the
first generator, whereas Clojure produces a lazy sequence, which you can
"pour" into the collection of your choice with `into`.

It looks like your specific example is also using some sort of imperative
generator in Scala.  Clojure tends to frown on those sorts of constructs,
and is more prescriptive, guiding you towards a more functional solution.
You might rework that generator as a lazy sequence.  Or possibly, if you
really need something more imperative in nature, you could represent the
generator as a channel and you could accomplish what you want with
transducers on the channel (I'm not aware of a for-like macro that operates
on channels, but it seems theoretically possible to write such a thing).


On Thu, Nov 26, 2015 at 8:16 AM, Rastko Soskic <rss...@gmail.com> wrote:

> Hi, I am not sure if it will serve point the best but that is what I have
> received as a koan style problem with Scala solution,
> now I am trying to comprehend it fully and convert to Clojure. Like I said
> I am by no means Scala expert.
>
> Let's say we have some Val container which is capable to hold some value
> plus yield another value
> which depends on "mapping" function provided to Val itself (exec param of
> case class).
>
> package question.google.group
>
> object worksheet {
>   def unit[S, A](a: A): Val[S, A] =
> Val(s => (a, s))
>
>   case class Val[S, +A](exec: S => (A, S)) {
> def map[B](f: A => B): Val[S, B] =
>   flatMap(a => unit(f(a)))
> def flatMap[B](f: A => Val[S, B]): Val[S, B] = Val(s => {
>   val (a, s1) = exec(s)
>   f(a).exec(s1)
> })
>   }
>
>   def int : Val[Int, Int] = Val(x => (x, x + 1))
>
> *  val something = for {*
> *x <- int*
> *y <- int*
> *  } yield (x, y)  //> something
>  : question.google.group.Val[Int,(Int, Int)] = Val()*
>
>   something.exec(5)   //> res9: ((Int, Int),
> Int) = ((5,6),7)
> }
>
> If I am following this example and wikipedia well (on Monads in fp),
> in bottom line Val is a monad given presence of type unit and bind
> (flatMap) operation... But that is not my primary focus here.
>
> It is Scala's for comprehension which expands to map and flatMap calls so
> some intial value (given to exec function) "flows" through it
> yielding in the end expected result.
>
> I hope this sheds some more light on what I am seeking for.
>
> @Torsten, thanks for mentioned resources I'll take a look at them.
>
> On Thursday, November 26, 2015 at 12:40:50 PM UTC+1, Gary Verhaegen wrote:
>>
>> It's a bit hard (at least for me) to see what you're actually trying to
>> do here that would precent a direct translation of your snippet to
>> Clojure's for. Could you perhaps post a complete, self-contained code
>> example in Scala?
>>
>> On Thursday, 26 November 2015, Torsten Uhlmann <torsten...@gmail.com>
>> wrote:
>>
>>> Hi Rastko,
>>>
>>> One way of doing that would be to use the mlet macro from the Cats
>>> library: http://funcool.github.io/cats/latest/#mlet
>>>
>>> Also, there are several if-lets or when-lets out there that allow
>>> multiple bindings, I used one from https://github.com/ptaoussanis/encore
>>>
>>> I use Scala's for most of the time when there are Options in the mix
>>> that may or may not hold a value.
>>>
>>> For binding to generators, Clojures for might be a better fit?
>>> https://clojuredocs.org/clojure.core/for
>>>
>>> Would that help you?
>>>
>>> Torsten.
>>>
>>> PS: I'm learning Clojure myself with Scala and Java background.
>>>
>>> On Thursday, November 26, 2015 at 12:12:01 PM UTC+1, Rastko Soskic wrote:
>>>>
>>>> Hi,
>>>> I am aware of philosophical differences of Scala and Clojure
>>>> but functional programming should be a pretty common ground :)
>>>> Thus I need help, I am trying to mimic Scala's for comprehension in
>>>> Clojure.
>>>>
>>>> Hopefully someone will be able to aid me with the following (perhaps
>>>> more familiar with Scala):
>>>>
>>>> Scala for comprehension is errr how to say "de-sugared" to series
>>>> of map and flatMap calls... thus, it is possible to use plain functions
>>>> in for-comprehension
>>>> like:
>>>> *val *ns: Conv[List[Int]] = *for *{ // Conv is 

Scala for-comprehension to Clojure

[Rastko Soskic]

Hi, 
I am aware of philosophical differences of Scala and Clojure
but functional programming should be a pretty common ground :)
Thus I need help, I am trying to mimic Scala's for comprehension in Clojure.

Hopefully someone will be able to aid me with the following (perhaps more 
familiar with Scala):

Scala for comprehension is errr how to say "de-sugared" to series 
of map and flatMap calls... thus, it is possible to use plain functions in 
for-comprehension
like:
*val *ns: Conv[List[Int]] = *for *{ // Conv is just alias for functions of 
type B => (B, A)
x <- int // int is function again of type Conv
y <- int
xs <- ints(x) // this is just sequence of numbers
} *yield *xs.map(_ * y)

I don't need all the nuts and bolts, just some guideline for achieving 
something similar
in Clojure.

I am not lazy :) I've already eagerly researched a bit and got to this: Scala 
for-comprehension to Clojure 
<http://stackoverflow.com/questions/25655132/how-to-convert-this-map-flatmap-into-a-for-comprehension-in-clojure>

But as you can see that is not really about having kind of generator 
function which is wrapped into flatMap
call. Perhaps this is not in Clojure's spirit at all, perhaps there is some 
Clojure idiom to achieve something similar.

Any tip, suggestion, critic is welcome and appreciated.

If someone is wondering how in the world I came up to this, I am doing some 
f-p exercises which I've got Scala solution for
however I am not very interested in Scala and I am doing Clojure so I just 
need to grasp concepts...

Thanks in advance...

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

Re: Scala for-comprehension to Clojure

[Torsten Uhlmann]

Hi Rastko,

One way of doing that would be to use the mlet macro from the Cats library: 
http://funcool.github.io/cats/latest/#mlet

Also, there are several if-lets or when-lets out there that allow multiple 
bindings, I used one from https://github.com/ptaoussanis/encore

I use Scala's for most of the time when there are Options in the mix that 
may or may not hold a value.

For binding to generators, Clojures for might be a better 
fit? https://clojuredocs.org/clojure.core/for

Would that help you?

Torsten.

PS: I'm learning Clojure myself with Scala and Java background.

On Thursday, November 26, 2015 at 12:12:01 PM UTC+1, Rastko Soskic wrote:
>
> Hi, 
> I am aware of philosophical differences of Scala and Clojure
> but functional programming should be a pretty common ground :)
> Thus I need help, I am trying to mimic Scala's for comprehension in 
> Clojure.
>
> Hopefully someone will be able to aid me with the following (perhaps more 
> familiar with Scala):
>
> Scala for comprehension is errr how to say "de-sugared" to series 
> of map and flatMap calls... thus, it is possible to use plain functions in 
> for-comprehension
> like:
> *val *ns: Conv[List[Int]] = *for *{ // Conv is just alias for functions 
> of type B => (B, A)
> x <- int // int is function again of type Conv
> y <- int
> xs <- ints(x) // this is just sequence of numbers
> } *yield *xs.map(_ * y)
>
> I don't need all the nuts and bolts, just some guideline for achieving 
> something similar
> in Clojure.
>
> I am not lazy :) I've already eagerly researched a bit and got to this: Scala 
> for-comprehension to Clojure 
> <http://stackoverflow.com/questions/25655132/how-to-convert-this-map-flatmap-into-a-for-comprehension-in-clojure>
>
> But as you can see that is not really about having kind of generator 
> function which is wrapped into flatMap
> call. Perhaps this is not in Clojure's spirit at all, perhaps there is 
> some Clojure idiom to achieve something similar.
>
> Any tip, suggestion, critic is welcome and appreciated.
>
> If someone is wondering how in the world I came up to this, I am doing 
> some f-p exercises which I've got Scala solution for
> however I am not very interested in Scala and I am doing Clojure so I just 
> need to grasp concepts...
>
> Thanks in advance...
>

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

Re: Scala for-comprehension to Clojure

[Gary Verhaegen]

It's a bit hard (at least for me) to see what you're actually trying to do
here that would precent a direct translation of your snippet to Clojure's
for. Could you perhaps post a complete, self-contained code example in
Scala?

On Thursday, 26 November 2015, Torsten Uhlmann <torsten.uhlm...@gmail.com>
wrote:

> Hi Rastko,
>
> One way of doing that would be to use the mlet macro from the Cats
> library: http://funcool.github.io/cats/latest/#mlet
>
> Also, there are several if-lets or when-lets out there that allow multiple
> bindings, I used one from https://github.com/ptaoussanis/encore
>
> I use Scala's for most of the time when there are Options in the mix that
> may or may not hold a value.
>
> For binding to generators, Clojures for might be a better fit?
> https://clojuredocs.org/clojure.core/for
>
> Would that help you?
>
> Torsten.
>
> PS: I'm learning Clojure myself with Scala and Java background.
>
> On Thursday, November 26, 2015 at 12:12:01 PM UTC+1, Rastko Soskic wrote:
>>
>> Hi,
>> I am aware of philosophical differences of Scala and Clojure
>> but functional programming should be a pretty common ground :)
>> Thus I need help, I am trying to mimic Scala's for comprehension in
>> Clojure.
>>
>> Hopefully someone will be able to aid me with the following (perhaps more
>> familiar with Scala):
>>
>> Scala for comprehension is errr how to say "de-sugared" to series
>> of map and flatMap calls... thus, it is possible to use plain functions
>> in for-comprehension
>> like:
>> *val *ns: Conv[List[Int]] = *for *{ // Conv is just alias for functions
>> of type B => (B, A)
>> x <- int // int is function again of type Conv
>> y <- int
>> xs <- ints(x) // this is just sequence of numbers
>> } *yield *xs.map(_ * y)
>>
>> I don't need all the nuts and bolts, just some guideline for achieving
>> something similar
>> in Clojure.
>>
>> I am not lazy :) I've already eagerly researched a bit and got to this: Scala
>> for-comprehension to Clojure
>> <http://stackoverflow.com/questions/25655132/how-to-convert-this-map-flatmap-into-a-for-comprehension-in-clojure>
>>
>> But as you can see that is not really about having kind of generator
>> function which is wrapped into flatMap
>> call. Perhaps this is not in Clojure's spirit at all, perhaps there is
>> some Clojure idiom to achieve something similar.
>>
>> Any tip, suggestion, critic is welcome and appreciated.
>>
>> If someone is wondering how in the world I came up to this, I am doing
>> some f-p exercises which I've got Scala solution for
>> however I am not very interested in Scala and I am doing Clojure so I
>> just need to grasp concepts...
>>
>> Thanks in advance...
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@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
> <javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@googlegroups.com');>.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Scala for-comprehension to Clojure

[Chris Murphy]

It is the same thing in Clojure. It is called a 'list comprehension' even
although for form for it starts with `for`  I wouldn't worry too much about
the flatmap / mapcat stuff, as I think the translation should be quite
direct at the higher 'comprehension' level.
On Nov 26, 2015 10:12 PM, "Rastko Soskic" <rss...@gmail.com> wrote:

> Hi,
> I am aware of philosophical differences of Scala and Clojure
> but functional programming should be a pretty common ground :)
> Thus I need help, I am trying to mimic Scala's for comprehension in
> Clojure.
>
> Hopefully someone will be able to aid me with the following (perhaps more
> familiar with Scala):
>
> Scala for comprehension is errr how to say "de-sugared" to series
> of map and flatMap calls... thus, it is possible to use plain functions in
> for-comprehension
> like:
> *val *ns: Conv[List[Int]] = *for *{ // Conv is just alias for functions
> of type B => (B, A)
> x <- int // int is function again of type Conv
> y <- int
> xs <- ints(x) // this is just sequence of numbers
> } *yield *xs.map(_ * y)
>
> I don't need all the nuts and bolts, just some guideline for achieving
> something similar
> in Clojure.
>
> I am not lazy :) I've already eagerly researched a bit and got to this: Scala
> for-comprehension to Clojure
> <http://stackoverflow.com/questions/25655132/how-to-convert-this-map-flatmap-into-a-for-comprehension-in-clojure>
>
> But as you can see that is not really about having kind of generator
> function which is wrapped into flatMap
> call. Perhaps this is not in Clojure's spirit at all, perhaps there is
> some Clojure idiom to achieve something similar.
>
> Any tip, suggestion, critic is welcome and appreciated.
>
> If someone is wondering how in the world I came up to this, I am doing
> some f-p exercises which I've got Scala solution for
> however I am not very interested in Scala and I am doing Clojure so I just
> need to grasp concepts...
>
> Thanks in advance...
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Scala for-comprehension to Clojure

[Rastko Soskic]

Hi, I am not sure if it will serve point the best but that is what I have 
received as a koan style problem with Scala solution,
now I am trying to comprehend it fully and convert to Clojure. Like I said 
I am by no means Scala expert.

Let's say we have some Val container which is capable to hold some value 
plus yield another value 
which depends on "mapping" function provided to Val itself (exec param of 
case class).

package question.google.group

object worksheet {
  def unit[S, A](a: A): Val[S, A] =
Val(s => (a, s)) 

  case class Val[S, +A](exec: S => (A, S)) {
def map[B](f: A => B): Val[S, B] =
  flatMap(a => unit(f(a)))
def flatMap[B](f: A => Val[S, B]): Val[S, B] = Val(s => {
  val (a, s1) = exec(s)
  f(a).exec(s1)
})
  }
  
  def int : Val[Int, Int] = Val(x => (x, x + 1)) 

*  val something = for {*
*x <- int*
*y <- int*
*  } yield (x, y)  //> something 
 : question.google.group.Val[Int,(Int, Int)] = Val()*
  
  something.exec(5)   //> res9: ((Int, Int), 
Int) = ((5,6),7)
}

If I am following this example and wikipedia well (on Monads in fp), 
in bottom line Val is a monad given presence of type unit and bind 
(flatMap) operation... But that is not my primary focus here.

It is Scala's for comprehension which expands to map and flatMap calls so 
some intial value (given to exec function) "flows" through it
yielding in the end expected result.

I hope this sheds some more light on what I am seeking for.

@Torsten, thanks for mentioned resources I'll take a look at them.

On Thursday, November 26, 2015 at 12:40:50 PM UTC+1, Gary Verhaegen wrote:
>
> It's a bit hard (at least for me) to see what you're actually trying to do 
> here that would precent a direct translation of your snippet to Clojure's 
> for. Could you perhaps post a complete, self-contained code example in 
> Scala?
>
> On Thursday, 26 November 2015, Torsten Uhlmann <torsten...@gmail.com 
> > wrote:
>
>> Hi Rastko,
>>
>> One way of doing that would be to use the mlet macro from the Cats 
>> library: http://funcool.github.io/cats/latest/#mlet
>>
>> Also, there are several if-lets or when-lets out there that allow 
>> multiple bindings, I used one from https://github.com/ptaoussanis/encore
>>
>> I use Scala's for most of the time when there are Options in the mix that 
>> may or may not hold a value.
>>
>> For binding to generators, Clojures for might be a better fit? 
>> https://clojuredocs.org/clojure.core/for
>>
>> Would that help you?
>>
>> Torsten.
>>
>> PS: I'm learning Clojure myself with Scala and Java background.
>>
>> On Thursday, November 26, 2015 at 12:12:01 PM UTC+1, Rastko Soskic wrote:
>>>
>>> Hi, 
>>> I am aware of philosophical differences of Scala and Clojure
>>> but functional programming should be a pretty common ground :)
>>> Thus I need help, I am trying to mimic Scala's for comprehension in 
>>> Clojure.
>>>
>>> Hopefully someone will be able to aid me with the following (perhaps 
>>> more familiar with Scala):
>>>
>>> Scala for comprehension is errr how to say "de-sugared" to series 
>>> of map and flatMap calls... thus, it is possible to use plain functions 
>>> in for-comprehension
>>> like:
>>> *val *ns: Conv[List[Int]] = *for *{ // Conv is just alias for functions 
>>> of type B => (B, A)
>>> x <- int // int is function again of type Conv
>>> y <- int
>>> xs <- ints(x) // this is just sequence of numbers
>>> } *yield *xs.map(_ * y)
>>>
>>> I don't need all the nuts and bolts, just some guideline for achieving 
>>> something similar
>>> in Clojure.
>>>
>>> I am not lazy :) I've already eagerly researched a bit and got to this: 
>>> Scala 
>>> for-comprehension to Clojure 
>>> <http://stackoverflow.com/questions/25655132/how-to-convert-this-map-flatmap-into-a-for-comprehension-in-clojure>
>>>
>>> But as you can see that is not really about having kind of generator 
>>> function which is wrapped into flatMap
>>> call. Perhaps this is not in Clojure's spirit at all, perhaps there is 
>>> some Clojure idiom to achieve something similar.
>>>
>>> Any tip, suggestion, critic is welcome and appreciated.
>>>
>>> If someone is wondering how in the world I came up to this, I am doing 
>>> some f-p exercises which I've got Scala solution for
>>> however I am not very interested in Scala and

Re: Lazy fold-right, help with Scala translation

[Rastko Soskic]

Posted before finishing :)

Thanks in advance for any tip/suggestion.

Cheers,
R.

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

Lazy fold-right, help with Scala translation

[Rastko Soskic]

Hi,
I have come up this implementation of fold-right in Scala:

def foldRight[B](z: => B)(f: (A, => B) => B): B = // Here, arrow => in 
front of argument means it is arg by name (lazy) and won't be evaluated 
until required
// z - init, f - combining f, and target sequence is 
this match {
  case Cons(h,t) => f(h(), t().foldRight(z)(f)) // If "f" doesn't 
evaluate second arg, there will be no recursion...
  case _ => z
}

Now, I know that Clojure doesn't provide facility such is lazy vals (lazy 
args that is)
and there are lazy sequences.

Could someone aid me in porting it to clojure as plain translation like:

(defn fold-right [z f s] ; z - init, f - combining function, s - target sequence
  (let [[h & t] s]
(if h
  (f h (fold-right z f t))
  z)))

is eager unlike Scala's lazy variant due to fact there are no lazy 
args/vals and argument is evaluated
regardless if function f evaluates really that argument or not.

I know I could use Clojure's reduce and that it is lazy but I'd like to 
figure out how I could achieve this.

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

Re: Lazy fold-right, help with Scala translation

[Elango Cheran]

Hi Rastko,
I was about to respond with the reverse + reduce answer, but it seems that
it was already covered here:
https://groups.google.com/forum/#!topic/clojure/MizwTxHwLE4

But there is a more detailed answer about short-circuiting reduce that you
might also be interested in (using the function 'reduced', which I didn't
know about until now):
http://stackoverflow.com/questions/16800255/how-do-we-do-both-left-and-right-folds-in-clojure

-- Elango

On Thu, Oct 8, 2015 at 6:49 AM, Rastko Soskic  wrote:

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

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

Re: Port of simple Scala match to Clojure core.match

[Rastko Soskic]

Great :) thanks :)

On Friday, July 17, 2015 at 2:14:50 AM UTC+2, Jonathan Winandy wrote:

 Hello ! 

 I think, this branch (without : empty?))

 (match [l prefix]
 *[_ ([] :seq)] true*

 ​is already checking that prefix is empty.

 ​Have a nice day,
 Jon


 On 16 July 2015 at 23:06, Rastko Soskic rss...@gmail.com javascript: 
 wrote:

 Hi, I am getting familiar with Clojure's core.match and
 simply starting with something simple and familar (some Scala match 
 expressions)
 and translating that to core.match variant:
 Check out this function which checks whether sequence starts with another:

 def startsWith[A](l: List[A], prefix: List[A]): Boolean = (l,prefix) 
 match {
 case (_,Nil) = true
 case (Cons(h,t),Cons(h2,t2)) if h == h2 = startsWith(t, t2)
 case _ = false
   }

 and my core.match attempt which works but I am not really sure
 about it as wiki page is not yet exhaustive enough:

 (defn starts-with [l prefix]
   (match [l prefix]
 *[_ ([] :seq : empty?)] true*
 [([h  t] :seq) ([h2  t2] :seq)] (if (= h h2)
 (starts-with t t2)
 false)
 :else false))

 second and third one are nothing special, former is just match 
 continuation.
 First one is of particular interest for me...
 Matching to Nil sequence in clojure is not appropriate as empty sequence 
 simply is not nil
 whereas it is handled differently in scala.

 What I wanted here is to check with empty? function if second argument 
 (prefix)
 is empty sequence... Like I said...it works but I am not sure if there is 
 better 
 way to achieve function application to :seq pattern. I don't need to 
 destructure or bind
 that to any particular var just to check if it is empty.

 Any tip, suggestion or critic is welcome and appreciated.

 Thanks in advance.

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




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

Port of simple Scala match to Clojure core.match

[Rastko Soskic]

Hi, I am getting familiar with Clojure's core.match and
simply starting with something simple and familar (some Scala match 
expressions)
and translating that to core.match variant:
Check out this function which checks whether sequence starts with another:

def startsWith[A](l: List[A], prefix: List[A]): Boolean = (l,prefix) match {
case (_,Nil) = true
case (Cons(h,t),Cons(h2,t2)) if h == h2 = startsWith(t, t2)
case _ = false
  }

and my core.match attempt which works but I am not really sure
about it as wiki page is not yet exhaustive enough:

(defn starts-with [l prefix]
  (match [l prefix]
*[_ ([] :seq : empty?)] true*
[([h  t] :seq) ([h2  t2] :seq)] (if (= h h2)
(starts-with t t2)
false)
:else false))

second and third one are nothing special, former is just match continuation.
First one is of particular interest for me...
Matching to Nil sequence in clojure is not appropriate as empty sequence 
simply is not nil
whereas it is handled differently in scala.

What I wanted here is to check with empty? function if second argument 
(prefix)
is empty sequence... Like I said...it works but I am not sure if there is 
better 
way to achieve function application to :seq pattern. I don't need to 
destructure or bind
that to any particular var just to check if it is empty.

Any tip, suggestion or critic is welcome and appreciated.

Thanks in advance.

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

Re: Port of simple Scala match to Clojure core.match

[Jonathan Winandy]

Hello !

I think, this branch (without : empty?))

(match [l prefix]
*[_ ([] :seq)] true*

​is already checking that prefix is empty.

​Have a nice day,
Jon


On 16 July 2015 at 23:06, Rastko Soskic rss...@gmail.com wrote:

 Hi, I am getting familiar with Clojure's core.match and
 simply starting with something simple and familar (some Scala match
 expressions)
 and translating that to core.match variant:
 Check out this function which checks whether sequence starts with another:

 def startsWith[A](l: List[A], prefix: List[A]): Boolean = (l,prefix) match
 {
 case (_,Nil) = true
 case (Cons(h,t),Cons(h2,t2)) if h == h2 = startsWith(t, t2)
 case _ = false
   }

 and my core.match attempt which works but I am not really sure
 about it as wiki page is not yet exhaustive enough:

 (defn starts-with [l prefix]
   (match [l prefix]
 *[_ ([] :seq : empty?)] true*
 [([h  t] :seq) ([h2  t2] :seq)] (if (= h h2)
 (starts-with t t2)
 false)
 :else false))

 second and third one are nothing special, former is just match
 continuation.
 First one is of particular interest for me...
 Matching to Nil sequence in clojure is not appropriate as empty sequence
 simply is not nil
 whereas it is handled differently in scala.

 What I wanted here is to check with empty? function if second argument
 (prefix)
 is empty sequence... Like I said...it works but I am not sure if there is
 better
 way to achieve function application to :seq pattern. I don't need to
 destructure or bind
 that to any particular var just to check if it is empty.

 Any tip, suggestion or critic is welcome and appreciated.

 Thanks in advance.

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


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

Re: Calling an overloaded Scala function

[Stephen Wakely]

Sorry about the double threads - I messed up and thought the original post
didn't go through.

Looking further into this it seems in Java generics are largely a compile
time thing. The generic type information is wiped out from the type on
compile. So how does Java know which overload to call when the only
difference in the generic type of the parameter?

The answer is - it doesn't.

I whipped up a quick bit of Java to test this :



public static String Onk(ArrayListString str) {
System.out.println(string);
return ;
}

public static int Onk(ArrayListInteger it) {
System.out.println(int);
return 0;
}



This fails to compile :


Error:(11, 24) java: name clash:
Onk(java.util.ArrayListjava.lang.Integer) and
Onk(java.util.ArrayListjava.lang.String) have the same erasure




This sort of thing doesn't seem to be a problem for Scala, so it must be
doing something funky under the hood to resolve these methods.


Now, I can get the generic information about these methods using reflection
:

(- Dist$/MODULE$ type .getMethods vec (map #(.getGenericParameterTypes
%))  pprint)

gives me :

([#ParameterizedTypeImpl
scala.collection.Seqscala.Tuple2java.lang.Object,
com.cra.figaro.language.ElementT,
  #ParameterizedTypeImpl com.cra.figaro.language.NameT,
  com.cra.figaro.language.ElementCollection]
 [#ParameterizedTypeImpl
scala.collection.Seqscala.Tuple2com.cra.figaro.language.Elementjava.lang.Object,
com.cra.figaro.language.ElementT,
  #ParameterizedTypeImpl com.cra.figaro.language.NameT,
  com.cra.figaro.language.ElementCollection]


So in theory I think I should be able to hack something together to resolve
to the correct method. It won't be fast - or elegant, but hopefully it can
work.


Thanks




On Fri, Jun 26, 2015 at 3:38 AM Ambrose Bonnaire-Sergeant 
abonnaireserge...@gmail.com wrote:

 That was meant as a response to the other thread.

 On Fri, Jun 26, 2015 at 10:35 AM, Ambrose Bonnaire-Sergeant 
 abonnaireserge...@gmail.com wrote:

 They apparently differ in the return type. I don't think
 clojure.lang.Reflector considers the return type hint
 when resolving methods.

 Thanks,
 Ambrose

 On Fri, Jun 26, 2015 at 4:16 AM, Stephen Wakely 
 fungus.humun...@gmail.com wrote:

 javap gives :

  public T com.cra.figaro.language.AtomicDistT
 apply(scala.collection.Seqscala.Tuple2java.lang.Object,
 com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT,
 com.cra.figaro.language.ElementCollection);

   public T com.cra.figaro.language.CompoundDistT
 apply(scala.collection.Seqscala.Tuple2com.cra.figaro.language.Elementjava.lang.Object,
 com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT,
 com.cra.figaro.language.ElementCollection);


 Bit of an eyesore, but the two methods only differ in the generic types..

 On Thu, Jun 25, 2015 at 9:11 PM Stephen Wakely 
 fungus.humun...@gmail.com wrote:


 So using reflection on the objects gives the following signatures -
 they have identical signatures :

 {:name apply,
 :return-type com.cra.figaro.language.CompoundDist,
 :declaring-class com.cra.figaro.language.Dist$,
 :parameter-types
 [scala.collection.Seq
  com.cra.figaro.language.Name
  com.cra.figaro.language.ElementCollection],
 :exception-types [],
 :flags #{:public}}
{:name apply,
 :return-type com.cra.figaro.language.AtomicDist,
 :declaring-class com.cra.figaro.language.Dist$,
 :parameter-types
 [scala.collection.Seq
  com.cra.figaro.language.Name
  com.cra.figaro.language.ElementCollection],
 :exception-types [],
 :flags #{:public}}


 On Thu, Jun 25, 2015 at 9:05 PM Stuart Sierra 
 the.stuart.sie...@gmail.com wrote:

 Scala has to compile down to JVM bytecode just like Clojure, but it
 may change method signatures along the way.

 You could try running `javap` to disassemble the compiled Scala
 bytecode and figure out what the method signatures actually are. Or use
 Java reflection to examine the objects you have and see what methods they
 declare.

 –S



 On Tuesday, June 23, 2015 at 10:51:55 AM UTC-4, Stephen Wakely wrote:

 I am trying to call into some Scala that has the following overloaded
 methods :

   def apply[T](clauses: (Double, Element[T])*)(implicit name:
 Name[T], collection: ElementCollection) =
 new AtomicDist(name, clauses.toList, collection)

   def apply[T](clauses: (Element[Double], Element[T])*)(implicit
 name: Name[T], collection: ElementCollection) =
 new CompoundDist(name, clauses.toList, collection)

 So one method takes a list of tuples of Double to Element and the
 other method takes a list of tuples of Element to Element.

 I am using t6.from-scala (https://github.com/t6/from-scala) to build
 up my list of Tuples. But when building these up there is no way to 
 specify
 explicit type information about the collections. Consequently when 
 calling
 this apply method Clojure will always choose to call the first method -
 even when my list is a collection of Element to Element

Re: Calling an overloaded Scala function

[Stephen Wakely]

I want to fully understand what is going on before doing anything.

Interestingly if I convert the Java code below to Scala it fails to compile
with the same error :

def Onk(str: util.ArrayList[String]): String = {
  println(String)
   erk
 }

 def Onk(it: util.ArrayList[Integer]): Integer = {
  println(Int)
   0
 }


But changing it to using (I think) more idiomatic Scala compiles and runs
fine.


 def Onk(str: (String)*): String = {
  println(String)
   erk
 }

 def Onk(it: (Integer)*): Integer = {
  println(Int)
   0
 }



On Fri, Jun 26, 2015 at 12:27 PM Ambrose Bonnaire-Sergeant 
abonnaireserge...@gmail.com wrote:

 Have you considered writing a wrapper method in Scala and calling that?

 Thanks,
 Ambrose

 On Fri, Jun 26, 2015 at 7:24 PM, Stephen Wakely fungus.humun...@gmail.com
  wrote:

 Sorry about the double threads - I messed up and thought the original
 post didn't go through.

 Looking further into this it seems in Java generics are largely a compile
 time thing. The generic type information is wiped out from the type on
 compile. So how does Java know which overload to call when the only
 difference in the generic type of the parameter?

 The answer is - it doesn't.

 I whipped up a quick bit of Java to test this :



 public static String Onk(ArrayListString str) {
 System.out.println(string);
 return ;
 }

 public static int Onk(ArrayListInteger it) {
 System.out.println(int);
 return 0;
 }



 This fails to compile :


 Error:(11, 24) java: name clash:
 Onk(java.util.ArrayListjava.lang.Integer) and
 Onk(java.util.ArrayListjava.lang.String) have the same erasure




 This sort of thing doesn't seem to be a problem for Scala, so it must be
 doing something funky under the hood to resolve these methods.


 Now, I can get the generic information about these methods using
 reflection :

 (- Dist$/MODULE$ type .getMethods vec (map #(.getGenericParameterTypes
 %))  pprint)

 gives me :

 ([#ParameterizedTypeImpl
 scala.collection.Seqscala.Tuple2java.lang.Object,
 com.cra.figaro.language.ElementT,
   #ParameterizedTypeImpl com.cra.figaro.language.NameT,
   com.cra.figaro.language.ElementCollection]
  [#ParameterizedTypeImpl
 scala.collection.Seqscala.Tuple2com.cra.figaro.language.Elementjava.lang.Object,
 com.cra.figaro.language.ElementT,
   #ParameterizedTypeImpl com.cra.figaro.language.NameT,
   com.cra.figaro.language.ElementCollection]


 So in theory I think I should be able to hack something together to
 resolve to the correct method. It won't be fast - or elegant, but hopefully
 it can work.


 Thanks




 On Fri, Jun 26, 2015 at 3:38 AM Ambrose Bonnaire-Sergeant 
 abonnaireserge...@gmail.com wrote:

 That was meant as a response to the other thread.

 On Fri, Jun 26, 2015 at 10:35 AM, Ambrose Bonnaire-Sergeant 
 abonnaireserge...@gmail.com wrote:

 They apparently differ in the return type. I don't think
 clojure.lang.Reflector considers the return type hint
 when resolving methods.

 Thanks,
 Ambrose

 On Fri, Jun 26, 2015 at 4:16 AM, Stephen Wakely 
 fungus.humun...@gmail.com wrote:

 javap gives :

  public T com.cra.figaro.language.AtomicDistT
 apply(scala.collection.Seqscala.Tuple2java.lang.Object,
 com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT,
 com.cra.figaro.language.ElementCollection);

   public T com.cra.figaro.language.CompoundDistT
 apply(scala.collection.Seqscala.Tuple2com.cra.figaro.language.Elementjava.lang.Object,
 com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT,
 com.cra.figaro.language.ElementCollection);


 Bit of an eyesore, but the two methods only differ in the generic
 types..

 On Thu, Jun 25, 2015 at 9:11 PM Stephen Wakely 
 fungus.humun...@gmail.com wrote:


 So using reflection on the objects gives the following signatures -
 they have identical signatures :

 {:name apply,
 :return-type com.cra.figaro.language.CompoundDist,
 :declaring-class com.cra.figaro.language.Dist$,
 :parameter-types
 [scala.collection.Seq
  com.cra.figaro.language.Name
  com.cra.figaro.language.ElementCollection],
 :exception-types [],
 :flags #{:public}}
{:name apply,
 :return-type com.cra.figaro.language.AtomicDist,
 :declaring-class com.cra.figaro.language.Dist$,
 :parameter-types
 [scala.collection.Seq
  com.cra.figaro.language.Name
  com.cra.figaro.language.ElementCollection],
 :exception-types [],
 :flags #{:public}}


 On Thu, Jun 25, 2015 at 9:05 PM Stuart Sierra 
 the.stuart.sie...@gmail.com wrote:

 Scala has to compile down to JVM bytecode just like Clojure, but it
 may change method signatures along the way.

 You could try running `javap` to disassemble the compiled Scala
 bytecode and figure out what the method signatures actually are. Or use
 Java reflection to examine the objects you have and see what methods 
 they
 declare.

 –S



 On Tuesday, June 23, 2015 at 10:51:55 AM UTC-4, Stephen Wakely wrote:

 I am trying to call into some Scala that has

Re: Calling an overloaded Scala function

[Ambrose Bonnaire-Sergeant]

Have you considered writing a wrapper method in Scala and calling that?

Thanks,
Ambrose

On Fri, Jun 26, 2015 at 7:24 PM, Stephen Wakely fungus.humun...@gmail.com
wrote:

 Sorry about the double threads - I messed up and thought the original post
 didn't go through.

 Looking further into this it seems in Java generics are largely a compile
 time thing. The generic type information is wiped out from the type on
 compile. So how does Java know which overload to call when the only
 difference in the generic type of the parameter?

 The answer is - it doesn't.

 I whipped up a quick bit of Java to test this :



 public static String Onk(ArrayListString str) {
 System.out.println(string);
 return ;
 }

 public static int Onk(ArrayListInteger it) {
 System.out.println(int);
 return 0;
 }



 This fails to compile :


 Error:(11, 24) java: name clash:
 Onk(java.util.ArrayListjava.lang.Integer) and
 Onk(java.util.ArrayListjava.lang.String) have the same erasure




 This sort of thing doesn't seem to be a problem for Scala, so it must be
 doing something funky under the hood to resolve these methods.


 Now, I can get the generic information about these methods using
 reflection :

 (- Dist$/MODULE$ type .getMethods vec (map #(.getGenericParameterTypes
 %))  pprint)

 gives me :

 ([#ParameterizedTypeImpl
 scala.collection.Seqscala.Tuple2java.lang.Object,
 com.cra.figaro.language.ElementT,
   #ParameterizedTypeImpl com.cra.figaro.language.NameT,
   com.cra.figaro.language.ElementCollection]
  [#ParameterizedTypeImpl
 scala.collection.Seqscala.Tuple2com.cra.figaro.language.Elementjava.lang.Object,
 com.cra.figaro.language.ElementT,
   #ParameterizedTypeImpl com.cra.figaro.language.NameT,
   com.cra.figaro.language.ElementCollection]


 So in theory I think I should be able to hack something together to
 resolve to the correct method. It won't be fast - or elegant, but hopefully
 it can work.


 Thanks




 On Fri, Jun 26, 2015 at 3:38 AM Ambrose Bonnaire-Sergeant 
 abonnaireserge...@gmail.com wrote:

 That was meant as a response to the other thread.

 On Fri, Jun 26, 2015 at 10:35 AM, Ambrose Bonnaire-Sergeant 
 abonnaireserge...@gmail.com wrote:

 They apparently differ in the return type. I don't think
 clojure.lang.Reflector considers the return type hint
 when resolving methods.

 Thanks,
 Ambrose

 On Fri, Jun 26, 2015 at 4:16 AM, Stephen Wakely 
 fungus.humun...@gmail.com wrote:

 javap gives :

  public T com.cra.figaro.language.AtomicDistT
 apply(scala.collection.Seqscala.Tuple2java.lang.Object,
 com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT,
 com.cra.figaro.language.ElementCollection);

   public T com.cra.figaro.language.CompoundDistT
 apply(scala.collection.Seqscala.Tuple2com.cra.figaro.language.Elementjava.lang.Object,
 com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT,
 com.cra.figaro.language.ElementCollection);


 Bit of an eyesore, but the two methods only differ in the generic
 types..

 On Thu, Jun 25, 2015 at 9:11 PM Stephen Wakely 
 fungus.humun...@gmail.com wrote:


 So using reflection on the objects gives the following signatures -
 they have identical signatures :

 {:name apply,
 :return-type com.cra.figaro.language.CompoundDist,
 :declaring-class com.cra.figaro.language.Dist$,
 :parameter-types
 [scala.collection.Seq
  com.cra.figaro.language.Name
  com.cra.figaro.language.ElementCollection],
 :exception-types [],
 :flags #{:public}}
{:name apply,
 :return-type com.cra.figaro.language.AtomicDist,
 :declaring-class com.cra.figaro.language.Dist$,
 :parameter-types
 [scala.collection.Seq
  com.cra.figaro.language.Name
  com.cra.figaro.language.ElementCollection],
 :exception-types [],
 :flags #{:public}}


 On Thu, Jun 25, 2015 at 9:05 PM Stuart Sierra 
 the.stuart.sie...@gmail.com wrote:

 Scala has to compile down to JVM bytecode just like Clojure, but it
 may change method signatures along the way.

 You could try running `javap` to disassemble the compiled Scala
 bytecode and figure out what the method signatures actually are. Or use
 Java reflection to examine the objects you have and see what methods they
 declare.

 –S



 On Tuesday, June 23, 2015 at 10:51:55 AM UTC-4, Stephen Wakely wrote:

 I am trying to call into some Scala that has the following
 overloaded methods :

   def apply[T](clauses: (Double, Element[T])*)(implicit name:
 Name[T], collection: ElementCollection) =
 new AtomicDist(name, clauses.toList, collection)

   def apply[T](clauses: (Element[Double], Element[T])*)(implicit
 name: Name[T], collection: ElementCollection) =
 new CompoundDist(name, clauses.toList, collection)

 So one method takes a list of tuples of Double to Element and the
 other method takes a list of tuples of Element to Element.

 I am using t6.from-scala (https://github.com/t6/from-scala) to
 build up my list of Tuples. But when building these up there is no way

Re: Calling an overloaded Scala function

[Stephen Wakely]

Interesting. That could be a good last resort.

On Thu, Jun 25, 2015 at 1:27 PM Andy Fingerhut andy.finger...@gmail.com
wrote:

 Sorry, I do not know whether Clojure can or cannot determine the correct
 overload in this situation.

 All I have is a weak suggestion that work well enough: have you considered
 creating wrapper functions, e.g. in Scala or Java, that have different
 enough function signatures that Clojure can easily determine the correct
 one?

 Andy

 On Thu, Jun 25, 2015 at 1:54 AM, Stephen Wakely fungus.humun...@gmail.com
  wrote:

 I am trying to call into some Scala that has the following overloaded
 methods :

   def apply[T](clauses: (Double, Element[T])*)(implicit name: Name[T],
 collection: ElementCollection) =
 new AtomicDist(name, clauses.toList, collection)

   def apply[T](clauses: (Element[Double], Element[T])*)(implicit name:
 Name[T], collection: ElementCollection) =
 new CompoundDist(name, clauses.toList, collection)

 So one method takes a list of tuples of Double to Element and the other
 method takes a list of tuples of Element to Element.

 I am using t6.from-scala (https://github.com/t6/from-scala) to build up
 my list of Tuples. But when building these up there is no way to specify
 explicit type information about the collections. Consequently when calling
 this apply method Clojure will always choose to call the first method -
 even when my list is a collection of Element to Element tuples.

 I can definitely appreciate how it is going to be tricky for Clojure to
 determine the correct overload to use here. Is there any way I can somehow
 force it to call the correct overload myself?


 Thanks

 Stephen

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


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


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

Re: Calling an overloaded Scala function

[Andy Fingerhut]

Sorry, I do not know whether Clojure can or cannot determine the correct
overload in this situation.

All I have is a weak suggestion that work well enough: have you considered
creating wrapper functions, e.g. in Scala or Java, that have different
enough function signatures that Clojure can easily determine the correct
one?

Andy

On Thu, Jun 25, 2015 at 1:54 AM, Stephen Wakely fungus.humun...@gmail.com
wrote:

 I am trying to call into some Scala that has the following overloaded
 methods :

   def apply[T](clauses: (Double, Element[T])*)(implicit name: Name[T],
 collection: ElementCollection) =
 new AtomicDist(name, clauses.toList, collection)

   def apply[T](clauses: (Element[Double], Element[T])*)(implicit name:
 Name[T], collection: ElementCollection) =
 new CompoundDist(name, clauses.toList, collection)

 So one method takes a list of tuples of Double to Element and the other
 method takes a list of tuples of Element to Element.

 I am using t6.from-scala (https://github.com/t6/from-scala) to build up
 my list of Tuples. But when building these up there is no way to specify
 explicit type information about the collections. Consequently when calling
 this apply method Clojure will always choose to call the first method -
 even when my list is a collection of Element to Element tuples.

 I can definitely appreciate how it is going to be tricky for Clojure to
 determine the correct overload to use here. Is there any way I can somehow
 force it to call the correct overload myself?


 Thanks

 Stephen

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


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

Re: Calling an overloaded Scala function

[Ambrose Bonnaire-Sergeant]

Do you know how to call this method from Java 1.4? That will probably give
enough context to use in Clojure type hints.

Thanks,
Ambrose

On Thu, Jun 25, 2015 at 9:03 PM, Stephen Wakely fungus.humun...@gmail.com
wrote:

 Interesting. That could be a good last resort.

 On Thu, Jun 25, 2015 at 1:27 PM Andy Fingerhut andy.finger...@gmail.com
 wrote:

 Sorry, I do not know whether Clojure can or cannot determine the correct
 overload in this situation.

 All I have is a weak suggestion that work well enough: have you
 considered creating wrapper functions, e.g. in Scala or Java, that have
 different enough function signatures that Clojure can easily determine the
 correct one?

 Andy

 On Thu, Jun 25, 2015 at 1:54 AM, Stephen Wakely 
 fungus.humun...@gmail.com wrote:

 I am trying to call into some Scala that has the following overloaded
 methods :

   def apply[T](clauses: (Double, Element[T])*)(implicit name: Name[T],
 collection: ElementCollection) =
 new AtomicDist(name, clauses.toList, collection)

   def apply[T](clauses: (Element[Double], Element[T])*)(implicit name:
 Name[T], collection: ElementCollection) =
 new CompoundDist(name, clauses.toList, collection)

 So one method takes a list of tuples of Double to Element and the other
 method takes a list of tuples of Element to Element.

 I am using t6.from-scala (https://github.com/t6/from-scala) to build up
 my list of Tuples. But when building these up there is no way to specify
 explicit type information about the collections. Consequently when calling
 this apply method Clojure will always choose to call the first method -
 even when my list is a collection of Element to Element tuples.

 I can definitely appreciate how it is going to be tricky for Clojure to
 determine the correct overload to use here. Is there any way I can somehow
 force it to call the correct overload myself?


 Thanks

 Stephen

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


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

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


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

Re: Calling an overloaded Scala function

[Stuart Sierra]

Scala has to compile down to JVM bytecode just like Clojure, but it may 
change method signatures along the way.

You could try running `javap` to disassemble the compiled Scala bytecode 
and figure out what the method signatures actually are. Or use Java 
reflection to examine the objects you have and see what methods they 
declare.

–S


On Tuesday, June 23, 2015 at 10:51:55 AM UTC-4, Stephen Wakely wrote:

 I am trying to call into some Scala that has the following overloaded 
 methods :

   def apply[T](clauses: (Double, Element[T])*)(implicit name: Name[T], 
 collection: ElementCollection) =
 new AtomicDist(name, clauses.toList, collection)

   def apply[T](clauses: (Element[Double], Element[T])*)(implicit name: 
 Name[T], collection: ElementCollection) =
 new CompoundDist(name, clauses.toList, collection)

 So one method takes a list of tuples of Double to Element and the other 
 method takes a list of tuples of Element to Element.

 I am using t6.from-scala (https://github.com/t6/from-scala) to build up 
 my list of Tuples. But when building these up there is no way to specify 
 explicit type information about the collections. Consequently when calling 
 this apply method Clojure will always choose to call the first method - 
 even when my list is a collection of Element to Element tuples. 

 I can definitely appreciate how it is going to be tricky for Clojure to 
 determine the correct overload to use here. Is there any way I can somehow 
 force it to call the correct overload myself?


 Thanks

 Stephen





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

Re: Calling an overloaded Scala function

[Stephen Wakely]

So using reflection on the objects gives the following signatures - they
have identical signatures :

{:name apply,
:return-type com.cra.figaro.language.CompoundDist,
:declaring-class com.cra.figaro.language.Dist$,
:parameter-types
[scala.collection.Seq
 com.cra.figaro.language.Name
 com.cra.figaro.language.ElementCollection],
:exception-types [],
:flags #{:public}}
   {:name apply,
:return-type com.cra.figaro.language.AtomicDist,
:declaring-class com.cra.figaro.language.Dist$,
:parameter-types
[scala.collection.Seq
 com.cra.figaro.language.Name
 com.cra.figaro.language.ElementCollection],
:exception-types [],
:flags #{:public}}


On Thu, Jun 25, 2015 at 9:05 PM Stuart Sierra the.stuart.sie...@gmail.com
wrote:

 Scala has to compile down to JVM bytecode just like Clojure, but it may
 change method signatures along the way.

 You could try running `javap` to disassemble the compiled Scala bytecode
 and figure out what the method signatures actually are. Or use Java
 reflection to examine the objects you have and see what methods they
 declare.

 –S



 On Tuesday, June 23, 2015 at 10:51:55 AM UTC-4, Stephen Wakely wrote:

 I am trying to call into some Scala that has the following overloaded
 methods :

   def apply[T](clauses: (Double, Element[T])*)(implicit name: Name[T],
 collection: ElementCollection) =
 new AtomicDist(name, clauses.toList, collection)

   def apply[T](clauses: (Element[Double], Element[T])*)(implicit name:
 Name[T], collection: ElementCollection) =
 new CompoundDist(name, clauses.toList, collection)

 So one method takes a list of tuples of Double to Element and the other
 method takes a list of tuples of Element to Element.

 I am using t6.from-scala (https://github.com/t6/from-scala) to build up
 my list of Tuples. But when building these up there is no way to specify
 explicit type information about the collections. Consequently when calling
 this apply method Clojure will always choose to call the first method -
 even when my list is a collection of Element to Element tuples.

 I can definitely appreciate how it is going to be tricky for Clojure to
 determine the correct overload to use here. Is there any way I can somehow
 force it to call the correct overload myself?


 Thanks

 Stephen



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


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

Re: Calling an overloaded Scala function

[Stephen Wakely]

javap gives :

 public T com.cra.figaro.language.AtomicDistT
apply(scala.collection.Seqscala.Tuple2java.lang.Object,
com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT,
com.cra.figaro.language.ElementCollection);

  public T com.cra.figaro.language.CompoundDistT
apply(scala.collection.Seqscala.Tuple2com.cra.figaro.language.Elementjava.lang.Object,
com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT,
com.cra.figaro.language.ElementCollection);


Bit of an eyesore, but the two methods only differ in the generic types..

On Thu, Jun 25, 2015 at 9:11 PM Stephen Wakely fungus.humun...@gmail.com
wrote:


 So using reflection on the objects gives the following signatures - they
 have identical signatures :

 {:name apply,
 :return-type com.cra.figaro.language.CompoundDist,
 :declaring-class com.cra.figaro.language.Dist$,
 :parameter-types
 [scala.collection.Seq
  com.cra.figaro.language.Name
  com.cra.figaro.language.ElementCollection],
 :exception-types [],
 :flags #{:public}}
{:name apply,
 :return-type com.cra.figaro.language.AtomicDist,
 :declaring-class com.cra.figaro.language.Dist$,
 :parameter-types
 [scala.collection.Seq
  com.cra.figaro.language.Name
  com.cra.figaro.language.ElementCollection],
 :exception-types [],
 :flags #{:public}}


 On Thu, Jun 25, 2015 at 9:05 PM Stuart Sierra the.stuart.sie...@gmail.com
 wrote:

 Scala has to compile down to JVM bytecode just like Clojure, but it may
 change method signatures along the way.

 You could try running `javap` to disassemble the compiled Scala bytecode
 and figure out what the method signatures actually are. Or use Java
 reflection to examine the objects you have and see what methods they
 declare.

 –S



 On Tuesday, June 23, 2015 at 10:51:55 AM UTC-4, Stephen Wakely wrote:

 I am trying to call into some Scala that has the following overloaded
 methods :

   def apply[T](clauses: (Double, Element[T])*)(implicit name: Name[T],
 collection: ElementCollection) =
 new AtomicDist(name, clauses.toList, collection)

   def apply[T](clauses: (Element[Double], Element[T])*)(implicit name:
 Name[T], collection: ElementCollection) =
 new CompoundDist(name, clauses.toList, collection)

 So one method takes a list of tuples of Double to Element and the other
 method takes a list of tuples of Element to Element.

 I am using t6.from-scala (https://github.com/t6/from-scala) to build up
 my list of Tuples. But when building these up there is no way to specify
 explicit type information about the collections. Consequently when calling
 this apply method Clojure will always choose to call the first method -
 even when my list is a collection of Element to Element tuples.

 I can definitely appreciate how it is going to be tricky for Clojure to
 determine the correct overload to use here. Is there any way I can somehow
 force it to call the correct overload myself?


 Thanks

 Stephen



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



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

Re: Calling an overloaded Scala function

[Stephen Wakely]

I am sadly quite clueless when it comes to Java.

De-compiling the Scala class file to Java gives me the following:

public T AtomicDistT apply(SeqTuple2Object, ElementT clauses,
NameT name, ElementCollection collection) {
return new AtomicDist(name, clauses.toList(), collection);

}



public T CompoundDistT apply(SeqTuple2ElementObject,
ElementT clauses, NameT name, ElementCollection collection) {


return new CompoundDist(name, clauses.toList(), collection);

}




Generics all over the place. Would this even be callable from Java 1.4?





On Thu, Jun 25, 2015 at 2:13 PM Ambrose Bonnaire-Sergeant 
abonnaireserge...@gmail.com wrote:

 Do you know how to call this method from Java 1.4? That will probably give
 enough context to use in Clojure type hints.

 Thanks,
 Ambrose

 On Thu, Jun 25, 2015 at 9:03 PM, Stephen Wakely fungus.humun...@gmail.com
  wrote:

 Interesting. That could be a good last resort.

 On Thu, Jun 25, 2015 at 1:27 PM Andy Fingerhut andy.finger...@gmail.com
 wrote:

 Sorry, I do not know whether Clojure can or cannot determine the correct
 overload in this situation.

 All I have is a weak suggestion that work well enough: have you
 considered creating wrapper functions, e.g. in Scala or Java, that have
 different enough function signatures that Clojure can easily determine the
 correct one?

 Andy

 On Thu, Jun 25, 2015 at 1:54 AM, Stephen Wakely 
 fungus.humun...@gmail.com wrote:

 I am trying to call into some Scala that has the following overloaded
 methods :

   def apply[T](clauses: (Double, Element[T])*)(implicit name: Name[T],
 collection: ElementCollection) =
 new AtomicDist(name, clauses.toList, collection)

   def apply[T](clauses: (Element[Double], Element[T])*)(implicit name:
 Name[T], collection: ElementCollection) =
 new CompoundDist(name, clauses.toList, collection)

 So one method takes a list of tuples of Double to Element and the other
 method takes a list of tuples of Element to Element.

 I am using t6.from-scala (https://github.com/t6/from-scala) to build
 up my list of Tuples. But when building these up there is no way to specify
 explicit type information about the collections. Consequently when calling
 this apply method Clojure will always choose to call the first method -
 even when my list is a collection of Element to Element tuples.

 I can definitely appreciate how it is going to be tricky for Clojure to
 determine the correct overload to use here. Is there any way I can somehow
 force it to call the correct overload myself?


 Thanks

 Stephen

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


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

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


  --
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure

Re: Calling an overloaded Scala function

[Ambrose Bonnaire-Sergeant]

They apparently differ in the return type. I don't think
clojure.lang.Reflector considers the return type hint
when resolving methods.

Thanks,
Ambrose

On Fri, Jun 26, 2015 at 4:16 AM, Stephen Wakely fungus.humun...@gmail.com
wrote:

 javap gives :

  public T com.cra.figaro.language.AtomicDistT
 apply(scala.collection.Seqscala.Tuple2java.lang.Object,
 com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT,
 com.cra.figaro.language.ElementCollection);

   public T com.cra.figaro.language.CompoundDistT
 apply(scala.collection.Seqscala.Tuple2com.cra.figaro.language.Elementjava.lang.Object,
 com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT,
 com.cra.figaro.language.ElementCollection);


 Bit of an eyesore, but the two methods only differ in the generic types..

 On Thu, Jun 25, 2015 at 9:11 PM Stephen Wakely fungus.humun...@gmail.com
 wrote:


 So using reflection on the objects gives the following signatures - they
 have identical signatures :

 {:name apply,
 :return-type com.cra.figaro.language.CompoundDist,
 :declaring-class com.cra.figaro.language.Dist$,
 :parameter-types
 [scala.collection.Seq
  com.cra.figaro.language.Name
  com.cra.figaro.language.ElementCollection],
 :exception-types [],
 :flags #{:public}}
{:name apply,
 :return-type com.cra.figaro.language.AtomicDist,
 :declaring-class com.cra.figaro.language.Dist$,
 :parameter-types
 [scala.collection.Seq
  com.cra.figaro.language.Name
  com.cra.figaro.language.ElementCollection],
 :exception-types [],
 :flags #{:public}}


 On Thu, Jun 25, 2015 at 9:05 PM Stuart Sierra 
 the.stuart.sie...@gmail.com wrote:

 Scala has to compile down to JVM bytecode just like Clojure, but it may
 change method signatures along the way.

 You could try running `javap` to disassemble the compiled Scala bytecode
 and figure out what the method signatures actually are. Or use Java
 reflection to examine the objects you have and see what methods they
 declare.

 –S



 On Tuesday, June 23, 2015 at 10:51:55 AM UTC-4, Stephen Wakely wrote:

 I am trying to call into some Scala that has the following overloaded
 methods :

   def apply[T](clauses: (Double, Element[T])*)(implicit name: Name[T],
 collection: ElementCollection) =
 new AtomicDist(name, clauses.toList, collection)

   def apply[T](clauses: (Element[Double], Element[T])*)(implicit name:
 Name[T], collection: ElementCollection) =
 new CompoundDist(name, clauses.toList, collection)

 So one method takes a list of tuples of Double to Element and the other
 method takes a list of tuples of Element to Element.

 I am using t6.from-scala (https://github.com/t6/from-scala) to build
 up my list of Tuples. But when building these up there is no way to specify
 explicit type information about the collections. Consequently when calling
 this apply method Clojure will always choose to call the first method -
 even when my list is a collection of Element to Element tuples.

 I can definitely appreciate how it is going to be tricky for Clojure to
 determine the correct overload to use here. Is there any way I can somehow
 force it to call the correct overload myself?


 Thanks

 Stephen



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

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


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

Re: Calling an overloaded Scala function

[Ambrose Bonnaire-Sergeant]

That was meant as a response to the other thread.

On Fri, Jun 26, 2015 at 10:35 AM, Ambrose Bonnaire-Sergeant 
abonnaireserge...@gmail.com wrote:

 They apparently differ in the return type. I don't think
 clojure.lang.Reflector considers the return type hint
 when resolving methods.

 Thanks,
 Ambrose

 On Fri, Jun 26, 2015 at 4:16 AM, Stephen Wakely fungus.humun...@gmail.com
  wrote:

 javap gives :

  public T com.cra.figaro.language.AtomicDistT
 apply(scala.collection.Seqscala.Tuple2java.lang.Object,
 com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT,
 com.cra.figaro.language.ElementCollection);

   public T com.cra.figaro.language.CompoundDistT
 apply(scala.collection.Seqscala.Tuple2com.cra.figaro.language.Elementjava.lang.Object,
 com.cra.figaro.language.ElementT, com.cra.figaro.language.NameT,
 com.cra.figaro.language.ElementCollection);


 Bit of an eyesore, but the two methods only differ in the generic types..

 On Thu, Jun 25, 2015 at 9:11 PM Stephen Wakely fungus.humun...@gmail.com
 wrote:


 So using reflection on the objects gives the following signatures - they
 have identical signatures :

 {:name apply,
 :return-type com.cra.figaro.language.CompoundDist,
 :declaring-class com.cra.figaro.language.Dist$,
 :parameter-types
 [scala.collection.Seq
  com.cra.figaro.language.Name
  com.cra.figaro.language.ElementCollection],
 :exception-types [],
 :flags #{:public}}
{:name apply,
 :return-type com.cra.figaro.language.AtomicDist,
 :declaring-class com.cra.figaro.language.Dist$,
 :parameter-types
 [scala.collection.Seq
  com.cra.figaro.language.Name
  com.cra.figaro.language.ElementCollection],
 :exception-types [],
 :flags #{:public}}


 On Thu, Jun 25, 2015 at 9:05 PM Stuart Sierra 
 the.stuart.sie...@gmail.com wrote:

 Scala has to compile down to JVM bytecode just like Clojure, but it may
 change method signatures along the way.

 You could try running `javap` to disassemble the compiled Scala
 bytecode and figure out what the method signatures actually are. Or use
 Java reflection to examine the objects you have and see what methods they
 declare.

 –S



 On Tuesday, June 23, 2015 at 10:51:55 AM UTC-4, Stephen Wakely wrote:

 I am trying to call into some Scala that has the following overloaded
 methods :

   def apply[T](clauses: (Double, Element[T])*)(implicit name: Name[T],
 collection: ElementCollection) =
 new AtomicDist(name, clauses.toList, collection)

   def apply[T](clauses: (Element[Double], Element[T])*)(implicit name:
 Name[T], collection: ElementCollection) =
 new CompoundDist(name, clauses.toList, collection)

 So one method takes a list of tuples of Double to Element and the
 other method takes a list of tuples of Element to Element.

 I am using t6.from-scala (https://github.com/t6/from-scala) to build
 up my list of Tuples. But when building these up there is no way to 
 specify
 explicit type information about the collections. Consequently when calling
 this apply method Clojure will always choose to call the first method -
 even when my list is a collection of Element to Element tuples.

 I can definitely appreciate how it is going to be tricky for Clojure
 to determine the correct overload to use here. Is there any way I can
 somehow force it to call the correct overload myself?


 Thanks

 Stephen



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

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




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

Calling an overloaded Scala function

[Stephen Wakely]

I am trying to call into some Scala that has the following overloaded
methods :

  def apply[T](clauses: (Double, Element[T])*)(implicit name: Name[T],
collection: ElementCollection) =
new AtomicDist(name, clauses.toList, collection)

  def apply[T](clauses: (Element[Double], Element[T])*)(implicit name:
Name[T], collection: ElementCollection) =
new CompoundDist(name, clauses.toList, collection)

So one method takes a list of tuples of Double to Element and the other
method takes a list of tuples of Element to Element.

I am using t6.from-scala (https://github.com/t6/from-scala) to build up my
list of Tuples. But when building these up there is no way to specify
explicit type information about the collections. Consequently when calling
this apply method Clojure will always choose to call the first method -
even when my list is a collection of Element to Element tuples.

I can definitely appreciate how it is going to be tricky for Clojure to
determine the correct overload to use here. Is there any way I can somehow
force it to call the correct overload myself?


Thanks

Stephen

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

Calling an overloaded Scala function

[Stephen Wakely]

I am trying to call into some Scala that has the following overloaded
methods :

  def apply[T](clauses: (Double, Element[T])*)(implicit name: Name[T],
collection: ElementCollection) =
new AtomicDist(name, clauses.toList, collection)

  def apply[T](clauses: (Element[Double], Element[T])*)(implicit name:
Name[T], collection: ElementCollection) =
new CompoundDist(name, clauses.toList, collection)

So one method takes a list of tuples of Double to Element and the other
method takes a list of tuples of Element to Element.

I am using t6.from-scala (https://github.com/t6/from-scala) to build up my
list of Tuples. But when building these up there is no way to specify
explicit type information about the collections. Consequently when calling
this apply method Clojure will always choose to call the first method -
even when my list is a collection of Element to Element tuples.

I can definitely appreciate how it is going to be tricky for Clojure to
determine the correct overload to use here. Is there any way I can somehow
force it to call the correct overload myself?


Thanks

Stephen

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

[ANN] from-scala 0.2.0: An experimental Scala interop library for Clojure

[Tobias Kortkamp]

Hi,

I would like to announce from-scala, an experimental Scala interop
library for Clojure.

Its main feature is the $-macro, a version of Clojure's
.-form.  The $-macro uses Java reflection and a series of heuristics,
so that you will be able to write code like

  ($ ($ scala.collection.immutable.List/empty) :: 1)

instead of the equivalent but ugly

  (.$colon$colon (.empty scala.collection.immutable.List$/MODULE$) 1)

Additionally there are some utility functions for working with case
classes, tuples, options, Scala functions, and Scala collections.

The source code can be found at https://github.com/t6/from-scala and
there are more examples in the guide at
https://t6.github.io/from-scala

To use from Leiningen:

  [t6/from-scala 0.2.0]
  [org.scala-lang/scala-library 2.11.5]

You need to provide your own Scala library.  from-scala has been
tested with Scala 2.10 and 2.11.

If you encounter any bugs or road blocks, have a feature request, or
want to discuss if this is a good or a bad idea, please open an issue
on GitHub.

Thanks,
Tobias

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

Re: Is Clojure more functional then Scala?

[Эльдар Габдуллин]

Clojure targets multiple platforms, Scala - one.

Clojure is Lisp. That means almost any programming paradigm/DSL is just a 
library.

But if you are interested in FP per se, I think Scala illustrates it 
better. 
With strong type system, pattern matching it's much closer to Haskell,
which is the best language to learn in such case. Haskell literally serves 
as a definition
of what FP is and almost every academic paper in FP field is written with 
Haskell nowadays.

понедельник, 16 декабря 2013 г., 7:33:35 UTC+4 пользователь John Kida 
написал:

 I jumped on the FP bandwagon over a year ago and have been using Scala 
 both at work and for personal interest. Recently however I decided to take 
 a closer look at Clojure and see if it is something i actually like. I have 
 to admit at first the syntax form was awkward, but im starting to really 
 see the simplicity behind it.

 I have heard many people claim that Clojure sets you up and supports you 
 for FP more so then Scala does. However they never provide any examples of 
 something Clojure does that is more supporting of FP then the way idiomatic 
 Scala does it.

 Here are some things that I have heard people say when comparing Clojure 
 vs Scala in reference to FP
 Clojure has immutable persistance data structures. but so does Scala
 Scala also tries to get you to use its immutable collections, like 
 Vectors, and are also persistent data structures. However they are not as 
 uniform as Clojures Seq i agree with that.

 Also Scala recommends using vals and not vars, which gives you immutable 
 references points

 I am certainly learning towards dropping Scala for a bit and giving 
 Clojure a real shot. The reason i even picked up Scala was because i wanted 
 to learn more about FP, and if there is a better tool for both doing and 
 learning FP then i want it.

 So tell me, if you have used both Scala and Clojure, do you have some real 
 examples of some things where Clojure really does support you better when 
 doing FP, where Scala really leads you no way, or worse the imperative way?




-- 
-- 
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 more functional then Scala?

[Cedric Greevey]

So, in other words, like most which is the best programming language?
questions, the answer to this one is It depends. :)


On Mon, Dec 16, 2013 at 5:31 AM, Эльдар Габдуллин eldar...@gmail.comwrote:

 Clojure targets multiple platforms, Scala - one.

 Clojure is Lisp. That means almost any programming paradigm/DSL is just a
 library.

 But if you are interested in FP per se, I think Scala illustrates it
 better.
 With strong type system, pattern matching it's much closer to Haskell,
 which is the best language to learn in such case. Haskell literally
 serves as a definition
 of what FP is and almost every academic paper in FP field is written with
 Haskell nowadays.

 понедельник, 16 декабря 2013 г., 7:33:35 UTC+4 пользователь John Kida
 написал:

 I jumped on the FP bandwagon over a year ago and have been using Scala
 both at work and for personal interest. Recently however I decided to take
 a closer look at Clojure and see if it is something i actually like. I have
 to admit at first the syntax form was awkward, but im starting to really
 see the simplicity behind it.

 I have heard many people claim that Clojure sets you up and supports you
 for FP more so then Scala does. However they never provide any examples of
 something Clojure does that is more supporting of FP then the way idiomatic
 Scala does it.

 Here are some things that I have heard people say when comparing Clojure
 vs Scala in reference to FP
 Clojure has immutable persistance data structures. but so does Scala
 Scala also tries to get you to use its immutable collections, like
 Vectors, and are also persistent data structures. However they are not as
 uniform as Clojures Seq i agree with that.

 Also Scala recommends using vals and not vars, which gives you immutable
 references points

 I am certainly learning towards dropping Scala for a bit and giving
 Clojure a real shot. The reason i even picked up Scala was because i wanted
 to learn more about FP, and if there is a better tool for both doing and
 learning FP then i want it.

 So tell me, if you have used both Scala and Clojure, do you have some
 real examples of some things where Clojure really does support you better
 when doing FP, where Scala really leads you no way, or worse the imperative
 way?


  --
 --
 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 more functional then Scala?

[Phillip Lord]

The problem with this question is that Functional Programming means many
different things to different people.

If we define FP negatively (i.e. the language does not allow anything
other than pure functions), then neither Scala or Clojure are FP. I
would side here with Doug Hoyte's Let over Lambda

(http://letoverlambda.com/index.cl/guest/chap5.html#sec_1)

which says As we've seen, macros can invisibly change the meaning of
certain forms from being function calls into arbitrary lisp expressions,
a technique which is capable of violating referential transparency in
many ways that simply aren't possible in other languages. He's talking
about Common Lisp, but Clojure is a lisp and it's true there also.

If we define it to mean, allows many of techiques that come out of FP, I
would say that both do. (Scala recommeds vals not vars, but then so does
Clojure in that it only allows vals, which is calls vars or locals).

Finally, most functional programming research these days is done in
strongly typed systems, and obviously, here, Scala wins hands-down.

My conclusion: if you want to learn functional programming, I'd probably
just use Haskell. If you want to learn FP and do something with it, I'd
pick Scala or Clojure and make the choice on the basis of what it is you
want to do. I picked Clojure because I need strong JVM integration,
and syntactic plasticity. And, of course, the main reason is that I
already knew other lisps, so it was easier.

Phil


John Kida jdk...@gmail.com writes:
 I jumped on the FP bandwagon over a year ago and have been using Scala both 
 at work and for personal interest. Recently however I decided to take a 
 closer look at Clojure and see if it is something i actually like. I have 
 to admit at first the syntax form was awkward, but im starting to really 
 see the simplicity behind it.

 I have heard many people claim that Clojure sets you up and supports you 
 for FP more so then Scala does. However they never provide any examples of 
 something Clojure does that is more supporting of FP then the way idiomatic 
 Scala does it.

 Here are some things that I have heard people say when comparing Clojure vs 
 Scala in reference to FP
 Clojure has immutable persistance data structures. but so does Scala
 Scala also tries to get you to use its immutable collections, like Vectors, 
 and are also persistent data structures. However they are not as uniform as 
 Clojures Seq i agree with that.

 Also Scala recommends using vals and not vars, which gives you immutable 
 references points

 I am certainly learning towards dropping Scala for a bit and giving Clojure 
 a real shot. The reason i even picked up Scala was because i wanted to 
 learn more about FP, and if there is a better tool for both doing and 
 learning FP then i want it.

 So tell me, if you have used both Scala and Clojure, do you have some real 
 examples of some things where Clojure really does support you better when 
 doing FP, where Scala really leads you no way, or worse the imperative way?

-- 
-- 
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 more functional then Scala?

[Luc Prefontaine]

In 2008 I was reviewing options,
we had to move away from Java.

I choose Clojure rather than Scala,
I found Scala quite confusing.
Attempts to pour in FP notions
in an OO language looked too me
as an attempt to transplant a fifth
limb to a four limb made body.

Since then I had a few discussions
with Scala developers and the
answers I got made it clear to me
that choosing Clojure is a better
choice.

The common ground to these answers
is 'do not use mutable collections',
'use values...','this is bad practice,...'

I never got a satisfying answer to
my counter questions 'then why offer
all these features (mutation, objects, ...) easily accessible,
if they are not to be used ?
And how a newbie is suppose to know
how to avoid all these sand traps ?

If you want to use mutation in
Clojure, it's doable but it also
colors your code in a way that makes
it obvious and exceptional somehow.

Clojure sits at the frontier but with
a bias toward FP while being
pragmatic.

We have a problem in this industry,
features inflation. At some point
it becomes useless to add not so
natural features to a language.

Scala is OO derived and adding FP
features will not change it's DNA.

Look at what Java 8 promises and
it will end up in some form of chaos.

Just thinking at what a mixed Java
code base will look like in 10 years
gives me nausea :)

Yes there's a plan to make Cobol
OO aware.

It's not because it's doable that we
should to do it.

http://rotpier.over-blog.com/article-97207983.html


Luc P.

 I jumped on the FP bandwagon over a year ago and have been using Scala both 
 at work and for personal interest. Recently however I decided to take a 
 closer look at Clojure and see if it is something i actually like. I have 
 to admit at first the syntax form was awkward, but im starting to really 
 see the simplicity behind it.
 
 I have heard many people claim that Clojure sets you up and supports you 
 for FP more so then Scala does. However they never provide any examples of 
 something Clojure does that is more supporting of FP then the way idiomatic 
 Scala does it.
 
 Here are some things that I have heard people say when comparing Clojure vs 
 Scala in reference to FP
 Clojure has immutable persistance data structures. but so does Scala
 Scala also tries to get you to use its immutable collections, like Vectors, 
 and are also persistent data structures. However they are not as uniform as 
 Clojures Seq i agree with that.
 
 Also Scala recommends using vals and not vars, which gives you immutable 
 references points
 
 I am certainly learning towards dropping Scala for a bit and giving Clojure 
 a real shot. The reason i even picked up Scala was because i wanted to 
 learn more about FP, and if there is a better tool for both doing and 
 learning FP then i want it.
 
 So tell me, if you have used both Scala and Clojure, do you have some real 
 examples of some things where Clojure really does support you better when 
 doing FP, where Scala really leads you no way, or worse the imperative way?
 
 
 -- 
 -- 
 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 Prefontainelprefonta...@softaddicts.ca 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 more functional then Scala?

[Softaddicts]

The url should have been this one:

http://rotpier27.files.wordpress.com/2012/01/chimc3a8re.jpg

}^}%}%}{[+{^ iPhone screen... too small for my big fingers... 


 In 2008 I was reviewing options,
 we had to move away from Java.
 
 I choose Clojure rather than Scala,
 I found Scala quite confusing.
 Attempts to pour in FP notions
 in an OO language looked too me
 as an attempt to transplant a fifth
 limb to a four limb made body.
 
 Since then I had a few discussions
 with Scala developers and the
 answers I got made it clear to me
 that choosing Clojure is a better
 choice.
 
 The common ground to these answers
 is 'do not use mutable collections',
 'use values...','this is bad practice,...'
 
 I never got a satisfying answer to
 my counter questions 'then why offer
 all these features (mutation, objects, ...) easily accessible,
 if they are not to be used ?
 And how a newbie is suppose to know
 how to avoid all these sand traps ?
 
 If you want to use mutation in
 Clojure, it's doable but it also
 colors your code in a way that makes
 it obvious and exceptional somehow.
 
 Clojure sits at the frontier but with
 a bias toward FP while being
 pragmatic.
 
 We have a problem in this industry,
 features inflation. At some point
 it becomes useless to add not so
 natural features to a language.
 
 Scala is OO derived and adding FP
 features will not change it's DNA.
 
 Look at what Java 8 promises and
 it will end up in some form of chaos.
 
 Just thinking at what a mixed Java
 code base will look like in 10 years
 gives me nausea :)
 
 Yes there's a plan to make Cobol
 OO aware.
 
 It's not because it's doable that we
 should to do it.
 
 http://rotpier.over-blog.com/article-97207983.html
 
 
 Luc P.
 
  I jumped on the FP bandwagon over a year ago and have been using Scala both 
  at work and for personal interest. Recently however I decided to take a 
  closer look at Clojure and see if it is something i actually like. I have 
  to admit at first the syntax form was awkward, but im starting to really 
  see the simplicity behind it.
  
  I have heard many people claim that Clojure sets you up and supports you 
  for FP more so then Scala does. However they never provide any examples of 
  something Clojure does that is more supporting of FP then the way idiomatic 
  Scala does it.
  
  Here are some things that I have heard people say when comparing Clojure vs 
  Scala in reference to FP
  Clojure has immutable persistance data structures. but so does Scala
  Scala also tries to get you to use its immutable collections, like Vectors, 
  and are also persistent data structures. However they are not as uniform as 
  Clojures Seq i agree with that.
  
  Also Scala recommends using vals and not vars, which gives you immutable 
  references points
  
  I am certainly learning towards dropping Scala for a bit and giving Clojure 
  a real shot. The reason i even picked up Scala was because i wanted to 
  learn more about FP, and if there is a better tool for both doing and 
  learning FP then i want it.
  
  So tell me, if you have used both Scala and Clojure, do you have some real 
  examples of some things where Clojure really does support you better when 
  doing FP, where Scala really leads you no way, or worse the imperative way?
  
  
  -- 
  -- 
  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 Prefontainelprefonta...@softaddicts.ca 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.
 
--
Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad!

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post

Re: Is Clojure more functional then Scala?

[Mark Engelberg]

I think you're right that all or nearly all of the functional aspects of
Clojure have counterparts in Scala.  On top of that, Scala provides mutable
flavors of everything, so you can pick and choose your approach.  So that
makes Scala better, right?

But the difference between Clojure and Scala is bigger than a
feature-to-feature comparison -- they have very different philosophies, and
programs developed in Clojure consequently have a very different feel to
them than those developed in Scala.  I find Clojure programs to be
dramatically simpler.

Just as one example, consider modeling a deck of cards.  In Clojure, you'd
be more likely to come up with a simple representation for a card, perhaps:
[10 :spades].  Depending on the card game, you might choose to represent a
face card as [:king :clubs] or [13 :clubs].  A deck would likely be modeled
as just a sequence of cards, and all the built-in sequence functions would
apply, for example, shuffle, take, drop, etc.  Serializing the data (for
example, if you want to keep a database tracking all the shuffled decks
you've ever used in a given game) comes for free.

On the other hand, in Scala, you'd be more likely to create a card Class
with a rank and suit field.  The Suit class would be comprised of four case
classes, because the philosophy is to enumerate all the possible suits as
separate entities -- there's nothing in Scala like Clojure's convenient
keywords.  For the rank, you'd be steered towards representing all the
ranks as integers.  The possibility of representing face cards with a name
would likely never occur to you, because it would be too complicated to go
through the effort of defining the type of a rank to be a integer or a
class comprised of four case classes -- jack,queen,king,ace.  For modeling
the deck, you probably wouldn't say a Deck is-a sequence, because
composition is favored over inheritance.  So you'd probably have a Deck
class which would *contain* a sequence of cards.  This means that you'd
have to reimplement methods like shuffle, take, and drop on your Deck class
to turn around and dispatch those methods to the underlying sequence of
cards.  If you're not careful, years of object-oriented training might kick
in and before you know it, you're representing the deck as a class where
methods like shuffle, take, and drop *destructively update* the underlying
sequence -- it feels so natural to do that once you've encapsulated the
underlying sequence of cards in a class.  If you want to serialize a deck,
that's more code to write (although general pickling of a Scala object is
an *active area of research*).

This example pretty much sums up what I prefer about Clojure.  I like to
tell people that a big part of what makes Clojure special is its philosophy
of *lightweight data modeling*.  It leads to delightfully simple systems.
Scala remains deeply rooted in the OO philosophy, which all too often leads
to an over-engineered muddle.

-- 
-- 
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 more functional then Scala?

[Guru Devanla]

Hi Mark,

A few questions:

1. The point you raise regarding declaring case classes is inherent to the
typed nature of Scala, correct? Can that be pointed to as valid strength of
Clojure. Since, we are comparing static vs dynamic typing here.

2. I am not super familiar with Scale, but I am assuming Scala can do
similar to what we have in ML, which would look like this:

datatype rank = Jack | Queen | King | Ace | Num of int

Isn't a similar idiomatic case class sufficient to achieve the needed
simplicity in Scala?

3. Regarding walking down the path of multiple object hierarchies, I guess
that is only a choice in Scala and is not necessitated by idiomatic Scala.
So, can't one just use the functional construct to achieve what you define
in Clojure?

I believe Scala's blending of static typing with OO and FP principles is a
exciting area of research and only time will tell if we could have all the
features in one big language.  Scala's tries to be different language to
different people depending on which background one approaches from.

I also agree with one other member where it is stated that Scala is just
too complex and Clojure's wins by its simplicity and consistent
representation.

Thanks
Guru



On Mon, Dec 16, 2013 at 12:13 PM, Mark Engelberg
mark.engelb...@gmail.comwrote:

 I think you're right that all or nearly all of the functional aspects of
 Clojure have counterparts in Scala.  On top of that, Scala provides mutable
 flavors of everything, so you can pick and choose your approach.  So that
 makes Scala better, right?

 But the difference between Clojure and Scala is bigger than a
 feature-to-feature comparison -- they have very different philosophies, and
 programs developed in Clojure consequently have a very different feel to
 them than those developed in Scala.  I find Clojure programs to be
 dramatically simpler.

 Just as one example, consider modeling a deck of cards.  In Clojure, you'd
 be more likely to come up with a simple representation for a card, perhaps:
 [10 :spades].  Depending on the card game, you might choose to represent a
 face card as [:king :clubs] or [13 :clubs].  A deck would likely be modeled
 as just a sequence of cards, and all the built-in sequence functions would
 apply, for example, shuffle, take, drop, etc.  Serializing the data (for
 example, if you want to keep a database tracking all the shuffled decks
 you've ever used in a given game) comes for free.

 On the other hand, in Scala, you'd be more likely to create a card Class
 with a rank and suit field.  The Suit class would be comprised of four case
 classes, because the philosophy is to enumerate all the possible suits as
 separate entities -- there's nothing in Scala like Clojure's convenient
 keywords.  For the rank, you'd be steered towards representing all the
 ranks as integers.  The possibility of representing face cards with a name
 would likely never occur to you, because it would be too complicated to go
 through the effort of defining the type of a rank to be a integer or a
 class comprised of four case classes -- jack,queen,king,ace.  For modeling
 the deck, you probably wouldn't say a Deck is-a sequence, because
 composition is favored over inheritance.  So you'd probably have a Deck
 class which would *contain* a sequence of cards.  This means that you'd
 have to reimplement methods like shuffle, take, and drop on your Deck class
 to turn around and dispatch those methods to the underlying sequence of
 cards.  If you're not careful, years of object-oriented training might kick
 in and before you know it, you're representing the deck as a class where
 methods like shuffle, take, and drop *destructively update* the
 underlying sequence -- it feels so natural to do that once you've
 encapsulated the underlying sequence of cards in a class.  If you want to
 serialize a deck, that's more code to write (although general pickling of
 a Scala object is an *active area of research*).

 This example pretty much sums up what I prefer about Clojure.  I like to
 tell people that a big part of what makes Clojure special is its philosophy
 of *lightweight data modeling*.  It leads to delightfully simple
 systems.  Scala remains deeply rooted in the OO philosophy, which all too
 often leads to an over-engineered muddle.

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

Re: Is Clojure more functional then Scala?

[Mark Engelberg]

On Mon, Dec 16, 2013 at 12:30 PM, Guru Devanla grd...@gmail.com wrote:

 Hi Mark,

 A few questions:

 1. The point you raise regarding declaring case classes is inherent to the
 typed nature of Scala, correct? Can that be pointed to as valid strength of
 Clojure. Since, we are comparing static vs dynamic typing here.


Well, in Scala, if you wanted to simulate keywords (albeit less
efficiently) you could just declare the type of something to be String.
But you wouldn't do that because the culture is to enumerate all the
possibilities.  Yes, that culture comes from the fact that Scala's
community believes in the value of static typing and being as precise as
possible about the type of a value.  But Scala's static typing doesn't
inherently prevent you from doing a more general solution.  That's why I
described it as a philosophy, rather than something intrinsic to static vs
dynamic typing.



 2. I am not super familiar with Scale, but I am assuming Scala can do
 similar to what we have in ML, which would look like this:

 datatype rank = Jack | Queen | King | Ace | Num of int

 Isn't a similar idiomatic case class sufficient to achieve the needed
 simplicity in Scala?


Yes, although it is more verbose in Scala.  I would argue that as we
program, hundreds of times every day we make little design choices, and we
are subtly influenced by our programming language, generally making the
choice that is easiest in the language we are using.  I think many
programmers, without even thinking about it, would choose
Integer
over
Scala's more verbose equivalent to datatype rank = Jack | Queen | King |
Ace | Num of int
Keep in mind that the type definition isn't the only place you incur extra
complexity: every time you ever process a rank anywhere in your code, the
datatype version will need to be unpacked using a match mechanism to
ensure you've handled all the cases and only those cases.




 3. Regarding walking down the path of multiple object hierarchies, I guess
 that is only a choice in Scala and is not necessitated by idiomatic Scala.
 So, can't one just use the functional construct to achieve what you define
 in Clojure?


Yes.  Again, the ideas of pinning down your types precisely and
encapsulating data is more of a cultural/philosophical issue, driven by the
static typing and object-oriented paradigms which Scala fully embraces.
You can code Scala in other ways, but if you were the kind of person who
didn't like those things, you probably wouldn't be using Scala.



 I believe Scala's blending of static typing with OO and FP principles is a
 exciting area of research and only time will tell if we could have all the
 features in one big language.  Scala's tries to be different language to
 different people depending on which background one approaches from.


I admire Scala, I just don't enjoy programming in it as much as I had hoped.

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

Is Clojure more functional then Scala?

[John Kida]

I jumped on the FP bandwagon over a year ago and have been using Scala both 
at work and for personal interest. Recently however I decided to take a 
closer look at Clojure and see if it is something i actually like. I have 
to admit at first the syntax form was awkward, but im starting to really 
see the simplicity behind it.

I have heard many people claim that Clojure sets you up and supports you 
for FP more so then Scala does. However they never provide any examples of 
something Clojure does that is more supporting of FP then the way idiomatic 
Scala does it.

Here are some things that I have heard people say when comparing Clojure vs 
Scala in reference to FP
Clojure has immutable persistance data structures. but so does Scala
Scala also tries to get you to use its immutable collections, like Vectors, 
and are also persistent data structures. However they are not as uniform as 
Clojures Seq i agree with that.

Also Scala recommends using vals and not vars, which gives you immutable 
references points

I am certainly learning towards dropping Scala for a bit and giving Clojure 
a real shot. The reason i even picked up Scala was because i wanted to 
learn more about FP, and if there is a better tool for both doing and 
learning FP then i want it.

So tell me, if you have used both Scala and Clojure, do you have some real 
examples of some things where Clojure really does support you better when 
doing FP, where Scala really leads you no way, or worse the imperative way?


-- 
-- 
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 more functional then Scala?

[Robin Heggelund Hansen]

The reason Clojure supports you better is that Clojure doesn't really 
give you an alternative. Scala is BOTH OO and FP, Clojure is only FP.

The problem with Scala is that if you come from an OO language, Scala 
doesn't force you to use FP concepts, sure it's idiomatic, but there is 
nothing that forces you to write things in a functional way. Clojure forces 
you to do that, cause you don't really have an alternative. Because of 
that, you'll probably get better at FP faster with Clojure than with Scala. 
I write probably, because if someone really wants too, they'll learn FP 
regardless.

kl. 04:33:35 UTC+1 mandag 16. desember 2013 skrev John Kida følgende:

 I jumped on the FP bandwagon over a year ago and have been using Scala 
 both at work and for personal interest. Recently however I decided to take 
 a closer look at Clojure and see if it is something i actually like. I have 
 to admit at first the syntax form was awkward, but im starting to really 
 see the simplicity behind it.

 I have heard many people claim that Clojure sets you up and supports you 
 for FP more so then Scala does. However they never provide any examples of 
 something Clojure does that is more supporting of FP then the way idiomatic 
 Scala does it.

 Here are some things that I have heard people say when comparing Clojure 
 vs Scala in reference to FP
 Clojure has immutable persistance data structures. but so does Scala
 Scala also tries to get you to use its immutable collections, like 
 Vectors, and are also persistent data structures. However they are not as 
 uniform as Clojures Seq i agree with that.

 Also Scala recommends using vals and not vars, which gives you immutable 
 references points

 I am certainly learning towards dropping Scala for a bit and giving 
 Clojure a real shot. The reason i even picked up Scala was because i wanted 
 to learn more about FP, and if there is a better tool for both doing and 
 learning FP then i want it.

 So tell me, if you have used both Scala and Clojure, do you have some real 
 examples of some things where Clojure really does support you better when 
 doing FP, where Scala really leads you no way, or worse the imperative way?




-- 
-- 
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: Scala interop (or, aliasing imported Java classes)

[Marshall Bockrath-Vandegrift]

Mark mjt0...@gmail.com writes:

 I think my preferred solution would be to allow imported Java classes
 to be aliased, so I could do this:

 (import '(org.fooinstitute.team.library.foo package :as foop))
 = org.fooinstitute.team.library.foo.package
 (foop/isFoo foop)
 = false

 But to the best of my knowledge (and searching), that doesn't exist in
 Clojure.

Clojure doesn’t provide it as a part of the `ns` or `import` forms, but
the underlying `Namespace` objects support it just fine, and then almost
everything works as you’d expect w/ the arbitrary alias:

user (.importClass *ns* 'Q java.util.concurrent.LinkedBlockingQueue)
java.util.concurrent.LinkedBlockingQueue
user Q
java.util.concurrent.LinkedBlockingQueue
user (Q.)
#LinkedBlockingQueue []
user (fn [q x] (.offer q x))
Reflection warning, /tmp/form-init7252328014986537096.clj:1:11 - call to 
offer can't be resolved.
#user$eval1302$fn__1303 user$eval1302$fn__1303@ece88d2
user (fn [q x] (.offer ^Q q x))
#user$eval1308$fn__1309 user$eval1308$fn__1309@251c4123

HTH,

-Marshall

-- 
-- 
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: Scala interop (or, aliasing imported Java classes)

[Sean Corfield]

Perhaps a small extension to (import ..) is warranted then, since the
underlying machinery seems to support aliases?

(import [the.java.package {Clazz1 Alias1 Clazz2 Alias2} Clazz3])

or, maybe more in keeping with require:

(import [the.java.package Clazz1 Clazz2 Clazz3 :rename {Clazz1
Alias1 Clazz2 Alias2}])

Sean

On Sun, Nov 3, 2013 at 4:38 AM, Marshall Bockrath-Vandegrift
llas...@gmail.com wrote:
 Mark mjt0...@gmail.com writes:

 I think my preferred solution would be to allow imported Java classes
 to be aliased, so I could do this:

 (import '(org.fooinstitute.team.library.foo package :as foop))
 = org.fooinstitute.team.library.foo.package
 (foop/isFoo foop)
 = false

 But to the best of my knowledge (and searching), that doesn't exist in
 Clojure.

 Clojure doesn’t provide it as a part of the `ns` or `import` forms, but
 the underlying `Namespace` objects support it just fine, and then almost
 everything works as you’d expect w/ the arbitrary alias:

 user (.importClass *ns* 'Q java.util.concurrent.LinkedBlockingQueue)
 java.util.concurrent.LinkedBlockingQueue
 user Q
 java.util.concurrent.LinkedBlockingQueue
 user (Q.)
 #LinkedBlockingQueue []
 user (fn [q x] (.offer q x))
 Reflection warning, /tmp/form-init7252328014986537096.clj:1:11 - call to 
 offer can't be resolved.
 #user$eval1302$fn__1303 user$eval1302$fn__1303@ece88d2
 user (fn [q x] (.offer ^Q q x))
 #user$eval1308$fn__1309 user$eval1308$fn__1309@251c4123

 HTH,

 -Marshall

 --
 --
 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: Scala interop (or, aliasing imported Java classes)

[Sean Corfield]

That would need quoting wouldn't it?

(import '(the.java.package {Clazz1 Alias1 Clazz2 Alias2} Clazz3))

or:

(import '(the.java.package Clazz1 Clazz2 Clazz3 :rename {Clazz1
Alias1 Clazz2 Alias2}))

On Sun, Nov 3, 2013 at 11:22 AM, Sean Corfield seancorfi...@gmail.com wrote:
 Perhaps a small extension to (import ..) is warranted then, since the
 underlying machinery seems to support aliases?

 (import [the.java.package {Clazz1 Alias1 Clazz2 Alias2} Clazz3])

 or, maybe more in keeping with require:

 (import [the.java.package Clazz1 Clazz2 Clazz3 :rename {Clazz1
 Alias1 Clazz2 Alias2}])

 Sean

 On Sun, Nov 3, 2013 at 4:38 AM, Marshall Bockrath-Vandegrift
 llas...@gmail.com wrote:
 Mark mjt0...@gmail.com writes:

 I think my preferred solution would be to allow imported Java classes
 to be aliased, so I could do this:

 (import '(org.fooinstitute.team.library.foo package :as foop))
 = org.fooinstitute.team.library.foo.package
 (foop/isFoo foop)
 = false

 But to the best of my knowledge (and searching), that doesn't exist in
 Clojure.

 Clojure doesn’t provide it as a part of the `ns` or `import` forms, but
 the underlying `Namespace` objects support it just fine, and then almost
 everything works as you’d expect w/ the arbitrary alias:

 user (.importClass *ns* 'Q java.util.concurrent.LinkedBlockingQueue)
 java.util.concurrent.LinkedBlockingQueue
 user Q
 java.util.concurrent.LinkedBlockingQueue
 user (Q.)
 #LinkedBlockingQueue []
 user (fn [q x] (.offer q x))
 Reflection warning, /tmp/form-init7252328014986537096.clj:1:11 - call to 
 offer can't be resolved.
 #user$eval1302$fn__1303 user$eval1302$fn__1303@ece88d2
 user (fn [q x] (.offer ^Q q x))
 #user$eval1308$fn__1309 user$eval1308$fn__1309@251c4123

 HTH,

 -Marshall

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



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

Scala interop (or, aliasing imported Java classes)

[Mark]

At work, we're primarily a Scala shop, but I've been writing some small 
Clojure utilities to handle quick tasks here and there (stuff I'd written 
in Python previously). I was hoping to make use of some of the Scala 
libraries we'd already written, but I ran into an Java/Scala interop 
problem that I couldn't solve cleanly.

The problem is with Scala's package objects. If you're not familiar with 
them, it's how Scala organizes top-level functions (ie, functions that do 
not belong to an object or class). It looks like Scala compiles package 
objects down to an object called package. They are lexically 
distinguished from one another by the packages to which they belong.

At the REPL, I was able to import one and call a method from it by doing:

 (import '(org.fooinstitute.team.libary.foo package))
= org.fooinstitute.team.library.foo.package
 (package/isFoo foo)
= true

However, if I needed to use code from multiple Scala package objects, I 
couldn't import them all individually, because there would be a name 
conflict, and the last one imported would presumably shadow all the others.

Alternatively, I could use the fully-qualified name for the package 
objects, like so:

 (org.fooinstitute.team.library.foo.package/isFoo foo)
= true

But that's kind of verbose. The only other solution I can think of is to 
write thin wrappers around the package objects I'd like to use, but as I 
understand it, the general Clojure philosophy eschews that practice, since 
Java interop should be fairly seamless (and is in just about every other 
case I've encountered so far).

I think my preferred solution would be to allow imported Java classes to be 
aliased, so I could do this:

 (import '(org.fooinstitute.team.library.foo package :as foop))
= org.fooinstitute.team.library.foo.package
 (foop/isFoo foop)
= false

But to the best of my knowledge (and searching), that doesn't exist in 
Clojure.

Has anyone encountered this and found a satisfying solution?

Thanks,
Mark

-- 
-- 
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: Scala interop (or, aliasing imported Java classes)

[Cedric Greevey]

I vote for adding :as to import. I've personally thought of other
situations where this could be useful.

Being able to alias a (Java) package might be useful too:

(import '((java.util.concurrent :as juc) LinkedBlockingQueue ReadWriteLock))

(def my-queue (juc/LinkedBlockingQueue.))

Most useful with conflicting class names, e.g. java.util.Date and
javax.sql.Date:

UDate vs. SDate

u/Date vs. s/Date

etc.



On Fri, Nov 1, 2013 at 4:40 PM, Mark mjt0...@gmail.com wrote:

 At work, we're primarily a Scala shop, but I've been writing some small
 Clojure utilities to handle quick tasks here and there (stuff I'd written
 in Python previously). I was hoping to make use of some of the Scala
 libraries we'd already written, but I ran into an Java/Scala interop
 problem that I couldn't solve cleanly.

 The problem is with Scala's package objects. If you're not familiar with
 them, it's how Scala organizes top-level functions (ie, functions that do
 not belong to an object or class). It looks like Scala compiles package
 objects down to an object called package. They are lexically
 distinguished from one another by the packages to which they belong.

 At the REPL, I was able to import one and call a method from it by doing:

  (import '(org.fooinstitute.team.libary.foo package))
 = org.fooinstitute.team.library.foo.package
  (package/isFoo foo)
 = true

 However, if I needed to use code from multiple Scala package objects, I
 couldn't import them all individually, because there would be a name
 conflict, and the last one imported would presumably shadow all the others.

 Alternatively, I could use the fully-qualified name for the package
 objects, like so:

  (org.fooinstitute.team.library.foo.package/isFoo foo)
 = true

 But that's kind of verbose. The only other solution I can think of is to
 write thin wrappers around the package objects I'd like to use, but as I
 understand it, the general Clojure philosophy eschews that practice, since
 Java interop should be fairly seamless (and is in just about every other
 case I've encountered so far).

 I think my preferred solution would be to allow imported Java classes to
 be aliased, so I could do this:

  (import '(org.fooinstitute.team.library.foo package :as foop))
 = org.fooinstitute.team.library.foo.package
  (foop/isFoo foop)
 = false

 But to the best of my knowledge (and searching), that doesn't exist in
 Clojure.

 Has anyone encountered this and found a satisfying solution?

 Thanks,
 Mark

 --
 --
 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: Scala interop (or, aliasing imported Java classes)

[Plínio Balduino]

+1


On Fri, Nov 1, 2013 at 6:49 PM, Cedric Greevey cgree...@gmail.com wrote:

 I vote for adding :as to import. I've personally thought of other
 situations where this could be useful.

 Being able to alias a (Java) package might be useful too:

 (import '((java.util.concurrent :as juc) LinkedBlockingQueue
 ReadWriteLock))

 (def my-queue (juc/LinkedBlockingQueue.))

 Most useful with conflicting class names, e.g. java.util.Date and
 javax.sql.Date:

 UDate vs. SDate

 u/Date vs. s/Date

 etc.



 On Fri, Nov 1, 2013 at 4:40 PM, Mark mjt0...@gmail.com wrote:

 At work, we're primarily a Scala shop, but I've been writing some small
 Clojure utilities to handle quick tasks here and there (stuff I'd written
 in Python previously). I was hoping to make use of some of the Scala
 libraries we'd already written, but I ran into an Java/Scala interop
 problem that I couldn't solve cleanly.

 The problem is with Scala's package objects. If you're not familiar with
 them, it's how Scala organizes top-level functions (ie, functions that do
 not belong to an object or class). It looks like Scala compiles package
 objects down to an object called package. They are lexically
 distinguished from one another by the packages to which they belong.

 At the REPL, I was able to import one and call a method from it by doing:

  (import '(org.fooinstitute.team.libary.foo package))
 = org.fooinstitute.team.library.foo.package
  (package/isFoo foo)
 = true

 However, if I needed to use code from multiple Scala package objects, I
 couldn't import them all individually, because there would be a name
 conflict, and the last one imported would presumably shadow all the others.

 Alternatively, I could use the fully-qualified name for the package
 objects, like so:

  (org.fooinstitute.team.library.foo.package/isFoo foo)
 = true

 But that's kind of verbose. The only other solution I can think of is to
 write thin wrappers around the package objects I'd like to use, but as I
 understand it, the general Clojure philosophy eschews that practice, since
 Java interop should be fairly seamless (and is in just about every other
 case I've encountered so far).

 I think my preferred solution would be to allow imported Java classes to
 be aliased, so I could do this:

  (import '(org.fooinstitute.team.library.foo package :as foop))
 = org.fooinstitute.team.library.foo.package
  (foop/isFoo foop)
 = false

 But to the best of my knowledge (and searching), that doesn't exist in
 Clojure.

 Has anyone encountered this and found a satisfying solution?

 Thanks,
 Mark

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


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


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

Re: Scala interop (or, aliasing imported Java classes)

[Michael Blume]

I ran into this problem using inner-class enums and wound up writing a 
macro to generate aliases for me. You could do something similar:

(defmacro def-class-alias
  Make name reference class

   (def-class-alias class-name foo.bar.baz.SomeClass)

   (class-name foo) - foo.bar.baz.SomeClass/foo
   ((class-name bar) arg1 arg2) - (foo.bar.baz.SomeClass/bar arg1 arg2)

  [name class]
  `(defmacro ~name
 ~(str automatically generated alias for class 
   class)
 [member#]
 (symbol (str (quote ~class) / member#


On Friday, November 1, 2013 1:40:41 PM UTC-7, Mark wrote:

 At work, we're primarily a Scala shop, but I've been writing some small 
 Clojure utilities to handle quick tasks here and there (stuff I'd written 
 in Python previously). I was hoping to make use of some of the Scala 
 libraries we'd already written, but I ran into an Java/Scala interop 
 problem that I couldn't solve cleanly.

 The problem is with Scala's package objects. If you're not familiar with 
 them, it's how Scala organizes top-level functions (ie, functions that do 
 not belong to an object or class). It looks like Scala compiles package 
 objects down to an object called package. They are lexically 
 distinguished from one another by the packages to which they belong.

 At the REPL, I was able to import one and call a method from it by doing:

  (import '(org.fooinstitute.team.libary.foo package))
 = org.fooinstitute.team.library.foo.package
  (package/isFoo foo)
 = true

 However, if I needed to use code from multiple Scala package objects, I 
 couldn't import them all individually, because there would be a name 
 conflict, and the last one imported would presumably shadow all the others.

 Alternatively, I could use the fully-qualified name for the package 
 objects, like so:

  (org.fooinstitute.team.library.foo.package/isFoo foo)
 = true

 But that's kind of verbose. The only other solution I can think of is to 
 write thin wrappers around the package objects I'd like to use, but as I 
 understand it, the general Clojure philosophy eschews that practice, since 
 Java interop should be fairly seamless (and is in just about every other 
 case I've encountered so far).

 I think my preferred solution would be to allow imported Java classes to 
 be aliased, so I could do this:

  (import '(org.fooinstitute.team.library.foo package :as foop))
 = org.fooinstitute.team.library.foo.package
  (foop/isFoo foop)
 = false

 But to the best of my knowledge (and searching), that doesn't exist in 
 Clojure.

 Has anyone encountered this and found a satisfying solution?

 Thanks,
 Mark


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

fast numerics in Scala...

[Jim]

I enjoyed watching this so I thought I'd share...

http://www.infoq.com/presentations/Scala-Spire


Jim


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

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Clojure vs Scala - anecdote

[cig]

Impressive, wonder if they were running this on a single node or more
widespread?
In a wide spread environment I think Erlang would be the true winner,
though it does not natively have macros :-(
There is an implementation of Lisp for Erlang called LFE (lisp
flavored Erlang) which I looked at, which does have macros and a real
engine underneath.
But clojure is an awesome combination

On Sep 7, 7:32 am, Sean Corfield seancorfi...@gmail.com wrote:
 I just wanted to share this experience from World Singles...

 Back in November 2009, we started developing with Scala. We needed a
 long-running process that published large volumes of changes from our
 member database as XML packets published to a custom search engine.
 The mapping from half a dozen tables in the database to a flat XML
 schema was pretty complex and the company had tried a number of
 solutions with mixed success in the past. I introduced Scala based on
 the promises of performance, concurrency and type safety - and
 conciseness (especially with XML being a native data type in Scala).

 We've been running the Scala publishing daemons in production for most
 of two years. Generally they work pretty well but, under stress, they
 tend to hit Out of Memory exceptions and, after a lot of poking
 around, we became fairly convinced it was due (at least in part) to
 the default actor implementation in Scala. Scala is going to fold in
 Akka soon and we had been considering migrating to Akka anyone...

 But having introduced Clojure this year (after experimenting with it
 since about May last year), we figured we'd have a short spike to
 create a Clojure version of the Scala code to see how it worked out.

 It took about 15 hours to recreate the publishing daemon in Clojure
 and get it to pass all our tests. Today we ran a soak test
 publishing nearly 300,000 profiles in one run. The Scala code would
 fail with OoM exceptions if we hit it with 50,000 profiles in one run
 (sometimes less). The Clojure code sailed thru and is still happily
 running - so we'll be replacing the Scala code during our next
 production build.

 The other aspect that's interesting is that the Scala code totaled
 about 1,000 lines (about 31k characters of code). The Clojure
 replacement is just under 260 lines (around 11.5k characters of code).
 Neither code base has much in the way of comments (*ahem* - I'm not
 proud of that, just pointing out that there's no noise offsetting
 the code comparison). That doesn't include unit tests either, it's
 just the raw production code. The form of the Clojure code mostly
 follows the form of the Scala code, most of the same functions - it
 was very functional Scala - with some refactoring to helper functions
 to make it more modular and more maintainable.

 The net result is (obviously) that we'll be taking the Clojure
 publishing daemon to production and we'll be dropping Scala
 completely.

 Kudos to Rich Hickey and the Clojure/core team for creating a great
 general purpose language that can solve big problems - thank you!
 --
 Sean A Corfield -- (904) 302-SEAN
 An Architect's View --http://corfield.org/
 World Singles, LLC. --http://worldsingles.com/
 Railo Technologies, Inc. --http://www.getrailo.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

Re: Clojure vs Scala - anecdote

[Sean Corfield]

On Wed, Sep 14, 2011 at 11:15 PM, cig clifford.goldb...@gmail.com wrote:
 Impressive, wonder if they were running this on a single node or more
 widespread?

We run an instance of the process on multiple nodes, configured
slightly differently. We needed some parallelization to improve
throughput but didn't need a massive net of processes. And we needed
JVM interop so Erlang is out (and Erjang isn't yet mature enough - at
least, not last time I looked).

 But clojure is an awesome combination

Indeed.
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.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

Re: Clojure vs Scala - anecdote

[Edward Garson]

Native Erlang does have a macro facility, but it is not as powerful as
Lisp/Clojure's.

On Sep 15, 2:15 am, cig clifford.goldb...@gmail.com wrote:
[snip]
 In a wide spread environment I think Erlang would be the true winner,
 though it does not natively have macros :-(
[snip]

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

Re: Clojure vs Scala - anecdote

[Raoul Duke]

On Thu, Sep 15, 2011 at 9:24 AM, Edward Garson egar...@gmail.com wrote:
 Native Erlang does have a macro facility, but it is not as powerful as
 Lisp/Clojure's.

lfe, baby, though of course that is not native erlang.

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

Re: Clojure vs Scala - anecdote

[Tal Liron]

On Tuesday, September 13, 2011 1:44:09 PM UTC-5, Sean Corfield wrote:

 It was intended to be purely anecdotal but that doesn't seem to satisfy 
 anyone! :)

Homer: You know, when I was a boy, I really wanted a catcher's mitt, but my 
dad wouldn't get it for me. So I held my breath until I passed out and 
banged my head on the coffee table. The doctor thought I might have brain 
damage.
Bart: Dad, what's the point of this story?
Homer: I like stories.

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

Re: Clojure vs Scala - anecdote

[Nathan Sorenson]

I adore Clojure as well, but could this success not be partially due
to the reimplementing for the second time phenomenon? i.e. if you re-
wrote the entire thing in Scala again, perhaps you would see similar
gains in brevity etc?

On Sep 6, 10:32 pm, Sean Corfield seancorfi...@gmail.com wrote:
 I just wanted to share this experience from World Singles...

 Back in November 2009, we started developing with Scala. We needed a
 long-running process that published large volumes of changes from our
 member database as XML packets published to a custom search engine.
 The mapping from half a dozen tables in the database to a flat XML
 schema was pretty complex and the company had tried a number of
 solutions with mixed success in the past. I introduced Scala based on
 the promises of performance, concurrency and type safety - and
 conciseness (especially with XML being a native data type in Scala).

 We've been running the Scala publishing daemons in production for most
 of two years. Generally they work pretty well but, under stress, they
 tend to hit Out of Memory exceptions and, after a lot of poking
 around, we became fairly convinced it was due (at least in part) to
 the default actor implementation in Scala. Scala is going to fold in
 Akka soon and we had been considering migrating to Akka anyone...

 But having introduced Clojure this year (after experimenting with it
 since about May last year), we figured we'd have a short spike to
 create a Clojure version of the Scala code to see how it worked out.

 It took about 15 hours to recreate the publishing daemon in Clojure
 and get it to pass all our tests. Today we ran a soak test
 publishing nearly 300,000 profiles in one run. The Scala code would
 fail with OoM exceptions if we hit it with 50,000 profiles in one run
 (sometimes less). The Clojure code sailed thru and is still happily
 running - so we'll be replacing the Scala code during our next
 production build.

 The other aspect that's interesting is that the Scala code totaled
 about 1,000 lines (about 31k characters of code). The Clojure
 replacement is just under 260 lines (around 11.5k characters of code).
 Neither code base has much in the way of comments (*ahem* - I'm not
 proud of that, just pointing out that there's no noise offsetting
 the code comparison). That doesn't include unit tests either, it's
 just the raw production code. The form of the Clojure code mostly
 follows the form of the Scala code, most of the same functions - it
 was very functional Scala - with some refactoring to helper functions
 to make it more modular and more maintainable.

 The net result is (obviously) that we'll be taking the Clojure
 publishing daemon to production and we'll be dropping Scala
 completely.

 Kudos to Rich Hickey and the Clojure/core team for creating a great
 general purpose language that can solve big problems - thank you!
 --
 Sean A Corfield -- (904) 302-SEAN
 An Architect's View --http://corfield.org/
 World Singles, LLC. --http://worldsingles.com/
 Railo Technologies, Inc. --http://www.getrailo.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

Re: Clojure vs Scala - anecdote

[Laurent PETIT]

Isn't it Brooks who said you will throw it away at least 3 times, or
something like this ? :)

2011/9/13 Nathan Sorenson n...@sfu.ca

 I adore Clojure as well, but could this success not be partially due
 to the reimplementing for the second time phenomenon? i.e. if you re-
 wrote the entire thing in Scala again, perhaps you would see similar
 gains in brevity etc?

 On Sep 6, 10:32 pm, Sean Corfield seancorfi...@gmail.com wrote:
  I just wanted to share this experience from World Singles...
 
  Back in November 2009, we started developing with Scala. We needed a
  long-running process that published large volumes of changes from our
  member database as XML packets published to a custom search engine.
  The mapping from half a dozen tables in the database to a flat XML
  schema was pretty complex and the company had tried a number of
  solutions with mixed success in the past. I introduced Scala based on
  the promises of performance, concurrency and type safety - and
  conciseness (especially with XML being a native data type in Scala).
 
  We've been running the Scala publishing daemons in production for most
  of two years. Generally they work pretty well but, under stress, they
  tend to hit Out of Memory exceptions and, after a lot of poking
  around, we became fairly convinced it was due (at least in part) to
  the default actor implementation in Scala. Scala is going to fold in
  Akka soon and we had been considering migrating to Akka anyone...
 
  But having introduced Clojure this year (after experimenting with it
  since about May last year), we figured we'd have a short spike to
  create a Clojure version of the Scala code to see how it worked out.
 
  It took about 15 hours to recreate the publishing daemon in Clojure
  and get it to pass all our tests. Today we ran a soak test
  publishing nearly 300,000 profiles in one run. The Scala code would
  fail with OoM exceptions if we hit it with 50,000 profiles in one run
  (sometimes less). The Clojure code sailed thru and is still happily
  running - so we'll be replacing the Scala code during our next
  production build.
 
  The other aspect that's interesting is that the Scala code totaled
  about 1,000 lines (about 31k characters of code). The Clojure
  replacement is just under 260 lines (around 11.5k characters of code).
  Neither code base has much in the way of comments (*ahem* - I'm not
  proud of that, just pointing out that there's no noise offsetting
  the code comparison). That doesn't include unit tests either, it's
  just the raw production code. The form of the Clojure code mostly
  follows the form of the Scala code, most of the same functions - it
  was very functional Scala - with some refactoring to helper functions
  to make it more modular and more maintainable.
 
  The net result is (obviously) that we'll be taking the Clojure
  publishing daemon to production and we'll be dropping Scala
  completely.
 
  Kudos to Rich Hickey and the Clojure/core team for creating a great
  general purpose language that can solve big problems - thank you!
  --
  Sean A Corfield -- (904) 302-SEAN
  An Architect's View --http://corfield.org/
  World Singles, LLC. --http://worldsingles.com/
  Railo Technologies, Inc. --http://www.getrailo.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 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

Re: Clojure vs Scala - anecdote

[Meikel Brandmeyer]

“Plan to throw one away.”

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

Re: Clojure vs Scala - anecdote

[Sean Corfield]

On Tue, Sep 13, 2011 at 9:48 AM, Nathan Sorenson n...@sfu.ca wrote:
 I adore Clojure as well, but could this success not be partially due
 to the reimplementing for the second time phenomenon? i.e. if you re-
 wrote the entire thing in Scala again, perhaps you would see similar
 gains in brevity etc?

Well, the Scala world has moved on quite a bit since 2009 so I could
certainly make it somewhat more concise (I'd use the parallel
collections in 2.9 instead of actors and I hope there's a better SQL
abstraction by now so I could drop the ResultSet collection wrapper I
wrote). I doubt I could reduce it by a factor of three which is what
it would take to get close to the Clojure code.

I don't know who posted it on HN but I see it's also on DZone and so
it's generated a lot of noise out there and now I'm probably going to
do a more detailed comparison and analysis to post on my blog, to
answer some of the critical voices on HN... It was intended to be
purely anecdotal but that doesn't seem to satisfy anyone! :)
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.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

Re: Clojure vs Scala - anecdote

[Laurent PETIT]

Oh, it was just one, after all ?

Please, don't tell this to my boss :-D

2011/9/13 Meikel Brandmeyer m...@kotka.de

 “Plan to throw one away.”

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

Re: Clojure vs Scala - anecdote

[Luc Prefontaine]

Hi,

We have been running Clojure daemons 24/7 in prod. since Jan. 2009.
We also considered Scala back in 2008.

We could not agree more with your conclusions :)

Luc P.

On Tue, 6 Sep 2011 22:32:47 -0700
Sean Corfield seancorfi...@gmail.com wrote:

 I just wanted to share this experience from World Singles...
 
 Back in November 2009, we started developing with Scala. We needed a
 long-running process that published large volumes of changes from our
 member database as XML packets published to a custom search engine.
 The mapping from half a dozen tables in the database to a flat XML
 schema was pretty complex and the company had tried a number of
 solutions with mixed success in the past. I introduced Scala based on
 the promises of performance, concurrency and type safety - and
 conciseness (especially with XML being a native data type in Scala).
 
 We've been running the Scala publishing daemons in production for most
 of two years. Generally they work pretty well but, under stress, they
 tend to hit Out of Memory exceptions and, after a lot of poking
 around, we became fairly convinced it was due (at least in part) to
 the default actor implementation in Scala. Scala is going to fold in
 Akka soon and we had been considering migrating to Akka anyone...
 
 But having introduced Clojure this year (after experimenting with it
 since about May last year), we figured we'd have a short spike to
 create a Clojure version of the Scala code to see how it worked out.
 
 It took about 15 hours to recreate the publishing daemon in Clojure
 and get it to pass all our tests. Today we ran a soak test
 publishing nearly 300,000 profiles in one run. The Scala code would
 fail with OoM exceptions if we hit it with 50,000 profiles in one run
 (sometimes less). The Clojure code sailed thru and is still happily
 running - so we'll be replacing the Scala code during our next
 production build.
 
 The other aspect that's interesting is that the Scala code totaled
 about 1,000 lines (about 31k characters of code). The Clojure
 replacement is just under 260 lines (around 11.5k characters of code).
 Neither code base has much in the way of comments (*ahem* - I'm not
 proud of that, just pointing out that there's no noise offsetting
 the code comparison). That doesn't include unit tests either, it's
 just the raw production code. The form of the Clojure code mostly
 follows the form of the Scala code, most of the same functions - it
 was very functional Scala - with some refactoring to helper functions
 to make it more modular and more maintainable.
 
 The net result is (obviously) that we'll be taking the Clojure
 publishing daemon to production and we'll be dropping Scala
 completely.
 
 Kudos to Rich Hickey and the Clojure/core team for creating a great
 general purpose language that can solve big problems - thank you!



-- 
Luc P.


The rabid Muppet

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

Re: Deamons in Clojure (was Re: Clojure vs Scala - anecdote)

[Bronsa]

the lein-daemon plugin seems to do that
Il giorno 07/set/2011 16.27, Marko Kocić marko.ko...@gmail.com ha
scritto:
 While we are at this topic, how do you run Clojure deamons. Do you have
some
 scripts to set it up how?
 Is there a simple way to daemonize lein project?

 Regards,
 Marko

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

Re: Clojure vs Scala - anecdote

[Dennis Haupt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

so the scala actors add much more overhead than the clojure equivalent?

Am 07.09.2011 07:32, schrieb Sean Corfield:
 I just wanted to share this experience from World Singles...
 
 Back in November 2009, we started developing with Scala. We needed
 a long-running process that published large volumes of changes from
 our member database as XML packets published to a custom search
 engine. The mapping from half a dozen tables in the database to a
 flat XML schema was pretty complex and the company had tried a
 number of solutions with mixed success in the past. I introduced
 Scala based on the promises of performance, concurrency and type
 safety - and conciseness (especially with XML being a native data
 type in Scala).
 
 We've been running the Scala publishing daemons in production for
 most of two years. Generally they work pretty well but, under
 stress, they tend to hit Out of Memory exceptions and, after a lot
 of poking around, we became fairly convinced it was due (at least
 in part) to the default actor implementation in Scala. Scala is
 going to fold in Akka soon and we had been considering migrating to
 Akka anyone...
 
 But having introduced Clojure this year (after experimenting with
 it since about May last year), we figured we'd have a short spike
 to create a Clojure version of the Scala code to see how it worked
 out.
 
 It took about 15 hours to recreate the publishing daemon in
 Clojure and get it to pass all our tests. Today we ran a soak
 test publishing nearly 300,000 profiles in one run. The Scala code
 would fail with OoM exceptions if we hit it with 50,000 profiles in
 one run (sometimes less). The Clojure code sailed thru and is still
 happily running - so we'll be replacing the Scala code during our
 next production build.
 
 The other aspect that's interesting is that the Scala code totaled 
 about 1,000 lines (about 31k characters of code). The Clojure 
 replacement is just under 260 lines (around 11.5k characters of
 code). Neither code base has much in the way of comments (*ahem* -
 I'm not proud of that, just pointing out that there's no noise
 offsetting the code comparison). That doesn't include unit tests
 either, it's just the raw production code. The form of the Clojure
 code mostly follows the form of the Scala code, most of the same
 functions - it was very functional Scala - with some refactoring to
 helper functions to make it more modular and more maintainable.
 
 The net result is (obviously) that we'll be taking the Clojure 
 publishing daemon to production and we'll be dropping Scala 
 completely.
 
 Kudos to Rich Hickey and the Clojure/core team for creating a
 great general purpose language that can solve big problems - thank
 you!


- -- 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOZ6cgAAoJENRtux+h35aGsxoQAKAkmQb/8cxVsHSw1bH6mZjW
Hoea0zi90eO2ds9Wk1wrFjtc0wfPPHdrp0FpZ3w1090BkwyKcRBj/iDM45sP4IY5
grc2I6vaRhfgIIVuaxgUt9HzTCbyjCOxk9xJHpCyY7sIfEIcFwNuzQWVHxgdqG/l
CY/9mDe1Wex3rt2QxCSsUX/+yB5uXaxmAoX5m0jyEAmZzw/46+cVzZ8xMi9Gw1o/
mjI/mvpwTmdGcPkh7DamIEU8QjYbNBosgPWpNktJzmhtUaFdXhEMxdyDhldzUcJZ
J8tZZkTWZoQqPfVdMPgfe1blDtV+nse8X2HDqed+Df42TU1YY+1VJ7e8jfr3vV62
cI+6SAqYTT91UC57GkmYKVOm01vNMpp98+fxaxBHUQi64tv/hIkWG4iHRgBCvncR
hdIKfmzVwcPGrOZu6QT0RrVQzeEbz83+3l4CZQ7KOdL8k5vjd5b1T/LsPrQM1rod
jDAn481tmpZKtSLe8+QbSakxfIFT9oTKUXbtDEEkN2CbJOkE4/EQwuCc/gnlo9Mr
YPlPfx96JLxBfVq6JZ92VSdrpnEBS65HjKhWF587XjGjTqzYbbCNJIekwRdqga8e
zkonzIj+IgnuZznV/fbKZ2yCEnO85TXoj0ZWUDnw0Ffvu2vUFvSF0ykR2BHxZBFD
a1yhe/wr8AGyvIff6Hj8
=N1zz
-END PGP SIGNATURE-

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

Re: Clojure vs Scala - anecdote

[Sean Corfield]

On Wed, Sep 7, 2011 at 10:17 AM, Dennis Haupt d.haup...@googlemail.com wrote:
 so the scala actors add much more overhead than the clojure equivalent?

The main problem is that the current implementation of actors in Scala
suffers from known memory leaks and performance problems - problems
that are completely addressed by Akka, which is why they're going to
incorporate it and replace the current implementation.

Our choices at World Singles were: migrate to Akka, wait for Scala
2.10 (which is when I think Akka will be folded in). Neither were
appealing solutions. Migrating to Clojure was less work and more
timely (for us).
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.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

Re: Deamons in Clojure (was Re: Clojure vs Scala - anecdote)

[Aaron Bedra]

I have used jsvc in the past and found it to be a great tool. It allows you to 
configure which user the application runs as, and does proper detaching. It 
allows you to configure output streams and pid files to your liking. I have 
written some simple init scripts as well to make it very unix service like.  
All in all, I like it a lot more than lein daemon. Lein is a development and 
packaging tool. I wouldn't want it to be a dependency of my production systems.

Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.com

On Sep 7, 2011, at 10:41 AM, Bronsa brobro...@gmail.com wrote:

 the lein-daemon plugin seems to do that
 
 Il giorno 07/set/2011 16.27, Marko Kocić marko.ko...@gmail.com ha scritto:
  While we are at this topic, how do you run Clojure deamons. Do you have 
  some 
  scripts to set it up how?
  Is there a simple way to daemonize lein project?
  
  Regards,
  Marko
  
  -- 
  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 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 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

Re: Deamons in Clojure (was Re: Clojure vs Scala - anecdote)

[Marko Kocić]

Thanks for the tip about jsvc. I'll give it a try. Do you have some script 
examples to share, since having Linux service is exactly what I need?

Thanks,
Marko 

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

Re: Deamons in Clojure (was Re: Clojure vs Scala - anecdote)

[Aaron Bedra]

On 09/07/2011 02:53 PM, Marko Kocić wrote:

Thanks for the tip about jsvc. I'll give it a try. Do you have some script 
examples to share, since having Linux service is exactly what I need?

Thanks,
Marko

I'll try and put together a few things including the code that 
implements the interface to get hooked up to jsvc.


--
Cheers,

Aaron Bedra
--
Clojure/core
http://clojure.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

Re: Deamons in Clojure (was Re: Clojure vs Scala - anecdote)

[Tal Liron]

On Wednesday, September 7, 2011 1:53:43 PM UTC-5, Marko Kocić wrote:

 Thanks for the tip about jsvc. I'll give it a try. Do you have some script 
 examples to share, since having Linux service is exactly what I need?


I strongly recommend Tanuki's wrapper over jsvc:

http://wrapper.tanukisoftware.com/

It's better in every possible way, and will make your deployment life so 
much easier! It's something I would very much like to see as baked into to 
the JVM.

If the GPL licensing is any concern (i.e., you need to distribute your 
product), YAJSW is somewhat Tanuki-compatible and also has an interesting 
architecture:

http://yajsw.sourceforge.net/

-Tal

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

Re: Clojure vs Scala - anecdote

[Ambrose Bonnaire-Sergeant]

Thanks for sharing Sean, very interesting!

Ambrose

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

Intresting project....Ozma: extending Scala with Oz concurrency

[Base]

Found at: http://lambda-the-ultimate.org/node/4300

Scala ported to run on the Mozart VM.

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

Re: HPC in scala ..

[Konrad Hinsen]

On 18 Jan 2011, at 07:37, Tim Daly wrote:


I have just finished
Language Virtualization for Heterogeneous Parallel Computing
http://infoscience.epfl.ch/record/148814/files/paper.pdf


Me too!


Clojure clearly fulfills all of the goals of a virtualization language
because it is a Lisp. Lisp systems are clearly capable of building
a DSL that is fully expressive of all of the power of Lisp. By using
the macro facility the DSL syntax can be matched to the problem
domain.


The authors do mention Lisp, saying that it satisfies most of their  
criteria except for safety, because a DSL implemented through Lisp  
macros always has access to all of Lisp, including the DSL's own  
implementation.


I suppose that for most Lispers, Clojure's namespaces are a sufficient  
answer. Just make a namespace for your DSL where you put all the stuff  
that is part of it. Sure, you can always get at the rest of Clojure by  
importing other namespaces and/or using qualified symbols. But you  
would do that only intentionally, not by accident.


People coming from statically-typed languages typically require more  
law enforcement and would probably not be happy with the namespace  
approach. More protection would require a DSL-specific reader that  
checks for namespace-qualified symbols and disallows arbitrary  
imports. But even that would probably be less work to implement than  
what it takes to make Scala virtualizable.


However, I do believe that Scala has a better chance of being accepted  
as a DSL hosting language for mass-market parallel computing,  
because it has familiar syntax.


So I think that Clojure is an excellent virtualization language for  
DSLs.


I certainly agree with that.

Konrad.

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

Re: HPC in scala ..

[Tim Daly]

On 18 Jan 2011, at 07:37, Tim Daly wrote:


I have just finished
Language Virtualization for Heterogeneous Parallel Computing
http://infoscience.epfl.ch/record/148814/files/paper.pdf


Me too!


Clojure clearly fulfills all of the goals of a virtualization language
because it is a Lisp. Lisp systems are clearly capable of building
a DSL that is fully expressive of all of the power of Lisp. By using
the macro facility the DSL syntax can be matched to the problem
domain.


The authors do mention Lisp, saying that it satisfies most of their 
criteria except for safety, because a DSL implemented through Lisp 
macros always has access to all of Lisp, including the DSL's own 
implementation.


I suppose that for most Lispers, Clojure's namespaces are a sufficient 
answer. Just make a namespace for your DSL where you put all the stuff 
that is part of it. Sure, you can always get at the rest of Clojure by 
importing other namespaces and/or using qualified symbols. But you 
would do that only intentionally, not by accident.

Well you could use scalac and dynamically load the class.
Or, since it is Java, just create a classloader and load anything.
Even a strong type system can be overcome.

Safety, in my interpretation, means not using anything but the
domain-specific language for portability. That won't stop people
from escaping to the VL but that makes their code non-portable.
C, for example, runs everywhere but compiles nowhere due to
the machine-specific hacking.


People coming from statically-typed languages typically require more 
law enforcement and would probably not be happy with the namespace 
approach. More protection would require a DSL-specific reader that 
checks for namespace-qualified symbols and disallows arbitrary 
imports. But even that would probably be less work to implement than 
what it takes to make Scala virtualizable.


However, I do believe that Scala has a better chance of being accepted 
as a DSL hosting language for mass-market parallel computing, 
because it has familiar syntax.

Sigh. I believe you are right.


So I think that Clojure is an excellent virtualization language for 
DSLs.


I certainly agree with that.

Konrad.

The real question is, given that Europe is willing to fund the DSL
approach to popular computing, what can we learn from this
research trend that will influence Clojure?

I do think that the idea of defining problems in terms of a DSL is
certainly an interesting design approach. It might be useful to have
some Clojure examples of such designs so we can ensure that
DSLs are easily created. One really useful example might be to
create Scala in macros :-)

Tim Daly

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

Re: HPC in scala ..

[cej38]

I think the clojure community should be seeking the type of funding to
make it the goto language for HPC.  As a community we definitely have
the brains to make it happen.

While I am not enough of a computer scientist to be able to contribute
to the development, I am willing to help write proposals for funding.



Chad Junkermeier, Ph.D.

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

Re: HPC in scala ..

[Konrad Hinsen]

On 18 Jan, 2011, at 17:37 , cej38 wrote:

 I think the clojure community should be seeking the type of funding to
 make it the goto language for HPC.  As a community we definitely have
 the brains to make it happen.

The brains, yes, but not the academic infrastructure. Scala is based at EPFL, 
and the work on parallel programming is done in collaboration with Stanford. 
That makes all of a difference when applying for funding in the academic world, 
such as the ERC grant that the Scala guys got.

Just out of curiosity: is there anyone else on this list who has an affiliation 
with an academic institution? Perhaps we could get together and see if we can 
apply for an interesting grant for some Clojure-related work.

Konrad.


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

Re: HPC in scala ..

[Konrad Hinsen]

On 18 Jan, 2011, at 15:34 , Tim Daly wrote:

 I suppose that for most Lispers, Clojure's namespaces are a sufficient 
 answer. Just make a namespace for your DSL where you put all the stuff that 
 is part of it. Sure, you can always get at the rest of Clojure by importing 
 other namespaces and/or using qualified symbols. But you would do that only 
 intentionally, not by accident.
 
 Well you could use scalac and dynamically load the class.
 Or, since it is Java, just create a classloader and load anything.

My understanding of the article is that the DSLs are compiled to something that 
may or may not be JVM bytecode (one example compiles to C++) and that the DSL 
code doesn't know that its compiler is written in Scala. A programmer who 
does know may resort to tricks such as you describe, but it is a lot 
straightforward than accessing clojure.core in Clojure.

 Safety, in my interpretation, means not using anything but the
 domain-specific language for portability. That won't stop people

Personally I fully agree. I just wonder if everyone else does.

 I do think that the idea of defining problems in terms of a DSL is
 certainly an interesting design approach. It might be useful to have
 some Clojure examples of such designs so we can ensure that
 DSLs are easily created. One really useful example might be to
 create Scala in macros :-)

I'd go for Fortran ;-)

Konrad.


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

Re: HPC in scala ..

[Tim Daly]

On 18 Jan, 2011, at 17:37 , cej38 wrote:


I think the clojure community should be seeking the type of funding to
make it the goto language for HPC.  As a community we definitely have
the brains to make it happen.

The brains, yes, but not the academic infrastructure. Scala is based at EPFL, 
and the work on parallel programming is done in collaboration with Stanford. 
That makes all of a difference when applying for funding in the academic world, 
such as the ERC grant that the Scala guys got.

Just out of curiosity: is there anyone else on this list who has an affiliation 
with an academic institution? Perhaps we could get together and see if we can 
apply for an interesting grant for some Clojure-related work.

Konrad.



In theory I am affiliated with Carnegie-Mellon University.

Tim Daly

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

Re: HPC in scala ..

[cej38]

I am currently at the Naval Research Laboratory, Washington DC.

Chad



On Jan 18, 11:59 am, Konrad Hinsen konrad.hin...@fastmail.net wrote:
 On 18 Jan, 2011, at 17:37 , cej38 wrote:

  I think the clojure community should be seeking the type of funding to
  make it the goto language for HPC.  As a community we definitely have
  the brains to make it happen.

 The brains, yes, but not the academic infrastructure. Scala is based at EPFL, 
 and the work on parallel programming is done in collaboration with Stanford. 
 That makes all of a difference when applying for funding in the academic 
 world, such as the ERC grant that the Scala guys got.

 Just out of curiosity: is there anyone else on this list who has an 
 affiliation with an academic institution? Perhaps we could get together and 
 see if we can apply for an interesting grant for some Clojure-related work.

 Konrad.

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

Re: HPC in scala ..

[Tim Daly]

On 18 Jan, 2011, at 17:37 , cej38 wrote:


I think the clojure community should be seeking the type of funding to
make it the goto language for HPC.  As a community we definitely have
the brains to make it happen.
The brains, yes, but not the academic infrastructure. Scala is based 
at EPFL, and the work on parallel programming is done in 
collaboration with Stanford. That makes all of a difference when 
applying for funding in the academic world, such as the ERC grant 
that the Scala guys got.


Just out of curiosity: is there anyone else on this list who has an 
affiliation with an academic institution? Perhaps we could get 
together and see if we can apply for an interesting grant for some 
Clojure-related work.


Konrad.



In theory I am affiliated with Carnegie-Mellon University.

Tim Daly


This is too much of a coincidence minutes after I hit enter to send
this note I was informed that our project was cancelled and everyone
in the project is being terminated. So, ummm, it appears that I will not
have any CMU connection every so shortly. Sorry about that.

Tim Daly

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

Re: HPC in scala ..

[Myriam Abramson]

Hi Chad!

Where are you at NRL? I'm also working there. I was dreaming of having 
a clojure users group there. 


-- 
   myriam
cej38 junkerme...@gmail.com writes:

 I am currently at the Naval Research Laboratory, Washington DC.

 Chad



 On Jan 18, 11:59 am, Konrad Hinsen konrad.hin...@fastmail.net wrote:
 On 18 Jan, 2011, at 17:37 , cej38 wrote:

  I think the clojure community should be seeking the type of funding to
  make it the goto language for HPC.  As a community we definitely have
  the brains to make it happen.

 The brains, yes, but not the academic infrastructure. Scala is based at 
 EPFL, and the work on parallel programming is done in collaboration with 
 Stanford. That makes all of a difference when applying for funding in the 
 academic world, such as the ERC grant that the Scala guys got.

 Just out of curiosity: is there anyone else on this list who has an 
 affiliation with an academic institution? Perhaps we could get together and 
 see if we can apply for an interesting grant for some Clojure-related work.

 Konrad.

From the cat's little instruction handbook:

Learn to appreciate fine books -- especially when somebody else is
reading them.

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

HPC in scala ..

[Sunil S Nandihalli]

Hello Everybody,

not directly related to clojure .. but it is interesting to know that scala
people got a huge funding to further the state of the art in HPC...

http://www.scala-lang.org/node/8579

Sunil.

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

Re: HPC in scala ..

[Tim Daly]

Hello Everybody,

not directly related to clojure .. but it is interesting to know that 
scala people got a huge funding to further the state of the art in HPC...


http://www.scala-lang.org/node/8579

Sunil.

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

Very interesting. I wonder if Clojure can be one of the polymorphic targets.
Certainly the Clojure macro facility can lift raw Clojure toward the DSL.

Sigh. Yet more papers to read. :-)

Tim Daly

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

Re: HPC in scala ..

[Tim Daly]

Hello Everybody,

not directly related to clojure .. but it is interesting to know that 
scala people got a huge funding to further the state of the art in HPC...


http://www.scala-lang.org/node/8579

Sunil.

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


I have just finished
Language Virtualization for Heterogeneous Parallel Computing
http://infoscience.epfl.ch/record/148814/files/paper.pdf

The fundamental idea is defining a DSL (domain specific language)
to express some ideas. The DSL lives in a layer above the implementation
language but is embedded into the implementation language. That is,
the DSL does not have a separate compiler. DSLs define languages
that can support this as virtualization languages (VL). The VL needs
to provide four properties:
1) expressiveness -- everything should be expressible in the VL
2) performance -- the DSL should perform at VL speeds
3) safety -- the DSL should not reach into the underlying VL
4) effort -- the DSL should be easy to implement.

DSLs should be easy to combine because they both rest on the
same VL. Thus, a developer can provide capabilities of multiple
DSLs in the same image.

Clojure clearly fulfills all of the goals of a virtualization language
because it is a Lisp. Lisp systems are clearly capable of building
a DSL that is fully expressive of all of the power of Lisp. By using
the macro facility the DSL syntax can be matched to the problem
domain.

Macros allow the Clojure code to dynamically generate high performance
code that takes advantage of domain specific optimizations.

The macro language can be defined independent of the underlying
lisp so that there is no need to reach below the VL into Clojure.
This gives the DSL portability.

Macros are minimal effort. It is easy to develop macros and easy to
incrementally develop and enhance them to support any DSL features.

So I think that Clojure is an excellent virtualization language for DSLs.

While I do not know of any large Clojure applications yet, I know that
Axiom can be viewed as a mathematical domain specific language
in Common Lisp with facilities similar to Mathematica. ACL2 is a
logical domain specific language in Common Lisp with the ability
to prove lisp programs. Because they have a common VL they can
be combined into the same lisp image and ACL2 can be used to
prove Axiom mathematical statements. Lisp systems like Clojure
make this combination simple to implement.

I believe that, given enough time for Clojure to mature, we will see
large domain specific languages developed. These will be easy to
combine in a single Clojure image.

This paper provides a potential way to write parallel code for specific
domains. It attracted multi-million euro funding and could represent a
specific way forward for parallel Clojure programs.

Tim Daly

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

Re: Reusing Clojure libraries in Java/Jythom/Scala

[Dilvan]

   Hi,

   From today, I will not receive updates from this group, so if
anyone cares to answer this question, please send me an email:
dil...@gmail.com. I do think that this is an important question to
many people that liked a lot the Clojure concurrency model but cannot
use Clojure in their day to day programs.

   Cheers,

Dilvan

On Nov 22, 12:58 pm, Dilvan dil...@gmail.com wrote:
    Hi,

    During the discussions of the topic Jython Interoperability
 problem,
 Mikhail Kryshen suggested implementations of Clojure data structures
 outside Clojure:

 Clojure's data structures modified for use outside of Clojure:
 http://github.com/krukow/clj-ds
 Persistent analogue of the Java Collections Framework:
 http://code.google.com/p/pcollections/

    I've been using the Clojure libraries (immutable collections and
 Refs) in Java programs (a version of the Manchester OWL-API). Reading
 the documentation for the Clojure replacements suggested by Mikhail,
 they imply that the implementations inside the official Clojure
 libraries are inefficient (in terms of speed and memory) if used in
 Java only applications (no Clojure code) AND that, in the future, they
 may demand that all of the Clojure machinery be loaded with them. Is
 there any official view/police about this issue?

    The question I need to answer is: Should I keep using the Clojure
 libraries in my programs or migrate them to some other implementation
 of immutable collections + Refs (STM) + (maybe) actors?

    Advices are welcomed :-)

 DIlvanMoreira

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

Re: scala

[Saul Hazledine]

On Jun 18, 11:56 pm, cageface milese...@gmail.com wrote:

 Unfortunately there seems to be a lot more commercial momentum for
 Scala though. It's still a blip compared to the mainstream languages
 but I'm seeing more and more job posts mentioning it, and hardly any
 for Clojure. I don't think Scala is a bad language overall, but I'm
 not sure I'd dump Ruby for it. On the other hand, I can imagine
 migrating most of my dev work over to Clojure with the right project.
 Has anybody else wrestled with this choice? Any thoughts?

I started playing with Scala before I decided to make a long term
commitment to learning and using Clojure. I think Scala is both
exciting and awesome. The only thing that bothered me about it was the
community's choice of a two space indent (its very tiring to look
after a few hours).

I ended up choosing Clojure for my own needs because the availability
of macros and I enjoy programming in Clojure more than other
languages. Personally I feel big corporate style projects destroy a
language - I've seen simple elegant Java code but the culture went in
a different direction entirely. So I personally would be happier if
Scala goes mainstream and Clojure doesn't.

The really cool thing though, is that with the JVM, Clojure and Scala
can interoperate.

Saul

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

Re: scala

[nickikt]

For such a young language it has a big momentum. Did Scala have that
after 2 years?

On 18 Jun., 23:56, cageface milese...@gmail.com wrote:
 Quick disclaimer - there are a lot of things I like in Scala and I
 think Odersky  crew have done some very impressive work bringing
 functional language concepts to the VM and giving Java developers a
 path forward. I also don't think Clojure vs x language battles are
 very productive and don't want to encourage one.

 Anyway, I imagine my trajectory as a developer over the last 10  years
 is pretty typical. I started out doing Java stuff but fell in love
 with Ruby and Rails in 2004 and have been working almost entirely in
 Ruby since. The idea that all that heavy, cumbersome Java cruft could
 in many cases be dispensed with was a revelation and the discovery
 that I could build software in a language that offered *no* compile
 time error checking that was still robust was a very pleasant
 surprise.

 Like a lot of Ruby hackers though, I also saw some warts in the
 language and also remained curious about other approaches. Also like a
 lot of Ruby hackers, the recent rise of new JVM languages has piqued
 my interest, particularly Scala and Clojure. Scala seemed like a more
 natural step from Ruby and my first experiences with it were
 encouraging. It seemed to offer a lot of the expressiveness of Ruby
 but with potentially much better performance and more robust runtime
 and, intriguingly, static type checking. However, after writing a
 handful of small but non-trivial programs in it the complexity lurking
 under the surface started peeking through and the intricacies of the
 type system and the significant complexity of the language itself
 became more apparent. It started to feel like a step back to the
 rigors of Java and heavyweight syntax and fights with the compiler.
 The predominant Scala web platform, Lift, also seemed to have a very
 heavy, enterprisey sort of correctness about it that felt
 overengineered.

 So I bounced over to Clojure and its clean, elegant core and minimal,
 flexible syntax seemed very refreshing. It felt much more in the
 liberal, malleable spirit of Ruby. The functional stuff was a bit of a
 stretch but it also seemed built on a simpler set of core concepts
 than the featureful but complex Scala collections.

 Unfortunately there seems to be a lot more commercial momentum for
 Scala though. It's still a blip compared to the mainstream languages
 but I'm seeing more and more job posts mentioning it, and hardly any
 for Clojure. I don't think Scala is a bad language overall, but I'm
 not sure I'd dump Ruby for it. On the other hand, I can imagine
 migrating most of my dev work over to Clojure with the right project.
 Has anybody else wrestled with this choice? Any thoughts?

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

scala

[cageface]

Quick disclaimer - there are a lot of things I like in Scala and I
think Odersky  crew have done some very impressive work bringing
functional language concepts to the VM and giving Java developers a
path forward. I also don't think Clojure vs x language battles are
very productive and don't want to encourage one.

Anyway, I imagine my trajectory as a developer over the last 10  years
is pretty typical. I started out doing Java stuff but fell in love
with Ruby and Rails in 2004 and have been working almost entirely in
Ruby since. The idea that all that heavy, cumbersome Java cruft could
in many cases be dispensed with was a revelation and the discovery
that I could build software in a language that offered *no* compile
time error checking that was still robust was a very pleasant
surprise.

Like a lot of Ruby hackers though, I also saw some warts in the
language and also remained curious about other approaches. Also like a
lot of Ruby hackers, the recent rise of new JVM languages has piqued
my interest, particularly Scala and Clojure. Scala seemed like a more
natural step from Ruby and my first experiences with it were
encouraging. It seemed to offer a lot of the expressiveness of Ruby
but with potentially much better performance and more robust runtime
and, intriguingly, static type checking. However, after writing a
handful of small but non-trivial programs in it the complexity lurking
under the surface started peeking through and the intricacies of the
type system and the significant complexity of the language itself
became more apparent. It started to feel like a step back to the
rigors of Java and heavyweight syntax and fights with the compiler.
The predominant Scala web platform, Lift, also seemed to have a very
heavy, enterprisey sort of correctness about it that felt
overengineered.

So I bounced over to Clojure and its clean, elegant core and minimal,
flexible syntax seemed very refreshing. It felt much more in the
liberal, malleable spirit of Ruby. The functional stuff was a bit of a
stretch but it also seemed built on a simpler set of core concepts
than the featureful but complex Scala collections.

Unfortunately there seems to be a lot more commercial momentum for
Scala though. It's still a blip compared to the mainstream languages
but I'm seeing more and more job posts mentioning it, and hardly any
for Clojure. I don't think Scala is a bad language overall, but I'm
not sure I'd dump Ruby for it. On the other hand, I can imagine
migrating most of my dev work over to Clojure with the right project.
Has anybody else wrestled with this choice? Any thoughts?

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

Re: scala

[Mark Engelberg]

I've spent a number of years looking for a functional programming
language suitable for the kind of work I do.  evaluating Clojure,
Haskell, Erlang, Scala, F#, Mozart, ML, Clean, Racket, and probably
some others I'm not thinking about right now.  For me, once Clojure
hit 1.0 status, it was clearly the best choice for my purposes.  Scala
is probably my second choice, but I think there's a chance it would be
my first if I were working on a large team -- I have an unfounded
opinion that static typing can be especially useful for ensuring that
components produced by different individuals get properly linked up.
But as a solo developer, I feel great about my decision to use
Clojure.

So to answer your question, yes, a lot of us have spent time
evaluating many languages and agonizing over which is the best one for
our purposes.  Try the languages that interest you, and decide for
yourself.

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

Re: scala

[RandyHudson]

Bear in mind that Scala is about 5 years older than Clojure, so it's
had more time to build up momentum.

On Jun 18, 5:56 pm, cageface milese...@gmail.com wrote:

 Unfortunately there seems to be a lot more commercial momentum for
 Scala though. It's still a blip compared to the mainstream languages
 but I'm seeing more and more job posts mentioning it, and hardly any
 for 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

Re: Matt Raible: Why is Clojure better than Scala or Groovy?

[Mike Meyer]

On Fri, Jan 15, 2010 at 8:22 PM, Julian juliangam...@gmail.com wrote:
 Matt Raible - Spring Expert and Java consultant posted the following
 entry to Twitter:
 Why is Clojure better than Scala or Groovy?

How about two reasons to learn Clojure instead?

1) Clojure is (a) LISP. According to Eric Raymond, LISP is worth
learning for a different reason — the profound enlightenment
experience you will have when you finally get it. That experience will
make you a better programmer for the rest of your days, even if you
never actually use LISP itself a lot.

2) Clojure is designed from the ground up for concurrent
programming. It has a number of mechanisms that improve on locks for
managing state. Those come from other languages, and are liable to
appear in yet more languages in the future. If you're doing concurrent
programming, learning them will make you a better concurrent
programmer. If you're not doing concurrent programming, consider that
CPU improvement has changed from an exponential growth in raw speed to
an exponential growth in number of cores.

   mike
-- 
Mike Meyer m...@mired.org http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O ascii ribbon campaign - stop html mail - www.asciiribbon.org
-- 
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

Re: Matt Raible: Why is Clojure better than Scala or Groovy?

[Keith Irwin]

I don't think you can really answer the question because it being asked in
the way it that precludes a good enough answer. The tone of Matt Raible's
request suggests that he'd really rather not learn it, and that there's no
possible reason to overcome that reluctance.

Why travel? There's plenty of good food right here, and interesting cultural
sites to see, and stuff to buy. But you don't ask that question: you just
go, and FIND OUT why it was worth doing after the fact. (Or maybe not.)

Still. My take:

1. Clojure is dynamic like Groovy, and functional like Scala, so if Matt
learned it, he'd be able to see what that's like.

2. It's a Lisp, and that's worth trying at least once, but it's on the JVM
and a new dialect, so it lets you write Java in Lisp at first, and the lets
you enjoy beginning to see new ways of thinking about problems.

3. Clojure has a flavor of STM that's database-like, and easy to use for the
non-theorist programmer (i.e., folks like me who just write dorky business
apps that aren't much more than shoving data to/from the web/database). This
really cuts down on threading bugs, which are super hard to diagnose when
the errors occur in production, which is always locked down and inaccessible
to devs, debuggers, etc. STM doesn't help distributed concurrency (for which
actors are better, imho), but it does help for a wide range of
non-distributed use cases.

4. Clojure's macros make domain specific languages a natural part of
programming. While Groovy's various Builders are pretty nice, it's not so
easy to write your own builder, esp. if you're under pressure to get
something done. For instance, I write a lot of Groovy apps, and I want
something like Compojure. But the idea of figuring out how to use the
Builder Support to do something like that just makes me tired.

Really, though, it's so hard to convince someone that one language is better
than another significantly enough to be worth learning using reason or
any other method. One just has to try it.

For me, Clojure/Lisp just works the way I do. Incremental, small functions,
interactive, etc, etc generally as a result of super-vague requirements.
Every time I write an app in it, I feel like the app gets smaller and
simpler over time. I let myself write a lot of boilerplate (to avoid
premature abstraction), then condense it all in a way that fits my app (not,
say, a general lib), and the whole experience of it is positive. Better,
smaller code, faster, and more fun to do (even if it's the same old business
tasks).

So, Clojure wins or is worth trying because of the experience of using
it, not because of some particular bullet point, which all languages feel
like they all have.

(Personally, I'd really love Haskell/Erlang like pattern matching, not just
destructuring or multi-methods (but those, too!), but even so)

Didn't Paul Graham say something to the affect that a user of a blub
language just can't see the point in other languages? I don't think Groovy
and Scala are blub languages, but I think the idea applies, at least in an
emotional way.

Matt should just give it a few weeks' try, like Tim Bray did.

Keith

On Sun, Jan 17, 2010 at 12:00 PM, Mike Meyer 
mwm-keyword-googlegroups.620...@mired.org wrote:

 On Fri, Jan 15, 2010 at 8:22 PM, Julian juliangam...@gmail.com wrote:
  Matt Raible - Spring Expert and Java consultant posted the following
  entry to Twitter:
  Why is Clojure better than Scala or Groovy?

 How about two reasons to learn Clojure instead?

 1) Clojure is (a) LISP. According to Eric Raymond, LISP is worth
 learning for a different reason — the profound enlightenment
 experience you will have when you finally get it. That experience will
 make you a better programmer for the rest of your days, even if you
 never actually use LISP itself a lot.

 2) Clojure is designed from the ground up for concurrent
 programming. It has a number of mechanisms that improve on locks for
 managing state. Those come from other languages, and are liable to
 appear in yet more languages in the future. If you're doing concurrent
 programming, learning them will make you a better concurrent
 programmer. If you're not doing concurrent programming, consider that
 CPU improvement has changed from an exponential growth in raw speed to
 an exponential growth in number of cores.

   mike
 --
 Mike Meyer m...@mired.org
 http://www.mired.org/consulting.html
 Independent Network/Unix/Perforce consultant, email for more information.

 O ascii ribbon campaign - stop html mail - www.asciiribbon.org

 --
 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.comclojure%2bunsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group

Matt Raible: Why is Clojure better than Scala or Groovy?

[Julian]

Matt Raible - Spring Expert and Java consultant posted the following
entry to Twitter:
Why is Clojure better than Scala or Groovy?
http://twitter.com/mraible/status/7793457551

He went on to say:
Let's try that again: I like Scala and Groovy and see no compelling
reason to learn Clojure. Am I missing something?
http://twitter.com/mraible/status/7794565786

I know that I think - but I thought the awesome community here could
help answer this question.
-- 
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

Re: Matt Raible: Why is Clojure better than Scala or Groovy?

[Rich Hickey]

On Fri, Jan 15, 2010 at 8:22 PM, Julian juliangam...@gmail.com wrote:
 Matt Raible - Spring Expert and Java consultant posted the following
 entry to Twitter:
 Why is Clojure better than Scala or Groovy?
 http://twitter.com/mraible/status/7793457551

 He went on to say:
 Let's try that again: I like Scala and Groovy and see no compelling
 reason to learn Clojure. Am I missing something?
 http://twitter.com/mraible/status/7794565786

 I know that I think - but I thought the awesome community here could
 help answer this question.


I would very much like to discourage the bashing of other languages
here. It is tedious and pointless. Should anyone be provoked into
responding to this, please keep your comments to attributes/deficits
of Clojure.

Thanks,

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

Re: Matt Raible: Why is Clojure better than Scala or Groovy?

[Laurent PETIT]

One third main selling point, just for you ;-) :

Clojure has a rooted in it a development paradigm suited to manage
state of identities over time.
That is, clojure embraces the functional paradigm for most of the
development process, but does not leave you naked when time comes to
write those parts of your application which require dealing with
state, time, concurrency, parallelism, etc.

Rich's videos are particularly enlightening concerning this point:

 * a (mostly) clojure agnostic explanation of the problem and a
general solution to it:
http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey

 * a more clojure-oriented talk which complements the above with clojure detail:
http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey


2010/1/16 Shantanu Kumar kumar.shant...@gmail.com:


 On Jan 16, 6:22 am, Julian juliangam...@gmail.com wrote:
 Matt Raible - Spring Expert and Java consultant posted the following
 entry to Twitter:
 Why is Clojure better than Scala or 
 Groovy?http://twitter.com/mraible/status/7793457551

 He went on to say:
 Let's try that again: I like Scala and Groovy and see no compelling
 reason to learn Clojure. Am I missing 
 something?http://twitter.com/mraible/status/7794565786

 I know that I think - but I thought the awesome community here could
 help answer this question.

 I wrote about benefits Clojure (v1.0) some time ago:
 http://bitumenframework.blogspot.com/2009/09/benefits-of-using-clojure-lisp-in.html

 The best benefit of Clojure is, I think, the power-to-weight ratio.
 The language is so much devoid of syntax and semantics bloat that
 whatever code you write in Clojure is pure productivity. Concurrency-
 handling makes it suitable for current-day development and as Chouser
 noted, the Macros feature is a game changer.

 Regards,
 Shantanu

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

Re: Matt Raible: Why is Clojure better than Scala or Groovy?

[Jon Harrop]

On Saturday 16 January 2010 18:10:15 Shantanu Kumar wrote:
 The best benefit of Clojure is, I think, the power-to-weight ratio.

That's a really good description for a low barrier to entry. :-)

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
-- 
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

Re: java/scala oneliner

[Krukow]

On Sep 18, 6:24 am, Wilson MacGyver wmacgy...@gmail.com wrote:
 Hmmm, your solution produces nils in REPL.

 user= (map #(printf Happy Birthday %s\n (if (= 2 %) Dear XXX To
 You)) (range 4))
 (Happy Birthday To You
 Happy Birthday To You
 nil Happy Birthday Dear XXX
 nil Happy Birthday To You
 nil nil)

Yes, the result of the computation is (nil nil nil nil), a side-effect
is printing:
Happy Birthday To You
Happy Birthday To You
Happy Birthday Dear XXX
Happy Birthday To You.

I thought you wanted to print since the Scala and Java programs
print.

If you want to compute, you could use

(map #(str Happy Birthday  (if (= 2 %) Dear XXX To You)) (range
4))

If you want to print, and avoid a list of nils, you could use

(dotimes [i 4] (printf Happy Birthday %s\n (if (= 2 i) Dear XXX
To You)))

which is essentially the Java version.

Incidentally,
user (count (dotimes [i 4] (printf \Happy Birthday %s\n\ (if (= 2
i) \Dear XXX\ \To You\
78

/Karl
/Karl
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: java/scala oneliner

[Wilson MacGyver]

Clojure REPL will display nil for anything that causes side-effect?
I had no idea!

On Fri, Sep 18, 2009 at 2:24 AM, Krukow karl.kru...@gmail.com wrote:
 Yes, the result of the computation is (nil nil nil nil), a side-effect
 is printing:
 Happy Birthday To You
 Happy Birthday To You
 Happy Birthday Dear XXX
 Happy Birthday To You.

 I thought you wanted to print since the Scala and Java programs
 print.

 If you want to compute, you could use

 (map #(str Happy Birthday  (if (= 2 %) Dear XXX To You)) (range
 4))

 If you want to print, and avoid a list of nils, you could use

 (dotimes [i 4] (printf Happy Birthday %s\n (if (= 2 i) Dear XXX
 To You)))

 which is essentially the Java version.

 Incidentally,
 user (count (dotimes [i 4] (printf \Happy Birthday %s\n\ (if (= 2
 i) \Dear XXX\ \To You\
 78

 /Karl
 /Karl
 




-- 
Omnem crede diem tibi diluxisse supremum.

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

Re: java/scala oneliner

[David Nolen]

On Fri, Sep 18, 2009 at 2:41 AM, Wilson MacGyver wmacgy...@gmail.comwrote:


 Clojure REPL will display nil for anything that causes side-effect?
 I had no idea!


No. The return value of println _is_ nil. map takes a collection of values
and returns a new collection of values by applying the supplied fn on each
element of the collection. Thus the collection of 4 nils when using map.



 On Fri, Sep 18, 2009 at 2:24 AM, Krukow karl.kru...@gmail.com wrote:
  Yes, the result of the computation is (nil nil nil nil), a side-effect
  is printing:
  Happy Birthday To You
  Happy Birthday To You
  Happy Birthday Dear XXX
  Happy Birthday To You.
 
  I thought you wanted to print since the Scala and Java programs
  print.
 
  If you want to compute, you could use
 
  (map #(str Happy Birthday  (if (= 2 %) Dear XXX To You)) (range
  4))
 
  If you want to print, and avoid a list of nils, you could use
 
  (dotimes [i 4] (printf Happy Birthday %s\n (if (= 2 i) Dear XXX
  To You)))
 
  which is essentially the Java version.
 
  Incidentally,
  user (count (dotimes [i 4] (printf \Happy Birthday %s\n\ (if (= 2
  i) \Dear XXX\ \To You\
  78
 
  /Karl
  /Karl
  
 



 --
 Omnem crede diem tibi diluxisse supremum.

 


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

Re: java/scala oneliner

[Richard Newman]

 Clojure REPL will display nil for anything that causes side-effect?
 I had no idea!

More accurately, any side effects that print will be printed, then the  
return value of the function will be printed by the REPL (the P part).

If the function returns nil, you'll see a final nil appear.

map collects the return values of its calls and returns the sequence.  
println returns nil, so

(map (fn [x] (println Foo x)) [1 2 3])

will print

Foo 1
Foo 2
Foo 3

and return (nil nil nil). This list will be printed by the REPL.

Strictly speaking, because map is lazy it will actually show in the  
REPL:

user= (map (fn [x] (println Foo x)) [1 2 3])
(Foo 1
Foo 2
Foo 3
nil nil nil)


You'll see that the side effects of printing involved in calculating  
the expression occur part-way through printing the list of nils in the  
REPL! Laziness in action :)

If you force the matter with doall this changes:


user= (doall (map (fn [x] (println Foo x)) [1 2 3]))
Foo 1
Foo 2
Foo 3
(nil nil nil)


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

Re: java/scala oneliner

[Adrian Cuthbertson]

If y're Sco'ish... - 59

(dotimes[i 4](printlnAppy Birthdy({2D'r XXX}iTo Ye)))
Appy Birthdy To Ye
Appy Birthdy To Ye
Appy Birthdy D'r XXX
Appy Birthdy To Ye



On Fri, Sep 18, 2009 at 6:35 AM, David Nolen dnolen.li...@gmail.com wrote:
 hiredman in the lead!
 (dotimes[i 4](printlnHappy Birthday({2Dear XXX}iTo You))) - 63

 On Fri, Sep 18, 2009 at 12:32 AM, Kevin Downey redc...@gmail.com wrote:

 :(

 map is lazy, so you'll need to wrap it in doall

 (dotimes [i 4] (println Happy Birthday ({2 Dear XXX} i To You)))

 On Thu, Sep 17, 2009 at 9:17 PM, David Nolen dnolen.li...@gmail.com
 wrote:
  Actually to be fair, here's a Clojure version that uses as little
  whitespace
  as the Scala and Java ones do.
  (map #(strHappy Birthday %)(assoc (vec (replicate 4To You))2Dear
  XXX))
  ; - 76 chars
 
  On Fri, Sep 18, 2009 at 12:14 AM, David Nolen dnolen.li...@gmail.com
  wrote:
 
  Your basic approach seems sound:
  (map #(str Happy Birthday  %) (assoc (vec (replicate 4 To You)) 2
  Dear XXX) - 81 chars including white space
  for(int i=0;i4;i++){System.out.println(Happy Birthday +(i==2?Dear
  XXX:To You));}) - 88 chars
  (1 to 4).map{i=Happy Birthday %s.format(if(i==3)Dear XXXelseTo
  You)}.foreach{println(_)} - 95 chars
  Anyone have a shorter version? :)
  On Thu, Sep 17, 2009 at 11:53 PM, Wilson MacGyver wmacgy...@gmail.com
  wrote:
 
  This blog post got me thinking.
  http://www.artima.com/weblogs/viewpost.jsp?thread=268561
 
  Basically it contains both a Java one liner and Scala one liner.
 
  Java:
  for(int i=0; i4; i++) { System.out.println(Happy Birthday  + (i==2
  ? Dear XXX : To You)); }
 
  Scala:
  (1 to 4).map { i = Happy Birthday %s.format(if (i == 3) Dear XXX
  else To You) }.foreach { println(_) }
 
  the goal is to generate
 
  Happy Birthday To You
  Happy Birthday To You
  Happy Birthday Dear XXX
  Happy Birthday To You
 
 
  I started thinking about how to do this in clojure. My first reaction
  was
  to
  think of the sentences as two sequences. Uses replicate to generate
  them, and map str to join them from two collections.
 
  ie, (map str (replicate 4 Happy Birthday )...
 
  Is there a more clojure way to do it?
  because using replicate to generate the 2nd sequence seem like
  cheating.
  ie, replicate 2 To You, 1 Dear XXX, and then To You again.
 
 
 
  --
  Omnem crede diem tibi diluxisse supremum.
 
 
 
 
 
  
 



 --
 And what is good, Phaedrus,
 And what is not good—
 Need we ask anyone to tell us these things?




 


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

Re: java/scala oneliner

[Timothy Pratley]

Nice one! :)


On Sep 18, 4:47 pm, Adrian Cuthbertson adrian.cuthbert...@gmail.com
wrote:
 If y're Sco'ish... - 59

 (dotimes[i 4](printlnAppy Birthdy({2D'r XXX}iTo Ye)))
 Appy Birthdy To Ye
 Appy Birthdy To Ye
 Appy Birthdy D'r XXX
 Appy Birthdy To Ye

 On Fri, Sep 18, 2009 at 6:35 AM, David Nolen dnolen.li...@gmail.com wrote:
  hiredman in the lead!
  (dotimes[i 4](printlnHappy Birthday({2Dear XXX}iTo You))) - 63

  On Fri, Sep 18, 2009 at 12:32 AM, Kevin Downey redc...@gmail.com wrote:

  :(

  map is lazy, so you'll need to wrap it in doall

  (dotimes [i 4] (println Happy Birthday ({2 Dear XXX} i To You)))

  On Thu, Sep 17, 2009 at 9:17 PM, David Nolen dnolen.li...@gmail.com
  wrote:
   Actually to be fair, here's a Clojure version that uses as little
   whitespace
   as the Scala and Java ones do.
   (map #(strHappy Birthday %)(assoc (vec (replicate 4To You))2Dear
   XXX))
   ; - 76 chars

   On Fri, Sep 18, 2009 at 12:14 AM, David Nolen dnolen.li...@gmail.com
   wrote:

   Your basic approach seems sound:
   (map #(str Happy Birthday  %) (assoc (vec (replicate 4 To You)) 2
   Dear XXX) - 81 chars including white space
   for(int i=0;i4;i++){System.out.println(Happy Birthday +(i==2?Dear
   XXX:To You));}) - 88 chars
   (1 to 4).map{i=Happy Birthday %s.format(if(i==3)Dear XXXelseTo
   You)}.foreach{println(_)} - 95 chars
   Anyone have a shorter version? :)
   On Thu, Sep 17, 2009 at 11:53 PM, Wilson MacGyver wmacgy...@gmail.com
   wrote:

   This blog post got me thinking.
  http://www.artima.com/weblogs/viewpost.jsp?thread=268561

   Basically it contains both a Java one liner and Scala one liner.

   Java:
   for(int i=0; i4; i++) { System.out.println(Happy Birthday  + (i==2
   ? Dear XXX : To You)); }

   Scala:
   (1 to 4).map { i = Happy Birthday %s.format(if (i == 3) Dear XXX
   else To You) }.foreach { println(_) }

   the goal is to generate

   Happy Birthday To You
   Happy Birthday To You
   Happy Birthday Dear XXX
   Happy Birthday To You

   I started thinking about how to do this in clojure. My first reaction
   was
   to
   think of the sentences as two sequences. Uses replicate to generate
   them, and map str to join them from two collections.

   ie, (map str (replicate 4 Happy Birthday )...

   Is there a more clojure way to do it?
   because using replicate to generate the 2nd sequence seem like
   cheating.
   ie, replicate 2 To You, 1 Dear XXX, and then To You again.

   --
   Omnem crede diem tibi diluxisse supremum.

  --
  And what is good, Phaedrus,
  And what is not good—
  Need we ask anyone to tell us these things?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

java/scala oneliner

[Wilson MacGyver]

This blog post got me thinking.
http://www.artima.com/weblogs/viewpost.jsp?thread=268561

Basically it contains both a Java one liner and Scala one liner.

Java:
for(int i=0; i4; i++) { System.out.println(Happy Birthday  + (i==2
? Dear XXX : To You)); }

Scala:
(1 to 4).map { i = Happy Birthday %s.format(if (i == 3) Dear XXX
else To You) }.foreach { println(_) }

the goal is to generate

Happy Birthday To You
Happy Birthday To You
Happy Birthday Dear XXX
Happy Birthday To You


I started thinking about how to do this in clojure. My first reaction was to
think of the sentences as two sequences. Uses replicate to generate
them, and map str to join them from two collections.

ie, (map str (replicate 4 Happy Birthday )...

Is there a more clojure way to do it?
because using replicate to generate the 2nd sequence seem like cheating.
ie, replicate 2 To You, 1 Dear XXX, and then To You again.



-- 
Omnem crede diem tibi diluxisse supremum.

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

Re: java/scala oneliner

[David Nolen]

Your basic approach seems sound:
(map #(str Happy Birthday  %) (assoc (vec (replicate 4 To You)) 2 Dear
XXX) - 81 chars including white space

for(int i=0;i4;i++){System.out.println(Happy Birthday +(i==2?Dear
XXX:To You));}) - 88 chars

(1 to 4).map{i=Happy Birthday %s.format(if(i==3)Dear XXXelseTo
You)}.foreach{println(_)} - 95 chars

Anyone have a shorter version? :)

On Thu, Sep 17, 2009 at 11:53 PM, Wilson MacGyver wmacgy...@gmail.comwrote:


 This blog post got me thinking.
 http://www.artima.com/weblogs/viewpost.jsp?thread=268561

 Basically it contains both a Java one liner and Scala one liner.

 Java:
 for(int i=0; i4; i++) { System.out.println(Happy Birthday  + (i==2
 ? Dear XXX : To You)); }

 Scala:
 (1 to 4).map { i = Happy Birthday %s.format(if (i == 3) Dear XXX
 else To You) }.foreach { println(_) }

 the goal is to generate

 Happy Birthday To You
 Happy Birthday To You
 Happy Birthday Dear XXX
 Happy Birthday To You


 I started thinking about how to do this in clojure. My first reaction was
 to
 think of the sentences as two sequences. Uses replicate to generate
 them, and map str to join them from two collections.

 ie, (map str (replicate 4 Happy Birthday )...

 Is there a more clojure way to do it?
 because using replicate to generate the 2nd sequence seem like cheating.
 ie, replicate 2 To You, 1 Dear XXX, and then To You again.



 --
 Omnem crede diem tibi diluxisse supremum.

 


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