Lucida Console Font on Emacs

Folks running Emacs on Windows (like me) might like to set their font to Lucida Console.
Until I find a tool or documentation on how to write X style font lines, I’ve copied some font-lines from other folks websites.

; (set-default-font "-outline-Lucida Console-normal-r-normal-normal-11-82-96-96-c-*-iso8859-1")
; (set-default-font "-*-Lucida Console-normal-r-*-*-11-82-*-*-c-*-*-ansi-")
; (set-default-font "-*-Lucida Console-normal-r-*-*-11-82-*-*-c-*-*-#204-")
; (set-default-font "-outline-Lucida Console-normal-r-normal-normal-12-90-96-96-c-*-iso8859-1")
; (set-default-font "-*-Lucida Console-normal-r-*-*-12-90-*-*-c-*-*-ansi-	")
; (set-default-font "-outline-Lucida Console-normal-r-normal-normal-13-78-120-120-c-*-iso10646-1")
; (set-default-font "-*-Lucida Console-normal-r-*-*-13-97-*-*-c-*-*-ansi-")
; (set-default-font "-*-Lucida Console-normal-r-*-*-14-*-96-96-c-*-iso8859-1")
; (set-default-font "*-Lucida Console-normal-r-*-*-15-*-96-96-c-*-iso8859-1")
; (set-default-font "-*-Lucida Console-normal-r-*-*-16-120-96-96-c-*-iso8859-1")

On Windows XP Pro, the difference in the font-line settings between font-sizes doesn’t seem to make any difference.
References:
http://www.crsr.net/Notes/Emacs.html
http://angg.twu.net/.emacs.local.w32.html
http://www.emacswiki.org/cgi-bin/wiki/JonathanArnoldDotEmacs
http://www.opensubscriber.com/message/[email protected]/8995847.html
http://www.charlescurley.com/emacs.html
http://www.dotemacs.de/dotfiles/AndreyAKulaga.emacs.html
Addendum 05/30/08:
Here is the answer.

Programming with Functional Objects in Scala

At the JavaOne 08 presentation “Programming with Functional Objects in Scala”, Scala‘s creator Martin Odersky summed up Scala’s mission statement for the audience:

Scala is the perfect mixture of Object Oriented (OO) and Functional Programming (FP). You get the flexibility of FP along with the familiarity of OO; along with the awesome power of the Actor model. Combine that will full speed execution on the JVM (in contrast to JRuby for example) along with seamless integration with existing Java libraries and you’ve got a platform that is tough to beat”.

Well said Martin.

Exposing the Depth JDK 7.0 Applications with DTrace

“Exposing the Depth JDK 7.0 Applications with DTrace” was the only lab that I attended at JavaOne 08. As you can imagine, it was all about dtrace.

dtrace is a no-overhead, highly dynamic, powerful programming language used to report on running systems. It runs on Solaris, FreeBSD, Mac OS X, and sorely neither Linux nor AIX (the two latter camps will roll their own clones on this one).

The tool itself is really delightful; in the right hands it can really work wonders.

I wish we had this on Windows, Linux, OS/400, and AIX.

Memes are Brainwashing

From Wikipedia:

A meme consists of any unit of cultural information, such as a practice or idea, that gets transmitted verbally or by repeated action from one mind to another.

Whether or not you agree in the validity of memes as a science (I don’t); the term is often used in authoratively in pop culture. They typically represent some bit information, usually in the form of a frequently repeated phrase, that spreads around and around the community. In the programming community, there are plenty. For example, here are a few: “convention over configuration”, “don’t write code just to make the compiler happy”, or “every developer must learn how to program concurrently: it is the future”.
The interesting things about memes are that they often have an element of truth behind them. For example:

  • “Convention over configuration”: Abstract away often repeated work
  • “Don’t write code just to make the compiler happy”: Use the right language for the task at hand
  • “Every developer must learn how to program concurrently: it is the future”: Use the right problem solving approach for the task at hand
  • “[My programming language] is purely functional“: For the type of program I am writing, side-effects are not welcome

The idea of memes is to pass around the interesting idea so that we can all benefit from it. The problem with them, though, is that they don’t. Instead, they sort of pass around a half-truth whose only intention is to further, most probably, some individual’s agenda. For example:

  • Lisp is convention or configuration taken to the extreme, but you never hear anyone saying that (If you hear me saying it, slap me), and they shouldn’t. Ruby on Rails is to Ruby as Struts was to Java; the only and therefore best of its time.
  • “Don’t write code just to make the compiler happy” is pretty silly. Use a statically typed language for a reason. Use dynamically typed language for a reason. There is a difference. You should understand the difference and its impact to your development process.
  • The IEEE, ACM, and nearly every presenter at JavaOne 08 preached fear of the multicore future without expounding on why every developer needs to master multi-core programming (solution looking for a problem?). That said: if every programmer learned how to program really well in the first place, we might not need 64 cores.
  • “Haskell is purely functional, so it is better than all other impure languages”: Please help me, the reader, understand why!

Because memes are half-truths, people often don’t get to the meaty goodness of the truths behind them. Perhaps at some gut-level they know there is a very good truth hiding back there. If, like most people, though, they don’t explore it further, then they will instead assume the meaty truthful goodness to be the ugly, half-truth of the meme. Since the community largely supports the meme; it becomes common knowledge that the individual must accept it in order to keep his place in the community.
Therein lays the danger of memes, whenever the meme is reintroduced, the individual sort of experiences the behavior modification reaction much like a Skinner pigeon; they have to buy into nonsensical statements about which everyone agrees. Sprinkle any article or blog post or discussion with any number of such memes and you have instant gold for making your point unbeatable. It is a strange and disappointing phenomenon that draws into question much of what is written in the tech world today.
Addendum: 12/10/08
Today I fixed typos, revised the grammar, and altered the content to reflect what I actually meant. As such, I believe this to be a “good faith” modification that didn’t merit change-tracking for the reader’s sake.

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.

Modularity in the Java platform

This presentation at JavaOne 08 could have been called “Features in Java 7 that people will love and wonder why it took so long to get them”.
The topic was JSR-277: The Java Module System.
Here is the 20K foot summary:

  • Give modules (roughly jars) first class language support
  • Provide support for module composition at deployment time

The result: no more Jar (aka DLL) hell and a lot of flexibility in terms of how you configure and deploy your system.

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.