- Comparison with ACM Graphics -
Here is a comparison of the zio package with
ACM Java Task Force Rationale, PRELIMINARY DRAFT -- December 10, 2004
written by the creator of zio.
Some short comparisons:
Some longer comments:
My first comment is about the risk you take adopting the zio package. Can a package supported by one person be as safe to adopt as one supported by many people and two institutions (ACM and Sun)?
NO and YES.
No, because one person cannot consider all ramifications of what he is creating or provide backup support for himself.
Yes, because zio is a small, well-documented, open-source system. “Small” is the keyword here. That word means:
My second comment concerns file I/O. Perhaps, I missed it but I haven't seen it in the ACM proposal. File I/O in Java is very flexible and very complicated. File I/O is also something with which beginners should have a little experience. The zio package offers it for text files in a form that is identical to the console I/O and it offers it (along with digital image I/O) with methods that perform whole file I/O.
Whole file I/O didn't use to be a common phenomenon. With the memory capacity of today's machines, it has become common in scripting languages. There are also good pedagogical reasons for using it: once you get that file into memory you have to get it into a form you can use and that usually means some kind of array. The bottom line here is that if you use whole file I/O you need say very little about I/O and you have another excuse for emphasizing arrays. I do think the ACM proposal was remiss in not including this feature. Of course, they can still add it but remember the virtues of small?
My third comment is that, even though I was unaware of the ACM proposal until today, it is interesting how similar my thinking was to the ACM committee's. The short comparisons above show this similarity and so does a look at the committee's concerns about the Java language. Here are the first two they list:
The ACM committee's first Java language concern, which they label L1, is that students are confused by what should be static and what should not. This was on my mind as I created zio. With my students, I distinguish between two kinds of classes: method defining (which exist only to define a set of actions that can be used independently of each other) and object defining (which exist only to define objects, that is data with a set of methods for manipulating that data). In method defining classes all methods are static. In object-defining classes all methods are not static. Instance variables, too, are static in method defining classes and nonstatic in object defining classes. However, instance variables are very rare in method defining classes, mostly being limited to the definition of constants.
Clearly this dichotomy is not the way the Java API does things but it is a convenient fiction and, as of July 13, 2005, the public and protected methods and variables in the zio package fit entirely into this fictional world.
When teaching Java the one time where I find I must talk about classes that have both method-defining and object-defining characteristics is with number formatting. Because the zio package supports formatted output on the console and on text files, I can put this awful day off to the end of the semester.
The ACM committee's second Java language concern, which they label L2, is the way Java forces beginners to be aware of exceptions. Both the ACM committee and I judged this to be unacceptable.
The committee has other concerns but it was with the first two that I felt the greatest resonance.
My fourth comment concerns the fact that the zio package does not encapsulate Swing and/or AWT. This is the price that needs to be paid in order to get an incremental transition from zio to the Java API's way of doing things. It is a price that the designers of the ACM proposal were not willing to pay.
Personally, I think it is a small price. Encapsulation is a software maintenance issue and I am as concerned about maintenance issues as the rest of you. (Probably even more so, after all I did serve on the editorial board of the Journal of Software Maintenance for a decade.) But I believe we are starting to overdo encapsulation in our beginning courses.
We emphasize encapsulation in the hope that programmers trained with Good Practices from day one will take the time to design in fully encapsulated patterns when pressures for quick solutions are on them. It is probably a vain hope. Future programmers will remember how much of a hassle it was to encapsulate things and they will still start their careers without the kind of experience that shows why the encapsulation hassle pays off.
Furthermore, it is real questionable whether the hassle does pay off when the program is quite small and for individual use. Do remember, we are teaching beginners, not software engineers. Most of those beginners will not become software engineers; they will write small programs for individual use.
My fifth comment is that the ACM system does nothing to help high school students compete in the USACO contests. My students have used zio's Input and Output classes in the online contests that occur monthly during the year. They have had to cut and paste the source code into their programs and mark the insertion as "not written during the contest". Still without some help from you, your students will not be able to do the I/O required in these contests. The zio package helps you give that help.
I intend to get a comment mechanism built into these web pages some day. For now, you'll have to settle for writing me and hoping I'll be moved to incorporate your ideas (with or without attribution as you wish) into these web pages. Write to firstname.lastname@example.org where mmm=jan,feb,... and yy is the last two digits of the year.)
|context||Jul 13, 2005||author|