> 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.
Regular Expressions – Mastering Lookahead and Lookbehind
41–50 of 85 posts
Re: Regular Expressions – Mastering Lookahead and Lookbehind
#42Earlier quoted context omitted.
But don't forget to point at the limitations. For example, you can't use regexps to match an arbitrary but equal number of nested opening and closing parentheses.
regex engines like PCRE can: ^(\((?1)?\))$
If it can then it's not "regular expressions."
Re: Regular Expressions – Mastering Lookahead and Lookbehind
#43Most 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.
When I was learning my way around regexes, I found a cheat sheet helped. I made my own - you can download it free from here:
https://www.cheatography.com/davechild/cheat-sheets/regular-...
Re: Regular Expressions – Mastering Lookahead and Lookbehind
#44Earlier quoted context omitted.
regex engines like PCRE can: ^(\((?1)?\))$
If it can then it's not "regular expressions."
Which is very computer-science-y approach, and totally uninteresting at that,
because the (?PARNO) syntax is still embedded in the same regexp engine for
any practical purpose or distinction.
If you didn't know, a regexp engine with capture groups is already stronger than what in formal languages theory is called "regular expressions".
Re: Regular Expressions – Mastering Lookahead and Lookbehind
#45Earlier quoted context omitted.
Regex is useful when you do lots of string processing, like in webdev. Outside of that, I've found uses to be very limited - certainly not worth the upfront time investment. (I mean, sure one can cobble together something that mostly works with a regex testing tool, but you need to either take a college automata course or work through the Friedl in detail to get a basic level of proficiency).
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.
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.
Re: Regular Expressions – Mastering Lookahead and Lookbehind
#46Most 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.
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 out there or that the programming you do is somehow superior(despite largely relying on math you learned at a decent secondary school).
Re: Regular Expressions – Mastering Lookahead and Lookbehind
#47Earlier 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.
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.
Re: Regular Expressions – Mastering Lookahead and Lookbehind
#48for those who find regex not very readable:
https://github.com/VerbalExpressions
// Create an example of how to test for correctly formed URLs
var tester = VerEx()
.startOfLine()
.then('http')
.maybe('s')
.then('://')
.maybe('www.')
.anythingBut(' ')
.endOfLine();
Re: Regular Expressions – Mastering Lookahead and Lookbehind
#49Earlier quoted context omitted.
Regex is useful when you do lots of string processing, like in webdev. Outside of that, I've found uses to be very limited - certainly not worth the upfront time investment. (I mean, sure one can cobble together something that mostly works with a regex testing tool, but you need to either take a college automata course or work through the Friedl in detail to get a basic level of proficiency).
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 expressions, having used maybe a dozen flavors of them over the last 20 years. Being snooty about how useful regular expression should be (in your opinion) to the work of every other programmer out there isn't going to change the experiences of those others. I maintain that for web development there are quite often uses, but for scientific software (which is what I do), embedded, non-web based CRUD/LoB, and many other applications - it's just not what it used to be.
EDIT: turns out I was mixing up the tone of your comment with that of bmn__ down below so I replied more belligerent than your comment warrented - no offense, I'm just going to leave it up regardless.
Re: Regular Expressions – Mastering Lookahead and Lookbehind
#50Most 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 think everyone who doesn't know regex should make learning regex a priority. (However, I find that lookahead and lookbehind in particular do not tend to come in handy very often. So maybe just make a mental note that this exists and then look it up when you need it.) Just learn the basics and maybe take a very quick look at the theory, finite automata (maybe the name puts people off, but its just a couple of circle…
I appreciate the sentiment same as you, but it is not quick to learn, because you'd either stop short or basically learn, well ... patterns, some for different usecases and categorize many different patterns that achieve the same, while the typical pupil has problems with simple arithmetic, calculus etc. already. So the question would be why the patterns aren't abstracted behind a nice composable gui [1]. Not to mention the confusion around the various ever so slightly differing applications.
Also, you don't wanna spoon feed students, they'll never learn to fish. You would indeed have to go as far as implementing a regex engine or implementing I don't know, a certain finite automate in regex. I'm kidding but all you could realistically achieve would be the usage of a catalogue like command-line-fu or stackexchange unless the whole thing fits in a broader cs syllabus/curriculum.
[1] lrovocative statement: sed and awk are breaking the "do one function and it well" idea of unix.