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

[Colin Yates]

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

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

[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

[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

[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

[Bozhidar Batsov]

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

[Colin Yates]

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

[Joseph Smith]

Batsov,

CIDER is the best Clojure IDE. ;)

--

@solussd

[Bozhidar Batsov]

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

[Luc Préfontaine]

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

Luc Préfontaine<lprefo...@softaddicts.ca> sent by ibisMail!

[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<lprefo...@softaddicts.ca> 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 <bozh...@batsov.com> wrote:

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

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

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

[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

[Alexis]

Bozhidar Batsov <bozh...@batsov.com> 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.

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

[Alexis]

Colin Yates <colin...@gmail.com> 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.

[Fluid Dynamics]

On Monday, March 30, 2015 at 4:18:03 AM UTC-4, Alexis wrote:

Bozhidar Batsov <bozh...@batsov.com> 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 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).

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

Point #1, period. ;)

* 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. :-)

Point #2, period, with some caveats about how "easily-modifiable" something really is if it's easily modifiable by anyone who understands its innards, but understanding its innards requires completing a four-year degree program in emacsology at an Ivy League university.

Yes, there can be a steeper initial learning curve with Emacs than
with IDEs,

This easily qualifies as a very strong candidate to be crowned understatement of the century, and we're not even 1/6 of the way through this one yet. Steeper? It's like comparing a gentle hill to the part of a roller coaster track that's more than halfway up the side of a loop-the-loop. The emacs learning curve is so steep it has overhangs!

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.

One-time cost. That's what they tell students about their thirty-thousand-dollar tuition debts they'll be paying off for the next forty years, too, isn't it? :) (See quip about emacsology degree programs, above.)

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.

And I already was familiar with Eclipse...

Emacs is surely not the best tool for all developers in all
contexts,

And now our fresh new candidate for understatement of the century already has to accept also-ran status as there's a new contender in town that now looks nearly certain to achieve victory.

but i also feel it's something that developers - and
Clojure developers in particular - should perhaps at least give a
second look.

Have they gotten around to adding a feature that makes it simple and intuitive to switch between the help pane and a document pane without having to navigate the help pane away from the thing you can't memorize to some other, pane-switching thing you also can't memorize? Such as, say, making alt-tab (or control-tab since nowadays you'd run it in a terminal emulator embedded in a real window system) switch panes? :) 

[Tassilo Horn]

Fluid Dynamics <a209...@trbvm.com> 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 niche languages is a bad thing. And "all
the rest" is again nonsense.

> Yes, there can be a steeper initial learning curve with Emacs than
> with IDEs,
>
> This easily qualifies as a very strong candidate to be crowned
> understatement of the century, and we're not even 1/6 of the way
> through this one yet. Steeper? It's like comparing a gentle hill to
> the part of a roller coaster track that's more than halfway up the
> side of a loop-the-loop. The emacs learning curve is so steep it has
> overhangs!

Every newbie should run through the tutorial once (C-h t) in which all
important concepts are discussed. After that, you are initiated and
should be able to look up documentation yourself.

> And now our fresh new candidate for understatement of the century
> already has to accept also-ran status as there's a new contender in
> town that now looks nearly certain to achieve victory.

How do you define victory? I have no doubt that other alternatives for
Clojure development might become more popular than Emacs. But why is
that important, and why would that make Emacs a loser?

I mean, everyone should use what suits him best. IDE X might serve the
"work the way I'm already used to" fraction, Emacs might serve the "I
want to tinker with anything and customize it to my very specific needs"
fraction.

> but i also feel it's something that developers - and Clojure
> developers in particular - should perhaps at least give a second
> look.
>
> Have they gotten around to adding a feature that makes it simple and
> intuitive to switch between the help pane and a document pane without
> having to navigate the help pane away from the thing you can't
> memorize to some other, pane-switching thing you also can't memorize?

`C-x o' is the standard key for cycling thru windows ("panes"). If
that's to hard to type (to me it is), then define a better key for it.
FWIW, Alt+<N> for N being an integer sets the input focus to the N-th
window here.

And to browse as many info manuals simultaneously so that you don't have
to navigate away from one topic to read another, you can have as many
open info buffers as you wish. The command that you invoke to open the
documentation also tells you how, i.e., the solution is documented in
`C-h k C-h i' ("Please Emacs, describe the command which gets executed
by the key `C-h i'.").

Bye,
Tassilo

[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 <a209...@trbvm.com> 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/fog0000000069.html

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

Do you really think Emacs can only be run in a terminal? If you
do, then it suggests you don't even have a basic familiarity with
Emacs, which has had GUI support for around a couple of decades
....

i generally use a GTK3 build of Emacs, and only use a
terminal-based frontend to the Emacs daemon when necessary (and
when it is, i'm glad such a facility is there).

As for i18n issues, here's a current thread on the help-gnu-emacs
list:

https://lists.gnu.org/archive/html/help-gnu-emacs/2015-03/msg00205.html

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

Yes, i've occasionally been frustrated by some of Emacs'
behaviours also. Fortunately, since Emacs is so easily directly
modifiable, i'm usually able to change those behaviours (not
least, the keybindings for certain things, when i just couldn't
get used to the default keybindings).

Having said that, i can't say i've never been frustrated when
trying to use Eclipse. Just one example: i had quite some 'fun'
trying to set it up for Android development with the ADT plugin,
with Eclipse getting itself into a broken state a few times before
i managed to successfully install the plugin. So just as you've
had some bad experiences with Emacs (as have i!), i've had some
bad experiences with Eclipse, but /in my own context/, have found
persisting with Emacs to provide a greater benefit than persisting
with Eclipse as my main IDE.

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

More gratuitous insults.

Perhaps you missed the text box at the top of the melpa.org page
which allows one to enter filter terms? Type in 'clojure' as a
filter term and see what happens.

Further, using the package.el UI within Emacs itself, one can use
various Emacs search facilities (not only e.g. `isearch`, but also
extensions such as e.g. `helm-package`) to quickly narrow down the
list of possibly suitable packages.

> Point #2, period, with some caveats about how
> "easily-modifiable" something really is if it's easily
> modifiable by anyone who understands its innards, but
> understanding its innards requires completing a four-year degree
> program in emacsology at an Ivy League university.

By the same token, one could argue that one needs a degree in Java
engineering to work with Eclipse, or that one needs a degree in
Clojure to use LightTable. :-P

Anyway, i tend to feel that being able to use Emacs `Customize` UI
to modify various settings, or to write ELisp like:

(setq a-customisable-variable 10)

or even like:

(defun move-buffer-file (dir)
"Moves both current buffer and file it's visiting to DIR. By
Steve Yegge." (interactive "DNew directory: ") (let* ((name
(buffer-name))
(filename (buffer-file-name)) (dir
(if (string-match dir "\\(?:/\\|\\\\)$")
(substring dir 0 -1) dir))
(newname (concat dir "/" name)))
(if (not filename)
(message "Buffer '%s' is not visiting a file!" name)
(progn
(copy-file filename newname 1) (delete-file filename)
(set-visited-file-name newname) (set-buffer-modified-p
nil) t))))

are things that would unduly stress anyone who can program in
Clojure.

> This easily qualifies as a very strong candidate to be crowned
> understatement of the century, and we're not even 1/6 of the way
> through this one yet. Steeper? It's like comparing a gentle hill
> to the part of a roller coaster track that's more than halfway
> up the side of a loop-the-loop. The emacs learning curve is so
> steep it has overhangs!

That's not my experience, and that's not necessarily the
experience of every Emacs user, even though it seems to have been
your own experience. Different people find different systems
easier/harder to learn.

> One-time cost. That's what they tell students about their
> thirty-thousand-dollar tuition debts they'll be paying off for
> the next forty years, too, isn't it? :) (See quip about
> emacsology degree programs, above.)

The same argument could be used to dissuade people from learning
new programming languages. (For example, many people find that
they need to pay for courses of various lengths to learn the art
of programming, and/or to learn certain programming languages in
particular.) Are you really suggesting that only things that can
be learned in moments, for little to no resource cost, have any
'true' value?

>> 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.
>
> And I already was familiar with Eclipse...

Fair enough.

> Have they gotten around to adding a feature that makes it simple
> and intuitive to switch between the help pane and a document
> pane without having to navigate the help pane away from the
> thing you can't memorize to some other, pane-switching thing you
> also can't memorize? Such as, say, making alt-tab (or
> control-tab since nowadays you'd run it in a terminal emulator
> embedded in a real window system) switch panes? :)

Again with the claim that Emacs is a terminal-only application,
rather than being something that can be run in a windowing
environment (i run it under the i3 wm) and a terminal (at the same
time, if necessary).

As for switching between panes, you can use C-x o
(`other-window`), or (as i do) `windmove`, which allows one to use
e.g. C-TAB j (which i've bound to `windmove-down`) to give focus
to the pane directly below the cursor, or C-TAB l (which i've
bound to `windmove-right`) to the pane directly to the right of
the cursor.

WFM, YMMV.


Alexis.

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

[Fluid Dynamics]

On Monday, March 30, 2015 at 7:23:00 AM UTC-4, Tassilo Horn wrote:

Fluid Dynamics <a209...@trbvm.com> 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 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 niche languages is a bad thing.

If there was any realistic hope of a search interface any reasonably computer-savvy person could just sit down and use, it wouldn't be. Without such a hope, clutter becomes a catastrophe.

Oh, no doubt someone in emacsland has managed to notice Tim Berners-Lee's newfangled invention by now, perhaps a few weeks or a month ago, and threw up a web site with downloadable items, and no doubt using these downloads, instead of whatever inbuilt package management, entails performing a 27-step manual installation procedure whose instructions, though thorough, are written assuming nobody in the audience isn't at least working on getting their master's degree in emacsology, if not already a postdoc or something. :)

>     Yes, there can be a steeper initial learning curve with Emacs than
>     with IDEs,
>
> This easily qualifies as a very strong candidate to be crowned
> understatement of the century, and we're not even 1/6 of the way
> through this one yet.  Steeper?  It's like comparing a gentle hill to
> the part of a roller coaster track that's more than halfway up the
> side of a loop-the-loop.  The emacs learning curve is so steep it has
> overhangs!

Every newbie should run through the tutorial once (C-h t) in which all
important concepts are discussed.  After that, you are initiated and
should be able to look up documentation yourself.

If said newbie has an eidetic memory, then you are likely correct. Otherwise, after reading the tutorial they will spend the next several hours realizing that they forgot this, and forgot that, and forgot that other thing, and forgot an additional 119 miscellaneous things, all of which were too long (meta-shift-x-what?), arbitrary, and non-mnemonic-in-the-least for any mere human to retain more than one or two of them without hours, days, or perhaps even weeks of intensive drilling. I don't suppose there's an emacs boot camp out there somewhere where this takes place? Otherwise, the number of people that have overcome all of the issues I witnessed to become some kind of proficient with emacs is difficult to explain, as eidetic memories simply aren't particularly prevalent in the population at large.

> Have they gotten around to adding a feature that makes it simple and
> intuitive to switch between the help pane and a document pane without
> having to navigate the help pane away from the thing you can't
> memorize to some other, pane-switching thing you also can't memorize?

`C-x o' is the standard key for cycling thru windows ("panes").

"Standard"? AFAIK it is used by the one single application, while to a fairly good approximation ALL THE REST of the world's software to which it's even applicable use control-tab (or command-tab, on Macintoshes). I'm quite interested to see whichever dictionary contains the definition of "standard" you are using. :)

And to browse as many info manuals simultaneously so that you don't have
to navigate away from one topic to read another, you can have as many
open info buffers as you wish.

I must confess to some amusement at the image that comes to mind of what it must look like when the terminal window is divided into more than a very small handful of panes. To me at this point, even 80x22 would be like peering through a mail slot at my code whilst wearing a pirate eyepatch.

 The command that you invoke to open the
documentation also tells you how, i.e., the solution is documented in
`C-h k C-h i' ("Please Emacs, describe the command which gets executed
by the key `C-h i'.").

Pardon me, but you may have mistaken me for somebody who has already learned Swahili. :)

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

[Lee Spector]

> On Mar 30, 2015, at 7:35 AM, Jony Hudson <jonye...@gmail.com> 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

[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

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

--

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

[Christian Weilbach]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

[Fluid Dynamics]

On Monday, March 30, 2015 at 7:29:36 AM UTC-4, Alexis wrote:

Fluid Dynamics <a209...@trbvm.com> 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 amount of tweaking, enough that the word "tweaking" no longer fits nearly as well as "hammering into near unrecognizability". After which, presumably, fine tuning it and actually *improving* on your normal workflow could finally commence.

I suppose the process accelerates, though. The more stuff you've managed to make sufficiently sane and nonsurprising, the easier the remainder of the job presumably becomes, particularly if you start with figuring out how and then changing the key bindings for basic UI navigation, saving changes, undo, and a few other things to something natural and readily remembered for more than the first 10 seconds after reading the relevant bit of the help. :)

>> * 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/fog0000000069.html

Oddly, the needs of a very large percentage of the potential user base for any software they use to have a user interface doesn't seem to have been dealt with. :)

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

Do you really think Emacs can only be run in a terminal?

I do seem to recall that it is terminal software of a similar vintage to vi, trn, elm, pico, etc....

The infinite regress of changing the keybindings for changing the keybindings before changing any keybindings ought to enter your awareness in 3, 2, 1 ... :)

Having said that, i can't say i've never been frustrated when
trying to use Eclipse. Just one example: i had quite some 'fun'
trying to set it up for Android development with the ADT plugin,
with Eclipse getting itself into a broken state a few times before
i managed to successfully install the plugin.

A dodgy plugin does not a bad IDE interface make. Whereas emacs fell down for me at the stage of "create new text file, type something into it, and File Save-As". There's simply no comparison.
 

So just as you've
had some bad experiences with Emacs (as have i!), i've had some
bad experiences with Eclipse, but /in my own context/, have found
persisting with Emacs to provide a greater benefit than persisting
with Eclipse as my main IDE.

Because, like persisting banging a head against a brick wall, it feels so good when you stop? ;)

OK, OK, cheap shot, but really, the progress made "persisting with emacs", at least for a complete n00b without access to an out-of-band help resource of some sort (such as an open Firefox window on some emacs related site -- in my case, it was a unix box whose networking was noworky, without X, and without any other computers handy, let alone networked ones, this being before ubiquitous smartphones and tablets), tends to make "glacial" seem like The Flash by comparison.

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

More gratuitous insults.

Perhaps you missed the text box at the top of the melpa.org page
which allows one to enter filter terms? Type in 'clojure' as a
filter term and see what happens.

Obviously, no such facility was available on *that occasion*. Even once that box's networking was working, there was no GUI, so no usable web browser and no convenient way to put a non-usable browser like Lynx side by side with emacs either.

Further, using the package.el UI within Emacs itself, one can use
various Emacs search facilities (not only e.g. `isearch`, but also
extensions such as e.g. `helm-package`) to quickly narrow down the
list of possibly suitable packages.

One can, if one already knows all of the arcana one is searching for. (Same problem as with the help on searching the help, natch.)

> Point #2, period, with some caveats about how
> "easily-modifiable" something really is if it's easily
> modifiable by anyone who understands its innards, but
> understanding its innards requires completing a four-year degree
> program in emacsology at an Ivy League university.

By the same token, one could argue that one needs a degree in Java
engineering to work with Eclipse, or that one needs a degree in
Clojure to use LightTable. :-P

The funny thing is, one doesn't. Whereas I can't see anyone (short of a photographic memory, at any rate) managing to get a handle on emacs without something like live tutelage with a heck of a lot of drilling and rote memorization. The training astronauts went through to learn how to correctly operate the Space Shuttle probably comes close to being comparable to what I envision being necessary here.

Anyway, i tend to feel that being able to use Emacs `Customize` UI
to modify various settings, or to write ELisp like:

    (setq a-customisable-variable 10)

or even like:

    (defun move-buffer-file (dir)
      "Moves both current buffer and file it's visiting to DIR. By
      Steve Yegge."  (interactive "DNew directory: ") (let* ((name
      (buffer-name))
             (filename (buffer-file-name)) (dir
              (if (string-match dir "\\(?:/\\|\\\\)$")
                  (substring dir 0 -1) dir))
             (newname (concat dir "/" name)))
        (if (not filename)
            (message "Buffer '%s' is not visiting a file!" name)
          (progn
            (copy-file filename newname 1) (delete-file filename)
            (set-visited-file-name newname) (set-buffer-modified-p
            nil) t))))

