Is there regular expression to match regular expression?
Regular Expressions – Mastering Lookahead and Lookbehind
71–80 of 85 posts
Re: Regular Expressions – Mastering Lookahead and Lookbehind
#72Earlier quoted context omitted.
A programmer saying they are terrible at regex is like a mathematician saying they are terrible at algebra.
You are so right! How could you possibly go out of practice in real-time biomedical algorithms engineering when you might use them one or two times out of the year?! I must have missed the memo where all those strings are encoded in a patient's hemodynamic signal. There are few people more frustrating to algorithms engineers and embedded engineers than people like you who think you are the only type of programmers ou…
Re: Regular Expressions – Mastering Lookahead and Lookbehind
#73Most of the time I mention the topic of regular expressions to other developers, I usually hear self-critical commentary like "oh, I'm terrible at regex", and rarely anyone who loves them. I think they're great though, if you take the time to understand them. They're something like a Swiss Army knife for programming.
It's like solving a puzzle that ends up eliminating work (by doing said work) extremely concisely. What better kind of puzzle is there?
Re: Regular Expressions – Mastering Lookahead and Lookbehind
#74> our pattern becomes: > \A(?=\w{6,10}\z)(?=[^a-z] [a-z])(?=(?:[^A-Z] [A-Z]){3})(?=\D \d). And then these guys wonder why people hate regexes? The "now you have 2 problems" quote fit perfectly for that case.
The regular formalism is pretty neat though. There are alternative syntaxes (e.g. multiline regexps in Python) that are better suited for complex matchers.
Re: Regular Expressions – Mastering Lookahead and Lookbehind
#75Earlier quoted context omitted.
It'd help a lot if the grammar was actually readable. Combinations like .* don't visually "read" like a single unit, and then to make everything worse you often need a crazy amount of backslashes. I'm not sure how you could fix that without introducing completely new characters or color-coding parts of the expression though.
The back slashes for escaping are absolutely awful . This is one of the worst things about Java. It's much better in languages with regex literals like Ruby and JavaScript.
Re: Regular Expressions – Mastering Lookahead and Lookbehind
#76Earlier quoted context omitted.
Some regex implementations allow for comments in the string; if your does not, you can probably make it work with concatenation, like: String pattern = "^https+" // match the protocol at the beginning + "([a-zA-Z])+" // match the machine name + ... Honestly, I use regular expressions because, even in such format expanded with comments, I haven't seen anything more readable after you get used to regex operators. I gue…
If you're using PCRE you should also make use of named patterns. It makes the expression easier to understand as you can reuse parts of it (a little like functions) and the matched patterns can be then used in your language with their name instead of their position. Decoupling the usage from the regexp so it is more robust. http://www.rexegg.com/regex-capture.html#namedgroups
Alas, we don't get such luxuries as named groups or static typing... Woe is me.
Re: Regular Expressions – Mastering Lookahead and Lookbehind
#77Earlier quoted context omitted.
JS programmers don't need to know how a C pointer works, but they're not doing themselves any favors by being ignorant of it. It's very basic basic background knowledge.
I meant to say they do not need to be great beyond basics like using wild cards, and simple Inclusion and exclusion syntax. That’s probably more than 50% of time all you need on that side of he world
Re: Regular Expressions – Mastering Lookahead and Lookbehind
#78Earlier quoted context omitted.
A programmer saying they are terrible at regex is like a mathematician saying they are terrible at algebra.
You are so right! How could you possibly go out of practice in real-time biomedical algorithms engineering when you might use them one or two times out of the year?! I must have missed the memo where all those strings are encoded in a patient's hemodynamic signal. There are few people more frustrating to algorithms engineers and embedded engineers than people like you who think you are the only type of programmers ou…
Re: Regular Expressions – Mastering Lookahead and Lookbehind
#79Earlier quoted context omitted.
You are so right! How could you possibly go out of practice in real-time biomedical algorithms engineering when you might use them one or two times out of the year?! I must have missed the memo where all those strings are encoded in a patient's hemodynamic signal. There are few people more frustrating to algorithms engineers and embedded engineers than people like you who think you are the only type of programmers ou…
I agree. If I ever need to use regex, I will dive in, but I don't mainly write software to process text. I mainly write control software for various things like subsea oil wells, oil rigs, gas turbines etc. It is enough for me to know it exists. I try to spread myself thin and broad, and then that gives me the control of which areas to dive deep, depending on the task at hand.
Re: Regular Expressions – Mastering Lookahead and Lookbehind
#80Earlier quoted context omitted.
I use a regular expression maybe a couple days out of the year; it seems they don't come up very often in real-time biomedical algorithms engineering. I'm sure most embedded programmers feel the same way.
All programmers' text editors include search/replace with regex and external filter commands (of which many of the often used are regex-enabled). If the biomed or embedded programmer deliberately does not make use of that functionality, he is inefficient.
I'm finding these comments hilarious. No true programmer!