Re: clojure, not the go to for data science

[Brad Blood]

Not sure how helpful this will to be to others, but just started using some 
new tools to expedite in my data normalization/ cleansing/prep: 
https://www.bisok.com/data-science-workbench/


On Sunday, 20 December 2015 15:37:11 UTC-6, Matt Revelle wrote:
>
> Hey all, just chiming in that I use Clojure for exploratory analysis, 
> prototyping, and "production." Most of my work involves social networks and 
> aside from my own libs I use: core.matrix, Loom, and gg4clj (ggplot!). I'm 
> also a big fan of core.typed type annotations and Schema for data 
> validation and coercion.
>
> I used Clojure for implementing the method described in this paper: 
> Revelle, Matt, et al. "Finding Community Topics and Membership in Graphs." 
> *Machine 
> Learning and Knowledge Discovery in Databases*. Springer International 
> Publishing, 2015. 625-640.
>
> And the code is available at:
> https://github.com/gmu-dmml-lab/senc
>
> I also have a utility library that will likely become a few separate 
> libraries in the future:
> https://github.com/mattrepl/munge
>
> It has some basic IO for common formats (Matrix Market, various graph 
> formats, R tables), helper functions (some of which are no longer needed) 
> for core.matrix and Loom, and simple text processing.
>
> My biggest pain point with using Clojure is the kludgy access to decent 
> plots (nothing on the JVM comes close to ggplot) as well as missing 
> functions for probability distributions and model fitting. I've tried 
> various substitutes (or written my own), but nothing is as polished as R.
>
> -Matt
>
> On Sunday, December 20, 2015 at 1:11:12 AM UTC-5, Christopher Small wrote:
>>
>> You're quite welcome; I was happy to add your work there :-) It's always 
>> wonderful seeing folks using Clojure for scientific research. I'm happy to 
>> add similar showcasings to the list.
>>
>> I should add that I've been wanting to make it easier for folks to submit 
>> suggestions through the site, and add interactive features, but I've been a 
>> bit busy. If anyone else is interested in contributing, I'd be grateful.
>>
>> Cheers
>>
>> Chris
>>
>>
>>
>> On Sat, Dec 19, 2015 at 11:31 AM, Boris V. Schmid  
>> wrote:
>>
>>> Just noticed one of my research paper made it to the showcase :-). 
>>> Thanks for that!
>>>
>>> As for clojure resources: I have been mainly used clojure itself, and 
>>> visualization libraries, (incanter, quil and gg4clj [to make plots in R 
>>> with ggplot2, but you can use it to run any R code]), and sometimes a stray 
>>> java library for smoothing or clustering things. The inter-op with java is 
>>> often not too bad. I use light table as an IDE.
>>>
>>> Boris
>>>
>>>
>>> On Thursday, April 9, 2015 at 3:17:44 AM UTC+2, Christopher Small wrote:

 Made some updates to http://clojure-datascience.herokuapp.com/. In 
 particular, went with the tagline "Resources for the budding Clojure Data 
 Scientist." Couldn't come up with anything else sufficiently punny and 
 appropriate.

 Again; please contribute! I'll be starting a list in the about page 
 mentioning everyone who's contributed.

 Chris


 On Tuesday, April 7, 2015 at 8:24:27 PM UTC-7, Emrehan Tüzün wrote:
>
> Clojure isn't the first tool coming into mind on data science at the 
> moment but the number of useful libraries are growing up. You can check 
> out 
> https://github.com/razum2um/awesome-clojure#science-and-data-analysis.

 -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "Clojure" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/clojure/vsjUlAWm64g/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/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.
To view this discussion 

Re: clojure, not the go to for data science

[Matt Revelle]

Hey all, just chiming in that I use Clojure for exploratory analysis, 
prototyping, and "production." Most of my work involves social networks and 
aside from my own libs I use: core.matrix, Loom, and gg4clj (ggplot!). I'm 
also a big fan of core.typed type annotations and Schema for data 
validation and coercion.

I used Clojure for implementing the method described in this paper: 
Revelle, Matt, et al. "Finding Community Topics and Membership in Graphs." 
*Machine 
Learning and Knowledge Discovery in Databases*. Springer International 
Publishing, 2015. 625-640.

And the code is available at:
https://github.com/gmu-dmml-lab/senc

I also have a utility library that will likely become a few separate 
libraries in the future:
https://github.com/mattrepl/munge

It has some basic IO for common formats (Matrix Market, various graph 
formats, R tables), helper functions (some of which are no longer needed) 
for core.matrix and Loom, and simple text processing.

My biggest pain point with using Clojure is the kludgy access to decent 
plots (nothing on the JVM comes close to ggplot) as well as missing 
functions for probability distributions and model fitting. I've tried 
various substitutes (or written my own), but nothing is as polished as R.

-Matt

On Sunday, December 20, 2015 at 1:11:12 AM UTC-5, Christopher Small wrote:
>
> You're quite welcome; I was happy to add your work there :-) It's always 
> wonderful seeing folks using Clojure for scientific research. I'm happy to 
> add similar showcasings to the list.
>
> I should add that I've been wanting to make it easier for folks to submit 
> suggestions through the site, and add interactive features, but I've been a 
> bit busy. If anyone else is interested in contributing, I'd be grateful.
>
> Cheers
>
> Chris
>
>
>
> On Sat, Dec 19, 2015 at 11:31 AM, Boris V. Schmid  > wrote:
>
>> Just noticed one of my research paper made it to the showcase :-). Thanks 
>> for that!
>>
>> As for clojure resources: I have been mainly used clojure itself, and 
>> visualization libraries, (incanter, quil and gg4clj [to make plots in R 
>> with ggplot2, but you can use it to run any R code]), and sometimes a stray 
>> java library for smoothing or clustering things. The inter-op with java is 
>> often not too bad. I use light table as an IDE.
>>
>> Boris
>>
>>
>> On Thursday, April 9, 2015 at 3:17:44 AM UTC+2, Christopher Small wrote:
>>>
>>> Made some updates to http://clojure-datascience.herokuapp.com/. In 
>>> particular, went with the tagline "Resources for the budding Clojure Data 
>>> Scientist." Couldn't come up with anything else sufficiently punny and 
>>> appropriate.
>>>
>>> Again; please contribute! I'll be starting a list in the about page 
>>> mentioning everyone who's contributed.
>>>
>>> Chris
>>>
>>>
>>> On Tuesday, April 7, 2015 at 8:24:27 PM UTC-7, Emrehan Tüzün wrote:

 Clojure isn't the first tool coming into mind on data science at the 
 moment but the number of useful libraries are growing up. You can check 
 out 
 https://github.com/razum2um/awesome-clojure#science-and-data-analysis.
>>>
>>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/clojure/vsjUlAWm64g/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/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: clojure, not the go to for data science

[Christopher Small]

You're quite welcome; I was happy to add your work there :-) It's always
wonderful seeing folks using Clojure for scientific research. I'm happy to
add similar showcasings to the list.

I should add that I've been wanting to make it easier for folks to submit
suggestions through the site, and add interactive features, but I've been a
bit busy. If anyone else is interested in contributing, I'd be grateful.

Cheers

Chris



On Sat, Dec 19, 2015 at 11:31 AM, Boris V. Schmid 
wrote:

> Just noticed one of my research paper made it to the showcase :-). Thanks
> for that!
>
> As for clojure resources: I have been mainly used clojure itself, and
> visualization libraries, (incanter, quil and gg4clj [to make plots in R
> with ggplot2, but you can use it to run any R code]), and sometimes a stray
> java library for smoothing or clustering things. The inter-op with java is
> often not too bad. I use light table as an IDE.
>
> Boris
>
>
> On Thursday, April 9, 2015 at 3:17:44 AM UTC+2, Christopher Small wrote:
>>
>> Made some updates to http://clojure-datascience.herokuapp.com/. In
>> particular, went with the tagline "Resources for the budding Clojure Data
>> Scientist." Couldn't come up with anything else sufficiently punny and
>> appropriate.
>>
>> Again; please contribute! I'll be starting a list in the about page
>> mentioning everyone who's contributed.
>>
>> Chris
>>
>>
>> On Tuesday, April 7, 2015 at 8:24:27 PM UTC-7, Emrehan Tüzün wrote:
>>>
>>> Clojure isn't the first tool coming into mind on data science at the
>>> moment but the number of useful libraries are growing up. You can check out
>>> https://github.com/razum2um/awesome-clojure#science-and-data-analysis.
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/vsjUlAWm64g/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/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: clojure, not the go to for data science

[Boris V. Schmid]

Just noticed one of my research paper made it to the showcase :-). Thanks 
for that!

As for clojure resources: I have been mainly used clojure itself, and 
visualization libraries, (incanter, quil and gg4clj [to make plots in R 
with ggplot2, but you can use it to run any R code]), and sometimes a stray 
java library for smoothing or clustering things. The inter-op with java is 
often not too bad. I use light table as an IDE.

Boris


On Thursday, April 9, 2015 at 3:17:44 AM UTC+2, Christopher Small wrote:
>
> Made some updates to http://clojure-datascience.herokuapp.com/. In 
> particular, went with the tagline "Resources for the budding Clojure Data 
> Scientist." Couldn't come up with anything else sufficiently punny and 
> appropriate.
>
> Again; please contribute! I'll be starting a list in the about page 
> mentioning everyone who's contributed.
>
> Chris
>
>
> On Tuesday, April 7, 2015 at 8:24:27 PM UTC-7, Emrehan Tüzün wrote:
>>
>> Clojure isn't the first tool coming into mind on data science at the 
>> moment but the number of useful libraries are growing up. You can check out 
>> https://github.com/razum2um/awesome-clojure#science-and-data-analysis.
>
>

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

[Christopher Small]

Made some updates to http://clojure-datascience.herokuapp.com/. In 
particular, went with the tagline "Resources for the budding Clojure Data 
Scientist." Couldn't come up with anything else sufficiently punny and 
appropriate.

Again; please contribute! I'll be starting a list in the about page 
mentioning everyone who's contributed.

Chris


On Tuesday, April 7, 2015 at 8:24:27 PM UTC-7, Emrehan Tüzün wrote:
>
> Clojure isn't the first tool coming into mind on data science at the 
> moment but the number of useful libraries are growing up. You can check out 
> https://github.com/razum2um/awesome-clojure#science-and-data-analysis.

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

clojure, not the go to for data science

[Emrehan Tüzün]

Clojure isn't the first tool coming into mind on data science at the moment but 
the number of useful libraries are growing up. You can check out 
https://github.com/razum2um/awesome-clojure#science-and-data-analysis.

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

[Gregg Reynolds]

On Apr 6, 2015 4:20 PM, "A"  wrote:
>
>
>
> Thanks for taking the initiative :) Looks good.
>
> My two cents is to prefer something instead of the word "goto" though,
which could imply an archaic coding semantic.

"into"?

Perhaps "...a growing resource to consolidate links to Clojure Data Science
topics"?
> or perhaps something that describes the goals and motivations, in the
spirit that https://www.refheap.com/about does for RefHeap could be useful
as well
>
> best,
> -A
>
>
>
>
>
> On Monday, April 6, 2015 at 12:15:02 PM UTC-7, Christopher Small wrote:
>>
>>
>> OK; Here's my humble stab at something along these lines:
http://clojure-datascience.herokuapp.com/ (source code here:
https://github.com/metasoarous/clojure-datascience).
>>
>> The data is currently just an edn file, so contributions should come in
the form of pull requests. However, we could look at moving the data to a
db or something in the future if we want a more dynamic submission process.
Right now I've seeded it with A's resource list, and not much else, so
please contribute!
>>
>> Also happy to accept other improvements here if anyone has any good
ideas. This includes discussion over the right category breakdown and
assignments, and any interface improvements which might better utilize the
data. I suggest using github issues for anything that needs discussion, or
via this thread for general direction thoughts.
>>
>> Cheers
>>
>> Chris
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
"Clojure" group.
> To unsubscribe from 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: clojure, not the go to for data science

[Daniel Slutsky]

https://github.com/joshuaeckroth/clj-ml
is a nice Weka wrapper.

It has had various forks and authors through its life.


On Monday, April 6, 2015 at 10:40:20 PM UTC+3, Goldritter wrote:
>
>  I wonder, has somebody ever tried to write something like a clojure 
> wrapper for WEKA (http://www.cs.waikato.ac.nz/ml/weka/) or added WEKA to 
> a clojure project? 
>
> I have done this for a classification problem, but it was rather inchoate 
> and only to create some libsvm and naive bayes classifier.
>
> Marcus
>
> Am 06.04.2015 um 21:15 schrieb Christopher Small:
>  
>
> OK; Here's my humble stab at something along these lines: 
> http://clojure-datascience.herokuapp.com/ (source code here: 
> https://github.com/metasoarous/clojure-datascience).
>
> The data is currently just an edn file, so contributions should come in 
> the form of pull requests. However, we could look at moving the data to a 
> db or something in the future if we want a more dynamic submission process. 
> Right now I've seeded it with A's resource list, and not much else, so 
> please contribute!
>
> Also happy to accept other improvements here if anyone has any good ideas. 
> This includes discussion over the right category breakdown and assignments, 
> and any interface improvements which might better utilize the data. I 
> suggest using github issues for anything that needs discussion, or via this 
> thread for general direction thoughts.
>
> Cheers
>
> Chris
>
>  -- 
> 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: clojure, not the go to for data science

[Christopher Small]

Hah. Yeah, I couldn't resist the pun, but I agree that it's pretty
antithetical to every bit of philosophy upon which Clojure's been built. I
can get to that eventually, but feel free to submit a pull request if I'm
lagging. And of course, more Clojuresque but equally appropriate puns would
be welcome :-)

Glad the direction looks good.

Cheers

Chris

On Mon, Apr 6, 2015 at 2:20 PM, A  wrote:

