5 ms·
You can always use tools like Regex101[0] to verify if they actually work or not. I have tried a few generated by the AI, and it seems to do the job most of the
by memorable 4y ago
You can always use tools like Regex101[0] to verify if they actually work or not. I have tried a few generated by the AI, and it seems to do the job most of the time.
[0]: https://regex101.com/ https://regex101.com/
- croes 4y agoYou still could have edge cases you don't want or want
- chii 4y agoif you have an edge case you know you want, you could add the description into the input of the AI. If you are afraid of unintended matches, that's a different problem, which you might also get writing the regex yourself! The solution, i reckon, is to create (may be even via the same AI?) a large list of matches, and you manually look thru to see if there's unintended matches.
- nonameking2026 4y agoor just if clause it - why spend 1 hour chasing down regex to save yourself from writing 3 lines of code.
- eurasiantiger 4y agoBecause application performance matters more than developer performance.
- episteme 4y agoI thought Regex was typically less performant than string operations?
- eurasiantiger 4y agoDepends. If you need to go through a 100MB file, you want to do it once, not twice.
- Blackthorn 4y agoAssuming you're using a non-backtracking library, they should both be O(n).
- Banana699 4y agoDepends very heavily on the task and the string implementation involved, but my prior is that you should always bet on regex for anything more complex than "ForEach chr in str: doSomething(chr)". Modern regex implementations are their own language interpreters/compilers, they implement their own string data strutures, they compile your regex into specialized bytecode (different from the hosting language), they have tons of special cases checks for fast paths (e.g. capturing groups make regexes much much more complicated than they need to be, a regex without capturing has the option to run signficantly faster). A random search just found out this 2016 SO question[1] where a compiled regex was faster than string.contains (!). Regex is just insanely optimized. It reminds me of C++, ugly and badly/un designed, but it can go fast. [1] https://stackoverflow.com/questions/2962670/regex-ismatch-vs-string-contains https://stackoverflow.com/questions/2962670/regex-ismatch-vs...
- nonameking2026 4y agoThis varies a lot. Reading a 100mb file 10 times a day vs. 100 times a day is perfectly acceptable in many scenarios.
- eurasiantiger 4y agoTrue, but in a fast-changing world, someone with slow data integrations might be leaving money on the table.
- wowokay 4y agoThat's true, but I think it's important to take the encryption approach, I understand how it works vaguely and hope I don't get burned.