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

Comments

Weakest Precondition Calculus

[Anonymous Coward]

Easy: follow the Gries book.

Re:Weakest Precondition Calculus

[El Cabri]

+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:Weakest Precondition Calculus

[Anonymous Coward]

functional programming is a reducible state machine. However, we're surrounded by iterative programing (eg, recipes, directions for assembling chairs, map directions, etc.), so that often seems more natural.

Re:Weakest Precondition Calculus

[jadavis]

Strange that you say that, because I've always considered most human directions to be far more declarative than imperative.

For instance, "go to the store and buy milk". If you were to try to reduce that to imperative instructions, it would be a nightmare. In fact, nobody has done it, because it's so hard to describe in terms of the myriad possible states and branches.

Along the way, you do all kinds of optimization, too. If there's traffic on the main street, you might take side streets. If one checkout line is longer, you might choose the shorter one. If one brand is on sale, you might buy that one.

All of them.

[Tokerat]

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.

[dcollins]

Unfortunately, they can't all be first.

Re:All of them.

[mbrubeck]

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.

[DerekJ212]

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.

[i.of.the.storm]

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.

Re:All of them.

[martijnd]

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.

Re:All of them.

[Anonymous Coward]

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.

[mkbc]

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.

Re:All of them.

[brilinux]

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.

Functional

[Anonymous Coward]

Definitely functional programming. OOP is an extension of this. The methods within an object are, of course, functional. I feel it's like trying to teach someone to drive with a manual transmission, in a city. It's better to let them learn the basics, and THEN learn the more complicated (and better) way to do things. Building upon the prior knowledge.

I am speaking as someone who learned functional first and then OOP, and who is now a (self-described) expert in OOP. Also, as someone who learned on an auto tranny first, and who is now a (self-described) expert at stick.

It's all about steps.

Re:Functional

[Anonymous Coward]

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

Despite omnipresent side effects?

Re:Functional

[El Cabri]

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

[Eli Gottlieb]

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.

Re:Functional

[johnsonav]

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:Functional

[PsychosisBoy]

Remember, we are talking about people who have NEVER programmed before. And teaching them how to do it.

I believe it is easier for someone to first understand how to program with functions, and then, after they are comfortable, to put these functions into a greater "whole", as part of an object.

It really is all about building upon the fundamentals. Functional programming is a fundamental. OOP is building upon that knowledge.

It's just my opinion, though =)

Re:Functional

[aiht]

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

Re:Functional

[gandhi_2]

someone called you captain obvious...but he/she is captain doesn'tknowthedifference.

functional programming (ocaml, et al) is quite a different thing than procedural. Procedural is imperative with procedures, which are often called functions, which almost sounds like functional programming, which often confuses the fucktard on /. that confused you for cpt. obvious.

Re:Functional

[dkf]

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.

Not at all. I have used a pure functional OO language in the past (the name of which I forget) and what it did when you did an operation that would "modify the state" is return the new state as the result of the method. The same would be true for any language where all objects are immutable and variables are immutable.

"Functional" means that the answer to an operation is determined entirely by the arguments to the operation and the nature of the operation itself, and that the operation does not change the state. (Functional languages are usually written in pseudo-mathematical notation, but not always.) "Object-oriented" means that your values (often structured values) know exactly what operations can be performed upon them that don't just see the object as an abstract token, that they encapsulate that notion, and that the language is written in "subject verb" form, not "verb subject". (That last point is just syntactic, but important.) Those two are entirely orthogonal properties.

Obviously, you've mixed up "OO" and "Imperative OO"; imperative systems are all about state modification.

Re:Functional

[MadKeithV]

I prefer non-functional programming. It's all the rage at Microsoft. ;-)

Both

[nog_lorp]

At my institution, the '101' and '102' courses are taught in C and Java respectively. The class I'm taking right now is these two classes combined, so my 'intro course' is taught in C and then Java. Several projects require writing the same program in each language.

Re:Both

[Xiroth]

When I went to university, the first course was in C - which was basically just preparation for the second course, which was in Assembly (specifically, MIPS). I'd say that was the most important part - a good grasp of the fundamentals of computing is really the best thing that you can take away from university. From there, all of the languages (and even paradigms - we covered the main three) were quite a bit simpler to grasp, as you could look a little deeper into them and ask "What are we really doing here?". Stripping away the mystery of compilers and interpreters simplifies understanding dramatically.

