How to teach computing...

[Monte314]

What is the proper way to teach computing?

1.) focus on teaching lots of languages, tools, and operating systems; anyone who writes code for a while will pick up the theory.

2.) focus on teaching theory; anyone who understands the theory can learn the languages as they need them.

3.) focus on packaged applications; integrated tools, systems, and web-based environments have made programming unnecessary.

4.) focus on _______________.

[Saint]

Is there a proper student?

disclaimer that everyone's different, blah blah, anyway:

This question fascinates me, because I'm the support to a lot of other Computer Scientists at my school that don't so readily grasps the concepts in class. This isn't the student's fault so much as the way the courses are being taught (in my opinion)

I wouldn't say that anyone who writes code will necessarily pick up the theory. Consider how mathematics (purer computing, some would argue? They're well-related in any case) is taught. I remember teaching a friend about derivatives. She knew how to do them, she'd been doing them all year, but what she did not know until I told/showed her was that a derivative of a function is the slope of that function at any given time. She knew how to use it, but what it was completely eluded her. I blamed the teacher, who covered the material but left out the "understanding and why" bit.

That being said, I'm not sure how to teach computing well, and I'd love to hear what others have to say. I can tell you that, while I never took it, watching the kids go through Computer Science I at my school (RPI) was horrible. Classes of 250 for the first course on such a technically-related topic is slightly insane. The kids that were new to the subject only got better if they had someone personally help them. I helped a lot of kids, as did the other CS students who knew what (and why) they were doing. But this is a much more general thing than what you're looking for...


Edit: OH I should mention that the lack of teaching proper style drives me insane. Some people's code is unreadable simply because they choose to format it in a shitty shitty way. (And well, most languages have conventions.)

[qwerty]

As a general subject, the idea is to teach all :P

But I think the biggest difference between university educated professionals and self-taught professionals is that university educated professionals have a deeper understanding of the the theory and foundations.

Anyone can teach themselves a programming language. How many can teach themselves to understand and appreciate why we use certain methods.

[void]

Theory is of paramount importance. I don't agree with the hypothesis that one may pick up essentials of a theory with enough exposure to languages and development tools. A lot of experience may give the programmer an intuitive (not very rigourous) notion of formal concepts but I don't think this is sufficient. I think one of the reasons why the phrase "software engineering" is largely an oxymoron is that the vast majority of programmers have a very poor understanding of the underlying theory.

The practical aspect of programming - familiarity with APIs and development tools - should be left to the student. I don't believe having university courses teach Emacs + GCC on SUS compliant Unix (for example) is worthwhile. Of course, theory and practice are like two wheels of a wagon - neither is dispensable. But students should be responsible for acquainting themselves with the latter.

[thod]

What is the proper way to teach computing?

I assume you mean to beginners. To go into two much abstraction will put them to sleep as it has no bearing on reality to them. To bring that reality, they must participate. Thus you begin by introducing the concepts of storage such as let a=3, branching if(a>3), and iteration while(a>3). Then you get them to produce simple 'hello world' programs. Once they are able to make the computer do things it becomes real to them.

It will become clear soon enough that programs become unreadable. So then you introduce them to concepts such as the scoping of variables sub routines and functions. Dont go into the mathematical definitions of a function which is way too abstract, stick to its use in programming. Offer more little problems so they get to use them to make them real to them.

You can move on to introduce idea such as object orientation here. This will allow them to understand interacting via a limited interface to other code. From this you can introduce the idea of the operating system as something alike, which you can only talk to via the interface. And it follows that this is how all inter system code works. You would bring in the concept of protocols to explain how systems communicate over time and the notion of stateful and stateless objects.

They will have to be shown the idea of code as an ideal case and exception cases. All programs have a relatively small proportion of the code as doing the work and the bulk as handling the exceptions. The way to understand the code is simply to follow the ideal case.

At this point they should be able to produce reasonable sized programs themselves.

I would introduce some simple data structures but stay away from overloading them. There is no point in putting them sleep with 73 ways to sort a list, but they should know what a list is. You may want to introduce tables in spreadsheets or even a relational database but dont go into normalization and certainly not the matematical theory of relations.

I guess what I am saying is concentrate on the enabling part and not the theory. Once they realize the need to know deeper they will study, without that its just more gobbledygook. Most of the university level CS course books are way too much into theory and the students end up hopeless in practice.

1.) focus on teaching lots of languages, tools, and operating systems; anyone who writes code for a while will pick up the theory.


Languages dont matter much once you learn one you pick up others. This is done simply by learning the differences in notation and the new facilities available. There is little point in teaching say C and pascal since they are similar but something like SQL is different and is worth introducing. Tools are there to enable, they will pick these up themselves as the need arises. OS doesn't matter, they will only encounter MS, mac, and unix anyhow.

2.) focus on teaching theory; anyone who understands the theory can learn the languages as they need them.

IMHO theory is bad. It must be given relevance. It is only when they face the problems they gain interest in the solutions.

3.) focus on packaged applications; integrated tools, systems, and web-based environments have made programming unnecessary.

This offers a lot of potential since most people will never write million line apps. You introduce things like word processor, email, image editing etc. Thus you are are showing them things they can do with a computer which gets their interest and enables them. You could introduce spreadsheets and use nothing else for your programming introduction. All the spreadsheets have programming languages which are pretty good.

[rokxal]

