I wish that people would stop using "intuitive" and "counterintuitive" as arguments for or against programming language features. I think it is one of those words that sounds meaningful but isn't particularly, and the judgements that come from it nearly always seem arbitrary to me. Nobody comes out of the womb with an intuition for programming languages, so in a sense all language features are counterintuitive.
Intuitions vary, and it may be possible to find someone for whom any particular feature is "counterintuitive". When people say "X is counterintuitive" they apear to mean that they find it counterintuitive; this may not have any correlation with whether anyone else feels the same way, so it's not clear that it has any probative value at all. It would appear to be more accurate and less prejudicial to make a personal statement, saying "I find this counterintuitive", rather than an absolute statement "this is counterintuitive." I have just gathered a large collection of examples of Perl features that have been deemed "counterintuitive" over the years, including the =~ operator, garbage colection of anonymous subroutines, the vec() function, the fact that defined("") and defined(0) are true, and insertion of spaces when arrays are interpolated into strings.
People also said things like this:
Also remember, if all 256**16 addresses are possible, than any scheme which compresses some addresses to less than 16 bytes, will expand others to more than 16 bytes. This may be counter-intuitive, but is an inviolable propery of all compression schemes; it's called "The Pigeonhole Principle."
and this:
Actually (though it's counter-intuitive), NFAs recognize the exact same set of languages as DFAs.
and I don't find either of these things counter-intuitive. Just the opposite; I find them both manifestly obvious. That doesn't mean that they are manifestly obvious; like counterintuitivity, manifest obviousness is a property of the observer as much as it is of the thing observed.
Here's another nice example: Responding to one of the many articles in which someone asked how to convert a string to a number, Jeff Pinyan said:
Have you tried just USING the variable as a number?
and Larry Rosler replied:
That concept is quite counter-intuitive to anyone who has used a typed language such as C and has had to face functions like atoi() and atof() all the time.
I think this sums up my point: when people use "counter-intuitive" they usually mean "unexpected", and what is unexpected to one programmer may be quite ordinary to another programmer with a different background.
I would like to see an end to the characterization of language features as "intuitive" or "counter-intuitive", and even more, an end to "elegant" and "inelegant". These certainly express something, but whatever that is, it does not appear to me to be useful in discussions about the desirability of these features.
Interesting timing (Score:3, Interesting)
In an interesting coincidence, I was just arguing the same thing today [perl.org].
I do find the "inuitive/non-intuitive" arguments annoying. I used to use them until I had people start using them on me and I realized how silly they were.
Reply to This
Exactly! (Score:1)
There is a huge class of words I wish no one would ever again use to describe computer things. I've said before I don't care if a non-programmer can't read my code [perlmonks.org] , and I still mean it.
"Consistent" and "simple" and "effective" are much better descriptions of languages and APIs and features. I prefer to talk in those terms, though they're also rather fuzzy.
Re:Exactly! (Score:2)
I almost entirely disagree. I agree that we should not use those words as though they are universals, absolute values shared by everyone, but I see nothing remotely damaging about saying I dislik