3 ms·
To be honest this sounds like the very definition of "you solved the problem with regex, and now you have two problems". In essentially every language in exist
by Merad 4y ago
To be honest this sounds like the very definition of "you solved the problem with regex, and now you have two problems". In essentially every language in existence the question you're asking can be solved with a simple loop and perhaps 3-4 lines of code. In many languages it's easily expressed as a one liner, i.e. (with C#) `s.All(c => c == s[0])`.
I really don't get the love affair that some devs have with regex. In my 10 year career I think I don't think I've run into more than a dozen problems in a production system that _required_ regex to solve. When you're working with robust modern languages there's almost a solution other than regex that's significantly easier to understand + maintain, and probably a lot more performant to boot. Is regex useful for other things, especially cli stuff like grep and sed? Oh yes absolutely. But generally speaking I really don't want it in my code base unless there's no other choice.
- RadiozRadioz 4y ago10 years and a dozen problems? Conversely, I encounter pattern matching problems and use RegEx near daily. Both these perspectives are anecdata, neither are useful. > and probably a lot more performant to boot I highly doubt your home-grown pattern matching functions could beat the decades of optimization that have gone into RegEx engines, in anything but the most trivial of patterns (like the one demonstrated here). Creating your own ad-hoc pattern matcher instead of using the ubiquitous one built into your language is like the junior in the article re-implementing JOINs. Sure, you may be able to beat the engine occasionally on particularly simple patterns, but I guarantee you'll lose out overall. RegEx is not inherently slow, and it is definitely possible to maintain. See industries with serious text processing demands like bioinformatics, where Perl is still used extensively. They could not operate like they do if they shied away from RegEx like many developers seem to.
- pixelbath 4y ago> Creating your own ad-hoc pattern matcher instead of using the ubiquitous one built into your language GP was using LINQ, which is a first-class language construct in C#. I'll grant that it may not be _as_ optimized as Perl's regex routines, but it's hardly ad-hoc or slow.
- RadiozRadioz 4y agoYes, the linked example falls in the category of "particularly simple patterns" I mentioned. This strategy only works for such simple patterns; add in a single alternation with a common base and the naïve iteration strategy falls apart. Implementing a sensible algorithm to evaluate such a pattern would require much more code than a couple of brackets, would not benefit from RegEx caching, etc.
- Merad 4y ago> I highly doubt your home-grown pattern matching functions could beat the decades of optimization that have gone into RegEx engines On the contrary, the All() method used here (which is part of the .Net standard library) is literally just a loop that evaluates each item in the collection to verify that they all match the predicate function. It'll be able to check hundreds if not thousands of characters in the time that it takes the regex engine to initialize and parse the pattern.
- ttfkam 4y agoIt other words, you're not caching/reusing you regex patterns? I think I see the cause of one of your recurring performance problems.
- RadiozRadioz 4y agoInteresting how you conveniently ignored the second half of my sentence. I will paste it here: > in anything but the most trivial of patterns (like the one demonstrated here)