> If a company is worth its salt, it will offer services on top of existing public knowledge, without creating walled gardens.

I contend that every profitable company leveraging public knowledge does offer services (broadly construed) on top of that knowledge, since otherwise no one would pay them. Maybe the minimal example is that in which the only service provided is marketing, but the range of service levels provided in practice runs the gamut. RStudio clearly goes well beyond that minimum.

In some cases, the services offered are so valuable that the company can create a walled garden - which reduces the net value of those services to the customer but provides the company with monopolistic pricing power. (It’s not clear to me that RStudio’s products have significant lock-in, for what it’s worth. R has significant lock-in, like any programming language, and RStudio benefits from the lack of competitors creating good R tooling, but that’s not really a walled garden of RStudio’s making.)

Academics might have their own grand plans for society, but funding agencies generally want industry to take over at some point and run with it. I expect they'd be happy to move on and fund something new rather than trying to compete with products that industry can provide.

Personally I think RStudio is far less clunky than, say Jupyter. I still think Matlab is by far the best tool for engineering. I think having a company supporting the technology like that has generally been very beneficial. It's certainly possible they would just cause it to stagnate and milk it for cash as the technology dies out, but their business would die with it. Hence these examples have never stopped advancing.

You can't steal the ideas from academia or commercial. You can implement the same idea, but the previous one still exists.

A company commercializing an idea from academia does not make that idea proprietary.

>because from proprietarizing ideas, there is no benefit for society.

Except for a profit motive for companies which then benefits society by lowering prices of products. If it weren't for private companies no one of us could afford a computer today.

OpenStack was definitely unnecessarily complex. And it led to many different distributions that were only manageable by hiring a lot of consulting manhours.

> The other way around it is not OK, because from proprietarizing ideas, there is no benefit for society

You say this as if proprietary rules (ie. copyright and patents) weren't intentionally designed to incentivize knowledge creation & sharing by ensuring compensation for innovation. Creators can't pay bills with societal advancements and research progress. This is a really shallow "proprietary = bad" ideological take that I expect to see on the black & white pages of Stallman's website, not an (at least partly) entrepreneurial forum.

It's great that RStudio is a B-corp, but that, by itself, isi a magic bullet.

Is there any information you can share on what steps RStudio has taken to reduce susceptibility to buyout and IPO pressure from VC?

Scientific programming is just different. Much of the culture of scientific programming is different and with good reasons not easy to understand.

Its something like how baking cookies at home and running a cookie factory are very different. To a person doing each, the behaviors and priorities of the other seem strange and it’s easy to for one to think “we are both just making cookies, why don’t they do what i do which is obviously superior “

Scientific programmers are solving problems first, not writing programs. They are solving problems in a way that is useful only to them or peers who know a whole lot about the problem being solved. The problem-first tools look strange because they deemphasize the programming niceness in favor of problem niceness.

You find the same sort of confusion when programmers are facing business types and excel usage.

There are certainly times when a piece of code starts needing the programming touch, but the right tool for the job depends on the job.

My description of R: It makes hard things easy and easy things hard. Ergonomically it is the absolute worst "programming language" I've touched in my life. However somehow it managed to become the official language of statistics research and has packages to do any type of analysis you can dream of.

I think the reason you and I dislike R is because we just work differently than non-programmers. Non programmers think in purely imperative, straight-forward semantics. They write one-off unmaintainable code tying together libraries that solves their immediate problem. Programmers try and write R code as if it was a proper programming language and immediately run into walls. Non-programmers never see the walls because they don't even know there's another way.

I was a mathematics major in college, and didn't have much training in programming when I graduated. R was the first language I learned when I started my career as an actuary, and it was a breeze. Things “just work”. Want to add 2 vectors of different dimensions together? R knows what you’re getting at, and makes it work. Comparatively, learning Python was harder.

Now that I’m used to both languages, I find it funny how much R is hated by “true” programmers.

Have you spent time with the community? The community is fantastic.

Also, the cheat sheets put out by the RStudio team are the best programming language cheat sheets I've seen for any language: https://www.rstudio.com/resources/cheatsheets/

I don't do R much anymore (at the end of the day I personally have the freedom to start fresh so I choose that over dealing with technical debt in the R language itself), but the R Studio product, team, and R community I found fantastic.

R got a simplicity boost with the "tidyverse", R studio and ggplot, all driven by Hadley Wickham. at its core, R is a very straightforward language. however it never had a benevolent dictator who gave it consistency, elegance and style. Hadley is compensating that a bit.

I am primarily a python programmer, but I sometimes use R.

