Agreed. I can write a regex the (very) few times I need one, but it generally entails me looking up a cheat sheet to get the appropriate character classes. If you were to put me in front of a whiteboard I would flub the most simple of tasks (from the original post, "{(.*)}", I think? Did we mean to include whitespace, and does . translate properly? Because that's partly language dependent when it comes to white space, newlines, etc, and how the regex parser works. Did we mean to capture empty cases? Did we intend for it to be greedy?).
Does that mean I can't program? Ha ha ha, no. Does that mean I can't manipulate strings like a boss? Ha ha ha, no. I first reach for the language's tools, before I reach for regular expressions (the OP, I would first reach for doing a string search for {, and then one for }, from the rear if you want it greedy, and substringing what is in the middle; it's far less ambiguous, and any dev will know exactly what it does). Even when something ~technically~ takes a regex, if what I'm looking for is just a literal (as it often is; does this string contain X or not?), I don't need to 'know' regexes. So there's a LOT I can do without knowing regular expressions.
Meanwhile, I -have- needed to be able to recognize that something was running in O(n^2) time, and what I could do to optimize it to O(n). I -have- needed to implement my own search and bucket sort routines.
EDIT: Oh, wait, no, for the regex I'd need to escape the brackets, too. Etc. See? Now I have two problems.
Start using regex in your text searches while programming. It will make you more productive (especially when you start using it with search-and-replace) and you'll learn regex properly. Please don't parrot that Jeff-Atwood-nonsense.
EDIT: I don't care if you ever actually use regex in a program. You should learn regex just as a part of using a text editor.
For example, suppose I want to write a bit of repetitive code like this:
x = x + vx * t + ax * t * t / 2;
y = y + vy * t + ay * t * t / 2;
z = z + vz * t + az * t * t / 2;
If you just copy-paste the first line and change all of the x's to y's and z's, you're extremely likely to make a mistake. There has been study in this and it's one of the most common classes of logic error.
However, with regex search and replace, I first type
x
y
z
Search with the pattern: (\w)
And replace with the pattern: $1 = v$1 * t + a$1 * t * t / 2;
And now that I've been doing it for a little while, it's second nature. It's how I write lots of code.
I do, if it will actually save me something. Usually, I don't need anything that actually requires me looking up or constructing a super complicated regular expression.
Per your example, I code in a functional language. I'm even less likely to make a mistake if I just reuse the function, than I am to apply a regex.
You don't have to look up how to use regex if you know how to use regex. If you just learn how to use the tool already--which isn't very hard, the syntax is quite limited and the salient points are nearly universal between all regex engines--then the stuff isn't "complex". It's as complex as C or Javascript or Scheme was on your first day of learning it. Less so, because there is less to learn.
The example is arbitrary. The point is, sometimes you end up writing repetitive code. Yes, even in functional languages.
Clarification: I know how they work. What I -don't- bother keep in my head, is every metacharacter, character class (POSIX especially), assertions, string replacement options, etc, because I can just look those up. The example mentioned above is actually a really good case of why I don't worry about remembering all the specifics; because it's really easy to screw it up. Oh, I forgot {} were special characters, because I have -never- used them (any time I needed repetition it was always so few times, and for a single character class, I just repeated the character in the pattern), so I forgot to escape them.
And let's not forget the implementation different specifics (the need to specify multiline matching as a separate parameter into the parser, \ vs $ for string replacement, etc)
In general, if I'm writing a regex more complicated then "Hey, does this string match this literal?" I'm going to pull up a cheat sheet, because it avoids issues like that. But the number of times it makes sense to do that is really, really low.
It makes as much sense to me to say you should remember all ASCII character codes. Why? If you know how they work, and you're not using them enough to remember all of them automatically, it's not really a problem to just look them up if/when you need them.
Does that mean I can't program? Ha ha ha, no. Does that mean I can't manipulate strings like a boss? Ha ha ha, no. I first reach for the language's tools, before I reach for regular expressions (the OP, I would first reach for doing a string search for {, and then one for }, from the rear if you want it greedy, and substringing what is in the middle; it's far less ambiguous, and any dev will know exactly what it does). Even when something ~technically~ takes a regex, if what I'm looking for is just a literal (as it often is; does this string contain X or not?), I don't need to 'know' regexes. So there's a LOT I can do without knowing regular expressions.
Meanwhile, I -have- needed to be able to recognize that something was running in O(n^2) time, and what I could do to optimize it to O(n). I -have- needed to implement my own search and bucket sort routines.
EDIT: Oh, wait, no, for the regex I'd need to escape the brackets, too. Etc. See? Now I have two problems.