Re:Both

[mrchaotica]

...C and then Java. Several projects require writing the same program in each language.

Wow, how fucking useless can you get?! I'll bet half the students wrap their C code in a class and think they're done.

Now, if they had to write their programs in LISP and Java (or LISP and C), then they'd be getting somewhere!

Functional languages are phenomenal.

[HFXPro]

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.

[HFXPro]

I should mention anyone who is trying to peddle python against java against c are all barking up the wrong tree. Those are really all the same class of languages and offer no benefits over the other in terms of good practice, smart thinking, and great design.

Re:Functional languages are phenomenal.

[calmofthestorm]

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.

[francium de neobie]

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.

Re:Functional languages are phenomenal.

[jonaskoelker]

[C, java, python] are really all the same class of languages

Really? For three "identical" things, I think they're quite far apart.

C doesn't have native support for object-oriented programming. If you want to teach the students that, you need to embed pointers to vtables everywhere, you need parent-objects-as-members and you need massive hacks.

Java doesn't have higher-order functions; you have to put your function pointer arguments inside classes. [C at least has function pointers]. By insisting that everything is put inside an object, procedural programming "looks OO" and might distort the students' view of what "real OO" is.

Python doesn't have static types. On the other hand, it lets you teach procedural and object-oriented each in their most natural ways. It also lets you teach ideas that will recur in functional languages, such as higher-order functions, closures and lazy lists.

More importantly, python lets you teach things without having to introduce a lot of overhead: "Why must closed-over variables be final? Why is it smart to feed my own anonymous Function class to MapIterator--a for loop is much shorter? Higher order--but it doesn't take a function, it takes an object! ..."

I'd advocate python first, because it allows you greater flexibility in the choice of what to teach. Also, it's good for teaching algorithms: http://www.ece.uci.edu/~chou/py02/python.html

"The most encouraging part was that more than a few students wanted to implement the algorithms that were not assigned as homework problems. The students said they wanted to see the algorithms run and test their own understanding."

well update them....

[powerspike]

just give the courses funky and updated names like
"Whiplash and programming, what they have in common"
"the 7 do's and don't of baning your head against a wall learning OOP for beginners"
that should do the trick!

Assembler... seriously

[EmbeddedJanitor]

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.

Re:Assembler... seriously

[fuhrysteve]

I wonder if something more basic might be in order.. My degree is in Philosophy, so I had to take symbolic logic. There was a CS guy in my course though who actually went to the department and said, "this should be on the CS curriculum, because we really don't formally learn logic." Here's the guy who taught me @ John Carroll: http://www.jcu.edu/philosophy/gensler/lc/index.htm

Re:Assembler... seriously

[Average]

I'm going to agree with that. I had programmed in an imperative to mildly GOSUBby way in various microcomputer BASICs, Pascals, and standard Cs since pre-Kindergarten. However, one of the best college classes I had was the one where we were given a 6800 (later classes it was an 68HC11) on a board, with a few external circuits, and we learned every single op-code. Then, I knew what a computer (and a compiler) was doing.

They'll have plenty of time to learn paradigms. Make them appreciate what those paradigms actually accomplish.

Re:Assembler... seriously

[cong06]

+1 to that.
Seriously, assembly is great and all, but people are idiots. Assembly would just scare them away.
While I would rather the field be smaller so that there's a higher chance of me being employed, I realize that I would probably not be interested in comp sci if I was thrown assembly the first day.

Re:The Basics.

[LaskoVortex]

Brainfuck.

SICP

[Anonymous Coward]

Structure and Interpretation of Computer Programs was my first CS text and it forever changed how thought about computers and programming. I can't recommend it strongly enough.

Teach them All

[Maple Syrup]

The classic text SCIP teaches multiple computing paradigms. A fluent computer scientist should know all of them.

Re:Teach them All

[KanshuShintai]

How to Design Programs is essentially a gentler SICP, and it accomplishes most of the same goals.

Re:Teach them All

[Eli Gottlieb]

Reading the paper on HtDP, and one of the funniest conclusions is that female students seem to prefer the HtDP approach over traditional SICP or "Welcome to Java" classes by a factor of 4.

