Writing the next great Java book

At JavaOne 08, the presentation “Writing the next great Java book” looked to be pretty exciting. It was originally billed as an introduction to a couple of authors, a QA session, and then primarily a review of great books in Computer Science history so I was pretty excited. In reality, it was very disappointing.
The authors blabbed about the same “Authoring 101” that you can pick this up on any “Intro to Authoring” website. In other words: it is really difficult, it will take four times as long as you think, and your family will hate you. The rest of the session was exhausted by the “Head First” authors Kathy Sierra and Bert Bates giving the same, canned presentation that they’ve been giving since at least 2006 (the first time I saw it).
Now don’t get me wrong; Sierra and Bate’s presentation is awesome. It is a lot of fun, and you learn a lot. The problem is that you learn a lot about selling; not about writing. Take the tenets for example:

  • Passion: Enable people’s passion
  • Experience: Provide a no-suck experience
  • Feeling: Don’t make people feel stupid; make them feel like they kick-ass

Very, very cool ideas. One problem, though; Computer Science is hard. You will feel stupid. Self-reflection is part of learning, and saying to your self “Darn, I don’t get this. It is only 5 sentences and I don’t get it. I feel stupid”. The next step is to press on and learn it. Books don’t make you feel stupid, you do; it is part of learning!
Now, if you truly find a book that sets out to make you feel stupid, be amazed, because such books are sure not to sell any copies. Contrast that with the classics of Computer Science that are works of art, and may involve you feeling stupid, but surely don’t set out with the intention to make you feel stupid, but to teach!
To wrap up the presentation, no time was given to classic Computer Science books.

Closure Cookbook

At Java One 08 Neal Gafter gave the “Closure Cookbook” on Closures in Java; in particular the BGGA implementation that he is proposing as a JSR.
To sum up the presentation, it was about closures, in Java. In particular, it went into explaining what are closures and how you might use them. The tough, and more interesting part, is how you would use them in a statically typed language like Java.
It will be interesting to find out what percentage of the Java community will actually grok how to utilize closures. The impression that I got from the presenter is that closures will be limited to the library and API writers in all but trivial cases.

Java One 08 Keynote

Is Sun in touch with Java developers?
The entire keynote was spent talking about how developers are soon going to be able to write applets that run on a desktop, in a web browser, and also on a phone. We have had this for years. Whose idea was this?
The really interesting stuff in Java land right now is Java 7 features and concurrent programming with Java, but apparently none of that was worth mentioning.
The worst part of it all is that during the demo, the applet repeatedly crashed, and crashed, and crashed. The first Java program that I ever saw was running was an applet running in a web browser, in 1995.
13 years to get applets right? Come on Sun.

Fortress: A Next-Generation Programming Language Brought to You by Sun Labs

“Fortress: A Next-Generation Programming Language Brought to You by Sun Labs” is the first session I attended at Java One 08. Being that this is my first time at Java One, I was pretty excited to see how both this session, and, the entire conference, would pan out.
Per her introduction, her background is big into parallelism, and like everyone else on they team, she is an old Lisper.
The focus of her talk was the top 10 ideas in Fortress. Apparently the original tag line for Fortress was that “Fortress will do for Fortran what Java did for C”. That makes sense since they were funded by the high performance computing people, but it isn’t the catchiest tag line.
Here is her top ten list for Fortress language features:

  • 10. Contracts. Requires, Ensures, Invariants.
  • 9. Dimensions and Units as fundamental types.
  • 8. Traits and Objects. Probably borrowed from Smalltalk.
  • 7. Functional Methods. I didn’t get this.
  • 6. Parametric Polymorphism.
  • 5. Generators and Reducers.
  • 4. Mathematical Syntax. One of the driving forces of Fortress to make a PL familiar to Mathematicians.
  • 3. Transactional Memory. She thinks it is “cool beans”.
  • 2. Implicit Parallelism
  • 1. Grow able. The big idea. Designed from the beginning.

Fortress is a hodge podge of cool language features; all of which are very cool (STM and concurrency were her favorite).
The last feature was the most exciting. I expected the entire room to say “ooohhhhhhh” at that moment, but no one did. I suspect no one had a clue as to what she was talking about. I would love to have syntactic extension facilities in Java. Since one of the background goals (my assumption) is to research language features that would eventually show up in Java, we’ll have to see what happens :).
While I got the impression that the presenter gave this presentation as the result of choosing the smallest straw; it was one of the top presentations out of the entire conference.

Why Emacs?

Emacs is a text editor built on top of a Lisp (Elisp) interpreter. The full API of the both text editor and the Lisp interpreter itself is available to the user.
For this reason, along with the fact that there are hundreds and hundreds of useful additions available to Emacs, I am learning it.
There isn’t anything more to it than that!

How to print a PLT Slideshow to a file

Here is how to print a PLT Slideshow to a file:
slideshow -P -c -o [output file] [input file]

  • -P: print to postscript
  • -c: (condense) flatten the output file in the case that you had built slides incrementally

Addendum: 05/17/08
The ‘ps’ argument doesn’t seem to work. I must have used the alternate ‘P’ originally for printing, but posted the other option, ‘ps’. As such, I’ve updated this post. I will look into this. Additionally I’ve changed the condense argument to ‘c’.

Scheme Versus Common Lisp: Why?

Anyone new to Lisp will quickly find that among certain folks there is very much an “us versus them” mentality when it comes to Scheme and Common Lisp.
Is it just human nature that drives the mentality? Is it boredom?
Since Scheme and Common Lisp are both Lisp dialects, in some ways they are very similar; but in other ways they are quite different. The thing is that every language decision is a trade off from which we can learn. Most students of programming would look to both the similarities and differences in each language and recognize their function and beauty!
One thing that I can guarantee that you will notice pretty quickly once you start hanging around Lispers (in general) is that there is a noticeable difference in attitude and demeanor among folks that have studied and appreciate both Common Lisp and Scheme, and the folks that have not.
The folks that have studied and appreciate both languages are simply a much more pleasant group of people to be around. Perhaps that is how the expression about “the haves and the have nots” came to be?