Oh, don't get me started on elisp. I've heard horror stories. Mutability everywhere. No proper local variable scope. No first class hashmaps with nice literal syntax...
 

are things that would unduly stress anyone who can program in
Clojure.

Until they reach for a "let" binding as the most natural solution to some particular problem, maybe. And assuming they got past what passes for the user interface. :)

> This easily qualifies as a very strong candidate to be crowned
> understatement of the century, and we're not even 1/6 of the way
> through this one yet. Steeper? It's like comparing a gentle hill
> to the part of a roller coaster track that's more than halfway
> up the side of a loop-the-loop. The emacs learning curve is so
> steep it has overhangs!

That's not my experience, and that's not necessarily the
experience of every Emacs user, even though it seems to have been
your own experience. Different people find different systems
easier/harder to learn.

Now why would that be, I wonder? I mean, given that eidetic memories don't have a particularly high population frequency, so most people would need a shitton of repetitively drilled rote memorization to be able to so much as open, modify, and save a text file without reaching for the help several times.

> One-time cost. That's what they tell students about their
> thirty-thousand-dollar tuition debts they'll be paying off for
> the next forty years, too, isn't it? :) (See quip about
> emacsology degree programs, above.)

The same argument could be used to dissuade people from learning
new programming languages.

??
Clojure took me about one week, to get the basics, and perhaps one month to be able to use it somewhat proficiently. And that's a *programming language*, not a mere text editor, which really you ought to be able to just sit at and use if you didn't sleep through ALL your grade school computer classes way back when.

