The second part of an interview with Bjarne Stroustrup showed up last week. (I talked about part one earlier.) One of the questions he was asked was if we should be "simplifying the process of coding so that more individuals are able to participate in development?" Stroustrup's answer is interesting and in two parts. Both parts are ripe for discussion. The first part of his answer is that "The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous." The second part should be very interesting to those of us trying to teach programming - "I don't think it is true that the programming languages are so difficult to learn." He basically says that most other academic subjects are more complex, have more detail and are harder to learn. Interesting.
I go back and forth about the idea of a lot more people being able to do their own programming. There I times when I think just about everyone should be able to develop their own code for specific applications but that they need some easier tools to use. There are other times when I think we have way too many programmers who don't really know what they are doing already. The ideal is probably somewhere in the middle. I do think that we have to make it easier for more people to do more with their computers than they do now. Does that necessarily mean they will or should be programming? That is unclear.
The idea of programming being easier to learn than other academic subjects again is - maybe so maybe not. I do believe that programming language syntax is not all that complex. Really it's not. Compare it to the weird stuff that goes into calculus or the complexity of learning another natural language or even the correct order of events in a history class. What is difficult about programming is the mind set - the thought process that goes into developing a program. That is what takes a while to teach.
That being said the art of teaching programming involves teaching the syntax and language structure at the same time one is teaching the planning and thought process that is involved in actually doing programming. Learning a second or third programming language is often a fairly trivial process for most people. The hard part is constant (mostly) while only the easy part (the syntax) changes. This is why tools like Alice, Squeak and Scratch are so popular - they allow teaching of programming concepts without the complexity of (the easy part) language syntax. Programming maybe the only discipline where we teach the hard part first and then come back to the easy part.
The hard part of programming is not programming languages but programming thinking. We may use other tools to avoid the more involved syntax of most programming languages at the beginning but there is real power in them so eventually people have to learn them. They really shouldn't find the languages all that difficult. It's not rocket science after all. And oh by the way they taught rocket science in my high school 35 years ago.
I maintain that the real problem with learning programming is poor teaching and poor teaching tools. I do not exempt myself from that poor teaching either. I often think that a lot of my students succeeded in spite of my teaching rather than because of it. If I'd done things differently maybe programming would have "clicked" for more of them. Maybe more of them would be writing code to change the world. We should be spending some of the money we are spending on new programming languages and put it into finding new and better ways to teach what really should be a moderately difficult rather than extremely difficult course of study.
What do you think?
I've always been a firm believer that the 'Coder Mindset' cannot be taught. It can be refined and honed by teaching and experience but all of the best programmers I've worked with were naturals.
On the flip side I've seen the utter devastation a department staffed with re-trained sports graduates (I kid you not) can cause.
I don't want to believe that there isn't anything about programming and developing software that can't be learned. There may be no motivation to do so, there may be unwillingness to go through all the steps and to work from fundamentals (just like learning to play an instrument), and there may be self-defeating points-of-view ("I can't do math," etc.), but I believe the content can be made accessible to those with a motivation and interest in doing the work and engaging in the subject.
Attitude may be the biggest difficulty. There may be some cognitive issues too, perhaps related to attitude or world-view that get in the way.
Donald Knuth speaks of this matter in an interesting way, around the need to deal with abstractions and how abstractions must be managed by software developers. He finds that there are people who find working with abstraction in an explicit way (self-consciously or not) extremely difficult.
I recall finding people who just don't get the difference between the character '5' and the number 5, (and ASCII code 0x35) for example, and certain things about programming make them very crazy. Eventually the light bulb lights or else the people flee computing because they can't deal with what seems insane to them and has them be incompetent.
Which is a long-winded way to suggest that it is about programming thinking and how to lead people to where the essential ahahs can be experienced. There is probably no right way to do this, leaving a wonderful rewarding challenge for the inspired teacher.
I agree with you Dennis. I want to beieve that everything can be taught. I have to beieve that people can be taught to sove problems. We need more problem solvers. Oh sure some people are just going to be better at it than others but really people need to think more critically. If we teach programming correctly more critical thinking will be a natural byproduct.
I wonder if student age and background enters in to this in a big way. I must admit to a level of 'geekness', I learned z80 assembler at 8 years of age on a Sinclair Spectrum, so I've always been able to program a computer. My family has a history of engineering, so from age 0 I was always taking stuff apart to see how it worked. For me problem solving and 'seeing' solutions was a natural thing. This has meant I've always considered programming as easy, fun and an intellectual challenge to find the most creative and elligant solution to any given problem.
Conversly most people I've encountered professionally didn't start programming until their late teans/early twenties at univercity. Amongst these the engineers tended to be the naturals. Again, they could just 'see' what was going on, the study was just to refine and formalise what they could already do. The non-engineers found it much harder going... Whilst they could be taught the Science of programming, the Art of programming was much harder to grasp. They never gained the ability to go from something seen before and extrapolate it into something new, which to me is the mark of a programmer.
I think it's *very* important to have tools that allow people to tinker, experiment, and build things for themselves. That may mean setting up filtering and routing rules for email, sending a chunk of data from app A to app B, or building complete custom solutions from the ground up.
Now, programming and problem solving are two different things; you can do the latter without the former, but not the other way around. No matter how "simple" you make the programming, there are problems to be solved and compromises to be made. Problem solving is far more important, and this is where I think we're missing the boat when we teach programming.
Language syntax may not be that hard, but what's the right language to teach with? C#/Java, C/C++, Python, Ruby, VB? I don't think so. Those are tools for programmers. Logo has probably been the best choice historically (IMO), though there are always initiatives and new developments (isn't MS doing something even now?).
"The hard part of programming is not programming languages but programming thinking."
"We may use other tools to avoid the more involved syntax of most programming languages at the beginning but there is real power in them so eventually people have to learn them."
Syntax isn't the main issue, though it's important; involved syntax is nothing compared to involved semantics, and the fact that both the syntax and semantics have nothing to do with problem solving in any real world domain--except programming. :) And there is no reason why a "simplified" language need by any less powerful than any other language; it's focus may be different but, if anything, it can be much *more* powerful. People should never have to learn more than they need to, in order to solve their problems--as far as languages go--so we can, forever, disassociate the term "real programmers" from language and tool choice.
I don't have a solution in hand for this problem, but I have an idea. As the Logo turtle helped teach problem solving with visual feedback, in a very specific domain, what if we provide tools and languages for other contexts? If you want to teach city planning, how far off would something like SimCity be? If you want to teach economics, what would a language look like, that let you "think" in that domain, plug in variables, and watch for trends or long term effects? Should you learn Java if you want to do graphics, and figure out how to render fur or landscapes, better or more efficiently; or if you want to do advanced mathematics?
If you need to step outside the bounds of the language, for whatever reason, having an escape hatch to a parent language that has much in common with what you know...that's icing on the cake.
So, I'm not worried about people learning to program, but I do want them to learn to solve problems using computers.
Microsoft has a number of things going on to help beginners and learners. Not all of them are far enough along to talk about yet. But there is deep interest in the problem at the highest levels of the company. The idea is to help people solve problems using computers. That has pretty much been the Microsoft goal since the early days.
I'll answer this question with another question, "Is programming an Art?? A person can learn language syntax, structure, etc. But can they learn creativity? Can they learn how to take the tools at their disposal and put them together to solve solutions. Similar to an artist or a craftsman
IMHO there has to be some innate ability. Now a person who is not been a developer may have that ability and not know it, but can a person who does not have the ability develop it? In the same way can a person who has no predisposition toward art become an artist, or a crafstman?