Friday, February 03, 2012

Some reasons to try out ZSH

I've been using bash forever, but I recently came across an article that introduced me to the wonders of zsh, more specifically zsh add-ons "oh-my-zsh".  Some of this is covered more thoroughly in the above article, but here's some great stuff that I've found in 20 minutes of playing around:

  1. Shared history file.  When you type history, you see a history of your commands that you have typed in any shell/terminal, throughout time.  I have completely had to re-learn things because the history command on bash let older commands drop out :).  It defaults to 10k commands, that should do for a while.
  2. Case-insensitive tab completion - just barrel right through all of those Upper Case Mac Directories, and don't stop to hit tab!
  3. Ignore dotfiles tab completion - barrel right past .svn and friends
  4. Spelling correct! When I was writing #1 above, I wanted to find what HISTSIZE is by default, and I typed "exho HISTSIZE".  zsh responded with "zsh: correct 'exho' to 'echo' [nyae]? ".  
  5. I haven't trained my fingers to do this one, but if you want to go to, say, /usr/local/Cellar/Rabbit, you can type "cd /u/l/c/r" and then tab: if it's unambiguous (it was for me), it expands.  Note I have a few possibilities for "/usr/l<tab>" - this suggests ZSH was smart enough to look ahead to try to resolve that ambiguity.
  6. Smart tab completion for command arguments: kill <tab> lists PIDs for you.  ssh <tab> lists hosts for you.  I can't wait to find other examples of this.
I'm sure bash can do all of this as well, I was just impressed at how oh-my-zsh had me up and running on this so fast.  

What am I missing?

Thursday, February 03, 2011

Scala's upcoming dynamic capabilities

I was surprised to see the Scala team check in a new "Dynamic" trait into Scala trunk recently.  Once this trait is mixed in to your class, any unresolved method calls are passed to an invokeDynamic() method, much like Ruby's method_missing.

I've been thinking about this a lot, and I see three decent reasons for the inclusion of the Dynamic trait:
1. Integration with dynamic languages on the JVM.
2. DSLs for accessing data where there's already no type safety, ie JSON and XML (written by @jorgeortiz85, I think)
3. DSL for reflection. Reflection libraries are ridiculously verbose, and like JSON/XML/etc libraries, offer little static typing benefits anyway.

I think #1 is very convincing.  LinkedIn and their LinkedIn Signal is one of the high-profile usages of Scala in industry, and it is a mixed Scala/JRuby project.  And why the heck not?  I'm very much warming to the idea that there is no Next Big Language, and programmers of different mindsets will be able to work together with the best tools possible.

Using the Dynamic trait is very easy, and really fun.  I thought I'd try hooking up Scala to Ruby using Dynamic, JRuby, and the Java Scripting Engine (JSR 223).  I was really pleased with how easy it was.  Here's some Ruby:

With a little setup (installing JRuby to get the "jruby" scripting engine and getting Scala trunk running), I had this simple Scala class:

The Ruby above can be annotated with type information, allowing jrubyc to compile down to normal old class files with complete type information.  In that case, we'd only need Dynamic for sugaring calls to "dynamic finders" which aren't declared in the class at all.  I imagine the situation is similar for other dynamic languages on the JVM.  I have to wonder why dynamic invocation would be preferable to calling static bindings of these dynamic classes.  I would love to learn more about how this will all work out in practice.

I have no information on this whatsoever, but from what I can tell this would be in Scala 2.9, which is slated for release in "weeks not months".

Update 3/28/2011:  For Scala 2.9This method is now called "applyDynamic", but is only available with the -Xexperimental flag.

Saturday, November 20, 2010

"Intro to Scala for Java Programmers": slides, code, and links

Last week, I presented a talk titled "An Introduction to Scala for Java Programmers".  I had a lot of fun making it, and I learned a ton.  I thought it was interesting that the more I learned, the more I liked Scala.  This is certainly not always true of technologies that look good at first!

Here's the slides.  They're probably pretty reliant on the speaking that typically goes with them, but maybe you will see something interesting.

