(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Tuesday, January 08, 2008
The word "intuitive"... isn't.
First off, thanks to everyone who wrote in with different interpretations of what the word “intuitive” really means. I agree that Jef Raskin did not have the final say.
Intuitive does not only mean familiar. It can also mean consistent, stable, discoverable, and exhibiting affordances. And some other things. The reason it means different things is that “intuitive” is not a concrete or objective property of software. It is the result of a good combination of objective properties. “Intuitive” is the result of good design, not the cause.
And this is why it is not a very helpful word. Like good design, it means different things to different people. So saying that such-and-such a programming language is “intuitive” is far less meaningful than saying it is consistent, or stable, or discoverable, or “familiar to C++ programmers.” Intuitive is a word people use to describe their subjective impression of whether something is well designed. Someone can always argue with the word “intuitive,” but we can all agree on objective characteristics like whether Java or PHP are consistent. Or we can compare the intellectual surface area of Haskell to Ruby.
So on to why a programming language cannot be better without being unintuitive:
All programming languages are equally powerful. So what does it mean to be “better”? Better is a subjective word, a result, just like intuitive. The sentence is consistent, because it compares two subjective things to each other. And obviously it makes a lot of sense if you accept Raskin’s rather narrow explanation that intuitive equals familiar. (Although narrow, it fits my experience when talking about how non-professionals view end-user software: In a recent project, clients were still claiming that search boxes for each field in a table were more “intuitive” than a single full-text search. Naturally, these were older managers who had spent their formative years working with ASCII applications that worked on that principle.)
So for the narrow explanation that intuitive springs from familiarity, a language cannot be better without being unfamiliar. Well, how can it be “better” if they’re all Turing Equivalent? Only in a subjective way; only by making you better. And in that sense, a language is only better if the process of using it makes you better as a programmer. Which comes from being moved out of your comfort zone and into a place where you must learn, and where the things you learn are productive.
Not rote memorization of when to use .length, .length(), .size(), or .getLength(). But rather when you learn new ways of thinking about the problem to be solved. Not every unfamiliar language is better, but every better language is unfamiliar.
Now what about the other ways you can arrive at software that feels “intuitive”? What about a language that is unfamiliar but consistent, stable, and discoverable? Won’t it be better? Well, yes, of course. In fact, it will be a better better than one that isn’t. You will learn more from functional programming in Haskell than functional programming in Ruby.
But what if a language was familiar but improved on what you already use by being more discoverable, more consistent, more stable, and so forth? How much better could it really be? In the sense of improving you as a programmer, how much personal value can we extract from a language that improves upon the familiar while still being familiar? Raskin suggests we will obtain at best minor improvements. Is Java really only a little better than C++, if at all? In the sense of making you a better programmer, what does Java teach you if you are already a competent C++ programmer?
(Of course, a straw man interlocutor can ask, “But what if I don’t already know C++? Isn’t Java a better language for me to learn first?” Ys, it may be a little better to learn. Perhaps. But in that case, the premise of the post is assured since neither language is familiar to the beginner.)
Unfamiliarity is the driving force behind being better in the sense of a programming language. And “intuitive” isn’t a real property of programming languages, it’s the result of good design.
First off, thanks to everyone who wrote in with different interpretations of what the word “intuitive” really means. I agree that Jef Raskin did not have the final say.
Intuitive does not only mean familiar. It can also mean consistent, stable, discoverable, and exhibiting affordances. And some other things. The reason it means different things is that “intuitive” is not a concrete or objective property of software. It is the result of a good combination of objective properties. “Intuitive” is the result of good design, not the cause.
And this is why it is not a very helpful word. Like good design, it means different things to different people. So saying that such-and-such a programming language is “intuitive” is far less meaningful than saying it is consistent, or stable, or discoverable, or “familiar to C++ programmers.” Intuitive is a word people use to describe their subjective impression of whether something is well designed. Someone can always argue with the word “intuitive,” but we can all agree on objective characteristics like whether Java or PHP are consistent. Or we can compare the intellectual surface area of Haskell to Ruby.
So on to why a programming language cannot be better without being unintuitive:
All programming languages are equally powerful. So what does it mean to be “better”? Better is a subjective word, a result, just like intuitive. The sentence is consistent, because it compares two subjective things to each other. And obviously it makes a lot of sense if you accept Raskin’s rather narrow explanation that intuitive equals familiar. (Although narrow, it fits my experience when talking about how non-professionals view end-user software: In a recent project, clients were still claiming that search boxes for each field in a table were more “intuitive” than a single full-text search. Naturally, these were older managers who had spent their formative years working with ASCII applications that worked on that principle.)
So for the narrow explanation that intuitive springs from familiarity, a language cannot be better without being unfamiliar. Well, how can it be “better” if they’re all Turing Equivalent? Only in a subjective way; only by making you better. And in that sense, a language is only better if the process of using it makes you better as a programmer. Which comes from being moved out of your comfort zone and into a place where you must learn, and where the things you learn are productive.
Not rote memorization of when to use .length, .length(), .size(), or .getLength(). But rather when you learn new ways of thinking about the problem to be solved. Not every unfamiliar language is better, but every better language is unfamiliar.
Now what about the other ways you can arrive at software that feels “intuitive”? What about a language that is unfamiliar but consistent, stable, and discoverable? Won’t it be better? Well, yes, of course. In fact, it will be a better better than one that isn’t. You will learn more from functional programming in Haskell than functional programming in Ruby.
But what if a language was familiar but improved on what you already use by being more discoverable, more consistent, more stable, and so forth? How much better could it really be? In the sense of improving you as a programmer, how much personal value can we extract from a language that improves upon the familiar while still being familiar? Raskin suggests we will obtain at best minor improvements. Is Java really only a little better than C++, if at all? In the sense of making you a better programmer, what does Java teach you if you are already a competent C++ programmer?
(Of course, a straw man interlocutor can ask, “But what if I don’t already know C++? Isn’t Java a better language for me to learn first?” Ys, it may be a little better to learn. Perhaps. But in that case, the premise of the post is assured since neither language is familiar to the beginner.)
Unfamiliarity is the driving force behind being better in the sense of a programming language. And “intuitive” isn’t a real property of programming languages, it’s the result of good design.
Comments on “The word "intuitive"... isn't.”:
<< Home
"what does Java teach you if you are already a competent C++ programmer?"
On languages very little, how to use a garbage collector, maybe ... no, I think that's it.
Actually, in reverse, I would have learned more from C++ if I started from Java: pointers, macros, virtual methods, bit manipulation, templates.
On programming, however, Java taught me a lot, given the sudden increase in productivity that made it possible to explore ever more interesting patterns and higher level abstraction.
Even more interesting was a short stint working with VB, which taught me nothing new about languages, but more about RDBMS than all the C/C++ projects combined. There was simply more energy left to learn database design, not having to worry about the mechanics of API calls, and troubleshooting GPFs.
Sometimes not having to learn about the language is a good thing.
On languages very little, how to use a garbage collector, maybe ... no, I think that's it.
Actually, in reverse, I would have learned more from C++ if I started from Java: pointers, macros, virtual methods, bit manipulation, templates.
On programming, however, Java taught me a lot, given the sudden increase in productivity that made it possible to explore ever more interesting patterns and higher level abstraction.
Even more interesting was a short stint working with VB, which taught me nothing new about languages, but more about RDBMS than all the C/C++ projects combined. There was simply more energy left to learn database design, not having to worry about the mechanics of API calls, and troubleshooting GPFs.
Sometimes not having to learn about the language is a good thing.
You ask 'Well, how can it be “better” if they’re all Turing Equivalent? Only in a subjective way; only by making you better.'
No: there is a much more objective way it can be "better". It can make you more PRODUCTIVE. Being more productive doesn't necessarily mean you improved. Languages are tools: force multipliers. A carpenter does not judge hammers based upon what they teach him. The judge hammers based upon how productive they are with them. I find your definition of intuitive/better as a bit perverse when viewed in that context.
So yes, a new language could be objectively better for a particular task without being unfamiliar. Imagine I invented a new language C++GC which is *exactly like* C++ except that the delete operator is unnecessary. That language would be better (for many projects) and yet familiar.
No: there is a much more objective way it can be "better". It can make you more PRODUCTIVE. Being more productive doesn't necessarily mean you improved. Languages are tools: force multipliers. A carpenter does not judge hammers based upon what they teach him. The judge hammers based upon how productive they are with them. I find your definition of intuitive/better as a bit perverse when viewed in that context.
So yes, a new language could be objectively better for a particular task without being unfamiliar. Imagine I invented a new language C++GC which is *exactly like* C++ except that the delete operator is unnecessary. That language would be better (for many projects) and yet familiar.
Paul:
To be perfectly frank, while what you say is true, in my personal opinion it falls under what Jef Raskin called "Offering at best a minor improvement."
Sure, C++GC is better than C++. But there is something better than C++GC that is going to make you productive and a better programmer.
Of course, we can debate the word “better” all day. Some people think whatever the boss wants is better than whatever needs to be sold to the boss. Or whatever makes them seem cool and hip is better than whatever makes them seem staid and afraid of change.
I think you know what I mean, and if it doesn’t interest you as much as improving your productivity whilst learning nothing new, no harm no foul.
To be perfectly frank, while what you say is true, in my personal opinion it falls under what Jef Raskin called "Offering at best a minor improvement."
Sure, C++GC is better than C++. But there is something better than C++GC that is going to make you productive and a better programmer.
Of course, we can debate the word “better” all day. Some people think whatever the boss wants is better than whatever needs to be sold to the boss. Or whatever makes them seem cool and hip is better than whatever makes them seem staid and afraid of change.
I think you know what I mean, and if it doesn’t interest you as much as improving your productivity whilst learning nothing new, no harm no foul.
Reginald: I am very interested in learning new stuff and imp. But it isn't the only vector of "better" available. So the statement that "a language cannot be better if it is intuitive" is trivially demonstrated to be wrong (in the purest mathematical sense of having exceptions).
A more accurate statement might be more like: "The 'best' programming languages are not intuitive" or "intuitive programming languages do not teach you anything."
A more accurate statement might be more like: "The 'best' programming languages are not intuitive" or "intuitive programming languages do not teach you anything."
Paul:
I must beg your pardon on this, but I do not find it useful to debate the purest mathematical truthfulness of statements about subjective reality.
You are welcome to promote either of the alternative statements if you find them more compelling subjectively.
I must beg your pardon on this, but I do not find it useful to debate the purest mathematical truthfulness of statements about subjective reality.
You are welcome to promote either of the alternative statements if you find them more compelling subjectively.
"Sure, C++GC is better than C++. But there is something better than C++GC that is going to make you productive and a better programmer."
There is always something better. Back when I was working with C++, C++GC would have offered me the chance to be more productive and a better programmer, even though it would have taught me nothing new about using the language, having less features than C++ (well, at least one less feature).
Not having to worry about GC removes the cognitive load that frees you to learn about databases and composition and user interface and other things not related specifically to expressing logic as code. That's why I learned so much from a stint working with VB, even though there was nothing in terms of language learning involved. And by making it easier to devise and reuse libraries, C++GC will teach you much more about reuse and composition than C++ templates and STL ever could.
There is always something better. Back when I was working with C++, C++GC would have offered me the chance to be more productive and a better programmer, even though it would have taught me nothing new about using the language, having less features than C++ (well, at least one less feature).
Not having to worry about GC removes the cognitive load that frees you to learn about databases and composition and user interface and other things not related specifically to expressing logic as code. That's why I learned so much from a stint working with VB, even though there was nothing in terms of language learning involved. And by making it easier to devise and reuse libraries, C++GC will teach you much more about reuse and composition than C++ templates and STL ever could.
I think this article clarifies your perspective more clearly than the last, and sheds light on where you and I disagree. Namely, I think your definition of "intuitive" places greater weight on familiarity than mine. Perhaps you've come that conclusion because most programming languages achieve intuition by relying on familiar concepts?
My belief is programming languages that rely on familiarity to sate a programmers' intuition cannot compare to those which exhibit intuition through discoverability without regard for familiarity.
My belief is programming languages that rely on familiarity to sate a programmers' intuition cannot compare to those which exhibit intuition through discoverability without regard for familiarity.
I agree with your premise, but the second-to-last sentence seems to have the cause and effect the wrong way around:
>Unfamiliarity is the driving force behind being better in the sense of a programming language.
I don't think the unfamiliarity is a driver to the betterness, rather it is a consequence of the betterness.
I think you could say that unfamiliarity is "necessary but not sufficient" for a better language.
>Unfamiliarity is the driving force behind being better in the sense of a programming language.
I don't think the unfamiliarity is a driver to the betterness, rather it is a consequence of the betterness.
I think you could say that unfamiliarity is "necessary but not sufficient" for a better language.
Switching from C++ to C++GC, although freeing up some of your precious cognitive load otherwise spent on figuring out how to manage the heap, could never possibly free up as much of this coveted load as switching from C++ to Ruby would. It would be a choice between a minor and a major improvement, just as Reg points out. Settling for the minor just for some immediate cognitive relief is short sighted (assuming we're not under big integration or performance constraints).
Not having to learn about the language can free your mind for other things, but it can't possibly free your mind more than learning a better language that teaches you to solve your problems with much less time and effort.
Learning curves aren't always obstacles to avoid. I believe that being a good developer means to wisely choose from among the available learning curves. Some take more time than others, and there's a balance to be struck between short and long term constraints. New programming paradigms are worth the effort in the long term.
Not having to learn about the language can free your mind for other things, but it can't possibly free your mind more than learning a better language that teaches you to solve your problems with much less time and effort.
Learning curves aren't always obstacles to avoid. I believe that being a good developer means to wisely choose from among the available learning curves. Some take more time than others, and there's a balance to be struck between short and long term constraints. New programming paradigms are worth the effort in the long term.
Sofal, I think you misunderstood my arguments. I'm not one to shy away from learning new languages, and I do work with Ruby daily, so I can appreciate what it offers compared to Java or C/C++. But learning more about development does not require picking a more sophisticated language, sometimes it's the dumbed-down language that offers great learning opportunities.
For me programming is just a means to creating software that solves people's problems. Solving problems requires architecture, data, composition, change management, user experience, algorithms, and much more than just lines of code. Some languages will only teach you how to be a better monkey. Other languages will teach you nothing about coding, except maybe the mistakes of their design, but a lot about building better software.
Bash may not be considered a serious language, but taught me a lot about scripting, piping and small pieces loosly joined. I did not learn the UNIX way from writing C code on a UNIX machine, but from using its command line tools. VB is brain dead as a language, but offered me the chance to learn about databases, components and end-user experience. Could have done it while programming in C++, but it just took longer. ABAP has got to be the worst COBOL I've ever seen, the language is a disaster zone, but how often do you get to work on an application that has 17000+ tables! (ABAP is SAP R/) I never much cared for SQR, but I did learn everything about reporting, OLAP and data transformation from that project, years before Jasper, BIRT and Ruports.
The focus on pure-form general-purpose languages like Java, Ruby and Haskell is coding for coding's own sake. It's important, but not the be all. Software development is about much more than coding faster or coding better, and you'll be surprised how much you can learn from some of these inbred proprietary languages. It's the skills that I can carry from one language to another that I value more than the features of any given language.
For me programming is just a means to creating software that solves people's problems. Solving problems requires architecture, data, composition, change management, user experience, algorithms, and much more than just lines of code. Some languages will only teach you how to be a better monkey. Other languages will teach you nothing about coding, except maybe the mistakes of their design, but a lot about building better software.
Bash may not be considered a serious language, but taught me a lot about scripting, piping and small pieces loosly joined. I did not learn the UNIX way from writing C code on a UNIX machine, but from using its command line tools. VB is brain dead as a language, but offered me the chance to learn about databases, components and end-user experience. Could have done it while programming in C++, but it just took longer. ABAP has got to be the worst COBOL I've ever seen, the language is a disaster zone, but how often do you get to work on an application that has 17000+ tables! (ABAP is SAP R/) I never much cared for SQR, but I did learn everything about reporting, OLAP and data transformation from that project, years before Jasper, BIRT and Ruports.
The focus on pure-form general-purpose languages like Java, Ruby and Haskell is coding for coding's own sake. It's important, but not the be all. Software development is about much more than coding faster or coding better, and you'll be surprised how much you can learn from some of these inbred proprietary languages. It's the skills that I can carry from one language to another that I value more than the features of any given language.
From Enfranchised Mind:
Are all programming languages equally powerfull?
The argument is that no they aren’t because of safety, and expressiveness, and productivity, and a bunch of other things along the lines of saying that although all languages are equally powerful in theory, in practice they aren’t.
Which will not come as a revelation to anyone reading this weblog, but I still recommend the article. Once it stops trying to create contention where there really is none to be had, it moves along to some common ground, discussing the importance of language design.
Are all programming languages equally powerfull?
The argument is that no they aren’t because of safety, and expressiveness, and productivity, and a bunch of other things along the lines of saying that although all languages are equally powerful in theory, in practice they aren’t.
Which will not come as a revelation to anyone reading this weblog, but I still recommend the article. Once it stops trying to create contention where there really is none to be had, it moves along to some common ground, discussing the importance of language design.
<< Home
