30 October 2008

When the iPhone SDK came out early this year, I was one of the first to sign up for the beta program. I was excited by the possibility to develop on the platform and quickly started reading through the documentation and watching developer videos as I began development of what was to be my first iPhone app. Unfortunately, Apple put one too many roadblocks in place, making the iPhone an undesirable platform for me to work on:

Apple prevented all discussion of iPhone APIs by developers. I tried to ask a simple API question on an Apple developer board, and although a nice explanation why no one could answer me was sent to the board (see the mailing list archive), I actually received obscene emails attacking me for having the audacity to break the SDK's non-disclosure agreement. The draconian NDA clause was removed a few weeks ago, but even then was long after the beta period was over.

Apple charged a fee just to get the developer kit working on an actual device, but then never gave many developers, including me, the unlocking codes to do so until long after the beta period ended.

Apple is still playing games with developers by occasionally pulling legitimate applications off the App Store.

In the end, I gave up and decided to work on Google's Android instead. First of all, Google got Android right by making the tools free and the restrictions few. Another nice benefit was the rich tools available to Android developers due to the Android SDK's use of Java (which has the added bonus of letting me use Scala for Android development!). So far, developing for the Android has been great-- straight-forward APIs, good tools, good documentation. Maybe someone got mobile OS development right.

20 October 2008

Being a fairly new convert to agile development methods, including test driven development, I knew the first thing I would want to get up and running with Scala was a unit testing framework. The NetBeans plugin has built-in JUnit support which served me very well. But I also wanted to get some unit testing working with the Eclipse plugin. It took me a while to get JUnit testing setup with Eclipse, mainly due to my lack of experience in the Java ecosystem. To help future explorers down this path, here are a few lessons I learned.

17 October 2008

I promised some technical notes on the Bay Area Scala Enthusiasts meetup earlier this week, so here we go.

Coding Guidelines

As I mentioned previously, the presentation by the Twitter folks focused on the informal guidelines they have been using internally for Scala coding (PDF of their presentation). I like their guidelines generally. Something that may be controversial in the guidelines is their policy not to use implicits. DSLs especially can make good use of implicits, so I would imagine that would have to be the exception to their rule. Maybe someone should take their coding guidelines as a starting point to make a coding guidelines page on the Scala Wiki?

Structural Types

One of the topics mentioned at the meetup was structural types, which I hadn't used before, so I checked them out. Structural types seem to be a way to accomplish the same sort of "duck"-typing that you can do in Ruby and Python. Let's say you don't care about what the inheritance hierarchy of a parameter is, just that it can perform some operation. There are at least two ways to do this: traits or structural types.

The Twitter guys pointed out that it might be a good idea to avoid structural types due to their use of reflection, which may be slow.

Dependency Injection

How to use dependency injection (DI) with Scala was brought up. There was some argument on how applicable DI was in Scala, with developers coming from a Java background supporting it and those with a Ruby background questioning its relevance to Scala. Either way, this in depth article by Jonas Bonér was brought up.

Development Environment

There was a short discussion on what ide/editor people were using for Scala. The Twitter guys were using TextMate or Emacs, and a few people in the audience mentioned Eclipse and NetBeans. I am really curious what luck developers have had with the different environments. I am using NetBeans right now, but I am not completely happy with it. Can anyone make any recommendations?

15 October 2008

Tonight I attended a meeting of the Bay Area Scala Enthusiasts, a user group focused on the Scala programming language. The meeting was held at Twitter's office in San Francisco, only a few blocks from my company's office, so it couldn't have been more convenient for me. I expected to encounter around 5-10 people there, but I was surprised when around 30 had gathered. The Scala community is definitely growing!

Alex, Steve, and Robey from Twitter hosted the meeting, and explained how they are using Scala at Twitter. They are using it both in middleware and in front-end code and seem to be committed to expanding its use in Twitter-- good things for Scala and Twitter both. Their main presentation focused on establishing a set of coding conventions for the Scala community, which I think could be a really good help for new programmers to have some structure. Robey showed us some of his open source code up on github, including configgy, which I plan to take a serious look at soon.

Some other interesting discussions at the meeting included preferred development environments and strategies to deal with the paradox of being paralyzed by having multiple ways to accomplish the same thing in Scala, usually at least a functional and an object-oriented way of doing things. The concensus seemed to be that each group will ultimately end up with their own style or Scala programming, somewhere between the extremes of writing Java in Scala or Haskell in Scala.

We also learned that there are no less than three Scala books in the works:

Programming in Scala by Odersky, Spoon, and Bill Venners (who was also present and shared some good stories about his experiences in the language as well as the origin of the "/:" operator)

10 October 2008

In my professional programming career, I have been a mostly object-oriented programmer, programming in C#, Java, Python, and C++. Throughout this time, though, I researched functional programming languages from Scheme to Haskell. While I was frequently fascinated by them and they definitely stretched my mind, I never found them to be as practically usable as the relatively new language Scala.

Scala describes itself as a fusion of object-oriented and functional programming languages, and while that is true, it certainly does not give the language justice. Scala has let me leverage my familiarity with object-oriented languages like C# and Java, but add in functional elements as I go along. This has been great for me since I am most comfortable developing real-world applications in an object-oriented style, as I suspect most professional developers are these days. After I have the basics of my program done in an object-oriented style, I can start adding in more functional features. I have never found a language that makes this easier.

To me, the biggest stumbling block for programmers new to Scala is that most of the official documentation describes Scala's functional features very well, but lacks in depth discussions on how to transition to Scala from an object-oriented background. My advice if you are new to Scala and you're an object-oriented developer, learn how to program Scala in a object-oriented way first, then add in functional stuff.

Finally, I have tried two IDE plugins that offer Scala support: one for Eclipse and one for NetBeans. Of the two, I find NetBeans to be more stable, faster, and better able to deal with Scala syntax than Eclipse. There are definitely still some bugs for them to solve, but I'll be sticking with the NetBeans plugin for my Scala development in the near term.

03 October 2008

I am studying the functional/object-oriented language Scala right now and I thought I'd share a few observations about this language and the community around it:

Last night I was having some issues getting Eclipse's Scala plugin to work correctly. Frustrated, I went on Scala's IRC chat room and made an off-hand comment on my problems. The maintainer of the plugin just happened to be in the room at the time, and pointed out my problem, quickly setting me on the right path. My first "technical support" question solved!