4 ms·
Nice work on this! I think apart from the very valid points raised by Joel Gru in his presentation slides, Jupyter Notebooks are woefully inadequate for explori
by _coveredInBees 7y ago
Nice work on this! I think apart from the very valid points raised by Joel Gru in his presentation slides, Jupyter Notebooks are woefully inadequate for exploring and understanding code that utilizes libraries. I'll take the FastAI library as an example since Jeremy Howard is the one who took Joel to task regarding criticizing Notebooks:
If I view any fastai notebooks taken from their repo, there are a million imports (having a bunch of `import *` statements in the fastai lib doesn't help things) and methods and classes keep popping up out of nowhere. Good luck making sense out of them in a notebook. At least in Pycharm or VS Code, it's one Ctrl+Click away from viewing the relevant source code and having a somewhat better idea of what is going on.
Debugging is woefully inadequate compared to the Pycharm experience (VS Code is slowly catching up with Pycharm on that front).
I've only found 2 good uses for Jupyter Notebooks:
1. As a scratch-pad to try out things without any plans to utilize directly or share the code with anyone
2. As a means to write well documented examples/code with a bunch of markdown...especially when I'm modeling things that have a lot of equations, where the LATEX support is a boon and makes the documentation in the notebook far superior to what you could achieve in a regular .py script.
In almost every other instance, you are better off using a full-blown IDE with a far superior development environment, ability to have venvs, superior debugging, superior code management/refactoring and most importantly, much better reproducibility.
All that being said, I think the direction in VSC is definitely a great step in the right direction. I honestly love VSC but can't give up PyCharm yet as it is still a long way ahead of VSC when it comes to Python features (much better linting, much better management of venvs and run configs, more powerful debugging experience... though VSC is getting pretty good, much better refactoring support and PEP-8 reformatting/linting). I really hope there is more of a push within MS to continue improving the Python experience in VS Code. Nothing would make me happier than to consolidate my work in VSCode! Keep up the awesome work!
- localhost 7y agoThanks for the kind words! I'm currently thinking about a model of notebooks / interactive programming where the default assumption is that you're using it as a scratchpad, i.e., you won't need to explicitly name the file in order to get the benefits of auto-save, but yet the file won't pollute your filesystem / project namespace until you choose to "keep" it. Hopefully this helps reduce the friction in the exploratory programming realm; my goal is to eliminate the "ConsoleApplicationX" directories (I'm a VS guy from way back so ...) and I think it helps with your scenario 1) above. The Python VS Code extension team is well aware of the gaps that you list as well, and are working hard to narrow them with each release. We are definitely serious about improving the Python experience in VS Code. How times have changed :) Thanks for the support and encouragement. And as always, if you find issues that aren't already in our github, feel free to add some more and keep the feedback coming!
- _coveredInBees 7y agoAwesome! Wish you guys the best. As someone who has made a few electron apps in the past couple of years (I am not a front-end/back-end guy), I have immense respect for the VSCode team and the quality of the product. They pretty much showed the whole world what a quality electron app can look like and that most of the blackeye electron gets for "performance" can be chalked down to poor programming practices and software design in the case of a lot of other electron apps.