I thought I knew regexps, then I read "Mastering regular expressions". After that I was embarrassed. :-)

Also – reading it was just a useful look into systems mapping (which is what language is!) with insights that apply in many contexts.

Very highly recommended.

The book is worth it's price if only for chapter 1, definitely seconding this recommendation.

"Mastering Regular Expressions" by Friedl is the ultimate resource, but for getting started that website above will let you learn the practical syntax.

You will profit from it for the rest of your career.

(There's also a Regex short reference and a Regex cookbook by O'Reilly...)

I recently got through the Design Patterns book. I was thinking of picking up either a new language (Go) or start the "Mastering Regular Expressions" book, not sure which.

[1] http://shop.oreilly.com/product/9781565922570.do

I picked up an older revision from abebooks or ebay. The Python 2.7 online docs recommend revision 1 and states later revs don't cover Python.

I found the pacing to be excellent, with complimentary exercises and that it was educational as both a cheatsheet and a coherent text. Learned a lot from it, despite being experienced from the outset.

Reading the first chapter of ORiley's Mastering Regular Expressions was what made me get it and that was maybe an hours worth of time.

Mastering Regular Expressions by Friedl is regarded as one of the best resources. But just to get up and running and as a reference I recommend http://regular-expressions.info

[1] http://regex.info/book.html

All history aside,
1: Sed&awk
2: Mastering Regexp
3: The vim book has a great chapter on regular expressions (it's been ~10 years since I've touched it, but I remember being gifted a copy from a colleague of my father when I was in my teens and it helped me grok it)

The glibc programming manual is actually really comprehensive. kernel.org/docs/man-pages/ gives a pretty in depth analysis of POSIX.2 regex. I'm sure Perldocs also have PCRE's very well documented.

It's 6,598 bytes long.

https://metacpan.org/release/Email-Valid/source/lib/Email/Va...

That comparison sold me. You deserve a commission.

I was obsessed with that book one summer and wrote a bunch of parsers after learning incremental techniques (/o I think), and then 8 months later I could no longer remember how anything that I wrote worked. Lol me.

And as clear as the source could be made, I feel the fact that so many people have just copied and pasted it means that any understanding is lost, and they're just praying and hoping, because a regex of that size is actually difficult for them to comprehend.

Regexp engines are subtle beasts, and there's a couple different ways to implement them (DFAs vs NFAs, simple engines vs lots of clever special cases, etc.). See O'Reilly's "Mastering Regular Expressions" for an exhaustive discussion.

- Perl Cookbook

- Mastering Regular Expressions

I completely understand why it looks like an NFA.

> What the heck do you call it?

Anything but an NFA? My personal preference is unbounded backtracking (still not quite right), or just "Perl regexes."

> (As well, that is how it was described in a number of popular and widely read books. For example pick up _Mastering Regular Expressions_.)

I read that book when I was a young pup and remained hopelessly uninformed about the entire situation until my first complexity theory class during my undergraduate study almost ten years ago.

That book is fantastic if you care about optimizing Perl regexes. It otherwise does a great disservice to theory and has likely been the cause of uncountable confusion. When pointed out the inaccuracy, Friedl essentially had the same response as you. It's tragic, frankly.

PCRE's documentation even cites Friedl's book when describing their implementation by calling it the "NFA algorithm." PCRE also has a supposed "DFA," but its description makes it sound more like the actual NFA algorithm (since it maintains multiple states simultaneously).

Regex will not only give you new skills for programming (no more splitting strings in weird ways and doing complex indexOf/substr operations), it will help you day-to-day in rummaging through file systems and your code.

And if you already know regex, then I'd recommend Map Reduce Streaming. The Streaming variety is all based on standard in/out and very straight forward. Amazaon Elastic Map-Reduce could be a nice way to test things.

Since many people are not good at them, whenever I use a regex in code, I add a comment with at least one example of the text that is to be matched, and note what the regex is also attempting to avoid. This is also a learning activity.

There is also the "Mastering Regular Expressions" book.

If you're curious about CS you should just go ahead and read SICP. I recommend the printed version, but the whole thing is online here:

http://mitpress.mit.edu/sicp/

Perhaps there are people who love CS and yet hate this book, but I have yet to meet one. It's not the easiest book in the world, but it is the real thing, and not an imitation.

