← Back to context

Comment by aorist

4 days ago

> Examples include converting boxplots into violins or vice versa, turning a line plot into a heatmap, plotting a density estimate instead of a histogram, performing a computation on ranked data values instead of raw data values, and so on.

Most of this is not about Python, it’s about matplotlib. If you want the admittedly very thoughtful design of ggplot in Python, use plotnine

> I would consider the R code to be slightly easier to read (notice how many quotes and brackets the Python code needs)

This isn’t about Python, it’s about the tidyverse. The reason you can use this simpler syntax in R is because it’s non-standard-evaluation allows packages to extend the syntax in a way Python does not expose: http://adv-r.had.co.nz/Computing-on-the-language.html

"The reason you can use this simpler syntax in R is because it’s non-standard-evaluation ..."

So it actually is about Python vs R.

That said, while this kind of non-standard evaluation is nice when working interactively on the command line, I don't think it's that relevant when writing code for more elaborated analyses. In that context, I'd actually see this as a disadvantage of R because you suddenly have to jump through loops to make trivial things work with that non-standard evaluation.

  • The increasing prevalence of non-standard evaluation in R packages was one of the major reasons I switched from R to python for my work. The amount of ceremony and constant API changes just to have something as an argument in a function drove me mad.

    • > nd constant API changes

      Yeah, this was so very very painful. I once ended up maintaining a library that basically used all the different NSE approaches, which was not very much fun at all.

>> I would consider the R code to be slightly easier to read (notice how many quotes and brackets the Python code needs)

Oh god no, do people write R like that, pipes at the end? Elixir style pipe-operators at the beginning is the way.

And if you really wanted to "improve" readability by confusing arguments/functions/vars just to omit quotes, python can do that, you'll just need a wrapper object and getattr hacks to get from `my_magic_strings.foo` -> `'foo'`. As for the brackets.. ok that's a legitimate improvement, but again not language related, it's library API design for function sigs.

  • The right way is putting the pipe operator at the beginning of the expression.

      (-> (gather-some-data)
        (map 'Vector #'some-functor)
        (filter #'some-predicate)
        (reduce #'some-gatherer))
    

    Or for those who have an irrational fear of brackets:

      ->
        gather-some-data
        map 'Vector #'some-functor
        filter #'some-predicate
        reduce #'some-gatherer

  • IIRC, putting pipe operator `|>` at end of line prevents the expression from terminating early. Otherwise the newline would terminate it.

I wonder what the last example of "logistics without libraries" would look like in R. Based on my experience of having to do "low-level" R, it's gonna be a true horror show.

In R it's often that things for which there's a ready made libraries and recipes are easy, but when those don't exist, things become extremely hard. And the usual approach is that if something is not easy with a library recipe, it just is not done.

  • Python: easy things are easy, hard things are hard.

    R: easy things are hard, hard things are easy.

  • The way you describe it, can we say that R was AI-first without even knowing?

    • R is overtly and heavily inspired by Lisp which was a big deal in AI at one point. They knew what they were doing.

> This isn’t about Python, it’s about the tidyverse.

> it’s non-standard-evaluation allows packages to extend the syntax in a way Python does not expose

Well this is a fundamental difference between Python and R.

  • The point is that the ability to extend the syntax of R leads to chaos and mess (in general) but when used correctly and effectively in the tidyverse, improves the experience of writing and reading code.

Python is nothing without it’s batteries.

  • The design and success of e.g. Golang is pretty strong support for the idea that you can't and shouldn't separate a language from its broader ecosystem of tooling and packages.

  • I hear this so much from Python people -- almost like they are paid by the word to say it. Is it different from Perl, Ruby, Java, or C# (DotNet)? Not in my experience, except people from those communities don't repeat that phrase so much.

    The irony here: We are talking about data science. 98% of "data science" Python projects start by creating a virtual env and adding Pandas and NumPy which have numerous (really: squillions of) dependencies outside the foundation library.

    • Someone correct me if I'm completely wrong, but by default (i.e. precompiled wheels) numpy has 0 dependencies and pandas has 5, one of which is numpy. So not really "squillions" of dependencies.

      pandas==2.3.3

      ├── numpy [required: >=1.22.4, installed: 2.2.6]

      ├── python-dateutil [required: >=2.8.2, installed: 2.9.0.post0]

      │ └── six [required: >=1.5, installed: 1.17.0]

      ├── pytz [required: >=2020.1, installed: 2025.2]

      └── tzdata [required: >=2022.7, installed: 2025.2]

      4 replies →

R is more of a statistical software than a programming language. So, if you are a so-called "statistician," then R will feel familiar to you

  • No, R is a serious general purpose programming language that is great for building almost any type of complex scientific software with. Projects like Bioconductor are a good example.

    • Perhaps a in a context of comparison with Python?

      In my limited experience, Using R feels like to using JavaScript in the browser: it's a platform heavily focused on advanced, feature-rich objects (such as DataFrames and specialized plot objects). but you could also just build almost anything with it.