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.
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.