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?"

All of them.

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.

Re:All of them.

Unfortunately, they can't all be first.

Re:All of them.

Unfortunately, they can't all be first.

But you can still do several in a first programming course. That's exactly what my intro CS course did. We worked with a functional language, an object-oriented language, a low-level assembly language, a logic programming language, and also theoretical constructs like finite automata.

Re:All of them.

That explains why so many kids drop out of CS. I was greatly interested in the subject, but if my CS101 class had tried to throw all that at me and expect me to really grok it all in a single class, I would have been looking for a different major/school.

Re:All of them.

That's similar to what my first college CS course has been like. We used SICP [mit.edu] and it was a really interesting semester. We did functional, OO, client/server, and logic programming (or well those were the 4 paradigms that the prof considered the main ones) and it was pretty interesting. Since most people came in with OO experience only, doing functional programming through people for a loop at first. Of course, we did it all in Scheme, which is a cool language, too.

Re:All of them.

doing functional programming through people for a loop at first.

Wow, that sounds pretty advanced. Functional programming, with loops, through people. I've never even heard of that new paradigm.

Re:All of them.

a logic programming language, and also theoretical constructs like finite automata.

Sounds like a great course -- however in most schools the professors will have long given in to the whining "this is not real world" crowd that sadly makes up most entry level computer classes.

Functional languages are phenomenal.

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.

Re:Functional languages are phenomenal.

I'm not sure of that, actually. C is not at all functional, and Java is only to a limited degree. In Python, all functions are first-class values. This means you can mix paradigms in a program. You have fully functional closures and capture.

I grew up on asm and C, now I write Python that looks more like Lisp or Haskell. In the end, I'd say either procedural programming or functional for introduction to programming. OOP is kind of verbose and clunky for an intro class, and while it certainly has its uses in large scale projects, when we were taught it in school I just saw a bunch of cruft obscuring the (simple) tasks that were assigned.

Re:Functional languages are phenomenal.

Really? Last time I checked...

1. There's no need to wrap a closure in a "function class" in Python. And I don't have to cast everything down to Object every so often. So while, theoretically, you can do functional programming in both Java and Python, in practice it is much easier in Python.
2. There's no need to wrap the "main()" function in a class in Python - in fact, I can go without writing the main(). Looks like a minor point but it saves a good portion of your time for trivial programs. Also, I don't need to compile it.
3. I have list and dictionary literals; I don't have to care what is the "type" of the list and dictionary when I create it - type of elements can be examined by duck typing or isinstance() if I need to - but usually it isn't needed; list comprehension is a really good time saver, makes the code easier to read as well.
4. I have an interactive command line for doing experiments. I can even read manuals in the command line via the help() function.
5. I have exec() in Python. It isn't as useful or as dynamic as eval() in Lisp, but that's something Java definitely cannot do on a language level. Sure, you can write a library that calls the Java compiler real time to emulate that... but I'm talking about the language itself.

Doesn't look very "same class" to me. At least when I'm considering which language to use for solving which problem.

Assembler... seriously

Give them a good understanding as to what is going on under the hood. It really helps them to connect the dots and really helps in the understanding of compiler/OS design, and basic concepts like "what's a stack?".

Choose a simple 8-bit micro such as an AVR first, or an ARM. Something with a RISC architecture is nice and clean.

Introduction to programming isn't what it used to be. Twenty or thirty years back that was often the first exposure a student had to programming. These days you'd be seriously concerned if a student showed up to a programming course and hadn't dabbled a bit at home.

Teach them All

The classic text SCIP [wikipedia.org] teaches multiple computing paradigms [mit.edu]. A fluent computer scientist should know all of them.

Linguistics

Ways that meaning are encapsulated in different human languages can be a useful way to demonstrate the structural underpinnings of programming languages. Linguistics is more interesting than reading Boole and gives you a way to think about larger structures without tying you to a particular paradigm. All computer languages have strengths, all are inadequate. But so are human languages. There is a Korean word that expresses this exactly, but it doeasn't translate directly into English. :-)

Consider Python

First off, a disclaimer: I'm actually not (much) of a Python programmer--I much prefer Ruby.

However, my Dad teaches Math & Physics at the high school level, and got tapped to teach an intro to programming class this year. On my advice, he bypassed C++ (which he kind of knew) and Java, and taught it in Python using this book:

Python Programming: An Introduction to Computer Science (Paperback) [amazon.com]