>
>
> Thanks for taking the initiative :) Looks good.
>
> My two cents is to prefer something instead of the word "goto" though,
> which could imply an archaic coding semantic.  Perhaps "...a growing
> resource to consolidate links to Clojure Data Science topics"?
> or perhaps something that describes the goals and motivations, in the
> spirit that https://www.refheap.com/about does for RefHeap could be
> useful as well
>
> best,
> -A
>
>
>
>
>
> On Monday, April 6, 2015 at 12:15:02 PM UTC-7, Christopher Small wrote:
>>
>>
>> OK; Here's my humble stab at something along these lines:
>> http://clojure-datascience.herokuapp.com/
>> 
>> (source code here: https://github.com/metasoarous/clojure-datascience).
>>
>> The data is currently just an edn file, so contributions should come in
>> the form of pull requests. However, we could look at moving the data to a
>> db or something in the future if we want a more dynamic submission process.
>> Right now I've seeded it with A's resource list, and not much else, so
>> please contribute!
>>
>> Also happy to accept other improvements here if anyone has any good
>> ideas. This includes discussion over the right category breakdown and
>> assignments, and any interface improvements which might better utilize the
>> data. I suggest using github issues for anything that needs discussion, or
>> via this thread for general direction thoughts.
>>
>> Cheers
>>
>> Chris
>>
>>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/vsjUlAWm64g/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/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: clojure, not the go to for data science

[A]

Can't recall which one, but I believe one of the aforementioned books has a 
chapter on Weka use with examples.

-A


On Monday, April 6, 2015 at 12:40:20 PM UTC-7, Goldritter wrote:
>
>  I wonder, has somebody ever tried to write something like a clojure 
> wrapper for WEKA (http://www.cs.waikato.ac.nz/ml/weka/) or added WEKA to 
> a clojure project? 
>
> I have done this for a classification problem, but it was rather inchoate 
> and only to create some libsvm and naive bayes classifier.
>
> Marcus
>
> Am 06.04.2015 um 21:15 schrieb Christopher Small:
>  
>
> OK; Here's my humble stab at something along these lines: 
> http://clojure-datascience.herokuapp.com/ (source code here: 
> https://github.com/metasoarous/clojure-datascience).
>
> The data is currently just an edn file, so contributions should come in 
> the form of pull requests. However, we could look at moving the data to a 
> db or something in the future if we want a more dynamic submission process. 
> Right now I've seeded it with A's resource list, and not much else, so 
> please contribute!
>
> Also happy to accept other improvements here if anyone has any good ideas. 
> This includes discussion over the right category breakdown and assignments, 
> and any interface improvements which might better utilize the data. I 
> suggest using github issues for anything that needs discussion, or via this 
> thread for general direction thoughts.
>
> Cheers
>
> Chris
>
>  -- 
> 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: clojure, not the go to for data science

[A]

Thanks for taking the initiative :) Looks good.

My two cents is to prefer something instead of the word "goto" though, 
which could imply an archaic coding semantic.  Perhaps "...a growing 
resource to consolidate links to Clojure Data Science topics"?
or perhaps something that describes the goals and motivations, in the 
spirit that https://www.refheap.com/about does for RefHeap could be useful 
as well

best,
-A




On Monday, April 6, 2015 at 12:15:02 PM UTC-7, Christopher Small wrote:
>
>
> OK; Here's my humble stab at something along these lines: 
> http://clojure-datascience.herokuapp.com/ 
> 
>  
> (source code here: https://github.com/metasoarous/clojure-datascience).
>
> The data is currently just an edn file, so contributions should come in 
> the form of pull requests. However, we could look at moving the data to a 
> db or something in the future if we want a more dynamic submission process. 
> Right now I've seeded it with A's resource list, and not much else, so 
> please contribute!
>
> Also happy to accept other improvements here if anyone has any good ideas. 
> This includes discussion over the right category breakdown and assignments, 
> and any interface improvements which might better utilize the data. I 
> suggest using github issues for anything that needs discussion, or via this 
> thread for general direction thoughts.
>
> Cheers
>
> Chris
>
>

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

[Marcus Lindner]

It is to note, that WEKA has at least a possibility for a clojure 
classifier ;)

(http://weka.sourceforge.net/doc.packages/clojureClassifier/weka/classifiers/clojure/ClojureClassifier.html)

Marcus

Am 06.04.2015 um 21:42 schrieb Christopher Small:


I remember seeing something like this, but if I recall correctly it 
hasn't been updated in years, so I wouldn't really bank on it for 
maintenance or dependability. Of course, its possible it could be 
resurrected.


If I recall what it was I'll share.

Chris

Sent via phone

On Apr 6, 2015 12:40 PM, "Marcus Lindner" 
> wrote:


I wonder, has somebody ever tried to write something like a
clojure wrapper for WEKA (http://www.cs.waikato.ac.nz/ml/weka/) or
added WEKA to a clojure project?

I have done this for a classification problem, but it was rather
inchoate and only to create some libsvm and naive bayes classifier.

Marcus

Am 06.04.2015 um 21:15 schrieb Christopher Small:


OK; Here's my humble stab at something along these lines:
http://clojure-datascience.herokuapp.com/ (source code here:
https://github.com/metasoarous/clojure-datascience).

The data is currently just an edn file, so contributions should
come in the form of pull requests. However, we could look at
moving the data to a db or something in the future if we want a
more dynamic submission process. Right now I've seeded it with
A's resource list, and not much else, so please contribute!

Also happy to accept other improvements here if anyone has any
good ideas. This includes discussion over the right category
breakdown and assignments, and any interface improvements which
might better utilize the data. I suggest using github issues for
anything that needs discussion, or via this thread for general
direction thoughts.

Cheers

Chris

-- 
You received this message because you are subscribed to the Google

Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com

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

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the
Google Groups "Clojure" group.
To unsubscribe from 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 a topic in
the Google Groups "Clojure" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/clojure/vsjUlAWm64g/unsubscribe.
To unsubscribe from this group and all its topics, send an email
to clojure+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/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 becaus

Re: clojure, not the go to for data science

[Christopher Small]

I remember seeing something like this, but if I recall correctly it hasn't
been updated in years, so I wouldn't really bank on it for maintenance or
dependability. Of course, its possible it could be resurrected.

If I recall what it was I'll share.

Chris

Sent via phone


On Apr 6, 2015 12:40 PM, "Marcus Lindner" <
marcus.goldritter.lind...@gmail.com> wrote:

>  I wonder, has somebody ever tried to write something like a clojure
> wrapper for WEKA (http://www.cs.waikato.ac.nz/ml/weka/) or added WEKA to
> a clojure project?
>
> I have done this for a classification problem, but it was rather inchoate
> and only to create some libsvm and naive bayes classifier.
>
> Marcus
>
> Am 06.04.2015 um 21:15 schrieb Christopher Small:
>
>
> OK; Here's my humble stab at something along these lines:
> http://clojure-datascience.herokuapp.com/ (source code here:
> https://github.com/metasoarous/clojure-datascience).
>
> The data is currently just an edn file, so contributions should come in
> the form of pull requests. However, we could look at moving the data to a
> db or something in the future if we want a more dynamic submission process.
> Right now I've seeded it with A's resource list, and not much else, so
> please contribute!
>
> Also happy to accept other improvements here if anyone has any good ideas.
> This includes discussion over the right category breakdown and assignments,
> and any interface improvements which might better utilize the data. I
> suggest using github issues for anything that needs discussion, or via this
> thread for general direction thoughts.
>
> Cheers
>
> Chris
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/vsjUlAWm64g/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/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: clojure, not the go to for data science

[Marcus Lindner]

I wonder, has somebody ever tried to write something like a clojure 
wrapper for WEKA (http://www.cs.waikato.ac.nz/ml/weka/) or added WEKA to 
a clojure project?


I have done this for a classification problem, but it was rather 
inchoate and only to create some libsvm and naive bayes classifier.


Marcus

Am 06.04.2015 um 21:15 schrieb Christopher Small:


OK; Here's my humble stab at something along these lines: 
http://clojure-datascience.herokuapp.com/ (source code here: 
https://github.com/metasoarous/clojure-datascience).


The data is currently just an edn file, so contributions should come 
in the form of pull requests. However, we could look at moving the 
data to a db or something in the future if we want a more dynamic 
submission process. Right now I've seeded it with A's resource list, 
and not much else, so please contribute!


Also happy to accept other improvements here if anyone has any good 
ideas. This includes discussion over the right category breakdown and 
assignments, and any interface improvements which might better utilize 
the data. I suggest using github issues for anything that needs 
discussion, or via this thread for general direction thoughts.


Cheers

Chris

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

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google 
Groups "Clojure" group.
To unsubscribe from 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: clojure, not the go to for data science

[Christopher Small]

OK; Here's my humble stab at something along these lines: 
http://clojure-datascience.herokuapp.com/ (source code here: 
https://github.com/metasoarous/clojure-datascience).

The data is currently just an edn file, so contributions should come in the 
form of pull requests. However, we could look at moving the data to a db or 
something in the future if we want a more dynamic submission process. Right 
now I've seeded it with A's resource list, and not much else, so please 
contribute!

Also happy to accept other improvements here if anyone has any good ideas. 
This includes discussion over the right category breakdown and assignments, 
and any interface improvements which might better utilize the data. I 
suggest using github issues for anything that needs discussion, or via this 
thread for general direction thoughts.

Cheers

Chris

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

[Christopher Small]

Yesyesyesyes! Great idea! I'm on it.

On Sun, Apr 5, 2015 at 4:15 PM, A  wrote:

> Please feel free to create something like http://www.clojure-toolbox.com/
> for data science in Clojure, that would be great.
>
> On Sunday, April 5, 2015 at 3:33:11 PM UTC-7, Sayth Renshaw wrote:
>>
>> Would be good to get that on a wiki for all so we could update and share
>> as a resourcee.
>>
>> Sayth
>>
>> On Mon, 6 Apr 2015 at 04:47 Christian Weilbach 
>> wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> >>
>>>
>>> >> http://viewer.gorilla-repl.org/view.html?source=github&user=
>>> ghubber&repo=cnc&path=rincanter.clj
>>> >>  I am not sure whether this fits the design atm. though. I also
>>> >> had a look at renjin, but I think the native plugins mandate an
>>> >> RVM integration atm.
>>> >>
>>> >
>>> > You might find http://beakernotebook.com interesting, if you
>>> > haven't seen it before. It allows several languages in the same
>>> > notebook, and has  a simple mechanism for sharing data between the
>>> > language environments. It's pretty green at the moment, but it has
>>> > some serious backing, so could be pretty useful once it's got a bit
>>> > more polish on it. I chatted a little with someone who was hoping
>>> > to implement a Clojure plugin for it, although I don't know how
>>> > they've gotten on since.
>>>
>>> This is really nice, thank you for pointing out! Effectively though
>>> this means you need to manually(!) convert data between all cells,
>>> which only works if serialization between the environments is a lot
>>> less work than processing the data and you don't want to call alien
>>> procedures e.g. in a loop. It also means that part of datasets need to
>>> be hold in memory in all runtimes at the same time. So I am not sure
>>> whether JSON synchronisation of state between runtimes is good in the
>>> long run, it feels fairly hacky and having that many runtimes already
>>> causes a big type-conversion matrix and probably many subtle
>>> incompatibilities. It is the most pragmatic approach though and
>>> probably the most successful for now.
>>>
>>> They are not opinionated about languages, while I would like to
>>> integrate data science tooling in Clojure, so it is easier to bring
>>> people on board, not to make language hopping the top goal, which is
>>> for mentioned performance reasons and from a Lisp/Clojure perspective
>>> a bit questionable imo (esp. since all these languages have to drop to
>>> C to get some performance). I also would like to have the environment
>>> written in Clojure (read: gorilla). I would be happy to integrate
>>> Python and R on the JVM, e.g. through Jython and RServe/renjin, which
>>> allows to share code much better down to direct method dispatch. Do
>>> you think integrating R cells in this way would be reasonable for you?
>>> Or just allowing plugins for new cell-types...
>>> (With RServe manual synchronisation with the RVM is still necessary
>>> btw., renjin would solve this, but needs more support for CRAN
>>> packages imho).
>>>
>>> >
>>> > I also have taken a paper I liked and implemented a quick version
>>> > of
>>> >
>>> >> SNE, which was fairly nice to do in Gorilla REPL:
>>> >>
>>> >> http://viewer.gorilla-repl.org/view.html?source=github&user=
>>> ghubber&repo=cnc&path=stochastic-neighbour-embedding.clj
>>> >>  A problem seems to be unicode support, I tried to use some math
>>> >>  symbols from the notation in the paper directly, but the viewer
>>> >> seems to have a problem with it.
>>> >>
>>> >
>>> > Not sure what the problem is there - my feeling is it should just
>>> > work, on the Gorilla side. If there's a test case you can point to
>>> > (with an expected result) I can take a look at it.
>>>
>>> The problem is just that viewer.gorilla-repl.org seems to have some
>>> encoding problems with UTF-8. See the sum sigma symbol for instance:
>>> https://github.com/ghubber/cnc/blob/master/stochastic-neighb
>>> our-embedding.clj#L72
>>> which is corrupted in the viewer. I hoped that was easy to fix.
>>>
>>>
>>> Christian
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v1
>>>
>>> iQEcBAEBAgAGBQJVIYNTAAoJEKel+aujRZMk5wsIAIl/CoX0E7u6lSJIHQfWI8U5
>>> HZWUPjHJie+sbIt+G4qm8SozAbmPEc6mRSDC3kP1v2JhoJv4y1j6klWmHH9Xm3dj
>>> eqxNgVTNClk5ZUUcAFhcy2gUCc9RP6AJF27TnSO+ArG4qApueU+s297uHTAfGefk
>>> hj+AbzCGoQOgvw1F6sUOTQ4KV6Z51/pYsjIgxwPC5vvzIKgv+qiKXMWLow1mM9uu
>>> tG4h/HDSxdjCWdVm4sCuipi5tJJmdYEuYHjtFiMVbpVA5YZT3KleL4K6Gn9nMu7u
>>> vrw2YlZyE9mlKPbv4GRS3ANnVv45+e0yLuMMXV1OdlxwKqmvKosmk7k4K6jR8Pc=
>>> =5QnK
>>> -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 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://group

Re: clojure, not the go to for data science

[A]

Please feel free to create something like http://www.clojure-toolbox.com/ 
for data science in Clojure, that would be great.

On Sunday, April 5, 2015 at 3:33:11 PM UTC-7, Sayth Renshaw wrote:
>
> Would be good to get that on a wiki for all so we could update and share 
> as a resourcee.
>
> Sayth
>
> On Mon, 6 Apr 2015 at 04:47 Christian Weilbach  > wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> >>
>>
>> >> http://viewer.gorilla-repl.org/view.html?source=github&;
>> user=ghubber&repo=cnc&path=rincanter.clj
>> >>  I am not sure whether this fits the design atm. though. I also
>> >> had a look at renjin, but I think the native plugins mandate an
>> >> RVM integration atm.
>> >>
>> >
>> > You might find http://beakernotebook.com interesting, if you
>> > haven't seen it before. It allows several languages in the same
>> > notebook, and has  a simple mechanism for sharing data between the
>> > language environments. It's pretty green at the moment, but it has
>> > some serious backing, so could be pretty useful once it's got a bit
>> > more polish on it. I chatted a little with someone who was hoping
>> > to implement a Clojure plugin for it, although I don't know how
>> > they've gotten on since.
>>
>> This is really nice, thank you for pointing out! Effectively though
>> this means you need to manually(!) convert data between all cells,
>> which only works if serialization between the environments is a lot
>> less work than processing the data and you don't want to call alien
>> procedures e.g. in a loop. It also means that part of datasets need to
>> be hold in memory in all runtimes at the same time. So I am not sure
>> whether JSON synchronisation of state between runtimes is good in the
>> long run, it feels fairly hacky and having that many runtimes already
>> causes a big type-conversion matrix and probably many subtle
>> incompatibilities. It is the most pragmatic approach though and
>> probably the most successful for now.
>>
>> They are not opinionated about languages, while I would like to
>> integrate data science tooling in Clojure, so it is easier to bring
>> people on board, not to make language hopping the top goal, which is
>> for mentioned performance reasons and from a Lisp/Clojure perspective
>> a bit questionable imo (esp. since all these languages have to drop to
>> C to get some performance). I also would like to have the environment
>> written in Clojure (read: gorilla). I would be happy to integrate
>> Python and R on the JVM, e.g. through Jython and RServe/renjin, which
>> allows to share code much better down to direct method dispatch. Do
>> you think integrating R cells in this way would be reasonable for you?
>> Or just allowing plugins for new cell-types...
>> (With RServe manual synchronisation with the RVM is still necessary
>> btw., renjin would solve this, but needs more support for CRAN
>> packages imho).
>>
>> >
>> > I also have taken a paper I liked and implemented a quick version
>> > of
>> >
>> >> SNE, which was fairly nice to do in Gorilla REPL:
>> >>
>> >> http://viewer.gorilla-repl.org/view.html?source=github&;
>> user=ghubber&repo=cnc&path=stochastic-neighbour-embedding.clj
>> >>  A problem seems to be unicode support, I tried to use some math
>> >>  symbols from the notation in the paper directly, but the viewer
>> >> seems to have a problem with it.
>> >>
>> >
>> > Not sure what the problem is there - my feeling is it should just
>> > work, on the Gorilla side. If there's a test case you can point to
>> > (with an expected result) I can take a look at it.
>>
>> The problem is just that viewer.gorilla-repl.org seems to have some
>> encoding problems with UTF-8. See the sum sigma symbol for instance:
>> https://github.com/ghubber/cnc/blob/master/stochastic-
>> neighbour-embedding.clj#L72
>> which is corrupted in the viewer. I hoped that was easy to fix.
>>
>>
>> Christian
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1
>>
>> iQEcBAEBAgAGBQJVIYNTAAoJEKel+aujRZMk5wsIAIl/CoX0E7u6lSJIHQfWI8U5
>> HZWUPjHJie+sbIt+G4qm8SozAbmPEc6mRSDC3kP1v2JhoJv4y1j6klWmHH9Xm3dj
>> eqxNgVTNClk5ZUUcAFhcy2gUCc9RP6AJF27TnSO+ArG4qApueU+s297uHTAfGefk
>> hj+AbzCGoQOgvw1F6sUOTQ4KV6Z51/pYsjIgxwPC5vvzIKgv+qiKXMWLow1mM9uu
>> tG4h/HDSxdjCWdVm4sCuipi5tJJmdYEuYHjtFiMVbpVA5YZT3KleL4K6Gn9nMu7u
>> vrw2YlZyE9mlKPbv4GRS3ANnVv45+e0yLuMMXV1OdlxwKqmvKosmk7k4K6jR8Pc=
>> =5QnK
>> -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 clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Clojure" group.
>> To unsubscribe from this topi

Re: clojure, not the go to for data science

[Sayth Renshaw]

Would be good to get that on a wiki for all so we could update and share as
a resourcee.

Sayth

On Mon, 6 Apr 2015 at 04:47 Christian Weilbach 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> >>
>
> >> http://viewer.gorilla-repl.org/view.html?source=github&;
> user=ghubber&repo=cnc&path=rincanter.clj
> >>  I am not sure whether this fits the design atm. though. I also
> >> had a look at renjin, but I think the native plugins mandate an
> >> RVM integration atm.
> >>
> >
> > You might find http://beakernotebook.com interesting, if you
> > haven't seen it before. It allows several languages in the same
> > notebook, and has  a simple mechanism for sharing data between the
> > language environments. It's pretty green at the moment, but it has
> > some serious backing, so could be pretty useful once it's got a bit
> > more polish on it. I chatted a little with someone who was hoping
> > to implement a Clojure plugin for it, although I don't know how
> > they've gotten on since.
>
> This is really nice, thank you for pointing out! Effectively though
> this means you need to manually(!) convert data between all cells,
> which only works if serialization between the environments is a lot
> less work than processing the data and you don't want to call alien
> procedures e.g. in a loop. It also means that part of datasets need to
> be hold in memory in all runtimes at the same time. So I am not sure
> whether JSON synchronisation of state between runtimes is good in the
> long run, it feels fairly hacky and having that many runtimes already
> causes a big type-conversion matrix and probably many subtle
> incompatibilities. It is the most pragmatic approach though and
> probably the most successful for now.
>
> They are not opinionated about languages, while I would like to
> integrate data science tooling in Clojure, so it is easier to bring
> people on board, not to make language hopping the top goal, which is
> for mentioned performance reasons and from a Lisp/Clojure perspective
> a bit questionable imo (esp. since all these languages have to drop to
> C to get some performance). I also would like to have the environment
> written in Clojure (read: gorilla). I would be happy to integrate
> Python and R on the JVM, e.g. through Jython and RServe/renjin, which
> allows to share code much better down to direct method dispatch. Do
> you think integrating R cells in this way would be reasonable for you?
> Or just allowing plugins for new cell-types...
> (With RServe manual synchronisation with the RVM is still necessary
> btw., renjin would solve this, but needs more support for CRAN
> packages imho).
>
> >
> > I also have taken a paper I liked and implemented a quick version
> > of
> >
> >> SNE, which was fairly nice to do in Gorilla REPL:
> >>
> >> http://viewer.gorilla-repl.org/view.html?source=github&;
> user=ghubber&repo=cnc&path=stochastic-neighbour-embedding.clj
> >>  A problem seems to be unicode support, I tried to use some math
> >>  symbols from the notation in the paper directly, but the viewer
> >> seems to have a problem with it.
> >>
> >
> > Not sure what the problem is there - my feeling is it should just
> > work, on the Gorilla side. If there's a test case you can point to
> > (with an expected result) I can take a look at it.
>
> The problem is just that viewer.gorilla-repl.org seems to have some
> encoding problems with UTF-8. See the sum sigma symbol for instance:
> https://github.com/ghubber/cnc/blob/master/stochastic-
> neighbour-embedding.clj#L72
> which is corrupted in the viewer. I hoped that was easy to fix.
>
>
> Christian
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJVIYNTAAoJEKel+aujRZMk5wsIAIl/CoX0E7u6lSJIHQfWI8U5
> HZWUPjHJie+sbIt+G4qm8SozAbmPEc6mRSDC3kP1v2JhoJv4y1j6klWmHH9Xm3dj
> eqxNgVTNClk5ZUUcAFhcy2gUCc9RP6AJF27TnSO+ArG4qApueU+s297uHTAfGefk
> hj+AbzCGoQOgvw1F6sUOTQ4KV6Z51/pYsjIgxwPC5vvzIKgv+qiKXMWLow1mM9uu
> tG4h/HDSxdjCWdVm4sCuipi5tJJmdYEuYHjtFiMVbpVA5YZT3KleL4K6Gn9nMu7u
> vrw2YlZyE9mlKPbv4GRS3ANnVv45+e0yLuMMXV1OdlxwKqmvKosmk7k4K6jR8Pc=
> =5QnK
> -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
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/clojure/vsjUlAWm64g/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscrib

Re: clojure, not the go to for data science

[Christian Weilbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

>> 

>> http://viewer.gorilla-repl.org/view.html?source=github&user=ghubber&repo=cnc&path=rincanter.clj
>>  I am not sure whether this fits the design atm. though. I also
>> had a look at renjin, but I think the native plugins mandate an
>> RVM integration atm.
>> 
> 
> You might find http://beakernotebook.com interesting, if you
> haven't seen it before. It allows several languages in the same
> notebook, and has  a simple mechanism for sharing data between the
> language environments. It's pretty green at the moment, but it has
> some serious backing, so could be pretty useful once it's got a bit
> more polish on it. I chatted a little with someone who was hoping
> to implement a Clojure plugin for it, although I don't know how
> they've gotten on since.

This is really nice, thank you for pointing out! Effectively though
this means you need to manually(!) convert data between all cells,
which only works if serialization between the environments is a lot
less work than processing the data and you don't want to call alien
procedures e.g. in a loop. It also means that part of datasets need to
be hold in memory in all runtimes at the same time. So I am not sure
whether JSON synchronisation of state between runtimes is good in the
long run, it feels fairly hacky and having that many runtimes already
causes a big type-conversion matrix and probably many subtle
incompatibilities. It is the most pragmatic approach though and
probably the most successful for now.

They are not opinionated about languages, while I would like to
integrate data science tooling in Clojure, so it is easier to bring
people on board, not to make language hopping the top goal, which is
for mentioned performance reasons and from a Lisp/Clojure perspective
a bit questionable imo (esp. since all these languages have to drop to
C to get some performance). I also would like to have the environment
written in Clojure (read: gorilla). I would be happy to integrate
Python and R on the JVM, e.g. through Jython and RServe/renjin, which
allows to share code much better down to direct method dispatch. Do
you think integrating R cells in this way would be reasonable for you?
Or just allowing plugins for new cell-types...
(With RServe manual synchronisation with the RVM is still necessary
btw., renjin would solve this, but needs more support for CRAN
packages imho).

> 
> I also have taken a paper I liked and implemented a quick version
> of
> 
>> SNE, which was fairly nice to do in Gorilla REPL:
>> 
>> http://viewer.gorilla-repl.org/view.html?source=github&user=ghubber&repo=cnc&path=stochastic-neighbour-embedding.clj
>>  A problem seems to be unicode support, I tried to use some math
>>  symbols from the notation in the paper directly, but the viewer
>> seems to have a problem with it.
>> 
> 
> Not sure what the problem is there - my feeling is it should just
> work, on the Gorilla side. If there's a test case you can point to
> (with an expected result) I can take a look at it.

The problem is just that viewer.gorilla-repl.org seems to have some
encoding problems with UTF-8. See the sum sigma symbol for instance:
https://github.com/ghubber/cnc/blob/master/stochastic-neighbour-embedding.clj#L72
which is corrupted in the viewer. I hoped that was easy to fix.


Christian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVIYNTAAoJEKel+aujRZMk5wsIAIl/CoX0E7u6lSJIHQfWI8U5
HZWUPjHJie+sbIt+G4qm8SozAbmPEc6mRSDC3kP1v2JhoJv4y1j6klWmHH9Xm3dj
eqxNgVTNClk5ZUUcAFhcy2gUCc9RP6AJF27TnSO+ArG4qApueU+s297uHTAfGefk
hj+AbzCGoQOgvw1F6sUOTQ4KV6Z51/pYsjIgxwPC5vvzIKgv+qiKXMWLow1mM9uu
tG4h/HDSxdjCWdVm4sCuipi5tJJmdYEuYHjtFiMVbpVA5YZT3KleL4K6Gn9nMu7u
vrw2YlZyE9mlKPbv4GRS3ANnVv45+e0yLuMMXV1OdlxwKqmvKosmk7k4K6jR8Pc=
=5QnK
-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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: clojure, not the go to for data science

[A]

>> Thanks, that is an awesome list of resources. 
kudos to the respective authors. 
-A

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

[Rafael de F. Ferreira]

Thanks, that is an awesome list of resources.

On Sun, Apr 5, 2015, 4:20 AM A  wrote:

> Caveats... there is a lot to explore, things are continually changing and
> evolving, I haven't made an exhaustive search, but here is what is quickly
> google-able... YMMV
>
> # Books
> - Eric Rochester: https://www.packtpub.com/big-data-and-business-
> intelligence/mastering-clojure-data-analysis and
> http://www.ericrochester.com/pages/announcements/clj-data-
> analysis/index.html
> - Akhil Wali:  https://www.packtpub.com/big-data-and-business-
> intelligence/clojure-machine-learning
>
> # Youtube videos
> - Jony Epsilon: http://gorilla-repl.org/
> - Edmund Jackson: "Clojure Data Science" https://www.youtube.com/watch?
> v=RVmY2lQ4DHE
> - Mike Anderson: "Enter the Matrix" https://www.youtube.com/watch?
> v=_h9TLJtjSJo and "Machine Learning Live" https://www.youtube.com/watch?
> v=QJ1qgCr09j8
> - Aysylu Greenberg: "Loom and Graphs in Clojure"
> https://www.youtube.com/watch?v=wEEutxTYQQU
> - Cascalog: https://www.youtube.com/results?search_query=cascalog
>
> # Clojure (wrappers)
> - clj-vw: https://github.com/engagor/clj-vw
> - deeplearning4j.org e.g. [org.deeplearning4j/dl4j-spark
> "0.0.3.3.2.alpha1"]
> - core.matrix (https://github.com/mikera/core.matrix)
> - Raynes/Conch (shell out to the executable of your choice.)
> https://github.com/Raynes/conch
> - loom (https://github.com/aysylu/loom)
> - https://github.com/marcliberatore/mallet-lda
> - java interop
>
> I recommend settling on a particular topic/method/problem you are
> interested in solving and then searching specifically on that, craft a few
> functions, try some approaches, existing tools, etc...
>
> best,
> -A
>
>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: clojure, not the go to for data science

[A]

Caveats... there is a lot to explore, things are continually changing and 
evolving, I haven't made an exhaustive search, but here is what is quickly 
google-able... YMMV

# Books
- Eric Rochester: 
https://www.packtpub.com/big-data-and-business-intelligence/mastering-clojure-data-analysis
 
and  
http://www.ericrochester.com/pages/announcements/clj-data-analysis/index.html
- Akhil Wali:  
https://www.packtpub.com/big-data-and-business-intelligence/clojure-machine-learning
   


# Youtube videos
- Jony Epsilon: http://gorilla-repl.org/
- Edmund Jackson: "Clojure Data Science" 
https://www.youtube.com/watch?v=RVmY2lQ4DHE
- Mike Anderson: "Enter the Matrix" 
https://www.youtube.com/watch?v=_h9TLJtjSJo and "Machine Learning Live" 
https://www.youtube.com/watch?v=QJ1qgCr09j8
- Aysylu Greenberg: "Loom and Graphs in Clojure" 
https://www.youtube.com/watch?v=wEEutxTYQQU
- Cascalog: https://www.youtube.com/results?search_query=cascalog

# Clojure (wrappers)
- clj-vw: https://github.com/engagor/clj-vw
- deeplearning4j.org e.g. [org.deeplearning4j/dl4j-spark 
"0.0.3.3.2.alpha1"] 
- core.matrix (https://github.com/mikera/core.matrix)
- Raynes/Conch (shell out to the executable of your choice.) 
https://github.com/Raynes/conch
- loom (https://github.com/aysylu/loom)
- https://github.com/marcliberatore/mallet-lda
- java interop

I recommend settling on a particular topic/method/problem you are 
interested in solving and then searching specifically on that, craft a few 
functions, try some approaches, existing tools, etc... 

best,
-A



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

[Rafael de F. Ferreira]

I would be awesome if you could provide links to some of the books, YouTube
videos, and clojure wrappers that you'd recommend.

On Thursday, April 2, 2015, A  wrote:

>
> Clojure is an Amazing tool for data science.  If people are slow to
> realize this, that is their disadvantage.
>
> The premise that "Clojure hasn't developed as a go to for data science"
> simply doesn't ring true to me at all.  There are numerous examples of
> Clojure use for data science, there are books about it, there are youtube
> videos about it, there are practitioners, there is Incanter, there are
> Transducers, there are Notebooks (Gorilla is awesome), there are Java
> libraries, there are wrapper Clojure libraries, there are a lot of useful
> tools.
>
> Clojure is my "go to for data science" and I often use it either directly,
> or to manage runs using fast tools (like vw), or to prepare SQL-izations of
> data etc... (Btw, your SQL often runs as easily in
> Postgres/Redshift/Hive/Spark with minimal changes if any if you need to
> scale etc... If you treat your SQL the way you treat HTML, let your customs
> functions write it, you get a lot of analytic power that is not tied to any
> particular database).  There is Clojurescript for visualization... There is
> so much that I am certain I am forgetting to mention some of it.
>
> Also, Big +1 for emacs use (cider is awesome! I rarely want to touch a
> mouse... )
>
> Thanks for an amazing, innovative Emacs and Clojure commuity!!
>
> -Avram
>
> The sky is the limit.
>
>
>
>
>
>
>
> On Sunday, March 29, 2015 at 2:55:34 AM UTC-7, Sayth Renshaw wrote:
>>
>> Hi
>>
>> I last learned clojure in 1.2. Just curious why Clojure hasn't developed
>> as a go to for data science?
>>
>> It never seems to get a mention R,Python and now Julia get the attention.
>> By design it would appear that Clojure would be a good fit. Is it a lack of
>> libraries, ease of install, no good default environment  (R Rstudio,
>> IPython ) where as you would need to use emacs with clojure, or is there
>> just a better default use of Clojure?
>>
>> Sayth
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> 
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>


-- 
--
Rafael de F. Ferreira.
http://www.rafaelferreira.net/

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

[Christopher Small]

Sure. I wasn't under the impression you were knocking it. On the contrary,
I appreciate the reflection. As someone who uses (and loves) Clojure for
data science, I'm keen to consider what can be done to broaden its adoption
in this area.

Chris

Sent via phone

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

[Jeff Heon]

RStudio is really nice! I'm taking some Coursera classes using R, and 
RStudio is great. Maybe that's because I'm an IDE kind of guy: using 
Cursive for Clojure, PyCharm for Python, RStudio for R, etc.

On Thursday, April 2, 2015 at 5:54:34 PM UTC-4, Jony Hudson wrote:
>
> I think the credit here has to go to RStudio for doing such a good job of 
> making an easy to install complete development environment. I'd say just 
> comparing base Clojure to base R, it's a wash. Install java and either 
> download the Clojure jar, or the leiningen script, and you're good to go. 
> Similar effort with R, just install the R distribution. Either way you 
> don't get much more than a REPL prompt.
>
> It is possible to get a working, fully-featured Clojure development 
> environment going without *much* more difficulty than RStudio. In fact, I 
> did precisely cover install and setup in two easy videos :-) See 
> http://gorilla-repl.org/videos.html , bottom of the page.
>
> I would still say that RStudio deserves kudos here though, as they've made 
> it really easy to get going. And I think there is value in this, as my 
> experience with getting inexperienced programmers started is that they 
> easily get stuck on the little set up details. I'd like to make Gorilla 
> REPL easier to get started with, but haven't figured out how to do that in 
> a way that's compatible with the amount of time I have to work on it!
>
>
> Jony
>
> On Thursday, 2 April 2015 22:14:08 UTC+1, Sayth Renshaw wrote:
>  
>
>> You appear to have vastly misinterpreted my intention regards Emacs. My 
>> mention of Emacs (I use emacs with prelude) was not based on my usage but 
>> as a perception of those who might be attracted to Clojure For Purely Data 
>> Science And wishes to get installed and moving quickly.
>>
>> R offers to get you installed in 2 quick point and click installs and 
>> gives you the language and R studio .
>>
>> What would that person think when looking at Clojure?  If they saw emacs 
>> would they know about prelude, how to configure it with so many 
>> configuration options? 
>>
>> If someone out organisation was running a data science course would they 
>> choose R because they can cover install and setup in 2 easy videos compared 
>> to current Clojure options which may be less clear.
>>
>> Sometimes often times onboarding people to a new language is about as 
>> much as ease of install or at least making a default set of optiins clear. 
>>
>> Could the default set abs best options be made easier to new comers?
>>
>> Sayth
>>
>> Emacs can use the native windowing system on every major platform. It 
>> still *looks* like a terminal app, but doesn't have to be one.
>>
>> Pretty much everything you are saying here doesn't apply to Emacs at all, 
>> and you would know it's all false if you knew anything about Emacs.
>>
>> On Wednesday, April 1, 2015 at 4:55:08 PM UTC-7, Fluid Dynamics wrote:
>>
>> On Tuesday, March 31, 2015 at 8:45:31 AM UTC-4, Phillip Lord wrote:
>>
>>  The benefit is that Emacs is that its not constantly changing, and it 
>> gives you some stability over the years. I like latex, for instance, for 
>> the same reason. I can still access a 10 year old document and use it.
>>  
>>   First of all, there are other posts in this thread complaining about 
>> constantly changing stuff breaking things! One such post is by Colin Yates.
>>
>> Second, to the extent that it isn't changing, it is legacy. Which helps 
>> to explain the Wordperfect for DOS style of UI, which is dependent on vast 
>> numbers of complex key-combinations being memorized by the user, instead of 
>> a just-sit-down-and-start-using-it UI like everything originating after, 
>> say, 1995 or so has tended to have. Of course, the result is that 
>> Wordperfect (and emacs) seemed to require a great deal of specialized 
>> training just to accomplish even the most basic tasks, whereas with modern 
>> interfaces the way to do such basic tasks (save, open, copy and paste, move 
>> around, select, etc.) tends to be obvious and special training can focus 
>> exclusively on doing advanced things (scripting, complicated Photoshop 
>> filters and tricks, things like those).
>>
>> Legacy also, obviously, tends to present problems in other areas besides 
>> UI-boneheadedness:
>>
>> * I18n and l10n
>> * Compatibility, with modern hardware and with modern operating systems, 
>> though that can be alleviated by people porting the code
>> * Boneheaded internal limits, along the same general lines as "640K ought 
>> to be enough for anybody". It may be unable to use more than a small 
>> fraction of what modern hardware can offer it in the way of memory, 
>> storage, cores, ...
>> * Accessibility. Interposing a terminal emulator between the app and 
>> screen reading software might cause problems, though on the other hand a 
>> text mode app may ultimately have advantages in that area too. On the other 
>> hand, it may not play well with accessibility tools
>>   that 

Re: clojure, not the go to for data science

[Sayth Renshaw]

Agree Chris, I think Clojure has a lot of advantage. I never intended to
knock Clojure just question as a person returning to look at the project at
the potential roadblocks whether real or perceived that were potentially
limiting its adoption.

Sayth

On Fri, 3 Apr 2015 at 10:07 Christopher Small  wrote:

>
> Editors as they apply to data science adoption is certainly relevant,
> particularly as relates to ease of adoption for beginners. It's easy for an
> experienced developer to dismiss the difference of ease in adopting
> something like RStudio vs R by itself; Those with experience already have
> workflows they're used to (vim/emacs + tmux / whatever), but getting to
> that point is not trivial. And there are certainly those who come to R and
> python looking to do data science who have little programming experience.
> I've seen a lot of this among biologists in particular.
>
> The Gorilla REPL does certainly take us a good way there, for those
> interested in the notebook model. But the RStudio/MATLAB workbench model is
> also something worth considering. Some easy to install packages gluing
> together Incanter, core.matrix, Gorilla REPL, Quil, and perhaps
> tools/interfaces that don't exist yet, with excellent documentation and
> guidance, could make a huge difference in adoption.
>
> As for broader thoughts coming to mind: My experience has been that R is
> great for exploration, but is terrible for scaling into bigger systems from
> an architectural standpoint (but other's might disagree with me). It can
> also feel rather cumbersome when developing algorithms. Python feels much
> better along these lines, but also has its own warts as a language
> (concurrency for example). It's my opinion that the shortcomings of Clojure
> for data science are much more easily addressable than those of R or
> python, as they're less about the language itself than things missing from
> ecosystem which can be added. And I think the value of a language which
> scales from exploration to production naturally is not something to be
> undervalued.
>
> Chris
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/vsjUlAWm64g/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/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: clojure, not the go to for data science

[Christopher Small]

Editors as they apply to data science adoption is certainly relevant, 
particularly as relates to ease of adoption for beginners. It's easy for an 
experienced developer to dismiss the difference of ease in adopting 
something like RStudio vs R by itself; Those with experience already have 
workflows they're used to (vim/emacs + tmux / whatever), but getting to 
that point is not trivial. And there are certainly those who come to R and 
python looking to do data science who have little programming experience. 
I've seen a lot of this among biologists in particular.

The Gorilla REPL does certainly take us a good way there, for those 
interested in the notebook model. But the RStudio/MATLAB workbench model is 
also something worth considering. Some easy to install packages gluing 
together Incanter, core.matrix, Gorilla REPL, Quil, and perhaps 
tools/interfaces that don't exist yet, with excellent documentation and 
guidance, could make a huge difference in adoption.

As for broader thoughts coming to mind: My experience has been that R is 
great for exploration, but is terrible for scaling into bigger systems from 
an architectural standpoint (but other's might disagree with me). It can 
also feel rather cumbersome when developing algorithms. Python feels much 
better along these lines, but also has its own warts as a language 
(concurrency for example). It's my opinion that the shortcomings of Clojure 
for data science are much more easily addressable than those of R or 
python, as they're less about the language itself than things missing from 
ecosystem which can be added. And I think the value of a language which 
scales from exploration to production naturally is not something to be 
undervalued.

Chris

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

[Fluid Dynamics]

On Thursday, April 2, 2015 at 5:54:34 PM UTC-4, Jony Hudson wrote:
>
> I think the credit here has to go to RStudio for doing such a good job of 
> making an easy to install complete development environment. I'd say just 
> comparing base Clojure to base R, it's a wash. Install java and either 
> download the Clojure jar, or the leiningen script, and you're good to go. 
> Similar effort with R, just install the R distribution. Either way you 
> don't get much more than a REPL prompt.
>
> It is possible to get a working, fully-featured Clojure development 
> environment going without *much* more difficulty than RStudio.
>

Umm, it's as easy as downloading the Counterclockwise Standalone binary and 
running it. So probably exactly equal to "just install the R distribution".

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

[Sayth Renshaw]

For python notebooks there is an ein plugin which integrates notebooks in
emacs. Giving features of both.

Doesn't address Rstudio ease but it may allow greater features for gorilla
for relatively smaller effort.

On Fri, 3 Apr 2015 8:54 AM Jony Hudson

wrote:

I think the credit here has to go to RStudio for doing such a good job of
making an easy to install complete development environment. I'd say just
comparing base Clojure to base R, it's a wash. Install java and either
download the Clojure jar, or the leiningen script, and you're good to go.
Similar effort with R, just install the R distribution. Either way you
don't get much more than a REPL prompt.

It is possible to get a working, fully-featured Clojure development
environment going without *much* more difficulty than RStudio. In fact, I
did precisely cover install and setup in two easy videos :-) See
http://gorilla-repl.org/videos.html , bottom of the page.

I would still say that RStudio deserves kudos here though, as they've made
it really easy to get going. And I think there is value in this, as my
experience with getting inexperienced programmers started is that they
easily get stuck on the little set up details. I'd like to make Gorilla
REPL easier to get started with, but haven't figured out how to do that in
a way that's compatible with the amount of time I have to work on it!

Jony

On Thursday, 2 April 2015 22:14:08 UTC+1, Sayth Renshaw wrote:



You appear to have vastly misinterpreted my intention regards Emacs. My
mention of Emacs (I use emacs with prelude) was not based on my usage but
as a perception of those who might be attracted to Clojure For Purely Data
Science And wishes to get installed and moving quickly.

R offers to get you installed in 2 quick point and click installs and gives
you the language and R studio .

What would that person think when looking at Clojure?  If they saw emacs
would they know about prelude, how to configure it with so many
configuration options?

If someone out organisation was running a data science course would they
choose R because they can cover install and setup in 2 easy videos compared
to current Clojure options which may be less clear.

Sometimes often times onboarding people to a new language is about as much
as ease of install or at least making a default set of optiins clear.

Could the default set abs best options be made easier to new comers?

Sayth

 Emacs can use the native windowing system on every major platform. It
still *looks* like a terminal app, but doesn't have to be one.

Pretty much everything you are saying here doesn't apply to Emacs at all,
and you would know it's all false if you knew anything about Emacs.

On Wednesday, April 1, 2015 at 4:55:08 PM UTC-7, Fluid Dynamics wrote:


  On Tuesday, March 31, 2015 at 8:45:31 AM UTC-4, Phillip Lord wrote:


  The benefit is that Emacs is that its not constantly changing, and it
gives you some stability over the years. I like latex, for instance, for
the same reason. I can still access a 10 year old document and use it.


  First of all, there are other posts in this thread complaining about
constantly changing stuff breaking things! One such post is by Colin Yates.

Second, to the extent that it isn't changing, it is legacy. Which helps to
explain the Wordperfect for DOS style of UI, which is dependent on vast
numbers of complex key-combinations being memorized by the user, instead of
a just-sit-down-and-start-using-it UI like everything originating after,
say, 1995 or so has tended to have. Of course, the result is that
Wordperfect (and emacs) seemed to require a great deal of specialized
training just to accomplish even the most basic tasks, whereas with modern
interfaces the way to do such basic tasks (save, open, copy and paste, move
around, select, etc.) tends to be obvious and special training can focus
exclusively on doing advanced things (scripting, complicated Photoshop
filters and tricks, things like those).

Legacy also, obviously, tends to present problems in other areas besides
UI-boneheadedness:

* I18n and l10n
* Compatibility, with modern hardware and with modern operating systems,
though that can be alleviated by people porting the code
* Boneheaded internal limits, along the same general lines as "640K ought
to be enough for anybody". It may be unable to use more than a small
fraction of what modern hardware can offer it in the way of memory,
storage, cores, ...
* Accessibility. Interposing a terminal emulator between the app and screen
reading software might cause problems, though on the other hand a text mode
app may ultimately have advantages in that area too. On the other hand, it
may not play well with accessibility tools
  that rely on standard UI conventions. Anything that responds to some
voice command by generating control-V keystrokes to paste, or that relies
on the presence of normal menus and/or mouse support is going to blow up
spectacularly when used with 1980s-vintage Unix
  (or MS-DOS) software, 

Re: clojure, not the go to for data science

[Jony Hudson]

I think the credit here has to go to RStudio for doing such a good job of 
making an easy to install complete development environment. I'd say just 
comparing base Clojure to base R, it's a wash. Install java and either 
download the Clojure jar, or the leiningen script, and you're good to go. 
Similar effort with R, just install the R distribution. Either way you 
don't get much more than a REPL prompt.

It is possible to get a working, fully-featured Clojure development 
environment going without *much* more difficulty than RStudio. In fact, I 
did precisely cover install and setup in two easy videos :-) 
See http://gorilla-repl.org/videos.html , bottom of the page.

I would still say that RStudio deserves kudos here though, as they've made 
it really easy to get going. And I think there is value in this, as my 
experience with getting inexperienced programmers started is that they 
easily get stuck on the little set up details. I'd like to make Gorilla 
REPL easier to get started with, but haven't figured out how to do that in 
a way that's compatible with the amount of time I have to work on it!


Jony

On Thursday, 2 April 2015 22:14:08 UTC+1, Sayth Renshaw wrote:
 

> You appear to have vastly misinterpreted my intention regards Emacs. My 
> mention of Emacs (I use emacs with prelude) was not based on my usage but 
> as a perception of those who might be attracted to Clojure For Purely Data 
> Science And wishes to get installed and moving quickly.
>
> R offers to get you installed in 2 quick point and click installs and 
> gives you the language and R studio .
>
> What would that person think when looking at Clojure?  If they saw emacs 
> would they know about prelude, how to configure it with so many 
> configuration options? 
>
> If someone out organisation was running a data science course would they 
> choose R because they can cover install and setup in 2 easy videos compared 
> to current Clojure options which may be less clear.
>
> Sometimes often times onboarding people to a new language is about as much 
> as ease of install or at least making a default set of optiins clear. 
>
> Could the default set abs best options be made easier to new comers?
>
> Sayth
>
> Emacs can use the native windowing system on every major platform. It 
> still *looks* like a terminal app, but doesn't have to be one.
>
> Pretty much everything you are saying here doesn't apply to Emacs at all, 
> and you would know it's all false if you knew anything about Emacs.
>
> On Wednesday, April 1, 2015 at 4:55:08 PM UTC-7, Fluid Dynamics wrote:
>
> On Tuesday, March 31, 2015 at 8:45:31 AM UTC-4, Phillip Lord wrote:
>
>  The benefit is that Emacs is that its not constantly changing, and it 
> gives you some stability over the years. I like latex, for instance, for 
> the same reason. I can still access a 10 year old document and use it.
>  
>   First of all, there are other posts in this thread complaining about 
> constantly changing stuff breaking things! One such post is by Colin Yates.
>
> Second, to the extent that it isn't changing, it is legacy. Which helps to 
> explain the Wordperfect for DOS style of UI, which is dependent on vast 
> numbers of complex key-combinations being memorized by the user, instead of 
> a just-sit-down-and-start-using-it UI like everything originating after, 
> say, 1995 or so has tended to have. Of course, the result is that 
> Wordperfect (and emacs) seemed to require a great deal of specialized 
> training just to accomplish even the most basic tasks, whereas with modern 
> interfaces the way to do such basic tasks (save, open, copy and paste, move 
> around, select, etc.) tends to be obvious and special training can focus 
> exclusively on doing advanced things (scripting, complicated Photoshop 
> filters and tricks, things like those).
>
> Legacy also, obviously, tends to present problems in other areas besides 
> UI-boneheadedness:
>
> * I18n and l10n
> * Compatibility, with modern hardware and with modern operating systems, 
> though that can be alleviated by people porting the code
> * Boneheaded internal limits, along the same general lines as "640K ought 
> to be enough for anybody". It may be unable to use more than a small 
> fraction of what modern hardware can offer it in the way of memory, 
> storage, cores, ...
> * Accessibility. Interposing a terminal emulator between the app and 
> screen reading software might cause problems, though on the other hand a 
> text mode app may ultimately have advantages in that area too. On the other 
> hand, it may not play well with accessibility tools
>   that rely on standard UI conventions. Anything that responds to some 
> voice command by generating control-V keystrokes to paste, or that relies 
> on the presence of normal menus and/or mouse support is going to blow up 
> spectacularly when used with 1980s-vintage Unix
>   (or MS-DOS) software, or at best will end up controlling the 
> xterm/Command Prompt window instead of the unde

Re: clojure, not the go to for data science

[Jony Hudson]

On Monday, 30 March 2015 14:46:53 UTC+1, Christian Weilbach wrote:
>
> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA1 
>
> I have started working on R integration with the help of rinancanter 
> (1) and it was nice to have dedicated R code cells with at least 
> syntax highlighting that I can mix with Clojure code in the same JVM 
> environment. 
>
> http://viewer.gorilla-repl.org/view.html?source=github&user=ghubber&repo=cnc&path=rincanter.clj
>  
> I am not sure whether this fits the design atm. though. I also had a 
> look at renjin, but I think the native plugins mandate an RVM 
> integration atm. 
>

You might find http://beakernotebook.com interesting, if you haven't seen 
it before. It allows several languages in the same notebook, and has  a 
simple mechanism for sharing data between the language environments. It's 
pretty green at the moment, but it has some serious backing, so could be 
pretty useful once it's got a bit more polish on it. I chatted a little 
with someone who was hoping to implement a Clojure plugin for it, although 
I don't know how they've gotten on since.

 I also have taken a paper I liked and implemented a quick version of 

> SNE, which was fairly nice to do in Gorilla REPL: 
>
> http://viewer.gorilla-repl.org/view.html?source=github&user=ghubber&repo=cnc&path=stochastic-neighbour-embedding.clj
>  
> A problem seems to be unicode support, I tried to use some math 
> symbols from the notation in the paper directly, but the viewer seems 
> to have a problem with it. 
>

Not sure what the problem is there - my feeling is it should just work, on 
the Gorilla side. If there's a test case you can point to (with an expected 
result) I can take a look at it.


Jony 

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

[Sayth Renshaw]

 You appear to have vastly misinterpreted my intention regards Emacs. My
mention of Emacs (I use emacs with prelude) was not based on my usage but
as a perception of those who might be attracted to Clojure For Purely Data
Science And wishes to get installed and moving quickly.

R offers to get you installed in 2 quick point and click installs and gives
you the language and R studio .

What would that person think when looking at Clojure?  If they saw emacs
would they know about prelude, how to configure it with so many
configuration options?

If someone out organisation was running a data science course would they
choose R because they can cover install and setup in 2 easy videos compared
to current Clojure options which may be less clear.

Sometimes often times onboarding people to a new language is about as much
as ease of install or at least making a default set of optiins clear.

Could the default set abs best options be made easier to new comers?

Sayth

Emacs can use the native windowing system on every major platform. It still
*looks* like a terminal app, but doesn't have to be one.

Pretty much everything you are saying here doesn't apply to Emacs at all,
and you would know it's all false if you knew anything about Emacs.

On Wednesday, April 1, 2015 at 4:55:08 PM UTC-7, Fluid Dynamics wrote:

On Tuesday, March 31, 2015 at 8:45:31 AM UTC-4, Phillip Lord wrote:

 The benefit is that Emacs is that its not constantly changing, and it
gives you some stability over the years. I like latex, for instance, for
the same reason. I can still access a 10 year old document and use it.

  First of all, there are other posts in this thread complaining about
constantly changing stuff breaking things! One such post is by Colin Yates.

Second, to the extent that it isn't changing, it is legacy. Which helps to
explain the Wordperfect for DOS style of UI, which is dependent on vast
numbers of complex key-combinations being memorized by the user, instead of
a just-sit-down-and-start-using-it UI like everything originating after,
say, 1995 or so has tended to have. Of course, the result is that
Wordperfect (and emacs) seemed to require a great deal of specialized
training just to accomplish even the most basic tasks, whereas with modern
interfaces the way to do such basic tasks (save, open, copy and paste, move
around, select, etc.) tends to be obvious and special training can focus
exclusively on doing advanced things (scripting, complicated Photoshop
filters and tricks, things like those).

Legacy also, obviously, tends to present problems in other areas besides
UI-boneheadedness:

* I18n and l10n
* Compatibility, with modern hardware and with modern operating systems,
though that can be alleviated by people porting the code
* Boneheaded internal limits, along the same general lines as "640K ought
to be enough for anybody". It may be unable to use more than a small
fraction of what modern hardware can offer it in the way of memory,
storage, cores, ...
* Accessibility. Interposing a terminal emulator between the app and screen
reading software might cause problems, though on the other hand a text mode
app may ultimately have advantages in that area too. On the other hand, it
may not play well with accessibility tools
  that rely on standard UI conventions. Anything that responds to some
voice command by generating control-V keystrokes to paste, or that relies
on the presence of normal menus and/or mouse support is going to blow up
spectacularly when used with 1980s-vintage Unix
  (or MS-DOS) software, or at best will end up controlling the
xterm/Command Prompt window instead of the underlying app.
* Interoperation with other (non-operating-system) software. On Windows it
won't speak OLE, DDE, OCX, or etc., and copying text in it and attempting
to paste into something else (web browser, calculator, etc.) is doomed to
failure. This is a general problem with
  pre-window-system software, much like the stuff listed under
Accessibility, with no easy solution. Terminal emulators tend to provide
some way to copy from their display into the host-native clipboard, but it
tends to be clunky (the Windows command prompt appears to
  require mouse use, with no keyboard shortcuts) and runs into the obvious
difficulties as soon as you want to copy more than will fit on one screen.
Ironically, really primitive stuff like ls and dir that just dump
possibly-paginated noninteractive listings to the term are easier
  to make big copies from than text-mode, interactive applications like
screen-oriented editors, because you can copy from the backscroll buffer of
the terminal emulator in the first case. Pre-window-system *graphical* apps
are the absolute worst, e.g. later, WYSIWYG
  word processor versions on MS-DOS, or pre-window-system X applications.
No internal support for the host clipboard and, at the same time, nothing
the emulator will recognize as text, meaning if you try to native copy and
paste you'll end up with a PNG or somethin

Re: clojure, not the go to for data science

[A]

Clojure is an Amazing tool for data science.  If people are slow to realize 
this, that is their disadvantage.

The premise that "Clojure hasn't developed as a go to for data science" 
simply doesn't ring true to me at all.  There are numerous examples of 
Clojure use for data science, there are books about it, there are youtube 
videos about it, there are practitioners, there is Incanter, there are 
Transducers, there are Notebooks (Gorilla is awesome), there are Java 
libraries, there are wrapper Clojure libraries, there are a lot of useful 
tools.  

Clojure is my "go to for data science" and I often use it either directly, 
or to manage runs using fast tools (like vw), or to prepare SQL-izations of 
data etc... (Btw, your SQL often runs as easily in 
Postgres/Redshift/Hive/Spark with minimal changes if any if you need to 
scale etc... If you treat your SQL the way you treat HTML, let your customs 
functions write it, you get a lot of analytic power that is not tied to any 
particular database).  There is Clojurescript for visualization... There is 
so much that I am certain I am forgetting to mention some of it.

Also, Big +1 for emacs use (cider is awesome! I rarely want to touch a 
mouse... ) 

Thanks for an amazing, innovative Emacs and Clojure commuity!!

-Avram

The sky is the limit.  







On Sunday, March 29, 2015 at 2:55:34 AM UTC-7, Sayth Renshaw wrote:
>
> Hi 
>
> I last learned clojure in 1.2. Just curious why Clojure hasn't developed 
> as a go to for data science? 
>
> It never seems to get a mention R,Python and now Julia get the attention. 
> By design it would appear that Clojure would be a good fit. Is it a lack of 
> libraries, ease of install, no good default environment  (R Rstudio, 
> IPython ) where as you would need to use emacs with clojure, or is there 
> just a better default use of Clojure? 
>
> Sayth

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

[Gary Johnson]

Please stop.

The amount of misinformation you are spreading about Emacs on this mailing 
list is deeply irresponsible and belies a very clear lack of understanding 
about how this software works. All of your concerns about 
internationalization (supported), accessibility to text readers 
(emacspeak), resource limits (full system utilization), and compatibility 
with modern hardware, operating systems, and window managers (GTK 
interface) are unfounded.

As it has been noted numerous times already by others, this thread is about 
Clojure and data science, not about your dislike of the Emacs user 
interface. Some people (such as myself) prefer a text-mode interface driven 
by keybindings over a mouse-driven graphical interface. That is an 
aesthetic and productivity-based choice. Please respect your fellow 
programmers and go write some software rather than continuing this diatribe.

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

[Christopher Small]

Dear lord... May I please echo the imploration that folks take the editor 
flame war else where. And while I'm at it, Vim FTW...

On the note of DATA SCIENCE...

I agree that Clojure has some catching up to do, both in tooling and 
awareness/perception. But it also has some major strengths in this area. 
Companies like the Climate Corp and Prismatic are certainly using Clojure 
for data analysis and ML to good effect, and I think they might have a lot 
to say about it's strengths.

As for Incanter, I would definitely recommend upgrading, primarily because 
2.0 (I believe) will be using core.matrix for it's matrix arithmetic and 
datasets. This certainly is a major refactor, but one that brings it in 
better pairing with what's going on in the rest of the Clojure community. I 
think part of why Incanter hasn't seen much pumping or visible change 
lately is because folks have been scrambling to get this new release ready, 
which I commend.

Chris


On Wednesday, April 1, 2015 at 6:21:20 AM UTC-7, Joseph Guhlin wrote:
>
> I haven't tested 1.9 or 2.0 yet, but I'm working with an existing project 
> that depends in incanter and I don't think there is a return on investment 
> for updating it at this time (only using a few features).
>
> If I was starting now, I would go with 1.9 for my data analysis.
>
> --Joseph
>
> On Tuesday, March 31, 2015 at 7:36:11 AM UTC-5, Erebus Mons wrote:
>>
>> Joseph Guhlin wrote: 
>>
>> > Incanter gets your pretty far, especially when combined with  Gorilla 
>> > REPL, but all the tools and features aren't quite there yet, but 
>> progress 
>> > is being made. 
>>
>> Incanter is undergoing major change with the migration to core.matrix, 
>> and a 
>> break in the API. 
>>
>> Has anybody of you tested incanter 1.9? 
>> Are there plans for the release date of the stable 2.0? 
>>
>> And how different is incanter 2.x from incanter 1.5x? 
>>
>> In other words, if you were tempted to start data analysis in clojure 
>> now, 
>> what would you do: 
>>
>> a) take incanter 1.9 
>> b) take incanter 1.5.6 
>> c) wait a few more weeks/months for the release of incanter 2.0? 
>>
>> Best, 
>>
>> EM 
>>
>>
>>
>>

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

[Justin Smith]

Emacs can use the native windowing system on every major platform. It still 
*looks* like a terminal app, but doesn't have to be one.

Pretty much everything you are saying here doesn't apply to Emacs at all, 
and you would know it's all false if you knew anything about Emacs.

On Wednesday, April 1, 2015 at 4:55:08 PM UTC-7, Fluid Dynamics wrote:
>
> On Tuesday, March 31, 2015 at 8:45:31 AM UTC-4, Phillip Lord wrote:
>>
>> The benefit is that Emacs is that its not constantly changing, and it 
>> gives you some stability over the years. I like latex, for instance, for 
>> the same reason. I can still access a 10 year old document and use it.
>>
>
> First of all, there are other posts in this thread complaining about 
> constantly changing stuff breaking things! One such post is by Colin Yates.
>
> Second, to the extent that it isn't changing, it is legacy. Which helps to 
> explain the Wordperfect for DOS style of UI, which is dependent on vast 
> numbers of complex key-combinations being memorized by the user, instead of 
> a just-sit-down-and-start-using-it UI like everything originating after, 
> say, 1995 or so has tended to have. Of course, the result is that 
> Wordperfect (and emacs) seemed to require a great deal of specialized 
> training just to accomplish even the most basic tasks, whereas with modern 
> interfaces the way to do such basic tasks (save, open, copy and paste, move 
> around, select, etc.) tends to be obvious and special training can focus 
> exclusively on doing advanced things (scripting, complicated Photoshop 
> filters and tricks, things like those).
>
> Legacy also, obviously, tends to present problems in other areas besides 
> UI-boneheadedness:
>
> * I18n and l10n
> * Compatibility, with modern hardware and with modern operating systems, 
> though that can be alleviated by people porting the code
> * Boneheaded internal limits, along the same general lines as "640K ought 
> to be enough for anybody". It may be unable to use more than a small 
> fraction of what modern hardware can offer it in the way of memory, 
> storage, cores, ...
> * Accessibility. Interposing a terminal emulator between the app and 
> screen reading software might cause problems, though on the other hand a 
> text mode app may ultimately have advantages in that area too. On the other 
> hand, it may not play well with accessibility tools
>   that rely on standard UI conventions. Anything that responds to some 
> voice command by generating control-V keystrokes to paste, or that relies 
> on the presence of normal menus and/or mouse support is going to blow up 
> spectacularly when used with 1980s-vintage Unix
>   (or MS-DOS) software, or at best will end up controlling the 
> xterm/Command Prompt window instead of the underlying app.
> * Interoperation with other (non-operating-system) software. On Windows it 
> won't speak OLE, DDE, OCX, or etc., and copying text in it and attempting 
> to paste into something else (web browser, calculator, etc.) is doomed to 
> failure. This is a general problem with
>   pre-window-system software, much like the stuff listed under 
> Accessibility, with no easy solution. Terminal emulators tend to provide 
> some way to copy from their display into the host-native clipboard, but it 
> tends to be clunky (the Windows command prompt appears to
>   require mouse use, with no keyboard shortcuts) and runs into the obvious 
> difficulties as soon as you want to copy more than will fit on one screen. 
> Ironically, really primitive stuff like ls and dir that just dump 
> possibly-paginated noninteractive listings to the term are easier
>   to make big copies from than text-mode, interactive applications like 
> screen-oriented editors, because you can copy from the backscroll buffer of 
> the terminal emulator in the first case. Pre-window-system *graphical* apps 
> are the absolute worst, e.g. later, WYSIWYG
>   word processor versions on MS-DOS, or pre-window-system X applications. 
> No internal support for the host clipboard and, at the same time, nothing 
> the emulator will recognize as text, meaning if you try to native copy and 
> paste you'll end up with a PNG or something.
>   OCR might work on that, if you can find cheap or free OCR software 
> that's any good. Your better bet would be to save the document as some 
> format that can be read by a native windowed app and then open the file in 
> that, then copy, and at that point you might as well
>   edit in the native windowed app and throw out the legacy cruft entirely, 
> since you'll have to deal with the native app anyway, and the cost of 
> switching between them constantly, reloading in the native app so it sees 
> changes, and re-locating the places you want to copy
>   from in the native app will quickly grow to outweigh any advantage the 
> legacy app might somehow have due to some feature it has that you haven't 
> found in any native app.
>
> Put more simply, there are giant costs to not playing well wi

Re: clojure, not the go to for data science

[Phillip Lord]

Fluid Dynamics  writes:

> On Tuesday, March 31, 2015 at 8:45:31 AM UTC-4, Phillip Lord wrote:
>>
>> The benefit is that Emacs is that its not constantly changing, and it 
>> gives you some stability over the years. I like latex, for instance, for 
>> the same reason. I can still access a 10 year old document and use it.
>>
>
> First of all, there are other posts in this thread complaining about 
> constantly changing stuff breaking things! One such post is by Colin Yates.


Yes. Obviously, newer stuff is changing.

> Second, to the extent that it isn't changing, it is legacy.

It makes little sense to complain about things changing, and then to say
things are legacy when they are not changing.

Legacy code is not code that is old. Legacy code is not code that you
wish were better. Legacy code is not even code that is nasty and hairy.

Legacy code is code for which there is a better alternative, but which
the activation energy of removing is too high.

I scanned most of the rest of your post. It's a bit of a ramble, and
doesn't relate to much of the software that I use. Broadly, I agree,
that old software sometimes behaves in a way that we would not write
today. Equally, software which has been written today sometimes suffers
from problems that were long solved in older software. The costs from
using old software are real, yes, but then so are the costs of using new
software, especially, if this entails constantly trying out the latest
and greatest technology just for the sake of it.

Phil

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

[Rinu Boney]

Hi,

 I'm working on a machine learning library for Clojure - Clatern(
https://github.com/rinuboney/clatern). I've written a couple of blog posts 
in my blog rinuboney.github.io. I've just begun and there is lot more work 
to do. I've actually submitted a Google summer of code proposal and I hope 
I get selected :-). I believe core.matrix and Incanter are awesome tools 
for data analysis. Clojure is a good fit for data analysis. I too propose 
that instead of the discussion, everyone channel their energy into open 
source data science libraries or on articles promoting Clojure for data 
science. 

Cheers,
Rinu.

On Monday, March 30, 2015 at 5:05:50 PM UTC+5:30, Jony Hudson wrote:
>
> I propose, instead of this discussion, everyone channels their energy into 
> writing an open-source data-science library, or blog post/article promoting 
> Clojure for data science. In their favourite editor, of course!
>
>
> Jony
>
>
> On Sunday, 29 March 2015 10:55:34 UTC+1, Sayth Renshaw wrote:
>>
>> Hi 
>>
>> I last learned clojure in 1.2. Just curious why Clojure hasn't developed 
>> as a go to for data science? 
>>
>> It never seems to get a mention R,Python and now Julia get the attention. 
>> By design it would appear that Clojure would be a good fit. Is it a lack of 
>> libraries, ease of install, no good default environment  (R Rstudio, 
>> IPython ) where as you would need to use emacs with clojure, or is there 
>> just a better default use of Clojure? 
>>
>> Sayth
>
>

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

[Fluid Dynamics]

On Tuesday, March 31, 2015 at 8:45:31 AM UTC-4, Phillip Lord wrote:
>
> The benefit is that Emacs is that its not constantly changing, and it 
> gives you some stability over the years. I like latex, for instance, for 
> the same reason. I can still access a 10 year old document and use it.
>

First of all, there are other posts in this thread complaining about 
constantly changing stuff breaking things! One such post is by Colin Yates.

Second, to the extent that it isn't changing, it is legacy. Which helps to 
explain the Wordperfect for DOS style of UI, which is dependent on vast 
numbers of complex key-combinations being memorized by the user, instead of 
a just-sit-down-and-start-using-it UI like everything originating after, 
say, 1995 or so has tended to have. Of course, the result is that 
Wordperfect (and emacs) seemed to require a great deal of specialized 
training just to accomplish even the most basic tasks, whereas with modern 
interfaces the way to do such basic tasks (save, open, copy and paste, move 
around, select, etc.) tends to be obvious and special training can focus 
exclusively on doing advanced things (scripting, complicated Photoshop 
filters and tricks, things like those).

Legacy also, obviously, tends to present problems in other areas besides 
UI-boneheadedness:

* I18n and l10n
* Compatibility, with modern hardware and with modern operating systems, 
though that can be alleviated by people porting the code
* Boneheaded internal limits, along the same general lines as "640K ought 
to be enough for anybody". It may be unable to use more than a small 
fraction of what modern hardware can offer it in the way of memory, 
storage, cores, ...
* Accessibility. Interposing a terminal emulator between the app and screen 
reading software might cause problems, though on the other hand a text mode 
app may ultimately have advantages in that area too. On the other hand, it 
may not play well with accessibility tools
  that rely on standard UI conventions. Anything that responds to some 
voice command by generating control-V keystrokes to paste, or that relies 
on the presence of normal menus and/or mouse support is going to blow up 
spectacularly when used with 1980s-vintage Unix
  (or MS-DOS) software, or at best will end up controlling the 
xterm/Command Prompt window instead of the underlying app.
* Interoperation with other (non-operating-system) software. On Windows it 
won't speak OLE, DDE, OCX, or etc., and copying text in it and attempting 
to paste into something else (web browser, calculator, etc.) is doomed to 
failure. This is a general problem with
  pre-window-system software, much like the stuff listed under 
Accessibility, with no easy solution. Terminal emulators tend to provide 
some way to copy from their display into the host-native clipboard, but it 
tends to be clunky (the Windows command prompt appears to
  require mouse use, with no keyboard shortcuts) and runs into the obvious 
difficulties as soon as you want to copy more than will fit on one screen. 
Ironically, really primitive stuff like ls and dir that just dump 
possibly-paginated noninteractive listings to the term are easier
  to make big copies from than text-mode, interactive applications like 
screen-oriented editors, because you can copy from the backscroll buffer of 
the terminal emulator in the first case. Pre-window-system *graphical* apps 
are the absolute worst, e.g. later, WYSIWYG
  word processor versions on MS-DOS, or pre-window-system X applications. 
No internal support for the host clipboard and, at the same time, nothing 
the emulator will recognize as text, meaning if you try to native copy and 
paste you'll end up with a PNG or something.
  OCR might work on that, if you can find cheap or free OCR software that's 
any good. Your better bet would be to save the document as some format that 
can be read by a native windowed app and then open the file in that, then 
copy, and at that point you might as well
  edit in the native windowed app and throw out the legacy cruft entirely, 
since you'll have to deal with the native app anyway, and the cost of 
switching between them constantly, reloading in the native app so it sees 
changes, and re-locating the places you want to copy
  from in the native app will quickly grow to outweigh any advantage the 
legacy app might somehow have due to some feature it has that you haven't 
found in any native app.

Put more simply, there are giant costs to not playing well with others, and 
these are inevitably incurred by all applications developed prior to the 
advent of a) window systems with window managers, systemwide copy/paste, 
and etc. and b) widespread user-interface standards for common cross-domain 
tasks like save and paste. Ultimately, the costs incurred every time you or 
some data need to cross the boundary between the legacy application and the 
modern world are likely to vastly outweigh whatever few missing features 
you can find only in le

Re: clojure, not the go to for data science

[Joseph Guhlin]

I haven't been able to get quil working with gorilla repl yet, but I hope 
the support is there one day.

--Joseph

On Wednesday, April 1, 2015 at 5:37:05 AM UTC-5, Sayth Renshaw wrote:
>
> I saw all the changes to incanter. lot of breaking changes going into 
> version 2 but they seem to reduce dependencies and going to core.matrix as 
> you pointed out. 
>
> There are a lot of things in clojure that I have  found that I just 
> haven't heard about need to clean some web data there are several great 
> options hickory seems to stand out as an html parser and css selector based 
> of jsoup https://github.com/davidsantiago/hickory .
>
> Gorilla is amazing why is this not heard? http://gorilla-repl.org/
>
> Not data related but for graphics quil seems awesome  
> https://github.com/quil/quil
>
>  
>
> On Tuesday, 31 March 2015 23:36:11 UTC+11, Erebus Mons wrote:
>>
>> Joseph Guhlin wrote: 
>>
>> > Incanter gets your pretty far, especially when combined with  Gorilla 
>> > REPL, but all the tools and features aren't quite there yet, but 
>> progress 
>> > is being made. 
>>
>> Incanter is undergoing major change with the migration to core.matrix, 
>> and a 
>> break in the API. 
>>
>> Has anybody of you tested incanter 1.9? 
>> Are there plans for the release date of the stable 2.0? 
>>
>> And how different is incanter 2.x from incanter 1.5x? 
>>
>> In other words, if you were tempted to start data analysis in clojure 
>> now, 
>> what would you do: 
>>
>> a) take incanter 1.9 
>> b) take incanter 1.5.6 
>> c) wait a few more weeks/months for the release of incanter 2.0? 
>>
>> Best, 
>>
>> EM 
>>
>>
>>
>>

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

