Live data from Hacker News

Jupyter, Mathematica, and the Future of the Research Paper

paulromer.net

161–170 of 179 posts

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

#161
post #14

Earlier quoted context omitted.

> it's free Well for you maybe – and we strongly believe it should be – but it's built on top of thousand of volunteers hours, grants money (Thanks Sloan, Helmsley, Moore) and donation from companies (Anaconda, microsoft...) and individual, and partners. NumFOCUS ( https://www.numfocus.org/ ) manage all of that it's a 501c3 tax deductible ! If Jupyter is of help to you (or your company, organisation) think about cont…

It's not free. Grant money means someone's paid for it (us, taxes). Volunteer is about credit, not fiat, but still costs something (gpl restrictions). Jupyter is great, it's revolutionized online education for example. But it's not as full featured as Mathematica, and like most Foss projects, slower to fix bugs, aka you get what you pay for. Both have a place unless you have hired, 100% dedicated help on juptyer. Thi…

Grant usually differ from US taxes. And AFAICT, Jupyter received no money from govt source.

Jupyter is not GPL but MIT, and volunteering is rarely about credit.

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

#162
post #153

Earlier quoted context omitted.

The writing style is very reminiscent of Ayn Rand.

Ouch

Have any downvoters actually even read Ayn Rand, or is it the usual people who don't even have to, because they know all they need to about her?

This segment, with it's hyperbole, ridiculous black and white simplification of complex matters, and tone of (over)confidence is unmistakably typical of her writing style:

"Jupyter rewards transparency; Mathematica rationalizes secrecy. Jupyter encourages individual integrity; Mathematica lets individuals hide behind corporate evasion. Jupyter exemplifies the social systems that emerged from the Scientific Revolution and the Enlightenment, systems that make it possible for people to cooperate by committing to objective truth; Mathematica exemplifies the horde of new Vandals whose pursuit of private gain threatens a far greater pubic loss–the collapse of social systems that took centuries to build.

Membership in an open source community is like membership in the community of science. There is a straightforward process for finding a true answer to any question. People disagree in public conversations. They must explain clearly and listen to those who response with equal clarity. Members of the community pay more attention to those who have been right in the past, and to those who enhance their reputation for integrity by admitting in public when they are wrong. They shun those who mislead. There is no court of final appeal. The only recourse is to the facts.

It’s a messy process but it works, the only one in all of human history that ever has. No other has ever achieved consensus at scale without recourse to coercion."

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

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

FWIW, I used MathCAD extensively around that period while in grad school (I taught physics lab courses that were 100% structured around MathCAD workflows). I hated it, and Jupyter is explicitly informed by that experience. So it's not like MathCAD very much by design, not by lack of knowledge.

We acknowledge there's a lot to improve in Jupyter, and some discussions in this post make excellent points (many of which we'd like to make progress on in the future). But the Jupyter team did probably use most/all of the modern scientific computing platforms, MathCAD included (and Maple, Mathematica, IDL, Matlab, Gnuplot, ...) at some point in our careers. We typically make our choices with reasonably good knowledge of the landscape.

We make mistakes, or our tradeoffs may be different than the optimal ones for your use case. But lack of knowledge of these tools is rarely the reason :)

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

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

I think of a Jupyter notebook as a REPL with superpowers. I can try code out in real-time and incrementally like a REPL, but when something breaks, the full history is right in front of me, so I can tweak something 10 lines ago and run the entire thing again like with an ordinary source file. It combines the best of both methods of programming. Seen that way, sharability is just a nice bonus. Yeah, I'd never try to t…

You should give some of the emacs modes a try. Could do this sort of stuff for wire a while now. And I'm really just talking of interior buffers. Not org.

Kind of odd, but repl on steroids is really just how dim the modern view of the old lisp machines is. Most of our neat repl tricks were just taken for granted on some of those machines.

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

#165

