If you have a single CS bone in your body, you should be able to grok at least the basics of regex.
If you don't, then go back to designing* I guess, and ask for a programmers' help
* I only say this because I recently saw a tweet from a frontend designer person who said she thought regex was the worst technology ever invented and she absolutely hated it.
Disclaimer: For whatever reason, I'm a big fan. Concisely describe patterns in text and match on them? Plus the puzzle-fun of figuring out how to match on what you're looking for? Yes, please. (And yet, on certain programmer teams, I've had to scale back my regex usage because of you folks who refuse to just learn it, sigh)
> If you have a single CS bone in your body, you should be able to grok at least the basics of regex.
Sure, but I don't think the existence of this lib implies the author disputes that, and I can only imagine they're pretty familiar with regex themselves. I think they're trying to fill a legitimate need in frontend dev, which is: if you're only touching regex a few times a year, it's pretty intimidating, and not at all maintainable. SQL can also be difficult to grok if you don't write it often, and ORM interfaces make it easier.
Would the world be a better place if everybody knew regex perfectly? Yeah ok it would, but investing a bunch of time learning something you will only occasionally use is a poor investment IMO.
> If you don't, then go back to designing* I guess, and ask for a programmers' help
This seems to be needlessly condescending? You can be an excellent programmer (particularly in frontend) for years while avoiding regex. It's not a make-or-break thing.
I agree with you. They can certainly be abused, like anything else ("now you have two problems!"). But crafting a beautiful regex when it's exactly the right tool for the job is extremely satisfying. I think if more people took the time to understand them and practice writing them (when appropriate), they wouldn't have such a stigma.
I think if more people took the time to understand
them and practice writing them (when appropriate),
they wouldn't have such a stigma.
I think this is part of the movement to a more "ide/web centric" development model. The chances to interaction with regexes on CLI are endless. Grep, git-grep, vim, sed, etc. Even bash has some limited regex integration. As a person who still does most their development in the cli with vim regexes are a massive part of my work flow I actively use them several times per day.
When people move away from this model there are a lot opportunities to practice regexes. I've noticed this my own workflow when working Java-centric languages (who's IDE's often have poor regex integration).
I think one reason why most people have a hard time reading regex is because they don't use any indentation or linebreaks.
Honestly, if a buddy came to you and asked you to help him debug a javascript method and all 15 statements were on the same line, would you offer to help him, or tell him to fix his shit first so you can read it?
What if it was all on one line and his variable names were all "v1", "v2", etc. Would you help him then? fuck no. And yet, this is standard operating procedure with regex, except you don't even get "v1", "v2" because nothing is labeled at all. v1/v2/... would be an improvement!
This is how most people write a simple date regex:
\d{1,2}/\d{1,2}/(\d{4}|\d{2})
And mind you, this is a very simple scenario. Here is how you would write it if you treated it like actual code:
(?<month>\d{1,2})
/
(?<day>\d{1,2})
/
(?<year>\d{4}|\d{2})
First off, you can know what my intent is when I'm capturing each group. Maybe this code gets used by a european where the month and day switch places. They can figure out how to fix it in like two seconds. Secondly, the forward slashes are not lost in a sea of characters anymore because we use whitespace like a civilized developer, not a regex savage.
The regular formalism is very neat and I like to use it, but the RegExp syntax doesn't do it justice.
They are pretty much write-only, and there's no way to compose two regexps safely (new `RegExp(a.source, b.source)` breaks for `/a|A/, /b/, for example).
Rex is a good attempt at solving this. I wrote a similar lib a while ago (more functional and tighter in design, see my other comment on this page).
>If you don't, then go back to designing* I guess, and ask for a programmers' help
Was this actually necessary to say? It's not only insulting to people who don't need/care about/currently know regex, while simultaneously insulting of designers' intelligence.
I'm a CS guy through and through. Regular languages, cfl, ..... Np complete, what was the books name again?
But I gotta say, regex isn't the best way to show things. Hard to verify, hard to maintain and what not. Computer sciency, sure. But not well "designed".
Now I have no love lost for people who talk about stuff without understanding the fundamentals or the basics even. So I don't doubt that the person was "whatever". But I do feel that regexes need an overhaul
Ps: I'm a fan too when I have to do quick stuff in shell. But not so much when I save it to a file to be read by me and multiple people weeks later. Regex is one thing that is way easier to write than read.
If you don't, then go back to designing* I guess, and ask for a programmers' help
* I only say this because I recently saw a tweet from a frontend designer person who said she thought regex was the worst technology ever invented and she absolutely hated it.
Disclaimer: For whatever reason, I'm a big fan. Concisely describe patterns in text and match on them? Plus the puzzle-fun of figuring out how to match on what you're looking for? Yes, please. (And yet, on certain programmer teams, I've had to scale back my regex usage because of you folks who refuse to just learn it, sigh)