Here's the code I used to develop the slides.  It's in the form of an Eclipse workspace.  To use it, you'll need the Scala plugin installed on Eclipse.  Unfortunately, you'll need to use Eclipse 3.5 (Galileo) instead of the latest.  Once it's installed, make sure you activate the Scala perspective, and import the sample code using File...Import...Existing Project Into Workspace, and use "Select Archive File" to import  The code is a downright odd collection of snippets, but I suspect it would be interesting to play with if you were curious about Scala.

Finally, I wanted to give better credit for some of the ideas and samples in the slides.

  • 3 interesting uses of traits: lifted from this awesome article
  • Actors: inspired by this great intro on Actors 
  • As useful as named parameters and default values are, I didn't have a good example to illustrate them until I found this intro on Artima
  • I think the format of the slides was guided by this article on combining OO and functional principles.
  • Many times, I ended up referring back to Programming in Scala for clarity.  It's a great general-purpose programming book.
Update: Some people have asked for a downloadable pdf - here it is

Tuesday, October 26, 2010

3 easy wins using Google Guava

Google Guava used to be known as Google Collections.  It is a large set of utility methods used within Google.  It aims to help you create concise and easy-to-read code.

1. Concise collection initialization - No example of Java being overly verbose is complete without showing a repetitive and noisy constructor like this:

Java 7 intends to introduce a "diamond operator" which allows the code to be converted to this:

This kind of change probably won't prevent any bugs, but in my opinion it greatly reduces code "noise".  Noise does not matter in a single-line example, but makes a big difference when multiplied across an entire system.

Google Guava provides similar functionality, today, and it works all the way back to Java 5.  It takes advantage of one of the few places Java does infer types: method return values.

Here, newHashMap is a static method on, with a static import.  It gets better, Guava can also be used to initialize collections with values:

java.util.Arrays.asList does something similar, but is actually immutable.  In combination with other techniques (many from Guava), type inference for collections and easy collection initialization can really clean up your code.

2. Multimap - How often are the values in your map actually a collection?  Imagine taking a group of people and grouping these people by last name using a Map.

Current way:

Using Multimap:

3. One-liners
Here's a small sampling of clever utility methods provided:

I've got to stop here, or I'll never finish. I have only covered a few of the classes I really love,  honorable mention goes to:

  • BiMap - Easily create the inverse of your map (keys become values and values become keys)
  • Ordering - Lots of nice extensions to Comparator
  • MultiSet - A set that keeps count of duplicates
  • Predicates and Functions - reusable objects for filtering and transforming your collections
  • AbstractIterator - Writing your own iterator is annoyingly tricky - this can really help
  • Forwarding Collections - Makes it easy to write your collection classes by delegating to existing collections classes (w/o boilerplate)
There's also a huge portion of the library I don't know yet, and really want to investigate:

  • MapMaker - Factory for producing maps for caches - makes a very tricky job easier.
  • Immutables - I'm a big fan of immutability, but haven't investigated Guava's extensive support for it yet

Friday, October 22, 2010

Scala's Option will save you from the most common cause of NullPointerException

A while back, Cedric Beust claimed "Scala’s “Option” and Haskell’s “Maybe” types won’t save you from null".  He's rightly convinced that Option is not a silver bullet for unexpectedly referencing null values at runtime.  However,  I believe there are "Good" NullPointerExceptions(NPE) and "Bad".  Option goes very, very far in saving you from "Bad" NPEs by enlisting the compilers help in tracking what is intended to be optional.

I believe there are two very different cases of NullPointerException:
"Bad" - The code incorrectly assumes the value is guaranteed to be set, but the value is null.
In this case "getPreferredTheme" is optional, but the programmer accesses it as if it will never be null in the current context. This is programmer error, due to the fact that the developer was unaware/not caring the value can sometimes be null. This is class of NPE I feel is the most common, and I believe the Option "pattern" can greatly, if not completely, reduce.

"Good" - The code correctly assumes the value is guaranteed to be set, but the value is null.
In this case, getCompany is designed to be set on a manager object. In my opinion, the developer should NOT try to accommodate getCompany returning null if it is specified that it never will. In the spirit of failing fast, the user should boldly use the object as it's specified.

In both Good and Bad scenarios, how was it specified that getPreferredTheme was optional and getCompany was required? In Java, I've seen a few approaches:

1. Sheer mental horsepower and subjective judgement. "Preferred Theme sounds pretty wishy washy to me, I better check for null". If you're not sure, check the javadoc, source, database schema, and any number of artifacts to inform your guess.  Good luck!

2. "Sentinel values" - Sentinel values are when you return a non-null value of the correct type, but with a wacky value to signify, well, null! For example, a binary search that returns -1 if the element isn't found. This is not the same as returning a default value, which is awesome when appropriate. Not realizing you're working with a sentinel value is identical to not realizing you are working with null. When you accidentally use it as a real value, it's gonna be ugly.

3. Annotations - JSR 305 defines some annotations which allow you to mark up your fields, variables and parameters as @Nonnull, @Nullable, @CheckForNull, @ParametersAreNonNullByDefault, and @ParametersAreNullableByDefault. A tool like windbags can process these annotations and give you warnings when you break the specification. I tried this approach for several months, and definitely had some success with it. However, it has a fair share of false negatives and false positives, and can be noisy. I gave up on it when I encountered code like this (paraphrased):
@Nonnull Person manager = ...
manager.getCompany(); //findbugs warns here - it doesn't know the semantics of checkNonNull

4. Naming conventions - I've tried preceding method names that can return null with a "try", ie tryGetPreferredTheme, and naming fields and vars using "optional", ie
private Theme optionalTheme.
This visually sets of the null access, and worked better than I'd thought. However, it seems a little noisy, and is very easy to overlook.

5. The "Null Object" Pattern - implement your interface using a "null" implementation.  Exactly like returning null, but more confusing.

Scala/Haskell and many other languages offer a 6th option: the Option type. In Java, our "getPreferredTheme" would change to this if it used Option:

Option is an interface with two implementations: "Some" to represent a real value and "None" to represent a null value.  Here's the code, adapted from this great article:

With the change above this would no longer compile:


Instead, the two choices are:
1. You just know it won't be null in this one special case:


get() will get you the actual Theme value if set, or throw a NullPointerException if not. What, a NPE? I thought we were avoiding those? We can't. I'm striving only to get rid of "bad" NPEs, ones which the programmer access the null reference out of ignorance or neglect. We only used get() here because we have assured ourselves it should be an error condition if it wasn't set - a "Good" NPE.  Think of it as a shortcut for "check for null and error out if it is null".

2. You're glad you were reminded it was potentially null, and can move on without it.

if (person.getPreferredTheme().isDefined()) {
...process the data

Yep, just a standard null check with a fancy name.

The important thing to note here is that accessing optional data without considering that fact is disallowed by the compiler. This cannot be said of the four approaches described at the beginning of the post.  You are moving what was previously developer busywork (which we're notoriously bad at) into the domain of the compiler, which excels at busywork. And not some whiz-bang language feature like Nullable Types or annotations either - it takes advantage of very simple classes.

It's also important to note Option should be used only on types that are specified to be optional.  I think a lot of people think Option is intended to protect you from all NPEs by forcing that extra check each time. Not so - just use it on your truly optional variables, and use your normal variables with confidence.

Option is absolutely worth trying in your Java project - I intend to try soon. I fear it may require too much boilerplate in Java.  Scala (and Haskell and others) make Option more appealing due to much stronger type inference (less noise) and a host of other tools for processing them beyond get() and isDefined(). The other tools available in Scala require much more of a leap of faith/new way of thinking.  They're also the source of most of Cedric's skepticism, I believe.  I hope to cover them in the next post.

"If it's worth telling another developer, it's worth telling the compiler"
-Guy Steele

Friday, July 09, 2010

A new syntax for Java closures/lambdas

I'm surprised this isn't making more news.  Brian Goetz of Oracle has posted a dramatic revision of Java 7's Project Lambda.   The syntax is much less noisy than the original version, thanks to a lot more type inference for parameters and return types.  I'm also really happy with how accessible the document is - the document is very readable, even for a "blue-collar" Java developer like me.

Thursday, May 27, 2010

Oracle pushes first version of Lambda/Closures implementation

Test cases may not be the best source of coding gems, as they're probably testing the weirder stuff.  But you can now see some test cases, and therefore the evolving syntax here.

Oracle has a tough task in adding closures to a language that has checked exceptions, minimal type inference, and without breaking compatibility of zillions of lines of existing code.  Go Snoracle!