Hacker News Reader

> which matches things like -.2, 0.123, +0.1, etc. (floating point numbers, basically). This likely has bugs, since I haven't tested it ;)

The fact you can't come up with a regex and be sure it's correct answers your first two questions.

Regexes are incredibly useful, but the syntax is just a bunch of noise. This library turns it into self-docummenting code, which is incredibly valuable. Novices might prefer showing their regex-fu, but after you've spent a good chunk of your life reading and writing code, you value clear code more.

Under the hood, what's being generated is still a regex though. How can you be sure ANY code is correct, aside from testing it?

True, but your argument can apply to any sort of abstraction (e.g. using C instead of assembly or even assembly over 1's and 0's).

He's arguing that the nicer syntax is a valuable abstraction over regex's overly-complicated syntax, not that the syntax will be 100% the same as regex 100% of the time.

> How can you be sure ANY code is correct, aside from testing it?

Apparently, we can't. So, you really want to improve your odds of writing correct code at the first attempt by making the language work with you rather than against.

Replacing a bunch punctuation with code that reads like prose is one way.

> This library turns it into self-docummenting code, which is incredibly valuable.

The problem is that for anyone who knows how regexps work, this library provides an obfuscation layer. I personally prefer the free-spacing regexp support[1] found in a number of popular parsers. It lets you write a complicated regexp in small and/or indented chunks across multiple lines, including comments. This provides as much or more documentation than this "self-documenting" form and allows the full power of the regexp engine (which big regexps often seem to need). I've occasionally had to work out some pretty gnarly regexps, but when written in two-column code/comments form they end up being pretty understandable and maintainable.

[1] Example from the Ruby docs. IIRC, Python and a few other parsers have similar support: http://www.ruby-doc.org/core-1.9.3/Regexp.html#label-Free-Sp...

Well, it's part of Ruby's philosophy: provide clean, readable and understandable code.

I'm a huge fan of regular expressions and I love to discover new ones, try to improve my own, etc. But, it does not mean there isn't place for a human readable regex syntax, and I will definitely give it a try.

> Am I the only person who thinks that things like this are totally unnecessary?

Not unnecessary, “useless”, “kidding” are more appropriate words IMHO.

Where is named captures? Oh, you cannot. Well, ordinary $1 $2 $3? Oh, you cannot capture at all! How do you use back refs? Oh, you cannot? Wait, why the heck then you even need regexps?

There are problems with complex regexes, yes. But this silly toy is not the solution. For solutions look at Perl6's “regexps”, Perl6's Grammars (example down the thread), Perl5's Regexp::Grammars, look how Haskell do it with parser combinators. They are all light years ahead.

Ouch, thanks for the harsh words.

But yes, 1.2 will likely have named captures and back refs. It's a regex, so $1 etc come with turning it into a regex and doing matching.

OK then. But look at state of the art solutions I mentioned ;-)

Perl5's R::Grammars is doing it the same way you do — it generates one-big-scary regex. But this lib is nowhere close to what it can do.

For idea: it will provide fully parsed struct like {proto: 'http', domain: { all: 'www.exampe.com', subdomains: ['www','example'], tld: 'ord', ... }

You can do this with regex captures.

It's not $1="this", $2="that", it's a tree.

So, no, you cannot. And there're many more cool things you cannot

You know what? I agree with you that regexes are not that hard, but the main problem from my POV is the lack of a standard. Each programming language implements those in a similar but always so slightly different syntax.

If we could come up with some sort of high-level API for regexes we might end up in a better situation, given that this would make them effectively language agnostic.

And you could always revert to your platform's native option if there are some missing features on the API (Given that those type of things generally end up with a least-common-denominator approach)

Not true. Regexes have been around for a long time and there are a few standards -- POSIX basic, POSIX extended, and PCRE. Any language/tool worth its salt these days will follow one of these three implementations (usually it's PCRE as it's the most complete). It's usually older tools like awk, vim, find, etc. that have their own quirks -- they were created before these standards existed and so they generally follow extended regex but then introduce their own syntax for certain concepts (in vim, for instance, \<...\> does the same thing as \b...\b in PCRE).

Didn't you just make the previous commenters point, that regex implementations vary? Within those three there are variations too with the flags and how they implement word boundaries (either exclusion of word characters or inclusion of certain spacing chars)

I think the case that there are too many implementations is overstated. Almost everyone can get away with knowing only PCRE these days. Most programmers I've know don't even know that they're using PCRE, they just know they're using "regexes"

I haven't had the incentive to learn regexes well enough to understand why I have to escape random things in different languages and environments. And occasionally something will fail to work all my cases and I have to fall back on a non-regex way of matching.

I've generally found that my practice is basically "try regex; if it doesn't work after ten minutes of effort, abandon regex completely".

Library owner here!

> Am I the only person who thinks that things like this are totally unnecessary?

No, it's been made clear to me that my library is totally unnecessary by quite a few developers. I like it though.

> ^(-|+)?[0-9]*\.[0-9]+$

exp.float, and you only have to define it once.

totally unnecessary? The fact that solving problems with a regex is a common joke answers this question handily enough ("Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.")

I only use regex occasionally and, as such, typically need to refresh each time I go back to it.

Obviously you should choose the level of abstraction that fits your needs but I would love something like this if I did any ruby.

It's just an alternate syntax, trading verbosity for readability. Debating whenever it's necessary or not is bikeshedding.

Am I the only person who thinks that things like this are totally unnecessary? Is learning/reading regular expressions really that difficult for most people?

No, you're not the only one. I have a feeling that things like that massive regular expression that is meant to match RFC822 email addresses is part of the reason for the focus on this kind of "easy to use, human" regular expression interfaces. The problem is that that email matching regular expression is an extreme case that matches a whole bunch of things that MTAs/MUAs need to know about, but that most people, who are accepting email addresses in web forms, don't need to know about, like "email comments", the real name fields, bang paths, etc. 99.999% of email addresses are going to match something simple like ^\S+@[\w-.]+\.[\w-]+$, and you're going to pass that off to the MTA to parse and validate and bounce anyway. For example, most people should be more concerned with having decent bounce processing support rather than trying to make email address matching regular expressions.

For me, the biggest advantage of this sort of "library" approach is that instead of only being able to spedify regexes using literals you can treat them like other values in the language: you can name subregexes, you can create functions that combine or modify regexes, etc.

I'm not sure the "builder pattern" in the OP does this well though...

Thoughts on doing it better? The DSL is just a wrapper for the objects.

I may as well make one suggestion along these lines ( implemented in a similar JS library I whipped up not too long ago: https://github.com/wyantb/js-regex ).

Macros! https://github.com/wyantb/js-regex#macros

Given some named macro, whenever the user wants to use it, they use addMacro (or some analogous method).

Not to mention that if you "learn" regular expressions with this library, you'll become an expert at this library and useless with "regular expressions", which is just one more example of things that can result in your inability to learn and use other languages effectively.

Regular expressions are a pain, but I strongly believe that you shouldn't use abstractions unless you have at least a functional understanding of what you're abstracting.

For one thing I agree it's totally unnecessary. I also think that people who're not familiar with regex should stay away from them as far as possible. Or at least get some understanding on how regex is implemented, learning about finite automata is very helpful to the understanding of regex.

I was prepared to think this was totally unneccesary, but ended up thinking it's actually pretty nice.