https://www.theatlantic.com/science/archive/2018/04/the-scie...
It basically makes the case that things like Jupyter notebooks are the future of scientific publishing.
And here's the accompanying HN discussion for convenience: https://news.ycombinator.com/item?id=16764321
Beyond that, the web wasn't created to improve publishing, it just did as a side effect. It was started for information exchange within collaboration, and it certainly has done that.
Experimental collaborations at CERN in the 80's were not too large at most around 50 authors (NA31 < 40 , NA32 < 50 ), by the next generation it was up to 350 distributed over 32 locations, and the current collaborations are at around 3000 over 180 locations.
The web is a crucial component of the information systems that allow these collaborations to function at all.
With Latex, we have a powerful tool at the hand which makes sure every single student can write himself a perfectly shaped PDF which looks timeless.
It doesn't even matter whether your favourite open access journal renders the paper as HTML -- they only took the Latex and transformed it.
It also doesn't matter that we have meta search engines for literature references (for instance http://inspirehep.net/ or https://ui.adsabs.harvard.edu/), or that we do have archives for uploading scientific data (https://zenodo.org/ or in general https://www.re3data.org/): The papers are still non-interactive, still linear (not clickable hypertext).
Science is old fashioned and slowly moving...
https://en.wikipedia.org/wiki/Java_(programming_language)#Hi...
That being said, I have a hard time seeing myself moving from Python to JS for any 'real' data science work when I get a lot of the more advanced viz features here for free from libraries like plotly without having to touch JS and with similar or better performance. Not to mention, I don't have any desire to move away from PyCharm after getting comfortable with and really taking advantage of of its full feature set.
I think for small projects this could be very useful, especially with GDocs style real time collaboration, but for now I can't see myself or my teammates taking advantage of this.
That being said, I vote full steam ahead and lets see where this takes us!
+1 - this is the right attitude to have! If you have a productive data science team, you should continue to use the tools you have - we'd be the first to tell you that. Re: the JS thing, we've found through user testing and our own experience as data scientists that folks don't really want to use JS for anything, and we want to meet some segment of data scientists where they are. As explained in the post, JS as a language and ecosystem isn't quite there in the way that it needs to be. In a few years, it may be, if you follow along w/ the various TC39 proposals out there.
To clarify, we do have support for Python / NumPy / Pandas / Matplotlib / others with Pyodide, which is natively supported in Iodide with the `%% py` delimiter. It doesn't address all the other workflow issues you have, of course, and there are some differences b/t a server kernel and what we have.
Surely there’s a better solution here? Maybe something like pandoc but for presenting science stuff in the browser? Do your work in whatever language, write up results and graphs using preferred tools and packages, output some kind of format that can be parsed to produce this stuff?
So you'd have things like 'await sleep(1)' which would be implemented with a Promise and setTimeout. Or 'await fetch("/api/v1/list")'.
Unfortunately I haven't gotten very far yet.
For example, running `await Promise.resolve(3)` in Chrome's js console prints `3`.
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Any JS Promise is awaitable from JS; JS async/await is (more or less) syntactic sugar on top of promises.
[1] www.shenlanguage.org
So they made a Markdown syntax which is capable of running JS and Python, and they name it JSMD.
Just nitpicking but they probably want to come up with a more suitable name other than JSMD. I'm genuinely amazed by this project though.
Other than that I love the design of the syntax, especially raw cell seem so great to me. I'm often supersized by the fact that both Markdown and Jupyter don't have the official ways to insert comments. Fetch cell is also a smart idea.
I'm wondering how the performance looks like when running Pyodide stack on JS.
The python data stack running in web assembly!
https://github.com/iodide-project/pyodide
Hats off to the team, this is some really neat stuff and I'm happy to see it coming from Mozilla.
Imagine if web servers were just standard containers and services which anyone could upload applications to. That would take us to a decentralised internet once again. No more centralized, fossilized, web application with stacks that are impossibly complex that only the original developers could change. All the power and innovation would be put in the hands of the content creators once more and the internet would just be infrastructure. Sound familiar? I hope so.
Time to program like it's 1999.
> It’s like JupyterHub, but for people who only know javascript?
That also was my feeling. And since Jupyter is language agnostic, why not just run a JavaScript kernel, such as https://github.com/n-riesco/ijavascript . It looks somehow as if Iodide is exactly that.
I'd love to see someone come up with a path taking something like this or Jupyter and have it target a wide market and extend the capabilities in an accessible way. I think you'd blow half steps like Airtable out of the water.
To be clear, I love Jupyter, and I think it's especially great for teaching beginners (especially because it has "real" cells, as in GUI widgets, though I do get the appeal of a flat plain text format for advanced users). But plotting has been a bit of a stumbling block, whereas the way it works in Iodide blew me away.
But on the other hand, I remain unsure that it makes sense to continually try to push everything into the browser. Take:
Iodide documents live in the browser, which means the computation engine is always available. Whenever you share your work, you share a live interactive report with running code. Moreover, since the computation happens in the browser alongside the presentation, there is no need to call a language backend in another process. This means that interactive documents update in real-time, opening up the possibility of seamless 3D visualizations, even with the low-latency and high frame-rate required for VR.
I mean, yeah, OK, there are aspects of this that make sense. But there are always tradeoffs. Take, for example this point: "there is no need to call a language backend in another process". This also means that you're limited to the processing power available on your local machine, which is - BTW, being shared among everything running on your computer.
I'm not saying that Iodide is bad, mind you. But it - like any other tool - may not be appropriate for everything. As a corollary to that, I think it might be a fun experiment to see what it would take to provide an ability to move the computationally expensive parts between the local computer and a remote $BEEFY_HOST in a seamless way.
You have convinced me to try this now!
