Live data from Hacker News

Deepnote, a Jupyter alternative, is going open source

deepnote.com

171–179 of 179 posts

Re: Deepnote, a Jupyter alternative, is going open source

#171
post #166

Earlier quoted context omitted.

This is Akshay, the original creator of marimo. Our whole team has come over to CoreWeave. We're building a whole lot more, not less, and our number one priority continues to be the open-source. We're also growing the open-source team, i.e. we're hiring.

From the looks of it, CoreWeave is a crypto company now turned AI company, currently offering infrastructure/cloud services. Definitely no focus on data or developer tools. (Also see the recent "CoreWeave is a time bomb" recent articles here, https://hn.algolia.com/?q=CoreWeave ). It's sad Marimo got sucked up into this, I fully expect it will not receive the love and support it deserves, especially now that it was s…

Ooof, more bad signs

I'd argue the founders made the choice more than they company got sucked up

Re: Deepnote, a Jupyter alternative, is going open source

#172

Earlier quoted context omitted.

Not sure if this is sarcasm, but GP has good taste and when marketing this stuff to developers, you need good taste. Otherwise it just rings hollow, and doesn’t inspire enthusiasm.

It was indeed sarcasm. I suppose after so many years I should know better than to try using humor on Hacker News.

FWIW I usually try to be explicit by adding /s. Text is low bandwidth so a lot of nuance gets lost.

Re: Deepnote, a Jupyter alternative, is going open source

#173
post #45

Way to undermine an interesting product launch through poorly chosen language: > Let’s be frank the single‑player notebook has felt outdated for a while now. We’re open‑sourcing its successor. Jupyter belongs in the hall of great ideas — alongside “Hello, world.” and “View Source.” If you're trying to reach out to the Python community this is not the way to do it. Completely unnecessary hostile language there! Have s…

[dead]

Re: Deepnote, a Jupyter alternative, is going open source

#174
post #165

Earlier quoted context omitted.

It's not reasonable to expect a source code management system to display the last output of every Python script. It might have been convenient for Jupyter notebooks, but that was a side effect of what's essentially a negative feature, the last output of every cell being thoroughly mixed with the source code.

You may see it as a negative feature, but i see it as a positive feature. I can push my notebooks to GitHub with the outputs and share them with others. Those people can see what the results are without having to setup and run the notebook. This is incredibly useful for knowledge sharing and learning

Oh don't get me wrong, I have nothing against publishing notebooks, on GitHub or anywhere else. That was the convenient part. The negative feature was Jupyter mixing output into the file source code, making it difficult to version.

With Marimo, the way to achieve the same result is to have it (automatically) export the notebook to a _separate_ static HTML file: https://docs.marimo.io/guides/exporting/#export-from-a-runni...

Re: Deepnote, a Jupyter alternative, is going open source

#175

Earlier quoted context omitted.

It was indeed sarcasm. I suppose after so many years I should know better than to try using humor on Hacker News.

FWIW I usually try to be explicit by adding /s. Text is low bandwidth so a lot of nuance gets lost.

But also, there is nothing more humorless than a culture that needs identifying metadata to recognize jokes.

Re: Deepnote, a Jupyter alternative, is going open source

#176

It's telling that Wolfram / Mathemetica doesn't even come up in a blog post like this, as the inventors of "the notebook". Jupyter took the concept to a whole new level, but the concept did originate in Mathematica 30 years ago!

They've edited that in as a footnote.

Re: Deepnote, a Jupyter alternative, is going open source

#177
post #12

I'm not involved in any capacity with the development or use of Jupyter—I think ipynb is fundamentally flawed at a deep level, starting with its (I)Python roots—but this company's framing of their product as "the successor to Jupyter notebook" comes across as passive aggressive at best and misleading at worst. What is their relationship to Jupyter besides building a Jupyter alternative?

What are some of the flaws surrounding IPython and ipynb in particular?

The .ipynb format mixes source code with nondeterministic program output in the same file and regularly has backwards-incompatible format "upgrades". Those two make version control a nightmare. The files are also huge because they typically contain humongous base64-encoded PNGs.

The execution model also keeps invisible state in the running kernel, so fairly often if you restart the kernel and re-execute all cells, you'll get a traceback or, worse, subtly different results (and, alarmingly for something called a "notebook", your old results have been erased with no confirmation and no undo). This can happen for a variety of reasons, like deleting the definition of an object you are still using, or defining a new object in the last cell, using it in some subsequent cells, and then going back and changing some earlier cells to use it too.

If you get an .ipynb file from a coworker, you need to read it carefully before hitting "Execute all below" in case there's a cell saying something like "execute this cell to do an emergency shutdown of the production server", because that is a thing people do with entirely good intentions.

Re: Deepnote, a Jupyter alternative, is going open source

#178
post #177

Earlier quoted context omitted.

What are some of the flaws surrounding IPython and ipynb in particular?

The .ipynb format mixes source code with nondeterministic program output in the same file and regularly has backwards-incompatible format "upgrades". Those two make version control a nightmare. The files are also huge because they typically contain humongous base64-encoded PNGs. The execution model also keeps invisible state in the running kernel, so fairly often if you restart the kernel and re-execute all cells, yo…

The problems described here notwithstanding, it's not exactly what I meant when I mentioned _fundamental_ flaws. I was referring to the decision to follow the paradigm where to share an MS Word or Excel document, the recipient will need to acquire and install a copy of Microsoft Office (or research acceptable third-party compatible viewer programs—an exercise even more fraught than installing Office proper).

Another commenter went on to write a lengthy comment (likening it to an IDE, however, which is an analogy that doesn't really work, and where the Excel comparison is really most apt): https://news.ycombinator.com/item?id=45815212>

> We're literally asking users today 'to view this notebook install Jupyter/Marimo/whatever and open from there' when the Notebook is designed to create the publication […] In general the output i demonstrate above should be the minimum bar [for what a notebook is]

Any desktop preparation pipeline for ostensibly sharing research that doesn't leverage the ubiquity of the World Wide Wruntime needing no installation (either that, or able to output self-contained, source-carrying executables supporting decompilation that you're expected to run like a video game rather than open like a PDF—all of which is fraught with other obvious problems) is not really solving the research-sharing problem. Jupyter just repeats what has always plagued the Python world and was never solved despite the existence of e.g. Anaconda.

Re: Deepnote, a Jupyter alternative, is going open source

#179
post #178
post #177

Earlier quoted context omitted.

The .ipynb format mixes source code with nondeterministic program output in the same file and regularly has backwards-incompatible format "upgrades". Those two make version control a nightmare. The files are also huge because they typically contain humongous base64-encoded PNGs. The execution model also keeps invisible state in the running kernel, so fairly often if you restart the kernel and re-execute all cells, yo…

The problems described here notwithstanding, it's not exactly what I meant when I mentioned _fundamental_ flaws. I was referring to the decision to follow the paradigm where to share an MS Word or Excel document, the recipient will need to acquire and install a copy of Microsoft Office (or research acceptable third-party compatible viewer programs—an exercise even more fraught than installing Office proper). Another…

These are good and important points, and I'd add that the rapid churn in the software ecosystem, especially in the Python world, further undermines the ideal of reproducibility, both at the most basic PDF level of "Can I see the visual appearance that the author intended?" and the deeper level of "Can I reproduce the calculations the author made from their empirical data?"

This morning I was reading a very valuable paper on eutectic points of evaporite salt mixtures from 01972, 53 years ago. If you publish something today in electronic form, how confident are you that it will be readable in 02078? Plain HTML and PNG will probably be readable, but it might not be ideal to depend on Web Workers, WebAudio, or the darker corners of the PDF spec.

Post reply on HN