Of course it also helps that accessing the help on programming Clojure is done with Firefox, rather than by programming Clojure, so that whole chicken-and-egg thing is avoided.
 

(For example, many people find that
they need to pay for courses of various lengths to learn the art
of programming, and/or to learn certain programming languages in
particular.) Are you really suggesting that only things that can
be learned in moments, for little to no resource cost, have any
'true' value?

Of course not. But if getting the hang of opening, modifying, and saving a text file in editor X requires a comparable learning effort to learning an entire programming language, then editor X has a problem, and indeed is tremendously outclassed in at least one aspect even by the lowly Notepad -- how embarrassing.

> Have they gotten around to adding a feature that makes it simple
> and intuitive to switch between the help pane and a document
> pane without having to navigate the help pane away from the
> thing you can't memorize to some other, pane-switching thing you
> also can't memorize?  Such as, say, making alt-tab (or
> control-tab since nowadays you'd run it in a terminal emulator
> embedded in a real window system) switch panes? :)

Again with the claim that Emacs is a terminal-only application,
rather than being something that can be run in a windowing
environment (i run it under the i3 wm) and a terminal (at the same
time, if necessary).

Well, of course it can be run in a windowing environment. That's called xterm. Everybody who's anybody knows about xterm. :)

Of course, the likeliest reason for many a sysadm to resort to something like emacs in the first place is because X is noworky for whatever reason on that machine, though ...