He has been absolutely delighted with the book and with how well the students have done with Python as a first language. His comment has been that he wishes he had been exposed to Python instead of (many years ago) Fortran and (more recently) C++ -- he might have actually learned to program. ;) It seems that Python's a good choice--it's an easy language to learn, supports procedural, object-oriented, and functional programming, and has all the usual advantages of a dynamic language for programmer usability.

Now if only they would do a version of that book in Ruby... :)

None of them.

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.

SCHEME, FOR THE LOVE OF GOD, SCHEME!!!!!!!!!!

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.)

Learn at least two paradigms WELL

I recommend learning at least two languages representing significantly different paradigms during a programmer's formative period. In this instance I consider C, C++, Java, C# and the lot to be in the same paradigm - procedural.

Haskell is a good language for exploring the functional paradigm. Smalltalk is good for object oriented. There are many good Prologs for learning logic relational programming. I recommend that a new programmer avoid multiparadigm languages until they have seriously explored programming in a more pure way in two or more paradigms.

I used to recommend SICP, now I recommend CTM [ucl.ac.be].

Also important is to (1) enjoy the programming you are doing and (2) work on programs which do interesting things and get you feedback from others.

back in the old days...

I went to an unnamed university that did not teach languages specifically. First year was theory, basic architecture, and PDP11 assembler on a simulator. There was one introduction to structured programming with Pascal.

Year two saw more theory including algorithms and data structures. The language chosen was modula-2 and we were expected to pick it up on our own. There was another low level course on hybrid 6502/68000 machines writing low level I/O in assembly. Again, we had to pick it up ourselves.

Year three got fun with hardware; async circuits, build your own 68000 based computer, OS (multitasking) and database concepts. We also had our new software engineering courses learning all about CMM and such.

Fourth year was simulation, HCI, write a compiler, and special projects. It was assumed we'd picked up C/C++ by that point on our own.

There were three streams at our U; hardware, computer graphics, or knowledge sciences. There was a lot of math - that I didn't appreciate until after I left. But one I learned is why and how things work at a low level. It was a computer science degree.

Programs like this don't seem to exist anymore; at least if they do they're more in engineering than compsci. This is really too bad. Because as one post already noted; the problem is one of problem solving vs. skills to get a job.

I still use state machines, optimization, algorithms, data structures knowledge in everything I do. Most of the people I work with have no idea why I care about such things, but usually they're impressed that my stuff just works more better.

IAE my advice to you is learn as many languages as you can because no one specific language or paradigm encompases computer science. Go do some lisp, smalltalk, java, and assembly programming... you'll see what I mean.

Re:Functional

The methods within an object are, of course, functional.

Despite omnipresent side effects?

Re:Functional

"Functional programming" != "Program with functions in it"

Re:Functional

There are no two things more opposite to each other than OOP and functional programming. Functional programming is about FUNCTIONS, which are those that return a value that is completely determined by their arguments, not depending on, or modifying, any state. OOP is all about calling METHODS, which have values that are determined by both the arguments and the state of the object they're called on, and often are meant to modify that state.

Re:Functional

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.

Re:Weakest Precondition Calculus

+1 for that.

I love functional programming but let's face it, computers are state machines and you cannot really program them without understanding how programs modify their state. Hoare. Dijkstra. Read them. Embrace them. Feel the pain of bending your mind around them.

Re:The Basics.

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.

Re:The Basics.

It sounds like you've missed the point. Not all languages operate on statements, with variables and assignment. These are common to imperative languages, which all fall under a single paradigm. The submitter asked which paradigm would be best to introduce someone to programming.

Your lack of experience in other paradigms (not meant as a slight, 99% of all mainstream work is done in imperative languages) means that you have a similar educational history to what the submitter is considering. You consider imperative languages to be the whole world, rather than just a subset of it.

Logic, or functional languages are very different. Learning them forces you to consider other approaches to programming than those that are evident in an imperative language. Making someone learn a functional language first can teach them a lot about programming in general. Especially when they move over to an imperative language, but they have a different bag of tricks to apply to problems.

One of the first languages that I learnt as a child was Logo. It's a bit of style these days, although it was fairly common back on 8-bit home computers. At the time I though of it as a bit weird in comparison to the other languages that I used, but it taught me to think about programming in a different way. It is only with the hindsight of 20 years and a degree that I can see that "weirdness" was because it was functional.