[Joseph Guhlin]

I haven't tested 1.9 or 2.0 yet, but I'm working with an existing project 
that depends in incanter and I don't think there is a return on investment 
for updating it at this time (only using a few features).

If I was starting now, I would go with 1.9 for my data analysis.

--Joseph

On Tuesday, March 31, 2015 at 7:36:11 AM UTC-5, Erebus Mons wrote:
>
> Joseph Guhlin wrote: 
>
> > Incanter gets your pretty far, especially when combined with  Gorilla 
> > REPL, but all the tools and features aren't quite there yet, but 
> progress 
> > is being made. 
>
> Incanter is undergoing major change with the migration to core.matrix, and 
> a 
> break in the API. 
>
> Has anybody of you tested incanter 1.9? 
> Are there plans for the release date of the stable 2.0? 
>
> And how different is incanter 2.x from incanter 1.5x? 
>
> In other words, if you were tempted to start data analysis in clojure now, 
> what would you do: 
>
> a) take incanter 1.9 
> b) take incanter 1.5.6 
> c) wait a few more weeks/months for the release of incanter 2.0? 
>
> Best, 
>
> EM 
>
>
>
>

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

[Sayth Renshaw]

I saw all the changes to incanter. lot of breaking changes going into 
version 2 but they seem to reduce dependencies and going to core.matrix as 
you pointed out. 