You are either going to use a programming language (or library, etc.) made by a programmer pretending they know about statistics, or a statistician pretending they know about programming. Oftentimes, as a programmer, the right choice is the former, but not uncommonly (because statistics is even less intuitive than programming), you really really need to know that the statistics have been done right. If someone has ported the relevant code from R to python, great. If not, bit the bullet and use R, it's where the statisticians hang out.

You know, I bet statisticians don't think any more kindly of how programmers make stuff. Our use of the '=' sign, for example. We're just used to that kind of thing, so it doesn't look like a problem to us.

R programming is fundamentally different at a conceptual level. You are operating on datasets rather than individual values. Also the GUI mechanism use reactive programming if you are using R Shiny. R is awesome for what it is designed for.

Other than using apply functions instead of loops, coding R is a lot like coding python only you get a lot more of the data science python package functionality already baked into base R. The syntax differences are slight enough where it's pretty easy to move between the two (or find relevant stackoverflow answers instantly to common annoyances). R generally inputs your data and outputs your statistical test results in less code with less headscratching than doing the same in python in my experience. I prefer plotting in R as well.

I've written some R both for small interactive scripts and running in production, it wasn't the first language I learned - R gets some things done very well; it also has some idiosyncracies, there is stuff that is clearly patched up together and exists for backwards compatibility, and there are many ways to do the same thing in R. If you don't expect it to be perfect, it gets the job done - nothing to write home about and certainly not a language that you should avoid at all costs.

There's a difference, in my mind, between "Programmers" and "Invokers of Code".

R is a terrible programming language.

It's not a bad language for invoking code, because for many of those people, they're not taught the concepts behind any language, so it's all semi-arbitrary symbols.

model <- lm(outcome ~ variable1 + variable2 + variable3, data=data)

summary(model)

Isn't any more complex than anything else. And what R does have is a network effect - at this point, for almost any statistical task I've ever encountered, there's R code for it.

They can use it because they don't come with preconceived notions of how programming normally works. And it let's them do powerful analysis without much boilerplate code along with a library of packages for an enormous range of analytical methods and visualization, all without having to do much in the way if boilerplate coding.

Sure the syntax is going to seem alien to them, but so would any first encounter with a programming language.

The use case for R simply isn't a traditional programmer. That isn't the target user. Sure if you need an application that might need significant scale you're not going to use R Shiny, but a lot of R work are one-off bespoke analysis projects. Models that do need to be deployed for use at scale in an application take their output parameters from R models and simply implement them in the app. I do this myself, taking coefficients etc, implement a function call in a database and then use the results on the front end.

I'm a professional programmer and I don't find R hard to understand. Have a look at R for Data Science[0], maybe you'll see why scientists and statisticians find it easy for their analysis and visualizations (and conversely find Pandas+Python very complex).

[0] https://r4ds.had.co.nz

That's are my thoughts, mostly, but in the end libraries are the killer feature of successful programming languages. I have got used to it and I'm more proficient now at data analysis tasks using R than Python/pandas thanks to tidyverse+ggplot.

The object system mess though... I have no words.

it seems to me that the value is in hard-compressed optimized functions and to this crowd this is the most important factor

software engineering practices don't exist unless you have a gigantic program, programming language theory is either not interesting or too foreign for them

about how they manage.. it's easy, they get used to it

Machine learning is ripe with similar examples (tensorflow in primis).

R was the supposedly the "FOSS" replacement for SAS, and Matlab to a degree. I had to support it and bioconductor.

Now, most people just use Python.

It's selling point is it's not matlab. It's downfall is it's not python. The python scientific compute libraries have they're problems but people are using them and math people "get them". I think they have an awful design/api from a programming perspective but most people don't care. Matlab is similarly a strange language but all of it's libraries/tools make what scientists do easy. "Click a button and your code can now run on a compute cluster".

R is very popular with stats people but new PhD candidates are beginning to write python implementations of R things (sort of how like DataFrames/pandas happened).

you know..."it depends" if a famous (non) answer among (good) software architecture

has mochizuki’s proof been formally recognized? i thought it wasn’t yet agreed upon

I agree with your assessment of the claims made in this post, but I want to note that for me the tidyverse culture became the reason to abandon R for all use cases where it has decent alternatives. R is not pretty, but it is also not super hard, and it has some internal logic. tidyverse's logic is orthogonal to that of R, it is a different data-manipulation paradigm, which I know have to know in addition to having to know R itself---not that you can really skip this part. Also, as it has been already mentioned here, this layering doesn't help with debugging.

