Biggest advantage I found when I evaluated it was the API was much more consistent and understandable than the pandas one. Which is probably a given, they’ve learned from watching 20 major versions of pandas get released. However, since it’s much rarer, copilot had trouble writing polars code. So I’m sticking with pandas and copilot for now. Interesting barrier to new libraries in general I hadn’t noticed until I tried this.
You're the first person I ever encounter that publicly states to prefer a library because of its copilot support.
Not making a judgement, just finding it interesting.
Anyway, for what is worth, Copilot learns fast in your repos, very fast.
I use an extremely custom stack made of TS-Plus a TypeScript fork that not even the author itself uses nor recommends and Copilot churns very good TS-Plus code.
So don't underestimate how good can copilot can get at the boilerplate stage once he's seen few examples.
Given examples, Copilot can generate code for extremely rare languages or data structures. For example, it worked fine when I was writing for an obscure scripting language found in a railway simulation game.
to further elaborate, Copilot automatically grabs most recent 20 files with same extension to get code examples. you dont have to do anything special to make this happen. it just improves quietly over time.
I think he means he uses an obscure programming language and co-pilot still gives him functioning code if he gives a few examples. Not sure if copilot is very context aware where you can feed it an entire code-base, but maybe you can point GPT to read the documentation
Copilot support is a chicken and egg problem. It needs to train on others code but if people don't write Polars code without Copilot then Copilot will not get better at writing Polars code.
This is really interesting to see these two posts. I can now imagine where AI tools actually inhibit innovation in many domains simply because they’re optimized for things that are already entrenched and new entrants won’t be in the training data. Further inhibiting adoption compared to existing things and thus further inhibiting enough growth to make it into model updates.
It is a healthy mindset to see this phenomenon as "interesting". I can get there when I dial up my mindfulness, but my default mode here is rather judgy; as in "please ppl! pick the better tool as evaluated over a 4+ hour timeframe (after you've got some muscle memory for the API) instead of a 15 minute evaluation".
Forgive me for ranting here, but have people forgotten how to bootstrap their own knowledge about a new library? Taking notes isn't hard. Making a personal cheat-sheet isn't hard. I say all this AND I use LLMs very frequently to help with technical work. But I'm mindful about the tradeoffs. I will not let the tool steer me down a path that isn't suitable.
I'm actually hopeful: there is an unexpected competitive advantage to people who are willing to embrace a little discomfort and take advantage of one's neuroplasticity.
> I can now imagine where AI tools actually inhibit innovation [...] new entrants won’t be in the training data
I still imagine the opposite impact... Welcome to no-moats-lang.io! So, you've created yet another new programming language over the holidays? You have a sandbox and LSP server up, and are wondering what to do next? Our open-source LLMs are easily tuned for your wonderful language! They will help you rapidly create excellent documentation, translators from related popular languages, do bulk translation of "batteries" so your soon-to-be-hordes of users can be quickly productive, and create both server and on-prem ChatOverflowPilotBots! Instant support for new language versions, and automatic code update! "LLM's are dynamite for barriers to entry!" - Some LLM Somewhere Probably.
Once upon a time, a tar file with a compiler was MVP for a language. But with little hope of broad adoption. And year by year, user minimum expectations have grown dauntingly - towards extensive infrastructure, docs, code, community. Now even FAMG struggle to support "Help me do common-thing in current-version?". Looking ahead, not only do LLMs seemingly help drop the cost of those current expectations to something a tiny team might manage, but also help drop some of the historical barriers to rapid broad adoption - "Waiting for the datascience and webdev books? ... Week after next."
We might finally be escaping decades of language evolution ecosystem dysfunction... just as programming might be moving on from them? :/
Because it’s like willfully choosing the more painful and difficult tool that occasionally stabs you in the hand, because you’re now used to being stabbed in the hand.
Continuing to choose it in the face of - in their own words - a better option, is a bit mind-boggling to me.
You recognize the API is more consistent and understandable, but you want to stay with Pandas only because Copilot makes it easier? Please, (a) for your own sake and (b) for the sake of open source innovation, use the tool that you admit is better.
About me: I've used and disliked the Pandas API for a long time. I'm very proactive about continual improvement in my learning, tooling, mindset, and skills.
> Please, (a) for your own sake and (b) for the sake of open source innovation, use the tool that you admit is better.
This is...such a strange take. To follow your logic to an extreme, everyone should use a very small handful of languages that are the "best" in their domain with ne'er a care for their personal comfort or preference.
> for your own sake
They're sticking with Pandas exactly for their own sake since they like being able to use Copilot.
> for the sake of open source innovation
Ohh by all means let's all be constantly relearning and rehashing just to follow the latest and greatest in open source innovation this week.
Tools are designed to be _used_ and if you like using a tool _and_ it does the job you require of it that seems just fine to me; especially if you're also taking the time to evaluate what else is out there occasionally.
Is it really that strange of a take? To use the best tool available for a job. That doesn't sound strange at all.
Doubly so if it involves copilot. There's no way to get training data without people writing it. This sound like a direct application of a greedy algorithm: trading long term success for short term gain. That's not the ideal way to live.
Yes, the greedy algorithm metaphor is an interesting connection!
I also like thinking about this as a feedback loop (as explained by systems dynamics), since it provides nice concepts for how systems change over time.
(a) For one's own sake, please pick the better tool as evaluated over suitable timeframe (perhaps an hour or two, after you've got some familiarity and muscle memory for the API) instead of only a brief evaluation (e.g. only 15 minutes).
(b) Better open source tools (defined however you want), which benefit us all, get better uptake when people think beyond merely the short-term.
The essence of my argument is "think beyond the short-term". Hardly controversial.
Don't miss the context: LLMs are giving people even more excuses for short-term thinking. Humans are terribly tempted for short-sighted "victories".
The Polars lib changes rapidly. I am not using Copilot but achieved very good results with ChatGpt if you set system instructions to let it know that eg with_column was replaced with with_columns etc. and add the updated doc information to the system instructions.
