home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / compiler / 2140 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  4.2 KB
  1. Path: sparky!uunet!spool.mu.edu!uwm.edu!ogicse!das-news.harvard.edu!spdcc!iecc!compilers-sender
  2. From: eifrig@beanworld.cs.jhu.edu (Jonathan Eifrig)
  3. Newsgroups: comp.compilers
  4. Subject: Re: Practicality of functional and logic languages?
  5. Keywords: functional, design
  6. Message-ID: <93-01-067@comp.compilers>
  7. Date: 12 Jan 93 00:43:17 GMT
  8. Article-I.D.: comp.93-01-067
  9. References: <93-01-059@comp.compilers>
  10. Sender: compilers-sender@iecc.cambridge.ma.us
  11. Reply-To: eifrig@beanworld.cs.jhu.edu (Jonathan Eifrig)
  12. Organization: The Johns Hopkins University CS Department
  13. Lines: 67
  14. Approved: compilers@iecc.cambridge.ma.us
  15.  
  16. Mirek Benes <benes@dcse.fee.vutbr.cs> writes:
  17. >I would like to know some opinions concerning functional and logic
  18. >programming languages (Haskell, Miranda, ML / Prolog) and their practical
  19. >usability for programming: 
  20. >
  21. >* Are they (1) toys for playful programmers, (2) something usable only 
  22. >  at universities for never-ending research, or (3) important means for 
  23. >  development of usable software products? 
  24.  
  25.     Hoo boy!  Sounds like flame bait to me!  :-)
  26.  
  27.     "Yes, Virginia, there is a Santa Claus," or in this case practical
  28. uses for "non-procedural" languages:
  29.  
  30.     1) Most expert system shells that I've seen have been written in
  31.        Lisp.  Now, Common Lisp is a "functional language" only in the
  32.        broadest possible interpretation of the definition, but since
  33.        it supports first-class function abstractions it certainly isn't
  34.        a "procedural language."
  35.     2) I know of at least two financial brokerage houses that use
  36.        Smalltalk extensively for financial and economic simulations.
  37.        Granted, Smalltalk isn't an example of either a functional or
  38.        a logic programming language, but the fact remains that people
  39.        sometimes _do_ use goofy programming languages in certain
  40.        environments.
  41.     3) The Japanese tried to use Prolog as the basis for their much-
  42.        ballyhooed "Forth Generation Computer" project.  Granted, this
  43.        never really got anywhere, but, hey, they tried!  :-)
  44.     4) ML wasn't originally intended as a general-purpose programming
  45.        language _per_se_, but rather as the metaprogramming language
  46.        for the PCF theorem-prover.  As such, it was used as a _tool_
  47.        for some very interesting programs.  Currently, Isabelle, a
  48.        very interesting theorem-prover, is written completely in ML.
  49.     5) The SML/NJ compiler, the _de_facto_ standard implementation of
  50.        ML in the United States, is written almost completely in ML
  51.        itself (with a few bits of C code for the garbage collector
  52.        and other run-time junk.)  While this of course seems a little
  53.        incestuous, the compiler was written in ML precisely _to_
  54.        demonstrate the feasiblity of writing very large programs within
  55.        ML.  By any metric, the SML/NJ compiler has to be considered
  56.        an important example of a "useable software product."
  57.  
  58.     I think the jury is still out with respect to which features of
  59. these more experimental languages are going to migrate to more mainstream
  60. languages; that is, after all, the purpose of research!  However, I think
  61. it's very safe to say that the following language features will be showing
  62. up in more "mainstream" use in the near future:
  63.  
  64.     1) A garbage-collected heap for non-system programming tasks.  It's
  65.        just too hard for programmers to keep track of the necessary
  66.        extent of persistent data structures in large systems.
  67.     2) User-defined recursive data structures, along the lines of
  68.        ML's "datatype" declarations.  This, along with the related
  69.        notion of function-definition-via-pattern-matching, is simply
  70.        too elegant and expressive to not catch on.  Tree-oriented
  71.        algorithms are so easy to implement and understand when one
  72.        doesn't need to fool around with pointers explicitly.
  73.     3) Some sort of parametric polymorphism in code modules.  The
  74.        future is still murky in this area, especially with respect to
  75.        the combination of reference cells and polymorphism, but
  76.        you're certainly going to see more than just Ada's generic
  77.        packages in the future.
  78. --
  79. Jack Eifrig (eifrig@cs.jhu.edu)       The Johns Hopkins University, C.S. Dept.
  80. -- 
  81. Send compilers articles to compilers@iecc.cambridge.ma.us or
  82. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  83.