Maybe the lack of girls in Computer Science has just been because the teaching has sucked.

Linguistics

[denissmith]

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

[Fished]

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)

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

Re:Consider Python

[TromboonDotPy]

This is one of those questions that make people tend to talk past each other because they start talking about their favorite language rather than educational purpose.

I'm sure that the educational purposes that motivate professors of young adults who have declared themselves computer science majors are rather different than those for high school CS teachers such as myself. I'll talk briefly about teaching high school, and let higher ed folks talk about their educational purposes themselves.

I've taught procedural, functional (Scheme), and OO to high school students ranging from very young 9th graders to very advanced 12th graders for 18 years. None of these have been an utter train wreck, and all have caused interesting and worthwhile conversations.

Lately, I have been teaching Python to Non-AP CS-1 for a few years. It has been an almost uninterrupted joy.

I am totally convinced that ordinary 10th graders benefit from non-oo, state machine programming and tacking on oo late in the day.

This serves the purpose of reinforcing a high school student's algebra, planning and workplace skills, and a welter of logical thinking skills that I can't believe are merely computer programming, such as understanding the distinction between type and instance.

Another purpose CS-1 is serving is as a not-really feeder course for APCS. By which I mean it is not a formal requirement, but gives only a few things I have to deal with differently when they become AP students (teaching manifest typing vs. duck typing, for instance. But that's a worthwhile conversation).

I would strongly encourage secondary CS teachers to investigate Python and perhaps other python-like languages, with the warning that there's no curriculum you can take off the shelf, and will need to reauthor your course so Python works for you. I note in passing that it is also a terribly friendly language for a teacher improvising while students are watching-- it generally does what you think it ought to do.

Structured programming

[ishmalius]

I've always thought that Java as a first language was a mistake. Students are forced to learn two concepts, structured programming and object orientation, at the same time. They should master one, then the other. For object orientation being second, it is not just a programming style, it is also an essential facet of design.

Functional programming can come third. I know that a lot of FP people would disagree. But I really don't think that the beginner student would have a clear grasp of scope, stack frames, or method references until they learn something easier first. But, hey, third semester is not so late.

I like Lisp, Haskell, Erlang, etc.

[rolfwind]

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.

None of them.

[Metasquares]

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.

Re:mathematica

[Anonymous Coward]

I know I'd love to sign up for an intro to programming course whose basic software cost only four figures.

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

[mrchaotica]

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

[_greg]

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.

"excessive" reliance on libraries!??

[toby]

Re-inventing the wheel is the pathology.

One of the most significant advantages of Java *is* the availability of mature libraries! They are there to be used.

Separate ideas from the language implementation

[dougwhitehead]

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)

The political paradigm

[GaryOlson]

Take a little from every one. Then promise you can deliver in whatever language your prospective future employer wants.

Re:Some combination?

[ryszard99]

perl

Teach students something they aren't familiar with

[iteyoidar]

I think the dude who invented Haskell had a pretty good insight in this interview where he was asked about teaching functional programming for a first programming class:

I don't know - I don't actually have a very strong opinion on that. I think there are a lot of related factors, such as what the students will put up with! I think student motivation is very important, so teaching students a language they have heard of as their first language has a powerful motivational factor. On the other hand, since students come with such diverse experiences (some of them have done heaps of programming and some of them have done none) teaching them a language which all of them aren't familiar with can be a great leveler. So if I was in a university now I'd be arguing the case for teaching functional programming as a first year language, but I don't think itâ(TM)s a sort of unequivocal, "only an idiot would think anything else" kind of thing!

Teach new students some sort of bizarro language so the ones who have been programming for years will be on the same level as everyone else.

It was from this interview: http://www.computerworld.com.au/index.php/id;1974033854;fp;;fpid;;pf;1

problem solving first, programming second.

[blackcoot]

if it were up to me, i would teach a first course in computer science using only pencils (maybe pens for the foolhardy) and paper. i say that as someone who has t.a.'d a lot of programming classes.

the issue, at least as far as i've observed, is that until a student has a solid ability to start decomposing a problem using top-down and bottom-up approaches, trying to teach them any kinds of programming language or algorithms is pointless. it's like having a carburetor and no car.

