mftl

MFTL
 /M.F.T.L/

   [abbreviation: `My Favorite Toy Language']

   1. adj. Describes a talk on a programming language design that is
   heavy on the syntax (with lots of BNF), sometimes even talks about
   semantics (e.g., type systems), but rarely, if ever, has any content
   (see {content-free}). More broadly applied to talks -- even when the
   topic is not a programming language -- in which the subject matter is
   gone into in unnecessary and meticulous detail at the sacrifice of any
   conceptual content. "Well, it was a typical MFTL talk".

   2. n. Describes a language about which the developers are passionate
   (often to the point of proselytic zeal) but no one else cares about.
   Applied to the language by those outside the originating group. "He
   cornered me about type resolution in his MFTL."

   The first great goal in the mind of the designer of an MFTL is usually
   to write a compiler for it, then bootstrap the design away from
   contamination by lesser languages by writing a compiler for it in
   itself. Thus, the standard put-down question at an MFTL talk is "Has
   it been used for anything besides its own compiler?" On the other
   hand, a (compiled) language that cannot even be used to write its own
   compiler is beneath contempt. (The qualification has become necessary
   because of the increasing popularity of interpreted languages like
   {Perl} and {Python}.) See {break-even point}. (On a related note, Doug
   McIlroy once proposed a test of the generality and utility of a
   language and the operating system under which it is compiled: "Is the
   output of a FORTRAN program acceptable as input to the FORTRAN
   compiler?" In other words, can you write programs that write programs?
   (See {toolsmith}.) Alarming numbers of (language, OS) pairs fail this
   test, particularly when the language is FORTRAN; aficionados are quick
   to point out that {Unix} (even using FORTRAN) passes it handily. That
   the test could ever be failed is only surprising to those who have had
   the good fortune to have worked only under modern systems which lack
   OS-supported and -imposed "file types".)
    

My Favourite Toy Language
MFTL

   <jargon, language> (MFTL) Describes a talk on a {programming
   language} design that is heavy on {syntax} (with lots of
   {BNF}), sometimes even talks about {semantics} (e.g. {type
   systems}), but rarely, if ever, has any content (see
   {content-free}).  More broadly applied to talks - even when
   the topic is not a programming language --- in which the
   subject matter is gone into in unnecessary and meticulous
   detail at the sacrifice of any conceptual content.  "Well, it
   was a typical MFTL talk".

   2. A language about which the developers are passionate (often
   to the point of prosyletic zeal) but no one else cares about.
   Applied to the language by those outside the originating
   group.  "He cornered me about type resolution in his MFTL."

   The first great goal in the mind of the designer of an MFTL is
   usually to write a compiler for it, then bootstrap the design
   away from contamination by lesser languages by writing a
   compiler for it in itself.  Thus, the standard put-down
   question at an MFTL talk is "Has it been used for anything
   besides its own compiler?".  On the other hand, a language
   that *cannot* be used to write its own compiler is beneath
   contempt.

   {Doug McIlroy} once proposed a test of the generality and
   utility of a language and the {operating system} under which
   it is compiled: "Is the output of a {Fortran} program
   acceptable as input to the Fortran compiler?"  In other words,
   can you write programs that write programs?  Alarming numbers
   of (language, OS) pairs fail this test, particularly when the
   language is Fortran.  Aficionados are quick to point out that
   {Unix} (even using Fortran) passes it handily.  That the test
   could ever be failed is only surprising to those who have had
   the good fortune to have worked only under modern systems
   which lack OS-supported and -imposed "file types".

   See {break-even point}, {toolsmith}.

   (1995-03-07)