Is it Jupyter envy? Why is it not possible to keep one good product and stay with it?
I wish MatLab licenses weren't so expensive, at this point I'd just buy one and sit all this churn out.
Also, a lot of the Posit team are fully "bilingual", it's not like the old guard of academic R contributors. My impression is they appreciate both languages for what they have to offer.
For me, I'm apathetic to the languages, the only thing I care about is the output.
This is absolutely the case. Dplyr syntax is much more intuitive for many use cases than Pandas or Polars equivalents.
One thing I miss from RStudio is the Rmarkdown documents with inline outputs. Jupyter notebooks, even in VSCode, are so needlessly over-engineered and under-featured compared to the elegance of RMarkdown. So I am excited to see what Posit can do to bring that experience to python. My git repos will be thankfull anyway.
The funny thing is that the R in Jupyter actually stands for R (the language). It's Julia, Python and R. No need for envy.
Of course, RStudio/Posit != R (at least in theory)
If you had no legacy or compliance requirements, are you going to start a new data project in SAS, R, or Python? Where are you going to find the most talent?
Of course, ML projects and other things that need to result in production-grade models are almost always done in Python. This is currently the most visible form of "data project" due to all the ML/AI hype, but it is far from the only data work going on.
For a "big data" project, people will probably use Python (though Google apparently retreats from it except in machine learning).
Why could you not use R and C++ or Java though? For example, Arrow has bindings for both, so the argument that Python is needed to shovel/scrape/steal data becomes less and less valid.
In practice we have nearly ZERO development for desktop apps, simply because modern desktops are still widget based stuff who was sold a "what we need", against the complexity of classic DocUIs, and then we migrate to modern web witch is a bad DocUI, so developing for the desktop is simply a nightmare. To add features we can't much "use the environment" so all apps tend to try doing anything inside evolving toward unmaintainable monsters no one can handle their codebase and at a certain point in time they became a kind of a framework where "features" became "ideas of someone" without a coherent vision or a target "for the application" like Eclipse from an IDE to a platform some use to code, some others to pay taxes (yes, Italian gov. have made Desktop Telematico witch is a custom Eclipse to fill taxes).
As the classic Greenspun's tenth rule we witness the same: we damn need an OS as a single user-programmable application like Emacs or doing ANYTHING is a nightmare and there is no long lasting solution.
A data science focused version of VS Code with some kind of notebook sounds rather awesome to me.
I prefer coding in VSCode but prefer data exploration in RStudio.
One issue with this is the lack of copilot. Copilot can be installed on VSCodium [1] but it breaks often. The other is MS’s proprietary Remove Development extension that enables a lot of functionality in VSCode. There is an open equivalent but I haven’t tried it [2]
I've heard that one way to use it effectively is writing a detailed comment about what you want to do, then let it suggest the code. I personally don't like those style of comments, so I'd have to:
- enable copilot if I have it disabled (I have a keymap for this in vim)
- write the comment
- carefully review that the suggestion is correct and complete
- accept the suggestion, then go back up to delete the comment
kinda inconvenient, but if I was blanking on a bunch of stdlib functions maybe it would help? But accepting the copilot suggestions doesn't add imports, whereas accepting language server suggestions often does (e.g. with gopls).
Most of the time it is just autocomplete on steroids. Scanning the suggestion and hitting tab is almost always faster especially if you have to write a lot of repetitive code.
Generating useful documentation.
I work a lot with legacy codebases. Oftentimes I use copilot to explain what a chunk of code is doing, or give it a requirement and see what it generates based on context. At this point I think working with a legacy codebase as a new maintainer would be a lot harder if I didn't have copilot.
The other way that works OK is when drafting new code, I can write some comments about what I want to do and trigger Copilot via a keybinding to draft a first version of the code. It can be useful when working with new libraries since I often don’t know what functions to lookup in the documentation.
Automatic not being useful was the least of the issue, it used crazy CPU, slowed down the IDE, and drained my battery too.
Otherwise, I’d be all in for this!
https://omz-software.com/pythonista/
Pyto is maybe less approachable but more up to date, with clang compiler and LLVM bitcode interpreter:
Juno is Python notebooks:
https://juno.sh/https://juno.sh/
In general I prefer Blink Code:
They've added support in blink as well which is my favorite iOS purchase for productivity on my iPad https://blink.sh/
We have no plans to stop development or maintenance on RStudio, and are committed to it for our users, both paid and community. While Positron and RStudio have some features in common, some R-focused features will remain exclusive to RStudio. If you're currently using RStudio and are happy with the experience, you can continue to enjoy RStudio. RStudio includes 10+ years of applied optimizations for R data analysis and package development.
Cross-posting the FAQ: https://github.com/posit-dev/positron/wiki/Frequently-Asked-...
It seems with some JavaScript generated from Java via Gwt. Regardless, I prefer it over VSCode UI.
However it also made it impossible to build the kinds of experiences we wanted to with Positron. Positron has a bunch of top-level UI as well as some integrated/horizontal services that don't make sense as extensions. We built those into the core of the system which is why a fork was necessary.
It's a goal for Positron to be extensible, so it has its own API alongside VS Code's API, and both the R and Python language systems are implemented as extensions.
When I open it with positron, it is treated like a text file, at least as far as I can tell by looking at the many icons and pulldown menus.
It is a weird choice, making a new application that cannot handle the key file type from its ancestor.
We do hope to add better GUI tooling for project-level actions; more info here: https://github.com/posit-dev/positron/issues/1486
Because Microsoft does not allow third-party IDEs to access the official VS Code
Marketplace ...
My wild guess is it means MS doesn't want third parties to build their own VS Code based IDEs (like this one)?
"Visual Studio Code is designed to fracture" - https://ghuntley.com/fracture/
This Microsoft "DevDiv" (see the link) sounds like the classic EEE dressed up as "open", "hip" and with all the right buzzwords.
> You may not provide the software to third parties as a hosted or managed service, where the service provides users with access to any substantial set of the features or functionality of the software.
> You may not move, change, disable, or circumvent the license key functionality in the software, and you may not remove or obscure any functionality in the software that is protected by the license key.
personally, i see the value of rstudio (and in extension positron) while learning in a course, but i struggle to find its place beyond data exploration.
despite the licensing stuff, if they can provide some based defaults (removing microsoft telemetry "sauce"), it can be an ergonomic way to bring math-sided team members to share the same development platform.