Live data from Hacker News

Regular Expressions – Mastering Lookahead and Lookbehind

rexegg.com

61–70 of 85 posts

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#61
post #49
post #34

Earlier quoted context omitted.

I’ve found otherwise. No single work day passes without me inspecting/converting/refactoring calls and complex expressions via regex. Tools define the way you think and create.

Right - and regex makes you think about function and variable names as strings, instead of as the higher level abstraction that an IDE with proper refactoring support lets you think. Regular expressions are not the right tool for that sort of work in 2018. Look, I used to write web application in the 1990's with vim on computers with video cards that didn't have X drivers for them. I'm well versed in regular expressi…

No offense taken. But I'm not sure if this is objective or an another point of view. I do not think in terms of strings; with regex I actually describe what syntax my writing has and use that for conversion. Obviously, I cannot manage random mixed-style codes or entire grammar that way (though some flexibility exists). But for a homogeneous style it is pretty simple -- imo simpler than getting used to yet another IDE with its can and cannot-s.

Since I may use 2-3 [non-web] languages at the same time, viable IDE options may go down to zero. I like how regex and other vim-specific features empower my typing enough to not use what constrains me in my toolset.

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#62
post #35

Earlier quoted context omitted.

I wrote a list of json keys that should be taken from a message and :‘ s/\(\S\+\)\s{0,}/t.\1 = message.\1;\r/g Hey, did you commit already? Still typing?

It looks like your quote characters might be messed up there? Anyway, to parse json on the command line one should just use jq.

Single quotes were modified by HN engine, right. It is not a command line (thinking of sed?), it is the middle of a source code in my editor. I have a json-parsed message and t is a target object.

  a b foo c

  t.a = !!message.a;
  t.b = String(message.b);
  t.foo = message.foo;
  t.c = tonum(message.c);

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#63
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 see many people treat regex as an in-app library and argue about that. But in fact it is a text processing tool. It is not important if you're biomed-dev with a honorable degree or web-dev from 'secondary school'. What is important is how you manage your code and constant data, which is mostly text that doesn't care who you are. How do you manage your code? What do you do if you understand that you need a module extraction? Documentation fixes? Managing any text includes non-trivial search and replace or specific tools, right? Either you know one of these, or you leave your mess as is. If former, you have to know something anyway. If latter, well... not much honor.

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#64
post #29

Earlier quoted context omitted.

Which version of RegEx? I've "learned" RegEx two or three times and then switched language/platform and had everything I previously learned no longer work reliably. You might think I am just talking about Microsoft's quirky implementation but even in the Linux-sphere it isn't consistent see: http://www.greenend.org.uk/rjk/tech/regexp.html You take a complex format string which was design to use the fewest characters…

That's an overstatement of the differences between various regex engines. They all follow the basic standards, with [] being character classes, () being submatches, * being "0 or more", + being "1 or more", etc. The two main differences between various engines are which characters are "literal" and which characters are "magic" (Vim's engine is particularly annoying here), and how to write the "convenience character c…

I generally include either \v or \V in my vim regex, at which point I no longer have to think about which characters are magic. I suppose this means that I agree that vim's default is annoying here, but imho vim more than makes up for that by making magic configurable.

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#65
post #29

Earlier quoted context omitted.

Which version of RegEx? I've "learned" RegEx two or three times and then switched language/platform and had everything I previously learned no longer work reliably. You might think I am just talking about Microsoft's quirky implementation but even in the Linux-sphere it isn't consistent see: http://www.greenend.org.uk/rjk/tech/regexp.html You take a complex format string which was design to use the fewest characters…

That's an overstatement of the differences between various regex engines. They all follow the basic standards, with [] being character classes, () being submatches, * being "0 or more", + being "1 or more", etc. The two main differences between various engines are which characters are "literal" and which characters are "magic" (Vim's engine is particularly annoying here), and how to write the "convenience character c…

> They all follow the basic standards, with [] being character classes, () being submatches

You've already described a feature which has different syntax in one of the primary regex dialects I use (Emacs).

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#66
post #37

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.

Regex's are awesome as a swiss army knife. Though in my experience, outside some edge cases where the format never changes (like matching a domain name in a URL) a regex is hell to maintain when you come back 3 years later. There is also always the fun of people trying (and failing) to use regex in emails.

.+@.+ seems to be the only one without too many false-negatives

Re: Regular Expressions – Mastering Lookahead and Lookbehind

#67
post #23
post #9

Earlier quoted context omitted.

Mobile programmers doesn’t need regex nearly as much as serverside

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

#68
post #26

A use-case for lookarounds that I often use is: grep -Po '(? Which also cuts out and prints the relevant part of the line. This saves a trip through cut, awk or perl. (-P is PCRE and -o is print only matched characters, which the lookarounds aren't a part of.)

Wow. I do this all the time, and the additional step of piping to sed never ceased to annoy me.

You've made my day.

Post reply on HN