There are, of course, lots of things you could learn which are not exactly "CS" but which will make you a better web programmer. Study SQL. Study emacs (read Steve Yegge for inspiration) or another killer editor. Learn to use a really decent version control system (the SVN book -- just google "SVN book" to find it -- is easy to understand, but Linus Torvalds is right when he claims that Git is much nicer!) Read "Mastering Regular Expressions". Read Bruce Eckel's Thinking in Java so that you know enough about the world's most popular language to understand where it sucks, ;) and so that you can follow the conversation of much of the rest of the software world. Read K&R.

Tutorials, blog posts and a smattering of example code is fine for messing about with some new technology. But where are the authoritative sources. Looking at my bookshelf now, where are the websites that contain all the information I got from (the excellent) "Mastering Regular Expressions" or "CSS: The Definitive Guide" which sits nicely between the CSS spec and actually being readable.

These books still need to be written, in the same format, by the same experts because they contain a lot of value. I agree though that they don't need to be physical books -- all my new O'Reilly books I read in PDF format.

(Realise there's a lot of O'Reilly naming here, it's only because I really like the quality of their books. I'm not affiliated with them.)

Jeffrey Friedl (author of Mastering Regular Expressions) has some KidZania entries on his blog from a few years ago.

http://regex.info/blog/2009-06-28/1245

http://regex.info/blog/category/japan/kidzania

Then you are the opposite of where I used to be -- I thought I understood and could use regexps. Hell, I do Perl for fun. :-)

Something like when I first sat down with Photoshop -- "Hey, I know how to program Macs [before MacOs X]. This is just using a Macintosh program, so I should have no problems"... :-)

Read "Mastering Regular Expressions". It made me feel embarrassed about my previous stupidity [Edit: Embarrassment, your name is Dunning–Kruger :-) ]. Just the first few chapters are enough to change your world.

Edit: I might add, I still can't use Photoshop.

One I'd recommend is "Eloquent Javascript". It may be a tiny bit out of date now (I read it over 5 years ago maybe, and Javascript has improved a lot since then), but it's a solid book.

Other books you might like: Pragmatic Programmer, Pattern on the Stone, Clean Code, Mastering Regular Expressions.

First -- I noted that I limited my comment to scripting languages.

I did discuss most of the relevant arguments in the article, so I really don't see what your point is?

It doesn't matter for the scripting languages that a regexp lib is large (it is linked in and used anyway), so I ignored that. I also ignored the Unicode point, since it is generally supported in scripting languages' regexp engines.

I did touch on speed and development speed. Shorter code is also generally easier to understand; a simple regexp can often replace 10-20 lines.

In my edit, 10++ hours before your comment, I discussed when full grammars where a better alternative -- so I handled Pike's accusation of treating Regexps as a "panacea for all text processing". (I have used regexps as lexers for grammars. But only for parsers of less than a few hundred lines.)

