The OP thinks of this thread as a way of obtaining good advice. On the
basis of what he has seen, he has made a decision, and from his point of
view the thread has fulfilled its purpose and has ended.
However the original question - which language for an introductory class
- is something which many people are interested in and it raises several
significant issues.
One issue is 'the aim of the class'. Here's an observation - it is
almost impossible to formulate precise and formal aims for introductory
courses. For example, what is the aim of an introductory calculus
course? A typical student following such will probably not get a strong
grasp of the limit concept - but they've made a start. The point of this
example is that most maths science and engineering students need to
start learning about calculus at some point. Same for programming.
Second issue is the dimension which ranges from the cognitive psychology
of the students at one end, to characteristics of the language (as a
professional production language) at the other. In other words, is the
primary concern the learning process of the student, or the 'merit' of
the language?
I think that psychologically the concrete is much more 'graspable', but
not as powerful, as the abstract. Consequently a possible route is to
start with assembler, so the student can see values being moved between
registers, added up, conditional branches and so on, in an extremely
concrete manner. And also to experience why in general assembly language
is not very productive, and that C is far easier to write and just as
fast to execute. And then to move on to Java or whatever, making use of
the idea of abstraction.
The hardest thing to bear in mind is that while we (educators) have the
idea of bits and bytes and registers, and know it is good to be able to
ignore them, most students are not aware of what it is that we are
saying 'it doesn't matter'.


From: C.Douce [] 
Sent: 07 April 2009 10:03
To: Ppig-Discuss-List
Subject: Re: Choice of introductory programming language to a freshman

(forwarded on behalf of Andy Ko)
I'm amazed to see so many recommendations based on power, consistency,  
expressiveness, and performance. These qualities are great properties  
for people using languages on a daily basis to build shippable, robust  
code. But in most cases, trying to teach what someone ought to know  
ideologically (objects first, elegantly designed languages, etc)  
overlooks the fact that the complexity of these languages quickly  
exhaust any motivation such students had to start with. Unless one has  
an amazing teacher to help every student overcome the upfront  
complexity with sheer charisma, the only students still paying  
attention at the end will be the ones with a high tolerance for failure.
My advice: tell the students upfront to expect constant failure,  
intense debugging, and give them guidance on how to respond tp such  
failures. Do that and it doesn't really matter what language you use  
first. Teaching these courses is a matter of managing expectations and  
providing concrete, reusable disgnostic strategies. Save the  
principles for once they have these strategies, and they'll have a  
much better experienced-based insight into how and why the principles  
Andy Ko
Information School
University of Washington
(Andy: I have added your mail to both announce and discuss lists.
Cheers, Chris)
Chris Douce, Institute of Educational Technology, The Open University,
Walton Hall, Milton Keynes, MK7 6AA
+44 (0) 1908 653 414

Reply via email to