« 6 April 2004 - 1:46 pm | Main | 15 April 2004 - 10:31 pm »

I've been neglecting this site as of late. I've been writing quite a bit, but most of it has been comments I've left on other people's sites. One of the longer comments I've left recently was a response to the Minutia Press post about the WashU web scripting class. Since I wrote my comment there, I've been thinking about the class quite a bit. It seems to me that in teaching "web scripting" you might very well be doing a disservice to the students taking the class. Web scripting is plenty useful -- I employ it on this site, and our entire back-end is Perl-based cgi (i.e., movable type) -- but its the past and present, not the future, of web-based development. Although even that might be a bit generous. The old saying "the future is upon us" seems to clearly apply in this arena.

Beginning with .NET a few years ago, a new model for web-based applications has quickly taken over in most large development houses. While not yet fully fleshed out in the Java world (JavaServer Faces, which were just approved, catches Java up on this, and perhaps propels them a bit ahead of the pack), .NET offers a model that shows you where things are going. The key is separation of your business logic from your presentation layer. Previous technologies embedded the business logic directly into the HTML. This is now considered a bad practice (and should have been recognized as a bad idea when languages like asp and php were first being developed). The idea is that your business rules and requirements should be separate from your presentation layer. There are multiple reasons for this. One key idea is that you shouldn't have to embed business rules into pages, requiring you to repeat rules here, there, and everywhere. You then have a nightmare scenario on your hands when you need to change one of them. But the more important concept is that your presentation layer should be able to change independently of back-end implementation. This allows you to have multiple renderings of your site for different media (normal browsers vs. WAP for example). This is similar to providing multiple stylesheets for different media, but takes things much further. It also means that changes to your front-end can happen without any impact to the actual logic running the site. (So I don't need to retest all of my SQL queries when I rebuild the front-end.) Also, for those of you who like patterns, these new web development standards are implementations of the Model-View-Control pattern that has been the norm in GUI development for quite a while.

These changes are interesting because they are building up a separation of hobbyist developers and professional developers. In many ways its overkill for a hobbyist to use some of these newer techniques unless they have the tools available to professional developers (in which case it becomes a lot easier). So things like php will be around for quite a while, but they won't see much use in a professional environment in the future.

Which brings us back to the topic of teaching pure "web scripting." Web scripting only takes students to a certain point on a path; it does not walk them all the way down. It leaves a whole host of products and methodologies unexplored. So it seems that teaching web scripting as an entire class is a bad idea. I'd rather see a web development course that incorporates web scripting as one of its topics, but also covers the newer trends in web development as well.

Posted by on 13 April 2004 at 6:37 PM

I think this is an interesting take on things.

I also think there are some conceptual models that could be helpful here, like I/O automata. The idea is that two interacting processes, in this case a client front end and server back end, cooperate at explicit points.

Separating business logic from presentation is a great step forward, but I think there are other things on the presentation (mostly client) side that could be nicely walled off. .NET is doing this pretty well, and I'll have to take a look at the new Java stuff you wrote about David.

I think overall the "service publication" model is good, but it would be nicer if things were more integrated, as with .NET. If it's easy to throw a page on the screen that front-ends an SQL database, and one can manipualte and query the database as if one were at the server (given proper permissions), I think it's a good step forward.

I am very disappointed in the scripting class. I think it could have been a great thing.

But then I thought the web development course could have been great too. Grayson Lang developed that class as 1/2 art and 1/2 CS/web stuff. It was taken over after he taught it, and the art aspects are all but gone.

I'm told that the new art buliding will house some kind of media/CS/art area, and I hope ideas liek the ones Grayson had could be revived.

In my opinion, the sad bottom line is that students and a curriculum will suffer if a prof's primary reason for teaching 3 ostensibly different courses is to spread the use of gawk.

Posted by rkc on 18 April 2004 - 5:18 PM

I seem to be bouncing from site to site today leaving comments that say nothing but "I agree with Ron." Of course, that's not exactly a bad thing.

Anyway, Ron, you made a couple of points that I wanted to follow up on. The first was the web development course, which you described as originally being designed as "1/2 art and 1/2 CS/web stuff." As I'm sure you're aware, this doesn't seem to be the case anymore, and I also am a bit disturbed by it. We're lucky to work in a field that touches many, many other fields. Art is one. Philosophy, mathematics, and engineering are others. Yet, while we embrace some of these topics and incorporate them into the CS curriculum, we completely ignore others. We've bought into the engineering aspects of our profession (that's why my title is "Software Engineer") and many CS professors spend a great deal of time trying to tie our field to mathematical underpinnings. But I've been in more philosophy classes that discuss Alan Turing than I have CS classes. (An interdisciplinary cognitive science class could be quite interesting.) And incorporating art into the CS curriculum hasn't happened at WashU, even though that seems to be a cross-disciplinary endeavor that could excite a lot of students.

And don't get me started on the inappropriate appearance of gawk into so many classes. That's just a blatant disservice to the students taking those classes. They need to be taught to use the appropriate tool for a given task, not that there exists one tool that can handle and is ideal for all tasks. The latter just isn't true and it shouldn't be presented as gospel.

I'm also concerned that a department that is occasionally criticized for offering too few advanced classes each semester is wasting resources teaching the same class under a variety of names. How many times do you need to learn gawk? In the past, a frequent complaint of CS342 was that the topic of the course (design patterns and frameworks) got lost in the effort to teach C++. The department was receptive to this complaint and moved the bulk of C++ out of 342, but here we are teaching gawk and nothing else here, there, and everywhere. Or so it seems.

I hope the next time the web scripting class is taught it is called web development and it teaches something besides gawk and asp.

(I want to address your other points as well, but I needed to get this off my chest. I'll follow up again in a bit.)

Posted by david on 20 April 2004 - 3:00 PM