3 ms·

So we're replacing a universally understood syntax for a new one that was just invented, and is painfully verbose? I understood what the first regex was doing j

So we're replacing a universally understood syntax for a new one that was just invented, and is painfully verbose? I understood what the first regex was doing just fine. This is a major step up in readability, so it's nice, and you have to invent a new syntax to do that, so I'll chalk that up as unavoidable. But did it have to be so verbose? SCSH/irregex's SRE had similar readability wins, with way less verbosity. You still have to learn a new syntax, though.

hiddenkrypt 10y ago
I'd be happy to get a translator that goes the other way, to help decode unfamiliar regex. Other than that though, I pretty much agree with you.
- helb 10y ago
  Not really translators, but can be quite useful sometimes – https://regex101.com/ https://regex101.com/ and http://regexr.com/ http://regexr.com/
  - Klathmon 10y ago
    Whenever i need to do anything in regex, i open regex101. It's such a great resource.
  - okonomiyaki3000 10y ago
    Nice tools. I often use https://regexper.com https://regexper.com
- riboflava 10y ago
  Wasn't this a goal of Light Table, or am I up in the night? There are a lot of useful representations I'd like to see for my foo, but very few of them I'd actually want to work in directly when I'm creating or modifying the underlying code representation. I could see this tool as a quick and useful way to load a complex regex meaning in my head like doc text, but after that, I'll just prefer to work with the regex directly instead of the verbose text.
  - qwertyuiop924 10y ago
    And I think SRE is a good middle ground. Plus, you can use paredit on it.
throwaway2016a 10y ago
While I agree that this is verbose to the point of almost being absurd, the regex syntax is far from universal. There are several different variations that are different in annoyingly subtle ways.
- qwertyuiop924 10y ago
  How so? The differences between PCRE and Python RE are negligable, and cannot be confused for any syntax in the other. Most people use ERE with only the most commonly implemented PCREisms in any case. And BRE is different enough that it's usually detactable right off the bat.
  - throwaway2016a 10y ago
    If you don't switch between them frequently enough it can be very difficult to deal with. For example, when doing a search in vim I often confuse what needs to be escaped and what doesn't vs a grep. And the escape syntax between perl compatible regexs and mySQL regexs are significantly different. They are subtle but they can cost valuable time while mentally context switching between them.
    - qwertyuiop924 10y ago
      The first is BRE vs ERE. Honestly, just use egrep. It behaves more in the way you'd expect. I'm not really sure what so different about the escape syntax in mySQL. But I'm sure you know.
      - throwaway2016a 10y ago
        mySQL regex is a bit of a nightmare. It contains a lot of character classes that can be confusing if you don't use them often. I guess "escape syntax" is the wrong phrase. http://dev.mysql.com/doc/refman/5.7/en/regexp.html http://dev.mysql.com/doc/refman/5.7/en/regexp.html
        10y ago
mVChr 10y ago
Indeed, and following their lead, I created SBFL (Simple Brainfuck Language) since most find the original specification too esoteric. So instead of writing this Hello World program in Brainfuck: ++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++. You can instead have this much more readable version: increment byte increment byte increment byte increment byte increment byte increment byte increment byte increment byte jump forward if zero increment pointer increment byte increment byte increment byte increment byte jump forward if zero increment pointer increment byte increment byte increment pointer increment byte increment byte increment byte increment pointer increment byte increment byte increment byte increment pointer increment byte decrement pointer decrement pointer decrement pointer decrement pointer decrement byte jump backward if zero increment pointer increment byte increment pointer increment byte increment pointer decrement byte increment pointer increment pointer increment byte jump forward if zero decrement pointer jump backward if zero decrement pointer decrement byte jump backward if zero increment pointer increment pointer output byte increment pointer decrement byte decrement byte decrement byte output byte increment byte increment byte increment byte increment byte increment byte increment byte increment byte output byte output byte increment byte increment byte increment byte output byte increment pointer increment pointer output byte decrement pointer decrement byte output byte decrement pointer output byte increment byte increment byte increment byte output byte decrement byte decrement byte decrement byte decrement byte decrement byte decrement byte output byte decrement byte decrement byte decrement byte decrement byte decrement byte decrement byte decrement byte decrement byte output byte increment pointer increment pointer increment byte output byte increment pointer increment byte increment byte output byte
- qwertyuiop924 10y ago
  How about SCL?: include header file stdio.h, searching system paths first. describe function main that returns a value of type integer, and has argument of type integer argc, and argument of type pointers to pointers to characters argv. begin function body call function printf with the single argument of type string "hello world" with a newline appended. begin new statement. return the integer value 0.
rtkwe 10y ago
I bet there's a fair number of people like me who rarely have to use regex and because of that have to half relearn it each time I have to use them. A more verbose syntax is easier to work with for that because you're not fighting both the syntax and the semantics simultaneously.
ryporter 10y ago
I agree that SRL is painfully verbose. I'm fairly experienced with regexes, and I found the new syntax to be far less readable. A better (and much simpler) way to make the regex more readable would be to split its construction into multiple lines (possibly using separate strings that are concatenated and given meaningful variable names). I already find myself often creating regex substrings that are then used in the construction of multiple, related regexes.
- qwertyuiop924 10y ago
  And I think that SRE is far more readable than standard regex syntax, which is in turn more readable than SRL. SRE is lisp-like, though, so it's not for everyone.

