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

Lessons learned reinventing the Python notebook

marimo.io

Post reply on HN
Print view View original

21–30 of 44 posts

Re: Lessons learned reinventing the Python notebook

#21

Post by akshayka »

wokwokwok wrote: post #13

> marimo makes it seamless to go from prototype to production. No, it doesn’t. In fact, no tool; not retool, not any of no-code solutions, free or paid, lets you take a hacked up prototype and seamlessly put in into production. In fact, even claiming that it does makes me question the other (superficially quite laudable) things it claims to do; eg. plain python files. Why do people go down these rabbit holes? You can…

token/password protection is in the works; just designed it with my co-maintainer yesterday.

Re: Lessons learned reinventing the Python notebook

#22

Post by Kalanos »

Kalanos wrote: post #18

as a daily jupyter user, i like this .py DAG approach a lot - more so for visualizing complex workflows than addressing a potentially corrupt hidden state. there isn't much *data science functionality* integrated into jupyter core apart from displaying static dataframes (nor is their internal desire to add it), and jupyter *extensions/widgets* should really be built with dash/streamlit, so i'd encourage you to make a…

why the downvote? debate me. it's saturday and i'm working in jupyterlab

Re: Lessons learned reinventing the Python notebook

#24

Post by akshayka »

taeric wrote: post #16

I find it so weird to see Jupyter being the "traditional" option in this discussion. Kudos for the shout out to excel being the main "notebook" most people have experience with. I question the choice of Python as the format. Agreed that Json is terrible. But Python will have similar problems. And a notebook is a marked up document. Using a markup language is a natural choice. Delimit areas of particular syntax and yo…

We're adding support markdown with fenced code blocks, which maybe gets you closer to "delimiting areas of particular syntax": https://github.com/marimo-team/marimo/pull/1332.

Python is nice because it enables composition and reuse as vanilla scripts. But there are definitely tradeoffs.

Re: Lessons learned reinventing the Python notebook

#25

Post by akshayka »

azhenley wrote: post #23

A lot of improvements! Relevant to my 2020 article: What’s wrong with computational notebooks? https://austinhenley.com/blog/notebookpainpoints.html

Yes! I remember reading your article very closely a few years ago, before starting work on marimo. Thanks for writing it and sharing it here.

Other things we looked at closely: Joel Grus' (in)famous talk on notebooks, and obviously Pluto.jl.

Re: Lessons learned reinventing the Python notebook

#27

Post by mscolnick »

wokwokwok wrote: post #13

> marimo makes it seamless to go from prototype to production. No, it doesn’t. In fact, no tool; not retool, not any of no-code solutions, free or paid, lets you take a hacked up prototype and seamlessly put in into production. In fact, even claiming that it does makes me question the other (superficially quite laudable) things it claims to do; eg. plain python files. Why do people go down these rabbit holes? You can…

production != public, in most cases.

If you are making things public, you likely care about more than just a password, which you'll want to push into an auth gateway with oauth support, authZ, rate-limiting, etc.

Re: Lessons learned reinventing the Python notebook

#28

Post by fifilura »

wokwokwok wrote: post #13

> marimo makes it seamless to go from prototype to production. No, it doesn’t. In fact, no tool; not retool, not any of no-code solutions, free or paid, lets you take a hacked up prototype and seamlessly put in into production. In fact, even claiming that it does makes me question the other (superficially quite laudable) things it claims to do; eg. plain python files. Why do people go down these rabbit holes? You can…

Yours is the fundamentalist view and it always has its place in the debate. But it is not necessarily what the organization needs.

There are benefits of running notebooks in production rather than reimplementing things in another environment.

1. The prototype is tested and verified. And I don't mean tested as in 50 unit tests and integration tests. But tested in the way that a human actually looked at the result and was satisfied. Reimplementing means that you will start from scratch.

2. That the production env is the same as the analysis env means that it is trivial to go back and debug issues.

3. Sometimes maybe what you need is a fast solution. Not sending stuff into the scrum loop of a separate engineering team and pray it makes it into a sprint not so far away.

TL;DR get shit done.

Re: Lessons learned reinventing the Python notebook

#29

Post by tiledjinn »

dan-g wrote: post #11
tiledjinn wrote: post #9

Earlier quoted context omitted.

no, it's a failed concept. frequently you'll find effectively shell scripts that couple workflows to some graphical environment for spurious reasons -- except they're baked with bad assumptions about state in that environment as outlined in the article. if you want knuth's literate programming, just comment liberally per that guidance. or carry forward with them and print your retractions later. vOv

I’m not sure what your definition of “failed” is, but notebooks of various kinds have been bringing value and accessibility to various different programming languages for a while now. If it was a “failed concept” I don’t think we’d see as much adoption, let alone new iterations and advancements in the space. Just because you don’t use something doesn’t mean it’s not worth something to someone else (or in this case, a…

inferior mechanisms frequently gain popularity, despite whether people who adopt them would be better off if they didn't.

people shouldn't use measuring cups either; since scales are more accurate, faster, and involve less cleanup. and yet.

Re: Lessons learned reinventing the Python notebook

#30

Post by Kalanos »

wokwokwok wrote: post #13

> marimo makes it seamless to go from prototype to production. No, it doesn’t. In fact, no tool; not retool, not any of no-code solutions, free or paid, lets you take a hacked up prototype and seamlessly put in into production. In fact, even claiming that it does makes me question the other (superficially quite laudable) things it claims to do; eg. plain python files. Why do people go down these rabbit holes? You can…

.py is undeniably more widely compatible in production envs than .ipynb
Post reply on HN