R Studio Notebooks are pretty good too; I like that, by default, there is an interactive console connected to the same kernel in addition to the notebook. This allows me to use the console to interactively probe my data, or try out something, and then record a more finished product in the notebook itself. I think this can be done in Juypter ( http://jupyter-notebook.readthedocs.io/en/latest/examples/No... ), but, not…

In JupyterLab (http://jupyterlab.readthedocs.io/en/stable/), this is built-in. Just right click a notebook and choose "New Console for Notebook".

JupyterLab is in beta and is intended to replace the current Jupyter front-end.

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

#166

R Studio Notebooks are pretty good too; I like that, by default, there is an interactive console connected to the same kernel in addition to the notebook. This allows me to use the console to interactively probe my data, or try out something, and then record a more finished product in the notebook itself. I think this can be done in Juypter ( http://jupyter-notebook.readthedocs.io/en/latest/examples/No... ), but, not…

In JupyterLab ( http://jupyterlab.readthedocs.io/en/stable/ ), this is built-in. Just right click a notebook and choose "New Console for Notebook". JupyterLab is in beta and is intended to replace the current Jupyter front-end.

cool!

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

#167
post #164

Earlier quoted context omitted.

I think of a Jupyter notebook as a REPL with superpowers. I can try code out in real-time and incrementally like a REPL, but when something breaks, the full history is right in front of me, so I can tweak something 10 lines ago and run the entire thing again like with an ordinary source file. It combines the best of both methods of programming. Seen that way, sharability is just a nice bonus. Yeah, I'd never try to t…

You should give some of the emacs modes a try. Could do this sort of stuff for wire a while now. And I'm really just talking of interior buffers. Not org. Kind of odd, but repl on steroids is really just how dim the modern view of the old lisp machines is. Most of our neat repl tricks were just taken for granted on some of those machines.

Yeah, I like the idea of that stuff, and org-babel too, actually. But the setup just seems like a bit of a bear. I use spacemacs, and the python layer for that[1] can spawn a repl and send code, but in order to do so incrementally, I have to manually select the code to send to the repl. The great thing about the cell construction in jupyter is that it supplies a natural way to organize chunks of code, you don't have to define the chunks of code before executing them.

That being said, it's still pretty sweet!

[1] https://github.com/syl20bnr/spacemacs/tree/master/layers/%2B...

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

#168

Earlier quoted context omitted.

Well, I asked the author for the data that led him to believe that the Julia community is "monopolistic", and he got mad and blocked me instead of linking to anything... https://twitter.com/ChrisRackauckas/status/98552939470474035... So your remark is pretty spot on.

You asked for that block in the second question. You sound very entitled to answers.

I am just curious what led him to his conclusions. He made a very nasty comment about a group of people and gives no justification for why. I cannot seem to find out why when Googling either. Is it not okay to ask someone how they came to their conclusions?

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

#169
post #164

Earlier quoted context omitted.

You should give some of the emacs modes a try. Could do this sort of stuff for wire a while now. And I'm really just talking of interior buffers. Not org. Kind of odd, but repl on steroids is really just how dim the modern view of the old lisp machines is. Most of our neat repl tricks were just taken for granted on some of those machines.

Yeah, I like the idea of that stuff, and org-babel too, actually. But the setup just seems like a bit of a bear. I use spacemacs, and the python layer for that[1] can spawn a repl and send code, but in order to do so incrementally, I have to manually select the code to send to the repl. The great thing about the cell construction in jupyter is that it supplies a natural way to organize chunks of code, you don't have…

Maybe you should try ob-ipython. It'll spawn a Jupyter server with a python kernel, and send your source blocks as cells, and you also get to keep all the other org goodies.

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

#170

Earlier quoted context omitted.

Yeah, I like the idea of that stuff, and org-babel too, actually. But the setup just seems like a bit of a bear. I use spacemacs, and the python layer for that[1] can spawn a repl and send code, but in order to do so incrementally, I have to manually select the code to send to the repl. The great thing about the cell construction in jupyter is that it supplies a natural way to organize chunks of code, you don't have…

Maybe you should try ob-ipython. It'll spawn a Jupyter server with a python kernel, and send your source blocks as cells, and you also get to keep all the other org goodies.

Thanks!
Post reply on HN