> my experience has been (at least the community) is quite proudly dogmatic on the One Right Way To Do It, for all values of "It".

This hasn't been true lately. Python is growing ever more complex.

I hear you and agree to an extent; my suspicion is the influx of non-CS self-styled "data scientists" using Python for all the ML hype has diluted the historical rabidness.

But, for people still working in "computer science-y" domains, I haven't seen the historical dogmatism lessen; in many cases people are digging in.

R is an analysis tool. You don't write software in R.

Well, maybe _you_ don't write software in R. Others can write a pretty capable server[0] using just that.

[0] https://github.com/opencpu/opencpu/tree/master/R

Of course you can write anything in R but that doesn't mean it will be possible to maintain the codebase for the next 10 maybe 20 years including dev team changes.

In other words R is wrong tool to use for building the software just from maintainability standpoint.

I agree that in general one would not use R to engineer software. However I disagree regarding low maintainability.

I've seen very complex R packages that have been around for 30+ years. They are actively maintained. Applying good design principles, unit testing, modularity - all that is very much doable in R.

And you will want to write software in R, especially if the purpose is to support the very activity of working with R packages and to expose the R statistical environment over HTTP. Case in point, the software I link to, in my comment above.