There are a lot of things in clojure that I have  found that I just haven't 
heard about need to clean some web data there are several great options 
hickory seems to stand out as an html parser and css selector based of 
jsoup https://github.com/davidsantiago/hickory .

Gorilla is amazing why is this not heard? http://gorilla-repl.org/

Not data related but for graphics quil seems awesome 
 https://github.com/quil/quil

 

On Tuesday, 31 March 2015 23:36:11 UTC+11, Erebus Mons wrote:
>
> Joseph Guhlin wrote: 
>
> > Incanter gets your pretty far, especially when combined with  Gorilla 
> > REPL, but all the tools and features aren't quite there yet, but 
> progress 
> > is being made. 
>
> Incanter is undergoing major change with the migration to core.matrix, and 
> a 
> break in the API. 
>
> Has anybody of you tested incanter 1.9? 
> Are there plans for the release date of the stable 2.0? 
>
> And how different is incanter 2.x from incanter 1.5x? 
>
> In other words, if you were tempted to start data analysis in clojure now, 
> what would you do: 
>
> a) take incanter 1.9 
> b) take incanter 1.5.6 
> c) wait a few more weeks/months for the release of incanter 2.0? 
>
> Best, 
>
> EM 
>
>
>
>

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

[Sayth Renshaw]

Sorry no offense intended, I have prelude, cider and Nrepl going right now. 
Actually I haven't usually gotten along with emacs but it is just working 
at the moment and  um i like it. I am just changing flx-ido to vertical 
as it looks a little nicer but that's it really, the only change.



