4 ms·

https://www.cursor.com/ https://www.cursor.com/ - an AI-first VS Code clone VS Code (and Cursor) has so nice Jupyter support that I find it much better to use

by stared 2y ago

https://www.cursor.com/ https://www.cursor.com/ - an AI-first VS Code clone VS Code (and Cursor) has so nice Jupyter support that I find it much better to use it for my workflow, rather than using any dedicated solution for Jupiter Notebooks only.

dakshgupta 2y ago
IMO data scientists often are used to the jupyter form factor instead of the editor form factor, so I see why they would prefer this thing.
- stared 2y ago
  I am a data scientist myself, one who moved from academia, vide https://p.migdal.pl/blog/2016/03/data-science-intro-for-math-phys-background https://p.migdal.pl/blog/2016/03/data-science-intro-for-math.... I used Jupyter Notebook before it was popular and back when I was a PhD student. I pushed in a few places for the unorthodox way of exploring data in a browser. Now, I am back - but only thanks to wonderful code editors and their good support of Jupyter Notebooks. I recommend VSC (or, this year, Cursor) as the default environment for data sci.
  - prasoonds 2y ago
    That's a cool blogpost! I'm mostly using Cursor now (just waiting until someone makes a kick-ass Emacs package so I can switch back!) so I can definitely see your perspective. I'd be curious to hear a bit more about the kind of work you do that made you switch. Also if there's anything you miss in VSC/Cursor vs Jupyter. If you don't mind a small email exchange, let me know and I'll drop you a message :)
    - stared 2y ago
      Thank you! If it is of public interest, I am happy to discuss it here. If you want to shoot me an email, that would be great. My path is in "What I do or: science to data science" (https://p.migdal.pl/blog/2015/12/sci-to-data-sci https://p.migdal.pl/blog/2015/12/sci-to-data-sci)... and well, a bit more recent one in "Embodiment for nerds" (https://p.migdal.pl/blog/2021/09/embodiment-for-nerds https://p.migdal.pl/blog/2021/09/embodiment-for-nerds). Regarding the shortcomings of the Jupyter Notebook, I made a few notes in "How I learned to stop worrying and love the types & tests" (https://p.migdal.pl/blog/2020/03/types-tests-typescript https://p.migdal.pl/blog/2020/03/types-tests-typescript).
prasoonds 2y ago
Agree with Daksh in the sibling comment. I think it's like you said - different people have different workflows and some might prefer using VSCode. IME though, most data scientists (and all data analysts) I worked with preferred using the company hosted internal Jupyter instance for their work. Also, as we build more features, we're definitely going in the direction of more analytics workloads (live collaboration, leaving comments, google-doc type versioning, fully AI driven analyses similar to OpenAI Interpreter mode etc) and with these features, I think there will be a clear divergence of feature-set in VSCode/PyCharm vs Pretzel. If I may ask, are you more on the engineering side (MLE) or more on the data side (Data Analyst)? EDIT: Just saw your other comment!
- stared 2y ago
  I am speaking of my experience, and I am an enthusiast for new things. I used the Jupyter Notebook before it was mainstream, or, say, PyTorch, in times when it was obvious that TensorFlow was the default option. However, in general, I believe that any approach that works is good. And I don't think there is any reason to think that we need to settle with the current data science programming UIs. However, some went with mixed success, e.g. ObservableHQ never took over Jupiter. In my view, PyCharm and VS Code are not that close to each other. PyCharm is a traditional IDE, while VS Code is more like an ecosystem of extensions. In particular, there is one (surprisingly good) for Jupyter Notebooks. When developing any new way of interacting with code, there is a question of which ecosystem to use. Having it as a VS Code extension (or clone) has benefits and limitations. So is having it as a Jupyter extension or (the way you went) - clone. If you want to talk more, happy to move it to emails.

by stared 2y ago

dakshgupta 2y ago

IMO data scientists often are used to the jupyter form factor instead of the editor form factor, so I see why they would prefer this thing.

stared 2y ago
I am a data scientist myself, one who moved from academia, vide https://p.migdal.pl/blog/2016/03/data-science-intro-for-math-phys-background https://p.migdal.pl/blog/2016/03/data-science-intro-for-math.... I used Jupyter Notebook before it was popular and back when I was a PhD student. I pushed in a few places for the unorthodox way of exploring data in a browser. Now, I am back - but only thanks to wonderful code editors and their good support of Jupyter Notebooks. I recommend VSC (or, this year, Cursor) as the default environment for data sci.
- prasoonds 2y ago
  That's a cool blogpost! I'm mostly using Cursor now (just waiting until someone makes a kick-ass Emacs package so I can switch back!) so I can definitely see your perspective. I'd be curious to hear a bit more about the kind of work you do that made you switch. Also if there's anything you miss in VSC/Cursor vs Jupyter. If you don't mind a small email exchange, let me know and I'll drop you a message :)
  - stared 2y ago
    Thank you! If it is of public interest, I am happy to discuss it here. If you want to shoot me an email, that would be great. My path is in "What I do or: science to data science" (https://p.migdal.pl/blog/2015/12/sci-to-data-sci https://p.migdal.pl/blog/2015/12/sci-to-data-sci)... and well, a bit more recent one in "Embodiment for nerds" (https://p.migdal.pl/blog/2021/09/embodiment-for-nerds https://p.migdal.pl/blog/2021/09/embodiment-for-nerds). Regarding the shortcomings of the Jupyter Notebook, I made a few notes in "How I learned to stop worrying and love the types & tests" (https://p.migdal.pl/blog/2020/03/types-tests-typescript https://p.migdal.pl/blog/2020/03/types-tests-typescript).

prasoonds 2y ago

Agree with Daksh in the sibling comment. I think it's like you said - different people have different workflows and some might prefer using VSCode. IME though, most data scientists (and all data analysts) I worked with preferred using the company hosted internal Jupyter instance for their work. Also, as we build more features, we're definitely going in the direction of more analytics workloads (live collaboration, leaving comments, google-doc type versioning, fully AI driven analyses similar to OpenAI Interpreter mode etc) and with these features, I think there will be a clear divergence of feature-set in VSCode/PyCharm vs Pretzel. If I may ask, are you more on the engineering side (MLE) or more on the data side (Data Analyst)? EDIT: Just saw your other comment!

stared 2y ago
I am speaking of my experience, and I am an enthusiast for new things. I used the Jupyter Notebook before it was mainstream, or, say, PyTorch, in times when it was obvious that TensorFlow was the default option. However, in general, I believe that any approach that works is good. And I don't think there is any reason to think that we need to settle with the current data science programming UIs. However, some went with mixed success, e.g. ObservableHQ never took over Jupiter. In my view, PyCharm and VS Code are not that close to each other. PyCharm is a traditional IDE, while VS Code is more like an ecosystem of extensions. In particular, there is one (surprisingly good) for Jupyter Notebooks. When developing any new way of interacting with code, there is a question of which ecosystem to use. Having it as a VS Code extension (or clone) has benefits and limitations. So is having it as a Jupyter extension or (the way you went) - clone. If you want to talk more, happy to move it to emails.