I haven't yet read all 101 replies on this thread. I do want
to make some comments from a more "user-oriented" standpoint;
I mean, I will be making commments based solely on using
this sort of language for "end-user" projects; you won't hear
anything about O(1) vs. O(n) ...
My background, to put it all in perspective: I am a researcher in
physics, use and program the computer daily, have been programming
for more than 12 years, have lots of experience in FORTRAN, C,
Basic (from the old days), Pascal, assembler, TeX/LaTeX (yes,
these are programming languages, just that the DATA statements
tend to dominate); worked under VMS, Unix, Macintosh, MINIX,
Harris, IBM. For a "user" I am very experienced; however I am by
no means an algorithms analyst; I do not understand what lambda
constructs are and have never examined a garbage-collection
algorithm.
My experience with Lisp: first exposed to it when I first picked
up GNU Emacs and installed in on our VAX/VMS system in '88 or so.
I understand it well enough to be able to figure out where I need
to change something if I have to add something to a list; I have
succeeded in writing functions of ten or so lines in the past, to
do very simple things. However I have no desire to sit down and
learn it, when it requires a completely different manner of
thinking than C or ksh or FORTRAN; those kind of languages are
what I use every day. My experience with about 95% of the people
in our field is that they think the same way; Lisp is for computer
science departments. Heck, they think I am crazy for using
Python, which is readable.
My experience with TCL: this was chosen here at NIKHEF for an
extension language for a hardware-control program being written
here. At some point, the software-development group handed out an
"example" TCL script to all the people who would eventually be
using the system. The function of the script was to test the
response of a detector, and using the results to determine the
appropriate high-voltage setting for the detector. The unanimous
response of the user team: 1) the procedure looked much longer
than we all thought was necessary. We did not really understand
why it had to be so, but based on our experience with "normal"
languages, we had expected that the procedure would be about half
as long as it was (long meaning number of code lines.) 2) It was
VERY difficult to understand exactly what was going on at any
given time. If the code had not been generously commented, it
would have been even worse. People were not happy about this.
Note that this brings up an important rule: "users" often have the
criterion that if they can't more or less figure out what is
happening with an example program in an hour or so, then it is
just too complicated and they will begin to hope that you will
change to a different language.
My experience with Python (python was brought up as a possible
alternative): I like this. Python is something that you can begin
very simply with; you can use it instead of "bc" for example. I
write Python scripts now to do a lot of the things that I used to
do in awk, but found somewhat "awk"ward in awk (there are some
things that just BEG to be done in awk). I have also now
completed two rather sizeable projects in Python, and one (a code
for working out nuclear reaction kinematics and cross sections)
used Python's object-oriented facilities quite heavily. I
recently gave this code to a colleague who needed to do something
similar, and he really liked it, and found Python really easy to
use after about an hour of playing with it. Mind you, these are
the same people who will not switch from vi to Emacs because Emacs
is just too complicated. Python is very good at scaling from
small to large projects; I think that this is in part due
to it being interpreted; you can play with the small pieces
of a program individually, which encourages you to write this
way; also you can pack things into modules, which encourages
you to write "reusably".
If you want to choose a language which will really get used by a
wide spectrum of people, I think Python is a good choice. I see
people like me using it, and I also see computer science people
posting parser generators written in Python. It seems that this
language has enough flexibility and "dynamic range" to reach a
large class of users.
JT