Slashdot Mirror
Best Paradigm For a First Programming Course?
Keyper7 writes "The first programming course I had during my computer science schooling, aptly named 'Introduction to Programming,' was given in C because its emphasis was on imperative programming. A little before I graduated, though, it was decided that the focus would change to object-oriented programming with Java. (I must emphasize that the change was not made because of any hype about Java or to dumb down the course; back then and still, it's presented by good Java programmers who try to teach good practices and do not encourage excessive reliance on libraries.) But the practices taught are not paradigm-independent, and this sparked a discussion that continues to this day: which paradigm is most appropriate to introduce programming? Besides imperative and object-oriented, I know teachers who firmly believe that functional programming is the best choice. I'm interested in language-independent opinions that Slashdotters might have on this matter. Which paradigm is good to introduce programming while keeping a freshman's mind free enough for him/her to learn other paradigms afterwards?"
If you go on to do anything comp sci related, you're going to need a good background in all of these methods of programming, their advantages and disadvantages. You'll need to know when it's appropriate to use each one, and why.
CAn'T CompreHend SARcaSm?
Procedural is most like instruction list people are used to doing. However, it often leads to bad practices and sloppy coding. Object oriented can be good, but few people use object oriented beyond procedural wrapped in a class. It also is often hard to represent a good object system on paper. Functional languages to vary degrees are very nice if you didn't learn procedural before hand and can think of problems as smaller problems. People usually have trouble with them because they have learned Basic, C, etc. Logic languages are extremely powerful in that you only describe what you want, not how it should go about being computed. That isn't quite true, but think of them as more of set theory and logic. However, they can be somewhat awkward to teach.
Reserved Word.
Despite omnipresent side effects?
I've found that good students tend to do well with any paradigm you introduce them to, while bad students do poorly no matter the paradigm. Few seem to be in the middle. I would argue that the choice of starting language or paradigm is therefore not as important as people think it is.
*I teach an introductory data structures & algorithms course. The school I teach at just switched from C++ to Java.
My first language was not Scheme -- I learned bits of LOGO and [Q|Visual|Ti-calulator] Basic as a kid. However, my first course at University was taught in Scheme, and it was by far the best computer science class I've ever had. Since then, my school has tried teaching freshmen Python, Java, and Matlab and they've all sucked horribly in comparison.
(LISP, ML, Haskell, etc. would probably be just fine too.)
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Definitely functional programming.
I don't think functional programming is the place to start for the majority of students. A procedural language has a much more direct relationship to the underlying machine code. If you don't want to start in assembler (and I don't advocate assembler for a first language for a lot of reasons), a language like C, which is high-level enough to not get bogged down in irrelevant details while teaching basic algorithms, yet is close enough to the metal to give the students a taste of the underlying hardware, is a good compromise. Functional programming, while closer to the underlying math, is so different from the instructions the machine actually executes that students may finish the class and still not have a clear idea how what they wrote directs the machine.
That said, my first development environment was HyperCard and most of what I have done since has been OOP. When thinking about a problem, my first instinct is to objectify it. But, I think OOP involves learning too much at once to be the ideal teaching paradigm. Think of how many lines of OO exist in a Java Hello World program. And think how much of that is meaningless to the student when they're still trying to learn the basics of println.
... and that's when the C.H.U.D.'s came at me.
"Functional programming" != "Program with functions in it"
Rather than a specific paradigm, you should focus on what almost all languages have in common. Almost all languages operate on statements. They have variables to store data. They get input and produce output. These simple concepts are mind-numbingly dull for anyone with experience, but most new students I've seen haven't done programming before. I feel that students should enter the world of programming with some understanding of the terms used and the core functions. To this end, my personal opinion is to use a language like the old (not Visual) BASICs.
It is sad that BASIC has fallen out of favor now. Complaints of bad code, lack of power, and old age have tarnished its good reputation with little real reason. Most of the complaints I hear stem from seeing BASIC code in environments where it simply doesn't make sense. As an educational tool, it's the perfect introduction.
If I were ever to teach such a course, the first day would be a simple program, that just ENDs. Consider the basic concept there. The program starts at the beginning and runs until it's told to stop. It runs a single command. Such a simple program also allows time to understand the process of compiling. Next, I would introduce data, using a Hello World program (with an END statement, of course). There, we get data, output, and commands running in series. Again, these concepts are things we take for granted, but are of vital importance.
I'd move on to input, assigning variables, order of operations (8th grade WAS good for something!), and probably some basic conditions. If I were really into it, I'd throw in some logical operations for good measure. With the commands being in plain English, it's easier to ignore the details of the language, and focus on what the statement actually does. Best of all, there's no extra code with no apparent purpose. No importing or including libraries at the top of the program, no class declaration, just meaningful code.
After that comes the most important part of any BASIC curriculum: abandoning BASIC. Move to functions, or objects, or whatever popular concept strikes your (or better yet, the students') fancy, and don't return to BASIC again. By that time, the student should have a solid understanding of how general programming works, so they can focus on adapting to whatever paradigm comes next. In fact, I'd recommend against even telling the students they were using an unstructured language. Use BASIC as a way to understand the code itself, before trying to understand how it fits into the big picture of the program.
You do not have a moral or legal right to do absolutely anything you want.