Why do people defend the regex syntax? [closed]

Answer 1

Pyparsing (http://pyparsing.wikispaces.com/Examples) is a Python library that makes it easy to write regex-like expressions that are highly readable, like these lines that will parse "Hello, World!":

from pyparsing import Word, alphas
greet = Word( alphas ) + "," + Word( alphas ) + "!"
greet.parseString("Hello, World!")

It looks like the library is very close to being able to match the power of regexes (see the examples page mentioned above).

Answer 2

Like Adam said, is there anything better? I shudder to think of trying to do a bunch of strcmp operations instead of a good regex. Like any expressive language it is possible to abuse the regex and make very unreadable constructs, but often even a seemingly unreadable regex makes much more sense than the equivalent procedural code to achieve the same thing.

Without the regex, you'd have to write your own routine to parse, backtrack, compare, store indexes, make substitutions, and manage all the results. Regex gives you all that in a very expressive form. I don't like to repeat code, but if I had to code my own parser every time I needed to look for a moderately complex pattern... I don't know what I'd do.

Yes there are different flavors of regex, but most the most popular ones are very similar, and whatever language you are using them in usually has documentation to help you read it.

Answer 3

Most of what I have to say were addressed by Adam and DGM, but I don't think they cover your second point very well.

"how about all the very easy to understand, non compact, non cryptic and dare I say pretty domain languages out there like SQL or LINQ?"

I think a good way to express an answer to this is to ask, how would you use English to explain a regular expression?

<TAG\b[^>]*>(.*?)</TAG>

Look for "<TAG" a word boundary zero or more of something that is not '>' followed by a '>' remember zero or more of something, stopping at the first "</TAG>"

This is a fairly simple regex. Is the English form really easier to understand? Could you do better?

Regular expressions are hard to read, but what you want from them can be just as hard to explain.

Answer 4

You should be looking at regular expressions as high-end power tools (and I mean power tools in the construction industry sense).

If you're building a little work table for your shed, you don't pull out the nail gun, chainsaw and industrial router. You use a saw, some nails and a hammer.

Similarly, you don't build a 30-floor building without a crane in there somewhere.

The idea is to use the right tool for the job AND the right tool for your skill level.

If you have to cut down a tree, make sure you know all about kickback before you start up the chainsaw. If you don't, then use a hand saw instead and save yourself a trip to the hospital to re-attach your severed limb.

I use regular expressions the way I use my chainsaw - very carefully. If you're uncomfortable with the tool, don't use it. Once you learn how to use it properly, you'll find it a lot easier to get things done faster.

Answer 5

Looking over the similar question which you mentioned and its answers, I saw a few attempts at creating "friendlier" alternative syntaxes, from both supporters and detractors of regexes as we know them today.

I found them to be uniformly less readable than equivalent regexes.

Now, granted, I am a regular user of regexes, so I'm sure my comfort with them is a significant part of this. But my primary problem with them was not unfamiliarity, but rather that they quickly grew too large to take in all at once. When your 20-character regex becomes a 10-line-by-30-column pseudo-English expression, it becomes much more difficult to see how the parts of it relate to each other.

Perhaps someone will come up with an alternative syntax to regexes which is universally more readable, even in complex cases, but I submit that such a syntax would inherently require some equivalent to subroutine calls. We don't write 200-line blocks of application code with 15 layers of nested logic because it would be a monumental task just to track the logic of it, never mind figuring out what it actually does. If we're going to explode regexes into a more English-like form, then that same problem will occur and we'll need the same tools to manage it.

Answer 6

A regular expression (at least originally) describes a regular language. Regular languages have very nice theoretical properties in that they both can be described by and describe a deterministic finite automata. DFAs for non-trivial regular expressions are painful to code by hand.

More importantly, regular expression compilers used in the back end of perl, etc. are very good at what they do. It would be very difficult to hand tune competitively performing code.

Finally, their existence is largely a historical artifact. They've been around a long time, picked up mindshare, a lot of people know them. A tool you have and that other people can support is a lot better than a theoretical tool that doesn't yet exist.

If it is just the syntax that turns you off, maybe you should consider looking at parser combinators in Haskell. They can express a superset of the same ideas and have a more explicit syntax.