Thursday, August 25, 2005

Flavor of the Day

I was talking to a friend last night. He's a professor of computer science, and is scheduled to teach a programming course, which is CS2. In computer science, there are usually two introductory computer science courses that teach the basics of programming. They are often informally known as CS1 and CS2, even if the real designation is something different.

The contents of these courses vary, but it used to be that CS1 would cover basics of functions, loops, conditionals, and possibly recursion, ie, the basics of a programming language, while CS2 would cover basic algorithms (searching and sorting) and basic data structures (stacks, queues, and trees).

With the introduction of object-oriented programming languages like C++ and Java, the amount to learn has increased. While most CS departments are loathe to add a new course, it really makes sense to add a third (and possibly, fourth) programming class. Notions of inheritance, polymorphism, design patterns ought to be covered, as well as software engineering tools such as CVS, Eclipse, a bug tracker, and so forth.

Yet, all of this is merely technology and more technology. From an academic point of view, computer science technology is killing computer science. Every five years, a new language or new ideas percolate in, and that's just one more thing that a student ought to know if they want to be employed. For example, the typical computer science graduate may have to know about J2EE, SQL, Tomcat, various kinds of web services, XML, XLST, and so forth.

An academic would find all those fads of the day, and not worthy of teaching. In five years, it will be replaced by something else, and so it's not worth teaching. Implicit in this belief is that it's not worth learning. It's not as if the academics keep up and say, despite their keeping up, it's not worth learning, but they've decided it's not worth learning, and so, by implication, the students should think so too.

Once upon a time, if you were, say, a blacksmith learning the trade, you'd spend time with a master, learning the craft of shaping iron. Once you learned this trade, your skills were golden. You merely had to repeat and repeat, and perhaps think of ways to make yourself better in the way that only age and experience could offer, solving certain little problems in creative ways.

You weren't told one day to use a hammer of one sort, then a hammer of a different sort, then a different material, then a different way to heat, then a way to deal with two different kinds of metals, and then to go into wood, then ivory, the metal inlaid in wood, and interwoven in ivory. Yet, that's the kind of fleeting knowledge that you have in the real world of computing.

It's true that advances are never made in wild jumps, that they are incremental. The knowledge you accumulate now will help make it that much easier to learn the next thing, but there's no longer a designated path to learn what you need. Thus, you find people whose knowledge about this and that to be encyclopedic, and those who barely know the technology. Both could be equally intelligent, and yet it's one person's desire to embrace technology that makes all the difference.

In the end, there's fear and desire. If you fear technology, it's hard to be a technologist. If you're in computer science, that means, learn math, learn sciences, go into an area of computing that doesn't require nearly the same amount of love of technology. If you love it, then you are set.

Yet, the fragility of technology is vastly depressing. Everything becomes flavor of the day. Sure, the underpinnings may still hold valid. You will still need to know algorithms or references vs. values or some other basics of programming, but it will be far from enough. Car technology may change, but drivers don't have to relearn how to drive every five years. This is what happens to programmers, and it's sad because it gets away from what I like about computer science which is algorithms.

The practical programmer now learns about "architecture", ie, how best to organize large pieces of software, and there are no good answers that I see to this problem. It's not taught because programming teachers don't have answers. They talk about syntax and semantics, and when best to talk about objects.

Yesterday it was vanilla, today it's cookies and cream, and tomorrow, it may be beer-flavored mango lassi delight.

No comments: