Comment by yoz | Hacker News Reader

Comment by yoz | Hacker News Reader

Sure, it's much easier to read, especially when it comes to finding and understanding a two-character diff in a 50-char regex.

Sure, I get the benefits of type safety.

Sure, it'll save me time debugging when I accidentally create an invalid regex.

But what am I meant to do with all that time saved? Read a book? Write more code? I don't get it. Let me waste the time on a ludicrously arcane syntax where I spend half the time looking at every bracket trying to understand if it's a control character in that particular context, because the ego trip I get from mastering this ridiculousness is HUGE!

(Yes, I understand regex syntax. I've been able to explain the phrase "zero-width negative lookbehind assertion" for the past twenty years. I inhaled the Friedl book and got utterly high on the idea that the awesome power of regular expressions - which are genuinely great in how they ease flexibility in accepting input - is entwined with their completely inhuman syntax. But I was wrong.)

Verbose does not ‘easier to read’ make; especially when you don’t know whether ‘anythingBut’ means (?!...) or [^...].

Type safety is nice, sure, but it’s a rather small benefit in this case. It doesn’t mean abandoning commonly-understood syntax is worth it. Most regular expressions are short enough to make errors visible with the naked (or IDE-assisted) eye.

This library at best looks like a crutch for a deficient language (which Java admittedly is), and at worst an unnecessary obfuscation layer.

The "deficient language" is "regex" not Java.

Escape codes and special characters for regex semantics is a deficiency of the 1980s programming world, not Javam

They can be hard to read, but I don't think they are deficient, on the contrary I think they are very elegant

Stephen Cole Kleene was a brilliant mathematician and when he invented regexs in the 50s of the past century, he anticipated a lot of concepts that became popular in computer science, such as recursion (which he also founded as a branch of mathematics and computer science together with Alonzo Church, Kurt Gödel and Alan Turing)

Java on the other hand has some deficiencies here and there and it's not really a modern language free from old cruft

Is there any language 20+ years old without cruft?

Haskell? (30 years old)

Where are the Lispers when you need them? :)

Haskell absolutely has waaaay too much cruft. Have you read the 30 page articles recommending which extensions to use? Have you ever seen MTL? Read any documentation written by Edward Kmett?

Modules and libraries are not part of the language

Java,for example, can't have proper generics because at the bytecode level (the "real" Java) they are not supported, it can't have static constructors because it would break inheritance and they had to come up with static blocks, it has no support for static methods with the same signature of an instance method, because the call syntax doesn't differentiate a call to a static method from a call to an instance method, so the compiler can't tell which method is being called, etc. etc.

These are all consequences of the original choices taken 25 years ago when they designed the bytecode and the sintactic sugar over the bytecode, that still live with us today

IMO, the prevalence of libraries like MTL, or with poor documentation, is a consequence of design decisions as well — maybe not of the abstract language, but at least of the primary implementations.