ggplot2 did a similar thing with plotting. Together these two projects made R more accessible-like and, IMO, seriously damaged the culture around it.

It's interesting, though, that those "clean" interfaces come with the horrors of non-standard evaluation and have caused a rather large divide between the tidyverse and base R.

I fully disagree with the disparaging aspersions or even motives that TFA leans towards, though. I can see how this would arise out of a local minimum.

The "beauty" of R has always been its core DataFrame abstraction and the fact that a table is a language primitive — and that's where 90% of the consistency came from (from my outsiders' vantage point).

    d <- data.frame(a = 1:3, b = 1:3)
    d[4,] <- 1:3
    # or
    d$c <- NULL
    # or
    d[c(T,F,T,F), 1] <- 1

Just to add an anecdatum, as a python programming who has started using R in production, I find dplyr to be less clear than base R. Not that either one is clear.

"Never ascribe to conspiracy, that which is adequately explained by incompetence."

Not that complexity means the programmer was "incompetent", per se, but not sufficiently competent to keep things simple, because as you point out, keeping things simple is really hard.

I missed your article when it first came out, and I'm glad to have encountered it here; thank you, I think it helps explain some things here and more generally. I do think that this explains why the "Base R" people feel so threatened by the Tidyverse.

What I find interesting about the quoted excerpt, and the article most broadly, is about how it spends very little time discussing what RStudio's economic interest in propagating the Tidyverse actually is. Because, notably, RStudio doesn't charge for the Tidyverse packages. There's no Tidyverse Enterprise Edition, there's no Tidyverse support plans. They mostly make money off their IDE and server products, and those products don't have a lot of meaningful synergies with the Tidyverse packages; there's few IDE features that integrate directly with the Tidyverse, and those that exist aren't very significant. Meanwhile, nothing about the Tidyverse is written to work better with RStudio than with VS Code using the R language server, or with Emacs, or what have you.

This isn't to say that RStudio is doing this for any reason other than economic interest, but the economic interest here is not in convincing R users to use Tidyverse packages; RStudio makes the same amount of money if you do your plots in ggplot or not, and if you switch to ggplot there's nothing about it pushing you to change your IDE/editor.

So what is the business model for the Tidyverse, then? It's pretty straightforward: the goal of the Tidyverse from the perspective of RStudio is to drive R adoption, mostly at places who are using commercial closed-source alternatives to R, like Matlab, or SAS or SPSS. (You could argue that they're competing for mindshare with Python, too, but RStudio has moved to treating Python the way that post-Azure Microsoft treats Linux, as a part of its product portfolio. RStudio's flagship products, the IDE and the Connect server, both advertise first-class Python support. Whether or not they have achieved this is another question, but they certainly are trying.) Once you have converted people to using R, you can sell them IDEs and servers.

I suspect that the "Base R" people have a hard time grappling with this aspect of the Tidyverse business model, because it implies that Base R is _inherently less popular_ than the Tidyverse, which makes their losing less about the whims of a corporation that they can argue is acting in bad faith, but about the preferences of the R community, which they have no power to gatekeep.

Because the point of the Tidyverse is driving adoption among people who were not previously R users, the Tidyverse is able to win over the majority of the community not by persuading holdouts but simply by growing the community with new Tidyverse supporters. I understand how that can feel threatening to someone who was an R user pre-Tidyverse, but you understand why they don't want to focus their message around shrinking the R community. And their efforts to persuade these new people to switch from the Tidyverse to Base R is undermined by the fact that the best argument for Base R over Tidyverse, the familiarity of Base R to someone who learned Base R to begin with, doesn't apply to them at all. They're fighting a losing war with bad weapons.

I agree with Matloff's overall point, though. "Tidy programming" (which came to mean non-standard evaluation) is very hard to understand, even for R professionals. It relies on directly handling symbols, and encourages using new notations to do it. Debugging is even more complex with NST code, and people learning the language will be doing a lot of debugging. I can't imagine a good way to introduce functions to newer users when using NST. You'd have to first mention environments, scoping, and symbols.

My rant aside, I did find this next quote from Matloff a better argument for using dplyr:

    > mean(Nile[80:100])

"printing the mean Nile River flow during a certain range of years. Incredibly, not only would this NOT be in a first lesson with Tidy, the students in a Tidy course may actually never learn how to do this. Typical Tidiers don't consider vectors very important for learners, let alone vector subscipts."

With dplyr, you'd subset based on a `filter()`, likely specifying the years to keep. It encourages self-explanatory code. Matloff's vector subscript tells me nothing about why certain elements are kept.