YOUR BLOG IS FALSE

So J-Dog says my blog is false and that while IDEs and version control is important, universities aren't particularly good at teaching them so industry should teach it.

One could argue that industry doesn't even really teach, so they are at least as bad at it as anyone else.

I think it's agreed that you can classify the Stuff J-Dog Wants Taught as more fundamental, i.e., hasn't changed much in years (admittedly, algorithms and finite automata being relatively recent areas in computer science, some 50 years old) and Faddish Stuff, as in IDEs and version control.

Linear algebra, etc. all are rather "singular". There isn't X flavor of linear algebra and Y flavor of linear algebra, there's just linear algebra (feels like an Obama geek declaration). But there is a version of this IDE vs that IDE, and this version control vs. that version control, thus it has a faddish flavor, a technological contrivance, and to learn one might give you an overall flavor of all things in the class, but you may find yourself incompetent in a rival product.

And I can see that being distasteful to the university cognoscenti.

What is Computer Science?

I was having a debate with a friend, which wasn't much of a debate to be honest, because we weren't really debating.

He felt that a computer science program should cover the fundamentals which, to him, meant math. You should know things like algorithms, linear algebra, statistics. He said things like IDEs and version control should not be taught. You have limited resources, and those things are fads that change. And since industry uses these things, then let industry teach it, or pick it up on the job.

He argued that no one is going to pick up linear algebra if they aren't taught it in classes, but people can always learn IDEs and version control.

At the time, while I disagreed, I didn't present any counterarguments.

So it made me think. Would a typical person actually pick up those things at work? There are fairly smart people that don't want to learn IDEs or version control because it is a fad. Could they learn it on their own? Perhaps, but there are so many mundane details to learn, much of which isn't that important to learn, that people often go in the other direction. They learn just enough to get by without fully understanding it.

To take this to an extreme, there are smart people that know math that don't even bother to learn to program properly. If you say IDEs and version control is unimportant because of its faddish nature, then you might as well say learning to program in any popular programming language is also faddish. It can take at least as long to really learn a language well as it does to learn the basics of stats or linear algebra (i.e., 3-4 months of focus) and it takes a certain personality to learn a language as well as possible.

The problem, in my mind, is that computer science, as it leads to a programming job, is faddish and fundamental. If you focus on the fundamentals, then you are telling graduating majors that everything else is a fad and is "easy" to pick up. These faddish things are in fact not easy to pick up and are difficult in completely unsatisfying ways.

At least, you can argue that if you learn linear algebra or stats and it's tough to figure out, then when you finally do figure it out, then you can feel you've understood something deep.

This isn't really the case with IDEs and version control. You learn a lot of mundane details and wonder why certain things even exist, and what their purpose is for. A typical industrial strength IDE has hundreds of options. There are ways to extend the IDE (say, for an open source IDE like Eclipse), ways to integrate it with a build system, with a bug-tracking system, etc.

So many details are there, and it takes a long time to master them, and it's not always that uniform from one product to another.

My thinking is that we need to teach how to deal with this because it is a survival skill in the industry, despite being so very ephemeral.

In other words, despite the fact that people may not choose to learn linear algebra once they go into industry, they may, for quite different reasons, not choose to learn an IDE particularly well when they arrive there either. To assume that they will is a bit of folly.

On Computer Labs

Computer science is a fairly new major for most universities. Most started CS programs sometime in the 1980s, even if departments may have existed ten or more years prior to that.

Computer science is weird because its existence is partly based on a technical device, the computer. Some would tell you that computer science's roots are in math, and they'd be right. When Turing came up with his machine, it was more of an abstract machine. It had a tape to write on, and a set of rules to run. I'm sure, initially, he didn't think of real computers, until they were invented shortly thereafter.

