> many statistics packages provide only weak text editor functionality
RStudio IDE with vim keybindings gives an extremely nice developer experience when working with R. There are only a few minor imperfections [1, 2, 3]. I'd still rate it a 9.5/10 dev experience.
I've recently been experimenting with R + neovim + vim-slime. It's not perfect but also a very nice experience. It enables interactive use of R but with the full power of neovim.
[1] control + 1 and control + 2 to switch between editor and console (pressing them in a hurry requires finger gymnastics)
[2] while vim keybindings work in the script pane, they don't work in the console
[3] about once per day for reasons I can't explain, RStudio's vim keybindings don't do what they should do (e.g. a key press is ignored)
A great package that I use on a daily basis. I feel the dev team have some issues with scope of work and tech debt, but I still find ESS to the comfy-zone for R
My colleagues and I have been discussing recently if we should use Positron IDE as a common environment for teaching R and Python. Emacs is another option, of course.
I'm in an MBA program and in my data science course (aimed at non programmers obviously) the prof used R and Rstudio.
At first I thought it was a bad choice, and I did all my assignments with Emacs/ESS. I preferred it, as I do almost all my coding in emacs and of course it's easy to define custom shortcuts to insert the un-ergonomic R operators like the magrittr pipe. But I came to realize that the way Rstudio is self-contained, and oriented around "sessions", or notebook-style code, makes it easier for neophytes to pick up.
I can't imagine how difficult it would be to teach a bunch of non programmers how to deal with python given the insane situation with venvs, pip vs homebrew, and 2 vs 3, imports, etc. 80% of my cohort are the type of people who think using the terminal constitutes "hacking" in the CrashOverride sense.
Is this really still relevant? I've been using only python3 for well over a decade now and I can't remember the last time anyone even suggested I use python2. the rest of your critiques ring true though.
Maybe you're right and it's not, but Python is definitely a Rube Goldberg machine of tutorials, libraries, and people who will tell you with a straight face that it's reasonable and expected to have 3.10, 3.11, and 3.12 installed alongside each other because reasons.
I say this as someone who writes a fair amount of python and whose package manager decided to install 3.10, 3.11, and 3.12 as dependencies.
Anyway, try explaining that to a bunch of business school people who are accustomed to just doing everything in the latest version of Excel, whatever that happens to be.
Looking forward to searching for tutorials explaining the difference between Python .NET Core, Python ASP.NET Core, Python .NET for Business, and Excel .NET Core
> try explaining that to a bunch of business school people
Never mind them! I have been programming for decades and have been defeated twice by Python and its disrespect for semantic versioning
Those version 3s often introduce breaking changes.
I continue to be amazed and astounded that it is so popular. A poster child for "do not choose software based principally on popularity". Being unpopular is a handicap, but being popular - just look at Python. The Python ecosystem is a *nightmare*
For Python, we settled on using Jupyter notebooks for the first semester to teach the language itself, while gradually introducing all the paraphernalia.
This is of course introduces another problem of ‘two cultures’: Python people using Jupyter and the R community largely preferring Markdown.
The basics of Emacs are not that hard. One of my introductory freshman courses taught us XEmacs in parallel, as we went through Lex & Yacc.
Basically you need to learn a few basic movements, which are also really useful on any terminal thanks to GNU Readline, and a some basic concepts like the minibuffer, interactive commands, etc. From there onward, things are quite easy to discover little by little, especially with newer packages like vertico, marginalia or which-key.
Obviously, its much harder than VSCode, but investing on Emacs is IMHO worth the effort if one values stability. It will be probably still relevant when most competing solutions are gone. Plus, it offers great support for lots of niche languages and workflows, like Org.
> Basically you need to learn a few basic movements, which are also really useful on any terminal thanks to GNU Readline
This is one of the biggest reasons why I’m slowly switching to Emacs for most of my editing needs. Those movement keyboard shortcuts are ubiquitous on UNIX family operating systems. They even work in most native text editing fields in macOS and iOS.
> They even work in most native text editing fields in macOS and iOS.
Some of them work, e.g. C-a/C-e, which is nice. However, after hearing about that "Readline keybindings work everywhere in MacOS", I was quite disappointed when I finally bought a Mac and the more useful Emacs/Readline bindings like M-f/M-b/M-d were all missing. I'm still happy with my Mac overall, but I wish they went further in this regard.
There are conflicting systems in macOS at play here as a result of choosing the "Option" key as your "Meta" key. The basics of the Cocoa Emacs Keybindings (DefaultKeyBinding.dict) do allow for M-f/M-b/M-d to work as us Emacs users expect, however there is a conflict with the default US Keyboard Layout, which hijack these useful Option key sequences to allow for the easy input of letters with various diacritic markings. If you want to undo this, you can use a Keyboard Layout Editor like Ukelele[0] to make a custom layout that allows these key sequences to arrive unmolested at the Cocoa input system.
This semester is my first using Posit Cloud. It removes the headache whether you're teaching R or Python. The only thing I've found annoying is the need for students to install their own packages.
I ran my own RStudio Server on Digital Ocean for years. That worked very well, with students not needing to install packages, but maintaining things myself created more work for me.
Before that I had to deal with an unending string of support for the students using their own computers. I would never go back to that again.
I used Cocalc once during the pandemic. It has a great set of features, but the students found the interface confusing.
If you're teaching a cooking class, you're wasting valuable time teaching people how to fish. But that wasn't really my point. A lot of the wasted time was mine.
I think it depends on how new your students are to programming. If they are already coding and have their favorite IDE then it would be nice to force them to try something new to see a different workflow (even if they end up going back to vscode later).
On the other hand for newer programmers you want to focus less on the tools, installation and workflow and more on just getting them programming. In that situation the batteries included environments like RStudio would be preferred.
Another practical thing to think about is how much you and your TAs want to wrestle with installation issues vs just giving them a web based notebook environment like Colab.
Personally I enjoy ess in Emacs because it is easy to search and mix code from multiple locations/buffers in addition to having separate sessions, and I love the interactive mixing of shell, python and R in one place, the ease to include code snippets into documents, and so on. I imagine the excellent documentation and visualization options exist in R studio but its hard to replicate the full Emacs experience.
> many statistics packages provide only weak text editor functionality
RStudio IDE with vim keybindings gives an extremely nice developer experience when working with R. There are only a few minor imperfections [1, 2, 3]. I'd still rate it a 9.5/10 dev experience.
I've recently been experimenting with R + neovim + vim-slime. It's not perfect but also a very nice experience. It enables interactive use of R but with the full power of neovim.
[1] control + 1 and control + 2 to switch between editor and console (pressing them in a hurry requires finger gymnastics)
[2] while vim keybindings work in the script pane, they don't work in the console
[3] about once per day for reasons I can't explain, RStudio's vim keybindings don't do what they should do (e.g. a key press is ignored)
A great package that I use on a daily basis. I feel the dev team have some issues with scope of work and tech debt, but I still find ESS to the comfy-zone for R
The only feature I miss in ESS is the ability to save plots using a GUI. Saving plots from the CLI can be a little cumbersome.
My colleagues and I have been discussing recently if we should use Positron IDE as a common environment for teaching R and Python. Emacs is another option, of course.
I'm in an MBA program and in my data science course (aimed at non programmers obviously) the prof used R and Rstudio.
At first I thought it was a bad choice, and I did all my assignments with Emacs/ESS. I preferred it, as I do almost all my coding in emacs and of course it's easy to define custom shortcuts to insert the un-ergonomic R operators like the magrittr pipe. But I came to realize that the way Rstudio is self-contained, and oriented around "sessions", or notebook-style code, makes it easier for neophytes to pick up.
I can't imagine how difficult it would be to teach a bunch of non programmers how to deal with python given the insane situation with venvs, pip vs homebrew, and 2 vs 3, imports, etc. 80% of my cohort are the type of people who think using the terminal constitutes "hacking" in the CrashOverride sense.
> 2 vs 3
Is this really still relevant? I've been using only python3 for well over a decade now and I can't remember the last time anyone even suggested I use python2. the rest of your critiques ring true though.
Maybe you're right and it's not, but Python is definitely a Rube Goldberg machine of tutorials, libraries, and people who will tell you with a straight face that it's reasonable and expected to have 3.10, 3.11, and 3.12 installed alongside each other because reasons.
I say this as someone who writes a fair amount of python and whose package manager decided to install 3.10, 3.11, and 3.12 as dependencies.
Anyway, try explaining that to a bunch of business school people who are accustomed to just doing everything in the latest version of Excel, whatever that happens to be.
They will soon have a convenient starting point: https://support.microsoft.com/en-gb/office/introduction-to-p...
Oh good grief.
Looking forward to searching for tutorials explaining the difference between Python .NET Core, Python ASP.NET Core, Python .NET for Business, and Excel .NET Core
...OMG. Getting worse
> try explaining that to a bunch of business school people
Never mind them! I have been programming for decades and have been defeated twice by Python and its disrespect for semantic versioning
Those version 3s often introduce breaking changes.
I continue to be amazed and astounded that it is so popular. A poster child for "do not choose software based principally on popularity". Being unpopular is a handicap, but being popular - just look at Python. The Python ecosystem is a *nightmare*
For Python, we settled on using Jupyter notebooks for the first semester to teach the language itself, while gradually introducing all the paraphernalia.
This is of course introduces another problem of ‘two cultures’: Python people using Jupyter and the R community largely preferring Markdown.
I love Emacs, but I think it would be challenging to teach an intro programming course using it these days. (We landed on VSCode for teaching Python.)
The basics of Emacs are not that hard. One of my introductory freshman courses taught us XEmacs in parallel, as we went through Lex & Yacc.
Basically you need to learn a few basic movements, which are also really useful on any terminal thanks to GNU Readline, and a some basic concepts like the minibuffer, interactive commands, etc. From there onward, things are quite easy to discover little by little, especially with newer packages like vertico, marginalia or which-key.
Obviously, its much harder than VSCode, but investing on Emacs is IMHO worth the effort if one values stability. It will be probably still relevant when most competing solutions are gone. Plus, it offers great support for lots of niche languages and workflows, like Org.
> Basically you need to learn a few basic movements, which are also really useful on any terminal thanks to GNU Readline
This is one of the biggest reasons why I’m slowly switching to Emacs for most of my editing needs. Those movement keyboard shortcuts are ubiquitous on UNIX family operating systems. They even work in most native text editing fields in macOS and iOS.
I agree, having a subset of Emacs/Readline keybindings available everywhere on macOS is really convenient and made Emacs quite natural to use for me.
GNOME used to have an Emacs GTK key theme, but it is no longer available as of GTK 4.0?
> They even work in most native text editing fields in macOS and iOS.
Some of them work, e.g. C-a/C-e, which is nice. However, after hearing about that "Readline keybindings work everywhere in MacOS", I was quite disappointed when I finally bought a Mac and the more useful Emacs/Readline bindings like M-f/M-b/M-d were all missing. I'm still happy with my Mac overall, but I wish they went further in this regard.
There are conflicting systems in macOS at play here as a result of choosing the "Option" key as your "Meta" key. The basics of the Cocoa Emacs Keybindings (DefaultKeyBinding.dict) do allow for M-f/M-b/M-d to work as us Emacs users expect, however there is a conflict with the default US Keyboard Layout, which hijack these useful Option key sequences to allow for the easy input of letters with various diacritic markings. If you want to undo this, you can use a Keyboard Layout Editor like Ukelele[0] to make a custom layout that allows these key sequences to arrive unmolested at the Cocoa input system.
[0]: https://software.sil.org/ukelele/
Lol. Geez, we gotta do something about key sequences getting 'molested'...
I think that’s because the Meta key is the Option key on Macs which conflicts with some traditional keyboard shortcuts for other things in the OS.
For M-b and M-f, the equivalents are M-<left> and M-<right>
This semester is my first using Posit Cloud. It removes the headache whether you're teaching R or Python. The only thing I've found annoying is the need for students to install their own packages.
I ran my own RStudio Server on Digital Ocean for years. That worked very well, with students not needing to install packages, but maintaining things myself created more work for me.
Before that I had to deal with an unending string of support for the students using their own computers. I would never go back to that again.
I used Cocalc once during the pandemic. It has a great set of features, but the students found the interface confusing.
> support for the students using their own computers.
painful but thats how you teach people to fish instead of being consumers.
> thats how you teach people to fish
If you're teaching a cooking class, you're wasting valuable time teaching people how to fish. But that wasn't really my point. A lot of the wasted time was mine.
I think it depends on how new your students are to programming. If they are already coding and have their favorite IDE then it would be nice to force them to try something new to see a different workflow (even if they end up going back to vscode later).
On the other hand for newer programmers you want to focus less on the tools, installation and workflow and more on just getting them programming. In that situation the batteries included environments like RStudio would be preferred.
Another practical thing to think about is how much you and your TAs want to wrestle with installation issues vs just giving them a web based notebook environment like Colab.
positron is nice but still very much in alpha stages. may be better to wait for a year or so
VS Code + R extension is pretty good.
In what way is R less powerful when used through Rstudio than through the terminal?
Personally I enjoy ess in Emacs because it is easy to search and mix code from multiple locations/buffers in addition to having separate sessions, and I love the interactive mixing of shell, python and R in one place, the ease to include code snippets into documents, and so on. I imagine the excellent documentation and visualization options exist in R studio but its hard to replicate the full Emacs experience.
[dead]