Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!arizona!gudeman
From: gudeman@arizona.edu (David Gudeman)
Newsgroups: comp.lang.misc
Subject: Icon
Message-ID: <3473@megaron.arizona.edu>
Date: 15 Jan 88 23:31:18 GMT
References: <636@PT.CS.CMU.EDU> <6121@cisunx.UUCP> <3132@cbmvax.UUCP>
Organization: U of Arizona CS Dept, Tucson
Lines: 31


   cef@H.GP.CS.CMU.EDU (Charles Fineman) writes:

   HOWEVER, I still can't see ICON as any more than a toy language. It
   may be good for quick prototyping of complex algorithms but you probably
   wouldn't want to write anything *real* in it because it is interpreted.

For a good time, say that in comp.lang.lisp.  By the way, Icon's
"interpreted" code is what Lisp people call "compiled".  That is, the
Icon translator converts from Icon source code to a virtual machine
code that is run by an interpreter.  Most "compiled" lisps work the
same way.

In case anyone is interested, there are a _lot_ of real programs
written in Icon, for mainframes and micros both.  There have been
cases of large software projects written in Icon as a prototype
language, then never converted to another language because the Icon
was version fast enough.  The developers were concerned that
conversion to another language would make the program so huge that it
would not be cost-effective to ever modify or upgrade the code.

   ... once you've written your prototype in ICON, all you have to do
   is formalize your data types....

It's not quite that simple.  Icon is based on a programming language
paradigm that is a superset of the paradigm implemented by CLU.  If
you want to eventually convert from Icon to a procedural language, you
should write your Icon program without depending too much on
generators and goal-directed evaluation.  This takes a lot of the fun
out of Icon, but it is still easier to program in than most other
languages.