As for switching between panes, you can use C-x o
(`other-window`), or (as i do) `windmove`, which allows one to use
e.g. C-TAB j (which i've bound to `windmove-down`) to give focus
to the pane directly below the cursor, or C-TAB l (which i've
bound to `windmove-right`) to the pane directly to the right of
the cursor.

So there was some vague attempt at a nod to being somewhat mnemonic, in that one case. Not that that helps the gazillion would-be users who will all hammer furiously on control-tab and then throw up their hands in disgust.

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

[Lee Spector]

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

On Mar 30, 2015, at 9:29 AM, Christian Weilbach <white...@polyc0l0r.net> 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

[Tassilo Horn]

Fluid Dynamics <a209...@trbvm.com> 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 <buffer-name>'. 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

[Phillip Lord]

Sayth Renshaw <flebbe...@gmail.com> 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

[danl...@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.

[Mikera]

On Tuesday, 31 March 2015 00:01:32 UTC+8, Phillip Lord wrote:

Sayth Renshaw <flebbe...@gmail.com> 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.

 

[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

[Phillip Lord]

Alexis <flexi...@gmail.com> writes:

> Colin Yates <colin...@gmail.com> 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

[Colin Yates]

Ha! Genius.

On 30 March 2015 at 19:47, danl...@gmail.com <danl...@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.
>

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

[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

[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

[Phillip Lord]

Colin Yates <colin...@gmail.com> 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.

[Phillip Lord]

Fluid Dynamics <a209...@trbvm.com> 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

[Phillip Lord]

Mikera <mike.r.an...@gmail.com> 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

[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 <bozh...@batsov.com> wrote:

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

On 29 March 2015 at 13:47, Colin Yates <colin...@gmail.com> wrote:

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

On 29 March 2015 at 09:54, Sayth Renshaw <flebbe...@gmail.com> 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
>

[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

[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

[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

[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 legacy applications and never in any of their modern counterparts, as moving anything across that boundary is likely to be fiddly at best (e.g., mark/copy from Command Prompt window) and require saving a file manually and manually opening it in another application at worst (e.g. copying text from a pre-Windows *graphical* version of WordPerfect into a Firefox form box to use in a blog comment or something.) Maintaining and learning virtual machine software is likely to be necessary as an additional overhead, for legacy applications that can't be run natively at all anymore (most pre-Windows graphical apps and anything that assumes it can talk directly to the hardware), and even terminal emulators add a smaller amount of such overhead for the user.

[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

[Phillip Lord]

Fluid Dynamics <a209...@trbvm.com> 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

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

[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

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

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

[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

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

[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 

[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

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

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

[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

[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

--

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

[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

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

--

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.

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

[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

[Rafael de F. Ferreira]

Thanks, that is an awesome list of resources.

--
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+unsubscribe@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscribe@googlegroups.com.

[A]

>> Thanks, that is an awesome list of resources.

kudos to the respective authors.
-A

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

[Sayth Renshaw]

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

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+unsubscribe@googlegroups.com
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+unsubscribe@googlegroups.com.

[A]

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

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.

[Christopher Small]

Yesyesyesyes! Great idea! I'm on it.

[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

[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

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

[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

   

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.

[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

[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

[A]

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

-A

[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

[Daniel Slutsky]

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

It has had various forks and authors through its life.

[Gregg Reynolds]

On Apr 6, 2015 4:20 PM, "A" <aae...@gmail.com> 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 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.

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

[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

[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

[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

--

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.

[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

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