Language comes first (its a much more softer introduction) but it doesn't imply that one will habitually pick up theory. The abstraction in most languages today (java,c#, c++) is too remote from concepts of turing machine and context free grammar (ruby/ocaml are slightly better but one will not understand how NFA/DFA works by simply writing regular expressions). Teaching it follows the traditional route of assigning numerous "projects" that tends to give everyone a hands-on feel of what they're expecting.

Theory is necessary and important because its essential for future innovation. Without it, there wouldn't be a formal understanding of the limitations of existing programming languages and the development of more higher-level abstractions as far as practicalities are concerned (not saying that theory exists to serve coding since theory has its own separate branch of independent study in academics).
Teaching it might be difficult as some people tend to disparage things that are not readily applicable for practical purposes. Stuff on recurrence relations, proof based run times, NP-complete/hard tend to not bode well for the non-math and non-abstract types. Good for PHD seekers, not always great for the industrial type. Best way to teach it through examples/sample problems and practice problems (aka assigned work) as without it, people will relegate it and subsequently fail exams/finals (not an uncommon phenomenon as theory classes are the typical "weed out" courses).

Packaged applications etc etc are more along the lines of specialized applications. Although an intro wouldn't be bad, the depth of these fields are usually covered in mid-upper level courses. Other than that, an understanding of web-based systems, scripting, etc is not key to CS as I see it as more of an offshoot of CS theory and languages/OS.

From my experience, the general order seems to be language->system/OS->theory->end with specialization (more algorithms/data structs, or OS/networking/scripting)

As for the difference between self-taught/formally educated: The difference is generally in the implementation and efficiency. Some people will run brute force and higher order run-time algorithms on a simple problem that should have been solved with a DP approach or through special data-structures and heuristics.

[Marcus]

What is the proper way to teach computing?

1.) focus on teaching lots of languages, tools, and operating systems; anyone who writes code for a while will pick up the theory.

2.) focus on teaching theory; anyone who understands the theory can learn the languages as they need them.

3.) focus on packaged applications; integrated tools, systems, and web-based environments have made programming unnecessary.


Teach 1-2-3 and focus on projects, teamwork, i.e. teach how to use 1-2-3 IRL.

[dtecmeister]

I would say introduce through watching a program work, then focus on how it was built including what choices and tradeoffs were made. Start with the big picture design choices then work on the details. Next walk through actually implementing the program including common tool usage and emphasis on current tool choices and possible alternatives.

Attentive study of history of CS should be covered as well as discussion of the types of problems that needed to be resolved that lead to the current standards and algorithms and what problems are still be worked on or are begging for improvement.

The core of CS can't be ignored either. Memory management, language implementation, VM and OS design, compiler and interpreter design, etc.

All popular tools should be discussed and explored.

[Mogura]

How about teaching theory, including the how and why, but using a chosen language to illustrate the practical/real world applications of the theory?

[Evil Eye]

I think it's very important to teach the concept of objects early. It helped me no end.

[ssrprotege]

Big picture first (2), and then languages; once they mastered the basic, go to the applications. Without strong basics, teaching application will be futile. Without strong grasp of theoretical backgrounds, it won't be easy to Mastermind or Architect.

[Monte314]

Big picture first (2), and then languages; once they mastered the basic, go to the applications. Without strong basics, teaching application will be futile. Without strong grasp of theoretical backgrounds, it won't be easy to Mastermind or Architect.

You've touched on something important here, my friend.

I'm always amused to hear people talk about the importance of nurtuting the natural creativity of children... which to them means "no drill, no rote learning, no acquisition of bulk knowledge by study". The honest fact is, creativity without knowledge is impossible. Facts are the raw material from which ideas are constructed, and ideas are the raw material of creativity.

Without knowledge, you can be anomalous, goofy, and apparently "spontaneous". But anything you happen to produce that looks creative is virtually guaranteed to be happenstance... a happy collision of ignorance with bliss.

[HackerX]

I might disagree to an extent.

I'd be inclined to give them enough knowledge to get them started, then let them run with it. After a certain point, stop and break down what they've done. Explain what's good, what's bad, give reasons and corrections.

Rote learning and then being given all the information to solve the problem before hand taught me nothing.

Facts by themselves are useless once you step out of your realm of knowledge. What you need to teach them is the correct way to go about finding the information they need for themselves.

[ssrprotege]

I might disagree to an extent.

I'd be inclined to give them enough knowledge to get them started, then let them run with it. After a certain point, stop and break down what they've done. Explain what's good, what's bad, give reasons and corrections.

Rote learning and then being given all the information to solve the problem before hand taught me nothing.

Facts by themselves are useless once you step out of your realm of knowledge. What you need to teach them is the correct way to go about finding the information they need for themselves.

Yes, I agree. "Enough knowledge" is, for me at least, "theoretical backgrounds." Then learn the "facts" (analogous to computer language") and then "let them run it" (application).

On rote learning: in sciences rote learning/memorization/whatever-you-call-it didn't help me at all. I memorize = I mess up. That has been my case. I believe "rote drills" may be helpful in learning some languages, but this discussion will be irrelevant.

[iceberg]

It's definitely needs to start for the theory and big picture and move toward the programs and application. In college it was the polar opposite and the hardest to understand in that way.

[allenlam]

I might disagree to an extent.

I'd be inclined to give them enough knowledge to get them started, then let them run with it. After a certain point, stop and break down what they've done. Explain what's good, what's bad, give reasons and corrections.

Very much agree. A little supplement.

In the first step, giving students a clear basic concept is important.

I have seen too many CS students who have finished their programming courses with high scores but could not distinguish a compiler from a language.

"Where can I download Pascal for my PC?" - I am wordless on questions like this.