hiddenkrypt 10y ago

I'd be happy to get a translator that goes the other way, to help decode unfamiliar regex. Other than that though, I pretty much agree with you.

helb 10y ago
Not really translators, but can be quite useful sometimes – https://regex101.com/ https://regex101.com/ and http://regexr.com/ http://regexr.com/
- Klathmon 10y ago
  Whenever i need to do anything in regex, i open regex101. It's such a great resource.
- okonomiyaki3000 10y ago
  Nice tools. I often use https://regexper.com https://regexper.com
riboflava 10y ago
Wasn't this a goal of Light Table, or am I up in the night? There are a lot of useful representations I'd like to see for my foo, but very few of them I'd actually want to work in directly when I'm creating or modifying the underlying code representation. I could see this tool as a quick and useful way to load a complex regex meaning in my head like doc text, but after that, I'll just prefer to work with the regex directly instead of the verbose text.
- qwertyuiop924 10y ago
  And I think SRE is a good middle ground. Plus, you can use paredit on it.

throwaway2016a 10y ago

While I agree that this is verbose to the point of almost being absurd, the regex syntax is far from universal. There are several different variations that are different in annoyingly subtle ways.

qwertyuiop924 10y ago
How so? The differences between PCRE and Python RE are negligable, and cannot be confused for any syntax in the other. Most people use ERE with only the most commonly implemented PCREisms in any case. And BRE is different enough that it's usually detactable right off the bat.
- throwaway2016a 10y ago
  If you don't switch between them frequently enough it can be very difficult to deal with. For example, when doing a search in vim I often confuse what needs to be escaped and what doesn't vs a grep. And the escape syntax between perl compatible regexs and mySQL regexs are significantly different. They are subtle but they can cost valuable time while mentally context switching between them.
  - qwertyuiop924 10y ago
    The first is BRE vs ERE. Honestly, just use egrep. It behaves more in the way you'd expect. I'm not really sure what so different about the escape syntax in mySQL. But I'm sure you know.
    - throwaway2016a 10y ago
      mySQL regex is a bit of a nightmare. It contains a lot of character classes that can be confusing if you don't use them often. I guess "escape syntax" is the wrong phrase. http://dev.mysql.com/doc/refman/5.7/en/regexp.html http://dev.mysql.com/doc/refman/5.7/en/regexp.html
      - 10y ago

mVChr 10y ago

Indeed, and following their lead, I created SBFL (Simple Brainfuck Language) since most find the original specification too esoteric. So instead of writing this Hello World program in Brainfuck: ++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++. You can instead have this much more readable version: increment byte increment byte increment byte increment byte increment byte increment byte increment byte increment byte jump forward if zero increment pointer increment byte increment byte increment byte increment byte jump forward if zero increment pointer increment byte increment byte increment pointer increment byte increment byte increment byte increment pointer increment byte increment byte increment byte increment pointer increment byte decrement pointer decrement pointer decrement pointer decrement pointer decrement byte jump backward if zero increment pointer increment byte increment pointer increment byte increment pointer decrement byte increment pointer increment pointer increment byte jump forward if zero decrement pointer jump backward if zero decrement pointer decrement byte jump backward if zero increment pointer increment pointer output byte increment pointer decrement byte decrement byte decrement byte output byte increment byte increment byte increment byte increment byte increment byte increment byte increment byte output byte output byte increment byte increment byte increment byte output byte increment pointer increment pointer output byte decrement pointer decrement byte output byte decrement pointer output byte increment byte increment byte increment byte output byte decrement byte decrement byte decrement byte decrement byte decrement byte decrement byte output byte decrement byte decrement byte decrement byte decrement byte decrement byte decrement byte decrement byte decrement byte output byte increment pointer increment pointer increment byte output byte increment pointer increment byte increment byte output byte

qwertyuiop924 10y ago
How about SCL?: include header file stdio.h, searching system paths first. describe function main that returns a value of type integer, and has argument of type integer argc, and argument of type pointers to pointers to characters argv. begin function body call function printf with the single argument of type string "hello world" with a newline appended. begin new statement. return the integer value 0.

rtkwe 10y ago

I bet there's a fair number of people like me who rarely have to use regex and because of that have to half relearn it each time I have to use them. A more verbose syntax is easier to work with for that because you're not fighting both the syntax and the semantics simultaneously.

ryporter 10y ago

I agree that SRL is painfully verbose. I'm fairly experienced with regexes, and I found the new syntax to be far less readable. A better (and much simpler) way to make the regex more readable would be to split its construction into multiple lines (possibly using separate strings that are concatenated and given meaningful variable names). I already find myself often creating regex substrings that are then used in the construction of multiple, related regexes.

qwertyuiop924 10y ago
And I think that SRE is far more readable than standard regex syntax, which is in turn more readable than SRL. SRE is lisp-like, though, so it's not for everyone.