This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-08-15
Channels
- # architecture (2)
- # beginners (16)
- # boot (2)
- # cider (4)
- # clara (6)
- # cljs-dev (78)
- # cljsrn (3)
- # clojure (158)
- # clojure-austin (1)
- # clojure-belgium (1)
- # clojure-dusseldorf (19)
- # clojure-italy (8)
- # clojure-russia (3)
- # clojure-spec (77)
- # clojure-uk (61)
- # clojurescript (341)
- # cursive (9)
- # data-science (12)
- # datomic (18)
- # emacs (9)
- # fulcro (109)
- # hoplon (10)
- # juxt (2)
- # leiningen (2)
- # lumo (31)
- # off-topic (1)
- # om (4)
- # onyx (40)
- # parinfer (17)
- # re-frame (36)
- # reagent (19)
- # spacemacs (10)
- # vim (60)
- # yada (20)
fyi kdd panel on ds: https://www.linkedin.com/pulse/kdd-2017-applied-data-science-invited-panel-usama-fayyad?published=t
@blueberry what's the DBDA book?
btw we've started hacking on some viz stuff for gorilla, early days though
we think it should be simple and not make assumptions about data structures (like incanter plot does obviously)
It's a bit unfortunate that the 'pimped' gorilla effort was focused on just reimplementing it - with total backward capability. Even so, the fact that this variant is based on Reagent (maybe even re-frame) would be a great place to maybe start. Pulling in and using gyptis to replace the plotting would be another step forward as it would be a more solid starting point for plotting (and still uses vega) (gyptis is stagnant, but already has a lot of dynamic aspects to the plots).
Definitely still use gorilla's renderer - that will also keep the useful plugins for it.
The big step would be to make the editor a 'real' editor - protorepl would be the place to look for that as it should be runnable in the browser.
I readily realize that all of this would require serious effort to make it 'real' - not just a kinda sorta works proof of concept.
what you say makes sense though, so we might at least check how much effort that would cost
Yeah, I don't think Python's 'rise' has much of anything to do with notebook tech for it or extent notebooks using it. I can directly speak to genomic data cases and they play almost no role there at all. Of course the 'wow useful analysis' aspect doesn't much involve Python at its core either. Most of that is still C/C++ and Java based.
Again, I am not saying notebooks have much of anything to do with 'popularity' of anything. For example, for R, we use it a lot (for obvious reasons) and it is scripts all the way - no R-Studio at all.
My comment on possible notebook tech that could be really nice is completely orthogonal to your @blueberry points here.