Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jupyter, Mathematica, and the Future of the Research Paper

paulromer.net

Post reply on HN
Print view View original

141–150 of 179 posts

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

#141

Post by FractalLP »

gaius wrote: post #37
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. 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 college engineering, but never the Word interface. My wife had to use it for all her engineering classes and was a whiz with it. Still, the overall system is pretty far behind in overall functionality I would say.

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

#142

Post by FractalLP »

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.

Carl Sassenrath (Amiga and Rebol inventor) tried to do this with Rebol. He had what he called iOS (internet operating system) that would let you share the tiny Rebol source files. A 1/2 page of Rebol can run a fully functional GUI with graphics...etc as there is a DSL for most things and high level primitives. The interpreter is < 5MB, so you can transfer everything over the web, but still avoid JavaScript...etc. A cool vision that didn't pan out. The Red project is continuing what is cool about Rebol, but with native compilation as well and a cross-platform compiler for Mac, Linux, Windows, Android, BSD, and several others. They have a whitepaper out on Dapps (decentralized apps) and how to use it with ethereum and blockchain. Worth a look.

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

#143

Post by hpcjoe »

blablabla123 wrote: post #137
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…

Also not to forget that Jupyter is just different to Mathematica. With Mathematica you can do symbolic computations, yes also Statistics and Machine Learning, but also Group Theory and what not. Jupyter does a great job as an interface for certain Statistics and Machine Learning tasks, also I'm quite sure that it needs less resources but that's all. That said, I'm still missing a free but powerful tool for symbolic c…

Maxima, the gpl'ed version of Macsyma (which I used in grad school days for stat mech calculations on spin systems with Potts, Ising, and other models) is available for most systems. There is a Jupyter kernel for it[1].

I am personally more a fan of Julia than Python, and Julia + Jupyter is an awesome combination.

[1] https://github.com/robert-dodier/maxima-jupyter

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

#144

Post by fdej »

ChrisRackauckas wrote: post #117
fdej wrote: post #62

Earlier quoted context omitted.

> On the other hand, open source tools are catching up. SymPy is doing nicely, but it's decades behind Mathematica when it comes to symbolic computation. By the way, if you want to invert a symbolic matrix, chances are that generic Gaussian elimination working with symbolic expressions isn't the best algorithm (it might even give wrong answers if zero testing is done incorrectly), and compiled code isn't going to cha…

It was a bunch of small matrices so it worked out well, but that's good to know. For future reference, what library implements these symbolic linalg routines? When I was looking around I could only find LinBox ( http://www.linalg.org/ ) but the barrier to entry was a little high for me to dig in.

In Julia, there is Nemo.jl for high performance exact and symbolic linear algebra. At least that is the goal; it doesn't have the best algorithms yet in all cases, but it has some of them (and more are being developed). You can see some examples here: http://nemocas.org/benchmarks.html

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

#145

Post by gravypod »

gravypod wrote: post #68
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…

Has anyone tried integrating this sort of thing into LibreOffice? I bet Calc would make a decent DataFrame tool.

Posted too long ago for me to be able to edit.

Looks like someone has: http://comppad.sourceforge.net/

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

#146

Post by tincholio »

dahart wrote: post #123
tincholio wrote: post #108

Earlier quoted context omitted.

> How easy is it to share a Jupyter notebook with someone else, versus sharing an org-mode notebook? Well, now you're talking about a whole environment. Use docker, or VMs or whatever. There's plenty of options for doing this (we actually use Docker for Jupyter, to make sure we work off a consistent install, so I guess sharing can be non-trivial if you walk a bit off the beaten path, anyway) > If I choose to use a di…

Yes, Anaconda + Jupyter is an environment and org mode is not. That’s a big reason Jupyter is so popular. > I don’t get your point. My point was Jupyter inflicts far less technical burden and debt on other people. There’s a huge downside to custom environments. If that’s not obvious, that explains why it’s hard to understand jupyter’s popularity. > it requires a minimum of computer literacy I’m sure you didn’t mean i…

> Yes, Anaconda + Jupyter is an environment and org mode is not. That’s a big reason Jupyter is so popular.

You're again comparing apples to oranges. If you want to use Jupyter, you need to install a whole lot of stuff (easier to do if you're using Anaconda, agreed). It's "not simple" enough that there are public docker images for it. My point is that when tooling is an issue, you can do the exact same thing with an org-based setup.

>My point was Jupyter inflicts far less technical burden and debt on other people. There’s a huge downside to custom environments. If that’s not obvious, that explains why it’s hard to understand jupyter’s popularity.