On Monday, 30 March 2015 01:27:08 UTC+11, solussd wrote:
>
> Batsov,
>
> CIDER is the best Clojure IDE. ;)
>
> --
> @solussd
>
>
> On Mar 29, 2015, at 9:14 AM, Bozhidar Batsov  > wrote:
>
> And CIDER isn't, right? I find this pretty insulting... 
>
> On 29 March 2015 at 13:47, Colin Yates > 
> wrote:
>
>> Cursive Clojure, LightTable and CounterClockwise are all good Clojure 
>> IDEs.
>>
>> On 29 March 2015 at 09:54, Sayth Renshaw > > wrote:
>> > Hi
>> >
>> > I last learned clojure in 1.2. Just curious why Clojure hasn't 
>> developed as a go to for data science?
>> >
>> > It never seems to get a mention R,Python and now Julia get the 
>> attention. By design it would appear that Clojure would be a good fit. Is 
>> it a lack of libraries, ease of install, no good default environment  (R 
>> Rstudio, IPython ) where as you would need to use emacs with clojure, or is 
>> there just a better default use of Clojure?
>> >
>> > Sayth
>> >
>> > --
>> > 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 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 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: clojure, not the go to for data science

[Phillip Lord]

Mikera  writes:

>> I would say, lack of numpy or equivalent. And nice tools to link between 
>> Clojure and the many C/Fortran numeric libraries. Python and R do this 
>> natively. 
>>
>
> core.matrix is effectively the equivalent of NumPy
>
> In some ways it is much more versatile, because it works with a general 
> array abstraction rather than a specific concrete array format. There are 
> core.matrix implementations (e.g. Clatrix) that link to native numerical 
> libraries.


I didn't know about the native implementation!

But my point was a more general one. If I have an old fortran numerical
library that I want to pull into my analysis. How easy is it to do this
in python and how easy in Clojure?

> native back end performance since you can use tools like Clatrix to access 
> BLAS etc. And aside from that, the JVM gives you a lot of big advantages on 
> the server side (sophisticated memory management, excellent JIT 
> compilation, concurrency, portability, library ecosystem etc.). I never 
> quite understand the motivation of people who seem to want to reinvent all 
> of this (probably badly) in native code. The JVM is an amazing piece of 
> engineering, and I believe that a lot of the sucess of Clojure comes from 
> taking advantage of this.


My experience of most big data projects is that a lot of it involves
writing some scripts to do some data munging, and then plug it into
some existing library for numerical analysis.

The JVM is a good piece of software and supports an amazing ecosystem.
It's just not that easy to break out of the ecosystem.

Of course, this might just be because people haven't tried enough. I
think that the lack of syntactic flexibility of Java made it problematic
in the past. Now with languages like Clojure or Scala which have at
least as much of flexibility as python (more in fact), perhaps this will
change.

Phil

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

[Phillip Lord]

Fluid Dynamics  writes:
>> That's nonsense.  As soon as you have made yourself acquainted with the 
>> basic Emacs terminology and concepts, getting started with Clojure 
>> development is a piece of cake.  Of course,
>
>
> the devil is in the details. Including the implementation details that leak 
> out all over the place, starting with the ubiquitous use of the term 
> "buffer" in user-facing documentation.


This is not an implementation detail. It's just the name that the Emacs
developers picked. There is a data structure which represents this idea
of a buffer underneath.

It's a slightly unfortunate name, as it's unusual, but better that
window which is usual but means something else. But what you see is
history poking through, not implementation detail. If Emacs were written
now, these things would have different names. It's a price you pay with
using emacs.

The benefit is that Emacs is that its not constantly changing, and it
gives you some stability over the years. I like latex, for instance, for
the same reason. I can still access a 10 year old document and use it.


Phil

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

[Phillip Lord]

Colin Yates  writes:
> The camel breaking straw for me was yet another iteration of 'come on,
> let's tame this beast, find package X to scratch itch Y, update and
> watch something break. Spend hours numptying and googling around, give
> up, fresh re-install, do some paid work'. Rinse and repeat.

It is worth saying, of course, that a lot of this has gone away, and
that package management in Emacs has changed massively in the last few
years. MELPA-stable has helped me move of the bleeding edge in most
cases. Still not perfect, but it is coming along.

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

[Erebus Mons]

Joseph Guhlin wrote:

> Incanter gets your pretty far, especially when combined with  Gorilla
> REPL, but all the tools and features aren't quite there yet, but progress
> is being made. 

Incanter is undergoing major change with the migration to core.matrix, and a 
break in the API.

Has anybody of you tested incanter 1.9?
Are there plans for the release date of the stable 2.0?

And how different is incanter 2.x from incanter 1.5x? 

In other words, if you were tempted to start data analysis in clojure now, 
what would you do:

a) take incanter 1.9
b) take incanter 1.5.6
c) wait a few more weeks/months for the release of incanter 2.0?

Best,

EM



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

[Colin Yates]

This. I am amazed it isn't more widely shouted about.

On Sunday, 29 March 2015 12:34:23 UTC+1, Jony Hudson wrote:
>
> First, let me shamelessly plug Gorilla REPL http://gorilla-repl.org . 
> It's a notebook type REPL, which I think works well as an environment for 
> the sort exploratory programming of that's common when analysing data. We 
> use it for science-involving-data every day in our research group, and I 
> think a few others do too.
>
> Regarding the question, my guess at the answer would be "fashion". My 
> experience has been that Clojure is a fine environment for technical 
> computing. It's not as complete, library wise, as the alternatives, so it's 
> sometimes a struggle. But it has some strengths over the others too 
> (deployment, in particular - and I find Java is a really nice low-level 
> escape hatch, compared to the alternatives). My guess is that it would take 
> some high profile organisation to adopt it as a data science platform, and 
> talk about it a lot, for it to really catch on, because that seems to be 
> how fashion works!
>
>
> Jony
>
>
> On Sunday, 29 March 2015 10:55:34 UTC+1, Sayth Renshaw wrote:
>>
>> Hi 
>>
>> I last learned clojure in 1.2. Just curious why Clojure hasn't developed 
>> as a go to for data science? 
>>
>> It never seems to get a mention R,Python and now Julia get the attention. 
>> By design it would appear that Clojure would be a good fit. Is it a lack of 
>> libraries, ease of install, no good default environment  (R Rstudio, 
>> IPython ) where as you would need to use emacs with clojure, or is there 
>> just a better default use of Clojure? 
>>
>> Sayth
>
>

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

[Colin Yates]

Yes, exactly this.

The camel breaking straw for me was yet another iteration of 'come on,
let's tame this beast, find package X to scratch itch Y, update and
watch something break. Spend hours numptying and googling around, give
up, fresh re-install, do some paid work'. Rinse and repeat.

Cursive - from day one it has worked for what I need out of the box.

Do I miss some things from emacs? Sure - keyboard navigation, buffer
switching, kill ring, ability to run over ssh on the powerful company
servers, undo-tree and so on. Do I hope that one day when I grow up I
will be good enough to build me own emacs-based-editor - sure :). I
had better stop thinking about emacs as it is feeding my ever-present
'grass is greener' gene

On 31 March 2015 at 10:54, Phillip Lord  wrote:
> Alexis  writes:
>
>> Colin Yates  writes:
>>
>>> I used it a few years back
>>
>> [snip]
>>
>>> [and] even after man-months spent tinkering, hunting down the right version
>>> on MELPA or MARMALADE (or whatever it is called)
>>
>> i basically only use MELPA and GNU ELPA. In terms of the ~200 packages i've
>> installed from MELPA, i can't remember having to deal with versioning issues
>> at all. Further, despite some people fretting about the theoretical lack of
>> stability of packages on MELPA, i've only rarely had to deal with broken
>> packages - and those breakages have been fixed very rapidly by the
>> maintainers.
>
> I have. Mostly with Clojure as it happens -- the move from slime to
> nrepl was quite painful. And the lack of stability on MELPA was a
> significant cause.
>
>> *nod*
>>
>> However, Emacs configuration management has, i feel, improved significantly
>> over the last couple of years, with things like `use-package`:
>>
>> https://github.com/jwiegley/use-package
>>
>> enabling one to create easily-reproducible config setups across
>> environments/machines.
>
> This was the cause of all my grief with MELPA though. My setup is
> use-package based (actually, I added the ELPA/package.el integration).
> I sync my .emacs across machines, and use-package auto-installs missing
> packages. This meant I got different versions on every machine,
> depending on when the auto-install happened.
>
> Fingers crossed more package authors add support for MELPA stable. I use
> it exclusively now.
>
> Phil
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: clojure, not the go to for data science

[Colin Yates]

Ha! Genius.

On 30 March 2015 at 19:47, danle...@gmail.com  wrote:
> http://www.scribd.com/doc/30605092/Saturn-v-Flight-Manual
>
> I have tracked down the flight manual of the Saturn-V rocket so we can 
> objectively decide whether emacs is more, or less, difficult.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: clojure, not the go to for data science

[Phillip Lord]

Alexis  writes:

> Colin Yates  writes:
>
>> I used it a few years back
>
> [snip]
>
>> [and] even after man-months spent tinkering, hunting down the right version
>> on MELPA or MARMALADE (or whatever it is called)
>
> i basically only use MELPA and GNU ELPA. In terms of the ~200 packages i've
> installed from MELPA, i can't remember having to deal with versioning issues
> at all. Further, despite some people fretting about the theoretical lack of
> stability of packages on MELPA, i've only rarely had to deal with broken
> packages - and those breakages have been fixed very rapidly by the
> maintainers.

I have. Mostly with Clojure as it happens -- the move from slime to
nrepl was quite painful. And the lack of stability on MELPA was a
significant cause.

> *nod*
>
> However, Emacs configuration management has, i feel, improved significantly
> over the last couple of years, with things like `use-package`:
>
> https://github.com/jwiegley/use-package
>
> enabling one to create easily-reproducible config setups across
> environments/machines.

This was the cause of all my grief with MELPA though. My setup is
use-package based (actually, I added the ELPA/package.el integration).
I sync my .emacs across machines, and use-package auto-installs missing
packages. This meant I got different versions on every machine,
depending on when the auto-install happened.

Fingers crossed more package authors add support for MELPA stable. I use
it exclusively now.

Phil

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

[Sayth Renshaw]

Technically I see the JVM as an advantage. F# now as well as Julia are seen
as the data science languages contenders of the future.

Clojure has a lot going for it but never gets a mention,  just could not
understand why that is. Spark implements Scala and Python as languages to
use,  again you would wonder why not clojure here.

Is there a level of advocacy missing?

Sayth

On Tue, 31 Mar 2015 5:06 PM Mikera  wrote:

>
>
> On Tuesday, 31 March 2015 00:01:32 UTC+8, Phillip Lord wrote:
>
>>
>>
>>
>> Sayth Renshaw  writes:
>> > I last learned clojure in 1.2. Just curious why Clojure hasn't
>> > developed as a go to for data science?
>> >
>> > It never seems to get a mention R,Python and now Julia get the
>> > attention. By design it would appear that Clojure would be a good fit.
>> > Is it a lack of libraries, ease of install, no good default
>> > environment (R Rstudio, IPython ) where as you would need to use emacs
>> > with clojure, or is there just a better default use of Clojure?
>>
>>
>> I would say, lack of numpy or equivalent. And nice tools to link between
>> Clojure and the many C/Fortran numeric libraries. Python and R do this
>> natively.
>>
>
> core.matrix is effectively the equivalent of NumPy
>
> In some ways it is much more versatile, because it works with a general
> array abstraction rather than a specific concrete array format. There are
> core.matrix implementations (e.g. Clatrix) that link to native numerical
> libraries. There are also core.matrix implementations that run in pure,
> portable JVM code (e.g. vectorz-clj). You can also use plain old Clojure
> persistent vectors as a (slow but convenient) core.matrix implementation.
> Having all these options usable via the *same API* is a big win.
>
> core.matrix is certainly not yet as mature or fully featured as NumPy. But
> if it doesn't do what you need - please help improve it! PRs, bug reports
> and enhancement ideas all gratefully accepted.
>
> https://github.com/mikera/core.matrix
>
> There is also a Google Group here specifically dedicated to numerical
> topics in Clojure:
>
> https://groups.google.com/forum/#!forum/numerical-clojure
>
>
>>
>> Maybe if Clojure pulls itself away from the JVM this will change. One
>> big problem with both python and R for data science is that a lot of
>> interactive data visualisation happens on the web these days, and
>> neither python nor R support that so well. An ecosystem with a C hosted
>> clojure at the back end and Clojure script at the front end might work
>> well.
>>
>
> I agree Clojure is a great back-end for data-driven web applications.
>
> I would argue however that you don't need a "C-hosted" Clojure to get
> native back end performance since you can use tools like Clatrix to access
> BLAS etc. And aside from that, the JVM gives you a lot of big advantages on
> the server side (sophisticated memory management, excellent JIT
> compilation, concurrency, portability, library ecosystem etc.). I never
> quite understand the motivation of people who seem to want to reinvent all
> of this (probably badly) in native code. The JVM is an amazing piece of
> engineering, and I believe that a lot of the sucess of Clojure comes from
> taking advantage of this.
>
> I've personally had good experiences with Clojure on the back end and
> JavaScript/ClojureScript on the front end, and never once worried about
> performance.
>
>

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

[Mikera]

On Tuesday, 31 March 2015 00:01:32 UTC+8, Phillip Lord wrote:
>
>
>
>
> Sayth Renshaw > writes: 
> > I last learned clojure in 1.2. Just curious why Clojure hasn't 
> > developed as a go to for data science? 
> > 
> > It never seems to get a mention R,Python and now Julia get the 
> > attention. By design it would appear that Clojure would be a good fit. 
> > Is it a lack of libraries, ease of install, no good default 
> > environment (R Rstudio, IPython ) where as you would need to use emacs 
> > with clojure, or is there just a better default use of Clojure? 
>
>
> I would say, lack of numpy or equivalent. And nice tools to link between 
> Clojure and the many C/Fortran numeric libraries. Python and R do this 
> natively. 
>

core.matrix is effectively the equivalent of NumPy

In some ways it is much more versatile, because it works with a general 
array abstraction rather than a specific concrete array format. There are 
core.matrix implementations (e.g. Clatrix) that link to native numerical 
libraries. There are also core.matrix implementations that run in pure, 
portable JVM code (e.g. vectorz-clj). You can also use plain old Clojure 
persistent vectors as a (slow but convenient) core.matrix implementation. 
Having all these options usable via the *same API* is a big win.

core.matrix is certainly not yet as mature or fully featured as NumPy. But 
if it doesn't do what you need - please help improve it! PRs, bug reports 
and enhancement ideas all gratefully accepted. 

https://github.com/mikera/core.matrix

There is also a Google Group here specifically dedicated to numerical 
topics in Clojure:

https://groups.google.com/forum/#!forum/numerical-clojure
 

>
> Maybe if Clojure pulls itself away from the JVM this will change. One 
> big problem with both python and R for data science is that a lot of 
> interactive data visualisation happens on the web these days, and 
> neither python nor R support that so well. An ecosystem with a C hosted 
> clojure at the back end and Clojure script at the front end might work 
> well. 
>

I agree Clojure is a great back-end for data-driven web applications. 

I would argue however that you don't need a "C-hosted" Clojure to get 
native back end performance since you can use tools like Clatrix to access 
BLAS etc. And aside from that, the JVM gives you a lot of big advantages on 
the server side (sophisticated memory management, excellent JIT 
compilation, concurrency, portability, library ecosystem etc.). I never 
quite understand the motivation of people who seem to want to reinvent all 
of this (probably badly) in native code. The JVM is an amazing piece of 
engineering, and I believe that a lot of the sucess of Clojure comes from 
taking advantage of this.

I've personally had good experiences with Clojure on the back end and 
JavaScript/ClojureScript on the front end, and never once worried about 
performance.
 

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

[danle...@gmail.com]

http://www.scribd.com/doc/30605092/Saturn-v-Flight-Manual

I have tracked down the flight manual of the Saturn-V rocket so we can 
objectively decide whether emacs is more, or less, difficult.

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

[Phillip Lord]

Sayth Renshaw  writes:
> I last learned clojure in 1.2. Just curious why Clojure hasn't
> developed as a go to for data science?
>
> It never seems to get a mention R,Python and now Julia get the
> attention. By design it would appear that Clojure would be a good fit.
> Is it a lack of libraries, ease of install, no good default
> environment (R Rstudio, IPython ) where as you would need to use emacs
> with clojure, or is there just a better default use of Clojure?


I would say, lack of numpy or equivalent. And nice tools to link between
Clojure and the many C/Fortran numeric libraries. Python and R do this
natively.

Maybe if Clojure pulls itself away from the JVM this will change. One
big problem with both python and R for data science is that a lot of
interactive data visualisation happens on the web these days, and
neither python nor R support that so well. An ecosystem with a C hosted
clojure at the back end and Clojure script at the front end might work
well.

Phil



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

[Tassilo Horn]

Fluid Dynamics  writes:

> You can have as many of them open as you like, say, one for 
> "task X", and one for "switching focus between windows".
>
> And then have what, two 27x24 and a 26x24 keyhole to squint through at
> everything? :) Less a couple of lines at the bottom for status
> notifications and the little command input area, of course.

