Hey! I worked on the plotnine guide (https://plotnine.org/guide/). Always interested to hear what people find hard to understand about plotnine, or what they wish there were more of (e.g. examples, guide pages, api reference docs).
(Both has2k1 and I work for Posit, which supports plotnine work, but authoring its guide was mostly an act of passion for me :)
I have used numpy, but don't understand what it has to do with dataframe apis
Take two examples of dataframe apis, dplyr and ibis. Both can run on a range of SQL backends because dataframe apis are very similar to SQL DML apis.
Moreover, the SQL translation for tools for pivot_longer in R are a good illustration of complex dynamics dataframe apis can support, that you'd use something like dbt to implement in your SQL models. duckdb allows dynamic column selection in unpivot. But in some SQL dialects this is impossible. dataframe apis -> SQL tools (or dbt) enable them in these dialects.
I think it's often a syntax convenience. For example, Polars and Pandas both have DataFrame.pipe(...) methods, that create the same effect. But it's a bit cumbersome to write.
I think piping and method chaining are a little bit different.
Piping generally chains functions, by passing the result of one call into the next (eg result is first argument to the next).
Method chaining, like in Python, can't do this via syntax. Methods live on an object. Pipes work on any function, not just an object's methods (which can only chain to other object methods, not any function whose eg first argument can take that object).
For example, if you access Polars.DataFrame.style it returns a great_tables.GT object. But in a piping world, we wouldn't have had to add a style property that just calls GT() on the data. With a pipe, people would just be able to pipe their DataFrame to GT().
It's neat to see tablets discussed in the context of modern tools. I recently helped edit an article for Great Tables[1] that discusses the history of tables like this, and recently Hannes mentioned a protocuniform tablet in his duckdb keynote at posit::conf()[2].
There's something really inspiring from realizing how far back tables go.
This is an interesting case, since the pigeon study is about what happens when the underlying process is random.
But if the shape drawing process isn't random, I think the author's experience of feeling unable to articulate the rules AND gravitating to a set of behaviors is a good example of procedural memory (implicit vs explicit).
Explicit rules would probably help speed things up, though!
As someone who did statistics and psychology, I'm very surprised by this take, for a few reasons:
1. Many of the early pioneers in statistics were psychologists.
2. The econ x psych connection is strong (eg econometrics and psychometrics share a lot in common and know of each other)
3. Many of the people I see with math chops trying to do psychology are bad at the philosophy side (eg what is a construct; how do constructs like intelligence get established)
From a more applied angle, a book like "10 steps to complex learning" might be helpful.
I come from a similar cog psych background as the Bjork Lab, so am a big fan of their research, but books like 10 steps come from instructional design, which is a bit more focused on the big picture (designing a whole course vs individual mechanisms).
Hey one of the co-maintainers of Great Tables, along with Rich Iannone, here!
I just wanted to say that Rich is the only software developer I know, who when asked to lay out the philosophy of his package, would give you 5,000 years of history on the display of tables. :)
I got into embroidery as a break from software engineering. Then, I got into machine embroidery and found myself running inkstitch in a docker container and submitting GitHub issues. Whoops!
Can't speak highly enough of the inkstitch maintainers, though--really welcoming community!
People questioning the headline are missing the point of the underlying article.
The underlying study is not about just rate of learning, but rate of learning under favorable conditions.
The article describes where the data comes from:
> In particular, we model learning using 27 datasets with over 1.3 million student performance observations from 6,946 learners in 12 different courses ranging across math, science, and language learning, across educational levels from late elementary to college, and across educational technologies including intelligent tutoring systems, educational games, and online courses
And the authors argue this is favorable learning conditions because of providing things like immediate feedback on errors, etc..
Lots of room for nuance, but "favorable learning conditions" is key here.
Having had the great pleasure of refactoring a few python libraries, I've had to encouraged people to switch away from inheritance.
You often get a ton of methods / attributes on the child class, which gets hard to keep tabs on. You have to be careful not to use the same names for things. (The worst is that someone uses this broken encapsulation and relies on things across parent classes via the child).
I get that inheritance can go okay for simple cases, but have seen enough chaotic uses of it that I'd just encourage people to write the boilerplate for forwarding methods.
(Both has2k1 and I work for Posit, which supports plotnine work, but authoring its guide was mostly an act of passion for me :)