A language that allows one to easily customize syntax, flow control structures, etc. for the convenience of the author without regard to future readers. It allows one to create their own language or sub-language in their mind's own image without worrying about other readers' preferences or grokkability of the style. Contrast with a CorporateLanguage that assumes or targets masses of mediocre PlugCompatibleInterchangeableEngineers (programmers) where there may be many readers with varying skills. Such a language tends to hard-wire ways of things to reduce variation. One can say that a CorporateLanguage is for the herd of sheep while a HackerLanguage is for the lone wolf. ("Hacker" could be "hobbyist" or "tinkerer" also in this context. It's not meant to only include the devious version of "hacker".)
One can often achieve high personal productivity with a HackerLanguage, but readability may fit a very narrow audience or be questionable. Sometimes derogatorily called a WriteOnlyLanguage. [I am thinking about merging this with that topic, but it is the mind-gloving that is the issue more than difficulty reading, for the author may easily read their own code. Pondering topic rework.]
PaulGraham proudly calls Lisp a HackerLanguage IIRC.
Something of an odd choice, considering its free implementations had tended to be highly academic and not practical, and its commercial implementations were (and remain) tremendously expensive for any hobbyist. Only recently has any really high-performance lisp suitable for systems programming hit the mainstream (SBCL and CMUCL), but despite its malleability, lisp has tended toward extremely verbose and cumbersome syntax. Lisp appears to be a hacker language for Emacs hackers or those who have already drunk several gallons of the kool-aid. People who grow one-offs incrementally into programs (that is, most hackers) still tend toward perl, python, ruby, and tcl (and to some extent, shell scripts, though those usually tend to "graduate" to one of the preceding languages sooner or later).
See also: WhenAreStandardsRestrictive, LispIsTooPowerful