I've worked at a couple of companies now where the hosts file is heavily leveraged to support multiple environments.  Through /etc/hosts file manipulation www.mycompany.com could be pointing to either dev, QA, staging or prod.  I prefer a more explicit approach but we'll leave that debate for another day. 

It's easy enough to write a little script to change hosts file, but I wanted something on the desktop that could quickly tell me my current environment.  Figured someone must have already written one but no luck.  So I decided to write one.  Problem is I'm pretty clueless about GTK, GTK+, GTK2 and GUI programming in general.

Then I stumbled upon the SystemTray class in java.awt.  It was perfect for what I wanted.  With just about 10 lines of code I was able to add this little system tray applet to the GNOME panel.

All it does is read in /etc/hosts and display the first line.  Now I'll never be left wondering which environment I'm pointing to.

Skimmed a paper titled "Pure versus Impure Lisp" by Nicholas Pippenger the other day.  Impure Lisp dialects allow mutations.  Pippenger wanted to know if pure Lisp, without mutation, was less "powerful".  Under two conditions he showed the following,  

A computation in impure Lisp upper bounded by O(n) is lower bounded in pure Lisp by big-omega n log n.  Basically, given the same problem there's a theoretical lower limit to pure Lisp's efficiency compared to impure Lisp. 

But then the guys at FP Lunch lead me to a follow-up paper titled "More Haste, Less Speed: Lazy Versus Eager Evaluation".  In it, Bird, Jone and de Moor showed that if you changed the pure Lisp evaluator to pure and lazy as oppose to Pippenger's original pure and eager then you can get the same linear time as the impure program.  Interestingly enough, the authors noted that lazy evaluation is often implemented with mutations behind the scenes (via memoization), so it's really a discussion of restricted mutation.  This is along the lines of an earlier posting I made about the problem with immutability and how compilers can, behind the scenes, solve some of the inefficiencies of immutability, but then it becomes a philosophical debate on what it really means to be immutable (or pure).

And that concludes another installment of interesting topics I'll never need to know.

Here's an example of where I read random articles just because the title is very catchy: F-Bounded Polymorphism for Object-Oriented Programming by Peter Canning, William Cook, Walter Hill, Walter Olthoff and John Mitchell.  Polymorphism is already confusing enough.  Just look at the Wikipedia entry on type polymorphism: "this article may be confusing or unclear to readers".

There's parametric polymorphism, let-polymorphism, impredicative polymorphism, ad-hoc polymorphism, intensional polymorphism and subtype polymorphism.  So WTF is F-bounded polymorphism then.  If there's no Wikipedia entry does it really exist?  Despite no mention in Wikipedia F-bounded polymorphism is pretty important and I'm using it everyday without knowing it.

Lets start with "bounded quantification".  With bounded quantification you can do something like this

Moveable {
 Moveable move(int x, int y)
}

Moveable moveMeOneInch(Moveable m) {...}

The method moveMeOneInch takes in some a Moveable, moves it one inch, and returns a Moveable.  It is polymorphic and will work on Cars, Trains, Points--anything that's Moveable.  All good, except we'll have to do some unsafe type casting.

Car c = ...
Car movedCar = (Car) moveMeOneInch(c);

But with Java 5 we can do something like this

<T extends Moveable> T moveMeOneInch(T m) {...}

Car c = ...
Airplane p = ...

Car movedCar = moveMeOneInch(c);
Airplane movedAirplane = moveMeOneInch(p);

and get the type safety we want, because "run time is a little late to find out whether you have a landing gear".  What we've done is created an "F-bound".

F-Moveable[t] = { move : int, int -> t }
F-Moveable[Car] = { move : int, int -> Car }
F-Moveable[Airplane] = { move : int, int -> Airplane }

Note the type appears on both sides. 

Here's a real world example.  The Collections utility class has a max method that takes in a Collection of Comparables and return the max of the collection.

public static <T extends Object & Comparable<? super T>> 
 T max(Collection<? extends T> coll) {...}

//Integer implements Comparable<Integer>
Collection<Integer> ints = ...
Integer i = Collections.max(ints);

Here we bound the type of the collection and the type is part of the bound for Comparable.  A collection of integers, and integers are comparable to integers.