But when it came time to teach it, many universities sought a model for computer science courses. Given the word "science", some adopted the idea of a computer lab, much like chemistry majors have chemistry labs and biology majors have biology labs. But if you're going to code, you need time, and these labs have rather limited hours. A significant project can take 10-20 hours, far longer than a typical lab.

It may have made sense to have labs when computers were expensive, but these days, even art majors have computers. A traditional lab like chemistry and biology still requires special materials like frogs or chemicals.

Jaime tells me that he still runs computer labs, and I have to imagine it's because the computer science department has gotten stale. You can have "labs", but it should run maybe 90 minutes, not a few hours, and have most of the work done out-of-class.

Dumbing Down?

Joel Spolsky has been complaining about the dumbing-down of computer science education. He's not the only one. Suddenly, out of the woodwork, you are getting folks who are agreeing with this. Is this problem specific to computer science? Do all the other disciplines have great teachers, and computer science awful ones?

There are a plethora of problems with computer science education, and I'll hit some of them myself, but the solutions are, frankly, very hard. Some of the issues are institutional, mired in the way academia views computer science education. Some of it is merely the mission of the university, seeking to educate as many students as possible, and the resulting mediocrity that's sure to come from that. Some of it is due to the incredible faddishness of the industry that pulls everyone in a million directions, and declares that their one obscure area of expertise is what every student should learn (a recent article proclaimed everyone should learn compilers--pretty soon, you hear everyone should learn algorithms or type theory or AI or network security or linguistics).

Let's begin with computer science education itself, and why it's causing problems. Perhaps the first problem with programming is that it's gotten quite complex. Object-oriented programming may seem particularly cool especially when it caught fire in industry in the late 80s, and universities struggled to keep up.

