the only ergonomic solution to me is to maintain a converted script of notebooks and using it for diff tracking, productionizing, etc. through a simple abstraction.
Lessons learned reinventing the Python notebook
41–44 of 44 posts
Re: Lessons learned reinventing the Python notebook
#42“I had 3 desiderata for it”
Ummm why use such a fancy word for requirement ? Put me off reading the whole article.
Re: Lessons learned reinventing the Python notebook
#43I am in the market for an alternative to Databricks' notebooks. Essentially, I want to use spark-connect, but also interact with delta tables directly via polars and duckdb (while still leveraging Ibis).
Support for Observable tier plots would be amazing.
Re: Lessons learned reinventing the Python notebook
#44> 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…
If the target is C++ you can use my library https://github.com/xlladdins/xll. It makes it easy to call C++ from Excel.