09:49 am, 2 Feb 05
jwz quote
I had a meeting on Monday where the presentation began with the
jwz quote:
But because it’s usenet it becomes a flame war, of course. But there are some other zingers:
Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems.So, so, true.
[link]
But because it’s usenet it becomes a flame war, of course. But there are some other zingers:
- > To me perl is the triumph of utalitarianism.
So are cockroaches. So is ‘sendmail’. - I’ve been hacking C (it’s not just a language, it’s a grade) ...
- Maybe someday, the language that practicality makes us settle for will also be one that doesn’t suck quite so much as the current crop do. Maybe we won’t be “settling” at all.
I expect this will be about the time we’re all buzzing around on jet packs, living in automatic houses, and driving nuclear-powered cars.
Almost.
sublanguages in one monolithic executable. It combines the power of
C with the readability of PostScript.
swoon!
Somehow I was unaware of the actual existence of the alt.religion.emacs newsgroup (although I think I'd always assumed that it was there)... hilarious thread.
There was a time when I'd use regexes for everything. As far as I'm aware, though, I've not really used them for anything major in the last few years; just quick shortcuts like
if ($something =~ /\S/)
.Xml has always made me wince. But, recently on /. I noticed someone mention that robust csv parsing meant handling escaped separators, testing for well formedness, ensuring each value was appropriate, and more. That's exactly -- and only -- what xml is good for. The dev community has produced a number of robust libs which make it easy to use well structured serialized data.
Like xml, regex tools provide a higher level, more robust way of mucking with text. It's sad to see a page of HLL code full of '\\' and loops.
My experience is that most developers are uncomfortable with regexes. That's the feeling I get from this thread... where's the beef?
personal issues with excessive regex use:
* can be hard to read (exponentially so as length increases)* hard to debug
Re: personal issues with excessive regex use:
1: If the regex library you're using allows for something like perl's /x modifier, use it. If it doesn't, find a way to use it anyway. (For those who don't use perl: /x makes un(backslash)escaped whitespace outside of character classes meaningless, and allows #-until-end-of-line comments.). If your language doesn't have it, you can probably get around it by building the regex as a string, with lots of concatination, and putting the comments outside of the strings.)2: If you're regexes need to be debugged, they're too long. Don't use anything that you can't understand at first glance inside a regex. For most people, this includes all the (?...) constructs, with the possible exception of (?:...).
3: Don't use (?:...) either. It makes your regex harder to read, and saves a little bit of CPU time (memory bandwidth, to be more exact). It's not worth it. Not only that, in sane languages, it doesn't save anything, because the language can tell if you're using the captures or not. (Perl is insane by this measure. I expect most other languages are too, since they stole everything they know about regexes from perl. Of course, perl stole it from somebody else too.)
Most problems I see with regexes are trying to get your regex to do something that could have been better done outside the regex, or doing things the hard way instead of the easy way. (Negitive lookbehind, for example, is often better done with a negated character class, sometimes |ed with ^. That only handles single-character cases, but that's normally what you're interested in. Don't do things the hard way when an easy way works. Similarly, often using two regexes instead of one is easier, or just using a negating the sense of your test, instead of using negated features inside the regex all the time... or sometimes the oppisite. For example, to check if your string contains only digits, die if it contains nondigts. It's better that the inside of your if be short then take up the entire rest of your function.)
Secrets to Perl success
Don't create constructs like this:
The punctuation to readable English ratio is way off here. You read this as “while there's stuff, if blargh wibble fibble foo, print somethingorother”.
Also, don't write things like this, unless it's just for laughs:
…but hopefully that was obvious.
I want both!
I don't want nuclear powered cars, I want flying cars.