i would suggest that c.s. instruction, especially at the early phases, should aim to make students spend a lot of time asking questions like: "what information do i need to solve this problem?", "what is the easiest useful thing i can do to help solve this problem?", "what's missing from my solution?", "is it easier to break this step down more or just do it right here?", "how can i join X and Y to do Z?", etc. once you get students asking those questions, picking up programming languages is a lot easier: they know what they want to do, all they need to focus on is how.

Re:The Basics.

[fireman sam]

whitespace

http://en.wikipedia.org/wiki/Whitespace_(programming_language)

Storytelling Alice

[Simina Branzei]

What about this: "Storytelling Alice motivates middle school girls to learn computer programming". Kelleher, Pausch, Kiesler. CHI 2007. Seems a useful paradigm for girls.

Re:The Basics.

[evanbd]

What's wrong with Malbolge?

back in the old days...

[micromuncher]

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.

C in intro to programming? Yikes!

[Spazmania]

I like C. I'm a C maven. But I'm *really* glad I didn't learn C first. My first programming courses were taught in Pascal. The good habits I learned there have saved me from writing really poor code when I graduated to more flexible languages like C.

Math

[spydabyte]

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.

Well, that's your problem then ...

[gordguide]

" ... I'm interested in language-independent opinions that Slashdotters might have on this matter. ..."

Slashdotters don't have any language-independent opinions. Sorry.

Not sure about others, pleased with Python

[KingAlanI]

In my senior year of high school, my senior project was essentially an independent-study intro to programming.
My advisor suggested Python (version 2.4 at the time), and thought that C/C++ was a bad idea for an intro language (C++ had been my initial suggestion)

I was pleased with the result; I felt that Python's straightforward English-like syntax, lack of funky punctuation as a structural construct, as well as not having to start scripts with declarations or somesuch, meant that I didn't get bogged down in arcane language features as I was trying to practice basic concepts.

(I came into that with no code-writing experience beyond simple HTML/CSS/JavaScript)

yet another attempted plug at upping functional pr

[Locutus]

I started reading the story intro and wondered if it wasn't another ploy to get a discussion going on functional programming since I've seen these quite a number of times in the last month. Sure enough, there was the plug and look at all the functional fan boyz talking it up.

Earlier it was multi-core programming, now this 'best paradigm for a 1st prog course'. What next, best compiler or maybe best OS for running functional programming applications?

FYI, the answer is OOP.

LoB

take it old school

[Tumbleweed]

Start with LOGO. Turtle graphics all the way!

