Live data from Hacker News

Jupyter, Mathematica, and the Future of the Research Paper

paulromer.net

101–110 of 179 posts

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

#101
post #61

Right, Jupyter is nice to have, but this is really over the top nonsense: Jupyter encourages individual integrity; Mathematica lets individuals hide behind corporate evasion I have no idea what he's talking about re PDF export either. I print to PDF all the time, to email people a static document to look at, etc. It works just fine. (Whether you can you make book-quality formatted text easily, I've no idea, never bee…

iguy, agreed. You have have no idea because you haven't tried.

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

#102
post #61

Right, Jupyter is nice to have, but this is really over the top nonsense: Jupyter encourages individual integrity; Mathematica lets individuals hide behind corporate evasion I have no idea what he's talking about re PDF export either. I print to PDF all the time, to email people a static document to look at, etc. It works just fine. (Whether you can you make book-quality formatted text easily, I've no idea, never bee…

I suspect that the OP used the "Print..." command in the File menu, and selected PDF as the printer option. ISTR that this can sometimes result in poor quality results as presumably it is relying on an external PDF engine to render the notebook. Whenever I've used the "Save As..." command, choosing PDF as the target, I've also only had good quality output.

Nope.

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

#103
post #92

Earlier quoted context omitted.

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…

I share your opinion about the superiority of org-mode as a means to assemble a document out of various pieces. It's not hard to show nicely formatted code, the code's output, the math behind the code and perhaps a graph of the results all in a LaTeX/PDF document and or HTML. All of this can be done with a flat text file that is easy to save as a part of a project under source control. What I wonder is why are Jupyte…

> What I wonder is why are Jupyter notebooks so popular?

How easy is it to share a Jupyter notebook with someone else, versus sharing an org-mode notebook? Think about the recipients rather than how hard it is for you. Assume the person you share with needs to be able to re-run your notebook. Assume the person you share with isn't using the same operating system that you are. Be honest and think about all the steps involved.

With Jupyter, I send a single install link to Anaconda. With Emacs + org mode + python + numpy + scipy + matplotlib, I might not even know where to begin if the recipient is using Windows or Mac. The recipient needs to install emacs, and they need to know how to use Emacs. They have to know how to install python packages (and possibly a package manager), and ideally be able to use virtualenv too.

If I need different libraries than what Anaconda comes with, I can put the commands in the notebook, and I won't mess up the recipient's system version of Python. With org-mode, they'd need to figure it out on their own.

If I choose to use a different language than Python in my org-node notebook, the recipient will have to install that programming language and environment themselves before they can use your notebook.

It's the simplicity and bundling of dependencies that make Jupyter popular. All the flexibility and power you get with org mode comes at a high price.

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

#104
post #93

Earlier quoted context omitted.

I would love discussing the literate ray tracer I have been working on and the literate programming workflow I have made for it. Couldn't find your email in the profile, mine is abhirag@outlook.com, would be great to discuss if I can improve my workflow further :)

Just sent you a mail (check spam folder if you don't see it, it comes from my own domain, and sometimes it's dumped with the spam)

Found it in the spam folder, will mail you the details soon :)

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

#105
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 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…

This is a good summary of the problems I have with the Mathematica notebook interface. And just as with the problems I described with the typography on PDF output, when you encounter something like Latex output that reads "\text{Sin}[]" you have to wonder, is this bad by mistake or bad on purpose?

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

#106
post #96

Earlier quoted context omitted.

> One of the more compelling reasons to use Jupyter is inline images and plots You can do those in org, since forever. I meant that the files themselves are plain text, which is good for sharing, version control, etc. ipynb files embed images with Base64 encoding, which makes seeing diffs a major PITA. >This is a wierd thing to say. Jupyter has download as .py right in the file menu. Not to mention download as Markdo…

I Agree with all those points. I've used org mode for a few things, but not for python notebooks. I remember seeing a great video a few years back on using python in org mode to make a research notebook. It really made me want to try org mode for literate / notebook style programming. I think it was this one: https://youtu.be/1-dUkyn_fZA It sounds like org mode does not store images inline, since you don't like the b…

>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 is made for python and org mode isn't. Jupyter comes with python and libraries, where with Emacs you're on your own to figure out how to install and use different languages, and setup your environment so Emacs can see them

Well, that requires a minimum of computer literacy, but rocket science, it ain't. I agree that Emacs is not for everyone, but if you're doing data analysis (and presumably something with the results), it's certainly not out of reach, and good tooling is worth learning.

I agree that Jupyter is "easier", but it's not simpler. And also, it's limiting in what it can do. So yes, you might get up and running a bit faster, but you're setting yourself for frustration down the line.

> Yes, but the editor is Emacs.

Precisely, it's vastly better than the alternative. If you don't like the bindings, you can use Evil (this is my choice, despite never having been a heavy vi user), or CUA mode, and get a more familiar experience for people used to Windows.

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

#107

Earlier quoted context omitted.

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

Yeah, I guess that is fair. It might just be that it is more or less the furthest way from how I like to work as I can imagine. > Sin[θ] //TraditionalForm //TeXForm Did not know of this. Thanks!

TeXForm automatically applies TradionalForm unless another *Form is applied.

So TeXForm[Sin[x]] gives "\sin (x)"

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

#108
post #103
post #92

Earlier quoted context omitted.

I share your opinion about the superiority of org-mode as a means to assemble a document out of various pieces. It's not hard to show nicely formatted code, the code's output, the math behind the code and perhaps a graph of the results all in a LaTeX/PDF document and or HTML. All of this can be done with a flat text file that is easy to save as a part of a project under source control. What I wonder is why are Jupyte…

> What I wonder is why are Jupyter notebooks so popular? How easy is it to share a Jupyter notebook with someone else, versus sharing an org-mode notebook? Think about the recipients rather than how hard it is for you. Assume the person you share with needs to be able to re-run your notebook. Assume the person you share with isn't using the same operating system that you are. Be honest and think about all the steps i…

> 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 different language than Python in my org-node notebook, the recipient will have to install that programming language and environment themselves before they can use your notebook.

Sure, and if you need to use another language from your Jupyter notebook, you can't. I don't get your point. Yes, if you need to use a tool, you need to install it. It requires a minimum of computer literacy.

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

#109
post #37
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've still got a Mathematica license. I never use it. For me, the out-of-pocket monetary cost was never an issue.

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

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

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

I am really interested in the specific advantages MathCAD had/has, and the problems you see with cells and being in a web browser.

> the coming revolution of non-web collaborative internet-connected rich client applications.

why? how is the web not up to this?

Post reply on HN