Yeah I don't understand what value this library provides. It's just additional indirection, not a proper abstraction any different than the regex APIs it's calling under the hood.
I know you're meme-ing, but it's a great way to put it tbh. This library struck a nerve with me today because it's a rare example of a library that's actually harmful to its intended beginner audience. The author invented a verbose DSL for what's already a DSL!
For the record, I'd never fault anyone for writing any code they want (unless maliciously ofc). "What would a method-based interface to regular expressions look like?" is a perfectly reasonable question! But the author is doing a disservice to anyone he gets to use this. Just use ''.match().
It is supported by most languages with special syntax because string manipulation is still important. The native support matters due to optimisations present that are peculiar to the runtime. Most any developer can understand your regular expressions, or they know who to ask. You need to know it if you expect to use shell tools.
It's just like SQL: sure SQL is missing modern features and modern syntax, but at least once you've learnt it you can use it for debugging, performance, administrative tasks, reporting systems, dev tools, and your future projects that use another language.
Why assume trolling? The sentiment that regex sucks is one shared with a very large population. At least to me, it's this kind of terrible "write-once" maintenance hell language that really ought to be wiped off the face of the planet.
Its only redeeming feature is that it's fast (assuming you don't use the wrong features - lookaheads can cripple performance). Looking for alternative abstractions is very worthwhile. I'm not suggesting throwing away the existing regex engines, just abstracting away the ugliness. Whether this solution is the right one is debatable.
You can draw a comparison with SQL. Lots of projects nowadays hide SQL behind an ORM, only using SQL when a very complex query needs to be written. I'd expect something similar for Regex would help maintainability of lots of projects.
This whole library is troll and people are trolling with it.
This:
new Matcher().find('Reg').anyWhitespace().capture((expr) => { expr.find('Exp') }).test('Reg Exp')
vs:
'Reg Exp'.match('Reg\s(Exp)')
> Its only redeeming feature is that it's fast (assuming you don't use the wrong features - lookaheads can cripple performance). Looking for alternative abstractions is very worthwhile.
First, it's not particular features of regex that are "slow", but the whole notion of backtracking that's central to how they work! Further, regexes are just a translation of a fundamental mathematical model. In university they even had us translate between finite state machines and regular expressions on tests. In short, any "alternate abstraction" you're looking for is going to be literally the same thing, just wordier, because you're talking about something fundamental in computer science.
That’s literally why I said we shouldn’t trash regexes. It’s not thenidea that sucks. It’s the syntax. The abstraction of the state machine. That’s what sucks. Shorter is not better. Something wordier that’s easier to understand would help alleviate the maintenance burden.
I think at this stage, the idea is to get feedback on how to improve it, or maybe what to change completely, not saying "recommend this to all newbies to learn instead of regular expressions". I'm just guessing because it seems to be 4 hours old.
Maybe for the purpose of a more interesting discussion, let's just assume everybody knows (how to look up the docs for) regular expressions, but sometimes they're still lazy or just feeling playful, and want to do the same stuff with a different syntax... and this is just one first prototype of how maybe to do that. No offense intended, no claim that this will supersede learning regular expressions implied.
The code written with this is probably going to be a lot easier for people to read that a raw regex. Never forget that code is read many time more often than it is written.
Indeed! In fact, the library author cites this as one of the "main advantages" of their library (under "Getting Started"):
> As you can see one of main advantages of using this library is ability to document every line of code without any hassle.
In other words, the 'x' flag. Though it turns out JavaScript doesn't provide the x flag, but it's the same thing as string concatenating a regex across different lines.
The fact that the author includes the warning "Never-ever add a semicolon if you want to continue expression" on a method chain shows the level of sophistication this library is intended for.
Actually, I think this library could provide a security benefit since generating code by string concatenation is generally dagnerous. Analogous to generating HTML or SQL -- safer to use a library than to construct it yourself.
