
SRL – Simple Regex Language - maxpert
https://simple-regex.com/
======
Drup
Regex combinators are a much better solution to that problem, for which I gave
various arguments here[1]:

\- You don't need to remember which regex syntax the library is using. Is it
using the emacs one ? The perl one ? The javascript one ? that new "real
language" one ?

\- It's "self documenting". Your combinators are just functions, so you just
expose them and give them type signatures, and the usual
documentation/autocompletion/whatevertooling works.

\- It composes better. You don't have to mash string together to compose your
regex, you can name intermediary regexs with normal variables, etc.

\- Related to the point above: No string quoting hell.

\- You stay in your home language. No sublanguage involved, just function
calls.

\- Capturing is much cleaner. You don't need to conflate "parenthesis for
capture" and "parenthesis for grouping" (since you can use the host's
languages parens).

[1]:
[https://news.ycombinator.com/item?id=12293687](https://news.ycombinator.com/item?id=12293687)

~~~
sillysaurus3
Personally, I use regexes _all the time_. Every day. I'm constantly typing
regexes into emacs and vim to do text manipulation. Sometimes a quick
:%s/\\(foo\|bar\\)d/baz\1/g, other times a :%v/function /d. I can't imagine
what it would be like if I had to write out "begin with either of (number,
letter, ..." I'd never get anything done.

For programming it could be nice. It's an interesting idea. But I've found
that good highlighting solves most of the problem. When I type "\\\\(" into
emacs, it immediately highlights that \\\\( in a different color, along with
\\\| and \\\\). That way you can differentiate instantly between capture
groups vs matching literal parens. Here's an example:
[http://i.imgur.com/b417O2o.png](http://i.imgur.com/b417O2o.png) That small
snippet would become way, way longer if you use a regex combinator. Maybe
good, maybe bad, but it's hard to read a lot of code.

Yeah, it's ugly. And there are a bazillion small variations between regex
engines. But for raw productivity, it seems hard to beat.

~~~
Drup
I think you misunderstand what "regex combinators" means. In particular, SRL
is _not_ regex combinators. TAForObvReasons in another answer posted this[1]
that would explain it to you.

[1]:
[https://groups.csail.mit.edu/mac/users/gjs/6.945/psets/ps01/...](https://groups.csail.mit.edu/mac/users/gjs/6.945/psets/ps01/..).

About your example ... on the contrary, it would become way _cleaner_ with
regex combinators. The string manipulation would be replaced with proper
composition and the escaping madness would disappear. For example

    
    
       (concat foo "\\|" bar "\||" baz) 
    

becomes

    
    
      (alt foo bar baz)
    

You seem to be familiar with elisp. The lisp family is particularly adapted to
combinators approach, please read the link above. :)

~~~
sillysaurus3
If you like regex combinators, check out the elisp "rx" library. You can end
up writing code sort of similar to the article's, with less emphasis on using
english grammar:
[http://i.imgur.com/iD34MqC.png](http://i.imgur.com/iD34MqC.png)

Combinators are very convenient and precise, but the tradeoff is that the code
is longer. And I have to look up what to write every time I want to write one.
But that's a personal bias.

Thanks for the reference. I'll study it.

EDIT: One of the good ideas in SRL is "if not followed by". There are too many
[not]ahead-[not]behind combinations to warrant special syntax for each of
them. I wonder if it could be streamlined, though?

------
draegtun
Barely touch regexes these days because for last few years I've been using
Rebol / Red _parse_ more and more.

Here's a _translation_ of the first SRL example in the parse dialect:

    
    
      [
          some [number | letter | symbol]                 
          "@"
          some [number | letter | "-" ]                   
          some ["." copy tld some [number | letter | "-" ]]
          if (parse tld [letter some letter])
      ]
    

And here's a full matching example:

    
    
      number: charset "0123456789"
      letter: charset [#"a" - #"z"]
      symbol: charset "._%+-"
      
      s: {Message me at you@example.com. Business email: business@awesome.email}
      
      parse s [ 
        any [
            copy local some [number | letter | symbol]
            "@" 
            copy domain [
                some [number | letter | "-" ] 
                some ["." copy tld some [number | letter | "-" ]]
            ]   
            if (parse tld [letter some letter])
            (print ["local:" local "domain:" domain])
    
            | skip
        ]   
      ]
    

Some parse links:

* [http://blog.hostilefork.com/why-rebol-red-parse-cool/](http://blog.hostilefork.com/why-rebol-red-parse-cool/)

* [https://en.wikibooks.org/wiki/REBOL_Programming/Language_Fea...](https://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Parse)

* [http://www.codeconscious.com/rebol/parse-tutorial.html](http://www.codeconscious.com/rebol/parse-tutorial.html)

* [http://www.red-lang.org/2013/11/041-introducing-parse.html](http://www.red-lang.org/2013/11/041-introducing-parse.html)

~~~
GordonS
I don't mind regular expressions myself, but this does look quite nice. Any
idea if this has been implemented for anything other than Rebol (which I'd
never heard of)?

~~~
rgchris
There was a Parse-inspired project for JavaScript, but I'm not sure to what
extent it was developed. There was also a Parse implementation in Topaz[1]
(which itself is implemented in JavaScript) but is as of now unfinished.

It'd be difficult to implement as tightly in another language that doesn't
have Rebol's (or a somewhat Lisp-like) free-form code-is-data/data-is-code[2]
approach. Rebol and its Parse dialect share the same vocabulary and block
structure that amongst other things: makes it easy to insert progress-
dependent Rebol snippets within Parse; build Parse blocks dynamically (mid-
Parse if needed!); build Rebol code from parsed data; develop complex grammar
rules very similar to EBNF[3]. The article linked above[4] (and now linked
again below :) does a good job of fleshing out these ideas and why it may
remain a unique feature for some time.

[1]: [http://reb4.me/tt](http://reb4.me/tt)

[2]: [http://rebol.info/rebolsteps.html](http://rebol.info/rebolsteps.html)

[3]:
[http://codereview.stackexchange.com/q/87716/46291](http://codereview.stackexchange.com/q/87716/46291)

[4]: [http://blog.hostilefork.com/why-rebol-red-parse-
cool/](http://blog.hostilefork.com/why-rebol-red-parse-cool/)

------
throwanem
I like how the marquee example is of how to do something you shouldn't be
trying to do [1] anyway.

In more general terms, if a regex is complicated enough that something like
this seems to make sense, the problem is that your regex is too complicated,
and you should fix that.

[1]
[https://news.ycombinator.com/item?id=12312574](https://news.ycombinator.com/item?id=12312574)

~~~
proactivesvcs
It's my observation that a lot of problems people have with regex is that they
haven't learned tips like "Is regex the right way to do this?", "Can I
simplify this regex because I trust the input?" and "What do I really need the
regex to do?".

To validate a user-supplied email address, you arguably just need something
along the lines of ^.@.\\..$ to help avoid whitespace and forgetting the @
sign. In a lot of cases, if the email address is wrong, all that happens is
either a) user login fails or b) user registration fails. Hence there's no
need for unreadably-complex regex to validate.

~~~
throwanem
> To validate a user-supplied email address, you arguably just need...

See the earlier discussion. It's not nearly so simple.

~~~
Accacin
I think what he's trying to say is the best test for a valid email is to send
them an email with a confirmation URL for the user to click.

------
adamjcooper
Consider changing "either of" to "any of".

The word "either" implies only two choices, making your opening example
confusing when the first "either of" was really picking from three
possibilities.

~~~
nailer
Also 'begin' is vague - it could mean start of word, here it means start of
line. Make it 'start of line'

I like the general approach, although the 2010-era BDD fake natural language
is a turn off.

~~~
pbhjpbhj
A really good shorthand for "start of line" is "^"

;o)

~~~
nailer
A really good shorthand for "yes, however it's not the most discoverable thing
in the world" is "& ^ ( ^ ^ % & ^"

~~~
pbhjpbhj
Is it less discoverable than the proposed alternative though?

In both cases one looks up the documentation, in one I find that search for
the line start requires a regex with "^" and in the other I find something
like "begin with" of Simple Regex Language (SRL). I still need to read (or
test) to find what "begin with" means and I still couldn't guess it - why not
"start with", "open with", "first character", or a myriad of other possible
options.

Whatever suits the user I suppose.

~~~
nailer
Since code is read more than it is written, how well do you think a colleague
without previous knowledge of regexs could understand '^' vs 'start of line'?

------
parenthephobia
I'm not absolutely sure this isn't a joke that got out-of-hand. This is the
COBOL of regular expressions. :)

Whilst the conventional regular expression syntax is arguably overly compact,
this is just too far in the opposite direction!

Something more PEG-like, or even Perl 6 regex-like, would make more more
readable regular expressions whilst not completely throwing out everything we
think things mean. Hell, even /x -- ignore whitespace and comments -- can make
things much clearer:

    
    
        / ^
          [0-9a-z._%+-]+           # The local part. Mailbox/user name. Can't contain ~, amongst other valid characters.
          \@
          [0-9a-z.-]+ \. [a-z]{2,} # The domain name. We've decided a TLD can never contain a digit, apparently.
        $ /x
    

Tangentally, there's no point validating email addresses with anything more
complicated than /@/. If people want to enter an email address that doesn't
work, they can and will. If you want to be sure that the address is valid,
send it an email!

~~~
comboy
> Tangentally, there's no point validating email addresses with anything more
> complicated than /@/

Well once you have this in database, maybe you'll give it to some library,
then maybe this poor little library will just paste it into the SMTP
conversation. And maybe some user will be clever enough to exploit it.

I believe that if you want to get X from the user, it's always a good idea to
make super sure that it is actually X before passing it further.

And I very much agree that whenever possible and necessary, simply splitting
regular expression to multiple lines and using comments seems like a superior
approach.

~~~
Retra
The point is not to parse email addresses with regex because an actual email
parser is far more appropriate for the task.

------
grondilu
My attempt at the Perl 6 version of the example:

    
    
        rx:i/^^
        [ <+ alpha + digit + [._%+-] >+ ] ** 2 % '@'
        '.'
        <alpha>** 2..*
        $$/
    

Notice that this avoids the repetition of a pattern.

Of course, it'd make much more sense to write a grammar:

    
    
        grammar Email {
            token TOP { <name> '@' <domain> }
            token name { <valid_char>+ }
            token domain { <valid_char>+ '.' <alpha>** 2..* }
            token valid_char { <alpha> | <digit> | <[._%+-]> }
        }

~~~
labster
Pretty good, though <domain> should end with <alpha> __2..*

Note that your version is not actually the same, as it accepts all alphabetic
characters, not just ASCII ones. Which put it much closer to RFC 6532, but
still not exactly there due to the quoting rules in usernames. Which get
pretty hairy. See [1] for an implementation of RFC 822, which is a simpler
version of the modern standard, for a regex to validate email in Perl 5.

[1]: [https://metacpan.org/source/RJBS/Email-
Valid-1.200/lib/Email...](https://metacpan.org/source/RJBS/Email-
Valid-1.200/lib/Email/Valid.pm#L390) trigger warning: bleeding eyes

------
codemac
If you dig the lisp lifestyle, check out SRE/rx/irregex. It is magical.

[http://www.ccs.neu.edu/home/shivers/papers/sre.txt](http://www.ccs.neu.edu/home/shivers/papers/sre.txt)

[https://github.com/ashinn/irregex](https://github.com/ashinn/irregex)

[https://github.com/scheme/rx](https://github.com/scheme/rx)

[http://srfi.schemers.org/srfi-115/srfi-115.html](http://srfi.schemers.org/srfi-115/srfi-115.html)

~~~
qwertyuiop924
Yes, I was talking about this. Irregex is much better than RX, nowadays,
however. Shinn did a really good job.

------
glangdale
We (the Hyperscan team) have spent a lot of time staring at regular
expressions over the years (shameless plug:
[https://github.com/01org/hyperscan](https://github.com/01org/hyperscan)).

I think a better format for regex is long overdue, but this isn't it. It's way
too verbose (other commentators also noticed the resemblance to COBOL). I'm
picturing a Snort/Suricata rule with this format regex, and you've now doubled
the amount of screen real estate per rule.

The real problems with regex readability are (1) the lack of easily grasped
structure, so it's almost impossible to spot the level at which a sequence or
alternation operates (PCRE's extended format and creative tabbing can help)
and (2) the total lack of abstraction - so if you have a favorite character
class or subregex you write it approximately a bazillion times.

~~~
SonOfLilit
I'd love to hear your feedback on my approach, that focuses on the kind of
problems I read in your comment.

[http://www.slideshare.net/AurSaraf/re3-modern-regex-
syntax-w...](http://www.slideshare.net/AurSaraf/re3-modern-regex-syntax-with-
a-focus-on-adoption)
[https://github.com/sonoflilit/re2](https://github.com/sonoflilit/re2)

------
PieterH
What's missing in regexps IMO is composability so you can build larger
patterns out of smaller ones, giving each a clear name. Replacing '[0-9]' with
'digit' doesn't really help much.

------
kazinator
Sane middle ground:

    
    
      $ txr
      This is the TXR Lisp interactive listener of TXR 147.
      Use the :quit command or type Ctrl-D on empty line to exit.
      1> (regex-parse ".*a(b|c)?")
      (compound (0+ wild) #\a (? (or #\b #\c)))
      2> (regex-compile *1)
      #/.*a[bc]?/

~~~
qwertyuiop924
I think SRE is a bit nicer than TXR's regex format, but it's the same idea.

------
chubot
I designed a similar but terser language in 2012:

The examples give the gist: [http://chubot.org/annex/cre-
examples.html](http://chubot.org/annex/cre-examples.html)

More justification:
[http://chubot.org/annex/intro.html](http://chubot.org/annex/intro.html)

doc index: [http://chubot.org/annex/](http://chubot.org/annex/) (incomplete)

I showed it to some coworkers in 2013 and got some pretty good feedback. Then
I got distracted by other things. One of the issues is that I learned Perl
regex syntax so well by designing this language that I never needed to use it
again :)

I plan on coming back to it since I'm writing a shell now, and I can't
remember grep -E / sed -r syntax in addition to Perl/Python syntax.

SRL is the same idea, but I think it is way too verbose, which it appears a
lot of others agree with.

If anyone is interested in the source code let me know! It was also
bootstrapped with a parsing system, which worked well but perhaps wasn't
"production quality". So I think I will reimplement CRE with a more
traditional parsing implementation (probably write it by hand).

------
kazinator
COBORE: common business-oriented regex.

Bonus: COBORE -> (Japanese) kobore -> こぼれ -> 溢れ/零れ ("spillage").

"Overflowing spillage of verbosity."

~~~
qwertyuiop924
Kaz is right.

Now if only I made this joke first...

------
PieterH
Looks like the COBOL of pattern matching, and frankly I like it.

------
SonOfLilit
I have a (mostly abandoned) side project with the same aim. I spent a lot of
time thinking about language design, from the perspective of enabling adoption
of a new language when an existing one has so much network effect:

[https://www.slideshare.net/AurSaraf/re3-modern-regex-
syntax-...](https://www.slideshare.net/AurSaraf/re3-modern-regex-syntax-with-
a-focus-on-adoption)
[https://github.com/sonoflilit/re2](https://github.com/sonoflilit/re2)

If people like my direction, I may continue to work on it.

------
keithnz
Maybe this as a learning tool? I think it's much better to learn regex as is,
no matter how ugly or terse you may or may not find it. It's pretty universal
across languages ( with some annoying variations ). There's lots of online
tools and programs that can help you decode or create regex, after a while
it's not so hard to read/create. But also worth knowing a more comprehensive
parsing tool or parsing techniques so you don't get too ambitious with regex
:)

------
WhitneyLand
I fully appreciate the problems with regex, but I don't think this is the
right approach.

If you have fantastic tooling regex can actually be a pleasure

Unfortunately the best regex helper ever made seems to still be an old Windows
app. But wow is it good:
[https://www.regexbuddy.com](https://www.regexbuddy.com)

I've seen online tools but they never seem to measure up.

~~~
laurent123456
Jan Goyvaerts, the author of this program also created this great website [0],
which has lots of very clear and detailed regex tutorials. I always come back
to it when I get confused about regular expressions.

[0] [http://www.regular-expressions.info/tutorial.html](http://www.regular-
expressions.info/tutorial.html)

------
nnq
Side note on the API of the PHP lib implementing this: could we please stop
using the fluent/query-builder pattern with closures?

It's the most disgraceful code style I've seen, and misleading: makes you mind
think smth. async could be happening. I know Laravel popularized this, along
with other ugly patterns, but let's stop cargo-culting this.

------
slantedview
Something similar:

[http://verbalexpressions.github.io/](http://verbalexpressions.github.io/)

------
0xCMP
I think this is really valuable. Just today I had a non-tech co-worker who
needed to understand Regex for some tool we were using. I did the regex for
him and (very briefly) explained it. Now this might be something he can more
easily grok and use a translator (+ regex101.com to verify) to create more
complex regex's he might end up needing.

------
buckbova
Sometimes it's difficult to reason out an involved regex. I doubt I'd ever use
something like this from code but I might use the translator.

Example based on their example.

[https://simple-regex.com/build/57bc5eac74c4d](https://simple-
regex.com/build/57bc5eac74c4d)

------
junke
See also:

 _Is there a specific reason for the poor readability of regular expression
syntax design?_

[http://programmers.stackexchange.com/q/298564/33157](http://programmers.stackexchange.com/q/298564/33157)

------
ajarmst
Demonstrative "that" adjective-connective-subjective "seems" infinitive-marker
"to" verb-existential "be" verb-passive-gerund "missing" article-definite
"the" noun-subject "point".

------
DonaldFisk
If you're dissatisfied with the terseness of regular expressions, it's worth
looking at SNOBOL4: [http://www.snobol4.org/](http://www.snobol4.org/) which
has been around for decades.

~~~
qwertyuiop924
SNOBOL, AWK, and TXR are all pretty cool: Pick your swiss army knife.

------
Grue3
Reminds me of regex parse trees in CL-PPCRE. S-expressions are the simplest
language of all! [1]

[1] [http://weitz.de/cl-ppcre/#create-scanner2](http://weitz.de/cl-
ppcre/#create-scanner2)

------
matt_wulfeck
The author pits his project against _POSIX_ regular expressions, but
personally I feel that it's PCRE that rules the day. I find pcre regex
significantly less verbose and easier to read.

------
onetwotree
Hmm, perhaps useful for a teaching tool.

If used as such, it'd be really nice to be able to go the other way - a regex
explainer if you will.

~~~
danso
That's what I was thinking too. It'd be a great way to get people to
understand the power of regex. But yeah, I wouldn't want to learn a verbose
language to use regexes as frequently as I do today.

------
edtechdev
Very nice. Would love to see versions in other programming languages.

I'm very interested in examples that extrapolate this idea to other areas of
programming and even math. And also work in the reverse direction.

Most of the examples I've found are old or not open source.

another example of english to regex:
[https://people.csail.mit.edu/regina/my_papers/reg13.pdf](https://people.csail.mit.edu/regina/my_papers/reg13.pdf)
[https://arxiv.org/abs/1608.03000](https://arxiv.org/abs/1608.03000)

English to dates
[https://github.com/neilgupta/sherlock](https://github.com/neilgupta/sherlock)

English to a graph (network representation)
[https://github.com/incrediblesound/MindGraph](https://github.com/incrediblesound/MindGraph)

C to English and vice versa
[http://www.mit.edu/~ocschwar/C_English.html](http://www.mit.edu/~ocschwar/C_English.html)

English to python:
[http://alumni.media.mit.edu/~hugo/publications/papers/IUI200...](http://alumni.media.mit.edu/~hugo/publications/papers/IUI2005-metafor.pdf)

English to database queries [http://kueri.me/](http://kueri.me/)

------
qwertyuiop924
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
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
Not really translators, but can be quite useful sometimes –
[https://regex101.com/](https://regex101.com/) and
[http://regexr.com/](http://regexr.com/)

~~~
Klathmon
Whenever i need to do anything in regex, i open regex101.

It's such a great resource.

------
colanderman
The first example:

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

is a total strawman, needlessly obfuscated. How about writing it like this:

    
    
        /^[0-9a-z._%+-]+@[0-9a-z.-]+.[a-z][a-z]+$/i
    

which, while "scary looking", is at least immediately readable by anyone who
knows even the basics about REs. If the argument for "verbose REs" is valid,
it ought to stand up at least a _typical_ standard RE.

Also, it's not clear that "letter" and "[a-z]" mean the same thing. Does
"letter" include uppercase? Does it include non-ASCII letters like
"[[:alpha:]]" does? Don't forget the weird collation behavior "[a-z]"
sometimes encounters.

~~~
Twisell
> which, while "scary looking", is at least immediately readable by anyone who
> knows even the basics about REs

Nope, I'm mostly a DB guy very fluent in SQl and I use regex like two dozen
time a year.But every time I nead to write something not trivial I must run to
a regex cheatsheat website and spend long minutes trying to figure shit out.

It's not that I'm dumb and taking a MOOC about regex is definitely on my todo
list... It's just that I haven't found the damn time yet to learn monstrosity
and exceptions of regex.

And this is especially painful coming from PostgreSQL which have a good
debugger and a clear syntax (even for non standard functions).

~~~
pbhjpbhj
FWIW I'm doing the Accessing Web Data part of the Python for Informatics
course at Coursera. First part of that course is regex and after one lesson
(~15 mins) it covers enough to read the above expression.

I was already cognisant with regex, so I'm perhaps biased, but a simple email-
like search seems easy for a novice to read.

Perhaps you have a particular block when approaching regex. The book by
Charles Severance that goes with the course (above) is freely available
online.

------
lucio
great work, nice site! There's a huge amount of programmer's time lost
worldwide reading Regex expressions and trying to determine what the
expression do. This a way better option for readability.

------
koytch
Zounds, now that programming languages basically scrapped the idea to sound
like English, regular expressions pick it up from the trash. And emulate
Applescript of all, if I am any judge.

------
yegortimoshenko
AppleScript, SQL, COBOL and others have all made the same mistake.

------
antiquark
Cool, it's like COBOL for regexes. Now even managers can write them!

------
malkia
Anyone remembers: South. South. West. Look. Pick axe.

for the same reasons I'm having mixed feeling about cucumber and similar
testing frameworks (BDB), that also rely on semi-english language to do
things. It looks cool, and enticing, but hard to sell (to others), even If I
myself am super-excited to see it in action (just because how crazy it looked
the first time I saw it).

------
soci
Looks like applescript, easy to read, impossible to write

------
VMG
This is really cool. I'm sure it can be improved, but a nicer high-level DSL
for regex is something I have been looking for a long time now. Combinator
libraries are nice but language-dependent.

------
crdoconnor
My attempt at simplifying (a subset of) regexes:

[https://github.com/crdoconnor/simex](https://github.com/crdoconnor/simex)

------
EdiX
Because if there was one thing regexp needed it was COBOL.

------
_pferreir_
Don't take me wrong, but I think that if anything this makes regular
expressions harder to understand. The syntax is super verbose.

------
Eridrus
I'm no fan of regexes, but I'm not a huge fan of this either; I would be
interested in seeing existing convoluted regexes expressed like this for me in
an IDE, but I don't like it as an input format.

I do wonder if having an EBNF compiler like ANTLR being more accessible would
solve the readability & maintainability issues.

~~~
duiker101
I don't think anyone is really a fan of regex(es?) but the task they are for
is actually a rather complicated one and, let's be honest, they are pretty
good at it. I agree that it would be nice to see better tools to understand
and create new regex but I think that they are actually fine on their own.

They might be ugly and everyone had a point where they thought they were just
some sort of magic impossible to understand but I think that there is a point
where they just... click. After that they can still be ugly and messy but you
at least understand that there is a purpose to it.

------
Cozumel
'Regular Expressions Made Simple'

Regular expressions _are_ simple. It's just a matter of putting a bit of time
in to learning them.

~~~
xapata
Simple for various definitions of simple. Readable not included.

------
coroutines
Hey, remember that time we gave up regular expressions and went back to
writing grammars? Right tool for the job..

------
kabes
I hate languages that try to be like natural language, for the simple reason
that I can't actually use natural language. I can't type: "I want something
that has at least some letters at the beginning followed by an @ ..." or any
other variation except the exact syntax they require. Maybe in 10 years if NLP
has come far enough, but not when it's a simple parser like now. I think it's
much harder to remember than a syntax that is completely different from
anything else you know.

On the other hand, it did work for SQL...

------
tempodox
This definitely has some entertainment value. However, if you want to make
your code verbose, there is only one way to go. Use a language that needs just
the following statement to produce a valid program:

    
    
      TRANSFORM THE CURRENT OBJECT INTO THE DESIRED OBJECT.
    

Any other program statements are redundant.

------
rosalinekarr
This is really cool, but my brain keeps getting stuck on the word choice.
Every time I see the `literally` keyword, I hear a teenage, valley girl accent
in my head.

"Literally, at sign."

"Like, literally, hashtag, guys."

I can't even.

~~~
ryporter
And now that "literally" has been coopted to also mean "figuratively", I don't
even know what that clause means. I also got mentally stuck on that phrase,
and my eyes literally popped out of my skull.

------
Faaak
For the sake of pedanticity, the regex he proposed as an example doesn't
validate all possible email addresses (particularly ones that are simply
…@tld).

