Daniel 🕹️

Honestly, I almost never use a dataviewer, in no IDE/tool. Testing in Positron is nice because you can easily select the test files you want to run, or even just a test inside a file, or all tests. Navigate to the test code on click etc. Debugging is less comfortable in Positron compared to RStudio.

I'm also using rmd, but not often. I mostly use R scripts, and knit a report of that R script if necessary.

But vim is complicated? I never got used to it. If you master vim, you probably master any IDE for R/python.

Thus, the smooth experience is coming to Positron first, and later (if at all?) to RStudio. And honestly, RStudio meanwhile looks like Win95 in comparison to VSCode / RStudio. And don't you want to be part of the cool kids, or an old grandpa using tools from the last century when you teach? 😁

Just start typing and you immediately see it. auto-completion / tooltips in editor and console, syntax-highlighting etc., something that doesn't work that smooth in VSCode. Meanwhile, new features from Positron (like highlighted warnings/errors in the console) are later integrated in RStudio.

(and if you do statistics/data science, Positron provides some tools that are very useful sometimes, like the data viewer, and unlike VSCode, the integration of tests for package development is great - there are lots of things in Positron that work out-of-the-box, unlike in R for VSCode)

R integration / console in VSCode is not even close to what Positron provides. So my take is instead of worst of both worlds (RStudio+VSCode), Positron combines best of both worlds ;-)
That said, which IDE are you using?

- modern look'n'feel
- fully customizable layout
- absolutely easy to handle GitHub integration
- code assist / LLM integration, if desired
- rather simple and intuitive UI
- hide/show relevant panes with a keystroke

What's not to like about it? 😎

Although the GitHub integration is a game changer, and one reason I switched from RStudio to vscode (and now to Positron). But you can safely uninstall all python extensions.

Post-hoc wizardry in #rstats! It's fascinating how many statistical challenges can be solved or research questions can be answered by some form of predictions, marginal means and effects, or comparisons and contrasts. Things you can easily do with packages like {modelbased} or {marginaleffects}!

I started with using LLMs for GitHub PR reviews, which works quite well. Co-pilot and Gemini integration. So far, Gemini is slightly better in this task, but both complement each other. But I've not used it for writing code, rather some kind of auto completion.

Modelbased for Quick and Beautiful Model Visualization in #rstats imachordata.com/2025/07/25/m... Thanks, @easystats.github.io!

You forgot to mention there's no @easystats.github.io for python, so it's a pretty useless language.

screenshot showing the row dataframe with a column of rvars and the markdown-formatted-table output of describe_posterior() + print_md()

bayestestR::describe_posterior() works on rvar columns

Default CI level back to 95%? 😱 · easystats bayestestR · Discussion #250 TLDR for new readers Currently, most of bayestestR's functions have ci=0.89 by default, yielding 89% CIs. We are thinking of changing that (maybe to 95%). To avoid any surprises or breaks when you ...

Join the discussion: github.com/easystats/ba...
😎

#rstats base ?`$`

I think you can also order online, not sure how it works with shipping outside Germany? And the website doesn't seem to have any translations, but it says that cars not registered in Germany costs 19.90 EUR instead 14.90:
www.tuev-nord.de/de/privatkun...

Beside the packages I'm (co-) developing, I most often use/load ggplot2, glmmTMB and brms. Important packages that are used by my packages are e.g. haven, gt or marginaleffects. That really covers 90% of my work, I think?

And for the distinction between conditional and marginal, see www.theoj.org/joss-papers/...

(I just checked previous drafts where I wrote down the methods section, and the package name was correct there)

After several years, I noticed that the first author of a co-authored article had corrected what he believed to be a ‘spelling mistake’ in the name of an R package.

See the slides 21-23 from "Introduction into predictions and the {modelbased} package", where I tried to write up my understanding/definition: easystats.github.io/easystats/ar...

best thing is source code in an additional supplemental word or PDF file, including truncated lines where the code no longer is executable. 🫣

haha, that's a good argument!

Yeah, but still, I sometimes find some old, published code which is hard to follow for me after a longer time. That's why I now say (and try to do that) that carefully writing *and commenting* scripts is important. Reviews 3-6 months after a paper was submitted, and you rarely remember your analysis

We often use data like PUF (ESS, Share, ...) where you are not allowed to publish the data again, but they are openly available to everyone. In this case, the data cleaning/preparation script is essential to recreate the data you used for analysis. That's why I usually publish those scripts, too

Yes, I often look up the code to understand what authors did, because the methods section is too short due to limited word count

Agree, I also consider this as a "quality indicator", when I'm demonstrating that I have nothing to hide and everyone can understand and reproduce results.

Yeah, it's good to have one place where you only have the *final* files and data located, because the next review is coming for sure, and you may need to do some re-analysis... skimming all files you saved during data-analysis can take hours to find the right script/code. ;-)

I don't think you need an extension for projects in positron, use use "add folder to workspace" or "save workspace as...", and then you can easily open/switch between workspaces ("projects") with the button in the top right, or the files menu.