From the JargonFile:

* A language lawyer is distinguished by the ability to show you the five sentences scattered through a 200-plus-page manual that together imply the answer to your question "if only you had thought to look there".

See LanguageLawyerRequired, where GarethMcCaughan most definitely qualifies ...

''An alternate definition:  Someone skilled in the ProblemDomain of programming languages--or at least in the implementation details of a particular language.''

----

LanguageLawyer''''''s are folks more concerned with what a language is supposed to do, and how to specify that, than they are with how to use it day to day. BjarneStroustrup and LarryWall are a couple of the more creative examples. Most mere mortals would do better to stick to what's simple and what works.

... but be sure you ''know'' a language lawyer.  It helps to have one on the team.  You may have to twist the lawyer's arms to make her keep it simple, but she will be able to tell you what's wrong when the language is fighting you on some simple thing and you can't figure out why.

''If you're in the business of designing and/or implementing a language, then you should either be a language lawyer, or have one (or more) on retainer.''

----

Brooks in TheMythicalManMonth describes the role of a LanguageLawyer in more detail. Brooks' information is based HarlanMills' article "Chief programmer teams, principles, and procedures." To Brooks, a LanguageLawyer is not a bad thing to be but is the "go to guy" when you can't figure out how to do something in your language, or have an error that you don't understand, similar to the role of the UnixGuru.