Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.teledata-fn.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <6563475.n3XdYolgyi@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Sat, 03 Nov 2012 10:19:05 +0100 User-Agent: KNode/4.4.11 Content-Transfer-Encoding: 7Bit X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. <1805042.BzeuYpbCYS@PointedEars.de> <7MidnYXvqeq8ggnNnZ2dnUVZ_uGdnZ2d@earthlink.com> <1466051.Cd1scNln3u@PointedEars.de> Followup-To: comp.lang.javascript MIME-Version: 1.0 Lines: 103 NNTP-Posting-Date: 03 Nov 2012 10:19:07 CET NNTP-Posting-Host: 1327d699.newsspool2.arcor-online.net X-Trace: DXC=>8J:CL6\R2mOKO]LCQ@0g`A9EHlD;3Ycb4Fo<]lROoRa8kFK`1P\^HX3IR7eg9gJ:RGAPMj X-Complaints-To: usenet-abuse@arcor.de Xref: csiph.com comp.lang.javascript:17026 [I had written a longer reply with examples, but apparently it has not reached Usenet. So I will keep this one shorter and expand on it upon request.] Patricia Shanahan wrote: > On 11/2/2012 2:10 PM, Thomas 'PointedEars' Lahn wrote: >> Patricia Shanahan wrote: >>> On 11/2/2012 10:41 AM, Thomas 'PointedEars' Lahn wrote: >>>> Patricia Shanahan wrote: >>>>> On 11/2/2012 2:22 AM, Evertjan. wrote: >>>>> ... >>>>>> if ( /foo/.test(someString) ) {..} >>>>>> >>>>>> I trust not understanding Regex is not a valid counterargument. >>>>> If I'm prepared to look at it long enough, I can generally work out >>>>> what a Regex does, but Regex does not seem to me to be a very >>>>> human-friendly, smoothly readable language. >>>> That depends on the flavor and your experience with them. >>> Well, I don't quite have 30 years of experience with regular expressions >>> yet, but it's getting close. >> Which flavors? > > Assorted UNIX shell tools (lex, grep, egrep, vi, ed, sed, awk etc.), > Perl, PHP, and Java. As I see it, implementations of regular expressions are lacking readability because of two factors: insufficient expressiveness and stringly typing. Insufficient expressiveness or excessive verbosity means you have to write longer expressions for rather simply concepts. Consider, for example, POSIX `[[:space:]]' vs. Perl/PCRE `\s'. Consider POSIX Basic Regular Expressions (BRE) `\{0,1\}' vs. POSIX Extended Regular Expressions (ERE)'s and Perl's/Perl-Compatible Regular Expressions (PCRE)'s `?'. Consider POSIX BRE `\{1,\}' vs. ERE's/Perl's/PCRE's `+'. Stringly typing, i. e. expressing data in string literals instead of in regular expression literals, causes regular expressions to be less readable, and in turn code that uses regular expressions to be less readable, due to the fact that string literals have their own escaping mechanism. I have not done much lex. But as you probably know, POSIX grep, vi(m), ed, sed, awk & friends only support POSIX Basic Regular Expressions. BRE both lack expressiveness and are stringly typed in direct use. So they cannot be shining examples of readable regular expressions. ERE as supported by POSIX egrep and GNU grep improve on that slightly by reversing expression logic (so you have to escape what you do *not* want to be special instead), by adding shortcuts for `{0,1}' and `{1,}' and alternation. But they still have the excessive verbosity and stringly typing problem of POSIX REs. Perl RE and PCRE (the latter is supported by GNU grep) improve on readability again by providing regular expression literals with and, among other powerful features such as interpolation, flags to improve readability specifically (such as `/x'). But you have to be aware of that. While PHP eventually supports PCRE and allows a wider range of delimiters, its RE implementation suffers from the fact that there are no regular expression literals. It steps back to stringly typing. So does Java, but Java essentially allows only one delimiter and no multi-line syntax; another two steps back. Java's RE implementation, in addition to that, suffers from Java's static typing and the excessive verbosity in implementation that brings. So both of them do not provide good examples either. You have not mentioned Python. Python's implementation is a step back from PHP and Java in that it does not support PCRE, but its own PCRE-inspired flavor. However, it is a step forward from that because of Python's implicit string concatenation, raw-strings to alleviate the escaping problem, and new RE features. By comparison, ECMAScript and its implementations have regular expression literals, but those have no variable delimiter, no interpolation, no multi- line syntax, and they do not support PCRE but their own flavor yet again. But on the plus side the languages are dynamic enough so that you can work around those shortcomings (as I did in JSX:regexp.js). (There are also other RE implementations, like that of Microsoft, which primarily suffer from the fact that they are very different to the common aforementioned ones, or have limited use. If you ever tried to use RE to search with Visual Studio, you know what I mean.) Finally, as a third factor to readability of code using regular expressions, here comes in the person responsible for writing it. Many people use regular expressions where they are not strictly necessary. And they write needlessly complicated regular expressions because they do not know better or do not care. Specifically for ECMAScript implementations (but you can also find similar bloat code elsewhere), people escape `/' in *string* literals passed to the RegExp constructor because `/' is the delimiter of *RegExp* literals. They needlessly escape special characters in character classes. They use alternation where character classes would have sufficed. And so on. Attempting to avoid regular expressions where they are not necessary, and simplifying regular expressions where they are, thereby improving readability, goes a long way towards understanding them, and vice-versa. You can find examples of that in many of my follow-ups in comp.lang.ALL and de.comp.lang.ALL. PointedEars -- When all you know is jQuery, every problem looks $(olvable).