3.1229 programming languages (256)
Willard McCarty (MCCARTY@vm.epas.utoronto.ca)
Wed, 28 Mar 90 19:00:57 EST
Humanist Discussion Group, Vol. 3, No. 1229. Wednesday, 28 Mar 1990.
(1) Date: Tue, 27 Mar 90 15:03:29 MST (10 lines)
From: koontz@alpha.bldr.nist.gov
Subject: Re: Icon for MS-DOS
(2) Date: Tue, 27 Mar 90 22:41:01 CST (165 lines)
From: Richard Goerwitz <goer@sophist.uchicago.edu>
Subject: Icon, Snobol, BASIC, C, Pascal -> opinionated statements
(3) Date: Wed, 28 Mar 90 10:32:34 PLT (25 lines)
From: "Guy L. Pace" <PACE@WSUVM1>
Subject: Languages, BASIC, Pascal
(4) Date: Wed, 28 Mar 90 12:12 PST (26 lines)
From: <OAKMAN_D1@PLU>
Subject: BASIC etc.
(1) --------------------------------------------------------------------
Date: Tue, 27 Mar 90 15:03:29 MST
From: koontz@alpha.bldr.nist.gov
Subject: Re: Icon for MS-DOS
I was able to download Icon via ftp by connecting to cs.arizona.edu, setting
binary mode, changing directories to icon/v7.5, and getting version7.doc,
dos_e_1.arc, dos_e_2.arc, and bench.arc. I haven't run anything yet.
(2) --------------------------------------------------------------182---
Date: Tue, 27 Mar 90 22:41:01 CST
From: Richard Goerwitz <goer@sophist.uchicago.edu>
Subject: Icon, Snobol, BASIC, C, Pascal -> opinionated statements
Bob Kraft asks:
> Do all forms of Pascal and C cost significant money these
> days?
If you are running a fairly standard architecture machine with
a 32-bit CPU running Unix you can get all kinds of GNU soft-
ware. I have a 80386-based no-name clone running SCO Xenix and
the Microsoft 5.1 C compiler. I find that the GNU compiler out-
performs it by a small but significant margin, so I use it. The
trouble is that you have to have _some_ sort of C compiler up
already before you can "bootstrap" a copy of GNU. Most Unix
boxes have compilers installed, so this is no big deal.
GNU software is generally pretty nice stuff, especially considering
that it is free. I've replaced my native Xenix prepocessor, make
command, and many, many system utilities with GNU equivalents. In-
cidentally, GNU stands for GNU's not Unix. GNU software is put out
by the Free Software Foundation (i.e. Richard Stallman and cohorts
at MIT and elsewhere).
Eric Johnson writes:
> Implementations of the Icon programming language are available for
>MS-DOS microcomputers and several other microcomputers as well as for
>MVS, UNIX, VAX/VMS, and VM/CMS. All are in the public domain except
>an MS-DOS/386 version. They are distributed by the Icon Project,
>Department of Computer Science, Gould-Simpson building, The University
>of Arizona, Tucson, AZ 85721. Phone (602) 621-4049 for ordering
>information. There is a small cost for materials: the MS-DOS
>executables cost $20.00; MS-DOS/386 version is $25.00.
Let me cast a vote in favor of Icon, rather than Snobol4. Icon is the
successor to Snobol. Snobol5 was under development when its creators
realized that they could generalize the concept of goal-directed evalu-
ation to the entire programming language, and not limit it to the string
scanning sublanguage. They abandoned Snobol, and created Icon. Icon
improves upon Snobol in many ways, among them that (in addition to its
more consistent treatment of backtracking and evaluation) it possesses
a procedural orientation, and provides built-in data structures of the
sort that those versed in, say, C and Pascal are accustomed to (though
usually with a subtle, and extremely useful twist). Those raised on
modern, procedural languages like these will doubtless find Icon much
more easy to learn, debug, and maintain.
The main problem I've seen with Icon is that it is a bit more low-level
than Snobol4. It was designed, from the ground up, to be a general-
purpose programming language without the same repertoire of builtin
pattern matchers, etc. Snobol programmers tend to become frustrated
when they learn Icon, mainly because they can't immediately do in Icon
what they have been accustomed to doing in Snobol. They have to learn
how to use the Icon library, and they have to learn essentially how
string scanning "really works." The familiar ARB, for instance, can
be coded as an Icon procedure very easily. It takes just three lines
of code, two of which are the frame of the procedure declaration:
procedure Arb()
suspend &subject[.&pos:&pos <- &pos to *&subject+1]
end
The process is trivial to an experienced Icon hand, but it takes know-
ing a lot about backtracking and scanning, as well as fine points such
as when to dereference variables (.&pos). I like Icon because I can
create _ad hoc_ all kinds of pattern matchers that Snobol has never
heard of. It's easy and fast. It takes some time to master, though.
This is, as I noted above, a problem for those migrating from Snobol,
since they want access right away to their familiar (and VERY useful)
builtin patterns.
In sum: Though Icon is lower-level than Snobol, it is more general-
purpose. It also has structures, scoping conventions, etc., that are
more like what we find in popular languages like C and Pascal. Finally,
Icon is easy to maintain and debug, not only because of its internal
elegance and consistency, but also because of its modern, procedural
orientation. It's a nice language, and what's more its essentially
free, and is implemented reliably on a great variety of platforms. Any
Icon program can be run, with only very minor adjustments, on any plat-
form possessing an implementation. No "porting" nightmares. For Hu-
manists, I'd think these advantages to be quite decisive, especially
given their need for a smooth, elegant string processing language which
does not require the programmer to think about nasty things like memory
allocation.
JBOWYER@UNOMA1 writes:
>I must side with those people who are shocked
>at a programming course built around BASIC, which is NOT a mainstream
>language.
This goes almost without saying. BASIC, while available for many, many
platforms, does not encourage modular program design, and leaves the
programmer with all kinds of problems due to the lack of any standard
ways of scoping variables. True, some vendors supply Pascal-like BASICs,
but then why not just use Pascal? Besides, a procedurally-oriented
BASIC is, by definition, nonportable. Bad way to start.
He continues:
>For that matter, SNOBOL and ICON, both of which I've learned
>and abandoned, are not mainstream either. I don't see any reason to
>program in a language that only fellow humanists can support when there
>exists so much third-party support for Pascal and C. I can pick up any
>computer-related magazine at the store and learn many new ideas related
>to C and Pascal. Can I do the same with BASIC or SNOBOL or ICON? I can
>choose from among several different programming tool packages that
>contain pre-coded routines for menus, directories, windows, text
>processing, graphics, etc. Can I do the same for BASIC or SNOBOL or
>ICON?
I must disagree on several counts here, though I agree on several others.
In my humble opinion, Icon doesn't need "support." If you like it, use
it. Implementations are solid. They are available for all the more
popular micros, and many, many mid-size machines (including nearly any-
thing that claims to run Unix). Icon frees the user of concerns relating
to storage, explicit typing, and various other matters that are the constant
concern of Pascal, and more so, C programmers. Really, C is hardly more
than a portable assembler with some nice libraries attached. Both Pascal
and C suffer from a lack of extensive string processing facilities like
what Icon and Snobol have. Vendors often add these facilities (which are
never as good as the ones in Snobol or Icon), but these are, by definition,
non-portable. Unless you want to get socked into a particular vendor, and
a specific machine architecture or operating system, I'd think it would
be better to do things involving language, symbols, etc. in Icon. This
is especially true for Humanists, who do not normally concern themselves
with garbage like putting nulls at the end of strings, malloc'ing storage
space, freeing the malloc'd space, etc. Those who want to learn Icon,
incidentally, can grab the book by Alan Corre (who is a member of this
list):
Alan D. Corre, _Icon Programming for Humanists_
(Robin Cover mentioned the same book in a previous posting, but I though
it worth mentioning here in this context as well.)
This is not to say that C is "bad for Humanists." It's just a bit unneces-
sary in most cases. Were I a teacher, I'm sure I would feel the same as
Alan Humm, who said in a recent posting:
...I would not teach introductory programming in 'C.' 'C' is
intended as a programming language for programmers and it is
incidentally my main programming language right now, but it is
but it is difficult to read and encourages programs that are
difficult to read. What it provides is an enormous amount of
flexibility and control to the programmer -- not, I would argue,
what you want to give to beginning programmers.
Alan (should I use prefixes here?) goes on to state that Pascal is
probably the best alternative, and that BASIC just does not encourage
good, clean, modular, maintainable programming style. Most of what
he says also applies to Icon. Pascal and Icon are both probably
good places to start. Again, though, note that portable Pascal pro-
grams are, by definition, not going to include those nice string-handling
additions that Humanists will typically need access to.
Although I've been programming far more in C lately, I'd still cast
my ballot for Icon.
-Richard L. Goerwitz goer%sophist@uchicago.bitnet
goer@sophist.uchicago.edu rutgers!oddjob!gide!sophist!goer
(3) --------------------------------------------------------------29----
Date: Wed, 28 Mar 90 10:32:34 PLT
From: "Guy L. Pace" <PACE@WSUVM1>
Subject: Languages, BASIC, Pascal
I'm getting behind again, but I need to get in my few cents worth on
languages for Humanists and others. I use Turbo Pascal Pro (with the
assembler and debugger) 5.5 and am having a great time learning to
use objects. I finally got an assembler with this package and I am
testing the assembly language waters on the IBM platform. I used
assembly language on Z80's a long time ago.
Pascal and I go back several years to when I got my first copy of
Turbo Pascal for the old CP/M computer.
My feeling today is that there is no more flexible, powerful and useful
language available for almost any purpose than Turbo Pascal. The
extentions added to Pascal by Borland (hang the ANSI standard!) provide
the Pascal programmer with the low-level handles of C, the simplicity
and directness of BASIC statements, and a solid, elegant structure.
Most of the work I've done in Pascal has been in the area of database
systems, both small and large.
With its strengths, Turbo Pascal is probably the best language for
entry level and advanced programmers in the Humanities. One of the
best tutorial programming books available for Turbo Pascal is the
one by Jeff Duntemann ... the darned thing is at home and I can't
remember the title.
Got it ... _Complete Turbo Pascal_ (Third Ed, I think).
(4) --------------------------------------------------------------30----
Date: Wed, 28 Mar 90 12:12 PST
From: <OAKMAN_D1@PLU>
Subject: BASIC etc.
All right, I've finally been provoked! After about a year and
a half as one of the "silent Humanists," I've finally decided to
contribute to a discussion.
My point about programming languages is going to be simple:
If it works, who cares if it is "spaghetti code"? Some programming
tasks do not require elegant code. BASIC or Icon may be just the
languages for certain relatively simple programming tasks. If
you do contemplate a major programming project (big program) or
a task that requires speed, then you will need to implement
well-structured code and adopt 'C' or even assembly language.
To some extent the task will dictate the language of choice.
Structured programs are much more easily debugged and maintained.
Some programming tasks, however, may much more profitably be
executed in BASIC. I have a BASIC grading program, for example, that
would have taken much more time to program in Pascal and would not
have worked any better.
My advice is, learn to program in several languages. Then you
can select the tool appropriate to the nature of the programming
task. Happy programming.