What's wrong with JavaScript's regular expression notation?

I was reading Douglas Crockford's web page, JavaScript: The World's Most Misunderstood Programming Language, and I couldn't help but notice that, under Design Errors, he mentions "the notation for literal 开发者_运维问答regular expressions." What exactly is he talking about? What's wrong with JavaScript's notation for regular expressions, and why?

Might have to do with the fact that it enforces you to escape / characters, perhaps he wanted a more unique character to use as the notation.

/test// is invalid, while /test\// is a valid regex.

Whereas in some languages you can actually specify the denotion character in a string, eg:

$regex = '#test/#';

Where # symbols do the denotion.

I could imagine that the regex literal notation is a hindrance for evolving the regex engine decoupled from the language specification.

If all regexes were strings, they were always valid at the language level, and the regex engine could interpret them more freely.

But that's just a guess. I have no idea what Crockford meant with his statement.

Personally I find regex literals rather helpful. The are a lot less verbose than the new RegExp(pattern, flags) alternative with its need to adhere to both regex escaping and string escaping rules ("Path\\\\with\\\\backslashes", anyone?). I can't see the huge benefit for this notation, other than for dealing with dynamic regexes.

He really isn't very clear on what he means by semicolon insertion being a mistake. Perhaps he means semicolons as statement delimiters. If that's the case, I disagree. Without semicolons code obfuscators/minifiers don't run on your code.

Possibly messed up with slashes used for comments and division per this or because "they should be one line with no white space or commentary inserted to it" per this.