That's F-bounded polymorphism in a nutshell.  Now you can say, "yea, I like Java, it supports F-bounded polymorphism."

A couple of years ago I wrote a now deleted blog post about how every web application should use a template engine for the presentation layer and how much I hated JSPs.  Here's my second attempt at convincing the developer community to stop using JSPs or similar technologies for view rendering.  I will approach things this time by piggy backing off dependency injection and functional programming.  Both dependency injection and functional programming are very popular these days and the community has largely accepted their benefits.  If I can convince you that template engines is dependency injection and functional then it's a no-brainer to start using template engines on your projects.

Think about how a typical JSP is rendered.  It'll make calls to each of the various scopes to get some information, maybe even a call to the database--or worse.  You'll have a hard time tracking down all the JSP's required data (dependencies).  Moreover, you'll have a hard time tracking down how the data got there in the first place.  This is especially true of session scope data.  Random flows in your application adds random crap to the session--good luck hunting things down.       

JSPs are just too powerful, flexible a mechanism for rendering the view.  With great powers comes great responsibility.  I'm sorry to say, we programmers are not capable of such great responsibility.

Contrast the above diagram with how a template engine works.  Dependencies are "injected" into the template.  The template is very limited.  It can't make random calls to the outside world, there are no complicated scopes--there are no scopes period.  Templates can only do one thing, take some input, render the output.  The input should be immutable base types: strings, integers, etc.

 

Template engines is dependency injection without the cool sounding name.  Just like how Guice or Spring inject dependencies into your Java classes, template engines inject dependencies into your templates. There are no "hard links" with templates. All the benefits of dependency injection applies to template engines.  Think about how much easier it is to test, debug and maintain templates than JSPs. 

