Re: Scala/Clojure/F# - Functional Programming Advocates - New York/Chicago/San Fran
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 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
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.
Scala/Clojure/F# - Functional Programming Advocates - New York/Chicago/San Fran
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 for-comprehension to Clojure
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 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
>> 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 j
Re: Scala for-comprehension to Clojure
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 > 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
Re: Scala for-comprehension to Clojure
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" 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
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
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
>
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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
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.
Scala for-comprehension to Clojure
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: Lazy fold-right, help with Scala translation
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: Lazy fold-right, help with Scala translation
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
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: Port of simple Scala match to Clojure core.match
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 >
> 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
>>
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from 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
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 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.
Port of simple Scala match to Clojure core.match
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: Calling an overloaded Scala function
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 > 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(ArrayList str) {
>> System.out.println("string");
>> return "";
>> }
>>
>> public static int Onk(ArrayList it) {
>> System.out.println("int");
>> return 0;
>> }
>>
>>
>>
>> This fails to compile :
>>
>>
>> Error:(11, 24) java: name clash:
>> Onk(java.util.ArrayList) and
>> Onk(java.util.ArrayList) 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 :
>>
>> ([#> scala.collection.Seq> com.cra.figaro.language.Element>>>,
>> #>,
>> com.cra.figaro.language.ElementCollection]
>> [#> scala.collection.Seq,
>> com.cra.figaro.language.Element>>>,
>> #>,
>> 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 com.cra.figaro.language.AtomicDist
>>>>> apply(scala.collection.Seq>>>> com.cra.figaro.language.Element>>, com.cra.figaro.language.Name,
>>>>> com.cra.figaro.language.ElementCollection);
>>>>>
>>>>> public com.cra.figaro.language.CompoundDist
>>>>> apply(scala.collection.Seq,
>>>>> com.cra.figaro.language.Element>>, com.cra.figaro.language.Name,
>>>>> 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,
>>&g
Re: Calling an overloaded Scala function
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
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(ArrayList str) {
> System.out.println("string");
> return "";
> }
>
> public static int Onk(ArrayList it) {
> System.out.println("int");
> return 0;
> }
>
>
>
> This fails to compile :
>
>
> Error:(11, 24) java: name clash:
> Onk(java.util.ArrayList) and
> Onk(java.util.ArrayList) 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 :
>
> ([# scala.collection.Seq com.cra.figaro.language.Element>>>,
> #>,
> com.cra.figaro.language.ElementCollection]
> [# scala.collection.Seq,
> com.cra.figaro.language.Element>>>,
> #>,
> 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 com.cra.figaro.language.AtomicDist
>>>> apply(scala.collection.Seq>>> com.cra.figaro.language.Element>>, com.cra.figaro.language.Name,
>>>> com.cra.figaro.language.ElementCollection);
>>>>
>>>> public com.cra.figaro.language.CompoundDist
>>>> apply(scala.collection.Seq,
>>>> com.cra.figaro.language.Element>>, com.cra.figaro.language.Name,
>>>> 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 jus
Re: Calling an overloaded Scala function
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(ArrayList str) {
System.out.println("string");
return "";
}
public static int Onk(ArrayList it) {
System.out.println("int");
return 0;
}
This fails to compile :
Error:(11, 24) java: name clash:
Onk(java.util.ArrayList) and
Onk(java.util.ArrayList) 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 :
([#>>>,
#>,
com.cra.figaro.language.ElementCollection]
[#,
com.cra.figaro.language.Element>>>,
#>,
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 com.cra.figaro.language.AtomicDist
>>> apply(scala.collection.Seq>> com.cra.figaro.language.Element>>, com.cra.figaro.language.Name,
>>> com.cra.figaro.language.ElementCollection);
>>>
>>> public com.cra.figaro.language.CompoundDist
>>> apply(scala.collection.Seq,
>>> com.cra.figaro.language.Element>>, com.cra.figaro.language.Name,
>>> 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 :
>>>>>>
>>>
Re: Calling an overloaded Scala function
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 > wrote:
>
>> javap gives :
>>
>> public com.cra.figaro.language.AtomicDist
>> apply(scala.collection.Seq> com.cra.figaro.language.Element>>, com.cra.figaro.language.Name,
>> com.cra.figaro.language.ElementCollection);
>>
>> public com.cra.figaro.language.CompoundDist
>> apply(scala.collection.Seq,
>> com.cra.figaro.language.Element>>, com.cra.figaro.language.Name,
>> 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
>> 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
>>>> you
Re: Calling an overloaded Scala function
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
wrote:
> javap gives :
>
> public com.cra.figaro.language.AtomicDist
> apply(scala.collection.Seq com.cra.figaro.language.Element>>, com.cra.figaro.language.Name,
> com.cra.figaro.language.ElementCollection);
>
> public com.cra.figaro.language.CompoundDist
> apply(scala.collection.Seq,
> com.cra.figaro.language.Element>>, com.cra.figaro.language.Name,
> 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
> 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.
>>>
Re: Calling an overloaded Scala function
javap gives :
public com.cra.figaro.language.AtomicDist
apply(scala.collection.Seq>>, com.cra.figaro.language.Name,
com.cra.figaro.language.ElementCollection);
public com.cra.figaro.language.CompoundDist
apply(scala.collection.Seq,
com.cra.figaro.language.Element>>, com.cra.figaro.language.Name,
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
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
> 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
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
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
I am sadly quite clueless when it comes to Java.
De-compiling the Scala class file to Java gives me the following:
public AtomicDist apply(Seq>> clauses,
Name name, ElementCollection collection) {
return new AtomicDist(name, clauses.toList(), collection);
}
public CompoundDist apply(Seq,
Element>> clauses, Name 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 > wrote:
>
>> Interesting. That could be a good last resort.
>>
>> On Thu, Jun 25, 2015 at 1:27 PM Andy Fingerhut
>> 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 f
Re: Calling an overloaded Scala function
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
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 wrote: > Interesting. That could be a good last resort. > > On Thu, Jun 25, 2015 at 1:27 PM Andy Fingerhut > 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
Interesting. That could be a good last resort. On Thu, Jun 25, 2015 at 1:27 PM Andy Fingerhut 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 > 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
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 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.
Calling an overloaded Scala function
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
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
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?
On Mon, Dec 16, 2013 at 12:30 PM, Guru Devanla 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.
Re: Is Clojure more functional then Scala?
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 wrote: > 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, visi
Re: Is Clojure more functional then Scala?
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?
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 Prefontaine sent by ibisMail!
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegrou
Re: Is Clojure more functional then Scala?
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 Prefontaine sent by ibisMail! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Is Clojure more functional then Scala?
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 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?
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, Эльдар Габдуллин wrote: > 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?
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?
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.
Is Clojure more functional then Scala?
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)
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 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
> wrote:
>> Mark 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.)
>> #
>> user> (fn [q x] (.offer q x))
>> Reflection warning, /tmp/form-init7252328014986537096.clj:1:11 - call to
>> offer can't be resolved.
>> #
>> user> (fn [q x] (.offer ^Q q x))
>> #
>>
>> 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.
Re: Scala interop (or, aliasing imported Java classes)
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
wrote:
> Mark 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.)
> #
> user> (fn [q x] (.offer q x))
> Reflection warning, /tmp/form-init7252328014986537096.clj:1:11 - call to
> offer can't be resolved.
> #
> user> (fn [q x] (.offer ^Q q x))
> #
>
> 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)
Mark 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.) # user> (fn [q x] (.offer q x)) Reflection warning, /tmp/form-init7252328014986537096.clj:1:11 - call to offer can't be resolved. # user> (fn [q x] (.offer ^Q q x)) # 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)
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.
Re: Scala interop (or, aliasing imported Java classes)
+1 On Fri, Nov 1, 2013 at 6:49 PM, Cedric Greevey 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 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)
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 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.
Scala interop (or, aliasing imported Java classes)
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...
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
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
On Thu, Sep 15, 2011 at 9:24 AM, Edward Garson 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
Native Erlang does have a macro facility, but it is not as powerful as Lisp/Clojure's. On Sep 15, 2:15 am, cig 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
On Wed, Sep 14, 2011 at 11:15 PM, cig 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
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 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
Oh, it was just one, after all ? Please, don't tell this to my boss :-D 2011/9/13 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 > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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
On Tue, Sep 13, 2011 at 9:48 AM, Nathan Sorenson 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
“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
Isn't it Brooks who said "you will throw it away at least 3 times", or something like this ? :) 2011/9/13 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 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
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 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: Deamons in Clojure (was Re: Clojure vs Scala - anecdote)
I've used Apache Commons Daemon in my projects On windows I had following registration .bat to run it as service: @echo off cd /D "$INSTALL_PATH\sbin" SET UHOME=$INSTALL_PATH SET UMAINCLASS=myprog.main SET ULOGDIR=%UHOME%\var\log MKDIR %UHOME%\var\tmp\myprog\ MKDIR %ULOGDIR% %UHOME%\sbin\%PROCESSOR_ARCHITECTURE%\myprog.exe //IS//Myprog --DisplayName="Myprog" --Install=%UHOME%\sbin\%PROCESSOR_ARCHITECTURE%\myprog.exe --Jvm=auto --Startup=auto --StartPath=%UHOME%\sbin --StartMode=jvm --StopMode=jvm --StartClass=%UMAINCLASS% --StartMethod=main --StartParams=start --StopMode=jvm --StopClass=%UMAINCLASS% --StopMethod=main --StopParams=stop --LogPath=%ULOGDIR% --StdOutput=auto --StdError=auto --Classpath=%UHOME%\lib\myprog-0.1-jar-with-dependencies.jar --JvmOptions=-Djava.library.path=%UHOME%\lib;-Dwservice.configuration=..\etc\wservice.properties;-Dlog4j.defaultInitOverride=true;-Dlog4j.configuration=..\etc\log4j.properties sc start Myprog on Linux I just followed instructions from ACD page On Wed, Sep 7, 2011 at 4:26 PM, Marko Kocić wrote: > 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 -- With best wishes, Alex Ott http://alexott.net/ Tiwtter: alexott_en (English), alexott (Russian) Skype: alex.ott -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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)
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: Deamons in Clojure (was Re: Clojure vs Scala - anecdote)
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)
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)
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 wrote: > the lein-daemon plugin seems to do that > > Il giorno 07/set/2011 16.27, "Marko Kocić" 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: Clojure vs Scala - anecdote
On Wed, Sep 7, 2011 at 10:17 AM, Dennis Haupt 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: Clojure vs Scala - anecdote
-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: Deamons in Clojure (was Re: Clojure vs Scala - anecdote)
the lein-daemon plugin seems to do that Il giorno 07/set/2011 16.27, "Marko Kocić" 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
Deamons in Clojure (was Re: Clojure vs Scala - anecdote)
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
Re: Clojure vs Scala - anecdote
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 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: Clojure vs Scala - anecdote
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
Clojure vs Scala - anecdote
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
Intresting project....Ozma: extending Scala with Oz concurrency
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 ..
Hi Chad! Where are you at NRL? I'm also working there. I was dreaming of having a clojure users group there. -- myriam cej38 writes: > I am currently at the Naval Research Laboratory, Washington DC. > > Chad > > > > On Jan 18, 11:59 am, Konrad Hinsen 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
Re: HPC in scala ..
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 ..
I am currently at the Naval Research Laboratory, Washington DC. Chad On Jan 18, 11:59 am, Konrad Hinsen 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 ..
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 ..
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 ..
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 ..
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 ..
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 ..
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 ..
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: HPC in scala ..
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
HPC in scala ..
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: Reusing Clojure libraries in Java/Jythom/Scala
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 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
Reusing Clojure libraries in Java/Jythom/Scala
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 :-) DIlvan Moreira -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from 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
On Jun 18, 11:56 pm, cageface 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
For such a young language it has a big momentum. Did Scala have that after 2 years? On 18 Jun., 23:56, cageface 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
Re: scala
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 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: scala
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
scala
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: Matt Raible: "Why is Clojure better than Scala or Groovy?"
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 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 Meyer > 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"
Re: Matt Raible: "Why is Clojure better than Scala or Groovy?"
On Fri, Jan 15, 2010 at 8:22 PM, Julian 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. 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?"
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: Matt Raible: "Why is Clojure better than Scala or Groovy?"
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 : > > > On Jan 16, 6:22 am, Julian 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?"
On Jan 16, 6:22 am, Julian 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
Re: Matt Raible: "Why is Clojure better than Scala or Groovy?"
On Fri, Jan 15, 2010 at 8:22 PM, Julian wrote: > Matt Raible - Spring Expert and Java consultant posted the following > entry to Twitter: > "Why is Clojure better than Scala or Groovy?" If I had to pick just one specific feature (which may be a bad way to going about answering this, but anyway...) I would say "macros" Clojure has full-on straight-up Lisp-style code-rewriting macros, and this changes the game. Macros have a unique combination of properties for a language feature: dramatically powerful, very well understood (lots of material written about them), and yet still relatively rare among popular new languages. Many dynamic languages have meta-programming features that can be used to fill some of the gaps left by lack of macros, so I wasn't convinced of the power and practicality of Lisp-style macros until I read Paul Grahams "On Lisp". I highly recommend it. Even though it talks mostly about Common Lisp and therefore Common Lisp macros, the macro discussions are very transferable to Clojure. http://www.bookshelf.jp/texi/onlisp/onlisp.html There are other reasons to like Clojure, but that's perhaps the simplest one to name. --Chouser http://joyofclojure.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: Matt Raible: "Why is Clojure better than Scala or Groovy?"
On Fri, Jan 15, 2010 at 8:22 PM, Julian 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
Matt Raible: "Why is Clojure better than Scala or Groovy?"
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: java/scala oneliner
Nice one! :)
On Sep 18, 4:47 pm, Adrian Cuthbertson
wrote:
> If y're Sco'ish... -> 59
>
> (dotimes[i 4](println"Appy Birthdy"({2"D'r XXX"}i"To 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 wrote:
> > hiredman in the lead!
> > (dotimes[i 4](println"Happy Birthday"({2"Dear XXX"}i"To You"))) -> 63
>
> > On Fri, Sep 18, 2009 at 12:32 AM, Kevin Downey 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
> >> wrote:
> >> > Actually to be fair, here's a Clojure version that uses as little
> >> > whitespace
> >> > as the Scala and Java ones do.
> >> > (map #(str"Happy Birthday "%)(assoc (vec (replicate 4"To You"))2"Dear
> >> > XXX"))
> >> > ; -> 76 chars
>
> >> > On Fri, Sep 18, 2009 at 12:14 AM, David Nolen
> >> > 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;i<4;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 XXX"else"To
> >> >> You")}.foreach{println(_)} -> 95 chars
> >> >> Anyone have a shorter version? :)
> >> >> On Thu, Sep 17, 2009 at 11:53 PM, Wilson MacGyver
> >> >> 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; i<4; 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
If y're Sco'ish... -> 59
(dotimes[i 4](println"Appy Birthdy"({2"D'r XXX"}i"To 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 wrote:
> hiredman in the lead!
> (dotimes[i 4](println"Happy Birthday"({2"Dear XXX"}i"To You"))) -> 63
>
> On Fri, Sep 18, 2009 at 12:32 AM, Kevin Downey 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
>> wrote:
>> > Actually to be fair, here's a Clojure version that uses as little
>> > whitespace
>> > as the Scala and Java ones do.
>> > (map #(str"Happy Birthday "%)(assoc (vec (replicate 4"To You"))2"Dear
>> > XXX"))
>> > ; -> 76 chars
>> >
>> > On Fri, Sep 18, 2009 at 12:14 AM, David Nolen
>> > 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;i<4;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 XXX"else"To
>> >> You")}.foreach{println(_)} -> 95 chars
>> >> Anyone have a shorter version? :)
>> >> On Thu, Sep 17, 2009 at 11:53 PM, Wilson MacGyver
>> >> 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; i<4; 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
-~--~~~~--~~--~--~---
