Last night I [Edit: grammar]had a talk on Regular Expressions for PAFOX a Visual FoxPro usergroup. Apparently there was a three part article in FoxTalk2.0 by Lauren Clarke and Randy Pearson about text manipulation that described an implementation/fusion of Regular Expressions with native VFP string/test functions. Tim Yeaney wanted to fill in some blanks for the group so he got in touch with Geoff Snowman, our Developer Champion, who put him in touch with me.
The slide deck for the presentation is over on the Thycotic site but I'll warn you, there's not a whole lot of meat. That's not to say it was a quick talk, it went for an hour and a half. The problem with discussing regular expressions (regex) is that you have to strike a balance. No one in my audience came from a pure computer science background, had any experience in language construction, compiler design, lexers and though I didn't ask any *nix tools like sed, awk, grep or PERL (no, it's not just a *nix tool, I know). So the theory / background leaned a lot more towards "it's a pattern describing a set of strings" instead of the formal language theory.
We quickly set aside theory and went into practical usage, starting with some typical contrived examples you might see in data validation. I was using The Regulator during the presentation, a choice I regret and I'll explain why in a moment, to demonstrate matching. Another thing you won't find in my slide deck is a list of characters and symbols [], [^], \d, \W, etc. Not because I don't think that's useful, because I wanted to focus on the intent of regex and not necessarily the details. Sure I'm discussins a specific implementation (System.Text.RegularExpressions) for use with VFP but I'm also talking about a tool that has many different implementations (look at VS.NET search and replace with regex for example, or for that matter just about any text editor has their own version of regex). It's important to understand the concepts, you can get the details from a reference.
I showed a few examples where it could be used in search, how string replacement worked and we ended by working through log parsing. The log parsing example was interesting because it tied a lot of pieces together. If you ever try something like this, make your log short 10, 15, 20 lines is probably plenty, I started with a 24K file and quickly pared it down.
One last note about my slide deck, I'm probably the first guy to talk about regex in .NET and not mention regexlib. That's not an oversight. I think regex is a fairly useful tool but like every tool there are appropriate times to use it and not use it. I've discussed this before over on my regex blog before. Yes it is possible to define a single regex to do a lot of the things I don't agree with, doesn't mean they're wrong, but I'm not going to encourage those things.
Regrets, thoughts, etc:
- Using The Regulator. I'm not busting on Roy or his tool. I think it is a great tool but it doesn't have a place--at least for me--during a presentation for several reasons:
- [Edit: content]
I can't change font size, if you can, let me know how, I couldn't find it.Right click in the edit window, choose options... - [Edit: content]
I want to turn off "intellisense", it just gets in my way. This was especially true when not building the complete expression from left to right. I liked to go back and refactor the expression, then I'd be caught in the intellisense bit and have to remember to escape out of it before trying to move the cursor somewhere.This one was even easier, view/options, and there are only 3 choices. - I want to turn off scope matching brackets, parens, braces for pretty much the same reason as intellisense. I think they're a great idea for a beginner but I'd really like to turn that off.
- Maybe install PowerGrep or something so the search demonstration could be a little more flexible.
- Not having made a minimal quick reference dealing just with basic ECMA, no lookaround stuff and no code just something I could pop back and forth to when I'm describing a new pattern.
There weren't a whole lot of questions. I'm not sure this was good or bad. I think neither, just that like any other tool unless when you learn about it you have a specific need where it coud be applied to make your life better you don't know what questions to ask yet. I could have spent some time quizing the audience, this would probably work a lot better if there was a whiteboard around (or they just pass the keyboard around or something -- not wireless, so I'll have to remember that if I want to try it).