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 :)
+1 to the team that's been doing a phenomenal job on the project... These days I'm just an email answering machine :)
But yes, JLab is shaping up quite nicely, opening up a lot of interesting possibilities. For advanced users/early adopters I think it's time to start playing with it (and filing issues for anything that's broken/sub-optimal, we really want to provide a great user experience with it once we hit 1.0).
And btw, it's worth mentioning that in JupyterLab, we just merged a PR that will make embedding the Monaco editor (the editing component of VS code) much easier: https://github.com/jupyterlab/jupyterlab/pull/1140.
We all want stronger editing capabilities, but it doesn't make sense for the Jupyter team to get into the business of writing text editors (plenty of better folks doing a great job on that already). So we're just trying to make it easier to integrate other text editors into the everyday workflow.
IPython creator here, just to say I'm thrilled to see this! We've wanted more languages to follow this route, and while we have only had time to work directly with the Julia team, it's fabulous to see others following up with the idea.
Please don't hesitate to ask us on the dev mailing list if you run into any problems. For one thing, we're planning on making some updates to the protocol spec soon, based mostly on the experience of the IJulia work. It would be great to have your input there as well, in case you spot something that wouldn't fit well the patterns you saw while doing the Haskell port.
And besides, this means I now have one less excuse to get off my butt and learn Haskell! :)
I'm also a researcher, but I've had to learn how these things work :) When you accept funds for a grant, that's a contract between the funding agency and typically your employer (UC Berkeley in my case), not you as a person. It's a contract to deliver the outcomes that you specified in your proposal.
A donation is just that, a donation: no strings attached, it is made in support of recipient's work and mission, but without any specific task in mind. Just like when you donate to your local public radio, you can't say "I want these funds to pay only for such and such program I like".
a) it's $100k we didn't have, and which we greatly appreciate. We have a 'donate' button on the site, but that's basically a few dollars a day, more or less. It will pay for pizza for a sprint every few months, and that's about it.
b) we've supported Windows for years, money or not. The core team isn't made of Windows experts, so our support may not be always ideal, but we always test on Windows, have Windows CI running, and always release Windows installers. Windows is widely used and we want the experience there to be as solid as possible. The money was a donation, no strings attached (under US law it can't have strings attached, since it's a donation to a 501c3).
Feel free to ask for help on our mailing list. We regularly test IPython with python 3.3, and one of our core developers is a python-3 person, so he's using it day in, day out.
You most likely didn't run the installer correctly, and for some reason are trying to execute the python2 sources with python3.
We are extremely aware of this fact, and are working very, very hard to ensure that the format is a robust component of long-lived, archival-quality workflows.
We (in the IPython project) are interested in using it for capturing reproducible research workflows all the way up to the publication stage, so we're painfully aware of the importance of format stability, good conversion tools and support for early format migration forward.
We see many others investing their own time in using our tools, and we know we'd get burned at the stake if we make gratuitous changes that harm their workflows.
We do have some format changes in mind, but we've been "bunching them up" precisely so we can make format revisions only very rarely (we haven't done any in ~2 years), and with rock-solid support for conversions and migration.
Please ping us on the ipython-dev mailing list; the core team is all made up of academics and we have a strong interest in educational uses (we're using it for our own courses), so it will be good to coordinate/share ideas on this front.
Indeed, and communicating that clearly and effectively is something that we don't always succeed at. This is the reason why, on many occasions I had to resist fairly vociferous requests that we split up the parallel computing code from the shell, and also all the clients.
In the future that may make sense, once our internal protocols and APIs are so stable that we can do so without breaking functionality just as a way to help decouple development. But as a way to think about computational workflow, these pieces are all part of a coherent vision. It's just one that we don't always communicate clearly :)
You can always use `%doctest_mode` to toggle back and forth between IPython-style prompts and `>>>` ones (along with changing exception mode to be more standard-looking).
I think I've only commented a handful of times, I'm not really a regular. But many thanks for the kind words, and to @profjsb for the generous writeup.
As I tried to say at the meeting, this really goes to the whole team. I may have started IPython, but it's the combined talent, energy and dedication of a big team that makes it what it is today. This award is a recognition of all that work, I'm just here to pick it up :)
Note that we also intend to at least expose Emacs/vim keybindings for the text area as soon as possible. It's not hard as codemirror has most of the bits we need, we just haven't had the time for it.
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 :)