Which is exactly why all such paradigms are _awful_.

Do you have any defense of that? I'd be interested to read it.

I think every article on coding advice I've read for the last decade favors long and descriptive function/variable names.

The "break" and "span" terms were familiar from a time when more people knew the Snobol language, which has two frequently useful pattern matching operators: BREAK and SPAN. Snobol's BREAK(S) pattern matching operator matches the input up to but not including the single-character match for any of the characters in set S. The set S delimits or "breaks" the sequence. SPAN(S) matches a sequence of one or more characters from the set S.

strpbrk tries to fit "string" "pointer" and "break" into a symbol that is different in the first six characters. It was once a common linker limitation that only the first six characters of external symbols were stored.

Actually the C function which corresponds to the concept of BREAK is strcspn (complemented span), because this gives the (length of) the range characters up to the first match in the set. That is to say, strcspn could have been called strbrk! Then we would have had strspn and strbrk as a complementing pair. In any case, the strpbrk function points one character past the substring indicated by this function; giving a pointer to the breaking character. I think, the following equivalences hold:

   strcspn(str, set)        <-->  strpbrk(str, set) - str;
   str + strcspn(str, set)  <-->  strpbrk(str, set);

Trivia: break and span appear as functions in the Scheme SRFI 1, by Olin Shrivers [1998]. I think these correspond to the take-while and drop-while in Clojure and imitations thereof like the Emacs Lisp dash library.

http://srfi.schemers.org/srfi-1/srfi-1.html#span

But there's a reason that this sort of name has been left behind in modern APIs.

Short names are not left behind in core languages. For instance, a function that gives the length of a list, string or other sequence is often called length or len, and not length_of_sequence or whatever.

Arc, in which HN is programmed, has reduced "lambda" to "fn". "fn" is the same sort of shortening as using "pbrk" for "pointer to break".

Ruby has shortened "print" to "p".

For the basic core of a language, shortening names is good. When you're reading code, the short names by their very brevity tell you "I'm a thing in the core language, and not some external API to some add-on lib", which also has connotations of "I might be useful in many contexts; it may be worth it to learn about me and remember me".

You do have to admit the slight irony of the shortened string-handling function names in C, given this fact.

Think about it: there's a reason why human languages are filled with pronouns, because if you use the full name for everything, communication will soon become tedious and it will become actually harder to understand.

Any desire for a long and descriptive name should be tempered with a matching desire for conciseness. Otherwise you end up with names like MaybeUpdateDisplayParameterListForValidation. Throw twenty of these names onto a screen, and I have no idea what the hell is going on: I can't even figure out which names are the same at a glance.

But long variable names?!? There is no place for such an abomination under this sun.

You mean field names? A paradigm where you have such a thing is _awful_. Seriously. And this is exactly one of the reasons why it is awful and why it leads to an unreadable and unmaintainable code.

And no, I don't believe you. Making your variable names more descriptive does not make your code less readable. Even when it's not strictly necessary, it's not harmful to comprehension UNLESS you refuse to move from a completely outdated line width.

Some people argue that it takes longer to type and edit. But as we all know, we spend far more time reading than writing code, and modern editors (like vim!) have solved this non-problem anyways.

And, yes, OOP is a filth.

  foo = bar(baz, qux)
  myClassInstance.someWritableVar = lib.someFunction(param1, MyOtherClass.constants.FOO)

    const uint64_t *p=bsearch(&ref->u,
                              df->file_offsets,
                              df->num_file_offsets,
                              sizeof df->file_offsets[0],
                              &CompareU64s);

I generally have one function call per line for ease of debugging. Nothing worse than having to do a fiddly step in/step out dance when you're trying to think about what's going on. But it's also good for keeping on top of line lengths too.