If you think that these complaints are not valid or stem from a lack of experience, I urge you to use R first.
(I’ve heard tell that R is worse, but I wouldn’t have any opinion on that since I’ve never used the language.)
So it stands to reason there must be a common explanation whey they are all so obtuse, which I would venture is something like: they solve a set of problems so broad and complex that the tools themselves must also be massively broad and complex, and so the only way to avoid API inconsistencies is to have the system designed whole-cloth from the very beginning, but doing so would make the development process so huge that it would take a decade before you had something ready for users and so it would never get off the ground. The tools that succeed in reality are the ones that solve a common subset of problems, and then grow organically as they are extended to solve other subsets, and the varying subsets have logical inconsistencies and conflicts, thus the state of tools available today having APIs with inconsistencies and conflicts.
That said, pandas is really good at solving problems with tabular data, and even though it's not easy to do complex work with I still like and appreciate it very much.
The alternative really is to write simple imperative style scripts with for loops in your favorite scripting language. Script will be much longer and likely more prone to errors, but the learning curve for simple tasks is just a lot less steep.
Eventually learning the array oriented approach is worth it though. It's the usual trade off in how much time is it worth learning a new tool vs kludging some old tool that doesn't quite fit for the task.
Take this with a grain of salt from someone who needs data manipulation occasionally every now and then (as opposed to being a full time number-cruncher, data-scientist, statistician etc.), using krangl[1] for Kotlin has been a great experience.
I was drawn to this library because I use Kotlin in my dayjob for backend development, but I love how well Kotlin's succinct syntax & features like extension functions lends itself to data transformation & ETL kind of use cases.
Also it doesn't hurt that JVM has a plethora of libraries available for things like DB access, plotting, etc.
I am sure that Pandas has many features I am unaware of, and for a lot of people the high-ish startup time can be a deterrant, but for most of my day to day data munging the combination of jbang, krangl & kravis has been a pretty good fit.
Lots of GUI based alternatives for data munging such as: Easy Data Transform, Alteryx, Knime. Whether they are better than text based tools, such as R or Python+Pandas, depends a lot on your use case and experience.
Data Science happened to python largely against its will (ie., that of GvR) -- and language-level support simply doesn't exist.
It can be both, but it doesn’t have to.
Python is an imperative, object-oriented language largely concerned with side-effecting programs (web severs, os automation, etc.).
It is about as hostile as it is possible to be, from "ideas" pov, to data science.
However those ideas are just a syntax skin over something much more flexible: pointers and dictionaries (/hashmaps). These are like the "Python VM Language" on which "Data Science" sits.
Data Science libraries essentially use the "actual" semantics of python and ignore the "official" syntax, as that's the only way of providing an API that makes any sense. (Ie., isnt just reams of for-loops with 5 sequential obj.method() calls).
I don't believe there is a "non-confusing" way of ignore python's syntax, *within python*; and that's just what is required.
object = state
object API = state change
encapsulation = internal control of state change
Your second and third statements are simply false.
Also, lacking skills in first order logic casts doubt on any kind of "understanding".
But please, do not assume I haven't read your arguments.
`object = state` is not a paraphrasing of first order logic; it is a paraphrasing of the english sentence,
"The intention motivating OOP is that the object represents state; the object's API represents changes to its state; an encapsulation ensures those changes are privately managed."
which if you understood any of the context to this discussion, you would have captured -- see, eg., the other commenter who captured this accurately.
I have taught hundreds of hours on programming language theory, and it is what I am doing today; and it is something I have been doing for a decade (not least, programming for two decades).
I take this tone with you because assuming a person cannot /reason/ basically is an extraordinarily arrogant view which presumes you have precisely captured the context of their statements.
In cases of apparent "basic failures to reason appropriately" it is almost always the observer, not the speaker, who has failed to arrive at the correct "propositional model" of their spoken/written language.
You would do well to remember this, and include more humility in your communications.
First of all, it does not matter what the initial intention was when OOP started growing to where it is now. The whole historical argument makes no sense whatsoever. The fact that something was like X in the past does not mean it is going to be like X in the future.
Second, I have a lot of doubt about the statement, that the idea of object API was solely to represent changes to object state. Unless you can link a supporting quote, I am ready to dismiss it as made up.
[1] I have never failed to find an answer for Pandas on SO for even the most convoluted manipulations I'm attempting. The first hit I look at usually has my answer.
It is certainly interesting though, how there are so many people firmly in opposite camps.
I really cannot imagine how pandas could be considered well put together; I'm always searching stackoverflow for data transformations I assume should be common and simple.
In dplyr, on the other hand, each function does one and only one thing (the touted Unix principle) and you just pass the data along via the pipe %>% operator