David Bolton Strikes Again

I was asked yesterday for advice on the best language between Objective C and Ruby to learn for someone new to programming, who is hoping to be employed working with that language in the near future (an important point).  Here’s my response:

These are two ‘hot’ areas generating a lot of buzz here and abroad.

For the Australian market, I’d recommend Ruby because its best use case is developing websites in Ruby on Rails and there is plenty of demand for websites at all levels, from small sites to large.  Plus working with the web will teach a set of skills that is transferable to other programming languages — such as using HTTP correctly and the ubiquitous HTML.  Ruby is syntactically reasonably simple, and makes a great language for learning the princuples of programming.

Objective C on the other hand has two main use cases currently: desktop software and iPhone applications.  Experienced developers can make serious money in these areas, but it is far more random, and not an area where you can build a career, particularly in Australia where the demand is minimal.  Objective C is could be interesting as a second or third language, but I’d advise against starting with it.

A couple of posts ago, I mentioned my concern that Merb could add too much flexibility to the Rails world, and that the abundance of options would increase the barriers to entry for new Rails programmers.  Having watched the Rails/Merb 3.0 commits so far, it seems that the aim right now is to fix things rather than add things, a good approach since it should be transparent for new and old Rails developers alike.

Anyway, Josh Susser thinks that we may be facing the issue of too many options and too much to learn already, and he could be right.

I have enough experience that I don’t have to spend much time pondering. But for someone new to Rails this all must seem pretty intimidating.

While I was thinking of framework options, the fact of the matter is that there are already a multitude of options for approaching almost any aspect of a web app in the Rails world now.  Java hit this state many years ago — Bruce Tate, a leading light in the Java world who moved to Ruby on Rails, had this to say:

Even if you do choose a popular stack such as Spring, your developers must learn potentially dozens of libraries that are specific to a given project. In this case, Java’s core strength, a plethora of libraries, works against it. In contrast, most Ruby developers know Rails.

It’s this last sentence that is under threat.  In a year or two, Rails development may be just as fractured as Java.

Now options are not a bad thing per se, but many options that are essentially the same add nothing to the game.  I’m thinking in particular here of testing, mocking, and fixture replacement solutions, of which there are bucketloads in Ruby right now.  As a group we’d probably be better off just letting one of them win and moving on with our lives.  For instance, it seems that by-and-large we will all be settling on Passenger as the main deployment platform for the time-being.  This is a good thing, and lets us speak in a common deployment language, and allows us to worry about other parts of the tricky business of web development.

Working with common options doesn’t stop new approaches and frameworks from emerging, but they will need to prove to be sufficiently better to make it worthwhile to move, which is a good thing.

All this is to say: it will be very interesting to follow the progress of the Ruby and Rails communities over the next couple of years.  With no dominant vendor (such as Sun with Java), organic growth is driven by community needs, but it would be good to see the philosophy of “convention over configuration” rule in most cases.

Like many programmers, I’ve been using JavaScript for years, without really understanding everything about it. Recently I’ve been working on a project which is exclusively JavaScript, which is to say exclusively browser DOM manipulation via JavaScript, so I’ve been doing as much learning as possible.

First, the thing most worth knowing is that browser DOM APIs are NOT synonymous with JavaScript.  As Douglas Crockford says: “The API of the browser, the Document Object Model is quite awful, and JavaScript is unfairly blamed”.  Once JavaScript the language is separated with the way it interacts with the browser, one can be a little more objective about the language itself.  To that end, the highest recommendation I can give is to Crockford’s “JavaScript: The Good Parts” book.  It is an excellent exposition on the most useful and reliable subset of JavaScript.  Crockford explains that there are many average and poor parts of JavaScript, but that used properly and in a restricted way, it is a versatile and practical language.

Other excellent resources for understanding the JavaScript way of doing things are, particularly in the context of the browser:

• A detailed talk on why the DOM causes so many headaches by the founder of the jQuery project, John Resig: The DOM is a Mess
• Douglas Crockford’s “Theory of the DOM” talk – parts 1, 2, 3

As Crockford mentions in his book,  most JavaScript references are not so useful, because they don’t differentiate between the bad parts and the good parts of the language, instead leaving them for you to figure out.  Nevertheless, it is probably worthwhile having a JavaScript reference, and O’Reilly’s guide by David Flanagan is probably a good start.  I’ve also got good mileage from Accelerated DOM Scripting with Ajax, APIs, and Libraries, which covers modern JavaScript in the browser reasonably well.

JavaScript can be quite neat, though it wouldn’t be a first choice for me unless it was necessary (essentially, if I was working on the client side, in a web browser).  I certainly wouldn’t use it server side for anything, though there’s plenty of effort in that area.

Another area gaining steam is Test-Driven-Development of JavaScript.  I’ve been using JsUnitTest, but there are a number of libraries out there, each with quirks of syntax and implementation.  JsUnitTest works well for me for the moment.