Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!cornell!rochester!PT.CS.CMU.EDU!H.GP.CS.CMU.EDU!cef
From: cef@H.GP.CS.CMU.EDU (Charles Fineman)
Newsgroups: comp.lang.misc
Subject: Re: Icon, was:Re: Discussions of languages (Was: Re: Modern langauges)
Message-ID: <636@PT.CS.CMU.EDU>
Date: 13 Jan 88 10:16:31 GMT
References: <6121@cisunx.UUCP> <3132@cbmvax.UUCP>
Sender: netnews@PT.CS.CMU.EDU
Organization: Carnegie-Mellon University, CS/RI
Lines: 30

And I thought I was alone!!!

I think one of the main reasons I liked ICON was that it was fast and easy
to program in. The resulting programs are much cleaner (read succinct) 
and thus easier to debug (and to grade i'm *SURE*). 

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.

The year after I took the Comparative Programming Languages course at CMU
they switched from ICON (which, incidentally, replaced SNOBOL from the year
before) to CLU. I borrowed a friend of mine's book and checked it out.
CLU has co-routine support similar to ICON's but instead of being loosely-
typed, it's tightly-typed with overloading. So, once you've written your 
prototype in ICON, all you have to do is formalize your data types
(CLU has a concept fo a CLUSTER; a data object and its associated operations)
in CLUish. CLU has the added benifit of being compiled and it has *great*
modularazation support (besides clusters).

I must make one thing clear, I have never actaully programmed in CLU so
the above is entirely conjecture. If CLU is really a bomb, I'd like to know.
I always thought a CLU compiler with shared clusters (between processes) 
would be a neat thing to try and implement.



	Charles Fineman
	Carnegie-Mellon University
	cef@h.cs.cmu.edu (via seismo)