Hacker News Reader

Comment by pwdisswordfish4 | Hacker News Reader

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.

View on HN

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/

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

> 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?

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).

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?

Reply on news.ycombinator.com