You can have as many windows as you want, and you can have as many
buffers as you want.  Windows display buffers.  You can have 2 windows
on the same buffer, or you can have one window and a gazillion buffers
in which case only one of them is displayed currently, but you can
switch from one buffer to another buffer in the current window with `C-x
b '.  It's not uncommon that I have 50 or more buffers at a
time, and it's still very manageable.

And of course, you don't need to run emacs on the linux console.  I run
it maximized in X with its graphical UI, and then I can easily have 3
windows side-by-side which are still wider than 80 columns.

Anyway, there's no point in discussing with you as it seems you know
better anyhow.  So the discussion is finished for me.

Bye,
Tassilo

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

Easy-install/GUI emacs for Clojure (was: Re: clojure, not the go to for data science)

[Lee Spector]

[Forked the thread as per suggestion by Timothy Baldridge.]

On Mar 30, 2015, at 9:29 AM, Christian Weilbach  
wrote:
> 
> I have failed to setup Emacs for development and used Vim or Eclipse
> primarily before entering Clojure-land. emacs-live allowed me to just
> execute a shell script and get a decent Clojure environment which I
> have used for 2 years until I have reconfigured my emacs having a
> better understanding. Its emphasis on live-coding inspired by
> composing music is a very compelling. The only thing I had to add to
> emacs live was evil-mode, which wasn't too hard.

I agree that emacs-live is a great step forward! I explored it for a while and 
considered adopting it for my teaching and research work. (I'm not a software 
developer, I'm a computer science professor/researcher.) I didn't think it got 
quite far enough towards meeting my needs for me to make the leap, but it came 
the closest so far. Perhaps it'd be a good starting point for someone to take 
the next step.

FWIW I try to survey all of the options every year or so, and I currently teach 
with and mostly use Counterclockwise, although I sometimes recommend Nightcode 
for newbies. Both of these are great, and I'm immensely grateful to their 
developers. But if an emacs-based environment came along with the right 
usability features (see bullet points below) then I'd almost certainly switch 
to that.

 -Lee


> On 30.03.2015 15:12, Lee Spector wrote:
>>> On Mar 30, 2015, at 7:35 AM, Jony Hudson 
>>> wrote:
>>> 
>>> I propose, instead of this discussion, everyone channels their
>>> energy into writing an open-source data-science library, or blog
>>> post/article promoting Clojure for data science. In their
>>> favourite editor, of course!
>>> 
>>> 
>>> Jony
>> 
>> 
>> 
>> That's a good idea, but I'd also like to say a bit more about the
>> pro/con-emacs discussion, which I hope to be constructive.
>> 
>> I think I actually agree with most of the comments both by the
>> emacs critics and the emacs proponents in this thread. Even the
>> most intense ones, on both sides. But rather than worrying about
>> who is more correct I want to point out that it's entirely
>> possible, and would be gloriously beautiful, for an emacs-based
>> Clojure environment to be produced that:
>> 
>> - Can be downloaded in a single click and run with one more click
>> to do basic Clojure development with no further configuration, on
>> Mac/Windows/Linux.
>> 
>> - Provides reasonably standard GUI elements (familiar to any
>> computer user without reading a manual) for triggering core
>> functionality and for discovering additional features.
>> 
>> As some have mentioned in this thread, a lot of work has been done
>> on easing configuration (by people on this list among others) and
>> there are some GUI-based packages out there, but as far as I know
>> there's nothing that comes close to meeting both of the bullet
>> points above. I think that most emacs-based folks either don't
>> think this is possible or don't see it as a priority, but something
>> like this must be possible (and there have been things close to
>> this for other Lisps in the past), and  if it became a reality that
>> I would switch to it for all of my coding and teaching and I'd
>> evangelize it from the rooftops.
>> 
>> I'm not in a position to do development work on this myself, but I
>> believe quite fervently that this would be a fabulous thing for the
>> Clojure community.
>> 
>> I'd be happy to discuss this further off-list and/or beta-test
>> projects aimed at these goals.

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

[Christian Weilbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 30.03.2015 13:35, Jony Hudson wrote:
> I propose, instead of this discussion, everyone channels their
> energy into writing an open-source data-science library, or blog
> post/article promoting Clojure for data science. In their favourite
> editor, of course!

I have started working on R integration with the help of rinancanter
(1) and it was nice to have dedicated R code cells with at least
syntax highlighting that I can mix with Clojure code in the same JVM
environment.
http://viewer.gorilla-repl.org/view.html?source=github&user=ghubber&repo=cnc&path=rincanter.clj
I am not sure whether this fits the design atm. though. I also had a
look at renjin, but I think the native plugins mandate an RVM
integration atm.

Sadly JyNI has made little progress towards Numpy support, (2)
otherwise Clojure could integrate more mature data science platforms
like R and Python more easily and leverage its integrative JVM
advantage more. The fragmentation on runtime level is really stupid imo.

It can be difficult to address some data science techniques in
Clojure, because you have to reimplement them from R, Python or
something else compared to Clojure being able to use Java libraries
directly and "sitting on top of the hill" by default for "business"
problems. Java is just not a good data science language and hated by
many people in my environment. But gorilla is really nice in
combination with ggplot already, so I think if one could at least
integrate R there, the disadvantages would shrink significantly.

I also have taken a paper I liked and implemented a quick version of
SNE, which was fairly nice to do in Gorilla REPL:
http://viewer.gorilla-repl.org/view.html?source=github&user=ghubber&repo=cnc&path=stochastic-neighbour-embedding.clj
A problem seems to be unicode support, I tried to use some math
symbols from the notation in the paper directly, but the viewer seems
to have a problem with it.

Christian

(1) https://github.com/jolby/rincanter
(2) https://github.com/Stewori/JyNI/issues/2#
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVGVPFAAoJEKel+aujRZMkLBYIAKp+kzS7l0iiKdKVhRl1e0wP
utRHY+KFwmIRpc0vBf1Y5I5Lo2jFlemslDlWmQb5iPcYfALpLrzhHVP4CL4nRy+c
SMfnHPOS4nD6usAbTjyi3ZP8/wTbL3Du6oGQmwQMcMpklTgh+qgBsLmLdYabwXcm
YMifMYZVjSEtFcAz/FLxukLGGOSa86Nld79Wgj9hu2kTpS3ZFIx2gSpNzeeyiZBU
O+QtKTVAM603vBDQF0dgYu5u45pfsW/SZ0dThOvKN9632MX8Xb+SzzS34pxtxGWr
/JMpffYOIZ7kw0qto1zKKwewoO0zmhCjmOXDS063wYfHWvEqhcia9ChdT/4rxvY=
=0XIe
-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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: clojure, not the go to for data science

[Fluid Dynamics]

On Monday, March 30, 2015 at 7:29:36 AM UTC-4, Alexis wrote:
>
>
> Fluid Dynamics > writes: 
>   
> >> * i don't have to learn and use a distinct, possibly   
> >>   resource-hungry,  IDE[2] for every new programming language 
> >>   or environment i  need/want to work in. (When the Swift 
> >>   language was released, for  example, basic Swift support in 
> >>   the form of `swift-mode` became  available within less than a 
> >>   week.)   
> > 
> > Eclipse has plugins for a wide variety of languages.   
>
> True, but i don't think i've ever heard that one of Eclipse's main 
> selling points is that it's light on resource usage. 
>

Its resource usage as a percentage of what's available with a typical 
developer's hardware now is probably comparable to emacs's as a percentage 
of what was available with a typical developer's hardware circa 1985. Of 
course, on modern hardware that percentage can do a whole heck of a lot 
more, such as presenting an actual user interface. :)

>> * Further to the resource-usage issue, i can more easily use 
> >> Emacs   
> >>   remotely over low-bandwidth links than i could use an IDE.   
> > 
> > Typical home and mobile connection speeds are multiple MBPS 
> > these days. 
>
> You respond to me saying that /i/ like Emacs for its ease-of-use 
> across low-bandwidth links (which i regularly have to deal with) 
> by  what, implying that i should be a so-called 'typical' 
> home/mobile connection user instead? 
>

Forgive me for assuming that you meant to suggest that as a general selling 
point, rather than a personal idiosyncracy or something. :)
 

> Anyway, 'typical' varies from geographic location to geographic 
> location. My home connection is ADSL2+, but my mobile provides 4G 
> speeds only within a limited geographic area - and when i visited 
> the city of Newcastle, New South Wales, recently, with it's 
> population of ~300,000, my mobile data connection was 
> intermittent, let alone of a decent speed. In such a situation, 
> i've found being able to use a text-based UI, rather than being 
> forced to use a graphical UI (even using something like NoMachine) 
> quite a boon. 
>

In such a situation, I'd find using infrequent and discrete network 
accesses, such as checkins and checkouts from a remote repository, and 
working with local copies of checked-out files with a local editor on my 
own device, to be quite a boon. And who wants their UI to have noticeable 
latency anyways? If you're trying to arrow to a position (or worse, 
backspace or delete to one), it's like skating on ice: you're prone to 
overshoot and spend ages playing golf with the damn cursor. If you have a 
local laggy UI, such as due to something else abruptly hogging the CPU 
unexpectedly (svchost.exe being the standard culprit on Windows), at least 
you can resort to the mouse to click the cursor into position in one move, 
but with a remote terminal emulation you won't even have that option.

Further, even ADSL2+ bandwidth can be heavily saturated when other 
> people on the connection are e.g. streaming HD movies at the same 
> time as one is trying to work on a remote system  
>

Isn't that cable you're thinking of? Which is why sane people use DSL/4G 
for most needs, unless they download a shitton of giant .mkvs themselves.

>> * IDEs typically don't allow one to change their basic 
> >> behaviours   
> >>   whilst  they're running. Related: if there's a bug fix or 
> >>   feature i want  applied, i can apply it myself, rather than 
> >>   having to hope that  the maintainers will (a) accept that 
> >>   it's something that  /should/ be applied, and (b) actually 
> >>   apply it.   
> > 
> > The second, at least, applies to every open source IDE, 
> > including a certain EPL-licensed one. 
>
> Not quite, at least not insofar as i understand what you're 
> saying. i'm talking about not having to patch the source tree and 
> recompile, even across new versions. In my Emacs config, i've 
> redefined a few different Emacs functions to behave the way i 
> want, such that, even when i install a new version of Emacs, i 
> don't need to make any changes to the source itself to get the 
> desired behaviour.
>

That sounds unbelievably fragile. Like monkey-patching clojure.core or a 
major Ruby class, and then updating Clojure/Ruby.   

> Unfortunately, one MUST do all of that and CANNOT use it as a 
> > black box, because it is the software analogue of a computer 
> > with no keyboard or monitor or anything else resembling a user 
> > interface, so one must toggle everything in and know the 
> > hardware internals backwards and forwards to get anything 
> > done. :) 
>
> A strong claim, considerably stronger than the weaker claim that 
> Emacs needs tweaking to get to one's 'ideal' workflow, or even 
> that Emacs needs more tweaking than other software to get to that 
> workflow.


To get to something that so much as vaguely resembles your normal workflow 
appears to take an astonishing amoun

Re: clojure, not the go to for data science

[Christian Weilbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 30.03.2015 15:12, Lee Spector wrote:
>> On Mar 30, 2015, at 7:35 AM, Jony Hudson 
>> wrote:
>> 
>> I propose, instead of this discussion, everyone channels their
>> energy into writing an open-source data-science library, or blog
>> post/article promoting Clojure for data science. In their
>> favourite editor, of course!
>> 
>> 
>> Jony
> 
> 
> 
> That's a good idea, but I'd also like to say a bit more about the
> pro/con-emacs discussion, which I hope to be constructive.
> 
> I think I actually agree with most of the comments both by the
> emacs critics and the emacs proponents in this thread. Even the
> most intense ones, on both sides. But rather than worrying about
> who is more correct I want to point out that it's entirely
> possible, and would be gloriously beautiful, for an emacs-based
> Clojure environment to be produced that:
> 
> - Can be downloaded in a single click and run with one more click
> to do basic Clojure development with no further configuration, on
> Mac/Windows/Linux.
> 
> - Provides reasonably standard GUI elements (familiar to any
> computer user without reading a manual) for triggering core
> functionality and for discovering additional features.
> 
> As some have mentioned in this thread, a lot of work has been done
> on easing configuration (by people on this list among others) and
> there are some GUI-based packages out there, but as far as I know
> there's nothing that comes close to meeting both of the bullet
> points above. I think that most emacs-based folks either don't
> think this is possible or don't see it as a priority, but something
> like this must be possible (and there have been things close to
> this for other Lisps in the past), and  if it became a reality that
> I would switch to it for all of my coding and teaching and I'd
> evangelize it from the rooftops.
> 
> I'm not in a position to do development work on this myself, but I
> believe quite fervently that this would be a fabulous thing for the
> Clojure community.
> 
> I'd be happy to discuss this further off-list and/or beta-test
> projects aimed at these goals.

I have failed to setup Emacs for development and used Vim or Eclipse
primarily before entering Clojure-land. emacs-live allowed me to just
execute a shell script and get a decent Clojure environment which I
have used for 2 years until I have reconfigured my emacs having a
better understanding. Its emphasis on live-coding inspired by
composing music is a very compelling. The only thing I had to add to
emacs live was evil-mode, which wasn't too hard.

Also installing packages in emacs 24 is a breeze, no match to Eclipse
plugin repository mess and screw-ups and I don't want to use a closed
source IDE. No matter how many resources you have, being able to run
emacs in a shared tmux session is a big plus. I even have aliased
emacs-client as vim, so I don't have to rethink starting vim for quick
edits and still do it in a common emacs environment. I also find it
interesting that Rich still uses inferior-lisp mode and I think people
get too obsessed with tooling. I usually wait until it really hurts
and then I try to adjust my tooling.

It is really important that the nrepl middleware is shared between
IDEs and I had the impression recently that Cursive and others started
to integrate features directly into the IDE, which I don't think is a
good strategy.

A thankful shoutout again to the emacs-live maintainers!
https://github.com/overtone/emacs-live

Christian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVGU+dAAoJEKel+aujRZMkMRIH+gJJ1rLqB4NZNDZHmZSz6E2W
7OwsDXcn7bqZeaGv/s/VRjZ9Hk6saxS2hJP+PEzWSnXU48fBvYSAU8tu657U85tk
wFuWqm2A5kl/RyKwukYY1o05GYmVQvkGA2cKM63rTItXL/4pkhMpMQhwkOZHe1Zt
ZesL4A8B1A5jiZqp3bwhHIt/c1Awi33XG2BrFmMqdlSINJ3t0ADDNZra5328G1yZ
eZDIO+ljRISkfxAOz/u45yi/KT9mDWe7AXqhavKwDFXbFZxmofrPNAHYRkB/+WuY
vZAuw+zyVvY8NyBmBNKW1b5oqljQtUBQxSbNdC1sdE9Z1pe2yYsyOD0Jp3EZjR0=
=jt1D
-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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from 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: clojure, not the go to for data science

[Timothy Baldridge]

>> That's a good idea, but I'd also like to say a bit more about the
pro/con-emacs discussion, which I hope to be constructive.

Discussion is often a good idea, but in a dedicated thread. Perhaps it's
time to fork the original topic so that this discussion about editors can
continue without derailing this thread even further.

Timothy

On Mon, Mar 30, 2015 at 7:12 AM, Lee Spector  wrote:

> > On Mar 30, 2015, at 7:35 AM, Jony Hudson  wrote:
> >
> > I propose, instead of this discussion, everyone channels their energy
> into writing an open-source data-science library, or blog post/article
> promoting Clojure for data science. In their favourite editor, of course!
> >
> >
> > Jony
>
>
>
> That's a good idea, but I'd also like to say a bit more about the
> pro/con-emacs discussion, which I hope to be constructive.
>
> I think I actually agree with most of the comments both by the emacs
> critics and the emacs proponents in this thread. Even the most intense
> ones, on both sides. But rather than worrying about who is more correct I
> want to point out that it's entirely possible, and would be gloriously
> beautiful, for an emacs-based Clojure environment to be produced that:
>
> - Can be downloaded in a single click and run with one more click to do
> basic Clojure development with no further configuration, on
> Mac/Windows/Linux.
>
> - Provides reasonably standard GUI elements (familiar to any computer user
> without reading a manual) for triggering core functionality and for
> discovering additional features.
>
> As some have mentioned in this thread, a lot of work has been done on
> easing configuration (by people on this list among others) and there are
> some GUI-based packages out there, but as far as I know there's nothing
> that comes close to meeting both of the bullet points above. I think that
> most emacs-based folks either don't think this is possible or don't see it
> as a priority, but something like this must be possible (and there have
> been things close to this for other Lisps in the past), and  if it became a
> reality that I would switch to it for all of my coding and teaching and I'd
> evangelize it from the rooftops.
>
> I'm not in a position to do development work on this myself, but I believe
> quite fervently that this would be a fabulous thing for the Clojure
> community.
>
> I'd be happy to discuss this further off-list and/or beta-test projects
> aimed at these goals.
>
>  -Lee
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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.
>



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

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

Re: clojure, not the go to for data science

[Lee Spector]

> On Mar 30, 2015, at 7:35 AM, Jony Hudson  wrote:
> 
> I propose, instead of this discussion, everyone channels their energy into 
> writing an open-source data-science library, or blog post/article promoting 
> Clojure for data science. In their favourite editor, of course!
> 
> 
> Jony



That's a good idea, but I'd also like to say a bit more about the pro/con-emacs 
discussion, which I hope to be constructive.

I think I actually agree with most of the comments both by the emacs critics 
and the emacs proponents in this thread. Even the most intense ones, on both 
sides. But rather than worrying about who is more correct I want to point out 
that it's entirely possible, and would be gloriously beautiful, for an 
emacs-based Clojure environment to be produced that:

- Can be downloaded in a single click and run with one more click to do basic 
Clojure development with no further configuration, on Mac/Windows/Linux.

- Provides reasonably standard GUI elements (familiar to any computer user 
without reading a manual) for triggering core functionality and for discovering 
additional features.

As some have mentioned in this thread, a lot of work has been done on easing 
configuration (by people on this list among others) and there are some 
GUI-based packages out there, but as far as I know there's nothing that comes 
close to meeting both of the bullet points above. I think that most emacs-based 
folks either don't think this is possible or don't see it as a priority, but 
something like this must be possible (and there have been things close to this 
for other Lisps in the past), and  if it became a reality that I would switch 
to it for all of my coding and teaching and I'd evangelize it from the rooftops.

I'm not in a position to do development work on this myself, but I believe 
quite fervently that this would be a fabulous thing for the Clojure community.

I'd be happy to discuss this further off-list and/or beta-test projects aimed 
at these goals.

 -Lee




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

[Colin Fleming]

Without wanting to get involved in this discussion, I'd just like to point
out that there's plenty of anti-IntelliJ trolling goes on in the Clojure
community as well. The trick is just to ignore it, something that I mostly
manage to do.

I'd also like to second Jony's suggestion that we also talk a bit about
data science, which was the original question.

On 31 March 2015 at 01:53, Fluid Dynamics  wrote:

> On Monday, March 30, 2015 at 7:23:00 AM UTC-4, Tassilo Horn wrote:
>>
>> Fluid Dynamics  writes:
>>
>> > * Further to the resource-usage issue, i can more easily use Emacs
>> > remotely over low-bandwidth links than i could use an IDE.
>> >
>> > Typical home and mobile connection speeds are multiple MBPS these days.
>>
>> Still, running Eclipse or some other IDE via X forwarding isn't too much
>> fun even with X2Go.
>>
>
> Most people these days also have all their devices, even the handheld
> ones, powerful enough to run a decent IDE locally, which can work with
> local files or connect to a remote git repository. This obviates the need
> to SSH or telnet into a remote host and run both the editor AND the
> repository there, or to use X forwarding.
>
> > Unfortunately, one MUST do all of that and CANNOT use it as a black
>> > box, because it is the software analogue of a computer with no
>> > keyboard or monitor or anything else resembling a user interface, so
>> > one must toggle everything in and know the hardware internals
>> > backwards and forwards to get anything done. :)
>>
>> That's nonsense.  As soon as you have made yourself acquainted with the
>> basic Emacs terminology and concepts, getting started with Clojure
>> development is a piece of cake.  Of course,
>
>
> the devil is in the details. Including the implementation details that
> leak out all over the place, starting with the ubiquitous use of the term
> "buffer" in user-facing documentation.
>
>
>> Emacs follows the unicode standard and represents characters as
>> UTF8-encoded codepoints.
>>
>
> All very useful, right up until the time comes to display such strings to
> ttya0 :)
>
> > Rather, the last time I tried using emacs, I seem to recall always
>> > ending up with this sequence of events:
>> >
>> > a) I am trying to do some task X, for which the obvious key combination
>> bleeps
>> > or does something weird but definitely doesn't do X for some reason.
>> > b) Soon, I have a split pane with my document on the left and the help
>> files on
>> > the right, with the latter open to a page on task X and the input focus
>> in it.
>> > c) A little bit later, I have a split pane with my document on the
>> left, the
>> > input focus in my document, and the help pane on the right open to a
>> page on
>> > how to switch focus between panes, and I don't remember the long and
>> > complicated sequence of keystrokes needed to perform task X any more
>> because it
>> > was deleted from my brain's short term memory to remember the long and
>> > complicated sequence of keystrokes that is how one says "alt+tab" in
>> the
>> > obscure and archaic dialect known as emacsese.
>> > d) Repeat b) and c) a few times, while experiencing an acute event of
>> abnormal
>> > pre-menopausal hair loss.
>> > e) Give up and fire up Notepad, Eclipse, or whatever seems best suited
>> to
>> > current task. ;)
>>
>> I think with "help pane" you mean a window showing the Emacs info
>> manual.
>
>
> Oh, if only. If it had been an actual window, I'd have been able to use
> OS-native window switching to switch between it and the document I was
> working on, and leave the help window open to something other than the how
> to switch panes topic! :)
>
>  You can have as many of them open as you like, say, one for
>> "task X", and one for "switching focus between windows".
>>
>
> And then have what, two 27x24 and a 26x24 keyhole to squint through at
> everything? :) Less a couple of lines at the bottom for status
> notifications and the little command input area, of course.
>
> > * The Emacs ecosystem is growing rapidly; http://melpa.org/
>> > currently lists ~2400 packages ("extensions" or "addons")
>> > available for easy installation via Emacs' package.el UI.
>> >
>> >
>> > I wonder how anyone can find anything in that mess.
>>
>> Searching might be a start.
>>
>
> If searching in emacs was as intuitive as control-F and type in a
> substring to look for, it likely would be. :)
>
> > The Java and Clojure IDEs are probably each sandwiched amongst
>> > hundreds of consecutive entries
>>
>> Yes, of course.  Hey, how to people use apt-get/packman/yum/whatever?
>> The packages needed for "task X" are sandwiched between tens of
>> thousands of unrelated packages.
>>
>
> For something like Ubuntu, there's probably a nicely designed searchable
> website not entirely unlike the Firefox addons site Moz runs. Given the
> vintage of the emacs "user experience" (I use this term loosely), its
> version probably is a textual alphabetical list with a blinking prompt at

Re: clojure, not the go to for data science

[Fluid Dynamics]

On Monday, March 30, 2015 at 7:23:00 AM UTC-4, Tassilo Horn wrote:
>
> Fluid Dynamics > writes: 
>
> > * Further to the resource-usage issue, i can more easily use Emacs 
> > remotely over low-bandwidth links than i could use an IDE. 
> > 
> > Typical home and mobile connection speeds are multiple MBPS these days. 
>
> Still, running Eclipse or some other IDE via X forwarding isn't too much 
> fun even with X2Go. 
>

Most people these days also have all their devices, even the handheld ones, 
powerful enough to run a decent IDE locally, which can work with local 
files or connect to a remote git repository. This obviates the need to SSH 
or telnet into a remote host and run both the editor AND the repository 
there, or to use X forwarding.

> Unfortunately, one MUST do all of that and CANNOT use it as a black 
> > box, because it is the software analogue of a computer with no 
> > keyboard or monitor or anything else resembling a user interface, so 
> > one must toggle everything in and know the hardware internals 
> > backwards and forwards to get anything done. :) 
>
> That's nonsense.  As soon as you have made yourself acquainted with the 
> basic Emacs terminology and concepts, getting started with Clojure 
> development is a piece of cake.  Of course,


the devil is in the details. Including the implementation details that leak 
out all over the place, starting with the ubiquitous use of the term 
"buffer" in user-facing documentation.
 

> Emacs follows the unicode standard and represents characters as 
> UTF8-encoded codepoints.
>

All very useful, right up until the time comes to display such strings to 
ttya0 :)

> Rather, the last time I tried using emacs, I seem to recall always 
> > ending up with this sequence of events: 
> > 
> > a) I am trying to do some task X, for which the obvious key combination 
> bleeps 
> > or does something weird but definitely doesn't do X for some reason. 
> > b) Soon, I have a split pane with my document on the left and the help 
> files on 
> > the right, with the latter open to a page on task X and the input focus 
> in it. 
> > c) A little bit later, I have a split pane with my document on the left, 
> the 
> > input focus in my document, and the help pane on the right open to a 
> page on 
> > how to switch focus between panes, and I don't remember the long and 
> > complicated sequence of keystrokes needed to perform task X any more 
> because it 
> > was deleted from my brain's short term memory to remember the long and 
> > complicated sequence of keystrokes that is how one says "alt+tab" in the 
> > obscure and archaic dialect known as emacsese. 
> > d) Repeat b) and c) a few times, while experiencing an acute event of 
> abnormal 
> > pre-menopausal hair loss. 
> > e) Give up and fire up Notepad, Eclipse, or whatever seems best suited 
> to 
> > current task. ;) 
>
> I think with "help pane" you mean a window showing the Emacs info 
> manual.


Oh, if only. If it had been an actual window, I'd have been able to use 
OS-native window switching to switch between it and the document I was 
working on, and leave the help window open to something other than the how 
to switch panes topic! :)

 You can have as many of them open as you like, say, one for 
> "task X", and one for "switching focus between windows".
>

And then have what, two 27x24 and a 26x24 keyhole to squint through at 
everything? :) Less a couple of lines at the bottom for status 
notifications and the little command input area, of course.

> * The Emacs ecosystem is growing rapidly; http://melpa.org/ 
> > currently lists ~2400 packages ("extensions" or "addons") 
> > available for easy installation via Emacs' package.el UI. 
> > 
> > 
> > I wonder how anyone can find anything in that mess. 
>
> Searching might be a start.
>

If searching in emacs was as intuitive as control-F and type in a substring 
to look for, it likely would be. :) 

> The Java and Clojure IDEs are probably each sandwiched amongst 
> > hundreds of consecutive entries 
>
> Yes, of course.  Hey, how to people use apt-get/packman/yum/whatever? 
> The packages needed for "task X" are sandwiched between tens of 
> thousands of unrelated packages.
>

For something like Ubuntu, there's probably a nicely designed searchable 
website not entirely unlike the Firefox addons site Moz runs. Given the 
vintage of the emacs "user experience" (I use this term loosely), its 
version probably is a textual alphabetical list with a blinking prompt at 
the bottom, with no perceived affordances of any way to search or jump 
nonlinearly within the list, and unless you're lucky perhaps not even an 
obvious way to page down and page up. (The keys on every keyboard bearing 
those precise labels, no doubt, beep and do nothing else, or else do things 
entirely unrelated to paging down and up, this being emacs we're discussing 
after all.)

> all the rest of which are for languages nobody has ever heard of 
> > outside of one obsc

Re: clojure, not the go to for data science

[Jony Hudson]

I propose, instead of this discussion, everyone channels their energy into 
writing an open-source data-science library, or blog post/article promoting 
Clojure for data science. In their favourite editor, of course!


Jony


On Sunday, 29 March 2015 10:55:34 UTC+1, Sayth Renshaw wrote:
>
> Hi 
>
> I last learned clojure in 1.2. Just curious why Clojure hasn't developed 
> as a go to for data science? 
>
> It never seems to get a mention R,Python and now Julia get the attention. 
> By design it would appear that Clojure would be a good fit. Is it a lack of 
> libraries, ease of install, no good default environment  (R Rstudio, 
> IPython ) where as you would need to use emacs with clojure, or is there 
> just a better default use of Clojure? 
>
> Sayth

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

[Alexis]

i'm assuming this response is a troll, given the use of the sort 
of gratuitous insults that Bozhidar mentioned; specific examples 
noted below. (And this somewhat amuses me, given the recent 
discussion about whether it's possible to critique different 
technologies without resorting to doing little more than 
trash-talking them.)


If it's /not/ intended to be a troll, then i feel it pretty much 
providing data which substantiates Bozhidar's complaint.


At any rate, on this occasion, i'll respond to a number of the 
points made; but feel free to have the final word (and sling some 
more gratuitous insults).


Fluid Dynamics  writes: 

* i don't have to learn and use a distinct, possibly  
  resource-hungry,  IDE[2] for every new programming language 
  or environment i  need/want to work in. (When the Swift 
  language was released, for  example, basic Swift support in 
  the form of `swift-mode` became  available within less than a 
  week.)  


Eclipse has plugins for a wide variety of languages.  


True, but i don't think i've ever heard that one of Eclipse's main 
selling points is that it's light on resource usage.


* Further to the resource-usage issue, i can more easily use 
Emacs  
  remotely over low-bandwidth links than i could use an IDE.  


Typical home and mobile connection speeds are multiple MBPS 
these days.


You respond to me saying that /i/ like Emacs for its ease-of-use 
across low-bandwidth links (which i regularly have to deal with) 
by  what, implying that i should be a so-called 'typical' 
home/mobile connection user instead?


Anyway, 'typical' varies from geographic location to geographic 
location. My home connection is ADSL2+, but my mobile provides 4G 
speeds only within a limited geographic area - and when i visited 
the city of Newcastle, New South Wales, recently, with it's 
population of ~300,000, my mobile data connection was 
intermittent, let alone of a decent speed. In such a situation, 
i've found being able to use a text-based UI, rather than being 
forced to use a graphical UI (even using something like NoMachine) 
quite a boon.


Further, even ADSL2+ bandwidth can be heavily saturated when other 
people on the connection are e.g. streaming HD movies at the same 
time as one is trying to work on a remote system 


* IDEs typically don't allow one to change their basic 
behaviours  
  whilst  they're running. Related: if there's a bug fix or 
  feature i want  applied, i can apply it myself, rather than 
  having to hope that  the maintainers will (a) accept that 
  it's something that  /should/ be applied, and (b) actually 
  apply it.  


The second, at least, applies to every open source IDE, 
including a certain EPL-licensed one. 


Not quite, at least not insofar as i understand what you're 
saying. i'm talking about not having to patch the source tree and 
recompile, even across new versions. In my Emacs config, i've 
redefined a few different Emacs functions to behave the way i 
want, such that, even when i install a new version of Emacs, i 
don't need to make any changes to the source itself to get the 
desired behaviour.


Unfortunately, one MUST do all of that and CANNOT use it as a 
black box, because it is the software analogue of a computer 
with no keyboard or monitor or anything else resembling a user 
interface, so one must toggle everything in and know the 
hardware internals backwards and forwards to get anything 
done. :)


A strong claim, considerably stronger than the weaker claim that 
Emacs needs tweaking to get to one's 'ideal' workflow, or even 
that Emacs needs more tweaking than other software to get to that 
workflow. i actually agree with the latter claim, but also feel 
that /for me/ the the benefits of doing most of it just once in 
Emacs have vastly outweighed the costs. i certainly acknowledge, 
howver, that this is a classic instance of 'YMMV'. 

Of course, there are some IDEs that run on top of the JVM, and 
are thus as widely available platform-wise as the JVM ... 


Granted. 

* Emacs is the product of approximately three decades of 
constant  
  development, such that it handles many corner-cases of many 
  scenarios (e.g. in the area of i18n) and continues to adapt 
  to  new ones.  


Three decades worth of accumulated legacy code. I can barely 
begin to  imagine what horrors must be lurking in some of the 
darker and less  well-traveled corners of that thing's /src 
directory. But you could  probably form a fairly accurate basic 
picture by reading the collected  works of one H. P. Lovecraft 
... :) 


A gratuitous insult, but sure, see http://emacshorrors.com/ for 
such examples.


Still, it's easy to dismiss the ugliness of legacy code when one 
doesn't have the luxury of not having to deal with the needs of a 
diverse user base over an extended period of time:


http://www.joelonsoftware.com/articles/fog69.html

And what kind of i18n corner cases tend to arise with a 7-bit 
80x24 character-based displ

Re: clojure, not the go to for data science

[Tassilo Horn]

Fluid Dynamics  writes:

> * i don't have to learn and use a distinct, possibly
> resource-hungry, IDE[2] for every new programming language or
> environment i need/want to work in. (When the Swift language was
> released, for example, basic Swift support in the form of
> `swift-mode` became available within less than a week.)
>
> Eclipse has plugins for a wide variety of languages. 

My experience has been that many plugins except for the really major
ones are frequently incompatible.  I.e., some cool plugin appears and
with the next eclipse release it won't work anymore because its
maintainers have a hard time keeping it up-to-date.

For that reason, it is not uncommon that people set up separate eclipse
installations for each and every project which has the exact version
required by the plugins needed for that project.

> * Further to the resource-usage issue, i can more easily use Emacs 
> remotely over low-bandwidth links than i could use an IDE. 
>
> Typical home and mobile connection speeds are multiple MBPS these days. 

Still, running Eclipse or some other IDE via X forwarding isn't too much
fun even with X2Go.

> * In my experience, Emacs tends to be less of a 'black box' than
> some IDEs, in that i can more easily get a better sense of what's
> going on "behind the scenes". This in turn means that i've got a
> better sense of the relevant build system, and how to fix and/or
> tune it in particular circumstances.
>
> Unfortunately, one MUST do all of that and CANNOT use it as a black
> box, because it is the software analogue of a computer with no
> keyboard or monitor or anything else resembling a user interface, so
> one must toggle everything in and know the hardware internals
> backwards and forwards to get anything done. :)

That's nonsense.  As soon as you have made yourself acquainted with the
basic Emacs terminology and concepts, getting started with Clojure
development is a piece of cake.  Of course, knowing more than that will
make it easier to make best use of its features and adapt it to your
personal preferences but that's the same with IDEs, too.

> And what kind of i18n corner cases tend to arise with a 7-bit 80x24
> character-based display (or emulation of same)?

Emacs follows the unicode standard and represents characters as
UTF8-encoded codepoints.

> * Emacs is, in my experience, one of the best-documented pieces of 
> software i've encountered. Absent or poor documentation is 
> typically treated as a bug. 
>
> The issue with its documentation isn't, of course, its existence or
> comprehensiveness.

No, but that's the issue many IDEs have.  Usually, you have a button or
a menu entry for some functionality possibly with some tooltip, and
that's as much "documentation" as you get.

> Rather, the last time I tried using emacs, I seem to recall always
> ending up with this sequence of events:
>
> a) I am trying to do some task X, for which the obvious key combination bleeps
> or does something weird but definitely doesn't do X for some reason.
> b) Soon, I have a split pane with my document on the left and the help files 
> on
> the right, with the latter open to a page on task X and the input focus in it.
> c) A little bit later, I have a split pane with my document on the left, the
> input focus in my document, and the help pane on the right open to a page on
> how to switch focus between panes, and I don't remember the long and
> complicated sequence of keystrokes needed to perform task X any more because 
> it
> was deleted from my brain's short term memory to remember the long and
> complicated sequence of keystrokes that is how one says "alt+tab" in the
> obscure and archaic dialect known as emacsese.
> d) Repeat b) and c) a few times, while experiencing an acute event of abnormal
> pre-menopausal hair loss.
> e) Give up and fire up Notepad, Eclipse, or whatever seems best suited to
> current task. ;)

I think with "help pane" you mean a window showing the Emacs info
manual.  You can have as many of them open as you like, say, one for
"task X", and one for "switching focus between windows".

> * The Emacs ecosystem is growing rapidly; http://melpa.org/
> currently lists ~2400 packages ("extensions" or "addons")
> available for easy installation via Emacs' package.el UI.
>
>
> I wonder how anyone can find anything in that mess.

Searching might be a start.

> The Java and Clojure IDEs are probably each sandwiched amongst
> hundreds of consecutive entries

Yes, of course.  Hey, how to people use apt-get/packman/yum/whatever?
The packages needed for "task X" are sandwiched between tens of
thousands of unrelated packages.

> all the rest of which are for languages nobody has ever heard of
> outside of one obscure city near Bernhöfen, or that nobody has used
> since 1987, or that nobody has used period because the whole thing was
> invented as an obscure joke (e.g.  Befunge).

I don't see how support for nic

Re: clojure, not the go to for data science

[Fluid Dynamics]

On Monday, March 30, 2015 at 4:18:03 AM UTC-4, Alexis wrote:
>
>
> Bozhidar Batsov > writes: 
>
> > Anti-Emacs stuff really gets to me. 
>
> i too find it somewhat tiresome. It makes me wonder how many 
> people have actually stopped and asked themselves: "Given that 
> Emacs seems like a crusty ancient artifact from The Land That Time 
> Forgot, why do so many people keep using it?" 
>
> i can't speak for other Emacs users, of course, but here are some 
> of the main reasons i prefer to use (GNU) Emacs[1]: 
>
> * i don't have to learn and use a distinct, possibly 
>   resource-hungry, 
>   IDE[2] for every new programming language or environment i 
>   need/want to work in. (When the Swift language was released, for 
>   example, basic Swift support in the form of `swift-mode` became 
>   available within less than a week.) 
>

Eclipse has plugins for a wide variety of languages. 

* Further to the resource-usage issue, i can more easily use Emacs 
>   remotely over low-bandwidth links than i could use an IDE. 
>

Typical home and mobile connection speeds are multiple MBPS these days. 

* IDEs typically don't allow one to change their basic behaviours 
>   whilst 
>   they're running. Related: if there's a bug fix or feature i want 
>   applied, i can apply it myself, rather than having to hope that 
>   the maintainers will (a) accept that it's something that 
>   /should/ be applied, and (b) actually apply it. 
>

The second, at least, applies to every open source IDE, including a certain 
EPL-licensed one.
 

> * In my experience, Emacs tends to be less of a 'black box' than 
>   some 
>   IDEs, in that i can more easily get a better sense of what's 
>   going on "behind the scenes". This in turn means that i've got a 
>   better sense of the relevant build system, and how to fix and/or 
>   tune it in particular circumstances.
>

Unfortunately, one MUST do all of that and CANNOT use it as a black box, 
because it is the software analogue of a computer with no keyboard or 
monitor or anything else resembling a user interface, so one must toggle 
everything in and know the hardware internals backwards and forwards to get 
anything done. :) 

* Emacs is available for a wider range of platforms than most 
>   IDEs, 
>   meaning it's more likely to be available to me should i need to 
>   work on a particular platform. 
>

Of course, there are some IDEs that run on top of the JVM, and are thus as 
widely available platform-wise as the JVM ...
 

> * Emacs is the product of approximately three decades of constant 
>   development, such that it handles many corner-cases of many 
>   scenarios (e.g. in the area of i18n) and continues to adapt to 
>   new ones. 
>

Three decades worth of accumulated legacy code. I can barely begin to 
imagine what horrors must be lurking in some of the darker and less 
well-traveled corners of that thing's /src directory. But you could 
probably form a fairly accurate basic picture by reading the collected 
works of one H. P. Lovecraft ... :)

And what kind of i18n corner cases tend to arise with a 7-bit 80x24 
character-based display (or emulation of same)? Just out of curiosity.

* Emacs is, in my experience, one of the best-documented pieces of 
>   software i've encountered. Absent or poor documentation is 
>   typically treated as a bug. 
>

The issue with its documentation isn't, of course, its existence or 
comprehensiveness. Rather, the last time I tried using emacs, I seem to 
recall always ending up with this sequence of events:

a) I am trying to do some task X, for which the obvious key combination 
bleeps or does something weird but definitely doesn't do X for some reason.
b) Soon, I have a split pane with my document on the left and the help 
files on the right, with the latter open to a page on task X and the input 
focus in it.
c) A little bit later, I have a split pane with my document on the left, 
the input focus in my document, and the help pane on the right open to a 
page on how to switch focus between panes, and I don't remember the long 
and complicated sequence of keystrokes needed to perform task X any more 
because it was deleted from my brain's short term memory to remember the 
long and complicated sequence of keystrokes that is how one says "alt+tab" 
in the obscure and archaic dialect known as emacsese.
d) Repeat b) and c) a few times, while experiencing an acute event of 
abnormal pre-menopausal hair loss.
e) Give up and fire up Notepad, Eclipse, or whatever seems best suited to 
current task. ;)

* The Emacs ecosystem is growing rapidly; http://melpa.org/ 
>   currently 
>   lists ~2400 packages ("extensions" or "addons") available for 
>   easy installation via Emacs' package.el UI. 
>

I wonder how anyone can find anything in that mess. The Java and Clojure 
IDEs are probably each sandwiched amongst hundreds of consecutive entries 
all the rest of which are for languages nobody has ever heard of outside of 
one obscure city near Bernhöfen, or

Re: clojure, not the go to for data science

[Alexis]

Colin Yates  writes:


I used it a few years back


[snip]

[and] even after man-months spent tinkering, hunting down the 
right version on MELPA or MARMALADE (or whatever it is called)


MELPA and Marmalade are two separate ELPAs ("Emacs Lisp Package 
Archives") - others include MELPA Stable, GNU ELPA and quelpa.


i basically only use MELPA and GNU ELPA. In terms of the ~200 
packages i've installed from MELPA, i can't remember having to 
deal with versioning issues at all. Further, despite some people 
fretting about the theoretical lack of stability of packages on 
MELPA, i've only rarely had to deal with broken packages - and 
those breakages have been fixed very rapidly by the 
maintainers. (i maintain a few ELisp packages myself, and also 
work to address issues with my packages promptly.)



I still couldn't get close to what Cursive gives me OOTB.


*nod*

However, Emacs configuration management has, i feel, improved 
significantly over the last couple of years, with things like 
`use-package`:


https://github.com/jwiegley/use-package

or `pallet`:

https://github.com/rdallasgray/pallet

enabling one to create easily-reproducible config setups across 
environments/machines.



Alexis.

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

To unsubscribe from 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: clojure, not the go to for data science

[Colin Yates]

For me personally, I absolutely admire emacs - I really do. I used it
a few years back when I first started in Clojure before Cursive was
around and when it was configured correctly it was absolutely great.
>From an engineering POV, yeah, it rocks.

I am sure that for anything I can do in IDE-X I can do it in emacs.
The major difference is, and the reason that I no longer use emacs is
that IDE-X _probably_ ships it out of the box (or at least is one or
two plugins away), and this is very important when you end up
re-installing stuff a lot on your machine and co-developers. Yeah, I
know, git your .emacs or use one of the curated packs (of which
Batsov's is absolutely great), but even after man-months spent
tinkering, hunting down the right version on MELPA or MARMALADE (or
whatever it is called) I still couldn't get close to what Cursive
gives me OOTB.

Emacs to me was something that could be absolutely great, but I just
ran out of time making it so. Do I feel part of the
'I'm-not-clever-enough-to-make-emacs-work-properly' club - sure :).

Emacs is great if you want to build your own editor, anything else is
great if you need to work now.

On 30 March 2015 at 05:32, Alexis  wrote:
>
> Bozhidar Batsov  writes:
>
>> Anti-Emacs stuff really gets to me.
>
>
> i too find it somewhat tiresome. It makes me wonder how many people have
> actually stopped and asked themselves: "Given that Emacs seems like a crusty
> ancient artifact from The Land That Time Forgot, why do so many people keep
> using it?"
>
> i can't speak for other Emacs users, of course, but here are some of the
> main reasons i prefer to use (GNU) Emacs[1]:
>
> * i don't have to learn and use a distinct, possibly  resource-hungry,
> IDE[2] for every new programming language or environment i  need/want to
> work in. (When the Swift language was released, for  example, basic Swift
> support in the form of `swift-mode` became  available within less than a
> week.)
>
> * Further to the resource-usage issue, i can more easily use Emacs  remotely
> over low-bandwidth links than i could use an IDE.
>
> * IDEs typically don't allow one to change their basic behaviours  whilst
> they're running. Related: if there's a bug fix or feature i want  applied, i
> can apply it myself, rather than having to hope that  the maintainers will
> (a) accept that it's something that  /should/ be applied, and (b) actually
> apply it.
>
> * In my experience, Emacs tends to be less of a 'black box' than  some
> IDEs, in that i can more easily get a better sense of what's  going on
> "behind the scenes". This in turn means that i've got a  better sense of the
> relevant build system, and how to fix and/or  tune it in particular
> circumstances.
>
> * Emacs is available for a wider range of platforms than most  IDEs,
> meaning it's more likely to be available to me should i need to  work on a
> particular platform.
>
> * Emacs is the product of approximately three decades of constant
> development, such that it handles many corner-cases of many  scenarios (e.g.
> in the area of i18n) and continues to adapt to  new ones.
>
> * Emacs is, in my experience, one of the best-documented pieces of  software
> i've encountered. Absent or poor documentation is  typically treated as a
> bug.
>
> * The Emacs ecosystem is growing rapidly; http://melpa.org/  currently
> lists ~2400 packages ("extensions" or "addons") available for  easy
> installation via Emacs' package.el UI.
>
> * Clojure-oriented point #1: since ~80%[3] of Emacs is written in  Emacs
> Lisp, a lot of work has been put into support for sexp-based  languages; cf.
> `paredit`.
>
> * Clojure-oriented point #2: having a polyglot dev system written  in an
> easily-modifiable Lisp environment makes it more attractive to  me as
> someone with a Lisp mindset, as per my interest in  Clojure. :-)
>
> Yes, there can be a steeper initial learning curve with Emacs than with
> IDEs, e.g. things like 'frames' and 'windows' not meaning what one might
> expect (which is hardly surprising, given that GNU Emacs predates the
> existence of GUIs-as-standard, and the Web). Yet this is a one-time cost
> that, in my experience, is rapidly amortised as one starts to use Emacs in
> an increasingly wider variety of contexts. For example: being able to use
> CIDER when i wanted to start learning Clojure meant that i could focus on
> learning Clojure itself, rather than an entire new dev system.
>
> Emacs is surely not the best tool for all developers in all contexts, but i
> also feel it's something that developers - and Clojure developers in
> particular - should perhaps at least give a second look.
>
>
> Alexis.
>
> ---
>
> [1] Or Vim, if Emacs isn't an option. Some things i mention here arealso
> applicable to use of Vim.
>
> [2] In the /literal/ sense of the phrase, Emacs can indeed provide an
> Integrated Development Environment. But obviously, i'm herereferring to
> highly graphical IDEs such as Eclipse.
> [3] According to David A. Wheele

Re: clojure, not the go to for data science

[Alexis]

Bozhidar Batsov  writes:


Anti-Emacs stuff really gets to me.


i too find it somewhat tiresome. It makes me wonder how many 
people have actually stopped and asked themselves: "Given that 
Emacs seems like a crusty ancient artifact from The Land That Time 
Forgot, why do so many people keep using it?"


i can't speak for other Emacs users, of course, but here are some 
of the main reasons i prefer to use (GNU) Emacs[1]:


* i don't have to learn and use a distinct, possibly 
 resource-hungry, 
 IDE[2] for every new programming language or environment i 
 need/want to work in. (When the Swift language was released, for 
 example, basic Swift support in the form of `swift-mode` became 
 available within less than a week.)


* Further to the resource-usage issue, i can more easily use Emacs 
 remotely over low-bandwidth links than i could use an IDE.


* IDEs typically don't allow one to change their basic behaviours 
 whilst 
 they're running. Related: if there's a bug fix or feature i want 
 applied, i can apply it myself, rather than having to hope that 
 the maintainers will (a) accept that it's something that 
 /should/ be applied, and (b) actually apply it.


* In my experience, Emacs tends to be less of a 'black box' than 
 some 
 IDEs, in that i can more easily get a better sense of what's 
 going on "behind the scenes". This in turn means that i've got a 
 better sense of the relevant build system, and how to fix and/or 
 tune it in particular circumstances.


* Emacs is available for a wider range of platforms than most 
 IDEs, 
 meaning it's more likely to be available to me should i need to 
 work on a particular platform.


* Emacs is the product of approximately three decades of constant 
 development, such that it handles many corner-cases of many 
 scenarios (e.g. in the area of i18n) and continues to adapt to 
 new ones.


* Emacs is, in my experience, one of the best-documented pieces of 
 software i've encountered. Absent or poor documentation is 
 typically treated as a bug.


* The Emacs ecosystem is growing rapidly; http://melpa.org/ 
 currently 
 lists ~2400 packages ("extensions" or "addons") available for 
 easy installation via Emacs' package.el UI.


* Clojure-oriented point #1: since ~80%[3] of Emacs is written in 
 Emacs 
 Lisp, a lot of work has been put into support for sexp-based 
 languages; cf. `paredit`.


* Clojure-oriented point #2: having a polyglot dev system written 
 in an 
 easily-modifiable Lisp environment makes it more attractive to 
 me as someone with a Lisp mindset, as per my interest in 
 Clojure. :-)


Yes, there can be a steeper initial learning curve with Emacs than 
with IDEs, e.g. things like 'frames' and 'windows' not meaning 
what one might expect (which is hardly surprising, given that GNU 
Emacs predates the existence of GUIs-as-standard, and the 
Web). Yet this is a one-time cost that, in my experience, is 
rapidly amortised as one starts to use Emacs in an increasingly 
wider variety of contexts. For example: being able to use CIDER 
when i wanted to start learning Clojure meant that i could focus 
on learning Clojure itself, rather than an entire new dev system.


Emacs is surely not the best tool for all developers in all 
contexts, but i also feel it's something that developers - and 
Clojure developers in particular - should perhaps at least give a 
second look.



Alexis.

---

[1] Or Vim, if Emacs isn't an option. Some things i mention here 
are 
   also applicable to use of Vim.


[2] In the /literal/ sense of the phrase, Emacs can indeed provide 
an 
   Integrated Development Environment. But obviously, i'm here 
   referring to highly graphical IDEs such as Eclipse. 


[3] According to David A. Wheeler's sloccount(1) run on the Emacs 24.5.1
   sources.

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

To unsubscribe from 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: clojure, not the go to for data science

[Joseph Guhlin]

Incanter gets your pretty far, especially when combined with  Gorilla REPL, 
but all the tools and features aren't quite there yet, but progress is 
being made. There are a few features I really need for clojure that I think 
are out there, but aren't in core and I haven't found the external 
libraries to do it. 

I have things that crash in R (Revolution R Open) because the data is too 
large that clojure just processes without a second thought or memory 
overflow. 

Best,
--Joseph

On Sunday, March 29, 2015 at 4:55:34 AM UTC-5, Sayth Renshaw wrote:
>
> Hi 
>
> I last learned clojure in 1.2. Just curious why Clojure hasn't developed 
> as a go to for data science? 
>
> It never seems to get a mention R,Python and now Julia get the attention. 
> By design it would appear that Clojure would be a good fit. Is it a lack of 
> libraries, ease of install, no good default environment  (R Rstudio, 
> IPython ) where as you would need to use emacs with clojure, or is there 
> just a better default use of Clojure? 
>
> Sayth

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

[Sam Ritchie]

The older the fiddle...


Luc Préfontaine 
March 29, 2015 at 9:21 AM
It's fun to see that vintage tools are so much appreciated these days :)
Luc P.


--
Luc Préfontaine sent by ibisMail!

Joseph Smith 
March 29, 2015 at 8:26 AM
Batsov,

CIDER is the best Clojure IDE. ;)

--
@solussd


On Mar 29, 2015, at 9:14 AM, Bozhidar Batsov > wrote:


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

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google 
Groups "Clojure" group.
To unsubscribe from 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.
Bozhidar Batsov 
March 29, 2015 at 8:14 AM
And CIDER isn't, right? I find this pretty insulting...


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

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google 
Groups "Clojure" group.
To unsubscribe from 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.
Colin Yates 
March 29, 2015 at 4:47 AM
Cursive Clojure, LightTable and CounterClockwise are all good Clojure 
IDEs.


Sayth Renshaw 
March 29, 2015 at 2:54 AM
Hi

I last learned clojure in 1.2. Just curious why Clojure hasn't 
developed as a go to for data science?


It never seems to get a mention R,Python and now Julia get the 
attention. By design it would appear that Clojure would be a good fit. 
Is it a lack of libraries, ease of install, no good default 
environment (R Rstudio, IPython ) where as you would need to use emacs 
with clojure, or is there just a better default use of Clojure?


Sayth



--
Sam Ritchie (@sritchie)
Paddleguru Co-Founder
703.863.8561
www.paddleguru.com 
Twitter // Facebook 



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

To unsubscribe from 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: clojure, not the go to for data science

[Luc Préfontaine]

It's fun to see that vintage tools are so much appreciated these days :)
Luc P.


> Batsov,
> 
> CIDER is the best Clojure IDE. ;)
> 
> --
> @solussd
> 
> 
> > On Mar 29, 2015, at 9:14 AM, Bozhidar Batsov  wrote:
> > 
> > And CIDER isn't, right? I find this pretty insulting... 
> > 
> >> On 29 March 2015 at 13:47, Colin Yates  wrote:
> >> Cursive Clojure, LightTable and CounterClockwise are all good Clojure IDEs.
> >> 
> >> On 29 March 2015 at 09:54, Sayth Renshaw  wrote:
> >> > Hi
> >> >
> >> > I last learned clojure in 1.2. Just curious why Clojure hasn't developed 
> >> > as a go to for data science?
> >> >
> >> > It never seems to get a mention R,Python and now Julia get the 
> >> > attention. By design it would appear that Clojure would be a good fit. 
> >> > Is it a lack of libraries, ease of install, no good default environment  
> >> > (R Rstudio, IPython ) where as you would need to use emacs with clojure, 
> >> > or is there just a better default use of Clojure?
> >> >
> >> > Sayth
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> > Groups "Clojure" group.
> >> > To post to this group, send email to clojure@googlegroups.com
> >> > Note that posts from new members are moderated - please be patient with 
> >> > your first post.
> >> > To unsubscribe from this group, send email to
> >> > clojure+unsubscr...@googlegroups.com
> >> > For more options, visit this group at
> >> > http://groups.google.com/group/clojure?hl=en
> >> > ---
> >> > You received this message because you are subscribed to the Google 
> >> > Groups "Clojure" group.
> >> > To unsubscribe from 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.
> 
--
Luc Préfontaine 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/d/optout.

Re: clojure, not the go to for data science

[Bozhidar Batsov]

Just picking on the wording, that's all. Anti-Emacs stuff really gets to
me. Forget I ever said anything.

On 29 March 2015 at 17:17, Colin Yates  wrote:

> I assumed his reference to emacs covered CIDER - don't be so sensitive :).
>
> On 29 March 2015 at 15:14, Bozhidar Batsov  wrote:
> > And CIDER isn't, right? I find this pretty insulting...
> >
> >
> > On 29 March 2015 at 13:47, Colin Yates  wrote:
> >>
> >> Cursive Clojure, LightTable and CounterClockwise are all good Clojure
> >> IDEs.
> >>
> >> On 29 March 2015 at 09:54, Sayth Renshaw 
> wrote:
> >> > Hi
> >> >
> >> > I last learned clojure in 1.2. Just curious why Clojure hasn't
> developed
> >> > as a go to for data science?
> >> >
> >> > It never seems to get a mention R,Python and now Julia get the
> >> > attention. By design it would appear that Clojure would be a good
> fit. Is it
> >> > a lack of libraries, ease of install, no good default environment  (R
> >> > Rstudio, IPython ) where as you would need to use emacs with clojure,
> or is
> >> > there just a better default use of Clojure?
> >> >
> >> > Sayth
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> > Groups "Clojure" group.
> >> > To post to this group, send email to clojure@googlegroups.com
> >> > Note that posts from new members are moderated - please be patient
> with
> >> > your first post.
> >> > To unsubscribe from this group, send email to
> >> > clojure+unsubscr...@googlegroups.com
> >> > For more options, visit this group at
> >> > http://groups.google.com/group/clojure?hl=en
> >> > ---
> >> > You received this message because you are subscribed to the Google
> >> > Groups "Clojure" group.
> >> > To unsubscribe from 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.
>

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

[Joseph Smith]

Batsov,

CIDER is the best Clojure IDE. ;)

--
@solussd


> On Mar 29, 2015, at 9:14 AM, Bozhidar Batsov  wrote:
> 
> And CIDER isn't, right? I find this pretty insulting... 
> 
>> On 29 March 2015 at 13:47, Colin Yates  wrote:
>> Cursive Clojure, LightTable and CounterClockwise are all good Clojure IDEs.
>> 
>> On 29 March 2015 at 09:54, Sayth Renshaw  wrote:
>> > Hi
>> >
>> > I last learned clojure in 1.2. Just curious why Clojure hasn't developed 
>> > as a go to for data science?
>> >
>> > It never seems to get a mention R,Python and now Julia get the attention. 
>> > By design it would appear that Clojure would be a good fit. Is it a lack 
>> > of libraries, ease of install, no good default environment  (R Rstudio, 
>> > IPython ) where as you would need to use emacs with clojure, or is there 
>> > just a better default use of Clojure?
>> >
>> > Sayth
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, send email to clojure@googlegroups.com
>> > Note that posts from new members are moderated - please be patient with 
>> > your first post.
>> > To unsubscribe from this group, send email to
>> > clojure+unsubscr...@googlegroups.com
>> > For more options, visit this group at
>> > http://groups.google.com/group/clojure?hl=en
>> > ---
>> > You received this message because you are subscribed to the Google Groups 
>> > "Clojure" group.
>> > To unsubscribe from 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: clojure, not the go to for data science

[Colin Yates]

I assumed his reference to emacs covered CIDER - don't be so sensitive :).

On 29 March 2015 at 15:14, Bozhidar Batsov  wrote:
> And CIDER isn't, right? I find this pretty insulting...
>
>
> On 29 March 2015 at 13:47, Colin Yates  wrote:
>>
>> Cursive Clojure, LightTable and CounterClockwise are all good Clojure
>> IDEs.
>>
>> On 29 March 2015 at 09:54, Sayth Renshaw  wrote:
>> > Hi
>> >
>> > I last learned clojure in 1.2. Just curious why Clojure hasn't developed
>> > as a go to for data science?
>> >
>> > It never seems to get a mention R,Python and now Julia get the
>> > attention. By design it would appear that Clojure would be a good fit. Is 
>> > it
>> > a lack of libraries, ease of install, no good default environment  (R
>> > Rstudio, IPython ) where as you would need to use emacs with clojure, or is
>> > there just a better default use of Clojure?
>> >
>> > Sayth
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, send email to clojure@googlegroups.com
>> > Note that posts from new members are moderated - please be patient with
>> > your first post.
>> > To unsubscribe from this group, send email to
>> > clojure+unsubscr...@googlegroups.com
>> > For more options, visit this group at
>> > http://groups.google.com/group/clojure?hl=en
>> > ---
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To unsubscribe from 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: clojure, not the go to for data science

[Bozhidar Batsov]

And CIDER isn't, right? I find this pretty insulting...

On 29 March 2015 at 13:47, Colin Yates  wrote:

> Cursive Clojure, LightTable and CounterClockwise are all good Clojure IDEs.
>
> On 29 March 2015 at 09:54, Sayth Renshaw  wrote:
> > Hi
> >
> > I last learned clojure in 1.2. Just curious why Clojure hasn't developed
> as a go to for data science?
> >
> > It never seems to get a mention R,Python and now Julia get the
> attention. By design it would appear that Clojure would be a good fit. Is
> it a lack of libraries, ease of install, no good default environment  (R
> Rstudio, IPython ) where as you would need to use emacs with clojure, or is
> there just a better default use of Clojure?
> >
> > Sayth
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> > To unsubscribe from 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: clojure, not the go to for data science

[Bruce Durling]

On smaller data and prototypes we do data science with R, Python,
clojure, java and scala. All of our larger scale and production work
is done in clojure including data science.

cheers,
Bruce

On Sun, Mar 29, 2015 at 9:54 AM, Sayth Renshaw  wrote:
> Hi
>
> I last learned clojure in 1.2. Just curious why Clojure hasn't developed as a 
> go to for data science?
>
> It never seems to get a mention R,Python and now Julia get the attention. By 
> design it would appear that Clojure would be a good fit. Is it a lack of 
> libraries, ease of install, no good default environment  (R Rstudio, IPython 
> ) where as you would need to use emacs with clojure, or is there just a 
> better default use of Clojure?
>
> Sayth
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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: clojure, not the go to for data science

[Steven Deobald]

The data scientists we work often build their final models in either
Clojure or Java, but most of them prefer Python or R for exploration.

Since they're comfortable with the environment (both the JVM and emacs),
the preference largely stems from a lack of library support and a short
history. Even the developers on our team tend to jump on R or Python first,
since most of the introductory material on stats and data science will
usually point a person in that direction.

Clojure does seem to be gaining traction, though. Scientist by scientist. :)

Steven Deobald -- ⌀ -- nilenso.com

On Sun, Mar 29, 2015 at 2:24 PM, Sayth Renshaw 
wrote:

> Hi
>
> I last learned clojure in 1.2. Just curious why Clojure hasn't developed
> as a go to for data science?
>
> It never seems to get a mention R,Python and now Julia get the attention.
> By design it would appear that Clojure would be a good fit. Is it a lack of
> libraries, ease of install, no good default environment  (R Rstudio,
> IPython ) where as you would need to use emacs with clojure, or is there
> just a better default use of Clojure?
>
> Sayth
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from 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: clojure, not the go to for data science

[Jony Hudson]

First, let me shamelessly plug Gorilla REPL http://gorilla-repl.org . It's 
a notebook type REPL, which I think works well as an environment for the 
sort exploratory programming of that's common when analysing data. We use 
it for science-involving-data every day in our research group, and I think 
a few others do too.

Regarding the question, my guess at the answer would be "fashion". My 
experience has been that Clojure is a fine environment for technical 
computing. It's not as complete, library wise, as the alternatives, so it's 
sometimes a struggle. But it has some strengths over the others too 
(deployment, in particular - and I find Java is a really nice low-level 
escape hatch, compared to the alternatives). My guess is that it would take 
some high profile organisation to adopt it as a data science platform, and 
talk about it a lot, for it to really catch on, because that seems to be 
how fashion works!


Jony


On Sunday, 29 March 2015 10:55:34 UTC+1, Sayth Renshaw wrote:
>
> Hi 
>
> I last learned clojure in 1.2. Just curious why Clojure hasn't developed 
> as a go to for data science? 
>
> It never seems to get a mention R,Python and now Julia get the attention. 
> By design it would appear that Clojure would be a good fit. Is it a lack of 
> libraries, ease of install, no good default environment  (R Rstudio, 
> IPython ) where as you would need to use emacs with clojure, or is there 
> just a better default use of Clojure? 
>
> Sayth

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

[Colin Yates]

Cursive Clojure, LightTable and CounterClockwise are all good Clojure IDEs.

On 29 March 2015 at 09:54, Sayth Renshaw  wrote:
> Hi
>
> I last learned clojure in 1.2. Just curious why Clojure hasn't developed as a 
> go to for data science?
>
> It never seems to get a mention R,Python and now Julia get the attention. By 
> design it would appear that Clojure would be a good fit. Is it a lack of 
> libraries, ease of install, no good default environment  (R Rstudio, IPython 
> ) where as you would need to use emacs with clojure, or is there just a 
> better default use of Clojure?
>
> Sayth
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from 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.

clojure, not the go to for data science

[Sayth Renshaw]

Hi

I last learned clojure in 1.2. Just curious why Clojure hasn't developed as a 
go to for data science? 

It never seems to get a mention R,Python and now Julia get the attention. By 
design it would appear that Clojure would be a good fit. Is it a lack of 
libraries, ease of install, no good default environment  (R Rstudio, IPython ) 
where as you would need to use emacs with clojure, or is there just a better 
default use of Clojure?

Sayth

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