Then you choose your platform, and go with whatever version of BASIC runs on the 8-bit platform of choice: Apple ][, C64, Atari 800, TRS-80 or Coco, whatever.

Once you've mastered that, just jump to the future and go with 64-bit asm and contribute to Menuet OS .

Your best answer is implicit by our answers....

[gandhi_2]

...not explicit.

About half of the posts thusfar, on /. of all places, display a lack of understanding of the programming paradigm-sphere.

How many posts here just extolled (or decried) the virtues (or problems) of "functional" programming languages like C and C++? Functional is not Procedural. Functional != just programming with functions.

Even here, among the (arguably) nerdiest nerds on to ever move mice... many people don't really know. So maybe you need to start there...a sampler course with various paradigms and languages so people will actually know how all these things fit together. Some functional OCaml, some imperative::procedural C, and some imperative::OO Java. Mix it up.

All, but procedural first

[GrouchoMarx]

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

Amen, brother

[istartedi]

Although, maybe, just maybe you should start them with BASIC. In other words, mirror the history of exposure that my generation got--slow BASIC, assembly to make it faster, high level procedural languages like Pascal, object oriented dreams, object oriented nightmares, and then that wierd thing called functional.

Yes, I know functional came before 8-bit micros; but for a lot of us the history I've outlined above is how it all progressed. I know I'll get flamed for this, but for many years you could come out of school without knowing anything about functional programming and do just fine. It seems like that's changed in the past few years; but we'll have to see if it really sticks. The recession might help it, since the complaint about not being able to find employees comfortable with functional programming will be mitigated by all the tech layoffs...

The bottom line though, is that underneath all that stuff you have a machine. Assembly gets you as close to that machine as possible. Everything else is just a cute wrapper for the machine. Too many CS grads have no feel for that "foundation". What if architects learned nothing about foundations?

Re:How about Turing?

[inKubus]

That and the Von Neumann architecture. What is the point of a computer really? Add, Multiply, Divide. Talk about the fundamental basic instructions, not x86 but what is a mov (oh it moves something). Translate some C code into ASM to see how that works. I would really dive all the way in immediately. You're not going to get it as a first year, but you learn by repetition, and you need concepts like this drilled into your head. Build a linux box in class compiling all the packages. After about a week of that (and resolving dependencies), you'll understand about the real meat of programming, compiling. Guess what, most languages are pretty similar. It's the delivery that makes it hard. For instance, there are things in PHP you have to know but never have to know in C, because you're dealing with the web paradigm. Sessions? Non-existent in C (well, you know what I mean). But most PHP is never compiled, yet it runs! Why is this? Compare/Contrast. Berkeley is known for two things: LSD and Unix. This is not a coincidence. Etc.

Re:The Basics.

[Sarten-X]

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.

Maybe I'm being too obscure....

[Joce640k]

http://www.pbm.com/~lindahl/real.programmers.html

Re:Not at all

[XDirtypunkX]

That's "declarative" programming. Popular functional languages tend to be more declarative, but it doesn't have to be that way.

Only C is not simple

[krischik]

C is not a simple language.

The C language specification is 500+ pages and a horrible read. C only appears simple on the surface but is full of nasty hidden surprises. The later being the reason why the language standard is such a horrible read.

I also disagree with you on the base of the for loop. The C for loop is just a while written on one line. Syntactic sugar without additional abstraction. And even as syntactic sugar a failure because you don't save any keystrokes. Compare:

for (int i = 1; i < 10; i++)
  {
  // do something
  }

with:

int i = 1;
while (i < 10)
  {
  // do something
  i++;
  }

2 characters and 2 Enter keys less - what a saving!

compare that to the following Ada code:

for I in 1 .. 10 loop
  -- do something
end loop;

Ok, it does not save keystrokes either - but it does add some higher abstraction and I is constant inside to loop - so no hidden surprises here, like in:

for (int i = 1; i < 10; i++)
  {
  // 20 lines of something

  if (i = 5) i = 6;

  // 20 lines of some more
  }

Which brings us back to "C is not simple but full of hidden surprises".

Martin

Re:Only C is not simple

[evanbd]

C should, in many ways, be thought of as a somewhat easier to read and portable assembly language. It doesn't hide much of anything from you, for better or for worse. Given the number of students who seem to manage to get rather far in their computing career without actually understanding what a pointer is, teaching a very low-level language first or very early has its merits.

That said, my personal choice would be either a functional programming language or a carefully chosen assembly language -- probably MIPS on an embedded processor. I'd prefer C to things like C++ or Java, though.

Re:Dumbest ask slashdot answer ever..

[dronkert]

How about: it's like learning to ride a bike by descending Alpe d'Huez. Talk about a crash course!

Re:The Basics.

[wisty]

Brainfuck is fine. It's Turing complete, right, and the only thing to programming is learning rules, and learning to type.

The real question is, what are you trying to teach? Programming and algorithms would be easy to teach in Python (or a lisp), user interface design would be good in Java or .net (vb or c#), web technologies would be good in Ruby, and systems programming would be good in C.

Are you trying to teach software development? What other things can you get students to memorize (or "learn", as fashionable people like to say - there is not much difference since education is in a controlled environment - yes I know that good teaching can make a difference). The stages of software development? The rules of XP? Scrum terminology? How about svn?

Re:The Basics.

[KDR_11k]

"should". From what I've seen of people who join a CS course most have never done any programming.

Re:The Basics.

[cgenman]

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 Basics-Lubrication.

[Ostracus]

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

I'm sorry but the basement door is jammed so yes it's the houses fault.

BASIC sucks!

[FranTaylor]

How can anyone seriously consider a language that is MISSING almost all of the modern features needed to express your programming intents?

Write a medium-complexity program like the ubiquitous Towers of Hanoi problem in BASIC, and then in a modern language like Scheme or python. Compare the source code of the two programs and then tell me what language is better for introducing programming concepts.

Re:BASIC sucks!

[Haeleth]

How can anyone seriously consider a language that is MISSING almost all of the modern features needed to express your programming intents?

That's one of the things that makes it a good introductory language.

There's a reason why people who started computing in the 1980s are way ahead of people who started computing in the 1990s -- and it's because we all had a BASIC interpreter pop up as soon as we switched our computers on, while the 1990s generation's computers booted into a vastly less powerful DOS shell, and too many of them were sucked into Doom before they ever discovered the joys of qbasic.

Dropping people in at the deep end with classes and objects is crazy, when they don't even grok what a variable is yet. Nobody's suggesting making BASIC the basis of the entire course, but it's a reasonable place to start for the first week or two, while people are still getting their heads round what programming is actually about. Then move onto Scheme to teach them about abstractions. Save "real world" languages like Python and Java until they know something about what's going on underneath all that sugary syntax.

Re:The Basics.

[smallfries]

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.

Re:The Basics.

[KeithIrwin]

I cut my teeth on BASIC as well, but really, it's a pretty terrible language for a beginner. The syntax is decent, in theory, but in practice, it's most of the older BASICs had weird little picky things involving spacing and stuff like that. And when you do mess up the syntax, you would only get "SYNTAX ERROR" without any explanation of what was wrong or how to fix it.

Variables don't have to be declared before use, so small typos in variable names cripple programs rather than resulting in compiler errors. This makes it much tougher for new users to debug their own programs.

The syntax also doesn't allow you to separate your code into blocks, so things like IF statements are a pain since they require using a GOTO if you want to do more than one statement. This makes the code harder to read and understand. Spaghetti code is a necessity in most BASICs.

Beyond that, being able to build functions or procedures or subroutines or some form of reusable code is fundamental to teaching intro programming. The GOSUB command exists in BASIC, but it doesn't make sense in any simple way. If you understand already what a subroutine is, then GOSUB makes sense, but otherwise, it's just confusing. Named function/procedure calls are much cleaner and easier for starting students to understand.

Obviously these issues could be solved by using a more modern BASIC, but then you lose most of the easier syntax because they've complicated it in order to add the new language features.

For starting students, I think what you really want is a language where they don't have to worry about syntax at all, where they can just get used to putting programs together. Languages like Scratch or Alice I think are very nice first languages for students to learn. Unfortunately, Scratch lacks procedures and it's difficult to build completely new projects in Alice because you have to understand things like where to place the lights and the camera in a 3-d world.

Alternately, a language like Logo which has fairly light-weight, but consistent syntax is also useful.

Right now, I'm working on modifying Scratch to meet my needs for teaching introductory programming. Specifically, I'm seeking to add user-defined functions/procedures and to be able to make projects for students to complete where they have a goal to accomplish and have a limited set of statements available to complete it.

In teaching Intro to Computer Science using Logo, I've found that a few students will want to just use Forward, Left, Right, Pen Up, and Pen Down to accomplish everything, even situations where they really should be using Repeat statements or building procedures. I want to add in a mechanism such that they'll need to use those tools to solve the problem. So if their task is to draw a square and they only have two "Forward" statements and two "Right" statements available, but they have a "Repeat" which they can use, then they'll learn to use the Repeat by necessity.

Plus, by limiting the search space, they're more likely to be able to find an answer by trial-and-error at first. In the long run, you don't want people programming by trial-and-error, but that's how most all of us learned to begin with.

Start at the Beginning

[DogLover4]

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.

Re:The Basics.

[DuckDodgers]

and most of those students will drop out of the class and/or change their major by the end of the semester. so why waste the time/tuition money of the students who have demonstrated initiative in their own academic career?

You're out of your mind.

• Some high schools don't offer software development courses at all.
• Some high schools offer software development courses taught by people who know nothing of the discipline and who will pass on false information or bad habits that need to be unlearned.
• Being self taught is good, but maybe the first teaching websites or development books or mentors you found were likewise very poor choices.
• A lot of the best senior developers in the industry night now are self taught because the CS teaching as we know it did not exist when they were younger.

At that stage in the game, the budding student doesn't even understand what he doesn't understand, so he has no ground for knowing whether his previous self-taught, website, book, mentor, or school-provided education is gold or garbage.

A good professor will take people from ground zero on day one and move at a blistering pace that still lets the hard workers keep up. I started a college CS program not knowing anything of the discipline, with two good friends that basically slept through the first two semesters and got better grades. I graduated from the program, and they did not.

Your elitism is misplaced.

Re:The Basics.

[TerranFury]

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.