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?"
Basic.
Simplified Imaginary Machine Programming Language for Everyone
Help stamp out iliturcy.
Easy: follow the Gries book.
I know that you said it should be language-independant, but some sort of language like Python might be good. With Python you can do object-oriented programming or not. Something with that sort of flexibility might be a good language to teach with.
the best tool for programming by far.
If you go on to do anything comp sci related, you're going to need a good background in all of these methods of programming, their advantages and disadvantages. You'll need to know when it's appropriate to use each one, and why.
CAn'T CompreHend SARcaSm?
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.
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.
Procedural is most like instruction list people are used to doing. However, it often leads to bad practices and sloppy coding. Object oriented can be good, but few people use object oriented beyond procedural wrapped in a class. It also is often hard to represent a good object system on paper. Functional languages to vary degrees are very nice if you didn't learn procedural before hand and can think of problems as smaller problems. People usually have trouble with them because they have learned Basic, C, etc. Logic languages are extremely powerful in that you only describe what you want, not how it should go about being computed. That isn't quite true, but think of them as more of set theory and logic. However, they can be somewhat awkward to teach.
Reserved Word.
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!
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.
Alice by Randy Pausch of the Last Lecture
How about instead of asking this you just go read the article posted hours ago about the creator of c++ and his views on education?
http://news.slashdot.org/article.pl?sid=08/12/09/2017242.
My first year, first semester University CS-101 course was in functional programming. I think it was a good idea as it forced us to think in a completely new way - including those of us who had some previous brushes with programming (C64-basic anyone?). Second semester moved on to C, and the joys of pointers and memory management etc.
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
Teaching assembler is the base.
After that, all digital representation can be understood as a patter on ones and zeros.
Higher-level languages can then be mastered faster.
Start at the base.
I don't know the meaning of the word 'don't' - J
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.
"imperative" and "object-oriented" are orthogonal concepts.
How we know is more important than what we know.
The classic text SCIP teaches multiple computing paradigms. A fluent computer scientist should know all of them.
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?
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:
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... :)
"He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1
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.
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.
LISP: http://xkcd.com/224/
More seriously, it shouldn't matter too much; a good programmer will pick up a new paradigm when it's needed. Less good programmers will just keep going in whatever they've learnt.
"I think it would be a good idea" Gandhi, on Western Civilisation
I've found that good students tend to do well with any paradigm you introduce them to, while bad students do poorly no matter the paradigm. Few seem to be in the middle. I would argue that the choice of starting language or paradigm is therefore not as important as people think it is.
*I teach an introductory data structures & algorithms course. The school I teach at just switched from C++ to Java.
My first language was not Scheme -- I learned bits of LOGO and [Q|Visual|Ti-calulator] Basic as a kid. However, my first course at University was taught in Scheme, and it was by far the best computer science class I've ever had. Since then, my school has tried teaching freshmen Python, Java, and Matlab and they've all sucked horribly in comparison.
(LISP, ML, Haskell, etc. would probably be just fine too.)
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
More than that, there are other concepts, like functional programming, which are somewhat mutually-exclusive with imperative programming.
And I would say, don't teach a paradigm at all. For your very first class, give them something like this introduction to Ruby. After they have a vague concept of how a program goes together, then you worry about teaching them other paradigms -- ideally, they should learn all of them eventually.
Also, avoid starting them with something like COBOL, Visual Basic, or Java. These things may tend to rot their brains.
Don't thank God, thank a doctor!
A very good read related to this is "The Perils of Javaschools" by Joel Spolsky. http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
I think that paradigm choice is secondary compared to teaching in a way that will stretch the student's mind.
C++ was the language I used when I started getting serious about programming. Before that I used Basic dialects. My experience learning to program in C++ wasn't very enlightening. There were just a lot of compile-time errors, and I spent a lot of time looking for them. If I'd had a teacher it would have been much easier.
I think that if you're going to go imperative, the best choice is a bottom-up approach, in which you start out pretty close to the metal and go up from there, not focusing so much on computer science theory than on pointers.
You don't really appreciate garbage collection unless you have had the pain of managing the memory manually.
The approach that I think is best, is to start with a very high level language in which you can teach basic computer science without the language getting in your way. Preferably a functional language =)
I first learned programming by reverse-engineering binaries in a hex editor. Starting out, I edited data structures in the program to see the effects; later, I started working with interpreted bytecode and later assembly language. I was 16 at the time. A year earlier I had tried C and just couldn't comprehend how it worked -- but there's no way to learn how computers run that provides the same experience as ASM and hardware manipulation.
I'll freely admit that OOP was a huge leap at first. My brain focused on efficiency in terms of cycles rather than programmer productivity. However, it took less than a year to become proficient in C++ and as a result just about any language that works in a similar way.
Now I'm in college studying engineering. Were it not for learning programming two years ago, I would be nowhere -- probably some liberal arts major with no idea of where to go in life. I can't comprehend learning programming in any way other than this one, and yet I see online people saying, "don't learn assembly, it's too hard and not very useful." It took me a while to realize that different people learn in different ways, and they tend to recommend the way they learned most to others.
They make a great context for learning, and are fun too, appealing to a broad community at various levels. A number of groups are exploring, researching and promoting robotics-based beginner programming classes. Gaming and multimedia provide other great contexts for learning.
The paradigm is less important IMO -- as someone already said, you ideally need to understand many. Context is the more important factor.
It should definitely be in a CS curriculum, bit perhaps not in a first programming course.
Engineering is the art of compromise.
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.
A couple of days ago Slashdot had Twenty Years of Dijkstra's Cruelty. In it, he proposed using a non-executable language to force the students to use formal methods to prove the correctness, rather than trial-and-error testing.
I was quite disappointed to see the conversation devolve into Python -vs- C -vs- Java -vs- Haskell, all of which are not what was proposed.
Has anyone gone to a University that does it the way Dijkstra proposed? (Does the University of Texas at Austin still do it this way? Any comments on it if they do?)
I'd think if your aim is to be a programmer at a commercial house later coursework would need to emphasize the skills needed for making successful software, as Stroustrup emphasized. But would Dijkstra's course be a better starting point?
OOP isn't an alternative to imperative programmg - it's a form of it.
OOP is contrasted with procedural design - also a type of imperative programming. The classic description of the difference between the two is that to implement a written specification, for OOP you implement the nouns (objects), else for procedural you implement the verbs (procedures).
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.
you had me at #!
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.
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
programming in *any* language is better than talking about programming...
Why do the CS teachers always draw the stack from top to bottom? When I get a stack of anything I start putting stuff on the bottom. If these types of paradigms are used its no wonder people don't get it.
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.
Oh my goodness. What you learned way back when, "when they did things right", or even recently, is not relevant. As someone without a background in programming, and no, not everyone has one, particularly outside of the Slashdot community, I would like to be informed in an introductory language that will be A) useful, B) relatively easy, and C) representative of the broader scope of programming languages.
I don't think it's unreasonable to ask Slashdot for advice in this matter. I can't wrap my mind around this pervasive notion in the computer science/software engineering community that if you don't have knowledge of every language known to man from the get-go, you are a worthless cad.
If someone could just state a language and a justification, I would be everlastingly grateful.
Twenty cents doesn't go very far these days.
*ducks*
I'd start with the way CPUs process code which is typically imperative, covering Python, assembly then C. Python so they can get the high-level concepts if they are new to programming as a whole. Assembly so they can see how instructions are truly carried out on a machine and issues related to instruction sizes, etc. (mov, cmp, jmp, .. keep it simple). Then C, so they understand why imperative programming is structured the way it is. I'd then cover its perceived weaknesses (I love C but understand its shortcomings) and why C++/Java/others were invented around C. I'd then introduce them to Haskell, Erlang, Scheme/Lisp, etc. that completely break away from this model and why. Give a little history on their purpose and assign real-life examples to work through so they may have a warehouse of tools at their disposal rather than a hammer.
That's the way I wish I would have learned it. If a student is passionate about programming, he'll find reasons to explore more languages and understand their niche regardless, but as I said, the discovery would have gone a lot faster if I had been taught it rather than wondering around without a guide, ie, being self-taught.
She even taught object oriented programming using Scheme (yes, you can implement encapsulation and message passing using lambda calculus quite easily).
Later we applied those principles to other languages (the most popular choices at that point were Modula-2, C, and of course C++).
I have never used Scheme in a professional environment since, but the lessons learned then still stick with me almost 20 years later.
What about this: "Storytelling Alice motivates middle school girls to learn computer programming". Kelleher, Pausch, Kiesler. CHI 2007. Seems a useful paradigm for girls.
My first language at the university level was Meta. Technically, it was Scheme/Lisp. From there on out it has been all C/C++. I'm finishing a course in Assembly.
A computer is a turning machine, and people easily relate to procedure based programing at first. Object programing encapsulated procedures in side of objects methods for various good reasons. the concept of objects is just a little harder for students to grasp at first. once they have a decent handle on those then I'd introduce the concept of recursive programing, and then stack based programing. Once they had the basic concepts form these four approaches to programing then really start expanding their awareness of other types of programing models and exposure to many languages. On of the most educational classes I had in collage was comparative languages. In that class we solved the same 10 problems in 10 different programing languages. Really opened my mind to the fact that every problem is different and while there are approaches that allow the problem to be addressed in any given language, there were some problems that were obviously much simpler to some in some languages than in others. Any competent programmer today is a multi language programmer and picks up the next language quite easily and quickly. This is where the college would really excel at providing graduates that were really ready to enter industry as productive people. -jeff
-jeff Thank God that I am Vertical and Employeed!
CS is not about programming I know ... but still, starting off with pure math without any applied courses is just a bad idea (at my uni advanced logic is a freshman course for CS BTW).
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.
/\/\icro/\/\uncher
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.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
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.
" ... I'm interested in language-independent opinions that Slashdotters might have on this matter. ..."
Slashdotters don't have any language-independent opinions. Sorry.
The university where I work on IT Staff tries to thread the needle on this. I am taking a beginning programming class for the first time in 20 years. While I did some BASIC and Pascal (I even just rediscovered Logo from my prepubescent days!), I had long gotten away from programming, turning into a hardware geek. But I went back to pick up some new skills ... the school uses Java for most of its classes, including the first two intro classes. Later, for the majors there is some C, Python and Assembly. But the instructor I had this semester tried to teach code first, emphasis on getting things working, before picking up classes and objects late in the semester. Contrast that with other instructors teaching different sections of the same course that go all out for the OO approach. Still, the focus of the major is that a student should be able to step out into the real world and adapt to any number of languages within about a week;s time.
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)
I listen to both RIAA and non-RIAA stuff if I like the music, tangential business/politics nonwithstanding.
I teach information system to a bunch of folks in a Business School where it is infra dig to be viewed as a programmer !!! Being a programmer myself I find this ludicrous but have discovered that by using Gamemaker -- a visual development environment for arcade style games -- i can get across the basics of Object Oriented Programming with much less effort. Many of my students do not realise that they are actually writing programs but get a good idea of objects, attributes, methods and instances !!! Gamemaker is available free of cost but it is not open source.
Insight into much, Influence over nothing !
What makes C a good introductory language is that it is simple syntactically. The core language can be picked up quickly, and then work can be done.
That is is imperative/functional/low level/high level doesn't really matter. A good course will cover roughly the same algorithms material.
The important thing about a first programming language is that the language should get out of the way.
Good educational languages:
1. C
2. scheme
Languages that shouldn't be used for intro courses:
1. Python
2. Java
3. C++
4. small talk
5. SML
These are all excellent languages (except java) but they all have something in common. They implement polymorphism (either runtime via vtables or compile time via generics/templates). Think about that for a second, how do you teach polymorphism to someone who doesn't know what a loop is? You don't. That stuff comes later.
In addition, the "for each" loop which most of these languages have (now even C++), hides the details of iteration and recursion; which are important concepts you want to teach.
Finally, the fact that the underlying language already implements all the data structure and algorithms that you are trying to teach undermines the course, because the question always comes up "why are we learning this when it is already written?".
#include <stdio.h>
void def_msg(const char *carp) { printf("Goodbye Cruel %s!!!\n", carp); }
void alt_msg(const char *carp) { printf("Hello %s!!!\n", carp); }
struct statement {
void (*msg)(const char *);
char *who;
};
int main(int argc, const char *argv[])
{
struct statement say = { def_msg, "World" };
if (argc > 1) {
say.msg = alt_msg;
say.who = argv[1];
}
say.msg(say.who);
}
Up until a few years ago, I taught programming languages at a few different summer computer camps, to kids basically ranging about 9-17 years old, for a total of about nine or ten summers. And for what it's worth, I also currently work full-time in a science/tech program for middle school and high school students in an urban area.
For the not-yet-(anywhere near-)college age groups, I have found that C++ is by far and wide the best teaching language, mainly due to its flexibility. That is, you can cover OOP if you want, but you don't have to. You can cover interaction with actual computer memory, but you don't have to. Etc. I think that is a much more important premise than narrowing the root of programming excellence down to one singular paradigm.
The actual discipline of computer science, like virtually all academic fields, is not actually laid out in a nice, neat, linear, easy-to-teach, and trivially-defined path. C++ gives new learners of CS many different avenues to branch out to without the rigors of learning multiple languages as an initiation ritual. Say what you want about the language in general (or for any other specific purposes) but it is an absolutely fantastic teaching language because it has the potential to cover many important paradigms.
As a high school students, one of the most mind-numbingly annoying things about our school's programming courses is that they are taught to the lowest possible denominator... in Java. To the point at which we can complete an entire semester of assignments in the first week or two of the course.
If you're going to teach, teach. Some of your students are not complete idiots, and are capable of going in depth on data structures, basic algorithms, etc.. The other ones can spend a semester teaching themselves how to make a hello world program without understanding what's going on. Or fuck it and just fail them.
I guess what I'm trying to say is, some of us students aren't taking computer programming so we can blow it off and get a bullshit A. And courses that aren't doing it right turn us off to the entire field.
I'd say perl since they're going to end up cranking out garbage code anyway once they get hired. They may as well get used to the world's first "write only" programming language.
On a serious note, I vote for C as the first programming language. It has the ability to express high level abstractions while also letting the students do things like arithmetic on characters. It's critical for a first course that students at least begin to understand both extremes. They need to understand that computers work on bits and they need to understand how a program can still present an abstraction.
Languages that hide too many of the underlying details leave students with the impression that the computer is doing some of the thinking for them. They don't understand that everything the computer does boils down to pushing bits around. At the other extreme, assemblers mean the students spend way too much time mastering arcane syntax while learning very little of what a computer can do. The students understand the bits but then switch to a petroleum engineering major that pays well and they can understand why it's important.
Besides, we need a new crop of kernel hackers.
Cheers,
Dave
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
My first programing language was GW basic. I believe the first thing you should learn is the logic behind programing before you learn how to implement it.
This is my list for the order programs should be taught in. FTR
GW basic -> WTF is programing
Visual Basic -> Lets Go OO
Visual C++ -> Where the real programing begins
PHP -> In a server far far away
Cold Fusion -> now we're just effing with you
In all seriousness, I started out in middle school tooling around with BASIC, but my real programming career started out with functional C. It's very basic, and simple enough to learn, and I have found that even to this day every new language I learn always seems familiar... like C. I definitely see the value in Java, mostly for teaching OOP, and I think its a great second step. If they start out with C and get their feet wet with it and move on to OOP, it seems like a solid foundation to build on.
Since it is a first programming course start simple but get them doing something that is interesting. A powerful declaritive language that can do some cool thing will help motivate the student. They will get a glimpse at the possibilies and power in what they are doing. Maybe an interpretted lanquage with its own environment would be a good choice, such as something akin to Matlab. At the end of the course you can start to introduce the other concepts like OOP and functional languages. Give them problems that are difficult to solve and then show them how these problems are address in other languages. That can't learn it all in an introductory course. Give them a taste and they can go where their interests take them.
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
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
It sounds like you already have your mind made up so I'd just go with that.
Libraries are what make or break languages. Libraries are the cornerstone of modern programming. No libraries? You need to start learning digital logic and buy a breadboard.
If you can understand BASIC then you can understand ASM. Well, that was my order and it worked out well for me. BASIC teaches you underlying routing and design. ASM teaches you wtf is going on. Everything else becomes, well, basic.
What do people think about Processing as a good first programming language? I'm learning it, after not having done any programming since the 80's (BASIC and APL), and it's very easy to learn. It was intended as a way to teach graphic designers and artists how to program. This might be good in a course for non-CS majors.
There's some liberal-arts school that teaches Forth as a first programming language. The idea is that it's close enough to the machine to make it clear what's really going on, but abstract enough that you can get reasonable amounts of work done with modest amounts of code. It's like the MIT approach of teaching Scheme; nobody writes much production code in Scheme, but it's a straightforward language with a clear underlying model.
(I'm not recommending writing anything real in Forth at this late date. Twenty years ago I used it for some robotics work, but only because there wasn't a C compiler for the 68HC11 at the time.)
Next class, the professor explained recursion. He demonstrated its power by solving the Towers of Hanoi recursively in four (4) lines of Pascal.
Zing. 25 years later I remember that moment crisply.
The difficult and crucial part of teaching is motivation.
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 .
It does not matter that Scheme is not commercially successful.
Scheme is a very simple language to understand and learn, yet it contains EVERY tool necessary to write the most sophisticated programs. It is the perfect language to learn how to program.
This is like your six year old saying, "Name me one Tour De France rider who uses training wheels".
MIT turns out a lot of great software people, Scheme is what is taught in their introductory class.
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.
THL phish sticks
BASIC is a terrible introductory language. It is very limited and it will forever stilt your understanding of how computers work and what you can do with them.
You really do not want to spend your introductory programming experience learning about memory allocation and why the computer does funny things when you run past the end of an array.
I learned on C, LISP, ML and JAVA, back in mid-90s. But the interesting thing is that I haven't really used any of those languages post college. I have instead used vbscript, bash, powershell, python and occasionally C#. Do I think my studies were a waste, not at all, I learned the core theoretical concepts behind programming. In fact I would argue my college (University of Pennsylvania) Profs had the following view (if we were going to teach you want was in now, it would likely be out by the time you graduate) so instead we are going to teach the theory so that when you "get out" you can focus on the "in" language you need to succeed. They gave me the fundamentals and I merely needed to learn the symantics of whatever language I meeded for a project. It has worked and when I find people who haven't had the theory and I try to explain something or witness their confusion, it is just so clear they are missing huge conceptual parts. That said, I think python is a good language to teach with because it is so simple to build useful apps that in JAVA or C would take many many more lines of code. As for when to introduce objects, that is a hard one, some books dive right in, others delay. I think objects are to big to get your head around at first, new programmers may think you understand, but there is a lot there. I think it is best to go over core fundamentals, variables, assignment statements, if statements, loops, etc. first and then bring in objects. I think you then need to teach and reteach objects in various ways so you can make sure they are understood. For me I thought I understood objects from the beginning, but looking back there was some fuzziness, which is hard to explain now that it is been clear for awhile now. I think explaining object oriented programming concepts repeatedly, but using different teaching methods, examples, etc. helps to make sure students eventually have that point where it "clicks". As a disclaimer I am paid to be a network admin, who uses scripts to make my life easier (Should make sense now why I use the languages I do). Only reason I avoid PERL is that I like to build scripts that are readable by others.
Respect the Constitution
A good programmer should be able to write FORTRAN code in any language.
No sig today...
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?
After assembly language everything is piece of cake.
Why not use Donald's Knuth MMIX language?
Teaching Java to beginners is bold - but not a good idea, in my opinion. It is the old argument about learning to walk before you start running.
The merit of C is not just that it is a very simple language to learn, if not to master; the real merit is that C is almost as close to assembler as you can get without it being assembler. This is a good thing, because in order to handle computers well, you have to understand how they work at the lowest level, and that includes machine language. It may well be that a mediocre C programmer is not as productive as as mediocre Java programmer, but we are talking about beginners here - they are about to learn the basics, in principle from scratch.
Object oriented languages start at the other end - the finished SW product, the user interface and just about as far from the actual computer as you can get without ditching it altogether. Of course if your aim is only to produce programmers that can make software without knowing what lies beneath, Java is not a bad choice even for a beginner; however, if that is all you can do, you will end up writing a lot of fluffy interfaces and possibly even some very good ones, but what are they going to look like inside?
As far as I can see, it is a lot better to start from the bottom as they do in most other areas - on the other hand, it is necessary that students can see results of what they are doing in a fairly tangible way; which is why you should start with C - it is still the best compromise between low-level understanding and high-level productivity.
After SICP, every computer language becomes very easy to learn, and you see how they are mostly all the same underneath.
If I am going to teach a first year programming in a local college, I will use Smalltalk(Squeak).
Learning C++ as an introductory language is like learning to ride a bicycle by climbing l'Alpe d'Huez.
languages like Haskell, Scheme, Lisp or Prolog?
easier to learn, if you ask me.
GENERATION 25: The first time you see this, copy it into your sig on any forum and add 1 to the generation.
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?
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
You know, I just realized: The fact that you answered "both" (referring to imperative and OO) when asked what programming paradigm to start with perfectly illustrates why you're wrong!
All CS students are going to learn imperative and OO anyway. But if they don't learn functional programming first, then they have no clue what a huge chunk of computer science they're missing!
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
http://www.cs.berkeley.edu/~kubitron/asplos98/dilbert.html
Read Pynchon.
You want to spend your introductory computing experience learning about data structures, algorithms, objects, etc.
You do not want to waste time learning about the difference between pointers and arrays.
You do not want to know why the computer cannot tell that you have indexed past the end of an array.
You do not want to learn about memory allocation and why the computer cannot do it for you.
These things can come later when you are comfortable with the concept of telling a computer what to do.
I always thought that CS was more about theory, which means that a low level language should be the first. How low depends on the faculty, I suppose.
If you really want to understand what's happening, assembly and the various ABIs are really the only way to go. What are the downsides of various ways to implement C++? What are the tradeoffs between different CPU architectures? Why use a register vs a stack-based model? What kinds of problems are better modeled in certain languages than others?
Most of these questions can't be answered by learning Java. Heck, I doubt anyone these days even reads java bytecodes and notices how crappy the optimization is (hello, has anyone even heard of CSE?). Have you thought about how OO causes code bloat because you can't strip dead code?
If you care about the language, then you should be looking at why certain things are in the language. It doesn't really matter what the language is. Why doesn't Java do MI? What are the issues with MI vs mixins?
98% of computer work today is basically gluing libraries together. It's probably more like 99.999%, but I'm being kind. Most coding is bugfixing, or working around decisions made years ago by someone without enough time. That's not CS, that's plumbing.
First language to learn? It should be z80, 6502, or 68k. They're nice, expressive, and relatively simple. x86 should be next because it's so common, then RISC, either SPARC or PPC. Maybe a VLIW would be nice. Not sure the custom chips (cray, thinking machines) matter so much - include them if you have time. Then branch out into subsystems (the storage hierarchy), I/O, etc.
That is kind of contrary to the point it seems. A huge chunk of computer science indeed, but almost useless in industry (perhaps the ideas are usefull, but how many jobs are there in functional languages?).
I think the question you should ask yourself is:
"Do I want to be a computer scientist, or do I want to be a programmer?"
The Admin and the Engineer
Teach them compiler!
Dumbass.
Functional programming is where you tell the computer what you want, and you leave it up to the computer to figure out how to do it.
SQL is the best known example of functional programming.
I agree, Pascal was an almost ideal teaching language. When one starts out, OOP and functional are usually too much to take on so early. Pascal is a well-structured procedural language that doesn't have the most of the pointer and "ram-memory" hang-ups that C does. Pascal is a very "clean" language (perhaps too clean for production code).
In my opinion, there's not much that beats it for introductions still. The only drawback is that it's not really used in practice. If one starts out with C, at least they are learning a common production "resume" language, despite fussin' with all the pointer/RAM weirdness newbies will encounter with C.
I don't know why they generally stopped using Pascal for teaching. Even back in it's heyday it wasn't a very common production language, so that can't be the reason.
It also has some nice ideas that I wish newer languages would adopt, such as type and scope indicators being on the right side instead of the left; and nested functions (with nested scope). But it's one-pass compiling was a bit annoying because you had to order your function definitions just right. But that seems fixable without busting backward compatibility.
Table-ized A.I.
For me, learning functional programming in comp sci was the most eye opening. This was part of my programming languages course. We did functional programming in Lisp, but we had to use it purely -- we couldn't declare variables. That, combined with what my OS prof said once, something like "there is no useful program that doesn't take input and produce output," gave me proper insight to what a clean, purposeful software solution is.
With functional programming, where you have no variables, everything you produce is a function of your input. Constants and the source code itself consist of the input. And of course your only goal is to produce output.
You can make designs that achieve a lot of functionality with a small amount of code by following that idea. Lisp itself is proof of that.
You can also create emacs. I'll stop here.
Moderators should have to take a reading comprehension test.
Scheme and so on are swell and functional programming is cool... ...but name one significant real world application made in such a language.
Try all of them - because the concepts I learned and mastered in Scheme were invaluable in every programming language I used after (and there were many).
Linked lists? Maps? The very concept of mapping over a set? The ideas that may not fit more naturally in other languages, fit very naturally into some problem domains and it's invaluable to know they exist even if sometimes the language you are in does not make them the easiest thing to do at times. There will be many things that come naturally to a language, that a language will be very good at - but if you can take a step outside whatever box you are playing in, then my friend you really have something.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I think we all could take a cue from the French, and start some of our programming classes in one of the ML families, like Caml Light, Standard ML, or my personal favorite Ocaml. These are fairly advanced languages, and support both imperative and functional features, so you can teach for loops AND recursion. Of course, you can do this with Lisp too, but honestly, the syntax of the ML families is a lot better than Lisp. Also you can do object-oriented programming with Ocaml.
In addition, Yale also taught its intro CS class in Standard ML a while back, and I understand it was a big hit.
Of course, it's the course content that matters the most, but why limit yourself? As already stated on Slashdot, FP is increasing in importance due to its ability to handle parallelism, so I think you can really have the best of both worlds with these impure functional languages.
I think the best way to start is with the absolute basics --- assembly language with a few simple instructions such as ADD, MUL, DIV, TEST, JMP, LOAD, STORE, and then add the notion of a stack and subroutines with SUBR and RET. Introduce Boolean logic with instructions such as AND, OR, XOR, NOT, and binary operations such as SHL and SHR. Then, once you fully understand the low-level mechanisms, you move to a higher level language, e.g. C, which still has intimate connections to assembly. Show how the higher level language translates simply to assembly. Introduce the ideas of a heap, processes, virtual memory, inter-process communication, threads, synchronization, files and I/O, etc. Then describe functional programming and object-oriented programming (e.g. LISP and C++). By this time the students are sipping from a fire hose, but once they understand the machine and the basic mechanisms that underpin all the higher level abstractions, then understanding all those higher level abstractions becomes much easier.
Every other language has been suggested, I suggest learning SQL.
SQL is functional programming. You tell the computer what you want. You don't know or care how it does it.
SQL is clearly not a general purpose programming language. That's not the point.
When you are learning, you need to take small bites of knowledge and chew them well. SQL will teach you to have patience with the computer.
SQL will teach you how to organize your data. This is a lot more important than you might realize. Getting the data structures right can turn hard problems into easy ones.
Don't bother with that JOIN stuff until you are comfortable.
Then move on to another language. Keep coming back to SQL as you learn the other language.
This will get you a good theoretical foundation and you will also have a great marketable skill.
Python has all three paradigms built in, for the order; functional programming should be taught first because it's so foreign to how we think naturally, any extra stuff in your brain beforehand will make it harder to learn. OO next, because it's the method of choice for most companies. Procedural next because it will be applicable to their next few courses (Data structures, assembley) Make sure you teach the Computer SCIENCE part during it all, not just "Here's list comprehensions and lambda functions and this is how you use them" They need to know wht they are for, how to get them to do something useful, and when it's really the worst tool for the job (It's really good to identify the best tool, but it's imperative to recognize when your using the worst) If the schools had more time for teching the programming part and didn't have requirements that suck up all of the CS time with exteranious bull, I'd say do LISP, Earlang, Prolog, C/C++, Java, Python,in that order.Get datastructures after they can program (second year) and assmebler. Work on the stuff that is uncomfortable first, otherwise they will want to stay with what they learned first. I taught myself Python first, and I love the language (I did BASIC back in the 80's). But I Taught mysef C next because I couldn't grock the functional languages, I can get them to do stuff, but I'll never reach for them first for anything because they aren't taught and they aren't something you can just apply to any problem at hand. Java and C# are painful for me, and I need a refrence next to me to do anything useful (Hell, I keep my Bjarn book handy so I can get strings to do what I want), but the libraries are huge, and not the first thing you want the students to work with. Datastructures should be taught concurrently with the OO languages, because the basic job of programming should be understood beforehand. They compliment nicely and you need both before you start on the design patterns stuff. That is just the oppinion of a humble self-taught 34 year old student at a fairly prestigious UofM (I'll leave the M as a guess) that is rather dissapointed with the curriculum at that school. More theory and branching out past what the job market is looking for is necassary for a well rounded education in CS. Networking is important, but not moreso than learning how to solve a problem in different ways and being able to come at a problem from a different angle when you get stuck.
Before anyone posts comments about "functional programming" I hope they read a bit about what it actually is. Compared to C and C++ functional programming is like programming on LSD the first time you try it ... it works by magic. Essential to know this stuff, in fact I haven't touched it in a decade ... about time I picked some of it back up again, eg Erlang.
What most people here seem to be calling "functional programming" is actually imperative.
Bitter and proud of it.
http://www.pbm.com/~lindahl/real.programmers.html
No sig today...
Teach thinking. Not a language, and not a paradigm.
SICP lays good foundations. An intro course is basically a survey course -- intro to concepts with some basic practice thrown in to help cement the concepts with repetition. Remember, you're laying the foundations for Computer Science, not for programmer-tradesman.
Unless you're teaching CS at a trade school of course, in which case go through some basic concepts with pencil and chalk, then use something like python and work your way from simple logic controls (if-then), to functions, to objects. The second course can teach Cobol -- I mean Java, or whatever it's called these days.
Or the community college version: html to get the toes wet, followed by css and perhaps javascript for the "gifted" students.
I'm still of a mind that the first computer programming class should be with pencil and paper with a grid to sketch out what's happening in memory. Most of the programmers I meet (or interview) don't really have a solid idea of what's going on in memory, and the art suffers because of that. And don't even get me started on the number of C projects out there that don't use data structures simply because the language doesn't provide them.
Don't let the student touch a computer until they're actively thinking about how the data they're working with is organized and how they want it to be organized. That would be a good start.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
You know that paradigms are independent on the programming laguage, you choose? It is perfectly possible to write object-oriented programs in C. It's the way you think during the programming process. A language can support a certain paradigm very well, but that's all it can do.
I would still recommend C, because it's the most universal language. It has a trade-off between minimal and useful syntax.
In the end it depends on the focus. If you are teaching some funky mathematicians, you better use something functional. When your students are interested in business jobs where you often have to orchestrate smaller process components, teach them BPEL or other process languages.
Object-oriented programming is important, but it's difficult to teach and difficult to understand for someone who hasn't seen how to operate a computer before. The students often don't understand why you have rich syntax to define classes, objects and their relations and you have to spend a lot of time to teach them "the why" and not "the what".
I forgot to point out that it *would* be possible to write more complex queries instead of mixing with an app language *if* they had a better query language. SQL does not scale in complexity very well unless you make lots of views. If you need one-off views, this is not practical. This is an area that SMEQL shines: it makes it easy to create temporary virtual views for the scope of the query only.
Table-ized A.I.
OOP is a good set of practices that, when applied correctly, can be used to increase code reuse and readability. However, this is not at all what matters at the initial stages of learning how to program. Before one learns how to write "good" (or rather, "maintainable") code, one has to learn how to write code in general. Most (all?) OOP-centric languages introduce too much extra scaffolding, which may be beneficial for real-world programs, but is simply noise for "hello world" stuff - and most things that are written when first learning to program are "hello world" stuff.
FP is more interesting, and I'd say that it can be a good candidate for the first paradigm, but only if it is paired with a Math course of the appropriate level. In other words, it would work if you can just say, "remember how you've learned what recursion is in a Math class last week? well, let's see how we can use it here". Similarly, things like tuple types and declarative algebraic notation (Haskell-style) have straightforward counterparts that can be used to aid understanding. In this case it has obvious advantage of immediately reusing knowledge that is already obtained elsewhere.
However, on its own, I do not think that FP is a good first paradigm to learn, especially if one learns early (e.g. in school). It abstracts away too much, and, without the necessary math background, can be very non-obvious and hard to explain. In this case, I'd say go for the good old procedural style, preferrably with some clean and readable language: Pascal is an old favorite (though you'd want to pick a dialect with pointers, such as Borland's, to deal with linked lists and such) and Python is a pretty good modern alternative (but not C, definitely not C!). Surprisingly, OCaml is also pretty good if you stick to the imperative subset of it - it has all the usual stuff such as "for" and "while" loops, single-branch conditionals, and so on, and can really be used in largely the same manner as Pascal; and pervasive type inference helps to explain the basic concepts first before even bothering with types.
Ada has five paradigms build in: concurrent (rendezvous and monitor-like based), distributed, generic, imperative, object-oriented (class-based).
The fact that you say "all three paradigms built in" shows that you have not yet arrived.
The language paradigm is not important. The whole point of programming is to get the computer to do something. The algorithms are what is important. Teach how algorithms work, then teach how to implement them. Problem solving is what it boils down to, whether you are trying to make a quick and dirty script or Skynet.
Treat every programming paradigm as a tool; these tools are there to solve a particular type / types of problem. There is no one size that fits all. There will be a lot of people out there to tell you which is the right way forward - but I think you should decide. Just keep programming and learning new languages. Use what you learnt to solve problems. The joy of programming is in programming.
Every language is a product of the philosophy of its author or authors. It will certianly help to understand the rationale behind why the particular author choose to create a new language and its features. In many cases the restrictions that one (author) faces / faced whilst developing / designing the programming language doesn't hold good after a while - because computers are getting faster or there has been a new algorithm developed that helps solve the problem better / faster. So what was true once is not true anymore.
Please don't fall into the trap of fanatically following any particular language. I did that and I paid a huge price. The more methodology and languages you learn, the more you will appreciate and understand how to solve similar problems in multiple ways. Who knows after a while you may go on to create a perfect programming language which we might end up learning about. All the best!!
This doesn't answer your question? Does it??
The short answer to your question is, theer isn't any correct answer. You can start with any paradigm that you are comfortable with; remember what is more important is to solve problems!! Imperative programming is not a bad place to start but its a personal choice.
hhmmm...functional with oop definitely like in Perl/Ruby. In addition, student should read this article in their first programming course. http://www.catb.org/~esr/faqs/hacker-howto.html
My first programming course was taught on a TI-59.
Pure algorithms, really. Learned a lot.
Never ended up going into comp-sci, though.
I say imperative in anything but C. Pascal is a good choice. C just gives people already struggling to wrap their brains around new concepts to much rope to hang themselves with.
C is not a simple language.
// do something
// do something
.. 10 loop
// 20 lines of something
// 20 lines of some more
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++)
{
}
with:
int i = 1;
while (i < 10)
{
i++;
}
2 characters and 2 Enter keys less - what a saving!
compare that to the following Ada code:
for I in 1
-- 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++)
{
if (i = 5) i = 6;
}
Which brings us back to "C is not simple but full of hidden surprises".
Martin
Damm - made an = == := error - again! But it highlight another C problem - Ada would not stand for a typo like that - but in C it compiles and fails at runtime...
This guy in our office once did a short expose about Aspect oriented programming. It involves implementing features that can be logically grouped as Aspects across classes. The way it was done was by generating additional Java code, so to program a new Aspect, you would work with a bunch of generated code includes before compiling your classes. It made me feel very confused and I never used it, but who knows it might actually be good for something, so, there you go. What I used to jump from procedural to object oriented, was Flash 4. There was the library of assets and you can instantiate them onto the stage, change properties and all instances would change too. That's what made me understand the basic concept. Not sure how many Flash developers will be in your first time programming class though. But that's what helped me understand OOP when I started.
I find it disgusting and appaling how people see introductory classes as an appropriate place for mental masturbation and lengthy sermons. Students with no previous experience have no reference points, no idea what the teacher is talking about when he describes differences between things that he believes to be best and worst practices in programming -- they have to either share the teacher's belief or dismiss it as impractical bullshit, in both cases getting superficial knowledge and no feasible way to apply or verify it.
Introductory class should first and foremost serve the purpose of providing the foundation for future study, introducing concepts, describing ideas and mechanisms that student will have to understand while studying the rest of courses related to CS, Engineering or IT. To do so, it must describe the subject of study -- purpose and application of software, basics of computer architecture, programming languages, formal logic, algorithms, data representation and data structures, languages, CS theory, various (!) approaches to software design, role of operating systems, interfaces and protocols. By the time the student has a firm grasp on those concepts and he is ready to think about applicability of procedural, object-oriented or functional programming, quality of C++, Java or Perl design, or look for a plausible excuse to use SQL, the semester is over.
Taking this into account, C is nearly perfect for most of such introduction. The language itself has a very simple syntax, so student is not distracted by learning details of some psychopath's design and implementation decisions. There is no overwhelming ideology pushed through the language except maybe simplicity and modularity. Same language can be used to illustrate workings of hardware, data structures of increasing complexity, operating systems, various approaches to programming, etc. without creating false impression of those concepts being implemented by isolated pieces of software and set in stone by wise and powerful language designers. Knowledge of C helps with learning new languages and serves as a demonstration of simple and unambiguous syntax designed for easy parsing and understanding.
Obviously the introductory course can't be a year of C and C alone -- students have to see how a different language design matches a purpose of the language -- however no other language is suitable as a proper introduction to the wide range of concepts that CS student has to understand. Least of all Java (the whole language design is a giant sermon on how some guy thinks, people should program), C++ (Frankenstein monster of programming languages), Perl (sure it's usable -- but it only makes sense if you are stoned), PHP (same but you have to be a stoned teenager) or BASIC (stoned toddler?). LISP/Scheme is good as an example of an approach that is drastically different from C, however I don't think, it works as this "foundation of all foundations" -- it's a thing in itself, so it doesn't help to get an idea how it is all tied together.
Contrary to the popular belief, there indeed is no God.
With programming, the foundation is in your head, and the apex is in the computer. Learn how to express your programming desires first, then learn how they get translated into the stuff that hardware executes.
I don't really understand your question, respectively the reason you're asking it. However, I can tell you this much: If you're just starting with programming, start with OOP, otherwise your barriers to enter OOP will be significantly higher. In your case it could be that you're spoiled already and will have a steeper climb towards OOP. In that respect C is just about the same distance away from OOP as Basic.
That aside, I don't really see your problem other that you're problably to preoccupied with the academic approach to programming, which is, quite frankly, something like 20 years behind reality.
Just go out, get an OReilly - I recommend the Python line of books (http://oreilly.com/catalog/9780596513986/#top), as it is a neat universal PL - start working through it and then find an FOSS project and join it or start your own, preferably some academic stuff you're doing just now and are interested in. Don't get to wound up about the OOP/imperative/functional 'war', as most of the ragging on one or other 'programming paradigm' - whatever the f*ck that is exactly anyway - is not much more that professional trolling to make oneself or the discussion sound more important. Find your PL, become good at it and get the job done. All else is just icing on the cake and you'll find out early enough when to add it.
My 2 cents.
We suffer more in our imagination than in reality. - Seneca
I see different technical merits in teaching asm/c/java/python/functional languages first.
There's another factor though, the reason my first formal course was a functional language: it levels the playing field between students that have grown up with C/Java/Python, and those that have never coded before. Even those with a lot of procedural programming experience can scratch their heads when presented with recursion, currying, closures, and other concepts that functional languages promote.
it's presented by good Java programmers who try to teach good practices and do not encourage excessive reliance on libraries
Maybe you would like to see the source of what seems to be 99% of the content on TDWTF
You're right though, I always find that I have way too much time to waste and money to burn in my job. This is why I also choose to ignore well designed, supported and tested libraries in favour of rolling my own.
It's just like a big recursive simile where everyone is trying to explain everything using similies that don't really match up with each other.
I think it would appeal to a lot of students to be shown the hammer and to try knocking some nails in before they're taught about velocity, kinetic energy and force times distance.
They should be taught it, make to mistake about it, but not as the first thing (in my opinion). It'd be nice to have some evidence to back up either position, though.
Teaching Turing machines first seems like you're teaching Latin first in the French class.
Wait, were we talking about the teaching of computer science or the teaching of the craft and art of programming? ;)
C has a horribly complex syntax. Go ahead and write a C parser in C, and that will illustrate the point nicely.
C forces you to learn WAY too much about the guts of the computer before you can get anything done.
You are EXACTLY wrong about Scheme. Scheme was designed from scratch to incorporate every principle of modern programming technique while stripping away everything that is unnecessary.
Very strange opinions.
Note that I remember a time where the following where sold as one of the advantages to of C - showing off the true limitless power of #define:
#define IF if (
#define THEN ) {
#define ELSEIF } else if (
#define ELSE } else {
#define ENDIF }
It does actually work.
Trust me (I used both languages extensively) C make far more unmaintainable code as Ada.
I still think that's a good start point. A procedural language, that's pretty strict about it's enforcement of basic rules.
We're talking about first starting learning to program, so it's my opinion that going foraying off into the realms of OO and functional paradigms just muddies the water and makes it inaccessible to the true beginner.
Pick up something that requires you to 'behave' whilst doing it - and for this reason, never ever C or it's ilk, because whilst it's powerful it's amazingly good at letting a 'newbie' do stuff that horribly breaks their code in insidious ways.
Object oriented and functional is something that do need to be covered, certainly, but they're a little more abstract than 'make computer do a list of things to produce a result'. Some languages also have a tendancy to be too powerful in my opinon - a lot of the OO stuff has this massive laundry list of stuff you can do with object method calls, but doesn't actually help you understand what's actually going on.
So whilst I'd never use Pascal again by choice, I'd still recommend it as a starting point for a true beginner.
If it's a full course, then try to make them write something very standard (an assembler for your preferred platform) in either C or ML (depending on taste. I participated in teaching this to beginning engineering students. Not only they learn how to program in the chosen language, but they understand how the computer works and get to see their code functioning and doing something they always knew about but never thought they could tackle.
Use Design Patterns and algorithms as a starting point.
Computers science (and programming) has everything to do with problemsolving, and this should be done in an abstract way. (A specific programming language is just a tool, just as the paradigm it belongs to.)
As a side effect Design Pattern books especially introduce you to several language specific implementations of the patterns. This gives an exceptionally good practical insight of what a specific programming language defines.
At the other end of the spectrum, an introduction to assembly language is a good idea.
Especially the discrepancy between assembly and abstract concepts will trigger curiosity, attention and true insight.
J.
In my university (LinkÃping university, Sweden) the intro programming course is lisp, interwoven with the calculus courses.
I recommend you to read this study about CS education... it mentions that even if you can try changing paradigms, techniques, tools, there is a single factor that students bring on already when starting the course which has more impact on their results than any other change.
I am not saying that every paradigm is the same, only that you're not starting "optimization" of the course at the most relevant problem.
"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.
Shai Schticks:"You don't make peace with friends, you make peace with enemies"
it went
introduction to programming
algorithms
assembly (starting with flipping toggle switches and progressing from there)
and beyond this you could go in many directions
the first language isn't critical. the important thing is to learn the basic approaches, a bit of how things are really working, and that there are many ways to do the same thing, and many languages that you can work with (and non of them are 'the one true language')
With Python, you can freely mix paradigms in a way that feels natural and convenient. You can use it in a procedural way, object oriented or both, while taking advantage of its functional programming capabilities, such as built-in functions (map, reduce, filter...) or list-comprehensions (taken from Haskell).
I think for taking decision on paradigm, language, etc., we should first ask we're going to teach programming to whom?
A computer engineering student? Imperative paradigm and Assembly + C should be a good start.
A computer science student? Maybe they should better be introduced to all of them and then go deeper in imperative. (One reason for imperative is: because algorithms are usually described in an imperative style.) I don't see much benefit in getting them involved in pointers and such; the language can be something simpler such as Python (which looks much like pseudocode!).
Math students? Maybe functional is better than imperative to start with.
You say for others.
Persian Project Management Software as a Service
Do that first. It seems[citation needed] it is easier to switch from OO to functional/imperative than the other way round. So I heared.
Well... if you want to program in the future, create scaleable software and like functional programming.
But still want a rich and proven environment.
Then maybe you should learn about F#.net
It's a multicore language, and i know plain basic is a lot easier, but to sharpen (#) your mind about programming then a functional language would make you a better programmer. I dont say it will be easier, it will be different, if you want simple code simple programs its more easy to start with basic. afterall its called basic
I know you're out there. I can feel you now. I know that you're afraid. You're afraid of us. You're afraid of change.
Unfortunately the premise of this question is somewhat flawed. The effective use of a programming language depends on understanding the paradigm >that language effectively supports. Since programming is hard to teach independent of the language, I would say that the best paradigm to teach is the paradigm the language itself effectively supports... and that a curriculum in programming should include several languages with emphasis and instruction on the paradigms they push.
Hmm.. I see a post about Stroustrup weighing in on educating software developers.. wonder what it says..
Probably off topic, but this sounds pretty similar to the CS/SE course on offer at University of Melbourne, Australia. Any chance this is where you are/were studying?
Speaking as a 1st year SE student having taken 'Introduction to Programming' in C, I don't recall the lecturer really focusing on the fact that what we were taught was any particular paradigm. I think it was simply stated that it was one of many ways to do it, and that if we continued to study within the CS/SE faculty we would continue to learn new/different ways with their own up/downsides. I really don't know what paradigm was taught (don't flame me yet), but whatever it was, I understood and enjoyed the course not because of what we covered, but how it was covered. So stop worrying about what you teach, and focus on how you teach it, I have friends at other institutions who hate what they're doing (seems to be the same thing but in Java) and actually transferred to my uni a year later.
FWIW, we studied functional programmming the following semester (Haskell), I absolutely loved it. I've seen a lot of you say so far that FP will throw a lot of C programmers off, but I got it pretty much straight away, and I'm really not a fast learner. Just had a fantastic lecturer.
"Too often I have seen programmers assuming infinite precision in their real numbers and similar errors that someone who has dealt with the reality of bits and bytes would never do."
These are errors on the part of the computer. The user wants to represent 1/3. He cares not why the computer cannot do it. That's the computer's fault, and it is easily remedied.
If you really want to start from that direction, then why not start with quantum physics, proceed into semiconductor theory, VLSI design, thermal design, clock skew, finite state machines, etc?
Much better to start from your head and work towards the hardware instead of starting with the hardware and working towards your head.
"How" backwards!!!
When you want to learn to play guitar, you don't start with acoustic theory and the physics of plucked strings. You start with music theory, melody, harmony, chords, etc.
[Preliminary note: In the following text I use language and paradigm interchangeably. The reason is that programs are, more often than not, built according to the paradigms embraced by the languages they are programmed in.]
The paradigm/language chosen to start with is IRRELEVANT as long as the programming language used:
Also of equal importance is the IDE used. While many programming teachers seem to be concerned with the paradigm/language to use, I think that the choice of which IDE to use is equally important.
I personally learned programming using the Turbo Pascal IDE from Borland (Dos based). It has all the "features" mentioned above in a manner that is easy for a beginner to use.
Today I tend to recommend C# as a language since it also provides the required facilities.
With regards to which IDE to use I shy away from presenting VisualStudio to beginners, prefering to recommend the use of SharpDevelop instead.
Important: once a particular starting language/paradigm has been well understood... encourage your students to proceed with other paradigms and languages.
- "They misunderestimated me."
Object oriented paradigm is not a true paradigm, but an extension to the procedural, or imperative, paradigm.
We sill have objects (classes in Java vs. structs/modules in C) that have states, and we call methods (functions) to modify those states. Functions have side effects, and assignment is destructive. Encapsulation, inheritance, and polymorphism are not new paradigms, its just that C++ and Java support them in language syntax and semantics, making it much easier to use.
The other true paradigms are functional (i.e. Lisp) and logical (i.e. Prolog).
Lisp also brings the dynamic aspect absent from C/Java world.
I would never teach students Java, no matter how good the course is. C/assembler would be the mast to learn machine internals and pointers, and Lisp to learn stateless and dynamic programming.
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.
linky
This sig all sigs devours
I've just written an article trying to explain various languages paradigms and consequences:
http://hc.fullpliant.org/doc/language/overview
And another one for advanced programmers explaining why meta programming is a more important feature than others (because more general) and must not be handled just as syntactical rewrites:
http://hc.fullpliant.org/doc/language/meta
My first programming subject was "Algorithms and Data structures" in wich I learned Pascal and muLisp, great stuff for learning.
Nowadays they teach C, wich I think is a huge mistake. The reason is that students get themselves lost in C sintaxis, tricks and optimizations rather than paradigm comprehension.
Use an old basic like the GP recommends, with a simple text editor or interpreter environment. Kids do not need the complexity of visual basic or visual studio interfering with their comprehension of the fundamentals.
The best paradigm to introduce programming to someone is procedural programming:
1) it teaches the person to separate functionality into subroutines. This is the first step for every other paradigm (object-oriented, functional etc).
2) it introduces the concept of variables. Functional programming languages don't have variables, so they are not suitable for teaching the concept of storage, which is central to programming.
3) it is simpler than object-oriented programming. Object-oriented programming is procedural programming coupled with many other concepts.
Two of the best languages for introducing someone to programming are:
1) the programming language Euphoria. It's very simple, but it contains all the basic concepts.
2) the programming language ABC, which is crafted for teaching and introductory courses.
Object orientated stuff adds a lot of complexity before you can start to even learn how to code. The fact that people even mentioned the difficulty in constructing a good object model diagram seems to reinforce my idea. When you are trying to learn how to program and someone spends hours teaching you how to read UML and then showing you diagrams you'll get bored out of your mind.
Procedural languages in general let the student jump right into making programs that do stuff. As the course progresses they'll learn better ways to do things, figure out what helps them prevent bugs etc. But pushing off the satisfaction of "making something" well into the future as OOP fans tend to want to do is not a good idea.
You know that it doesn't have to come first right? In my Uni we had to learn the basics first (variables, conditional statements, loops, etc). Then we got onto Java and C++. After that we were exposed to a whole bunch of different languages, including Scheme. In fact a whole class was dedicated to Scheme and the concepts behind functional programming. It was a lot more useful to be able to code in Java/C++/[enter non-functional language here] to get other subjects done (really, how can you learn software engineering concepts or write a simple filesystem if you can't code anything) than wait until everybody had learned functional programming before learning anything else.
It was made rather clear to us though that programming was much more than Java or OO though so I guess we all knew it was only a part of the programming world that we were being taught.
Silly rabbit
I have observed that engineers can write bad FORTRAN in almost all programming languages.
When the people fear their government, there is tyranny; when the government fears the people, there is liberty.
My first course was "Introduction to Algorithms" and was taught using TrueBasic. The greatest advantage to this course was that it was about the basics. Not how to write a function for X language, but rather how to write a function, how best to utilize loops (and we did stay as far away as possible from GOTO, though in Basic it was sometimes unavoidable), etc. It was a class that forced you think in logical paths, to think like a programmer. We learned to plan how we wanted something to work before diving headfirst into code. Though I took classes in other languages and more advanced concepts later, I maintain that that first algorithms class was by far the most beneficial and carried the most knowledge down the line for not just the remainder of my college career, but also my actual career.
Those who have telepathy have no need to RTFA.
Maybe because Ada is not actually horrible.
Maybe because Ada is only called horrible by those who never used it. At least I now of no seasoned Ada programmer who calls Ada horrible.
Which is unlike C / C++: I know several seasoned C / C++ programmer who consider C / C++ horrible and only use it because they have to. Some posted right here in this discussion a little further up.
Maybe because any seasoned programmer I know of with in deeps knowledge of Ada, C and C++ will choose Ada if he / she has a free hand.
Maybe because I have more experience with the matter then you.
And why use monopace? Because code tags don't work any more on "plain old text" posting.
Martin
They are all three good languages, that are good for programming in. They aren't related to some kind of stupid advocacy nor inflated egos. Knowing any of these will teach you about important programming concepts and give you a good start to becoming a software engineer.
Java on the other hand is a very poor choice. In my career (10 years) I've met many "Java Programmers". They all sucked, every one of them. It seems like all one trick ponies that gets thought only Java, or never ended up grasping any other language, never really understands the art of programing. I've known many Software Engineers on the other hand that did know how to program Java, among other languages, and many of them have been very good at what they do. This leads me to belive that Java is a horrible choice to teach. It's easy to pick up, it's easy to use, but it is not a good programing language at all. There is 0 need to teach it. Any half way decent softie should pick it up in a week.
I'm going to end with a brilliant qoute (which I am paraphraising, probably badly) by Jimmy Nilsson (google him!): "Everyone should learn a new language every year".
So you might have a first language you learn, but if that is also your last, do not bother...
PS Lua and Javascript are two other great languages to teach. And if you are teaching kids they can have imidiate use of it as well. Addons for MMORPGs and webapps :)
"
Jacopini-BÃhm, and I say this because it's more like...walk before you run.
I am tired of seeing developers that learned to program OOP first, and have almost no idea on what's involved in actually getting shit done. What I mean is, they don't know what the OS does internally when you ask it to open a file, or read from a file, or put stuff on the screen, etc.
You asked for language-independent opinions, but...I think the way to go is:
-Structured programming: Learn control structures, flow: Pascal (boy, will you learn what's a datatype)
-Structured programming: a little lower, learn memory mgmt, pointers, a better world: C.
-Structured programming: install DOS 6.0 and play with assembly (now we are talking)
-Object oriented programming: Hello C++
-better OOP: Java
-make the brain work a bit more: lisp, clisp, etc. You probably won't use it, but it will help you analyze problems better.
I hope that helps.
What's wrong with relying on libraries? Why reinvent a tool if it's already there?
I started with C. I think it is important that folks understand the concepts of pointers and memory management prior to hitting references and garbage collection. (and structs/unions before classes/interfaces.) As Spolsky once (glibly) said, there are two types of people in the world, those that understand pointers and those that don't, and taking C first helps figure out what group you are in.
While modern techniques like dependency injection, interfact driven design, event driven programming, etc are key to being a good programmer, I feel like that stuff is best learned after getting a good grasp of good ol' functional low-level programming basics.
That said, maybe the world can be divided up into "those that just want to hack up web pages or spreadsheets", and "those that want to be hardcore programmers." Because if you just plan on hacking some VB or javascript, then I don't know if you need to know C.
Well, I learned basic interpreters first and I turned out all right! As for instruction, The first I ever had was watching "Bits and Bytes" with Billy Van and Luba Goy (Canadian TV series, some clips are available on youtube). It's (obviously) the only first exposure to programming I ever experienced. It's taken me an additional 25 years or so to get to where I am now, but I have to say it was good beginning.
It had cute little animations about bits being light-switches and the CPU being a long-nosed cartoon character putting numbers into boxes. I still think about computers like that.
For example: Bits and Bytes: Program 1
My first computer science course was based on Scheme. It was my first exposure to recursion, and my first encounter with a language that didn't have artificial boundaries (such as the 4-byte integer limit, or the delineation between an integer and a float).
My second was an obligatory introduction to C and Unix.
My third was a completely theoretical course, utilizing only pseudo-code on a whiteboard.
Despite the fact that I wasted the remainder of my post-secondary education on video games and alcohol, I have always found this 'trifecta' to be an excellent introduction. To put it another way:
1. Teach a language that opens up new possibilities (such as Scheme).
2. Then teach a proper baseline (such as C/C++).
3. Then get theoretical.
J
Jesus told him, "I am the way, the truth, and the life. No one can come to the Father except through me. - John 14:6 NLT
And I say this as a functional programming zealot. It's hard to learn a new paradigm at the same time as you're learning to program at all, and both functional and object-oriented programming require you to shift your perspective a lot. So teach imperative programming first, because it requires the least adjustment to one's way of thinking.
I am trolling
not Java.
If what you care about is being "useful in industry," then go to DeVry or ITT or one of those other vocational schools that advertise on TV.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
I am just finishing a Computer Engineering degree up in Canada..
The way we did it here, first two courses were in Java. The first one started with functional programming, but quickly gave way to OO. The second course was heavy OO. The third focused heavily on design patterns.
Afterwards we moved to so called "Digital Courses" at which point we sort of started from scratch. All VHDL and Verilog, building simple state machines (counters, handshakers etc).
After that another course on Assembly, moving up to C, at which point about 2 or 3 about programing on various embedded platforms.
I think this approach is good... Get your feet wet, understand some high level concepts... and then get right down and dirty and understand how the fundamental blocks are working and slowly build back up.
just my 2 cents...
Programing should make your life simpler, it is a tool. It can also be fun, like crosswords or suduko :)
I would start with a shell (bash or fish) and show the power of piping, and move on to python since it supports most paradigms. I belive different paradigms are suited for different persons and problems. We should not force one view.
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.
My college (MIT) offers very few real programming courses. Its presumed that almost everyone had learned how before attending. This was as true 30 years ago when I attended as now.
For an "Introduction to Programming" course, how about pseudo-code?
Teach the concepts using pseudo-code, then give examples in specific languages, and paradigms. You could use a C inspired pseudo-code, so that the format and syntax would be near that of C, C++ and Java; and that would give you imperative and object oriented. I don't know enough about functional to comment on that.
You could also use pseudo-code to introduce the differences in the various types of programming.
Better yet, I think I have run across pseudo-code interpreters from time to time.
Another way to go, if there is enough demand is to offer multiple variations of the Intro course. "Intro to Programming with C++", "Intro to Programming with Java", "Intro to Programming with Haskel", "Intro to Programming with machine language", or whatever as desired and enrolled by the students.
This signiture copied from somewhere.
My first programming language was LincolnLog, followed by TinkerToy and then LEGO.
Start on the metal, then work up through the abstraction stack. Machine code is all the damn boxen do anyway, and it teaches hard discipline and later appreciation for higher-order language features.
If x86 is too ugly, start with a cleanly designed emulator like MIX (er, MMIX).
Happy DEC-10 day.
at this site: www.thedailywtf.com
And no, you probably don't want to read it. It may just scar you for life.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
Logic ...
Doesn't matter what you want to do, if you can't define a logical progression of states, you can't get anywhere in programming.
High level math class is all any person needs ... the syntax only takes a couple weeks/months to master.
Best practices for coding is really just a matter of opinion. Any paradigm that is preformed cleanly and consistently is fine.
Let me clarify the example: Perhaps they should mention that Double-precision has limits in class #1, but not get into the nitty gritty of how floating point works just yet.
Table-ized A.I.
The term object oreinted is used to describe a different set of characteristics of programming languages than imperative is. An object oriented language, like Java, is a programming language supporting user-defined complex type hierarchies and allowing creation of individual instances of those types. An imperative language, like, for example, Java, is one in which statements describe the steps to be taken in order to transform input into output by a sequence of changes in program state.
Imperative programming dominates most venues of practical use and is also the closest to how the computer operates. The other two common paradigms, functional and logical programming, are much further from the actual behavior of the computer as a device and closer to the mathematics behind programming. They are both worthwhile, but I think that imperative programming is probably the best way to begin, especially since many novice programmers have difficulty grasping the mathematical concepts.
From: Dave Thomas's book The Pragmatic Programmer.
Don't Repeat Yourself (or DRY) says that every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation. A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation.
Given all this knowledge, why should you find one way to represent each feature? The obvious answer is, if you have more than one way to express the same thing, at some point the two or three different representations will most likely fall out of step with each other. Even if they don't, you're guaranteeing yourself the headache of maintaining them in parallel whenever a change occurs. And change will occur. DRY is important if you want flexible and maintainable software.
I've lost all my marbles except one & It's fun to test angular & centripetal acceleration in my skull
I learned BASIC first... then assembler. I think it would be hard to jump right into assembler. BASIC gives you the ideas of how things work, and some of what NOT to do. :)
I was in CS in college back in the late 80s/early 90s. I know things were different then, but I learned BASIC, Fortran, Assembler, Pascal, C, C++, Lisp... probably some others I can't remember. I do remember avoiding COBOL like the plague. I took an OS and hardware class, wrote a bootstrap, etc. I am sure many here had similar experiences. I can't say I use really ANY of it now, I chose the path of testing once I got out of school, and have since moved into project management. But it has always helped me to have those languages / experiences under my belt. It's much easier to communicate with developers if you can understand them and speak their language.
My beliefs do not require that you agree with them.
Cortland Starrett has met with good results teaching high school kids Executable UML. http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=04281135 This will put them ahead of their peers in college, as they will have better insight into proper partitioning of the problem spaces present in a system.
OTOH, they may have trouble understanding some of the illogical approaches taken by their professors and peers in the name of "good" OOP, or have trouble talking problem solving at a lower level of abstraction.
For my first programming class, the instructor based his curriculm off 5 concepts common in all (ok, most) programming languages.
1. Input/Output
2. Saving Information (variables)
3. Arithmetic and Boolean logic
4. Selection Structures
5. Looping Structures
He hammered these concepts into us, even making us memorize the list (I wrote it up from memory).
While it isn't perfect (and not entire accurate), it is very effective in teaching a laymen the basic beginnings of programming. Allowing them to decipher bits and pieces of code, in just about any language, that was once foreign to them. I have found it to be quite effective for beginners.
Back in the old days, when we had to walk to school in the snow, uphill both ways, we learned to program the _right_ way. All you you wimps should have to do it that way, too. First, you start by learning to program an 8088 CPU in machine code using DIP switches. Then and only then, you learn how to use A86 assembler. Then you learn a strongly-typed language like Pascal to learn discipline. Then you learn object oriented programming. (I will leave the choice of an object-oriented language as an exercise for the reader. I dislike the sight of blood.) Then you learn cloud computing, neural networks, quantum computing (you _did_ take four years of theoretical physics, right?), or whatever is currently in vogue. Then and only then you learn to actually do something useful, say with AJAX. Can't find a Cromemco 8088 or Z80 computer on eBay? Build one from scratch. (I also think all this garbage about letting medical interns sleep four hours in every twenty-four and one day off in every seven shows how deep the moral rot is penetrating.) Well, what are you waiting for? Go get your soldering iron.
I believe that the first course should be about problem solving. In particular, problem solving using a computer.
Use a language that lets you focus on problem solving and not on the details of the language. My personal favorite is Python.
(I've taught introductory programming using FORTRAN, Pascal, C, and C++, and, yes, I do have gray hair).
IN my college physics labs they gave us bad equipment on purpose so that we could learn how to make sensitive measurements with crappy gear. At the time I thought this as insane. But later in graduate school I learned no this was sheer genius, since all I was ever doing was trying to make a measurement that was just a bit beyond the (theoretical) capability of existing equipment. One had to have a really good grip on how to do error models, and how to remove noise, and how to tweak uncertainty principles to get gains in places you want while giving up things you don't care about.
When I learned languages, like basic, I was always trying to write other languages in that language. e.g. bootstrapping a pascal interpreter.
and now I get to my seemingly crazy reccomendation. I understand python and java today because I leanrned Perl first. with Perl, object oriented programming is the equivalent of the visible man. Everything from inheritance, to how attributes are indexed to how the heirarchy of subclass method resolution is traced is at your disposal to tweak.
it's the "visible man" on languages.
turns out python objects are just a subset of perl's object method. Under the hood they work identically. i.e. pythons __dir__ is the same as a blessed hash in perl. python's slots are the same as a blessed array in perl. You just don't get to see them in action in python but they are there lurking underneath.
So if you really want to understand object oriented programming. use perl. it's not a good language to write huge object oriented programs in. But it makes you see how all the magic works and how tou can change the magic to do some really great things.
and that will bake you a good scientist. otherwise learning one language well just makes you a good programmer.
Some drink at the fountain of knowledge. Others just gargle.
RAD - It's the most interesting and people need as much help as they can get to stay awake during a computer programming course :-).
When you start out it certainly helps to understand there are different ways to develop software and this really depends on a lot of different aspects. The realy question is what resources are available? What expert knowledge is there? Does the customer know what they want or do they need help to get the specification correct?
A good software architect would know that any large software project may involve several paradigms, each working for a given area. For example if you want to build an interface for a system you may pick to develop using a rapid application development and mix and match with other paradigms.
If you wanted to build software for medical equiptment or missiles then you'd have to look very closely at how to make sure it's safe.
My course taught us to look at the complexity based on how many instructions there were, and how many different systems were involved. This helps decide on how much time NEEDS to be dedicated to testing any given module and what 'cycle' you should use to develop.
I would start with a language that's easy to use and gives easy access to graphics. A beginner needs to learn "concepts" not syntax. I like BASIC because you can create simple shapes and learn all about double buffering and screen modes without having to learn much syntax. You can also learn how to make functions and implement basic AI. BASIC would allow students to make games within the confined time of a semester or year.
Then, if the student decides that this programming thing is fun they can be aware of DirectX, OpenGL, etc and when they go to learn how to use it they know the concept of screen modes, double buffering, functions, loops, logic, etc which makes learning the new more powerful languages significantly easier. Games require a vast array of concepts that can be applied to any programming project.
It would take a week to learn in C what can be learned in a day with BASIC. Students can then be self motivated to learn the more complex version of the basic concepts on their own time.
The next class should get into more powerful languages that show how the concepts learn in BASIC are applied. Then you don't have to waste a semester showing students that all languages implement many of the same concepts. They'll figure it out on their own. And they'll know the concepts so they can figure out how to use any language quickly.
Work Safe Porn
The OP is talking about a first PROGRAMMING course. Not a CS degree specifically. The goals are not really the same. If you're teaching someone to program you don't really want to start with the low level stuff. A CS grad needs to know that stuff, but I don't see why it should be covered as "Intro to Programming".
As far as paradigm, imperative. Why? Because it's going to be kind of familiar to newbs.
Language? BASIC or Python. Java is nuts. I shouldn't have to tell a newb about classes and objects. Or, worse, to tell them to ignore the magic statements. You can do "Hello World" in a single line of BASIC. No magic. Python is similar, but with a better library.
Teaching programming should be about programming, not machine level interactions. Teach things like variables, operators, conditionals, and loops. Teach it in BASIC first, then Python. You're not teaching syntax or algorithms here. Once they can do those, you can move to more complex stuff like functions. After that is the time to start talking about objects. A newb can start making sense of what an object is and why they should care to use them at this point.
Functional programming is very different from how most people seem to think. It's useful to learn it though, so perhaps the last month or so can be dedicated to functional. Show how to do some of the things we already did in a functional way. That way, the student can see that there are different tools that might be better for various problems.
Pointers, memory management, objects, classes, and other such things aren't really "into" concepts. They layer on other concepts. A good programmer needs to know them, but they don't need to start there.
I think many of you are missing the point... the object is to get intro students to learn programming. ANY language will teach them the basics of logic and structure IF they are taught - but what will ignite the imagination and give immediate results?
Why not a web dev environment like PHP or RoR?
In addition to being decent languages, the students can get really fast results and an immediate "product". As they get more excited, they will WANT to learn more details and figure out how to create a better app. PLUS - web dev is a relatively easy way to make some extra cash, and practical abilities that can lead to money are another motivator.
I know - learning C or Pascal, etc. is more foundational and powerful in the big picture. But for beginners, I think its more important to get them excited to learn. Once they have a bit of confidence and curiosity, its much easier to migrate to just about any other language they want/need. Humans learn best by actually "doing stuff" and not by theory alone. Theory and the intricacies of coding become more relevant once we have a rough foundation to build on.
Get them "hooked" with immediate gratification and easy apps (that they can easily share with friends!), and then lead them into deeper waters once they are comfortable.
This is a pretty easy question. You are teaching basic programming to someone who has no prior experience. Teach them to think like a computer first - assignment, decisions, branching. Show them how that's a state machine, but don't delve deeply. Show them a few assembly statements (but don't make them program in assembly) so they really see how it works down deep.
Let them code the towers of hanoi and all the other basic fun stuff. Don't throw heavy theory at them right now.
Class #2 is a great point to extend towards your favorite. Now that you've got them doing basic programs, you can show them the pitfalls and why is superior. But first, ground them in the basics.
-Jeff
Please learn the difference between a dissenting opinion and a troll before you moderate.
My intro programming class at U of Chicago was taught entirely in Scheme. Having already taken C++ and Basic before, I found it tedious and hellish, but I can see how it would definitely leave a new programmer open to any other paradigm.
The first programming course should be about how to write good unit tests.
It's suprising that so few programmers leave university and even progress in careers as software developers for years without this basic, essential skill. More emphasis on testing at an educational level would solve a lot of the problems we have with writing good software these days.
(So says somebody who didn't learn how to write a good unit test until ten years after graduation)
Actually, out of the three of my friends who majored in electrical engineering [technology], only one of them has a job in his field. The other two have IT/website backend/light Java-type jobs. Guess which one went to DeVry (while the other two went to GA Tech).
Now, I don't know how that actually translates to salary, per se, but I'd bet the DeVry guy's job is at least as good as either of the other guys'.
(By the way, all degrees were Bachelor's degrees, but the DeVry guy earned his in 3 years while the other two struggled through in 5, and the DeVry guy got a full scholarship.)
The bottom line is that if you want job training, you are not better off at a University. It's the same in all fields: getting a mechanical engineering degree is a waste of time if you want to be an auto mechanic. And there's nothing wrong with being a mechanic (or, analogously, an "IT guy" or a "programmer"); in fact, there are a lot more of those sorts of jobs around than there are for engineers and computer scientists! The real problem here is that both schools and students have completely the wrong expectation of what a university computer science program is all about.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Colleges are supposed to TEACH understanding so one can discover and solve their own problems and essentially train themselves on the grunt level stuff (not that training may still save time.)
TRADE schools are supposed to TRAIN workers to get the job done. Understanding is not required beyond what is mandatory to the trade. (I know I'm oversimplifying the difference.)
CS is NOT supposed to train you for industry! Colleges are being undermined for their focus theory because people are mistaking a college for a TRADE SCHOOL.
Theory applies indirectly to industry. Its up to industry to understand that a CS major has to learn trade type stuff on the job; some are realizing the CS degree is less important than real experience.
The big question is should CS be an offshoot of math and go back to its theoretical roots?? Should a TRADE like path be used instead where you have apprentices and masters - because becoming a master programmer is actually akin to a TRADE like carpentry?
Why should 1 model of career development dominate each offshoot specialization? (other than the bias for academic institutions to expand and remain relevant even when they are not best suited.)
Would development of computer worker unions help address the problem? For example, local unions for plumbing, pipefitting, painting, etc. have an apprenticeship model for career development - the academic model doesn't work their careers.
Democracy Now! - uncensored, anti-establishment news
To start with, an "intro" class should not focus on one single paradigm, but focus on general concepts and show how they apply in multiple paradigms. This is best done through using several different languages, and repeating the same exercises in each throughout the course. Later courses can focus on a single paradigm and language, and then choose one that best fits what that course is trying to achieve. And yes, this is doable, but requires a very dramatic change in the CS curriculums to do it.
Many curriculums assume that you need to teach the students "how to program" before you expose the students to multiple languages. This holds true, somewhat, but the use of multiple programming languages can still be easily achieved in a intro course. To achieve the result, select different languages that each have different paradigms (chaotic, functional, OO, etc.) and go through each one covering each quickly - e.g. spend 3 weeks in each language on really simplistic programs that demonstrate the basics of programming; the assignments for each 3 week group are the same, just in a different language using a different paradigm.
You can also run a secondary "intro to language C/Java/whatever" course alongside the course to go into greater depth on other things; or it can be reserved for the next semester/year.
BTW, I speak as someone who was through such a course. My high school programming classes started with an intro course that introduced the other programming language courses. The first semester was more or less computer introductory, and focused on DOS Batch programming; the second took up QBasic, the third Pascal, and the fourth C++. QBasic, Pascal, and C++ each had advanced courses we could take after that. But it taught us a lot more than a standard CS intro course - it was more analogous to my "Programming Languages" course - a "200" level college course. So yes, it can be done and done well; and by doing it, you get to mold the student's mind into being able to think in more than one paradigm or programming language.
Given today's computer languages, I would probably advocate the course use something like JavaScript, Perl, C/C++, Java, and SmallTalk. (JavaScript because it is handy for a lot of scripting - web and on Windows computers - and it can be very similar to Chaos style programming. Perl for its RegEx, C/C++ for functional, Java for its sluggish OO style, and SmallTalk for true OO.) But I wouldn't limit it to specifically those. You could replace JavaScript with Assembly for true Chaos style programming, but I think that would be going a bit too far for an intro course.
Needless to say, I would put the emphasis on the intro course being a diverse CS experience, having to deal with multiple paradigms and programming languages. It will give students a better taste of what CS really is as opposed to focusing simply on a single paradigm and language that embodies that paradigm.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
I would probably lean towards a procedural language for a first go. It just seems to be easiest to grasp. Objects require too much design overhead for newbies to get right -- doing a fair amount of procedural programming, IMHO, gives them enough of a feel for program structure that they at least have a hope of getting things modeled well enough using objects later. Furthermore, if you were to teach, say C, you can introduce OO concepts through procedural means such using structures having associated functions taking a "this" pointer, function-pointers for basic polymorphism, etc. I realize that C++ is not a "pure" OO language, but being able to show things in the more-transparent C, which are direct analogs to their C++ implimentation is very valuable.
A decent modern BASIC might also be a decent route -- VB/VB.net is no good, all the focus on the GUI aspects confuses students. My girlfriend is taking a Web development course, and the poor VB students can make a GUI well enough, but they didn't learn what a function was until the last week, which was a week after they began their final project. Maybe FreeBASIC or RealBasic would be better.
In the end I think its mostly about teaching varied and fundamental methods -- for example, whatever the language, make sure you school them well on recursion, because it opens a door to a new way to solve a problem for most people -- and its also an important basis for functional programming.
I wouldn't worry so much about whether that language supports various features, such as closures or first-class functions, as long as the chosen language allows you to demonstrate a reasonable facsimile of the feature -- providing an intellectual framework in which to discuss the feature and how it works behind the scenes is what's important, not that it actually *is* implemented that way in the chosen language. IMO, its all the better if you can put it in familiar terms in a "primary language", say C, and then show them what it looks like in a language that supports it naively -- since that often demonstrates the elegance of the feature, as well as putting it in a high-level light free of the implimentation details.
I might be tempted to say that C would be the best choice -- Its in a unique position of being low-level enough to serve as a basis for most features in any language, as well as being the "lingua franca" of programming languages.
Then again, Dijkstra believed that an intro programming class should not be about computer programming at all, but rather about logic, reasoning and proofs... I actually tend to agree, but I doubt you'd ever sell the faculty, parents, or students on that because there's no immediate gratification -- That was actually the point of Dijkstra's famous essay; that the desire for immediate apparent gratification goes hand-in-hand with the infantilization of the educational institution, at the detriment of all involved.
What a great day, both a Platform religious flamewar, and a Language flamewar in a single day! How great is that?
I love you guys. Keep those inline ads coming!
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
What I learned most from in my CS studies was to understand how a higher language (in my old days Pascal) translates into a machine readable form.
The basis to all this was the understanding a Van Neuman machine and We simplified actual Pascal Programs into a PascalSimplified dialect and then into assembler code. You can do the same with higher level concepts like OO or functional programming.
The beauty is that after that exercise you are ready for the next paradigm shift, which is about 5-7 years away. You can understand how it relates back to what you already know and do not start from scratch or fear the "new world."
Busy helping non technical users of OpenOffice.org - http://plan-b-for-openoffice.org/
You should learn software design first. Learn how to make a software requirement specification, test plans, and and architecture.
Functional, OO, or (structured) imperative methods are all valid; I think How to Design Programs is a good basis for a first course not because of paradigm, but because of its focus on problem analysis, design for reuse, and testing, which is largely paradigm independent.
Just a small information.. I am a first semester student (Bachelor in Informatics) and we started with both Java and C. The very basic concepts were introduced in Java and then we continued in C for pointers and data structures. So this option exists too.. it's a bit strange but it works for the moment (or I must say, I hope it works...)
I think the best place to start is a language that is close to how the machine "thinks" without creating lots of unnecessary detail early on. I think I'd probably start with C for that reason. It has enough expressive power that you can introduce some basic stuff without needing to go into full detail right away, but as you introduce the lower-level bits (probably in assembler, as you say) you can easily identify how the C constructs map onto the underlying machine language, so the details are introduced in terms of the abstractions that the student has already learned.
This also works well in the other direction. Having taught C, you can show how it makes solving some common problems quite fiddly, and thus introduce the concept of an abstraction and the concrete examples of object oriented and functional programming as abstractions for solving certain classes of problems. At this point it's easy to draw the parallel that C is in fact an abstraction over assembler which is itself an abstraction over the machine language.
I think it's a mistake to assume that each paradigm requires learning a new language.
Use a language like Ruby (Python might work too, or even JavaScript) that will allow you to start out with super basic procedural stuff, and then add object orientation, and then work your way up to functional programming. (See http://www.rubyconf.org/talks/46 if you don't believe you can do functional programming in Ruby.)
Along the way you can dabble in a language that typifies each approach, so C could be covered briefly, and Java or C++ or C# as well, and Lisp or Scheme or Haskell or Erlang toward the end. But I would make the main focus the single language (Ruby, for example) so that through the course the students are not merely getting exposed to several languages but are actually building on what they learned and building practical skills.
There's no need for "real-world skills" and theory to be completely at odds. A really popular language that provides the ability to work in multiple paradigms allows for learning both marketable skills and important CS concepts.
I know I'm late to this thread, so most people probably won't read this, but I didn't want to Jones in on a sub-thread. I also admit I only read through the first page and a few on the last page.
So the way I see it, starting with assembly language really lets people understand what's going on "under the hood," how memory is allocated for variables... you don't have to write a big program in it, just a few small ones so that students understand how memory works and the importance of various types of instruction sets. So not for long, and not necessarily in depth... like the first few weeks.
Then C. It's simple for people to see how C could be translated into assembly, and then you can also expose them to libraries. Again, this doesn't have to be long, I just think it's one of the easiest languages to learn HOW things work.
From there, you can go on to anything: C++ seems logical but it can be a bit of a beast, and if you want to discuss object oriented, I think Java would be a fine choice.
Like everybody else, just my opinion.
But hey, we were taught Pascal in CS 101 and 102, and I managed to graduate and get a pretty nice job programming, so as so many others are pointing out, the language doesn't mean a whole lot... of course, I already knew BASIC and had taught myself assembly on my Atari...
Stupid sexy Flanders.
Since they're learning the consistent and creative application and extension of abstractions, the less "real" it is at first, the better. Imaginary machine code makes a nice beginning because from there they'll be glad to have structured programming, and if the go the electronics route instead they won't have the mental crutch of a "magical black box".
Help stamp out iliturcy.
Hrm. Interesting. It was my impression that DeVry and the like had reputations similar to that of "Joe Bob's Correspondence University of Theoretical Physics". Perhaps I am mistaken. I don't know any HR people personally; maybe they don't feel that way after all! ... in which case I really should have taken them up on that scholarship thing. DAMNIT!
For teaching to whom?
For kids, definitely using ALICE
LUA
The best Intro to Programming classes I took covered theory first, starting with an introduction of the differences between sequential, object-oriented and functional programming. The theory has to do with languages, and what they are..
In the course labs there was hands on experience with C/C++, etc., but no language-specific stuff in the main lectures. Later, each class would use a different language to introduce a CS concept. Java for web, C/C++ for operating systems, Dylan/Lisp for the compilers class. This is the best, since languages change too frequently.
I learned Basic, assembly and Pascal first, but they're ever used directly now. I say focus on the theory, and an overview first.
Despite omnipresent side effects?
Um, "omnipresent" means being everywhere, simultaneously, and is thus an attribute of a deity. I doubt that even the most ardent OO-worshipper would ascribe godhood to an object.
I'm thinking the word you meant was something more along the lines of "inevitable" or "ineluctable".
Since the newbies are not pre-occupied by what is going to be their first language, I suggest you'd ask THEM how they think the computer should best told what to do. That way, we can maybe achieve progress on the programming language front, for really there isn't much new stuff coming out, but this doesn't mean today's languages are perfect. Lanugages like Ruby (and I'm not saying anything against Ruby here) are really just mashups of existing features found in Scheme, Perl, and Python. It's time to come up with new revolutionary paradigms, and nowhere can the be better encouraged/instilled than in the first programming class.
In some sense, any course based on SICP goes a long way, as it introduces abstraction as the foundation of computing, and meta-linguistic abstraction, i.e. the invention of new languages, is described as just one our of the many tools that often lead to better software. So True!
Assembly language allows the new programmer to understand the computer as it really is. Anyone who doesn't understand what is happening under the covers of higher abstraction layers is never going program above a very poor level.
Preferrably, a RISC assembly language, but PPC is relatively orthogonal.
-I like my women like I like my tea: green-
My first programming course was taught in Scheme, a variant of Lisp. It made sense since students came from all kinds of different background and some already had skills in C, C++. This way everybody stated from scratch since it was very unlikely somebody already knew Lisp programming.
Nobody's every offered a usable definition of "object-oriented" that really allows you to distinguish OOP from non-OOP in any reliable manner. Classes don't do it (because of prototype-based languages that are said to be OO); "sending messages to objects" doesn't do it either (counterexamples: CLOS, Dylan); object.operation syntax doesn't do it either (CLOS and Dylan, again). Dynamic dispatch seems the closest thing to a deciding criterion, but that alone seems like an unsatisfying answer, because it describes a technique that can be easily built into a random impure functional language (you can probably implement simple dynamic dispatch in two pages of Scheme code).
"Pure functional" does have a good demarcation criterion (the language has referential integrity in all contexts with no exception), but "impure functional" is also impossible to demarcate precisely (Is Ruby an impure functional language? Is Python so? C#?)
Ultimately, I think all this talk about "object-oriented" vs. "functional" isn't very useful. It would be better to enumerate specific features or properties that one would like a language to support. So, for example, I like PLT Scheme because it has first-class functions, closures, macros, dynamic types, mutable state, record types and a module system. I can use these fairly straightforwardly to implement nearly any programming technique or feature out there, from dynamic dispatch to monads, logic programming, or what have you.
Are you adequate?
I would have to say the best language is dependent on other factors involved. Consider the goals of both the teaching institution and the type of graduate they wish to produce. I'll describe three different approaches to education I have come accross and why each would use a different language paradigm.
Example 1: Alpha
Alpha is a university that has a strong focus on research and academic qualities over industry practice. Their approach to programming is that it is a part of computer science and they are interested in teaching computer science. Their courses focus on mathematics, logic and languages with a heavy emphasis on theory. In this scenario I would suggest a functional programming language to begin with - it matches the mathematics and theory quite nicely.
Example 2: Beta
Beta is also a university, however the emphasis is on creating industry ready graduates. The university has taken a conscious decision to focus on skills over theory and has no mathematics as part of their IT course. Their approach to programming is very mechanical and about understanding state. In this setting I would suggest a procedural language that is heavy on state, maybe C, C++ although OO languages are also options.
Example 3: Gamma
Gamma is a tertiary education institute that creates certified graduates with specific skills. Their approach to programming is to create a programmer who can jump into a team right away and start working. They have no real interest in underlaying programming theory at all, they want to tick a box on an application form or resume. They typical run a language specific course on the language used by the industry and so would likely teach OO languages such as Java.
I would not claim any of there are a "better" or worse approach to learning your friend programming language. IMHO the universities (Alpha and Beta) should produce better programmers in the long run as they go into more theory and detail, but any of the three is as good a starting point as the other - in the end a good student will learn despite the limitations of the institution.
I first learned from people who kept it interesting for me at first, and I learned in basic (lol it was the 80's). As I recall, it wasn't the means but the ends that excited me in the earliest days. From there I taught myself, and I think the key wasn't the language, it's truly being interested in what you're doing and seeking out better ways to do "stuff with code".
I'm not advocating people toss formal education aside, but I will say that I firmly believe that without a love for programming no amount of training will ever make anyone a "good" developer. Proficiency != skill in my book.
There is a free online programming book called
How To Design Programs:
http://www.htdp.org/
It uses Scheme as the teaching language, but covers most of the common things, such as recursion, loops, etc.
Slashdot = Sarcasm
Are you at a university at the top of the international league tables, that enjoys treating its students badly -- "shape up or ship out"? If so, of course you will go with functional programming. No need to think about their best interests, especially not for those students who won't stay with computing.
If you care about your students on an ordinary Programming 101 where approximately 0% will go on to a job with Programmer in the title and many will not take programming next year or ever again, then you need to think harder about what serves your audience. That part who will stay in hands-on computing will mostly be in databases and/or web development.
Start with procedural or OOP programming? Well actually, start with something in which your students can easily produce professional-looking programs. Those happen to be OOP languages with good development frameworks. Dedicated nerds or students required to take just this one course will both benefit from a feeling of achievement.
My experience suggests introduce procedural concepts first, wearing the OOP lightly "We will program this button to...". In depth OOP can be introduced in System Analysis (if you are really lucky in your colleagues).
Man, I am SO late but... just to add to the pile.
1. Emphasize that there are multiple paradigms, not a single paradigm.
2. Demonstrate each paradigm with different programming cases and languages. For example, do something OOP in scheme. Something functional in Java. Or preferably do them all in multiple languages. Show how some languages have features that gear the language towards specific paradigms and coding practices.
3. Help them recognize the difference between learning how to build something, and the internals of programming. Building involves knowing your platform, getting the tools, knowing where to find help, and getting over bugs and quirks to accomplish the end result. An example would be making something for the iPhone, or for Windows. The internals of programming involves learning all the concepts, and how things *actually* work.
4. Teach what makes a good programmer independent of language. Code reading comprehension. Code debugging. Consistent syntax. Variable naming. Scope and namespaces. Commenting and organizing code in a way that lets other people easily work with it. Team concepts. Abstraction. Abstraction layers. Using and building APIs and libraries. Google searching skills.
5. If the science is important, why not show them this:
Structure and Interpretation of Computer Programs, Video Lectures by Hal Abelson and Gerald Jay Sussman from 1981
BASIC
Hebrews 11:8
Jeremiah 33:3
While functional programming and other paradigms are important to computer science, they are NOT important to a beginning programmer. Why not have them doing graduate-level compiler optimizations in their second week?
First thing you have to do with new programmers is get them to relate what they're doing to what they already know. The classic "tell me how to make a Peanut butter and Jelly sandwich" exercise is a way to engage the group and get them to realize how literally everything is taken by the computer. Then start them making similar programs - Ruby, Python, whatever seems fine as a way to program without cruft and less confusion for the students.
I had programmed in Apple BASIC and MSDOS C before taking MIT's SCIP course, and I still couldn't make heads nor tails of their functional programming. I barely survived by doing pattern matching to make somewhat functional programs once we hit the part of using true Scheme/LISP paradigms, but that is no environment to encourage understanding nor creativity. Possibly because I already understood procedural, but I doubt it. I don't see how picking someone off the street has a chance of understanding functional programming. (Oh? You who are protesting: How much programming is a prerequisite for an INTRO course?)
Just because you present the material doesn't mean you've made it understandable. MIT definitely proved that to me, even when Abelson and Sussman taught the course. Well, presented it.
Object oriented, however much others protest, is just an abstraction on procedural (ie. the definition of C++) and has nothing to do with functional programming. OO languages may have other features which lend them to functional programming (or functional ones with OO features) but they're hardly equivalent nor disjoint sets.
Also, yes, after the first course have additional courses in functional, ASM, etc. 6.004 was a blast building computers first with ANDs/ORs and later programming chips to interpret 'languages' all the while wiring them together. I hope everyone has the chance to do that!
8-PP
I think if someone wants to give a good introduction on programming, the goals should encompass a detailed, but high-level overview of what computers do, how they are architected, what the different styles of programming are, and how to play around with them. It does not need to be a single language that rules them all. It does not even need to be the best representative of each style. I'd say the focus should be on getting the message of what each programming paradigm stands for as quickly as possible.
I would say that easy-to-use tools are important here. And they don't have to always be traditional development environments with traditional assignments. To teach the concepts of modern computer architecture, I'd devise a game, where students play the roles of a controller, memory, and other parts. Only, to make it interesting, the controller operates on a set of simple "real world" instructions that can be used to write a program that causes the players in the game to bake a cake or solve some puzzle. This would also go a long way in explaining some concepts of imperative programming, what compiled and interpreted languages are all about, etc.
For functional stuff, how about let the students play with spreadsheets? I am biased on this subject, having developed a kind of programmer's spreadsheet app that I think is great for this sort of exercise, but it's not the only one. There are lots of extensible spreadsheets out-there that can teach one the same concepts. Then, to reiterate how programming is not always manifested in the same way, draw parallels to XSLT processing and have the students grasp some concepts from there as well. The goal here is to teach them to think, not teach them a specific skill, yes?
Alexey
I don't know if this will give some sort of insight or not but I thought I'd share my story of starting out in my first programming courses.
I'm most definitely a beginner programmer still to this day. I started out at college with Java and being young and not knowing much after about half way through the semester I quickly felt overwhelmed. I switched majors and did about 2 years of VB.NET and ASP.NET. Now when I go back to Java, or look at other languages like PHP and Python everything is SO much clearer than it was. Understanding OOP has become so much easier among other things.
I guess my point is it really helped me to not start out with a "hardcore" OOP language like Java (which may not actually be that hardcore, keep in mind my knowledge level). After starting out with VB.NET I moved to C# .Net and now am going back towards my older Java days and found a new interest in Python. I know there is many elitist on here and I don't know anything about "Paradigms" but I thought it might help hearing from a beginners point of view.
I tutor students in computer science courses and have seen so many students complain that they don't understand functions and data, yet their teacher has moved onto classes and objects.
The problem with teaching C++ and not C is the that too many teachers move too quickly to the OOP stuff because they feel that it somehow "replaces" non object C programming. This is not only wrong but dangerous because these students are rushed into OOP without understanding the problems it solves. Besides, not all problems are best solved with OOP.
The C programming language is actually a simple language. You'd be surprised at how quickly students can pick up concepts like pointers and dynamic memory management if the teacher only expose it to them early on and give them short projects to boost their understanding. Sadly, many teachers do the students a tremendous disservice by trying to avoid pointers because it gets in the way of teaching OOP. Or perhaps the teacher himself is rusty.
Given they are learning what a turing machine and a language *are* on other courses, if you want them to teach programming, forget languages at first and teach paradigms and patterns. Dont need to go deep inside language flavours to learn divide et impera, bottom-up, facade and wrapper; then assign programming problems focusing on input-output, data structures and design: dont forget when most posters here, including me, graduated, we hadnt the net but just plain books. Thus, let them form a personal idea about what to use to solve the problems.
After that introductory part, divide them in six groups, each one respectively writing a client and a server in C++ on windows, in C on linux and in java (for instance a simple client-server versioning text editor/repository). Let the server groups and the client groups meet each other in order to specify a common protocol and a common data format. During the course make them write the software so that the linux client can interoperate with the win server and so on.
At the end of the course, probably there will be no working software, but you would have taught to this little army of uber-developers the way to face programming problems, not your way to solve them.
IMHO, I think Assembly is the best because it forces you to start thinking about how the machine itself functions underneath. Art of Assembly is where I got my start.
I was a programmer in the US Air Force. I also taught their 11- week computer programming course for three years. We began with basic problem solving. We taught programming design language (PDL) and flowcharts. Students were given simple problems to solve with these tools before they learned any actual computer languages. Their first languages after that were Assembler, Fortran, and Cobol. It worked very well. For those who believe object oriented is best, remember, within your objects are methods, and those methods are essentially imperative.
Do what you can do until you can figure out how to do what you can't do.
The best first programming paradigm is one that doesn't involve the word "paradigm".
(You should watch out, you'll become a manager that way.)
Would you expect somoene starting med school to already be a doctor? Some subjects aren't taught in high school, or at least not in all of them.
TFA did say it was an introductory course.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I'd recommend whatever paradigm best gets out of the way for new programmers. IMHO, in the first course, you shouldn't focus on the paradigm - you should focus on generally learning how to get computers to do things, and how to solve problems with them. Once the students know the basics, they can start learning different paradigms and the tradeoffs between them.
I was taught SICP here at berkeley in Scheme. The language is a multi-paradigm language so we really understand functional programming by the end of the first month. Then we move on to imperative, and object oriented for another month. Then just to make sure we really understand whats going on under the hood we build our own language interpreter. Then we implement our own lazy evaluating, and logic based languagues! Then we create a register machine for this interpreter!
After that class I some very strong opinions about what a programming language should and shouldn't be. I've also learned 3 programming languges in one semester on my spare time! I couldn't imagine a better way to learn about programming.
An Assembler programmer can program C, C programmer can program C++, a C++ programmer can program Java, a Java programmer can program Python.
A python programmer who can't program java, can't program C++
A java programmer who can't program C++, can't program C.
A C++ programmer who can't program C, can't program Assembler,
A C programmer who can't program Assembler, doesn't understand computer architecture.
QED.