You could imagine my excitement when I read the following on the Google Closure page:
“It also also checks syntax, variable references, and types, and warns about common JavaScript pitfalls. These checks and optimizations help you write apps that are less buggy and easier to maintain”
But then I tried the compiler and it thinks this code is dandy:
// ==ClosureCompiler==
// @compilation_level ADVANCED_OPTIMIZATIONS
// ==/ClosureCompiler==
function upper(s)
{
return s.toUpperCase();
}
function add(i)
{
return i + 1;
}
var i = add(new Array());
var s = upper(new Array());
alert(s);
alert(i);
Dynamic languages are evil. They cannot be tamed by mankind.
Over the years, I had heard much about Lisp. Articles I had read, or colleagues who knew it, would espouse the benefits of learning it or using it. Promised results ranged from making you a better imperative programmer to the highest intellectual enlightenment that could be achieved. So I dove into Lisp. Except it wasn’t diving. Well it was like diving if the body of water you are diving into is covered with 18 inches of ice, and you need to use a sledge hammer to make a hole to dive into. And then your mind and body react to diving into close to freezing water. If you come from a strictly imperative programming background, learning Lisp and/or Functional Programming can be a battle. I’m pretty sure it’s easier to learn Lisp and FP if you don’t know anything about programming.
So I started reading bits and pieces about Lisp, but without actually coding in it, I really didn’t get it. I needed to code. But what were the options? Islands. Islands with libraries that promised this and that but still little islands. Then I met Rich Hickey and his language Clojure. Clojure is a much improved dialect of Lisp that compiles down to JVM or CLR byte code. Continents. Continents with lots of libraries and documentation. I could now easily connect to SQL Server and do some real world stuff. Yes, Clojure is a dynamic language, and I’ve mentioned I prefer static languages, but Clojure is filled with awesome.
Although Clojure along with other Lisps are functional programming languages, Lisps have a very unique property that other common FP languages don’t have: Homoiconicity. Thats fancy talk for saying the code and data have the same shape. Data structures and code are represented the same way: s-expressions. This is what drives the powerful Lisp macro system. The macro system is what makes the language changeable. If there is a feature you want that’s not in the language, you can add it. This point was really driven home to me when I learned about the F# pipeline operator: |> . I thought, see this is a nice feature that Clojure doesn’t have. Until I realized that someone had built a pipeline macro for Clojure. This is from core.clj:
(defmacro ->
"Threads the expr through the forms. Inserts x as the
second item in the first form, making a list of it if it is not a
list already. If there are more forms, inserts the first form as the
second item in second form, etc."
([x form] (if (seq? form)
`(~(first form) ~x ~@(next form))
(list form x)))
([x form & more] `(-> (-> ~x ~form) ~@more)))
If F# didn’t have |> there would be nothing you could do [Update: That is not true. As Brian pointed out in the comments, F# allows you to declare infix operators.]. Don’t get me wrong, I’m a HUGE fan of F#, it just doesn’t have a macro system. But it is statically typed 
I’m a refactorer. My title’s have had the words developer or programmer or engineer or architect. But really a lot of what I do is refactor. I mean even when I design and build something from the ground up, part of that process involves refactoring. You start with a design, you start coding with that design in mind but inevitably you realize an hour later, maybe a day or two later, that part of your vision of the problem or solution domain was wrong. So you refactor. I can’t imagine doing this with a dynamically typed language. The very beginning of creating a thought about potentially having to do this immediately causes my brain to shutdown.
You get two years into a large enterprise application with hundreds of source files. You realize you need to refactor a couple of the fundamental classes/libraries used in your system. It’s not because you were an idiot when you designed the things, its just that business has changed. The problem has changed. You need to adapt (refactor). It’s the right thing to do. It is good for the future. Are you a spineless ninny? Your’e not. You refactor. It’s not that bad, 341 compiler errors, but it doesn’t compile.
And don’t give me the old: “but all I need to do is grep for…”