Object-oriented programming is tough compared to the simplicity of C or Pascal (and C isn't that easy either). But we continue to teach programming as if it were C or Pascal because academia doesn't want to admit that programming got difficult, and that two courses aren't enough.

Indeed, traditional CS had two courses for programming: CS1 and CS2. CS1 was learning the basics, which honestly, was control-flow (if statements, loops), arrays, and functions. No classes, and maybe a touch of pointers. CS2 was data structures: stacks, heaps, trees, and pointers. That was all you needed.

CS courses then often taught assembly, which has disappeared (and to be honest, if it returned "as is", it would not give enough insight into low-level programming as some would imagine).

One could easily argue that object oriented programming requires at least a third course to fully comprehend programming in it. A third semester alone is useful for a horrid language like C++ where templates, virtual functions makes reading and debugging a nightmare (and memory management).

And we haven't even talked about threads!

The other part academia hasn't particularly cared for is that software engineering has become a discipline. True, many a department now have software engineering professors, but academic software engineering is a strange beast, often divorced a bit from the reality of real software engineering, and then further lacking the respect from other more mathematical disciplines that have been around longer.

Indeed, many other computer science research areas look at programming as a mere tool, useful as a means to an end, and not an end to itself.

Software developers have to deal with a lot of issues these days. Let's hit a few of the basics. At the very least, you now need to know version control. There used to be RCS and SCCS, which both sucked. Now there's CVS and Subversion, and now a whole spate of distributed version control systems. It takes a while just to understand how version control works, especially the nastiness of branching and merging.

Academics who haven't dealt with version control (fortunately, fewer and fewer) find this subject painful. What does this have to do with programming? And, in a very real sense, they are right. It has very little do with programming, and everything to do with software development. And because it's tool-based, and because we still haven't fully gotten it right, people are going to come up with one system after another, and as soon as you master CVS, you waste time trying to learn git and other bits of arcania just to get by.

But then, there's the new trend (and it is a trend now) towards agile programming. That means unit testing. That means test driven development. That means behavior driven development. And, oh the plethora of tolls. Programming has become so convenient to the masses that the best of them produce wonderful tools. And now, people have to pay attention to their existence! If you were doing Rails development, you might play with RSpec or autotest, tools that are only about a year old, and you'd have to keep your ear pretty close to the ground to keep up. That's tough when an academic wants to do research rather than keep track of the tabloids.

Software development has lead to people using terms like "requirements gathering" and "test document" and "test plan". Documentation has gotten big, even if people routinely do a bad job of it.

Let's briefly talk testing. This used to be something a programmer does. Indeed, it's still something a programmer does. But now, there are separate folks that handle quality assurance, so much so, that it's given the name quality assurance, and there's a whole spate of terminology and tools surrounding testing! And the mentality of testing is quite different from coding. What was considered something a conscientious programmer would do has now become its own discipline, almost worthy of a major.

Speaking of tools, what about usability? The web did a marvelous job exposing the need to write usable software. The average person doesn't understand software so much, and can quickly leave one webpage for another. A webpage has to be visually appealing, yet easy to use, and preferably both. Once upon a time, people figured the only people using programmers were other programmers. Thus, beauty, comprehensibility, and all those things people now care about were a complete afterthought.

Did we mention how faddish the industry is? Right now, dynamic languages like Python and Ruby have caught everyone's fancy. And while those languages make great strides towards wide acceptability, people are already looking for the next great panacea of a language. Whispers of Erlang, Haskell, O'Caml, Scala abound. Even if we stick to Python and Ruby, both have enough magic in it that you can do a lot of non-obvious magic.

And, one of Java's downsides is that it's so verbose that people need a good IDE to write code in the language. You simply didn't need a decent IDE for languages like Pascal. Eclipse itself is so complex, you need hundreds of pages to scratch the surface of what it can do. It's integrated with tools to test, use version control, refactor(!). Things no one much cared about 20 years ago, so that people could focus on, you know, programming (I know--it's all programming, isn't it?). Thus, a good programmer now has to master a complex IDE, and one that's not likely to be around 20 years from now.

Once upon a time, most programs didn't play well with each other. But now, people extend languages all the time. Thus, people write tons of libraries for Python and Ruby. You have to worry about what libraries exist, and how to use them. There are people that now link in other people's code. A good programmer has to locate all sorts of software, and evaluate them and decide whether to use it or not. In the good old days, you'd simply write the code yourself (badly) or simply do with a bad solution (your own).

Oh, what about open source? Want to explain the gazillion variations of open source licensing and what it means to the average programmer?

It's a big world out there. Want to explain internationalization, and how it affects your code? Is your code ready for the world market?

How about handling all those timezones and dates? That also falls under internationalization. As does, of course, Unicode (and that it's not just one code, but a family of codes).

How about databases? You don't talk about all those web frameworks without databases? And web frameworks? And XML? These are now part of the day-to-day toolset a programmer needs to know.

And that's outside of all the usual stuff academics generally care about, like algorithms, compilers, computation theory, AI, bio-computing, numerical analysis, and so forth, most of which, the average developer knows little about.

All of these topics could fill courses and course and courses that a typical computer science department doesn't even want to tackle. Why? Because five years from now, another new trend will sweep in, and people will have to learn again. And will those changes be an improvement? More than likely, not enough to offset the headaches learning it.

Now, here's what I'd love all the critics to do. Teach an intro course. Decide that everyone is an idiot, and tell it to their faces. Then, be told that you still have to get them to learn something, and feel what it's like, what it's really like, to have to get people to learn that don't want to learn. If it will make the visualization easier, imagine it's your own child, refusing to learn, wondering why it's so hard, and why there's so much crap, rather than that superstar you just hired who can't get enough of this new stuff, and can take anything you throw at him or her, and turn out magic.

Spolsky complains about the dumbing down of the curriculum, but it's only because Java doesn't do it for him. He knows that to get the speed he wants, he's dealing with languages that will give it to him. Even he's not crazy enough to believe that coding in assembly will offset the productivity losses coding in something that horrid. Don't you think that if Java ran ten times faster than C++, he'd be hapier to give up all the crap associated with C++. But because he needs stuff that runs better, runs faster, he realizes that his coders have to know these grungy details.

Compare computer science to math, where irrelevant details are left out, and where people learn deep concepts, to computer science, where dealing with complexity has lead us to fads of the day, as good as we have now, but likely to be replaced with something new, and more and more and more code out there that we have to deal with.

Now, let's take a step back. Breathe.

We can teach as much of this as we want, but learning isn't simply a bunch of concepts that you teach. It's a worldview. When you are given a problem, what do you do? Suppose someone tells you to port a device driver. Do you even know what a device driver is? Or what it means to port? And yet, some people can take something that vague, and get code to work, and someone else will say that they were never taught that in college, and how are they supposed to deal with this?

And the fact of the matter is that, as much as the industry complains, unless they are prepared to head into academia (itself, very territorial, and having its own idea about what students need), academia can basically ignore what is being said. First, academia is so distributed that most professors couldn't even tell you what courses are required for their own students to graduate. They barely care about their own class, and don't even think about how their class fits in the overall plan. To get them to work together and make such changes, especially changes that are likely to come every five years, is to against their nature that knowledge shouldn't be a total fad.

And it's contrary to the mission of universities which is to graduate students. Most software pundits would have 90% of computer science majors jettisoned, despite the fact that mediocre programmers are often needed to do a lot of work. They would have their other courses jettisoned, because there's no time to worry about all those humanities and such. If every major took that attitude, most students would not even be in college. Since most universities are in the business of graduating students, then each major has to worry about how to get students who don't understand pointers very well to do well enough to get out.

Imagine it's your job to educate all the students who want to be computer science majors. The mediocre ones and the brilliant ones. Then, your view of what they should learn changes, when you realize that it's hard to even get the basic programming down, beyond all this other crap you have to learn to be decent in the field.

Ruby for a New Generation

Man, I'm blogging a storm today. I think I'm trying to outdo how many entries I had last month. I'm blogging at an average of a post a day, but today I have like 5-6 posts alone.

In my last post, I said Java succeeded because it's being taught in high schools and colleges. If Ruby (and Rails) would like the same success, they need to seriously encourage high school kids to embrace Ruby, and with it, I hope, test-driven development.

Chad Fowler and the guys at Ruby Central are pushing this notion of a giving community, though charities. Dave Thomas implored audiences to make a tradition of giving to charities at conferences like Railsconf.

But it's time Ruby and its community start to help itself in this charity. Just like the tennis industry wants kids from the inner cities to learn to play tennis (many of those kids opt to play football or basketball instead), the Ruby community ought to think of ways to talk to high school kids and encourage people to develop Ruby on Rails projects.

So here's my idea. Create a Rails school for high school students. Alas, it's a little too late for this summer, but next summer would be an ideal time to get it set up. Heck, open it up to college kids too.

I'd even volunteer to do it.

Well, volunteer isn't quite the right word =).

So Frickin Expensive

A few years ago, I was visiting the University of Washington, the one in Seattle. In particular, I went to visit one Mr. Stuart Reges (the "Reeg" as I like to call him--no, not really, I hardly know the guy). He was an instructor revamping the way intro computer science was being taught at U-Dub, which is a topic near and dear to my heart.

Indeed, as I made the trek to visit him in his office (and drop by a former instructor's office, whose class I hadn't taken in nearly 20 years), I was, alas, somewhat interrupting a meeting with him and Martin Stepp.

He and Marty were in the process of writing a book. You see, Java had become all the rage. Java tends to force object-oriented programming. You can't declare functions outside of a class (you can make it static, I suppose). There are all sorts of roadblocks to prevent you from easily writing "C" in Java.

Not to say you can't work your way around these, but that this kind of procedural programming would just make for icky Java programming.

So many authors took the OO plunge and promoted an idea called "objects first" where objects were taught plenty early. To be fair, this is not an easy task. OOP implies inheritance, and inheritance is hard to teach if you haven't hit the basics of loops, conditional statements, parameter passing. Still, many a book tried it.

UW decided to change to Java around 2002 or so, and they too opted for objects first since this was the approach being advocated. They moved away from C++. Now, you can avoid objects first in C++. Just teach C first, then head into OO land with C++. It's a heady transition, because you think one way to write stuff procedurally, and another to write it in an OO style.

UW then did something (I gather) that was utterly amazing for a computer science department. Realize many a university had either made this transition to Java or were contemplating this change. You'd think most universities have already made the leap, but the extremes aren't really up for it. MIT wanted to ditch Scheme, a popular intro language they had used for twenty years (and some feel, perfectly good to teach from) for a more "modern" language, say, Python. They aren't that gung-ho over Java. The other extreme are so-so computer science departments who just don't want to change. They taught C++ and mastered it in the early 90s, but don't want to bother learning Java. Too much work, don't you know.

The departments that made the switch to Java just did so. No questions asked. But apparently, UW surveyed the students and found that they didn't quite master OO principles as well as the C++ students had. And the department wanted to rectify situations.

I suppose somewhere Stuart Reges enters the picture. He suggests that what's needed is to go back to a procedural way of teaching. OO is too hard to learn right away, and objects first is shown to be a failure (at least, in his estimation).

Somewhere else, Marty joins the picture. Now, Marty's an Arizona kid, so what's he doing up in Seattle? After graduating, he joins the evil empire and works for M$ (I say this somewhat facetiously). A year or so afterwards he says adios, and goes to teaching, which apparently, he has a good deal of experience (at least, TA-wise).

This is all backstory to my eventual point.

The two wrote a book, and the book is frickin expensive. It's nearly 90 bucks! I mean, seriously! Why on earth does it cost this much when a typical technical book is half the length. Something is dreadfully wrong when textbooks have to cost twice as much as their technical brethren.

Stu, Marty, I know you guys can't help it. If you had your druthers, you'd sell it for forty bucks, and you might even double or triple your sales because the average Joe might buy it, instead of the few students who do actually buy it. Heck, I'd like to read it, but I'm not spending 90 bucks to read it!

Now, what I really want to see is someone write a book that is one or two books down the line. Oh, but everyone wants to write an intro book. Heck, I want to write an intro book, but what's really needed is a CS 3 book.

What's that? OK, here's some background. Every university numbers its courses differently. Traditionally, computer science departments believe it takes only two courses to teach intro programming. First semester is syntax and control flow. Second semester is data structures. These are called CS1 (for "computer science 1") and CS2 (you get the idea), respectively.

But first, Stuart is right about OO programming. It is hard to teach, and it does take time. What Java saves, it takes away in other issues (say, JAR files). But there's something more. Software engineering.

In the end, intro books can't teach you that much about programming. It's much like a basketball book teaching you dribbling, scoring, the basic rules, and layups. It ain't gonna be enough when it comes time to playing high-powered bball, where you need to do crossovers, and such.

The problem with writing that kind of book for programming is the average writer of a book isn't a software engineer. They'd be totally guessing as to what it takes to write a book that teaches you how to program. Marty would, I imagine, be able to write such a book because he worked at Microsoft.

But here's the issue. Who'd buy it? You see, here's the other half of the story. Many computer science professors also haven't been software engineers. Even those who teach software engineering. There's something ironic about that. And furthermore, there's enough CS profs who find programming, much like a non-techie CEO, as monkey work. Anyone can do it! But only a few can do it well.

So even if such a book might be valuable, it would only be valuable for there here and now, and you'd have to convince departments who are still stuck on CS1 and CS2 that they should have a CS3 and a CS4, that programming has become tougher, and it requires more than trivial programming exercises to get any good.

Now, that's the book I really want to see.

But I still wouldn't pay ninety bucks for it.