> What people call an “intuitive interface” is generally one which becomes obvious as soon as it is demonstrated. But before the demo there was no intuition of what it would be like. Therefore the real first sense of “intuitive” is retroactively obvious.
Programming languages often tout their “intuitive” this or that—syntax, semantics, whatever. It’s all crap written by a well-meaning designer who’s gotten so deep in their design that they can’t see how “obvious to me” does not mean “obvious to any equally intelligent person”.
Consider the kinds of interfaces which actually are intuitive, say, well-designed radio or temperature controls in a car. They afford experimentation, provide instant feedback, and need little to no labelling.
That’s how I think programming ought to be, at least at a beginner level. A text-based programming language is a great tool for power users, but it’s totally unapproachable for a new user because they don’t know the shibboleth. A blank slate is not friendly; in the rare event that the fledgling has a specific problem in mind already (“I want to make Mario!”) then they almost certainly don’t know even the most general form of what their solution would look like. Your beautiful, informative, 400-page manual does not make your language intuitive, just usable.
The end goal of my current language project—which is textual—is to serve as a basis for that kind of interface. If the system is designed from the beginning to support experimentation and play, and there is a 1:1 mapping to the “real thing” to avoid the disparity of “beginner mode” and “advanced mode”, then I think that would open up programming to a lot of people.
Essentially the opposite of COBOL: don’t try to make a system “easy for non-programmers”. Try to make a system that helps people become programmers so that they can realise their visions of games, applications, art pieces, and beyond.
> What people call an “intuitive interface” is generally one which becomes obvious as soon as it is demonstrated. But before the demo there was no intuition of what it would be like. Therefore the real first sense of “intuitive” is retroactively obvious.
Programming languages often tout their “intuitive” this or that—syntax, semantics, whatever. It’s all crap written by a well-meaning designer who’s gotten so deep in their design that they can’t see how “obvious to me” does not mean “obvious to any equally intelligent person”.
Consider the kinds of interfaces which actually are intuitive, say, well-designed radio or temperature controls in a car. They afford experimentation, provide instant feedback, and need little to no labelling.
That’s how I think programming ought to be, at least at a beginner level. A text-based programming language is a great tool for power users, but it’s totally unapproachable for a new user because they don’t know the shibboleth. A blank slate is not friendly; in the rare event that the fledgling has a specific problem in mind already (“I want to make Mario!”) then they almost certainly don’t know even the most general form of what their solution would look like. Your beautiful, informative, 400-page manual does not make your language intuitive, just usable.
The end goal of my current language project—which is textual—is to serve as a basis for that kind of interface. If the system is designed from the beginning to support experimentation and play, and there is a 1:1 mapping to the “real thing” to avoid the disparity of “beginner mode” and “advanced mode”, then I think that would open up programming to a lot of people.
Essentially the opposite of COBOL: don’t try to make a system “easy for non-programmers”. Try to make a system that helps people become programmers so that they can realise their visions of games, applications, art pieces, and beyond.