How would you design a regular expression syntax more intuitively? Personally, I find beauty and simplicity in regular expressions. Sure, they can grow to hideous atrocities, but you can achieve such disastrous feats with any language/syntax. Maybe you could back up your claim of regexes being a disgusting abomination with, at the very least, anecdotal evidence.

IMO, the main problem is that the syntax is too terse. The syntax is taken wholesale from the algebraic notation used in mathematics and dropped in unmodified. Essentially, regex code ('cause regexes really are code) is not skimmable.

The greatest syntactical atrocity in regexes is that they don't have the `x` modifier (in Perl parlance) on by default. This means that you can't use whitespace to chunk code into meaningful bits, nor can you comment it to easily document what does what or explain a particularly hairy section to handle some weird edge case. This means that regexes degenerate a lot faster than ordinary code in terms of readability.

Edit: Misplaced close paren.

"Easy to write, hard to read". Perl's influence on Regex shows. Which is fine in most cases.

I always wonder what regexes would look like if they were derived from Python instead.

Actually, regex syntax isn't primarily a Perl invention. Regexes as software tools go back to early Unix text processing tools (ed and grep, according to Wikipedia), and Perl took the syntax from those tools.

It is true that Perl reformed the syntax in important ways (to the better, if you ask me), and later on extended it a lot, but it's certainly not a Perl invention.

A typical regex looks like this:

  \b[A-Z0-9._%-]+@[A-Z0-9.-]+\.[A-Z]{2,4}\b

Which is also what happens when a cat walks across the keyboard.

There's nothing wrong with regex syntax. But there _is_ something wrong with the formatting of your example: it's not readable. Perhaps you _should_ write (assuming Java-syntax):

  (?x:              #standard token is an uppercase letter, digit, dot, or hyphen
    \b
    [A-Z0-9._%-]+   #1 or more of standard token, underscore, or percent sign
    @               #at-sign
    [A-Z0-9.-]+     #1 or more standard tokens
    \.              #dot
    [A-Z]{2,4}      #2 to 4 uppercase letters
    \b
  )

We can easily optimize for readability with regex syntax.

You can say that about pretty much anything if you aren't familiar with the syntax. That looks pretty readable to me - certainly far more portable and readable than equivalent code.

[It's also perfectly obvious that if this is an attempt to match email addresses that it's not a very good one - but I don't know the context where it's supposed to be used, it might be good enough for whatever the author intended].

I find that perfectly readable, except for the \b which I hadn't seen before. It's matching an all-uppercase email address.

There's plenty of upper case e-mail addresses that won't match that expression.

Well, if you want to be fully compliant you can go for this 6kb monster

http://ex-parrot.com/~pdw/Mail-RFC822-Address.html

/i

There's characters missing[1] and the tld is too short[2]. And even if that's fixed, we still don't match internationalized addresses or actually validate that the e-mail address exists. You're probably better off with something like...

   if "@" in email and "." in email.split("@")[1]:
       send_verification(email)

...but you should probably also check for common misspellings like "gmial.com" etc.

[1] http://en.wikipedia.org/wiki/Email_address#Syntax [2] http://en.wikipedia.org/wiki/List_of_Internet_top-level_doma...

Call me weird, but I find that very readable.

Hmm - you know I actually think it's not correct to look at regex as an interface - even though we use it as one. It's really more accurate to look at it as a grammar (type 3 if I remember correctly).

Anything that comes out of the whole chomskian hierarchy stuff isn't going to look intuitive. But the point is that it is a particular, very rigorously defined system of representation. And various systems of representation are always more or less intuitively accessible - and come with a whole set of trade offs around what they can represent vs their ease of use etc...

These things just are - written into the laws of the world. They are discovered - not invented. We pick them up and use them as we would rocks left lying around. We find better ones when we can and fashion better ones when we can too...

> Anything that comes out of the whole chomskian hierarchy stuff isn't going to look intuitive.

Why not? Type-0 (recursively enumerable) languages are equivalent to Turing machines, and we've managed to invent some pretty good syntaxes for that. The main problem with regexes really is the syntax. Regular languages are a lot easier to understand (IMO) if you look at the left/right-linear grammars that define the same language as the regex.

Regex syntax as a representation is very close to the FSA used for matching, and that's not necessarily the representation best suited for human consumption.

> These things just are - written into the laws of the world. They are discovered - not invented.

This applies only to the theoretical computer science regexes. The practical regexes are very different in this aspect.

Practical regexes are neither discovered nor invented - they are constructed. The theoretical regexes are just the basis but on top of that there's a lot of features added. Some of them are just syntactic sugar for theoretical regexes but others actually make the language non-regular.

Groups that match what previous named groups have matched are definitely in this category.

>It's one of the worst syntaxes to ever be invented, and every one of us should feel the cold stink of UX failure wash over us every time we write a regex.

Okay, so they're ugly and hard to read at first glance. Considering the purpose of a regex, I can't think of another way to implement them that doesn't involve typing more characters needlessly (therefore even making it more hard to comprehend).

I think that regular expressions have a good syntax for most typical (small) uses of regular expressions. Maybe the choice of special characters isn't ideal, and it might be nice to have 'English' versions of more special characters (similar to e.g. [[:digit:]] in POSIX), but for small regexes the (mostly) one-to-one mapping between characters in the pattern and characters in the string is a very nice and intuitive syntax.

I think the real problem is that we lack (or don't learn) good tools to bridge the gap between regular expressions and 'custom parser'. We're reluctant to refactor from '1 line of just-starting-to-be-horrible regex' to tens or hundreds of lines (depending on language and libraries) to do it 'properly', and so we end up stretching regular expressions beyond the point where they make life easier.

Perl has Parse::RecDescent (and probably several others), which is pretty close to the right thing, and clearly it's very doable in a lot of languages - anyone got any suggestions in other languages?

I could imagine a Jquery-like DSL where something like /^[A-Z]+[0-9]{2}$/ could be expressed like Match(str).BeginsWith().BigCaseAlpha().AtLeastOne().Numeric().FixedLength(2).EndsWith()

Of course, you would also have to be able to nest these for more advanced matching...

Is there something like this already in existence? :)

How about pyparsing? http://pyparsing.wikispaces.com/

Please name 2 concrete ways to improve the "interface" of a standard regex.