Hard disagree. The function regex serves in programs like Notepad++ can’t be easily replaced by “writing it out in code”. With a very small number of characters you can get complex search patterns and capturing groups. It’s hard to read but incredibly useful.
I fall in the abandon it camp. Code is read way more times than it is written. I’d rather read an algorithm that validates input than read a regex that validates input.
If you’re needing that level of complexity in a text file search, you already fucked up by putting the data in a text file. There’s a reason data file formats exist.
Not even close. Sometimes you can have a large text file where you need to do a find replace with a pattern. For example, in the translation world this can be a common occurrence for translation files (.xliff) or translation memories (.tmx).
There’s a reason why this is widely used and it’s not because everyone else but you is dumb.
I’m saying if your use case makes regex the best option, you’ve gone the wrong way and should turn back. There are definitely corners you can paint yourself into that make it the way to go, but you’ve ended up there through a series of bad ideas.
Maybe, just maybe, the context in which you use regex isn’t the same as everyone elses. But hey, who am I to deny you the disservice of thinking you’re the center of the world?
Why would I use SQL to to reformat a poorly structured log file for programs whose source I have no input in during a live debug with a customer on system that I don’t own and can’t install anything on? Or to extract and format things like hosts from a similar file?
That’s stuff that’s quickly and easily done in vim (which is generally part of the base install) with regex. There’s a lot of use cases that have no overlap with SQL.
Modifying software that might not be within the scope of the company that I work for, much less my team, on systems that I explicitly do not have authorization to make such changes on? No, I would not be doing that.
An important thing to remember is that going all-in on a given tool is going to result in a bad time. You suggestion of SQL, for example, excels in querying and modifying data that lives in a database and follows the expected structures in said database. Most data is not in databases, nor is it structured in a compatible manner, if at all. The workarounds needed to coax SQL into performing such tasks would result in syntax both more arcane and more verbose than the regex necessary to transform it into something compatible.
Use the right tool for the right job. For transforming semi-structured and unstructured data into something useful in a practical amount of time, regex is frequently the right tool.
I love regex and I use it a lot, but I very rarely use it in any kind of permanent solution. When I do, I make sure to keep it as minimal as possible, supplementing with higher level programming where possible. Backreferences and assertions are a cardinal sin and should never be used.
Never debug regex, just generate a new one. It’s not worth the hassle to figure out not only what it does, but what it was meant to do.
Better yet, just write it out in code, and never use regex. Tis a stupid thing that never should have been made.
Hard disagree. The function regex serves in programs like Notepad++ can’t be easily replaced by “writing it out in code”. With a very small number of characters you can get complex search patterns and capturing groups. It’s hard to read but incredibly useful.
Can’t upvote twice, have a low effort comment instead
I fall in the abandon it camp. Code is read way more times than it is written. I’d rather read an algorithm that validates input than read a regex that validates input.
You’re discussing a completely different use case from what I said. RegEx can be increidbly useful but it’s not always the only/best option.
feel like thats a notepad++ problem? in general, breaking it out into manageable human ingest-able chunks is A Good Idea
If you’re needing that level of complexity in a text file search, you already fucked up by putting the data in a text file. There’s a reason data file formats exist.
Not even close. Sometimes you can have a large text file where you need to do a find replace with a pattern. For example, in the translation world this can be a common occurrence for translation files (.xliff) or translation memories (.tmx).
There’s a reason why this is widely used and it’s not because everyone else but you is dumb.
Turns out the million hours of coding put into SQL, makes it a better option than regex, even for xml based files.
Maybe for your very specific use case that’s true. However, other use cases exist and for many of those RegEx is the better option.
I’m saying if your use case makes regex the best option, you’ve gone the wrong way and should turn back. There are definitely corners you can paint yourself into that make it the way to go, but you’ve ended up there through a series of bad ideas.
Maybe, just maybe, the context in which you use regex isn’t the same as everyone elses. But hey, who am I to deny you the disservice of thinking you’re the center of the world?
Why would I use SQL to to reformat a poorly structured log file for programs whose source I have no input in during a live debug with a customer on system that I don’t own and can’t install anything on? Or to extract and format things like hosts from a similar file?
That’s stuff that’s quickly and easily done in vim (which is generally part of the base install) with regex. There’s a lot of use cases that have no overlap with SQL.
So your use cases for regex are when you’re not going to actually fix the problem that caused you to need regex?
Modifying software that might not be within the scope of the company that I work for, much less my team, on systems that I explicitly do not have authorization to make such changes on? No, I would not be doing that.
An important thing to remember is that going all-in on a given tool is going to result in a bad time. You suggestion of SQL, for example, excels in querying and modifying data that lives in a database and follows the expected structures in said database. Most data is not in databases, nor is it structured in a compatible manner, if at all. The workarounds needed to coax SQL into performing such tasks would result in syntax both more arcane and more verbose than the regex necessary to transform it into something compatible.
Use the right tool for the right job. For transforming semi-structured and unstructured data into something useful in a practical amount of time, regex is frequently the right tool.
Regex is a write only language.
I love regex and I use it a lot, but I very rarely use it in any kind of permanent solution. When I do, I make sure to keep it as minimal as possible, supplementing with higher level programming where possible. Backreferences and assertions are a cardinal sin and should never be used.