Jupyter, Mathematica, and the Future of the Research Paper • Hacker News Board

Re: Jupyter, Mathematica, and the Future of the Research Paper

#71

Post by hatmatrix » Sun, Apr 15, 2018, 12:42 PM UTC

arca_vorago wrote: post #20

I have chosen the emacs org mode system over Jupyter, but I still like Jupyter regardless. The real tragedy is how dependent people have become on proprietary stacks like Mathematica.

org-mode + babel is excellent. But again the social aspect necessary for adoption is much less developed than Jupyter (the emacs community is very social, but small).

In that Jupyter files are just json files, I hope that there it will be easier to switch between the two in the future. Like [1], [2], and [3].

[1] https://github.com/gregsexton/ob-ipython

[2] https://github.com/jkitchin/ox-ipynb

[3] https://github.com/millejoh/emacs-ipython-notebook

Re: Jupyter, Mathematica, and the Future of the Research Paper

#72

Post by pletnes » Sun, Apr 15, 2018, 12:43 PM UTC

improbable22 wrote: post #58

rotorblade wrote: post #55

Earlier quoted context omitted.

>> The tie-breaker is social, not technical. > The tie-breaker is financial. Jupyter is winning because it's free [...] It is a bit more nuanced than that. Personally I do not pay from Mathematica usage, so why do I like Jupyter more? The Mathematica notebook interface is horrible . You may go "oh, neat" the first few times you try it then, at least I, get more and more frustrated on all the idiotic issues * Indentat…

These are matters of taste, I use both & find Mathematica's notebooks much better than Jupyter. Editing text in a web browser is just painfully clumsy, and plain text is not great for reading mathematical expressions of any length. But obviously it depends what you're doing with it. You complain about Sin[] but not about ugly things like np.sin()? Also I think you're looking for Sin[θ] //TraditionalForm //TeXForm

Using \text{} instead of \sin is, arguably, plain incorrect. Or at least at odds with the tex philosophy of separation between content and formatting.

Re: Jupyter, Mathematica, and the Future of the Research Paper

#73

Post by gaius » Sun, Apr 15, 2018, 1:01 PM UTC

tincholio wrote: post #50

sanderjd wrote: post #47

Earlier quoted context omitted.

I used MathCAD in physics and chemistry classes in college. I frequently wonder what happened to it, because I share your perception that while Jupyter is very nifty, it is hamstrung by the limitations of the browser environment. I'm waiting impatiently for the coming revolution of non-web collaborative internet-connected rich client applications.

