mccarrol@topaz.rutgers.edu (<MC>) (01/11/88)
]My favorite language is Icon :-) :-); this language is VERY loosely typed. My ]problems usually don't come about because of type differences (Note: since it ]is an interpretive language it does provide the equivalent of runtime checks). ]This language helps me find my logic bugs (I don't have to worry about silly ]little things like stacks and lists; they are built into the language. ] ]One of the philosophies of Icon is that every function should either return a ]useful value or fail (i.e., x < y returns y if true; otherwise fails). Another ]thing is that functions can return more than one value (generators; i.e., ]find(s1,s2) returns all the positions of s1 in s2, and fails when it can't find ]any more). I love these concepts; what do others' think? ] Since I just started reading some info on Icon this week, and you seem to be fairly interested in it, I have a couple of questions about Icon. It seems to be a language with a lot of excellent concepts (generators in particular strike me as being a great idea..). But it doesn't seem to me to be terribly useful in general. It seems like it could do awk type jobs extremely well, but from what I've seen, it doesn't seem to be terribly good at much else. What is it intended for? Is it basically a text processing language, is it just something to try out some new ideas, or have I totally missed something? ] _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ]' ) ) "The secret compartment of my ring I fill ] / / _ , __o ____ with an Underdog super-energy pill." ]/ (_</_\/ <__/ / <_These are solely MY opinions, not AT&T's, blah blah blah -Mark -- "It is a principle of the music/to repeat the theme |Mark C. Carroll Repeat/and repeat again/as the pace mounts. /------/Rutgers U CS Student The theme/is difficult/but no more difficult |ARPA :CARROLL@AIM.RUTGERS.EDU than the facts to be/resolved"-WC Williams |Usenet:mccarrol@topaz.rutgers.edu
wpnst@cisunx.UUCP (Bill 'Deus' Nixon) (01/12/88)
Here at Pitt, one of the upper level CS courses uses Icon.
It was designed bascially for String processing and is a superset of
SNOBOL. Allows for structured programming (for you Pascal type people)
and symbolic manipulation of formulas. Seems like it would work good
for a parser.
I like the 'C' type statements - statements can succeed or fail, passing
along a value for each case.
Even tho it allows structured programming, I love having not to declare
my variable. I hate compiling my PASCAL or Modula-2 program, and have
the compiler yell at me for not declaring some stupid counter variable.
--
Bill 'Deus' Nixon One of the Univ. Of Pgh ZETS !
mail : wpnst@pittvms.BITNET
wpnst@unix.cis.pittsburgh.EDU
{allegra, cadre, psuvax1}!pitt!cisunx!wpnstdaveh@cbmvax.UUCP (Dave Haynie) (01/13/88)
in article <6121@cisunx.UUCP>, wpnst@cisunx.UUCP (Bill 'Deus' Nixon) says: > Here at Pitt, one of the upper level CS courses uses Icon. > It was designed bascially for String processing and is a superset of > SNOBOL. Nope. Icon does many of the kind of things that SNOBOL was designed to do, but other than the fact they both process strings and they're both Ralph Griswold languages, they're not all that closely related. SNOBOL is syntatically a very primitive language. Things like functions were added after the language was initially defined, and as a result they're implemented very strangely; you actually have to have your program jump around all functions you define. SNOBOL, like older BASICS, is globally oriented and starts execution from its first lines. Icon is a more modern language, syntatically similar to the Algol-derived languages like Pascal. I used SNOBOL in at course in college, and I've used Icon only a bit on my Amiga, but I much prefer Icon. > Allows for structured programming (for you Pascal type people) > and symbolic manipulation of formulas. Seems like it would work good > for a parser. I think it would be very good for writing compilers, if it could be easily compiled itself. Without that capability, it's going to be much too slow. > I like the 'C' type statements - statements can succeed or fail, passing > along a value for each case. In SNOBOL, your control structures consist of an optional GOTO-type field on the end of any program line that can act on success and failure. Pretty nasty, but I guess it works. > Even tho it allows structured programming, I love having not to declare > my variable. I hate compiling my PASCAL or Modula-2 program, and have > the compiler yell at me for not declaring some stupid counter variable. > Bill 'Deus' Nixon One of the Univ. Of Pgh ZETS ! > mail : wpnst@pittvms.BITNET > wpnst@unix.cis.pittsburgh.EDU > {allegra, cadre, psuvax1}!pitt!cisunx!wpnst -- Dave Haynie "The B2000 Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
cef@H.GP.CS.CMU.EDU (Charles Fineman) (01/13/88)
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)
franka@mmintl.UUCP (Frank Adams) (01/20/88)
In article <6121@cisunx.UUCP> wpnst@unix.cis.pittsburgh.edu.UUCP (Bill 'Deus' Nixon) writes: >Even tho it allows structured programming, I love having not to declare >my variable. I hate compiling my PASCAL or Modula-2 program, and have >the compiler yell at me for not declaring some stupid counter variable. What I really hate is having the compiler *not* yell at me for mispelling one of my variable names, and having to spend (sometimes) hours to find the bug. The overlooked declaration can be fixed in a few minutes. It takes a *lot* of those to make up for one six hour debugging effort. -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
wpnst@cisunx.UUCP (Bill 'Deus' Nixon) (01/25/88)
In article <2666@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >What I really hate is having the compiler *not* yell at me for mispelling >one of my variable names, and having to spend (sometimes) hours to find the >bug. The overlooked declaration can be fixed in a few minutes. It takes a >*lot* of those to make up for one six hour debugging effort. Complier not yelling at you for things ? Well, maybe AI research will come up with a compiler capable of this. The worst language to make a typo in is 'c'. For example, a friend of mine was working on a LARGE project (ie. lots and lots of code.), and had this line buried inside of the middle of it : if (c = 10) Of course he meant, if (c == 0), but hey, he was used to PASCAL, and well, couldn't figure out why the code was bombing with certain test cases. What's worse, a mispelling that isn't caught, which could be caught with a spelling checker variation, or a logic error, that may be caught with lint, if you can read and understand all the stuff. Program error are always going to be prone to human error no matter how much checking the complier/paser/linter does. Now, for a question - what is the langauge with the least about of risk to make 'typo' mistakes ? Maybe you all can sent your opinon to me, and I'll post the "poll" results in a few weeks. -- Bill 'Deus' Nixon One of the Univ. Of Pgh ZETS ! mail : wpnst@pittvms.BITNET wpnst@unix.cis.pittsburgh.EDU {allegra, cadre, psuvax1}!pitt!cisunx!wpnst
matt@oddjob.UChicago.EDU (My Name Here) (02/02/88)
wunder@hpcea.CE.HP.COM (Walter Underwood) writes:
) Lint'ing code can be very interesting. I've found procedures called
) with the wrong number of arguments, variables used but not set, etc.
) All this in code that seemed to work just fine.
For instance, unix kernels. (If I may let the last sentence apply to
them!)
Matt Crawford