41–50 of 55 posts
By the way, if some like spacing that much, and if the reason is to have a better mouse-selectability, then I humbly propose "( a , b )".
More concise? Sometimes. Slower? Always. BenchmarkRegexp 500000 5136 ns/op BenchmarkStrings 10000000 173 ns/op http://play.golang.org/p/YT29Ao-tOt
Stop propagating bad interfaces like 'regular expressions' damn it! An interface that e.g. makes me 'escape' half of my input because its designers think their special use of characters must take precedence over all user input is a bad interface.
OT: Where from come this seemingly odd and new habit of spacing inside parentheses? I always write "(a, b)", mostly because it is closer to English (or other languages) typography, and it seem to have good readability, plus it is, I believe, the standard in most languages. So why write "( a, b )"? By the way, if some like spacing that much, and if the reason is to have a better mouse-selectability, then I humbly prop…
My current pet peeve is with parser combinators, wich seems a good compromise (it's not a magic wand) between maintenance (whereas external parser generators don't blend well in your code), parsing what you think you are parsing (more so when your grammar was defined with rules in a reference document), and integrating the parser with your code.
THE single best ressource to really learn how to deal competently with regex is still Jeffrey Friedl's book "Mastering Regular Expressions". 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...)
Sincere question - is it worth investing time into reading a 500 odd page book for something that I might not use that frequently in my career? From my experience, I've seen that I can get away by just Googling or just experimenting whenever I'm stuck on a regex.
The core criticism of regular expressions is legitimately directed at intermediate programmers who know enough to be dangerous, but is sometimes inappropriately cargo-culted by beginner programmers who use it as an excuse not to learn regular expressions. The fact is that despite pithy slogans, there is a sweet spot where a regular expression does the job of matching a string in a clearer fashion than anything else.…
Though there's nothing wrong with busting out a baroque regex in one time use contexts (editor's search function, throw-away application of grep or sed, &c).
THE single best ressource to really learn how to deal competently with regex is still Jeffrey Friedl's book "Mastering Regular Expressions". 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...)
Sincere question - is it worth investing time into reading a 500 odd page book for something that I might not use that frequently in my career? From my experience, I've seen that I can get away by just Googling or just experimenting whenever I'm stuck on a regex.
I do take issue with your suggestion that you might not use this stuff all that frequently in your career. This is definitely at odds with my experience. Even though I don't use them that much in final-quality code, I use them all the time from the text editor, and quite often for quick one-off text manipulation or extraction scripts. Having a quick way to extract text from ad-hoc data can quickly get you a rough answer to a speculative question, the text equivalent of of back-of-the-envelope calculation, without needing to do a lot of work and without needing the question to justify a lot of work.
But I mainly use them for searching for one of two or three different strings in the text editor.
More concise? Sometimes. Slower? Always. BenchmarkRegexp 500000 5136 ns/op BenchmarkStrings 10000000 173 ns/op http://play.golang.org/p/YT29Ao-tOt