minutia press.
Scripting classes and languages

Some have posted about the new scripting class; I won't link to them in case Some People are watching this, but you know who you are. Here's what I have to say about all this.

I receive lots of seemingly random hate messages from RPL about Java, and how it pales in comparison to gawk. This went to the point of an exchange with Doug Lea (whose book on concurrency patterns in Java is IMHO a must-read, but 102 students didn't like it all that much), who sided with me on why Java continues to be a good language to teach foundational programming and CS principles.

The idea of "server-side state" and transactions against such state is really what server-side scripting is all about, and there are various ways to get that done. One way is to use Java and Servlets, or one can use CGI and almost anything to do the "business logic", including gawk.

Two years ago I had two strong students each try his hand at implementing a journal management system. We designed the database together, and one tried it with Servlets while the other used .NET. The .NET implementation was completed well before the Servlet version. The main reason for this was that the .NET environment is integrated better with SQL and web-based tools. On the Java/Servlet side, apache has to agree to do mysql, mysql has to be set up. It's all possible but a lot more trouble.

i write this because when the scripting "class" was proposed, I felt they should use .NET because of the interest in the business sector, the strength of the implementation, and the ease of its use for a class like 363.

If the class had concepts, what would those be? My list would include concurrency control (always one of my favorites), security, fault tolerance, state-representation (in a connection-less environment).


Thanks for not linking. I appreciate it. And the class, as it is, has no concepts. It is all just syntax, and that is getting old.

Posted by: Nathan at March 31, 2004 6:09 PM

I'm in this class. First, I think it's an important class to offer strictly in terms of making our CS students marketable to companies. In the long run, WU CS students will be more successful than others due to the strong theory and concepts learned in the core classes. However, in order to get jobs in the short run, it's a fact of life that CS students must at least understand scripting, database applications, and other business-type things.

However, there are quite a few problems with the class. First of all, CDB is teaching asp not ASP.net. When someone asked him why this was the case in class, he got very defensive. The answer seemed to be "this is what I know and I'm not willing to learn something else to teach it to you." If you're going to teach a class on tools and langauges, at least teach the latest technology, not one that will soon be obselete.

Speaking of learning new languages, this class seems to run counter to everything else that we're taught in the CS department. The focus of the class is learning as many languages in a semester as possible(asp, gawk, awk, perl, php, sql, etc.). Since many of these scripting languages are quite similar, and in most cases very easy to pick up the basics of in just a few hours, why spend time teaching so much syntax? If this stuff is truly going to be useful to anyone in the real world, why aren't they teaching concurrency, security, fault tolerance, etc? I can pick up php in an afternoon, but it's not that useful to me if I don't understand important concepts that will allow me to use it effectively. The class would be much better if it focused on a single language and spent most of the semester teaching concepts.

Posted by: Anonymous at March 31, 2004 8:51 PM

I hope you and others will pass along these ideas at the "fireside chat" this year (the annual meeting with our dept chair).

Posted by: rkc at April 1, 2004 11:08 PM

Another consideration is that a lot of companies (even the big ones) are moving to open source technologies for web applications. While it may take longer to build the same application in Linux/Apache/mysql you save the licensing costs of Windows .NET/SQL server. Over time that can be significant.

Posted by: mjuster at April 3, 2004 9:31 AM

Hey Michael! Is this true? So it's not worth the license of .NET even if development can be faster? I guess for a large number of deployments that would certainly be the case. Interesting point!

Posted by: rkc at April 3, 2004 10:02 AM

I'm a bit late to the game in responding to this post. I've been meaning to put some things together in response to this, but other things kept popping up. First, I don't really think licensing costs are keeping people from moving to .NET. At the place I work (I'm going to be a bit coy with the exact location since I'm delving into internal business decisions here) the decision was made not to go with .NET not because of the license fees but because of a one vendor concern. The thinking here being that being locked into one vendor is a bad thing.

So we do Java development, which is an open standard, but we certainly don't use free tools to do it. When you have millions of dollars of business activity going through your server, the appeal of having someone contractually obligated to fix problems greatly increases. So we do Java development and deploy to BEA's WebLogic application server.

But I'm not arguing that the web scripting class should go out and buy WebLogic or .NET licenses. But I think some time should be spent, at least in discussion, on more robust web processes. JSP, ASP, gawk, perl, etc. just don't really fit the bill these days. Developers seem to be moving away from embedding code directly into HTML. The approach taken by .NET (and emulated in the new JavaServer Faces standard) follows the Observer pattern (like Listeners in the Java AWT). Button clicks on web pages fire off events on the back-end that process things, then they forward to another page or populate fields on the current page and reload it. In this way the web front-end is becoming analogous to a Swing-based GUI. This new approach has a number of advantages. The principle one being that GUI changes are made much simpler when your business logic isn't embedded into your screens.

All of that is really background to my main point. I remember discussing this class with Dr. Loui and Dr. Butler perhaps 18 months ago or so at an ACM student/faculty mixer, when it was still in its proposal stages. They had already latched onto the UNIX/Windows split, and I tried to dissuade them from taking that approach. At the time it seemed like an arbitrary distinction to draw, and I think it remains to today. I can code something in ASP on a Windows server or PHP on a Unix-like server ans while the syntax won't be exactly the same, the concepts learned will be. The hardest part about ASP, PHP, and JSP is learning that code goes inline with HTML. I can move back and forth between them, putting a loop around a bit of HTML code, for example. Once you latch onto that concept, the rest is syntax. And teaching variations in syntax seems a bit foolish. You can pick up a $30 book for that.

A better approach, in my mind, would be to touch on a number of different approaches to web development. Touch on applets, cgi, asp/php, .NET, and perhaps a Java implementation. The Java is where things get complicated, because there are a lot of different technologies that you need to bring together, because everything is in a bit of flux right now. The current state would be to use Apache Struts (which builds on JSPs) as a front-end. How you implement your back-end is really dictated by the scope of your application. Your struts action classes could implement the business logic directly if you application isn't too big, or they could call out to EJBs to handle that stuff. However, Struts is on its way out. Its going to be replaced by JSF (the JavaServer Faces I mentioned above) which allows for more .NET-like behavior. This same behavior is available in Struts, it just takes a bit more effort. So a Java approach may or may not be appropriate given the complexity, but plenty of companies are using it because there are a number of server vendors so you aren't locked in to one manufacturer. And you could do the Java stuff for free if you wanted, which isn't the case with .NET.

Anyway, I would probably try to discuss all of these different approaches in lectures, with special emphasis given to the most important aspect of web-based development: database access. I would probably also assign two projects. The first would be simple project that only consists of three or four screens. The students could use any of the simpler languages such as ASP, PHP, JSP, or take cgi-based approach. Then I would assign a second project with perhaps seven to ten pages. For this they'd need to use .NET, Struts, or JSF for the front-end.

I'm also interested in building a front-end that is language independent of the back-end. The two could communicate using web services, which seem to be all the rage these days. So you could have a .NET front-end calling EJB-based web services on the back-end.

That's my first take on a web development class. It doesn't quite meet the criteria of web scripting (since it goes considerably beyond scripting), but I suspect that it would prove to be more interesting and useful to students. Although it would probably also be more time-consuming for students.

Posted by: david at April 12, 2004 11:37 AM

Nice take on all of this David! Want to teach the class? :-)

Posted by: rkc at April 12, 2004 1:27 PM

> Want to teach the class?

I don't know. It seems a lot easier to sit in the bleachers and tell everyone how it should have been.

Posted by: david at April 12, 2004 3:23 PM