I agree that there's difficulty in achieving reproducible environments, and that's why there's tools that handle that for you. I think that much of Jupyter's popularity comes from the fact that it's easily available, and based on Python, which let's non-programmers get started moderately quickly. I just don't think that it's the best choice. This is not to shit on Jupyter, I've mentioned a bunch of advantages of using org (which by the way, you haven't really addressed, other than focusing on the setup aspects)

> I’m sure you didn’t mean it that way, but this borders on white tower programmer centric dismissiveness.

It's not, really. My point is that when you're doing presumably advanced analysis on presumably complex data, you (should!) certainly have the capacity to deal with tooling.

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

#147

Post by tincholio »

dragonwriter wrote: post #138
tincholio wrote: post #108

Earlier quoted context omitted.

> How easy is it to share a Jupyter notebook with someone else, versus sharing an org-mode notebook? Well, now you're talking about a whole environment. Use docker, or VMs or whatever. There's plenty of options for doing this (we actually use Docker for Jupyter, to make sure we work off a consistent install, so I guess sharing can be non-trivial if you walk a bit off the beaten path, anyway) > If I choose to use a di…

> Sure, and if you need to use another language from your Jupyter notebook, you can't. Not entirely true, BTW. https://blog.dominodatalab.com/lesser-known-ways-of-using-no...

Still limited, and pretty clumsy. Have a look here: https://orgmode.org/worg/org-contrib/babel/languages.html

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

#148

Post by tincholio »

jononor wrote: post #122
tincholio wrote: post #108

Earlier quoted context omitted.

> How easy is it to share a Jupyter notebook with someone else, versus sharing an org-mode notebook? Well, now you're talking about a whole environment. Use docker, or VMs or whatever. There's plenty of options for doing this (we actually use Docker for Jupyter, to make sure we work off a consistent install, so I guess sharing can be non-trivial if you walk a bit off the beaten path, anyway) > If I choose to use a di…

There are Jupyter kernels for most languages out there. https://github.com/jupyter/jupyter/wiki/Jupyter-kernels

And for the most part, you cannot use them at the same time from the same notebook.

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

#149

Post by hpcjoe »

Responders have been making the argument that Jupyter is beating Mathematica because of financial or social issues. I'd like to posit a different interpretation, which could be construed to encapsulate these reasons, as well as additional other factors.

Jupyter has a lower friction to adoption and usage than Mathematica, for a definition of friction which encompasses ease of acquisition and sharing. I include economic considerations in the ease of acquisition and sharing. Lack of proprietary walled garden lock-in/lock-out factors in as well.

People are also likely considering the longer term scenario, whereby data, model, and information interchange has been hindered by proprietary formats (the "wall" in the walled garden) and lack of complete information on how to get information in and out. Which is what the OP was complaining about, as they were not able to easily construct a publication quality preprint/submission from one, but could do it easily from the other.

Some of these sources of friction are effectively "own-goals", that is, you increase friction in such a way as to prevent something that people need to do, to be effectively impossible. Or you hide it. Or disable certain groups from using that functionality.

Then the question is balancing the longevity of the format, the proprietary value against alternatives. Increasingly, people are less interested in this friction for a number of critical systems.

I am looking at this from the perspective of someone who has a few 10's of MB of data/writings on 25-30 year old 3.5 inch and 5.25 inch floppies. These are in formats for which I may not have an ability to extract the data/information without some significant effort.

The formats that have survived well for me over the last 30 years have been either open, or readable/writeable with open tools. The closed ones, not so much luck with.

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

#150

Post by tincholio »

dahart wrote: post #126
tincholio wrote: post #106

Earlier quoted context omitted.

>If you have to package images separately when sharing, then wouldn't inline images score a point for easier sharing? I guess that depends on who you're sharing with and how. If you're using git, you can just add them to your repo (only they won't clobber your diffs). If you're just publishing, you can export to HTML and put it somewhere online. >Agreed, and that is powerful, but this also goes to my point. Jupyter i…

Jupyter isn’t competing with emacs, it’s not an editor. It’s competing with the python shell. And it’s editing capabilities are way better than the python shell. Adding git as a dependency to sharing is too much in general, that would prevent sharing.

> Jupyter isn’t competing with emacs, it’s not an editor.

I'm fully aware of that, my point was that functionality- and ergonomics-wise, you're better off using Emacs/org. I agree that it's not for everyone, but for people working on data science, it's a much more powerful tool.

>Adding git as a dependency to sharing is too much in general, that would prevent sharing.

I think we probably have vastly different target audiences in mind.

Post reply on HN