Rev v. Java - How to structure academic project? (kinda long)

[Jim Witte]

Hello,

   The Computer Science department at my University (Indiana University 
Bloomington) teaches their first programming course in Scheme (!) and 
the second in Java.  I'm planning to try to do an independent study 
(preparing for possible grad work) about determining if, how, and why 
Revolution is better than Java for introducing programming to novices 
who've had nothing but Scheme.

   My great suspicion is that it *will* be much easier to learn, as well 
as develop applications which "do more" faster, possibly with less code 
(depends on how you count it, since in Java you're code in bunch of 
files, whereas in the Rev environment your code is spread all over 
everywhere), and be easier to debug.  Although I'm not completely sure 
of this (this is why we do science, after all!).

   My general suspicions about why it would be easier revolve around the 
english syntax of Transcript vs the C-style of Java, the "concreteness" 
of objects in Rev, and the indistinguishability between the "program 
guts" and the "program interface".

   The interface of the language I think helps especially when trying to 
avoid those pesky semicolon errors (which then cascade down so you have 
156 errors instead of just 1) and "plus one" errors in loop counters 
and array references.

   I see Rev (Hypercard originally) as being a more "concrete" example 
of OO than Java is.  In Java, you create an abstract class to 
*describe* a button and what it's actions are, then you instantiate it 
on a "canvas" (which you also have to instantiate) and then you run the 
program to get the interface.  In Rev, you simply create the button.  
In Java, there are actions (handlers/instance methods) linked to button 
objects, but they seem to me to be far removed from the "actual button" 
you see on the screen - they are in the source file.  In Rev, by virtue 
of the fact that you have to "open up" a button to edit its properties, 
script, etc, those scripts, properties, etc all seem much "closer" to 
the actual objects somehow.  (I also feel this way about the Mac GUI vs 
the Windows GUI as wrapping around filestream, but I digress..)

   This is connected closely with my third idea, that the *creation* of 
a program's interface and it's "guts" (algorihms, data structures, file 
handling code, serial interface code, etc) seem very much close 
together in Rev.  In Java, for instance (at least when not using an 
IDE) you'd write out your program logic in a text editor (usually in an 
abstract form first), then write the visuals classes (which access that 
first abstract layer), then actually run it to see what the interface 
looks like.  In Rev, you create the interface and the code which 
controls it/it controls simultaneously (or you can if you want.  Of 
course you can also write everything as a stack script handler and then 
have all the buttons make calls, but where's the fun in that.. [Of 
course, that was how a large part of the Revolution UI stacks look like 
they were done])

   What I'm wondering is if anyone else here has any pertinent 
information for background research into this type of programming 
psychology, or studies done on an xTalk environment before.

   I'd also like any ideas on how to formally test some of these 
theories.  One way would be to take two groups, teach one Java and 
another Rev ("just enough to get the problem done..") then turn them 
loose on a slightly harder problem (than the ones they had been shown 
how to do - requiring a bit of synthesis) for a week or two in Java or 
Rev and see which one finishes first or puts more bells and whistles on 
theirs.

   Another idea is to take a part of a class that just finished the Java 
class here (C212), teach them some Rev, then give them a problem to 
solve in Rev. (we like games in the lower-level programming courses 
here, so maybe a mouse-chasing-cat game or something).  The rest of the 
course would do Java (that could get logisically hard as it would have 
to be done while the Java course is still in session, uugh.

   These scenarios would help establish the basic premise that 
programmers can do more, faster with Rev than Java.  However, I would 
also hypothesize that not only could a programmer code up application x 
faster in Rev than Java, but that if you just gave two groups of people 
[students] (one Rev and one Java) some small, open-ended problem, the 
Rev people would go *much* further, especially in areas like graphics 
output, file output, and overall presentation of the app.  A recent 
problem given in my Artificial Intelligence class was to write a 
three-layer neural network (1 hidden layer) and then write a 
backpropagation routine to train it on handwritten digit data (in 
Scheme, of all programming lanauges!)  Now, In Scheme, I'm probably 
going to get about 50 percent of it done.  In C, I think I could have 
gotten about 70-100 percent of it done.  In Rev, I think I might have 
been able to finish it, as well as making a nice graphical 
representation of the network and a testing routine, almost "for free"

   Ideally, the best way to do this would be to design a Java/Rev 
course, to immediately follow the C212 class, and discuss what the 
students think is different from Java, which is easier, "cooloer", why, 
etc.  But, getting them to let an undergrad teach a class (and one he 
made to boot) might be a bit hard (to say the least), and I'd have to 
tread carefully to avoid stepping on various Java and Scheme toes in 
the department..  ("IUB:  Home of the Goddess of Scheme...")

Thank You,
Jim Witte
jswitte at bloomington.in.us  //  jswitte at indiana.edu