(I am not going to touch Pike's argument if I and others really grokk regular expressions, because I thought I did understand them until I read "Mastering Regular Expressions". Maybe there are some more satori insights waiting? I do consider myself a little bit familiar with them from automata theory, implementing state engines and usage [Edit: and my considered opinion is that re:s are often a good solution for scripting languages.])

It's my standard litmus test judging a programmer; if you haven't read or don't care to read a book on regular expressions, then I probably don't want to write code with you. It's also useful to remind people who think they're nerds because they own a smartphone and can download "apps" that they're in a league far below.

http://shop.oreilly.com/product/9780596528126.do

One other caveat about this, though. They make more sense and the topic is more motivating when you have a significant amount of text munging to accomplish (as I did, at one point).

Nonetheless, I remember some years ago being astonished at some of the Java code I saw being written, at not insignificant amounts of programmer time and with a bevy of mistakes, to accomplish simple pattern matching in use cases where a regular expression would have been more appropriate and more efficient -- both to write and probably in execution.

The developers, despite being fairly seasoned, just weren't familiar with the paradigm. A few years later, they were using them "all over the place".

It appears they punt on the particular issue of regex's running out of memory though. Developers are told "careful crafting of the regular expressions can help," and told to read "Mastering Regular Expressions."

As I recall, Boost's regex library will throw an exception if evaluation of the regex is getting out of hand.

It's funny, I generally judge a regex library on how compatible it is with perl's implementation. In this case though, I might actually prefer the behavior of Boost and PCRE.

For example, I've become known as "the regex guy" at the office. I know regex really well as well as the ins and outs of the regex engines of languages we use. I don't mind when I get called over to help with a tough regex, or optimizing something. But way too often whatever I get interrupted and cross the building just to replace ".*" with ".+" or something equally simple.

I usually just type the solution and tell them my copy of Mastering Regular Expressions is on the office bookshelf if they'd like to borrow it, the first chapter should cover all the basics. I'm also very happy to explain the basics of regex to someone in my down time, but very few people have taken me up on that offer.

You might want to read or reread Mythical Man Month, if you're looking for startup books. While not a startup book per se, its usefulness in the aspects of the programming environment is tenfold.

Take time to really grok Perl and you may find the soundbite swipes at Perl don't make sense any longer.

Mastering Regular Expressions is a good book to read as Mr. Friedl does a good (great?) job of explaining the pluses and minuses of regular expressions in a readable manner.

If all you want is how to use regular expressions then there are plenty of man pages and internet documents which provide examples that you can learn from without reading Mastering Regular Expressions.

You might look at the Ruby documentation to see how Ruby does things. And a quick search using Ruby regular expression provided this link: http://rubular.com/ which is a utility to test regexes. There are several other links immediately following this one which appear to be tutorial or information for what you are looking for.

Classic Shell Scripting by Arnold Robbins

Unix Power Tools 3rd edition

Two additional worthwhile books:

The Unix Programming Environment by Kernighan and Pike

Mastering Regular Expressions by Friedl.

All 4 are classics.

Also try tldr.sh website in addition to man pages. They are easier to grok.

Is that a joke? $30 is quite literally nothing for a new technical book. Refactoring is still $45 new (hardcover but more than 10 years old now), Effective Java is about the same price, TAPL will set you back $60 and ATPL is $56 on Amazon, HTDP is $67, Koza's "Genetic Programming: On the Programming of Computers by Means of Natural Selection" released in 1992 is $67, SICP is $70, amazon asks for a hundred bucks for the purple dragon books, and then of course The Art of Computer Programming boxset will blow a $200 hole in your wallet.

$30? That's the price of a small and widely-distributed paperback like Friedl's Mastering Regular Expressions. It's basically the lower bound, even The Art of the Metaobject Protocol (345p, published in 1991) is $40.

Here's what's under $30: "For Dummies" books. Even the Head First collection bottoms out around $30.

However, technical, computer, electronics, physics and math books are almost all uniformly terrible from Amazon (or even epub). These are long-term references that need a proper print layout option (PDF) and be unencumbered by DRM. A 2002 edition of Mastering Regular Expressions is virtually totally applicable today, 15 years later - but imagine if I had bought this in a DRM'd Sony version, or a Palm .prc (now part of Amazon)? I'd be SOL.

I thought I knew REs before reading that book -- since I had both been using them for years and did a course on automata theory at Uni -- but that was just Dunning–Kruger.

Edit: Also write a templating system and be done with it, so you won't waste time doing it later. :-) When I first learned programming I did quite a few simple games and routines to find primes.

http://www.unixwiz.net/techtips/be-consultant.html

Steve does a lot of sysadmin consulting work (in addition to software development). Here are some of his shared tidbits:

http://www.unixwiz.net/techtips/

He's also the brother of Jeffrey Friedl, author of Mastering Regular Expressions:

http://regex.info/

No Starch, Eloquent JavaScript. A Modern Introduction to Programming: http://shop.oreilly.com/product/9781593272821.do

No Starch, The Book of CSS3: http://shop.oreilly.com/product/9781593272869.do

O’Reilly, bash Cookbook: http://shop.oreilly.com/product/9780596526788.do

O’Reilly, CSS: The Missing Manual, 2nd Edition: http://shop.oreilly.com/product/9780596802455.do

O’Reilly, JavaScript: The Good Parts: http://shop.oreilly.com/product/9780596517748.do

O’Reilly, Mastering Regular Expressions, 3rd Edition: http://shop.oreilly.com/product/9780596528126.do

O’Reilly, The Art of SEO, 2nd Edition: http://shop.oreilly.com/product/0636920019091.do