From: eifrig@beanworld.cs.jhu.edu (Jonathan Eifrig)
Newsgroups: comp.compilers
Subject: Re: Practicality of functional and logic languages?
Keywords: functional, design
Date: 12 Jan 93 00:43:17 GMT
Article-I.D.: comp.93-01-067
Reply-To: eifrig@beanworld.cs.jhu.edu (Jonathan Eifrig)
Organization: The Johns Hopkins University CS Department

Mirek Benes <benes@dcse.fee.vutbr.cs> writes:
>I would like to know some opinions concerning functional and logic
>programming languages (Haskell, Miranda, ML / Prolog) and their practical
>usability for programming: 
>
>* Are they (1) toys for playful programmers, (2) something usable only 
>  at universities for never-ending research, or (3) important means for 
>  development of usable software products? 

	Hoo boy!  Sounds like flame bait to me!  :-)

	"Yes, Virginia, there is a Santa Claus," or in this case practical
uses for "non-procedural" languages:

	1) Most expert system shells that I've seen have been written in
	   Lisp.  Now, Common Lisp is a "functional language" only in the
	   broadest possible interpretation of the definition, but since
	   it supports first-class function abstractions it certainly isn't
	   a "procedural language."
	2) I know of at least two financial brokerage houses that use
	   Smalltalk extensively for financial and economic simulations.
	   Granted, Smalltalk isn't an example of either a functional or
	   a logic programming language, but the fact remains that people
	   sometimes _do_ use goofy programming languages in certain
	   environments.
	3) The Japanese tried to use Prolog as the basis for their much-
	   ballyhooed "Forth Generation Computer" project.  Granted, this
	   never really got anywhere, but, hey, they tried!  :-)
	4) ML wasn't originally intended as a general-purpose programming
	   language _per_se_, but rather as the metaprogramming language
	   for the PCF theorem-prover.  As such, it was used as a _tool_
	   for some very interesting programs.  Currently, Isabelle, a
	   very interesting theorem-prover, is written completely in ML.
	5) The SML/NJ compiler, the _de_facto_ standard implementation of
	   ML in the United States, is written almost completely in ML
	   itself (with a few bits of C code for the garbage collector
	   and other run-time junk.)  While this of course seems a little
	   incestuous, the compiler was written in ML precisely _to_
	   demonstrate the feasiblity of writing very large programs within
	   ML.  By any metric, the SML/NJ compiler has to be considered
	   an important example of a "useable software product."

	I think the jury is still out with respect to which features of
these more experimental languages are going to migrate to more mainstream
languages; that is, after all, the purpose of research!  However, I think
it's very safe to say that the following language features will be showing
up in more "mainstream" use in the near future:

	1) A garbage-collected heap for non-system programming tasks.  It's
	   just too hard for programmers to keep track of the necessary
	   extent of persistent data structures in large systems.
	2) User-defined recursive data structures, along the lines of
	   ML's "datatype" declarations.  This, along with the related
	   notion of function-definition-via-pattern-matching, is simply
	   too elegant and expressive to not catch on.  Tree-oriented
	   algorithms are so easy to implement and understand when one
	   doesn't need to fool around with pointers explicitly.
	3) Some sort of parametric polymorphism in code modules.  The
	   future is still murky in this area, especially with respect to
	   the combination of reference cells and polymorphism, but
	   you're certainly going to see more than just Ada's generic
	   packages in the future.
--
Jack Eifrig (eifrig@cs.jhu.edu)       The Johns Hopkins University, C.S. Dept.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers