- Instant gratification. Yes, I know this offends the more scholarly programmers, but I think instant gratification is critical. Positive feedback is immensely important when you are learning and there is nothing more satisfying than seeing software you have written do "real things". Writing a program that posts to twitter or blinks an LED is a "real thing". Writing a program that mutates or transforms a list of objects in some clever way is not.
- Understanding what the program does is vital. I often see people recommend languages that depend heavily on a deep understanding of more demanding subjects. If the newcomer can't describe why a program works: effort has been wasted. "You'll get it later" is not a good way to learn.
- Languages that require a lot of ceremonial fluff distract from what the student should be focusing on. This applies to everything from how the tools work to syntactic fluff in the language itself.
- It has to be a "real" language. As in: a language that is actually used by a significant number of people in paid jobs.
- Languages specificly designed for teaching programming are rarely useful. If they were useful they wouldn't be teaching languages.
- No oddball or perversely domain-specific languages.
- Some exposure to a hardware-near language early on can be beneficial, but not as a first language.
Nobody starts learning the violin by having the teacher ram Paganini's 24 Caprices down their throat.
41 comments: