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?"
Easy: follow the Gries book.
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.
Engineering is the art of compromise.
Back in 1979 my first formal course in programming started out with the Turing machine - and frankly I'm glad.
IMHO today's junior programmers don't have nearly enough background in either formal program definition or the underlying hardware that eventually ends up executing whatever the high level language compiles or interprets to.
Been there, done that, paid for the T-shirt
and didn't get it
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. :-)
I have nothing to hide. So, why are you spying on me?
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.
Maybe even scheme although it is sometimes too minimalistic. Some languages such as C naturally incline toward a specific structure like imperative, some don't. But avoid C unless they are expected to write low level code.
Why? Because out in the "real world", you are usually assaulted with C or it's derivatives. Not because these are the best languages, but they were faster when developed and took a strong foothold over the thinking of the programming community. It's rather a self perpetuating cycle like Microsoft Windows and operating systems. Another reason is that C/C++ is low level language masquerading as a high level one, with libraries to cover some of it's more glaring defiencies.
Yes, they'll eventually have to learn C/C++ or a descendant, but that is not the point: it is because they'll have to learn C/C++ that you should teach them something else. Otherwise once you teach them C, mental inertia takes over and they'll be stuck in the C mindset for the rest of their lives and cannot imagine anything else. They'll have time enough to learn C in sophomore or later levels.
Also, I wouldn't worry too much about "paradigms". Learn to attack problems one by one, making a program that fits each one best. Throw a lot of small coding problems at them, actually, to scale them up to bigger tasks. Thinking about a problem is great, but no reason not to learn coding by coding. I remember Paul Graham writing he never had used Object Orientation his entire life, although it would have seemed that some problems were initially screaming out for such a solution on paper. IMO, paradigms are usually taught as a way to evolve or grow a program an ongoing problem, so you don't end up with sloppy, spaghetti code - but I think experience and getting to see the big picture is more important than rigid paradigms. Afterall, most paradigms grew up from an person's experiences with one or a set of closely related problems that may not closely relate to another random set of problems.
Stuff like rabid prototyping, etc, are in view more common sense (and better coding methods) than an exact paradigm.
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.
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.
I was a CS major in 1979 at VT and we had a beginning course that taught principles in pseudo code and programming language and assignments in Labs. Each student was in one of four labs where they taught implementation of these techniques in: C, Pascal, PL1, or Fortran.
This curriculum was way ahead of its time. I have always felt it gave me an amazing foundation. (Unfortunately it was abandoned as the department watered down the undergraduate program to expand the curriculum into grad school)
Take a little from every one. Then promise you can deliver in whatever language your prospective future employer wants.
Every mans' island needs an ocean; choose your ocean carefully.
And yet in an impure functional language a set of closures closing over the same variables are equivalent to an object with those functions implemented as methods.
The basics of all computing, why we started building circuits, was mathematics. Algorithms was originally "dirty math" but now contains some of the most elegant mathematical proofs ever, due to the expansion of computing.
An era ago computing majors were unheard of, they were applied mathematics majors.
That's similar to what my first college CS course has been like. We used SICP 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.
All your base are belong to Wii.
How to Design Programs is essentially a gentler SICP, and it accomplishes most of the same goals.
As others have said, expose students to all three methodologies (procedural, OOP, and functional) as early as possible. A language that supports all of the above can be good for that, or else pick languages with reasonably similar syntaxes (eg, they all use curly braces for code blocks) to reduce the mental overhead.
That said, I would do procedural first. It's the closest to what the computer actually does: Execute one instruction after another in order. It is also, therefore, the one with the least mental overhead. It's easier to explain a conditional or a loop in a procedural structure than a functional structure, I'd argue. (And in that case OOP is a superset of procedural, as the code within methods is still behaving procedurally.) So the 101 course should be in a procedural language, or using procedural style in a procedural/OO language.
I did OO next, but in hindsight I'd probably suggest functional second. It's the most "mathematically pure", and the one that forces you to think about what you're doing at a conceptual level the most. It's also the one they're least likely to use in practice out in industry, but what students learn about good design in a functional language (atomic functions, no side effects, logical thinking, etc.) will serve them in very good stead later on in their careers. I only had about a quarter of one class in which we covered functional languages and I just didn't get it at the time. Years later I finally figured out what functional programming was all about and even though I don't write functional code I've found my coding style drifting to be more functional-ish, and as a result much less bug-prone and, for me at least, easier to read.
Then put it together with good OOP. You then have the procedural stuff down pat, and the good practice of how to treat functions as discrete behaviors. An object, then, is just a larger chunk of discrete behavior bundled together. It introduces the complications of state, but the idea of each method as an atomic little bundle of behavior within that larger bundle should be a smooth transition from functions as an atomic little bundle of behavior.
All three are equally expressive, but knowing all three will give students a better understanding of *how to think about the problem at hand*, which is what school is all about. Even if you're not coding in one of those paradigms, you can still implement many of the same concepts in another paradigm where appropriate. (No-side-effects from functional, polymorphism and delegation from OO, and "how does the computer think" from procedural are all applicable in all paradigms, if you're coding properly.)
--GrouchoMarx
Card-carrying member of the EFF, FSF, and ACLU. Are you?
Concepts of Programming Languages was a third year course at my University in which we discussed and formed a decent background in a variety of languages. I think you're skipping ahead. I got my kids learning with Scratch. When I was little there was Logos. But if we're talking CS programs, learning Pascal first has serverd me well - although I admit I have never encountered it outside of my University. All my first year courses that involved programming were done in Pascal. Its a procedural language that is easy to grasp - its for beginners and encourages good habits. Second year we did assignments in Pascal, Smalltalk and Prolog. It wasn't until my third year that I was expected to use C and C++. I think my University did it right in progressing to C and C++. C and C++ are for people who already know how to program so they are not good starting points.
How about: it's like learning to ride a bike by descending Alpe d'Huez. Talk about a crash course!
BASIC was created to be a highly accessible introduction to programming concepts, and it remains such to this day. Just because it isn't a tool that they will be programming with until the end of their days doesn't mean it isn't a valid option.
Also, BASIC gets a bad rap due to people who never left it. How these people survived is beyond me, but it is not the language's fault any more than it is the house's fault when the 30 year old child refuses to move out of his parents' house.
The ______ Agenda
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.
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
Wow, that sounds pretty advanced. Functional programming, with loops, through people. I've never even heard of that new paradigm.
To be fair, the loops were really tail recursive calls.
Seriously, though, I do believe that SICP is a fantastic way to learn programming; it really is very thorough, and Scheme is a great language for learning - it is small and simple, yet supports every programming paradigm you could want to teach. While I am partial to SICP, another good one is How to Design Programs, which is designed to fit in more generally in a liberal arts curriculum, so its focus is more on problem solving.
I also believe that a, perhaps basic, introduction to logic and discreet math (how to do induction proofs, what graphs are, and things like that) are also important, and should be taught before or concurrently with an intro programming class.
I have to weigh in on the side of beginning with imperitive programming. After all, that's closer to what the machines are actually doing. If you don't start with the idea that the machines are taking instructions and perfoming tasks, that concept is harder to grasp later on. I had a computer science professor who used to say that nothing is automatic. If something happens "automatically," that means that someone else has already written the program to do it.
OOP is a programming design concept. It and the languages that support it should be taught after the basic concepts are learned. Would you teach an architect how to design a house, before teaching him the basic properties, adavantages, and disadvantages of different building techniques? If you did, you might get a house made out of inappropriate materials, just to satisfy a design feature. For the vast majority of applications, you want the architect to use appropriate materials. The exceptional architects will know when to "break out of the box." This is when you get a Frank Lloyd Wright.
In the same way, programmers should be taught starting with the basics. They must know the advantages and disadvantages of all programming design concepts. They should be exposed to many programming languages, so they can see how to implement different designs in different languages. They should be taught that in the "real world" there will be business considerations that will take higher priority than what they perceive as the ideal technical solution, and that they may have to work with the less than ideal solution. To do this, they need to know many ways of designing programs, and the advantages and disadvantages of each. To understand these advantages and disadvantages, they have to understand how the higher level programming is converted (compiled, interpreted) into what the machine can understand.
functional languages are very different
I think you should start with imperative languages before doing functional programming. It's not hard to understand a loop, but kids take a long time to "get" recursion, and that's what functional programming depends on.
So, teach BASIC. Then C. Then Scheme.
You see a progression from GOTO in BASIC (easy to understand as an idea; a terrible way to program), to imperative programming with functions including recursion in C, to pure functional programming in Scheme. I think the progression of ideas makes sense.
After that, you can worry about object orientation if you want. But you should have made inroads with that by now with C (structs and functions) and Scheme (classes, polymorphism). So Java should come with a snap of the fingers.