Is this in a written work or are you speaking?
–
American LukeNov 7 '12 at 23:27

3

Non-technical audiences probably prefer to avoid having to remember acronyms and abbreviations because, unless they're well known, they make reading more difficult. I hate having to constantly look up meanings. Technical audiences love them. That's one reason technophiles are called "geeks". I don't see what's gained by creating yet another ungainly acronym. Spare the reader and spell the words out: there are only two, not ten.
–
user21497Nov 7 '12 at 23:39

4

Unless the documentation deals extensively with regular expressions, I would even avoid saying those two words, favoring letter pattern instead. No matter if you carefully define a technical term, it'll never sink in for a non-technical audience, until it actually becomes a popular common term. I find it hilarious when young ones think old geek terms are cool and quiz my knowledge on these. I'm afraid though that regular expressions will never make the main stream, with most software/system engineers born into Microsoft camp simply unable to fully grasp the concept. Let alone the mainstream.
–
ChrisNov 7 '12 at 23:53

1

@BillFranke But “regular” has an irregular meaning. Plus most of what gets called such, aren’t. That’s why I favor returning to the basic English word, pattern.
–
tchristNov 8 '12 at 2:14

@tchrist: That seems reasonable to me. "Pattern" is a word, not an acronym or abbreviation. It seems to me also that I'm out of my depth here because this has become a discussion about software & computer programming or development terminology. The only suggestion I can make is to clearly define the term for non-technical audiences. If "regular" is the wrong word, then your suggestion of "pattern" & Chris's suggestion of "letter pattern" seem good substitutes. I'm a technical editor, but biomed journals remind authors that some readers need simple language, & that's what I provide.
–
user21497Nov 8 '12 at 3:31

2 Answers
2

Edit

Apparently my drive-by downvoter didn’t care for “tell ’em I said so”. However, I quite assure you that it is germane, and indeed, a proper reference.

In particular, I said so in the Glossary of Programming Perl [O’Reilly Media], in its 2nd,
3rd,
4th editions published respectively in 1995, 2000, and 2012:

pattern:
A template used in pattern matching.

pattern matching:
Taking a pattern, usually a regular expression,
and trying the pattern various ways on
a string to see whether there’s any way to
make it fit. Often used to pick interesting
tidbits out of a file.

regex: See regular expression.

regular expression:
A single entity with various interpretations,
like an elephant. To a computer scientist,
it’s a grammar for a little language in which
some strings are legal and others aren’t. To
normal people, it’s a pattern you can use to
find what you’re looking for when it varies
from case to case. Perl’s regular expressions
are far from regular in the theoretical sense,
but in regular use they work quite well.
Here’s a regular expression: /Oh s.*t./.
This will match strings like “Oh say can you
see by the dawn's early light” and “Oh
sit!”. See Chapter 5.

The referenced Chapter 5 is titled “Pattern Matching”. It is not titled “Regular Expressions”. There are several reasons for that. One is that it is a mouthful. Another, as alluded to in the glossary entries above, is that in formal computational theory, a regular expression is an expression that describes a particular type of formal language: a regular one. And what “regular” means is quite specialized.

But before we can get into that, understand that even “language” here means a specific, technical thing that is not what users of regular English mean by “language”. It means “a possibly infinite set of strings”.

Moreover, a regular language is a language (that is, a set of strings) that can be parsed without requiring any auxiliary space proportionate to the size of the input set. Another way of saying it is that if the language is regular, then it is one that can be parsed using a deterministic finite automaton, or DFA for short.

In theory, there are formal requirements for determining whether a language is regular or not. You can read the link for how to do so, because lamentably enough, I cannot use TeX for the equations needed here in the ELU StackExchange site.

Examples of languages that cannot be parsed by a DFA include such things as palindromes and nested parentheses. Formally put, even something so simple as anbn cannot be solved (parsed) by a DFA, where that means n repetitions of some string a followed by that same n repetitions of some other string b.

However, format definitions and formal theory aside, the patterns used by modern programming languages and tools can often enough indeed match such things. Indeed, as soon as write a pattern as simple as (a+).*\1, you have violated the rules for what a DFA can solve, because you just required unbounded auxiliary storage to solve the back reference.

So theory gets in the way of practice here. The practice is that regular users (for the regular sense of regular, not the irregular one) continue to use in their daily language (here for the first time in this article at last meaning the regular thing most people mean by “language”) the term “regular expressions” long after those patterns had ceased to be such.

Plus no matter how you define it, a “regular expression” is a mouthful. It’s six syllables, and neither word means what people think it means. Both “regex” and “pattern” address the length concern, but only “pattern” alone addresses the formal concern.

It is for these reasons, amongst others, that I prefer the term “pattern”. Indeed, all told, the term “regular expression” occurs only 197 times in the 4th Edition of Programming Perl, while “pattern” occurs 541 times. Furthermore, “regex” occurs 156 times.
Replacing the shorter terms with the longer one would not only have been technically inaccurate, it would have required more tree-killing and back-breaking madness, and I might have had to resort to a different binding technology, as the book is already at risk of being bigger than a breadbox.

And that is why I said, “tell them I said so”. I really did say so, and from an actual position of authority on the matter. The laconic response that my downvoter seems to have confused for cavalier flippancy was nothing more, nor one whit less, than genuine compassion for the reader. I was being compassionate in my brevity. Apparently compassion is not here universally valued—nor, by some, brevity; and so, with this brief edit, do I set both such matters aright..

There are several shorten versions of the term "regular expression". Such as "regex" and "regexp".

The regular expression part is nothing more then a special character string representing a non-standard pattern of matching terms. The implementation is dependent upon the regex library that was used to implement the matching.

Regular expressions by design are technical. You must be capable of understanding sequences, groups and pattern matching. Otherwise, educating a reader on the subject of regular expressions is pointless.

As a result, I see no reason why your readers could not handle the following.

"A regular expression (regex or regexp for short) is a special text string for describing a search pattern."

And then continue to refer to the term as regex. A task that children might find difficult to follow in text, but who would write a children's book on regular expressions?

Yes, adult readers can handle abbreviations & acronyms, but tech writing contains so many that creating another just adds to the confusing alphabet soup. I've been doing biomed editing for 15 years & learned more tech abbrevs & acronyms than I want to know. I still hate them & can't remember them all. Non-technical people hate them more than I do. You're a geek, so you don't grok this point. BSOD & other error messages that say nothing intelligible to non-geeks beyond "Unexpected error: Shutting down & deleting your work. Bye!" are as friendly as the Linux command line. Clarity vs. brevity.
–
user21497Nov 8 '12 at 3:30