11

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?

cherouvim
  • 31,725
  • 15
  • 104
  • 153
Sasha Chedygov
  • 127,549
  • 26
  • 102
  • 115

4 Answers4

9

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.

meder omuraliev
  • 183,342
  • 71
  • 393
  • 434
  • Very true, that's probably it. But what languages, besides PHP, actually let you specify the character? I have a hard time thinking of any, but that might just be because I hardly ever use regular expressions. – Sasha Chedygov Jun 20 '10 at 07:12
  • 3
    Yeah. Crockford's complaint was about 'overloading' the slash character, but I think his main concern was about the overloading in JS in general (I think!). For example, if you comment out blocks of code with `/*...*/` you can see what would happen if you tried to comment out `/0x[0-9a-f]*/.test(strMyString);` with that. There've been a bunch of times that I've had to use the RegExp() method of creating regular expressions because the literals were prone to errors. – Andrew Jun 20 '10 at 07:45
  • @Andrew Really? I see how it's possible, but I've never encountered that. – Justin Johnson Jun 20 '10 at 08:36
  • 2
    @Justin It's unlikely you'd run into that problem in real life very often, particularly if your IDE supports JS syntax highlighting. But I have run into that specific problem a couple of times and it was a real head-scratcher. Comment out all the JS on a page in notepad and see it die on working code you'd not touched in weeks. "Wha...? But that's not the problem. And it's ALL BEEN COMMENTED OUT!!" It's also guaranteed to happen to you if you embed some large, minimized JS framework (like jQuery) into your site's code base and then comment it out (e.g. to see how it loads without jQuery). Fun. – Andrew Jun 20 '10 at 09:57
  • 2
    @musicfreak The ["stream editor" sed](http://en.wikipedia.org/wiki/Sed) performs substitutions based on regular expressions, and lets you choose the delimiting symbol for substitutions. – Christian Semrau Jun 20 '10 at 10:32
  • I don't see how removing literal regex would fix the problem with comments. Wouldn't we run into the same issue if the code contained some string like this: var a = '/example.*/'; The way to think about / is more as an alternate quote char (like ` " '). – Kevin Seifert Aug 27 '13 at 18:01
1

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.

Tomalak
  • 332,285
  • 67
  • 532
  • 628
0

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.

Ebrahim Byagowi
  • 10,338
  • 4
  • 70
  • 81
0

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.

jamesmortensen
  • 33,636
  • 11
  • 99
  • 120
  • His complaint about semicolon insertion is that semicolons are "optional" and are therefore inserted. But the question is about the bolded portion on regex literals, not about semicolon insertion. – eyelidlessness Jan 02 '11 at 08:24
  • Thanks for your answer, but I was specifically asking about the part bolded in the question. – alex Jan 02 '11 at 08:25
  • I was confused :) It sounds like a rant to me. The author is merely making complaints without going into detail as to why he thinks JavaScript is poorly designed. – jamesmortensen Jan 02 '11 at 08:27
  • @jmort253, that piece isn't particularly good, but Crockford is one of the most knowledgeable ECMAScript evangelists out there and does a great deal of elaboration in talks he's given on the language. Almost all of his complaints are valid (and he explains in his "The Good Parts" stuff, which is worth looking up if you're interested), but some are off the mark. – eyelidlessness Jan 02 '11 at 08:32
  • semicolon => see http://stackoverflow.com/questions/1995113/strangest-language-feature/2003277#2003277 – NoxArt Jan 02 '11 at 08:47
  • @jmort253 Any obfuscator/minifier/compiler/checker that BREAKS without *optional* semi-colons is WRONG BY DESIGN and is not ECMAScript-compliant. Read: Therefor, any behavior may be introduced -- so get better tools :-) (I don't agree with Crockford on this issue and use ASI all the time -- however I can't accept "Use semi-colons because of poorly-designed software." All major web-browsers work correctly with ASI.) –  Jan 02 '11 at 08:57