There would be virtually no objections to introducing Guice or Spring into any solution stack.  DI is a no-brainer (except that we really should have the language provide us DI, but that's another topic).  Yet it amazes me that in 2009 template engines haven't reached the same level of awareness and acceptance. 

OK, fine, you're not really that into dependency injection.  How about thinking about template engines as functional and JSPs are imperative.

// imperative, full of side effects
String html = myJSP.render();

// functional, referential transparency, composable
String myTemplate = ...
String html = render("Tinou", "tinou.com", 
   "you're broke", myTemplate);

JSP rendering is very imperative.  It's potentially full of side effects.  Calling myJSP.render() twice might give you back different HTML each time because JSPs can use gloabl state.  Basically, you have no idea what's really going to happen when you invoke render. 

Contrast this with the functional template approach.  There's a render function that renders the given template with the given arguments.  You call render a million times and it'll produce the same HTML. You can compose templates together to produce bigger, more complex output.  You can't compose JSPs--good luck with trying to "include" JSPs.  Templates give you all the advantages of the functional programming style.

I probably can continue and make an analogy of how JSPs are like GOTO statements, but if you're not convinced by now that templates are the way to go, another comparison probably won't persuade you.

I picked up Real World Haskell last week when Gilad Bracha warned me that I might become unemployable if I don't brush up on my functional programming skills.  I found his comment amusing because I have Lisp on my resume and have always wondered if anybody cared that I know Lisp.  Know is an exaggeration;  all I remember is cons, car, cdr and thinking why the f*** are there so many parentheses.  Yet here I am, a decade older, reading up on lambda-calculus and folding to remain marketable.

One thing that might confuse the imperative programmer when reading Haskell code for the first time is the unfamiliar function definitions.  In Java if you have an "add" method that adds two ints and returns an int you might write it as

add (int, int) : int

or

int add (int a, int b)

or

(int, int) -> int

In any case it's clear that add takes two ints and returns an int.  But in Haskell your add function will be

add :: Int -> Int -> Int

You might guess that the first int is the first argument, the second int is the second argument, and the final int the return type.  But not really.  In Haskell all functions are single argument functions.  Add is a function that takes an int, returns a function that takes an int, returns a function that evaluates to an int.  Here's an example with the map function. 

map abs [-1,-3,4,-12] 
[1,3,4,12]

:type map
map :: (a -> b) -> [a] -> [b]

It appears that the map function takes two arguments, a mapping function (in this case the abs function that returns the absolute value of a number) and a list, and applies the mapping function to each element of the list.  But as you can see in the type definition map is a function that takes a mapping function (a->b), returns a function that takes a list [a], returns a function that evaluates to a list [b]. 

This is because the lambda-calculus which Haskell is based upon doesn't have built-in support for multi-argument functions.  It'd be pretty easy to support multi-argument functions according to Benjamin Pierce, but to confuse us imperative programmers they decided it would be easier and better to use higher-order functions (functions that accept and/or return functions). Instead of f = λ(x,y).s we have f = λx.λy.s.  Then we would just write f v w and do two "reductions" instead of writing something like f(v,w). 

Converting multi-argument functions into higher-order functions is called "currying" after Haskell Curry, for whom the Haskell language is named.  Haskell was a contemporary of Alonzo Church, who developed the lambda-calculus during the 1920s.  While at Princeton Church supervised the doctoral thesis of Alan Turing, the tape machine guy, who committed suicide in 1954 after being prosecuted for his homosexuality.   (That was for all the history buffs out there.)

Once you see it a few times the notation becomes "normal".  It's actually very elegant (among other things).  Everything is a single argument function.  I mean everything.  You know how Smalltalk guys are always saying everything is an object, well the lambda ultimate guys say everything is a function, including numbers like 23 and 17.  Maybe that's what Java's missing, a pithy tag line.  Java, where everything is a....

In my last two blogs on The von Neumann Bottleneck and The Problem with Immutability I was flushing out some thoughts on immutability, side effects and the difference between functional and imperative programming.  One thing I continue wrestling with is reconciling "no side effects" with the real world need for side effects.  We know that side effects lead to all sorts of problems but how can we eliminate side effects and still be left with useful programs?  The answer seems to lie in these magic monads that everyone keeps talking about.  So I spent some time skimming some papers on monads.  It seems as though I'm late to the party.  2007-2008 was the big year of the monads, when people were comparing them to burritos, elephants and sexual conquests.  But I'm always late to the party. 

After a day of casual reading I kind of get monads.  There's left unit, right unit, type constructor, a bind function and a couple of other goodies.  Still a bit abstract since when was the last time a Java programmer like myself ran across an explicit monad.  But something still felt off.  Philip Wadler writes in "Monads for functional programming"     

Monads provide a convenient framework for simulating effect found in other languages, such as global state, exception handling, out-put, or non-determinism

So aren't monads just a neat math trick for keeping things pure when things are in fact full of side effects?  That's like me saying my apartment is clean after I shove all my junk in a closet out of sight.  No, it's still dirty, you just can't see it anymore. 

Then I saw this video of Brian Beckman of Microsoft Research explaining the state monad and I think I'm one step closer to my "ah ha" moment.  Sequential programmers (Java, C, etc.) live in a huge ambient monad.  In this ambient monad side effects (updates) are allowed.  FP forces you to live in smaller monads.  Brian Beckman:

In fact there's nothing wrong about side effects at all, it just how disciplined, how precise are you going to be in your use of side effects.  If your programming language allows you to update any variable then you can never tell by looking at a variable whether it has been side effected. All Haskell does is discipline the side effects; so if you're doing side effects you have to do them in an explicitly written monad.  So now you can tell.  The stuff in the monad may have been side effected by whatever function was ahead of you and may be side effected by whatever function is behind you...It's precise in the text of the program. In a programming environment [like c# or vb] you are in am ambient monad so everything is updatable.

OK, this makes a lot more sense now.  Side effect is not this horrible, terrible, bad thing you absolutely cannot have (duh), you just need to be precise with it.  There's no way to be precise with it in Java or the imperative languages (enforce preciseness), but there is a way to be precise with it in functional languages.  Monads make this precision more convenient than passing the world around as was done in the past.

It should be noted that Beckman goes on to say that monads are not a panacea.  While reading up on Haskell one question in the back of my mind was how does Haskell do logging?  In Java I can do something like System.out.println("the value of x is " + x), but does this mean I have to use the IO monad now to do basic logging?  And Beckman points this out as a shortcoming, that to just do a printf you have to rewrite your functions to use monad.  I guess that's why there's some "unsafe" IO stuff you can do in Haskell, but as the name implies it's unsafe and the compiler can't guarantee things, as it can with monads.