| ▲ | aorist 11 hours 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 |
|
| ▲ | jampekka an hour ago | parent | next [-] |
| 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. |
|
| ▲ | robot-wrangler 9 hours ago | parent | prev | next [-] |
| >> 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. |
| |
|
| ▲ | isolli 2 hours ago | parent | prev | next [-] |
| Or seaborn. It was built exactly for this purpose: abstracting some of the annoying kinks of matplotlib while still offering a rich set of features. https://seaborn.pydata.org/tutorial/introduction.html |
|
| ▲ | getnormality 7 hours ago | parent | prev | next [-] |
| It's not about Python, it's about how R lets you do something Python can't? |
|
| ▲ | npalli 11 hours ago | parent | prev | next [-] |
| Python is nothing without it’s batteries. |
| |
| ▲ | jskherman 11 hours ago | parent | next [-] | | Python is its batteries. | |
| ▲ | pphysch 10 hours ago | parent | prev | next [-] | | 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. | | |
| ▲ | LtWorf 10 hours ago | parent [-] | | The success of python is due to not needing a broader ecosystem for A LOT of things. They are of course now abandoning this idea. | | |
| ▲ | lmm 7 hours ago | parent [-] | | > The success of python is due to not needing a broader ecosystem for A LOT of things. I honestly think that was a coincidence. Perl and Ruby had other disadvantages, Python won despite having bad package management and a bloated standard library, not because of it. | | |
| ▲ | procaryote 2 hours ago | parent | next [-] | | The bloated standard library is the only reason I kept using python in spite of the packaging nightmare. I can do most things with no dependencies, or with one dependency I need over and over like matplotlib If python had been lean and needed packages to do anything useful, while still having a packaging nightmare, it would have been unusable | | |
| ▲ | lmm an hour ago | parent [-] | | Well, sure, but equally I think there would have been a lot more effort to fix the packaging nightmare if it had been more urgent. |
| |
| ▲ | LtWorf 16 minutes ago | parent | prev | next [-] | | The bloated standard library is the reason why you can send around a single .py file to others and they can execute it instantly. Most of the python users are not able nor aware of venv, uv, pip and all of that. | |
| ▲ | rjzzleep 3 hours ago | parent | prev [-] | | It's because Ruby captured the web market and Python everything else, and I get everything is more timeless than a single segment. |
|
|
| |
| ▲ | 1vuio0pswjnm7 10 hours ago | parent | prev | next [-] | | What language is used to write the batteries | | | |
| ▲ | throwaway2037 9 hours ago | parent | prev [-] | | 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. | | |
| ▲ | m55au 9 hours ago | parent [-] | | 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] | | |
| ▲ | noitpmeder 4 hours ago | parent [-] | | I don't know about _squillions_, but numpy definitely has _requirements_, even if they're not represented as such in the python graph. e.g. https://github.com/numpy/numpy/blob/main/.gitmodules (some source code requirements)
https://github.com/numpy/numpy/tree/main/requirements (mostly build/ci/... requirements)
...
| | |
| ▲ | m55au 3 hours ago | parent [-] | | They're not represented, because those are build-time dependencies. Most users when they do pip install numpy or equivalent, just get the precompiled binaries and none of those get installed. And even if you compile it yourself, you still don't need those for running numpy. |
|
|
|
|
|
| ▲ | dm319 9 hours ago | parent | prev | next [-] |
| > 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. |
|
| ▲ | evolighting 8 hours ago | parent | prev [-] |
| 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 |
| |
| ▲ | UniverseHacker 8 hours ago | parent [-] | | 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. | | |
| ▲ | evolighting 5 hours ago | parent [-] | | 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. |
|
|
