There's a new book by a guy named Nicolas Carr, called The Big Switch: Rewiring the world from Edison to Google. It's reviewed here http://www.networkworld.com/news/2008/010708-carr-it-dead.html
Predictions from Mr. Carr:
1. IT departments are dying and will soon be dead,
2. The PC is dying and will be in a museum in 20 years,
3. Software developers will all be out of work soon, as will journalists, etc.
What a load of crap.
1. Mr. Carr states that IT departments are going to die because companies will outsource all their IT needs to "utility" companies that will do all the work for them. We've all been here before, guys. IT was dead when minicomputers allowed departments to do their own computing. IT was dead when PCs came along allowed everyone to do their own computing. IT was dead when the Internet allowed everyone to do their own research and handle all their own communications. So now IT is dead because a very old idea (outsourcing computing - can you say client-server? thin-client?) will cause companies to let Google do all their computing. Yawn.
IT is not dead - IT will evolve, as it has for the last 50 years. Get over it.
2. PCs are already in museums. Desktops may change in the future, and mobile computing may become ubiquitious, but I doubt desktops will completely fade away unless someone comes up with a laptop battery that will last a month. There's still big iron out there, after all, despite the millions of PCs.
3. Mr. Carrs argument about software developers is that because all these new utility companies can get by with so few employees, that developers will no longer be needed. Crap. Who does he think creates the Skype code? the Google doc tools? browsers? operating systems? networking software? widgets?
These things don't create themselves. Dating companies can get by with few employees because they are aggregators of existing software. Who does he think writes all that software?
As I said, what a load of crap.
Monday, January 7, 2008
Friday, January 4, 2008
First Day of Class
We're back for Winter Term here at Knox and today is my first real day of classes. As usual, I'm just barely ready to go. I've got both courses outlined, the syllabi done and the first few lectures done. Need to work on homeworks and labs though - something that I am always late on.
It seems that I do a lot of research for each class; lots of surfing the web and finding resources and new ideas (especially like this term, when I'm teaching CS1) and then I focus in on an approach and most of my research ends up gathering figurative dust on my hard drive. Halfway through the course I'll stumble upon one of these gems and go "Geez, I should have used this!"
It also seems to be the case that I prepare a first lecture; create an exciting introduction to the class, and then I end up off on a tangent and that lecture gets half-delivered at best. Go figure.
Part of the problem with beginnings is that I have this ton of material to cover in a class, I've usually got several competing ideas on how to work through the material, and I have this desire to kind of spew it all out at once. This is particularly true in the Intro classes because there's always this "in order to do anything interesting we've got to learn these 47,000 things TODAY!" syndrome. It makes planning lectures and topic orderings a delicate art.
It seems that I do a lot of research for each class; lots of surfing the web and finding resources and new ideas (especially like this term, when I'm teaching CS1) and then I focus in on an approach and most of my research ends up gathering figurative dust on my hard drive. Halfway through the course I'll stumble upon one of these gems and go "Geez, I should have used this!"
It also seems to be the case that I prepare a first lecture; create an exciting introduction to the class, and then I end up off on a tangent and that lecture gets half-delivered at best. Go figure.
Part of the problem with beginnings is that I have this ton of material to cover in a class, I've usually got several competing ideas on how to work through the material, and I have this desire to kind of spew it all out at once. This is particularly true in the Intro classes because there's always this "in order to do anything interesting we've got to learn these 47,000 things TODAY!" syndrome. It makes planning lectures and topic orderings a delicate art.
Monday, November 26, 2007
CS1: Dueling philosophies
During a discussion on how to teach CS1, one one of my colleagues wrote:
"I introduce things like linked lists very early, because once you've done data structures of any stripe, and then type hierarchies, the idea of a recursive data structure with two variants (empty, and non-empty) is a pretty natural one. Furthermore, it motivates recursion without most of the strangeness that usually entails---you're handing off part of the job to *someone else*, rather than to "yourself". Linked lists serve as data structures of arbitrary size, which let students start writing interesting programs much earlier than otherwise. And using recursion instead of iteration lets you put off teaching mutation (i.e. assignment statements) until relatively late in the course---which is a huge benefit as you don't have to teach the difference between pass-by-value and pass-by-reference in week 2, which you would otherwise have to do. The polymorphic-recursion paradigm also is good at isolating the different pieces of what you have to do than is the iterative model, which seems to be good for building a conceptual framework."
My response:
The real difference between this philosophy and mine here I think is the view of recursion. Of course I think recursion is central to many algorithms and problem solving techniques, but I've never been convinced it should be taught early. I've never agreed that recursion is easy or natural for most people. I've never agreed with the Scheme folks (sorry Abelson, Sussman, Felleisen, et. al) that recursion should be taught from day one and that syntax is evil. (This from someone who spent many years working in Lisp and thinking about machine learning - all recursively, of course.)
That said, what I do think is that folks understand iteration and simple decisions much more easily than they do recursion. I'm a big fan of Boehm & Jacopini's fundamental control structure theorem. I'm also a big fan of not hiding the machine. So I teach assignment early, I teach pre-test iteration early, and I teach conditionals early. I'm not a big fan of IDEs even though I teach them and use them when I have to.
Oh, and I also think that programs with 87 objects in them, 84 of which do pretty much nothing but are there just because you can break something down into smaller pieces, are stupid. But that's my object-oriented programming rant. Don't get me wrong, I think that object-oriented design is a very powerful paradigm and is one of several very good ways of looking at how to solve problems. But I also think that some of it's advocates take it waaaaay too far.
I do like the idea of linked lists early because it frees you from having to talk about limits on data structures at the beginning, but I'm also willing to live with arrays, including arrays of objects, to get halfway there.
This is all probably because I learned programming in the early '70s when "structured programming" was new and because I spent most of my career in industry doing operating system and embedded programming of some form or another in either assembly language or in C. I'm warped - and I like it that way. ;^) I learned procedural programming first, then functional, and then - way later - logic programming (I like Prolog, weird as it is) and object-oriented, so I'm always more comfortable when I return to my roots.
"I introduce things like linked lists very early, because once you've done data structures of any stripe, and then type hierarchies, the idea of a recursive data structure with two variants (empty, and non-empty) is a pretty natural one. Furthermore, it motivates recursion without most of the strangeness that usually entails---you're handing off part of the job to *someone else*, rather than to "yourself". Linked lists serve as data structures of arbitrary size, which let students start writing interesting programs much earlier than otherwise. And using recursion instead of iteration lets you put off teaching mutation (i.e. assignment statements) until relatively late in the course---which is a huge benefit as you don't have to teach the difference between pass-by-value and pass-by-reference in week 2, which you would otherwise have to do. The polymorphic-recursion paradigm also is good at isolating the different pieces of what you have to do than is the iterative model, which seems to be good for building a conceptual framework."
My response:
The real difference between this philosophy and mine here I think is the view of recursion. Of course I think recursion is central to many algorithms and problem solving techniques, but I've never been convinced it should be taught early. I've never agreed that recursion is easy or natural for most people. I've never agreed with the Scheme folks (sorry Abelson, Sussman, Felleisen, et. al) that recursion should be taught from day one and that syntax is evil. (This from someone who spent many years working in Lisp and thinking about machine learning - all recursively, of course.)
That said, what I do think is that folks understand iteration and simple decisions much more easily than they do recursion. I'm a big fan of Boehm & Jacopini's fundamental control structure theorem. I'm also a big fan of not hiding the machine. So I teach assignment early, I teach pre-test iteration early, and I teach conditionals early. I'm not a big fan of IDEs even though I teach them and use them when I have to.
Oh, and I also think that programs with 87 objects in them, 84 of which do pretty much nothing but are there just because you can break something down into smaller pieces, are stupid. But that's my object-oriented programming rant. Don't get me wrong, I think that object-oriented design is a very powerful paradigm and is one of several very good ways of looking at how to solve problems. But I also think that some of it's advocates take it waaaaay too far.
I do like the idea of linked lists early because it frees you from having to talk about limits on data structures at the beginning, but I'm also willing to live with arrays, including arrays of objects, to get halfway there.
This is all probably because I learned programming in the early '70s when "structured programming" was new and because I spent most of my career in industry doing operating system and embedded programming of some form or another in either assembly language or in C. I'm warped - and I like it that way. ;^) I learned procedural programming first, then functional, and then - way later - logic programming (I like Prolog, weird as it is) and object-oriented, so I'm always more comfortable when I return to my roots.
Thursday, November 15, 2007
Well, I'm stuck
After years of lurking, I thought to start my own blog. Actually, I'm thinking about the CS1 class I'll be teaching during our Winter Term and wanted to start to lay out how that might go. It's been two years since I've taught CS1 and watching my two colleagues teach it has been increasingly frustrating for me. You see, they're both young and they grew up with the object-oriented thingie and are all hot to teach CS1 using an objects-first pedagogy.
I'm not young, being 25-years older than either of my colleagues. I grew up when there was just the procedural world, or if you were wacky (and I was, once), the functional world. We've taught CS1 using objects-early or objects-first for the last 5 years at least - we eased into it starting in 2000. I've even taught it that way a couple of times. And for the last 5 years (or more) we've complained that our upper-class students don't know how to program. Is there a connection? I don't know. Are the three of us just incompetent? I don't think so. Are our students all just stupid? Certainly not all of them.
So my idea is to harken back to my youth and teach CS1 in a procedural fashion - at least for the first few weeks. I'm going to teach objects-late, quite late, and emphasize problem decomposition, single class solutions (with multiple methods), unit testing, and debugging techniques. We'll use Java object classes and the API where appropriate, and we'll talk about objects, instance variables, and (horrors!) static variables and methods.
Originally I thought to use Stuart Reges and Marty Stepp's new book Building Java Programs: A Back to Basics Approach. But, while I like their procedural approach, on closer examination, their book seems to be stuck with the same dreary set of examples we got in Pascal textbooks 25 years ago - Fahrenheit to Celsius conversion, ASCII art, gpa calculations, etc. Stuff that our students these days are just crying to try out - not.
My second choice is Mark Guzdial and Barbara Ericson's Introduction to Computing and Programming with Java: A Multimedia Approach. This is the Java version of the Python book Guzdial wrote for the Multimedia curriculum at Georgia Tech. I've used the Python book in our non-majors class for the last 3 years and it works very well for the part of that course where I'm introducing the students to programming. My problem with it is that it's not procedural enough for what I wanted to do.
So my third choice is to use both. Taking the ideas from Reges and Stepp and doing them in a multimedia fashion like Guzdial and Ericson. I haven't finished this thought yet, so the course sequence is unclear, as are the lab and homework assignments. The lab I'll do all this in is a Linux lab, so the students will have some cognitive dissonance there as well. Thinking continues...
I'm not young, being 25-years older than either of my colleagues. I grew up when there was just the procedural world, or if you were wacky (and I was, once), the functional world. We've taught CS1 using objects-early or objects-first for the last 5 years at least - we eased into it starting in 2000. I've even taught it that way a couple of times. And for the last 5 years (or more) we've complained that our upper-class students don't know how to program. Is there a connection? I don't know. Are the three of us just incompetent? I don't think so. Are our students all just stupid? Certainly not all of them.
So my idea is to harken back to my youth and teach CS1 in a procedural fashion - at least for the first few weeks. I'm going to teach objects-late, quite late, and emphasize problem decomposition, single class solutions (with multiple methods), unit testing, and debugging techniques. We'll use Java object classes and the API where appropriate, and we'll talk about objects, instance variables, and (horrors!) static variables and methods.
Originally I thought to use Stuart Reges and Marty Stepp's new book Building Java Programs: A Back to Basics Approach. But, while I like their procedural approach, on closer examination, their book seems to be stuck with the same dreary set of examples we got in Pascal textbooks 25 years ago - Fahrenheit to Celsius conversion, ASCII art, gpa calculations, etc. Stuff that our students these days are just crying to try out - not.
My second choice is Mark Guzdial and Barbara Ericson's Introduction to Computing and Programming with Java: A Multimedia Approach. This is the Java version of the Python book Guzdial wrote for the Multimedia curriculum at Georgia Tech. I've used the Python book in our non-majors class for the last 3 years and it works very well for the part of that course where I'm introducing the students to programming. My problem with it is that it's not procedural enough for what I wanted to do.
So my third choice is to use both. Taking the ideas from Reges and Stepp and doing them in a multimedia fashion like Guzdial and Ericson. I haven't finished this thought yet, so the course sequence is unclear, as are the lab and homework assignments. The lab I'll do all this in is a Linux lab, so the students will have some cognitive dissonance there as well. Thinking continues...
Subscribe to:
Posts (Atom)