> (?:[a-z0-9!#$%&'+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'+/=?^_`{|}~-]+)|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])")@(?:(?:[a-z0-9](?:[a-z0-9-][a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-][a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])

Such elegance.

Might as well write code in machine code while we're at it.

That's like complaining that you can write ugly code in any language. The problem isn't the regular expression, it's that email addresses, while they technically may form a regular language (not sure if they 100% do), are an insanely complicated such language and not a very nice one.

How would you write a specification for that language in any other way that was more elegant? Sure, you could make it more verbose, but that wouldn't make it easier to understand the whole of it, or why it is the way it is.

Almost every RFC writes their grammars in some form of BNF not in regular expressions. RFC are written to be understandable.

> Sure, you could make it more verbose, but that wouldn't make it easier to understand the whole of it, or why it is the way it is.

Absolutely it would. The way to understand a large thing, is to understand the smaller components and then put them together. Regular Expressions to do not compose well.

> Regular Expressions to do not compose well.

That is patently untrue. Regular expressions compose under a number of important mathematical operations, such as union, intersection and concatenation. If your PL supports string interpolation, it's trivial to compose them in these ways (well ok, maybe not intersection). Nobody says that your regex needs to be written as a single string.

Elegant regexes are almost unheard of in real world no matter if it's e-mail or anything else.

Principia Mathematica wants a word in private

P.s. do you realise how much harder it would be to understand the same thing in machine language?

I think having an EBNF like syntax would be nice. It’s verbose, but (IMO) fairly unambiguous. A side effect would be the ability to define variables (I.e. terms) within the expression

Yeah; I'd rather have proper multiline strings in Java and a regex documented with the COMMENTS flag set. What I don't need is a regex builder. Or SQL builder, for that matter.

I think java has (or is getting) multiline stings now.

Java got them in the most recent version 15: https://openjdk.java.net/jeps/378

This took them way too long for how easy it is to add and how many headaches it would prevent.

They don't want to bloat language with million of rarely used syntax and hard to read features, just as Go devs do. Not to repeat the failure of Scala (and I'm afraid Rust goes the same way).

> Verbose does not ‘easier to read’ make

Java is founded on the opposite principle, I think.

That you can make things hard to read even when verbose?

You don't like Java, I see.

This tool has little to do with Java, except that author decided to implement it in it. It's a regular expression composer. You could implement it in any other general-purpose language.

It already is. In 30+ of them. You can find them on: http://verbalexpressions.github.io/

Surprisingly it emits [^...]*

See: https://github.com/VerbalExpressions/JavaVerbalExpressions/b...

Well that’s terribly confusing. So .anythingBut(“a”).then(“a”) matches “a”?? That’s so far off from what I’d expect that when I read the example for a URL:

(...).anythingBut(“ “).endOfLine()

I defaulted to assuming endOfLine mapped to [^\n]*\n and was left confused about the whole thing. I’ll take simple rigorously defined grammars over someone’s attempt to embed English onto them any day.

Dang I really liked working with the streams package in Java STL.

I've been burned by Java specifics before but overall found it fun to dev on. Why don't you like it?

I've never had any problems writing and debugging regular expressions after I came across this: https://regex101.com

And since regexes are usually write-once, adding this complexity on top of them serves no additional benefit. If anything, it'd probably make it harder for the next guy to understand your code.

I bought RegexBuddy years ago and have loved it for debugging. However it only runs on Windows. Found regex101 recently and I think it's a great alternative (though I almost didn't check it out because the domain has SEO abuse site vibes).

Can you explain the SEO abuse vibes? I always felt it was a straight forward name. It's a site the provides the basics of regexes.

I think that's actually the problem. I'm used to domains that are very precise being used to host junk content. Most popular sites aren't so narrowly focused and/or have some brand-name-like domain.

Have you seen https://regexr.com? I've only come across it recently but I really appreciated the visual description of complicated regex, especially for interpreting someone else's work.

It's fun to write regex but it is absolutely miserable to read it. This looks like an improvement.

It is. For most parts regexes like "\d+" are ok, but when there is something more complicated I pull Verbal Expessions into a project. To these days reactions on CR were mostly positive or netural at worst. If it was built into the standard library I would probably use it instead of regex, but adding a new dependency and interfacing it with libraries that expect Java regex objects has its cost.

Regular expression defines graph, graphical representation looks like a better choice:

https://jex.im/regulex/#!flags=&re=%5E(%3F%3Ahttp)(%3F%3As)%...

Usage example — CSS Syntax Module Level 3 documentation:

https://www.w3.org/TR/css-syntax-3/#string-token-diagram

and JSON specification:

https://www.json.org/json-en.html

Have not found visual editor, made sample in quiver:

https://q.uiver.app/?q=WzAsMTEsWzIsM10sWzAsNl0sWzEsMCwiXiJdL...

Graphs may be more clear, but if we rule out visual editors, IMO this approach is still a net positive.

> Sure, I get the benefits of type safety.

It seems not ;)

It's as if your java-compiler would stop warning you on forgotten semicolons and would instead error out during runtime when it reaches the statement with the missing semicolon.

It's not your time saved. It's time saved not running the test suite, for example. An uncompilable regex is a category of errors that you can ban completely from your program. Like java bans syntax errors as a category of (runtime) errors. It's time saved as any developer will not break this in a way that is not a semantic error. It's time and mind saved not thinking about a whole class of errors.

Thank you for the clarification! To be clear: my post is sarcastic, and I was trying to say that this library looks like a significant usability improvement over traditional regex syntax.

Fortunately C++ won't suffer from this kind of problems since there, you can make your regex builder a constexpr!

(lol)

Saving time is not just about getting to use it elsewhere - you also save time fixing bugs and the harm they can cause.

Reply on news.ycombinator.com