Every widget in Swing, WinForms, and pretty much every other last-gen interface framework is a big bundle of state. First you instantiate the object, and then

Every widget in Swing, WinForms, and pretty much every other last-gen interface framework is a big bundle of state. First you instantiate the object, and then you make a series of function calls to set all the right toggles. So far, this doesn't seem like much of an obstacle. Clojure has (doto ...), which lets us trim some fat, so at least we're beating Java, right? The problem, though, is that Java has tools which autogenerate this boilerplate, letting the programmer treat setup as an atomic step. When writing it out by hand, you have to worry about the order of your calls, and that when you copy/paste some code you change all instances of layoutPanel1 to layoutPanel2, because otherwise you get the obscure NPE mentioned by the author. The above problem is why the current-gen interface frameworks (WPF, GWT, and Android) all rely on XML schemas for high-level layout. Schemas avoid a whole class of programmatic error that can arise in this initial setup, and can be sanity-checked in a number of ways thousands of lines of code cannot. Unfortunately, this still doesn't solve the other problem: callbacks. Callbacks are chock-full of side effects, and fragile for all the same reasons mentioned above. There's no equivalent in a Swing scene graph to XPath or CSS selectors, which means that your code is closely coupled to the current hierarchy, and fragile if it changes. What this all means is that it's hard to introduce very much abstraction into the creation or modification of Swing interfaces. My theory, which I have not tested, is that if you modeled the initial interface as a schema, and forced callbacks to be purely functional modifications of that schema, it would be a much less painful experience writing UIs in Clojure.