My name is Camiel Plevier.
At Dutch Space, Leiden, the Netherlands, in 2005 I worked on a test program for the Herschel and Planck satellite's attitude control system. The test scripts needed to be written in TCL 8.3. Several times the discussions on these pages helped me to work around the unnatural quirks of TCL. So I felt I had to contribute as well.
RS: Welcome! But could you elaborate on what "unnatural quirks" you mean?
CMP What someone regards as "unnatural quirks" is relative to his background and viewpoint. Any examples given by one person will be debated by others. My contributions to several pages should give a clue on my particular vantage point.
LV for me, at least, when a program language's operator/function/proc is described as performing a particular function, and doesn't raise an error when input provided would generate output that doesn't match the description, that would qualify as an "unnatural quirk". For instance, in a hypothetical example that is not based on reality, if the description of "+" indicated what it did, and when using it I discovered that if I tried -13.47 + 1 and got an answer of -999.9 , then I would consider it at best an unnatural quirk, and more likely I would consider it a bug.
Even if someone explained to me that on the particular hardware I was using, even the C programming language did the same thing, I would not consider that justification for the language to operate in the manner described. I would not even consider it justified if the reference and training materials specifically warned that providing that value would cause problems. I would, however, consider the language creator/maintainer to be doing an exceptional job if I discovered that, despite hardware and the underlying implementation language limitations, a language did what I "meant" when I performed a function such as that.
A good example in Tcl where it does what I mean is this:
$ tclsh8.4 % expr 1<<31 -2147483648 % exit srv29 (22390) $ tclsh8.6 % expr 1<<31 2147483648
Notice how that, in Tcl 8.6 (and probably 8.5), tcl does the right thing with regards to shifting a bit, even though if I tried to do this in C, using 32 bit integers, I would get the same result as Tcl 8.4 did in the olden days.
There are other examples, in tcl, perl, etc. where language maintainers decided that making things work right was the better choice.
AM (20 june 2008) Sorry, can't help intrude here :). You mention Perl in this respect. I had a problem with a Perl script a number of years ago and ran into an attitude that contradicts the "make things work right" adagio - IMHO. This script would perform scheduled tasks. Between tasks it would wait a number of seconds before starting the next one.
The problem was, that sometimes it would compute a negative number of seconds to wait. In Perl, however, that number is interpreted as an unsigned integer. So instead of continuing immediately, it would wait approximately 2*10**9 seconds. Neatless to say that my patience ran out long before that.
When I complained about it on the Perl newsgroup, I got the answer that the number of seconds is unsigned, so Perl was doing the right thing. When, instead, I mentioned this on the Tcl newsgroup, Jeff Hobbs immediately volunteered to look at the possibility of building in a time machine in the [after] command to solve this problem once and for all. Of course the technical realisation of this still awaits the prerequisite implementation of TIP 131, but still.
(Could not resist telling this anecdote :))