As a die-hard Emacs user, I think that org-mode with it's org-babel capabilities blows Jupyter out of the water, and it produces much better, readable output. You can use it with pretty much any language, and combine several languages in a single document without any issues. Besides all this, it's just a plain text format, and you can extract all the code into proper source files for later offline use, too ('tangling…

combine several languages in a single document without any issues

You can do this with RMarkdown as well, despite the name, and run notebooks in RStudio. Much better experience than Jupyter in a browser.

https://yihui.name/knitr/demo/engines/

Re: Jupyter, Mathematica, and the Future of the Research Paper

#74

Post by nmca » Sun, Apr 15, 2018, 1:21 PM UTC

gaius wrote: post #66

PopePompous wrote: post #63

Earlier quoted context omitted.

Science publication is moving (very, very, very slowly) towards a model where instead of a final, polished traditional paper, the raw data along with the software tools and interpretation is published. In principle this should allow readers to completely understand and reproduce the processing of the raw data, rather than reading a few paragraphs summarizing the processing done by the authors. Using a closed source t…

In principle this should allow readers to completely understand and reproduce the processing of the raw data, rather than reading a few paragraphs summarizing the processing done by the authors. Using a closed source tool But consider http://www.bbc.co.uk/news/science-environment-39054778 "Science is facing a "reproducibility crisis" where more than two-thirds of researchers have tried and failed to reproduce another…

Open source software, in general, tends to make things more reproducible. Sure, software licencing might not be the singular root cause, but why does that suggest we shouldn't capitalise on the improvements available?

Re: Jupyter, Mathematica, and the Future of the Research Paper

#75

Post by klmr » Sun, Apr 15, 2018, 1:26 PM UTC

dahart wrote: post #8

> The tie-breaker is social, not technical. The tie-breaker is financial. Jupyter is winning because it's free, not because it's social. It becomes social because of widespread adoption, and it get's widespread adoption because it's free. I love Jupyter, love love love. But there's a lot of hyperbole and opinion here. Mathematica is just a for-profit business, it's that simple. And it wouldn't be fair to deny the exa…

> The tie-breaker is financial.

It can be both financial and social: individual institutes are all too happy to pay for Mathematica licenses, and consequently institute members can use it to produce reproducible research with it. However, the reproducibility of the resulting notebooks is drastically hindered by the fact that a reader essentially also needs to pay for Mathematica to get the full benefit out of these notebooks (even if they are readable without Mathematica). As a consequence, few people bother using it even though they can afford to. Social drivers disincentivise its usage.

By a similar dynamic, Git beat out the competing DVCS: in this case mostly technical rather than financial factors that drove individual actors to prefer Git over alternatives (due, to a large part, to GitHub). But many people don’t actually care about technical considerations (or even prefer other systems over Git in this regard). What people most care about is seamless integration. In the end, a social driver caused Git’s adoption.

Re: Jupyter, Mathematica, and the Future of the Research Paper

#76

Post by gaius » Sun, Apr 15, 2018, 1:33 PM UTC

nmca wrote: post #74

gaius wrote: post #66

Earlier quoted context omitted.

In principle this should allow readers to completely understand and reproduce the processing of the raw data, rather than reading a few paragraphs summarizing the processing done by the authors. Using a closed source tool But consider http://www.bbc.co.uk/news/science-environment-39054778 "Science is facing a "reproducibility crisis" where more than two-thirds of researchers have tried and failed to reproduce another…

Open source software, in general, tends to make things more reproducible. Sure, software licencing might not be the singular root cause, but why does that suggest we shouldn't capitalise on the improvements available?

Open source software, in general, tends to make things more reproducible

Citation very much needed for that. Because you can very easily find that 6 months or a year later you update your dependencies and everything is now broken. I recently came back to a Python project after a year, updated my packages then realized: I simply cannot be bothered to unpick the mess that resulted just to add one trivial feature. Whereas the poster child for backwards compatibility is closed-source and proprietary.

Science is not reproducible because there are no incentives for it to be so, despite everyone paying lip service to it. It's extra work and helps those who are competing with you for grants, after all. That's a social problem, not a software one. The software is irrelevant.

Re: Jupyter, Mathematica, and the Future of the Research Paper

#77

Post by madengr » Sun, Apr 15, 2018, 1:35 PM UTC

sanderjd wrote: post #47

gaius wrote: post #37

Earlier quoted context omitted.

The tie-breaker is financial. Jupyter is winning because it's free This is it really Back in the 90s I was using a program called MathCAD, it provided a “notebook” interface by running as a plugin to Word 6. In terms of general usability and experience, 20-years-ago blows away modern-day Jupyter and it’s silly “cells” interface, which it does not because it’s better but because it’s trying to force itself into a web…

I used MathCAD in physics and chemistry classes in college. I frequently wonder what happened to it, because I share your perception that while Jupyter is very nifty, it is hamstrung by the limitations of the browser environment. I'm waiting impatiently for the coming revolution of non-web collaborative internet-connected rich client applications.

MathCAD went to shit in about 2000. I had been using it for 10 years then (started in DOS). They made some annoying UI changes and really increased the cost. The kicker was when they called me and accused me of using a fake license, when I had dutifully been paying support for both a home and work license. I got fed up and went to Mathematica.

MathCAD was later bought by PTC, and further went to shit. It amuses me how some companies can self destruct.

Re: Jupyter, Mathematica, and the Future of the Research Paper

#78

Post by gaius » Sun, Apr 15, 2018, 1:44 PM UTC

madengr wrote: post #77

sanderjd wrote: post #47

Earlier quoted context omitted.

I used MathCAD in physics and chemistry classes in college. I frequently wonder what happened to it, because I share your perception that while Jupyter is very nifty, it is hamstrung by the limitations of the browser environment. I'm waiting impatiently for the coming revolution of non-web collaborative internet-connected rich client applications.

MathCAD went to shit in about 2000. I had been using it for 10 years then (started in DOS). They made some annoying UI changes and really increased the cost. The kicker was when they called me and accused me of using a fake license, when I had dutifully been paying support for both a home and work license. I got fed up and went to Mathematica. MathCAD was later bought by PTC, and further went to shit. It amuses me ho…

MathCAD went to shit in about 2000

That would be a couple of years after I last used it. What a shame, at least I have those memories. Really loved how low-friction working with it was, and how trivial it was to generate high quality documents or reports, there was no "write it up" stage, you were done basically as soon as you had done the actual work. Then just print and go! Still can't really do that with Jupyter.

Re: Jupyter, Mathematica, and the Future of the Research Paper

#79

Post by FractalLP » Sun, Apr 15, 2018, 1:45 PM UTC

askvictor wrote: post #27

FractalLP wrote: post #23

Long time user of Python here and recent user of Mathematica. Some observations I have are that they're both great. Python is a nice open source scripting language, but getting libraries to work can sometimes be a pain. Mathematica is basically install this and everything is included. The Mathematica documentation is amazing and it is really simple how to do most things. The whole iPhone "there is an app for that" is…

While I totally hear you regarding the pain of python modules (particularly on Windows), the point of python 'distributions' like anaconda and canopy is to bring the kitchen sink along, kind of like mathematica. The problem with Mathematica from a science point of view is that, being closed source, means you can't independently ensure the calculations are happening correctly. To be replicable, science involving data…

I hear what you're saying and you're right that WinPython & Anaconda certainly help, but the documentation is still a long way off from Mathematica in my opinion.

One thing in Python's favor though might be depth in certain categories. The machine learning stuff in Mathematica is very nice and high level if you want neural networks, but if you need PSO or GA, you'll probably have to write your own or grab someone else's notebook.

It was difficult for me to support closed-source software as I've always supported linux for this reason.

As far as ensuring accuracy of calculations, having a very large and highly technical user base over several decades helps, but I'm not sure how much this is used in theory. If a statistician publishes a paper using R, is anyone really going to check the R module source code? I bet this is a rare occurrence.

Re: Jupyter, Mathematica, and the Future of the Research Paper

#80

Post by improbable22 » Sun, Apr 15, 2018, 1:49 PM UTC

nmca wrote: post #74

gaius wrote: post #66

Earlier quoted context omitted.

In principle this should allow readers to completely understand and reproduce the processing of the raw data, rather than reading a few paragraphs summarizing the processing done by the authors. Using a closed source tool But consider http://www.bbc.co.uk/news/science-environment-39054778 "Science is facing a "reproducibility crisis" where more than two-thirds of researchers have tried and failed to reproduce another…

Open source software, in general, tends to make things more reproducible. Sure, software licencing might not be the singular root cause, but why does that suggest we shouldn't capitalise on the improvements available?

Because the reproducibility crisis has very little to do with the difficulty in re-running the same code. These are almost orthogonal concerns.

The typical problem paper has a small data set, on which the authors tried 20 different things, one of which achieved p<0.05 and got published. The result tells you nothing meaningful about the world (or more often, tells you something about how its authors wish the world worked). But re-running their code on their data set will not reveal the problem.