Xref: utzoo comp.lang.misc:7207 comp.lang.icon:685
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!ames!haven!ni.umd.edu!uc780.umd.edu!cs450a03
From: cs450a03@uc780.umd.edu
Newsgroups: comp.lang.misc,comp.lang.icon
Subject: RE: Survey Results : Perl vs Icon vs .... (> 500 line
Message-ID: <1APR91.08094454@uc780.umd.edu>
Date: 1 Apr 91 08:09:44 GMT
References: <BEVAN.91Mar29162211@panda.cs.man.ac.uk> <1991Apr1.043321.11251@midway.uchicago.edu>
Sender: usenet@ni.umd.edu (USENET News System)
Organization: The University of Maryland University College
Lines: 23
Nntp-Posting-Host: uc780.umd.edu

Richard Goerwitz writes:
>I'm curious why it is that you would see any advantage in run-time
>loading other than decreased in-core mem. reqs.  If you were to use the
>Icon compiler (i.e. Icon->C translator), you wouldn't even have to
>worry about adding any code to any run-time system.

Well, I don't Icon, but I'm willing to put my foot in my mouth
anyways...

(1)  If you compile an entire application, you lose the
maintainability that the {Icon} environment provides.

(2) If you have some method of adding new primitives (accessible as
proper objects of your system) you suddenly make it possible to use
{Icon} for commercial applications (e.g. where speed is important).

Also note that it should be considered in good taste to provide, along
with any object code, the {Icon} work-alike "source" so that a year or
two down the road when somebody else wants to know what this thing is
doing they can figure it out.  If you GPL, you'd want to keep around
the intermidiate language source as well.

Raul Rockwell