Hacker News new | ask | show | jobs
by vain_cain 1593 days ago
I mostly work with data mining on my personal projects(which is a couple of hours every day), and I'm pretty sure I didn't have to write a single regex since I've started using Copilot. It's hard for me to even imagine how I used to do it before, and how much time I've wasted on stupid mistakes and typos. Now I just write a comment of what I want and an example string. It does the job without me having to modify anything 99% of the time, even for complex stuff. Sure, sometimes it gives an overly complicated solution but it almost always works. Exciting times.
3 comments

How do you know the regular expressions are correct, without understanding them?
I never said anything about not understanding them. If it's something simple, like getting a date from a string, a quick glance will tell me if it'll work. If it's more complex, a quick glance or two will give me the general idea and then I can test it against what I think will be edge cases. If you don't know what kind of a string you'll have to process then you can't really know if any regex is correct, and if you do testing it in most cases is pretty easy and quick. You'd have to test even if you write it yourself. And in the cases where it's wrong it usually gives me a good starting point.
All regular expressions are incorrect, but some are useful.
Who cares if they're correct? If they fail a test, you can fix them. If they turn out to be wrong in production you can isolate the example and add it as a test. Producing regexes that pass all current tests but contain a subtle bug satisfy 100% of what programmers are incentivized to do. Producing them very quickly will get you promoted.
I think we will very soon start seeing a clear separation between programmers ("co-pilot operators") and software engineers (those who do the thinking and understanding when there's someone "who cares").
We already have that bifurcation in the sense that the majority of programmers can use frameworks, libraries, etc. to get work done but don't have the deeper knowledge to build them well.
This separation has existed since the first computer was built.
I feel like you only see programmers as cogs, and not programmers as invested in the success of their product with the statement like "satisfy 100% of what programmers are incentivized to do"

Generally the people using regexes care if they're correct. Frequently, all possible input variants are not enumerated in tests. Frequently, companies want to have confidence in their production code. Imagine this regex is deployed on a sign up flow, and its failures invisibly increase your churn rate. Can it happen with a hand crafted regex? Yes, of course. But I'd imagine it will happen even more frequently with an AI produced custom regex plus a person who doesn't actually understand regexes.

Programmers often feel invested in the success of their product but that's not what they're incentivized to do. They're incentivized to produce fast results that are bad in ways that you have to be a programmer to understand.

If you have to be a programmer to understand why something's bad, who's going to prevent it? This is a major unsolved problem in the structure and organization of working.

The CTO who used to be a dev. More generally anyone in management with a technical background. They may not exist in some companies, but that's not because it's "a major unsolved problem in the structure and organization of working", it's because the company sucks in that regard.
Except testers and users aren’t programmers. Code reviews are what’s supposed to catch this stuff, but it’s rare for a team lead or other programmer to investigate every single commit.
You're not wrong, but hopefully someone is at least doing a code review.
Thanks for the good example. The first time I tried OpenAI's assistant (before I had access to GitHub CoPilot) I wrote a comment in Javascript code that read something like "perform SPARQL query to find out where Bill Gates works" and code was generated using an appropriate library, the SPARQL (like SQL) query was correct, and the code worked. Blew my mind.
would like to talk about the paintpoints you experienced while doing data preparation and mining
I have an e-mail in my description, you can ask me what you'd like to know there.