"No one is actually using the vertical tab escape sequence. [...] That's because
it doesn't do anything, except with some particular printers and terminal
emulators, and in those cases you're better off not relying on it anyway. [...]
Here's my simple plea: stop it. Stop mentioning vertical tabs in tutorials and
language references. Drop the "\v" sequence in all future programming
languages."
James Hague, Stop the Vertical Tab Madness (http://prog21.dadgum.com/76.html)

"Looking at code you wrote more than two weeks ago is like looking at code you
are seeing for the first time."
attributed to Dan Hurvitz (http://www.softwarequotes.com/showquotes.aspx?id=738)

"At a fundamental level, all software describes changes in the state of a system
over time. Because the number states and state transitions in software can have
combinatorial complexity, programmers necessarily rely on approximations of
system behavior (called mental models) during development. The intent of a
mental model is to allow programmers to reason accurately about the behavior of
a system."
Devon H. O'Dell in ACM Queue: Debugging, March 22, 2017, Volume 15, issue 1
I don't agree with much of the rest of the article, but the intro, including the
quote above, nicely summarizes the importance of mental models.
(http://queue.acm.org/detail.cfm?id=3068754)

"Code Search was Google's first and only search engine to accept regular
expression queries, which was geekily great but a very small niche. The sad fact
is that many programmers can't write regular expressions, let alone correct
ones. When we started Code Search, a Google search for “regular expression
search engine” turned up sites where you typed “phone number” and got back
“\(\d{3}\) \d{3}-\d{4}”."
Russ Cox, in "Regular Expression Matching with a Trigram Index" (https://swtch.com/~rsc/regexp/regexp4.html)

On the importance of not only API clarity but on the fact that the algorithm
behind the API must be understood as well:  (I would argue this supports Rosie's
linear time approach versus the typically variable regex approach.)
"What did we learn from this harrowing experience? First, we need to fully
understand our dependencies before putting them into production. We made
incorrect assumptions about the Express.js API"
(http://techblog.netflix.com/2014/11/nodejs-in-flames.html)

"Regular expressions can be concatenated to form new regular expressions; if A
and B are both regular expressions, then AB is also a regular expression. In
general, if a string p matches A and another string q matches B, the string pq
will match AB. This holds unless A or B contain low precedence operations;
boundary conditions between A and B; or have numbered group references. [...]
For details [consult] almost any textbook about compiler construction."
(https://docs.python.org/2/library/re.html)

"not that regular expressions are evil, per se, but that overuse of regular expressions is evil."
(http://blog.codinghorror.com/regular-expressions-now-you-have-two-problems/)

"Regular expressions are dangerous"
(https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-regexp-query.html)

"Some people, when confronted with a problem, think “I know,
I'll use regular expressions.”  Now they have two problems."
Jamie Zawinski, in a Usenet post quoted with this attribution
"<jwz@netscape.com> wrote on Tue, 12 Aug 1997 13:16:22 -0700:"
(http://regex.info/blog/2006-09-15/247)

"the worst-case exponential-time backtracking strategy [is] used almost everywhere
else, including ed, sed, Perl, PCRE, and Python."
Russ Cox (https://swtch.com/~rsc/regexp/regexp2.html)

"I spent the summer of 2006 building Code Search, which lets programmers search
for source code using regular expressions. That is, it lets you grep through the
world's public source code. We originally planned to use PCRE for the regular
expression search, until we realized that it used a backtracking algorithm,
meaning it is easy to make searches take exponential time or arbitrary stack
depth. Since Code Search accepts regular expressions from anyone on the
Internet, using PCRE would have left it open to easy denial of service attacks."
Russ Cox (https://swtch.com/~rsc/regexp/regexp3.html)

"The plan had been to switch to a “real” regexp library, namely PCRE, probably
behind a newly written, code reviewed parser, since PCRE's parser was a
well-known source of security bugs. The only problem was my then-recent
discovery that none of the popular regexp implementations - not Perl, not
Python, not PCRE - used real automata."
Russ Cox (https://swtch.com/~rsc/regexp/regexp4.html)

"People with little regex experience have surprising skill at coming up with
exponentially complex regular expressions."
Jan Goyvaerts (http://www.regular-expressions.info/catastrophic.html)


"A major advance toward demystify the patterns previously referred to as
“regular expressions” is Perl’s /x regex flag — sometimes written (?x) when
embedded — that allows whitespace (line breaking, indenting) and comments. This
seriously improves readability and therefore maintainability. The white space
allow for cognitive chunking, so you can see what groups with what.

Modern patterns also now support both relatively numbered and named
backreferences now."
(http://stackoverflow.com/questions/764247/why-are-regular-expressions-so-controversial)

"filter(P, S) is almost always written clearer as [x for x in S if P(x)]"
Guido van Rossum on Python, quoted by Paul Graham
(http://www.paulgraham.com/quo.html)

"I mention this mostly as a joke, but it is quite true. If you define a language
that has car, cdr, cons, quote, cond, atom, eq, and a notation for functions
expressed as lists, then you can build all the rest of Lisp out of it."
Paul Graham
(http://www.paulgraham.com/icad.html)

"In software development, programming in the large can involve programming by
larger groups of people or by smaller groups over longer time periods.[2] Either
of these conditions will result in large, and hence complicated, programs that
can be challenging for maintainers to understand.  With programming in the
large, coding managers place emphasis on partitioning work into modules with
precisely-specified interactions."
[2] Brooks, Frederick P., Jr. (1982). "The Tar Pit", published in "The Mythical
Man-Month - Anniversary Edition". ISBN 0-201-83595-9 
(https://en.wikipedia.org/wiki/Programming_in_the_large_and_programming_in_the_small)

"Every day, we create 2.5 quintillion bytes of data — so much that 90% of the
data in the world today has been created in the last two years alone. This data
comes from everywhere: sensors used to gather climate information, posts to
social media sites, digital pictures and videos, purchase transaction records,
and cell phone GPS signals to name a few."
(http://www-01.ibm.com/software/data/bigdata/what-is-big-data.html)
