Apr 29
I bet some profs saw Java as a simple language to teach back in the day.
After seeing some of the generics hells that you can see in javadoc, we can also see a ’simple’ example of the future:
<R, T extends java.io.Closeable, throws E>
R with(T t, {T=>R throws E} block) throws E {
try {
return block.invoke(t);
} finally {
try { t.close(); } catch (IOException ex) {}
}
}
I am glad I don’t have to teach Java. I would be running to teach Scheme for data structures 101…. or Ruby/Python…. or Haskell/Erlang….
April 29th, 2007 at 4:01 am
And so Java became C++.
April 29th, 2007 at 5:31 am
Now that’s some readable code. Java is getting closer to a write-only language.
April 29th, 2007 at 5:32 am
I do teach Java, and I’ll be happy for students to look at the documentation for ‘with’, and not worry about the funny notation for a while. After all, they’ll never actually need to write closure-accepting methods.
My students are more likely to use addActionListener() {
stuff..
}
and understand it, than they are the anonymous class route.
Java just keeps pushing the bar up for other languages. Can you imagine a new popular statically typed language now without generics? Soon we won’t be able to imagine one without a good notation for closures.
By the way, I’m not sure how you think closures will affect your data structures lectures, unless you cover useful constructs like map, fold (reduce), etc., in which case they would certainly make it easier.
Sure, the standard “this is a drawing of a linked list, go and write your own” lecture isn’t going to be improved by closures, but isn’t it time to move on from that?
April 29th, 2007 at 5:33 pm
Ricky,
I agree with a lot that you are saying. Closures are like the conditional tense. It was great when I was twelve and could use “me gustaria” to get points for using the conditional tense. Often closures are so clearly a better way of doing things, so you use them without knowing “I am using a closure now”.
I love closures. I use a Closure.java. It will be great to have them as first class citizens in Java.
However, I worry that we are strapping on too much to Java itself. We don’t have to keep adding and adding and adding to Java the language. The beauty of Java is the top class VM and stdlib. Maybe we don’t have to keep throwing mud on the ball to “keep up with the jones’”.
Cheers,
Dion
April 29th, 2007 at 6:52 pm
Is this a syntax issue? Or a semantic issue? That is the real question. For example, what about this syntax:
<R, T extends java.io.Closeable, throws E>
R with(T t, Closure<T return R throws E> block) throws E {
. try {
.. return block.invoke(t);
. } finally {
.. try { t.close(); } catch (IOException ex) {}
. }
}
April 29th, 2007 at 7:16 pm
generics for API design is an advanced topic. All langyages has advanced and complex sytax stuff. this features are not meant to be taught as undergrad lectures. Also, the example you show is an extreme and handpicked. lame.
April 30th, 2007 at 6:47 pm
It was hand picked from the proposal itself. Since that is the only place to look at…. hardly like I scoured the world to find it ;)
Cheers,
Dion
May 1st, 2007 at 1:34 pm
You should be teaching algorithms, software engineering, language and compiler theory, etc to students, not arcane language constructs or Java/C#/Scale/Ruby 101.
So in this case, unless you are trying to teach about closures, your students shouldn’t see this code, but hopefully they’ll be able to read a document and understand it someday (if you are a decent professor).
May 2nd, 2007 at 9:50 am
I am a computer science professor, and I agree that it is depressing for the students (and teachers) when they realize that they will never know everything about the Java language and library that there is to know.
But what does that have to do with your example? This syntax is unfamiliar to you and me because it is new. Well, every Java syntax is unfamiliar to students because it is new to them.
public Employee(String name, String department) {
super(name);
this.department = department;
}
That’s easy for you, but it is no picnic for a freshman.
Or how about
Writer out = new FileWriter(”output.txt”);
try {
…
} finally {
out.close();
}
Piece of cake, right?
Umm, I would prefer if my students learned
with (Writer out = new FileWriter(”output.txt”)) {
…
}
Now you may say “If you let them use with, shouldn’t you teach them how it is implemented?”
If I follwed that logic, I surely should tell them how FileWriter is implemented. Let’s see. FileWriter is a simple wrapper around FileOutputStream. Here is the FileOutputStream constructor
public FileOutputStream(File file, boolean append)
throws FileNotFoundException
{
String name = (file != null ? file.getPath() : null);
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkWrite(name);
}
if (name == null) {
throw new NullPointerException();
}
fd = new FileDescriptor();
this.append = append;
if (append) {
openAppend(name);
} else {
open(name);
}
}
Ok, boys and girls. Listen carefully, for we have a long road ahead of us. Let me tell you about the SecurityManager…
I don’t think so.