Comment by hinkley | Hacker News Reader

Comment by hinkley | Hacker News Reader

Parent Full thread

I can't shake the feeling that Regexp could be written just as efficiently as a fluent interface with a more human friendly syntax.

I've been telling Jr devs bucking for promotion for years to explain what they're doing in plain english, then write code that looks like that. Basically telling them to skip right over the "gee look what a clever fuck I am" stage and write good code instead of creating riddles.

The Regexp problem just screams this at me. What am I doing? I'm looking for a line that starts with a capital T, then has some quantity of alphanumeric characters greater than n (if n is not 0, 1, or infinity, this requires extra work in Regex), followed by an equals sign with or without whitespace characters around it.

Give me an API that does exactly that, instead of Regex. Something gets lost in translation every time.

I think the fact that the origin of Regex is the command line interface is pretty telling. We didn't and we don't have a convenient way to type in imperative code on a command line. So an arcane syntax was created so you could do the whole thing in a quarter line of text.

Speaking as someone who has had a Unix shell for 25 years, and routinely works on mini tools for their fellow developers, I don't think we actually type stuff into a shell that often anymore. The difference between documenting a one-liner in a README and just building a shell script that does the same thing is not that big. There's a difference in development effort but building a script can allow you access to a debugger. Personally, I'd be willing to pay that tax any day.

> I can't shake the feeling that Regexp could be written just as efficiently as a fluent interface with a more human friendly syntax.

You can use SRL - Simple Regex Language (https://simple-regex.com/) for making readable regex/matching rules. It is supported in C++, Java, C#, PHP, Javascript, and Python. Also, you can use the web version to generate equivalent regex if your language is one of the above.

Here is an example from the website for matching an e-mail address:

  begin with any of (digit, letter, one of "._%+-") once or more,
  literally "@",
  any of (digit, letter, one of ".-") once or more,
  literally ".",
  letter at least 2 times,
  must end, case insensitive

Regex to do the same:

  /^(?:[0-9]|[a-z]|[\._%\+-])+(?:@)(?:[0-9]|[a-z]|[\.-])+(?:\.)[a-z]{2,}$/i

The first one is readable, second one is cryptic. https://simple-regex.com/examples has more examples.

SRL was previously discussed here in 2017, see https://news.ycombinator.com/item?id=12384862

Also, the parse feature (DSL) of Rebol language is an excellent regex alternative:

1. Why Rebol, Red, and the Parse dialect are Cool (http://blog.hostilefork.com/why-rebol-red-parse-cool/)

2. Rebol's answer to Regex: parse and Rebol types (https://rebol-land.blogspot.in/2013/03/rebols-answer-to-rege...)

Interesting, thanks for mentioning! Looks similar to VerbalExpressions (https://github.com/VerbalExpressions/JSVerbalExpressions/wik...)

Parsing combinators are the API you want.

    regexReplaced n = do
       char 'T'
       spaces
       x <- concat (replicateM n alphaNum)
       y <- concat (many alphaNum)
       spaces
       char '='
       return (x ++ y)

The above is a Haskell function that does the parsing required above, returning the alphanumeric characters if the parse succeeds and returning an error if it does not. You may not speak Haskell, but this is probably still more readable than (n) => {new RegExp(`T\s(\w{${n}}\w)\s*=`)}, which is the Javascript function that does a similar thing.

But are they as efficient as regexp? I personally prefer regexp combinators.

Optimizing them is a bit more work, but they can outperform hand-rolled C code:

http://www.serpentine.com/blog/2014/05/31/attoparsec/

> "I can't shake the feeling that Regexp could be written just as efficiently as a fluent interface with a more human friendly syntax."

You may be interested in the Parse dialect of Red:

http://www.red-lang.org/2013/11/041-introducing-parse.html

Also worth noting that Red can be embedded in any program that supports a C function interface, through using LibRed.

http://www.red-lang.org/2017/03/062-libred-and-macros.html?m...

I agree. That’s why I pointed out that a necessary addition to get more productivity out of writing custom parsers is

a) easy usability in shellscripts B) easy tooling for unittests

I started writing shellscript in kotlin, so i get the unittests for free

Reply on news.ycombinator.com