I have a new blog!

My new blog is here. It has images and code, since I'm getting all serious about this stuff now. Maybe it will even have screencasts of me doing unnatural things with my emacs.

Objective-C, Javascript

There are relatively few programmerly things that benefit from being done in a GUI. Most everything is better done as text or on a command line. But UI creation is a big exception to that. UIs are definitely best done in a builder. My experience with Cocoa's Interface Builder over the past month has been awesome. It's so awesome, I don't know how I could even ever go back to doing things by hand. That's how awesome it is.
What's more, it's turned me on to other GUI builders, like the one for WPF in Visual Studio; and it's totally obliterated any lingering desire I've had to write Swing or *name-that-framework* code anymore. Clearly, the way of the future is XML markup. And that's the key difference between something like Winforms and WPF or Cocoa; there's no generated code, just generated XML, and that XML is simply read in at runtime to set up your widgets and your event bindings. That's the way to do it -- it sortof has a web feel to it even.
Anyway, I can't ever go back to writing Swing GUIs by hand. It's too monstrous. And all the Swing GUI Builders just generate crappy Java code for you. I don't want code generators, I want markup generators. I want something like Glade for GTK, except for Swing. Though I'm not sure I'll ever get it since Sun has abandoned Swing and nobody likes Java Desktop Apps anyway.
But Objective-C is actually a pretty awesome language, and combined with Cocoa and all the Apple tools, OSX is a pretty awesome platform for rich application development. Everything is easy to use, the Objective-C runtime, though lacking garbage collection, is dynamic and has an excellent reference counting facility -- the Cocoa API is consistent and comprehensive... it's a pretty awesome package overall, and I can see why developers like developing applications for the Mac.
It does bother me though that I'm dependent on their tooling to be productive on Cocoa. You can't really write Cocoa interfaces without the Interface Builder, and all that stuff only runs on Mac and only is available for Mac. I might have missed it, but as far as I know there is no interface builder for GNUStep -- I don't even know if GNUStep has a UI library like Cocoa; maybe some sort of wrapper for GTK.
Anyway, I had an awesome time developing for the iPhone and for the OSX desktop environment, and I think Objective-C is a cool language that really intrinsically fits the MVC model and suites the task of creating desktop applications really well.

----


Javascript is really Scheme. It's Scheme with a half-assed, ugly varnish of C. But it's still Scheme to the core, and a lot of its querkyness can be explained in terms of it being Scheme; once you understand that it is Scheme, you understand why it behaves in certain ways. Like why variables declared in an if statement or a for-loop are available throughout the enclosing function scope. That's because, like in Scheme, environment is a factor of functions. Every time you create a new function, you instantiate a new environment to place your variables in. For loops and If-statements don't create new functions, so the environment your in, and hence all the variables you declare, are declared in the enclosing function scope, just like they would be with scheme "(define x 1)", but instead you have "var x = 1;".
Javascript could have been a lot more awesome if it had just been a little more straightforward. If they could have skipped the C-ishness, and just done straight Scheme with some Self, programmers coming from more typical languages wouldn't be so shocked by Javascript's schemeish and selfish behavior. If Javascript were more plane about what it was about and how it worked, there would be less confusion. The guy who wrote "Javascript: The Good Parts" said that he had an epiphany where he realized Javascript was just Scheme... he'd have had that epiphany sooner if Javascript wasn't perpetually travelling in Cstyle disguise.
But Javascript is pretty awesome, cause despite all its grossness, the first class functions and dynamic typing and prototype inheritance and object literals and array literals are all so awesome and so powerful that they make up for all the rest. And provided you avoid the nasty parts, you can program in Javascript just like you would Scheme, and you get something awesome and powerful like JQuery as a result. I think John Resig really understands or understood what Javascript was about when he created JQuery; he didn't try and force it to be like other languages and build some guady inheritance heirarchy that's classically fake -- he used lambdas and functional programming techniques to create a really awesome and expressive framework that brings the fun back into DOM manipulation and Ajax and such. I really love JQuery, and I'm starting to really love Javascript as I begin to understand more of how to write good Javascript. Indeed, the most important realization for any Web 2.0 developer to make is that you CAN write good Javascript. It is not impossible. Javascript isn't this terrible bomb waiting to go off. You can get it right, and it can empower your web pages.

