Live data from Hacker News

Regular Expressions – Mastering Lookahead and Lookbehind

rexegg.com

71–80 of 85 posts

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#71

Is there regular expression to match regular expression?

No. One way to convince yourself of this is that regexp capture groups must properly nest: /())(()/ is invalid for example. Regexps famously cannot match balanced parenthesis.

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#72
post #7

Earlier 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…

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

#73

Most 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.

I absolutely unabashedly love Regex.

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
post #41

> 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 regexp syntax was devised for write-only programming at the terminal (at a time when a terminal was a physical object, not a window in your GUI).

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

#75
post #11

Earlier 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.

It's especially nicer in Ruby (which got it from Perl) where you can use whatever delimiters you like for regexes, with /abc/, %r"abc", %r{abc}, %r#abc# and so on all being equivalent, so you can just about always pick something that won't clash with the characters in your pattern (You can even use spaces as the delimiters, which looks terrible).

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#76
post #32

Earlier 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

That would be nice to have when working in Javascript, making code a lot more readable and easy to update.

Alas, we don't get such luxuries as named groups or static typing... Woe is me.

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#77
post #67
post #23

Earlier 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

Yeah, that's true. If you understand the quantifiers and matching groups, you basically understand regex. That's all I'm referring to. I'm not saying everyone has to be an expert on implementing them.

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#78
post #7

Earlier 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…

Well, maybe I think that the ability to use the search and replace function in a text editor is a foundational skill. Maybe you're a better programmer? I know programmers who don't even need to write code, but I wouldn't think they were good programmers.

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#79
post #72

Earlier 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.

[deleted]

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#80
post #47

Earlier 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.

What if needing to search and replace in the first place is inefficient? Also, what if that engineer is female? Is he still inefficient?

I'm finding these comments hilarious. No true programmer!

Post reply on HN