Something interesting: Cappuccino is a web framework -- essentially a port of Cocoa to Javascript. What's really awesome about it (one of the things) is that you can use the Interface Builder to create your web guis. Because it's all xib files, they were able to write a converter that takes the xib xml and turns it into an equivalent for their framework. Pretty awesome.

Mac Development

I'm not really doing any Mac development at the moment, though I have considered it. What surprises me about OSX is just that Apple hasn't modernized the development platform very much. They don't, for instance, have a virtual machine like the CLR. Why does Windows have .NET and OSX not have anything?
It seems somewhat stoneage to have the only language for Mac development be the venerable but crusty Objective-C. The standard variety of Objective-C does not have garbage collection, and it has all the unpleasant benefits of unmanaged C. I haven't done much development with Objective-C, so I can't say how often memory leaks arise; I do appreciate their auto-release pools and associated reference counting mechanisms, but I strikes me that in modern times, and for application development, there isn't any good excuse not to have automatic memory management in your application. I know that Objective-C 2.0 or whatever has a garbage collector, but it seems half-ass. And it doesn't work on the iphone apparently; so that screws most the Objective-C market.
I really like the idea of Macruby; the HotCocoa screencasts are very impressive. I'd absolutely love to be able to do Cocoa development without having to resort to Xcode and the interface builder. However, it is not clear how stable or production-ready MacRuby is. Their only at version 0.4 -- not that version numbers mean anything -- but I don't have any confidence that Apple is actually committed to the MacRuby project. I mean... where's their epic plan for future development on the Mac. Is MacRuby it? Is that all they've got? That's good enough I suppose, but it seems like their just diddling around with it: they haven't moved forward from Objective-C ever. No innovation, no development, except within the context of what's already there. I know they replaced Carbon or whatever with Cocoa, but I'm talking about building a real managed runtime like you see with .NET or the JVM. Something that can host multiple languages and provide the kinds of things developers have come to expect from modern platforms: the most important being (and I hate to harp on this, but it's true) -- memory management! There's no greater productivity booster for application development than not having to track down memory leaks all the time. And, like I said, maybe no one complains about that because it's not so much of an issue with Objective-C autorelease pools and strict naming conventions... but I still feel like this is some sort of medievilism on their part. Come on to the future why dontcha?
With respect to garbage collection, MacRuby solves that issue for Mac development. And it presents a nice dynamic (and non-compiled) language to add to the toolset. In the presentation I watched (perhaps I should post the link, but I am lazy), the dude mentioned that MacRuby would be set to become THE scripting language for the Mac platform. That makes sense of course, just because there isn't anything else. All the other scripting languages that run on Mac right now can only interact with Cocoa over a bridge; which sucks a lot. This would be the only instance of a scripting language running natively on the objective c runtime, with all the performance and easy accessiblity that entails.
Anyway... time to go. Bye.

Windows Development

Until last week, I'd never done any Windows development. That's mostly because I think Microsoft is a little gross; and I don't like Windows. But it's also because I've mostly been doing Java or JVM related development, and so I haven't needed to specifically target anything Windowsy. Last week though, I got an assignment that involved coding a Windows service, and accessing a C API on Windows, so I had to learn.
It hasn't been as terrible as I thought it might be; though some parts have been terrible. One thing I hate is that, if you're going to be doing Windows development, you're almost obligated to use Visual Studio; especially if you're doing anything besides Java development. For me, cause I had to interact with some C, I needed access to the Microsoft compiler, and so I had to use Visual Studio. Plus I was exploring .NET, and I think Visual Studio is like the only .NET IDE. I would just as soon use emacs for everything, but then I'd have to use the command line c compiler, which wasn't written for humans. I don't mean GCC, I mean the microsoft c ompiler -- which was never meant to be used from the command line, and is completely unintuitive and alien (from my perspective, having tried to use it.)
On the plus side, installing Python, Perl, and Ruby (the most important scripting languages I can think of) was painless. They all come with msi installers that make everything a breeze. I imagine compiling them from source, which is easy to do on Linux, would be much more painful on Windows -- but, as they say, when in Rome, do as the Romans do, and therefore: when on Windows, do as Windows does -- meaning: use the fricken msi installer.
Because I cannot live without multiple desktops anymore -- osx and linux having addicted me to them -- I cannot live without an Ubuntu VM on my Windows partition. Since Windows doesn't offer multiple desktops, at least not on Windows XP, I've ended up using my Ubuntu VM for a lot of my development work, and just using Windows to compile and deploy stuff. I hop into the vm to do my work, I hop out to run the tests. Also, what irks me about XP (and I don't know if this will be an issue with Windows 7), is that you cannot create custom keybindings without making esoteric changes to the Registry. The evil and mysterious registry, that strikes terror into the mind of every sane developer, or even every sane IT person. In Ubuntu, or any Linux distro, it's as simple as editing xmodmap, or whatever the equivalent keybindings config file. But in Windows, nooooo. Not that simple. You have to do some black magic and possibly corrupt your whole machine. Vomit.
I think .NET is cool. The only thing I wish is that it wasn't tied to Windows. I know there's Mono, but Mono's implementation is kind-of sketchy. If Microsoft wasn't so self-possessed (and perhaps didn't own so much of the desktop market share) they'd make a proper port to Linux and to OSX, like Sun does for Java; though the Apple guys have taken the OSX Java port into the own hands recently and screwed everything up. Anyway, it'd be nice if I could use .NET, and especially nice if I could use .NET languages, just not on Windows. I'd like to program F# from the comfort of my own Ubuntu, in emacs, with a nice Linux runtime. Unfortunately, the dark gods of Microsoft software imperialism say no.
In conclusion, Windows development hasn't been the awful experience I thought it might be. It's been new and interesting. I've even experimented with the satanic Visual Basic .NET -- though just enough to learn the wretched syntax so I could follow examples. And for the record, I think C# has way too much syntactic sugar for its own good. It makes me lightheaded just looking at it. Finally, ctypes for Python is totally awesome. And that's all I have to say about that.

Clojurey

Clojure went 1.0! w00t. And in the meantime, my blog languishes for lack of attention. What kind of blogger am I? to Leave it lying here for so long. Soaking in its own silly juices.But I'm back, for a moment. I must consolidate my web presence; fortify it; make it strong again. But it was never strong to start; yet it will be again! Imagine if James Joyce wrote a blog -- it wouldn't make any sense at all. It shocks me, no... flabergasts me, that one can get anything done in Clojure, cause afterall, it is a "functional" language; and aren't functional languages all universally useless? Don't functional languages just burn up cpu? It must be as the Great Maestro Hickey states: that Clojure is the most friendly face ever put to a functional language. Clojure is easier than Haskell because it doesn't have Monads. There was a guy... Ted Neward (I think) who said that the only way a functional language can ever take off outside academia is if it doesn't have monads. F# doesn't have monads, and look how well it is doing. And neither does Clojure, so it's sure to be a success. Instead of Monads, Clojure has mutable reference types; in that sense, it deviates from being a pure functional language. However, the semantics for mutating said reference types are strictly defined by the language -- it's not anarchy, not like Java. Clojure is much safer. The only way you can get yourself into trouble is my calling out to Java; if only Clojure had an effects system: then I would label all my Java code impure and be done with it. That'd be tricky though, being that Clojure is dynamic and everything. I've written several thousand lines of Clojure in the past few months, and its so dynamic: it could change any minute. In fact, as anyone who has ever worked with me will tell you, it does change every minute. and every half a minute. and not just little bits change. no, the whole thing changes. constant mutation! Most of it I've written over and over again in sundry different ways, since it took me a while to figure out what I was doing. But it's always that way with strange new languages. Some people are lulled into thinking that one programming language is much like another -- but it isn't so. C and Java and C++ and all those other gross static imperative languages may all seem pretty much the same, but beyond their provincial pale is a whole galaxy of strange and unnatural languigy artifice. I recall that Shakespeare line about living in a nutshell and thinking yourself king of infinite space. That's how people get. I'm probably that way. Clojure isn't nearly as hardcore as Haskell; I know, I've tried to write Haskell: and I've failed. You'll fail too! and if you don't fail... well.... then shame on you for being so smart. Remember, it wasn't me, it was Ted Neward who said: No Monads!

Language Libraries

Libraries are a part of language's expressiveness. A language can be compressible and foldable, but if it doesn't have the right libraries, you'll write more code than you have to. Therefore, when you select a language for a project, emphasize libraries.

I don't think Python is a particularly expressive language. It has crappy broken lambdas, no syntax for arbitrary anonymous functions, no currying, no encapsulation, no overloading, no macros, and no regular expression syntax and lame string interpolation. As a scripting language I think Ruby is a whole lot better, and as an application language I think Scala trumps them both. But I'm using Python right because it has the libraries I need. Library beats language feature.
For large do-it-yourself projects it's the opposite: language beats library, because if you're going to be writing your own libraries, you don't want to pay a large language tax while you're doing it. Steve Yegge has talked about the enormous 1/2 Million line game he wrote, and he wishes he'd chosen a more expressive language than Java -- code size becomes a maintenance hazard; the less code you have the happier you'll be, and that is the foremost reason for picking an expressive language in large projects such as his: to avoid paying the language tax and to avoid producing a monstrously large code-base. Languages that support lots of higher order features like Scala or Ruby let you compress your code and factor out syntactic patterns (like for-each) which are intractable in languages with out higher order functions. In such languages, the control structures that come with the language are all that you're going to get, whereas in Scala or Ruby there's syntax for writing your own 'foreach', or you own 'do_times', or your own 'synchronized' etcetera.
Most of the projects I've worked on have not been more than a few thousand lines, ever; and that is because I've made extensive use of libraries and avoided writing thing myself. On that basis I will choose an anemic language like Python or (god forbid) Java if that's what it takes to get things done. Thankfully, I rarely have to choose Java anymore because there are so many other better languages on the JVM which can seamlessly interop with old Java code; but as in the case of Python, I still have to occasionally make the hard choice between a richer platform, or a richer language. And I choose a richer platform almost all of time: with the one exception of (as I said) large do-it-yourself projects for which you do not want to have to pay the language tax.

Streams

So, to lead into this: Scala, despite being a quasi-functional language, doesn't have much laziness support. There is a lazy keyword, and you can have lazy arguments, but by default everything is eager including 99% of the collection functions. Why is this a problem? Because I've changed my mind and decided that instead of returning the first answer to my question, I want all possible answers; except I don't want to pay the price of computing all possible answers until I actually need them, ergo I want a lazy collection. But in order to get my lazy collection, I have to convert my entire API over to Streams, which is the one token lazy sequence in the entire Scala standard library. And it's a hassle!
Clojure, on the other hand, has almost everything set to lazy. Many was the time that I thought: "Hmmm... this would be so much more convenient if I were using Clojure." For whatever reason, I did not listen to myself.
But it's not too late. Perhaps I will make a hybrid project of Scala and Clojure. I'm not sure how difficult that would be, or even if it is possible at all. Maybe it'll be too ugly. Alternatively I could just convert entirely over to Clojure... but that seems like wasted effort; I don't want to keep reimplementing projects in different languages -- throws away too much work. Lastly I could just bite the bullet and use Scala's damn nasty Stream crap, and live with a duplicated API for streams and not-streams.
Something to ponder.