The IntelliJ IDEA Bomb

In case you missed the announcement from JetBrains yesterday, the popular IntelliJ IDEA has gone free and open source. Sort of. There is now a community edition, that is FOSS, and an enterprise edition that you must pay for. Why is this a big deal? Read on.

IntelliJ really revolutionized Java development. It wasn't the first IDE to allow for code completion, or even the first Java IDE to do this. However, it was definitely a pioneer in code refactoring. And this was huge. It took many of the code improvement ideas catalogued by Martin Fowler, and turned them into simple commands that any programmer could use. This also allowed for things like code navigation, where you could go from the usage of a class or a method to the implementation (or at least the declaration, if the usage only referred to the interface.) This was only the beginning. IntelliJ was a pioneer of bringing in the Java ecosystem. I remember how much easier IntelliJ made it to use Struts, for example.

This reminds me of my own personal use of IntelliJ over the years. When I first started working in enterprise Java development, I was working for a startup that built EJB applications targeted for WebLogic and WebSphere. For WebSphere, we used Visual Age for Java. For WebLogic, we just used Kawa (a bare bones editor.) I hated Visual Age with a passion. It scarred me badly. For years afterwards, I stuck to simple text editors.

Several year later (2003), I joined a fresh startup, KeepMedia (later renamed to MyWire). Prior to KeepMedia, I had a short stint with a .NET startup, Iteration Software (later renamed to Istante, and sold to Oracle.) There I used Visual Studio quite a bit, and appreciated the productivity gains it provided. So at KeepMedia, I took a look at various Java IDEs: JBuilder, JDeveloper, and IntelliJ. I was one of three programmers at KeepMedia, and one of my colleagues was really in love with Struts. He worked on the front of KeepMedia, but I worked mostly on our back end system that integrated magazine content from publishers. I didn't have to use Struts for that obviously, but I did occasionally help with the front end (we had three programmers after all.) I hated Struts, but IntelliJ made it more tolerable. The only negative about it was that it was flaky on Linux, but pretty much everything was flaky on Linux back then.

After I worked at KeepMedia, I worked at a consulting company, LavaStorm Engineering (2004). I had been using IntelliJ for a long time, and was convinced that everything else was crap. One of my colleagues introduced me to Eclipse. I was horrified. Most of Eclipse's codebase came from an all-Java rewrite of Visual Age (the version I had used was written in Smalltalk.) So even though it shared no code with the beast that I had hated, it shared a lot of the look-and-feel. For example, take a look at the outline view in Eclipse (any version, even the most recent.) This was completely taken from Visual Age. Even the icons are exactly the same. There was no way I was going to give up my IntelliJ for that thing...

A couple of years later, I was at another startup, Sharefare (which later changed its name to Ludi Labs.) Being a startup, there was no standardization arounds tools. However, everyone used Eclipse. I had warmed up to Eclipse (though I still preferred IntelliJ), and I had started writing Eclipse related articles for IBM. So I went with Eclipse there, as there were advantages to everyone using the same IDE (being able to share .project/.classpath, plugins, etc.)

After Ludi Labs went down in early 2007, I joined eBay. To say we're a major Eclipse shop, would be putting it mildly...

Eclipse @eBay 2009

View more presentations from michael.galpin.

We're not the only major Java shop that has invested heavily in Eclipse plugins. If you're doing GWT, App Engine, or Android development, then you're probably using Eclipse too. I know I am. I didn't really start using IntelliJ again, until the past year. The reason was simple: Scala. It is the best IDE for doing Scala development currently. Actually IntelliJ's Scala offering vs. the competition, is similar to anything else. It's not that it necessarily has a lot more features, but it has similar and most importantly, it is of higher quality. Here's a great visualization of this key difference:

This is why the open sourcing of IntelliJ is important. It's not that we didn't already have great open source IDEs for Java. No, it's more about what does this mean for IntelliJ. Will the attention to detail go down hill? Will the stable plugin ecosystem be disrupted?

Of course, for most current and would-be users of IntelliJ, the availability of a free IntelliJ is really not big news. The free version is really quite limited. You're not going to build web apps, or apps that connect to databases, use web services, etc. Not with the community version, unless in-the-wild plugins became available that enable this. IntelliJ has awesome support for all of these things, but those parts of IntelliJ remain behind a price wall.

There is one notable exception here: Scala. Right now, IntelliJ has the best Scala support. It has more features and less bugs than NetBeans, and it is much more stable than Eclipse. Scala support is one of the features supported in the community edition. That means a lot of newbie Scala developers can just use IntelliJ. This is great news. I would not give NetBeans or Eclipse to Scala newbies, for the simple reason that both of them report syntax errors inconsistently. In other words, both are guilty of either not identifying an error, or identifying a false error (or both.) That's anathema for somebody learning a language. I'm able to put up with it, simply because I know just enough Scala to say "you're wrong IDE" at times. I've rarely seen this happen with IntelliJ.

A Tipping Point for Scala

This past week's BASE meeting was all about IDE support for Scala. You can read my notes, posted to the Scala tools mailing list. I was very surprised by this meeting. Not by the findings, if you will, as I have used all three IDEs at various times in the last few months. What I was surprised by was the feedback from the group, and the logical conclusion of this discussion: Scala is near a tipping point, but IDE support is holding it back.

First off, there was a large turnout for the BASE meeting. I would say it was the second largest BASE meeting, only bested by the June meeting where Martin Odersky spoke. It is funny, because I think our esteemed organizer, Dick Wall, had been intending this topic to be like "well if we have nothing else to talk about it, we'll talk about IDEs." If there had been an alternative topic brought up, I don't think people would have objected. After all, developers and their attitude towards IDEs are contradictory. Most developers I know would tell you that IDE support for a language is very important, but they would also act indifferent about IDEs when it came to them personally. It's like "all of those other developers really need IDEs, but I would be ok without them." We all know our APIs so well, that we don't need code completion, right? And we don't write bugs, so a debugger is of limited use, right? However, I am sure that if the meeting had not been about IDEs, then there would have been less people in attendance.

So why so much interest? Like it or not, but Scala's primary audience right now are Java developers. Yes, I know Scala appeals to some dynamic language folks, and to some functional programming folks, and that its .NET implementation is being updated, but you could sum up all of the Scala developers from those disciplines and it would be dwarfed by the Java contingency. Scala has a lot of appeal on its own merits, but it is always going to be framed against Java. Scala's most (only?) likely path to mass appeal is as "the long term replacement for java."

So when you talk about developers choosing to use Scala, you are really talking about Java developers choosing to use Scala instead of Java. This is not the only use case, but not only is it the most common use case, it is arguably the only use case that matters. Without this use case, Scala will at most be a marginal language, a la Haskell, or OCaml, or Groovy for that matter.

Back to my point... Java developers need great IDEs. This is not because they "need" help from their IDE because of some lack of skill. No, it's because they have had great IDEs for a long time now, and thus it has become a requirement. I remember when I joined Ludi Labs (it was still called Sharefare at the time) several years ago, we had a Java programming quiz. Candidates were given a clean install of Eclipse to use for writing their programs. We could have given them Vi or Emacs and a command line, but that would have been asinine and foolish. IDEs are an integral part of Java development.

I knew all of the above before the BASE meeting, but what I did not know was how many development organizations were at a critical juncture when it comes to Scala. For many folks, Scala, the language, has won the arguments. Whatever perceived extra complexity that it has, has been judged as worth it. Whatever challenges there may be in hiring people to develop in Scala can be mitigated. Legacy code is not even a factor, as integration with existing Java code is trivial. Maybe it's bleak future of Java, or maybe it's the high profile use of Scala at Twitter. Who knows, but Scala is poised to take a big piece of the Java pie.

Thus the missing piece is IDE support. Development orgs can't switch to Scala without IDE support, and the support is not there yet. That's the bad news. The good news is that Scala is ready to explode once the IDE support is there. There are a lot of folks out there ready to adopt Scala simply as a "better Java." They just need an IDE that is on par with Java IDEs. That is the standard.

All of that being said, there is a lot of concern around the IDEs. Many people expressed to me that they are worried that IDE progress is being coupled to the release of Scala 2.8. That seems reasonable at first, but what happens if 2.8 is not released until 2010 sometime? Will Scala lose its momentum and window of opportunity?

The Java App Engine

One of the worst kept secrets in the tech world was revealed on Wednesday night when Google announced Java support on the Google App Engine. Everyone knew this was coming, but it was still very exciting news. Last night I went to a Google Technology User Group meeting where folks from Google went into more detail on GAE/J as some folks are calling it. Here are a few of my thoughts:

1.) First of all, kudos to Google for supporting a lot of the standards in Java. They did the same thing with Python on GAE, but there are a lot more standards to deal with in Java and those standards tend to be harder to implement.

2.) Also major props to Google for working so well with partners. They had big partners like IBM, but also smaller ones like ThoughtWorks. The ecosphere around GAE/J is off to a great start. Of course reaching out to partners is probably a big reason for the lack of secrecy about GAE/J, but it is certainly worth it.

3.) The Eclipse tooling is outstanding. I know some folks were a little dismayed that they would have to use Eclipse instead of IntelliJ or NetBeans, but what can you do? Eclipse is king, and the developer experience with the Google tools is second to none.

4.) Speaking of standards, support for JPA is great. So you can't do joins or aggregates, but did you really think you could or should be able to do that on GAE? After all, you have a non-relational store (BigTable) behind all of this.

5.) On the other hand, support for JDO is ... surprising and a little puzzling to say the least. Heck, I thought Gavin King put a wooden stake through the heart of that would-be standard a long time ago. At least you can eschew it in favor of a standard that people actually use (JPA.)

6.) No threading is not entirely suprising, but it lights the way to a bigger issue. The GAE road map has talked about task queues/background processing for awhile now. Google announced cron jobs this week as well, but those are limited to 30 seconds of execution time, only 10/day, and are schedule at a specific time. Here is another Java standard for you: JMS. I think GAE/J needs this, as well as some kind of thread pool (or substitute) for processing. BigTable (as a backing store for a queue) and cron tasks are not enough. Heck, even one of the App Engine success story/presenters talked about how they simulated (quite cleverly I might add) batch processing.

Scala Puzzler and IntelliJ

Today I received a serial number for the highly regarded IntelliJ. The license was courtesy of the San Fran JUG, as a thank you for speaking there last month. I used to use IntelliJ many years ago, when I worked in consulting. Back then its refactoring was much more powerful than Eclipse and NetBeans was a joke. I haven't used it too much since then, as I became quite the Eclipse convert. Every once in awhile I will take a look at it. Today I thought I should give it more of a try, since I had this license for it. So during my lunch, I set it up, got its Scala plugin, and solved a Facebook puzzle. Actually I shouldn't say that I solved the puzzle, my solution is a naive, inefficient solution. Anyways, here's the code

import java.io._
import scala.collection.mutable._
import scala.io._

object PeakTraffic {
    def main(args:Array[String]){
        val users = HashSet.empty[User]
        val stream = if (args.length == 1) new FileInputStream(args(0))
            else Thread.currentThread.getContextClassLoader.getResourceAsStream("traffic.txt")
        val src = Source.fromInputStream(stream)
        src.getLines.foreach((str) => {
            val emails = str.split(" ").filter(_.contains("@")).map(_.trim)
            val sendingUser = User(emails(0))
            val receivingUser = User(emails(1))
            users(sendingUser) match {
                case true => sendingUser = users.find(_ == sendingUser).get
                case false => users += sendingUser
            }
            users(receivingUser) match {
                case true => receivingUser = users.find(_ == receivingUser).get
                case false => users += receivingUser
            }
            sendingUser <==> receivingUser
        })
        makeClusters(users).foreach(println(_))
    }

    def makeClusters(users:Collection[User])={
        val clusters = new ArrayBuffer[List[User]]
        users.foreach(_.friends.foreach((friend) =>{
            clusters += friend :: friend.friends.filter(friend.isFriend(_))
        }))
        clusters.filter(_.size >= 3).map(_.sort(_ < _)).toList.removeDuplicates.map(_.mkString(", ")).sort(_ < _)
    }
}
case class User(email:String) extends Ordered[User]{
    private val friendSet = HashSet.empty[User]
    private val sentSet   = HashSet.empty[User]
    private val receivedSet = HashSet.empty[User]

    def compare(that: User) = email compareTo that.email
    override def toString = email
    def friends = friendSet.toList
    def isFriend(friend:User) = friendSet(friend)
    def <==> (user:User) = {
      this >> user
      user << this
    }
    private
    def >>(user:User) = {
        sentSet(user) match {
            case false => {
                receivedSet(user) match {
                    case true => {
                        friendSet += user
                        receivedSet -= user
                    }
                    case false => sentSet += user
                }
            }
        }
    }
    def <<(user:User) = {
        receivedSet(user) match {
            case false => {
                sentSet(user) match {
                    case true => {
                        friendSet += user
                        sentSet -= user
                    }
                    case false => receivedSet += user
                }
            }
        }
    }
}

A couple of things about IntelliJ... Code completion seemed much slower than on NetBeans or Eclipse. Similarly most errors weren't flagged until the code was compiled (maybe it's this way with Java, too?) Debugging was good. Some refactoring is supported. I think IntelliJ is unique in this regard. However, I couldn't rename a method to an operator symbol (>> in this case.) Also, method extraction did not seem to work, which is probably the refactoring technique I use the most when I code. The indentation was also flaky. Like I could create a class, hit return (indented) create a val, hit return (indented even more), etc. I think the lack of semicolons might have been causing it problems, but that's just a guess. Overall, I think the NetBeans plugin is better, but at least my experience wasn't as bad as David's.

EclipseWorld

This week I have been speaking at EclipseWorld in Reston, VA. I have been talking about Ruby on Rails mostly, and a little session on iPhone (web) development. Most of the developer here are Java developers, so they look at Rails as a way to make their jobs easier. It's a grim economy, and they are being given the classic task of doing more with less. They look at Ruby on Rails as a way to do just that. More features. Less code. Happier developers!

EclipseWorld has been a great conference to speak at. What has been very cool for me is interacting with developers outside of Silicon Valley. Now don't get me wrong, if you are a developer, especially a web developer, then Silicon Valley is the place you want to be. I would compare it to working on Wall Street if you are in finance, or working in Hollywood if you are in show business. It's not for everybody, but it presents the chance to prove that you've got what it takes, and, if you are lucky, a chance to make a lot of money.

However, in the Valley it is easy to forget that most web development is not about creating The Next Big Thing. In the Valley, @tychay will rip you up for using Rails because it fails at web scale. On the east coast, I have met a lot of developers creating internal web applications, or maybe customer service applications. These are applications that can run just fine a single multi-core box, even with the database running on the same machine. They aren't stressing out over page weight, database partitioning, or terabytes of cache. They are creating sophisticated applications, and always have way more feature requests than they have time.

These are the people who are most empowered by tools, especially Eclipse. They don't have some huge team with specialists for doing the CSS or tuning the database. They do it all themselves, and Eclipse makes that a whole lot easier. I've written a lot about things you can do with Eclipse, but this experience has really put things into better perspective.

October Talks

October is going to be a busy month for me. Next weekend I will be at Adobe's FlashCamp. I will be there Friday night and Saturday, and I may do a short session on TwitterScript, the ActionScript API that I maintain. In particular I want to talk about some of the authentication wrinkles present in TwitterScript and its forked brothers.

On October 20, I am speaking at AjaxWorld. I am going to be talking about a subject near and dear to me, Networked Applications. I'll be talking about why you shouldn't waste the power of your servers building HTML strings but why you should instead start using things like jQuery, GWT, or Flex to cash in on the power of your user's computers.

The week after that, I will be on the east coast speaking at EclipseWorld. On Day One, I am doing a day long, introductory workshop on Ruby on Rails. Of course I'll also talk about how Eclipse can help you out. On Day Two, I am doing two talks. One ties in to the previous day's workshop and is about RadRails. The other session is on ... iPhone development. Kind of a strange topic for me. Chris Williams from Aptana was supposed to do both sessions, but couldn't make it. So Aptana asked me to fill in for him. Hopefully they won't wind up regretting that decision!

Eclipse Day Video

Couldn't make it to Eclipse Day? You're in luck. Since it was at Google, it was recorded and is now on YouTube. Enjoy!

Eclipse Day 2008

Congratulations to the Eclipse Foundation for releasing Ganymede today. As part of the festivities, Eclipse and Google collaborated on Eclipse Day yesterday. I was fortunate enough to be asked to speak at the event, and it was a great experience. I spoke about how we use Eclipse at eBay. The response was very enthusiastic with lots of folks amazed at how many tools we had built for our developers and how we had standardized tools across such a large development organization. I totally agree that our tools developers are amazing. For me, I don't know how we could survive without having all of the tools we have built! Here are the slides from my presentation, courtesy of SlideShare:

| View | Upload your own

I wanted to really thank Ian Skerrett from Eclipse for organizing everything. The folks at Google were excellent hosts, so I must also thank Robert Konigsberg from Google.

EclipseDay

I will be speaking at EclipseDay next month at Google. I will be talking about how we use Eclipse at eBay. I am going to try to demo and show off eBay's highly customized Eclipse-based development environment. Of course anytime you do a demo, you are at the mercy of the demo-gods! Hopefully they will be merciful.

eBay on developerWorks

I have written a lot of articles for IBM over the last couple of years. Most recently I got a chance to write about "my day job" if you will: eBay. I wrote two articles on how we use Eclipse at eBay to tackle a lot of interesting problems. When I first came up with the idea for the two articles, it seemed really cool but I was a little worried about it being complicated. When you think of a large company (and with 15,000 employees and a $36B market cap, eBay certainly qualifies) you think of all kinds of red tape, armies of lawyers, etc. I was pleasantly surprised to have almost none of that to deal with for these two articles. The articles definitely show some of what's "under the hood" at eBay, but its just enough to explain some of eBay's unique needs and how we have used Eclipse to help with these needs.

Galpin on Rails on IBM

A couple of pieces that I wrote on Rails appeared on IBM at the end of last year. I didn't even realize it until today when somebody emailed me about one of the articles.

The first article is part one of a four part series on using Rails, XForms, and DB2's PUREXML tables together. I also wrote part two, but another writer wrote parts three and four. Only part one is up so far.

The second article is the third tutorial I wrote on using Eclipse as a web development platform. Part one was about using Eclipse for Java web development, and part two was on using it for PHP development. The last tutorial is on using Eclispe (via RadRails) for Rails development. Note, the link for part two shows the intro page to part one. If you login, it correctly gives you part two. Clearly some kind of technical glitch for IBM!

Mac Java 6

There's been a lot of developers upset that Leopard does not include Java 6. Does this make the Mac a poor choice of Java developers? No, it doesn't, not yet at least.

First of all, I fully expect that Apple will release an update to Leopard that will include Java 6 before the end of the year. But it doesn't matter too much because Java 6 was mostly a performance release for Sun. There's some nice things in the Swing implementation included on Hot Spot. Neither one of these things is even relevant for Apple. There are some language features (debugging, StAX parser) but these are pretty minor.

So to me it doesn't matter too much that there is no Java 6 for the Mac. Oh, but there actually is, or was. I personally had some problems with it, so I wasn't too surprised that it's no longer available from Apple.

Things only become problematic if Apple takes a long time to support Java 7 when it comes out, especially if you assume there will be a lot of language changes in Java 7. If that happens, then it could be conceivable that developers won't be able to use OSX. Others have pointed out that a major litmus is Eclipse. If Eclipse will run on OSX, then all is well. Eclipse 3.3 was released just a few months ago and was the first version of Eclipse to require Java 5... Eclipse is obviously important for Java developers, but also for Flex developers and even PHP developers.

Non-Java Article on IBM

I have a new article up on developerWorks: Developing applications using the Eclipse C/C++ Development Toolkit. This is one does not use Java, as should be obvious from the name, though it does use Eclipse. For some reason IBM listed my very old "About the author" info from the first article I wrote for them 1.5 years ago. So it says I work for Vitria still, instead of eBay.

It was a fun article, though I must provide a word of warning on it. CDT relies on g++/make/gdb being "properly" installed on your system. This can be a real pain on Windows, though it is status quo on any kind of Linux or on OSX. From the screenshots, it is obvious I wrote the article on a Mac, and part of why I did that was so that I did not have to deal with make/cygwin configuration on Windows. So before trying CDT out, make sure you have its prereqs working, i.e. at least use make to build something with at least two source files, via the command line. Otherwise you might think there's a problem with CDT, when actually the problem is with make or cygwin.

GWT, Eclipse, and JUnit -- Rants

I love the ideas behind the GWT command line tools. They remind me a lot of Ruby on Rails. They seem to have some surprising shortcomings though. The projectCreator works pretty good for creating an Eclipse project. However, it doesn't include the gwt-dev-.jar (for example gwt-dev-windows.jar) in the classpath of the project. So you can't launch in Hosted Mode because the executable class is in that jar. Thus you can't use the Eclipse debugger either. If you add the jar to your project classpath, it seems a little better. You still need to configure the run profile, similar to how the -shell script does. Seems like these are obvious things that the projectCreator could do.

The junitCreator seems even worse. It needs a GWT module name, but none of the artifacts created by the applicationCreator or projectCreator contain this. The .gwt.xml file has the module of course, but not it's name. It took me some trial and error to get this right. Even when I did, I could only launch my unit tests using the generated command line tools. I could launch these files directly from Eclipse, but I couldn't launch the unit tests using Eclipse. Thus I could not attach Eclipse's debugger.

I'm sure there's a way to do this. I'm sure that either I 1.)didn't use the right junitCreator command option, 2.) need to configure my project differently, or 3.) need to configure my run/debug profiles differently. Whatever this case, this is all very un-Ruby on Rails like.

Oh, one last complaint. The projectCreator has an option for generating an Ant file. That is borderline useless. The build file only builds a JAR and does not include the gwt compiler as part of the build. Guess what, if you're using gwt, you're building web applications. You don't need a JAR you need a WAR, and you need it to include all the web files, i.e. all that gwt-generated JavaScript. You need a web.xml file, which gwt knows how to generate (it creates one when you launch web mode.) WAR files have a very standardized structure, so this should not be very hard. Just package up what gets deployed to the bundled Tomcat in web mode.

Update: Strangely I don't have a lot of these same problems when I run everything on a Mac. No idea why, since even though the command line tools are platform specific and some of the runtime is platform specific, one would think that the underlying Java code that creates the projects, artifacts, etc. is pretty much the same.

Adobe Apollo and Flex

With all of the recent hoopla around Adobe's Apollo, I decided to give it a try. From what I've read, you should be able to develop a web application and Apollo will give it an "offline" mode. So you could just build a typical web application or even an AJAXy one. I figured for the full Adobe effect, maybe I should finally dip my toe into the Flash waters.

So I downloaded a trial version of Adobe Flex Builder, plus the Apollo SDK and extensions for Flex Builder. It turns out that Flex Builder is built on Eclipse. That made me optimistic. Not only do I think Eclipse is a very smart platform to build on top of, but I know Eclipse really well. One would think that my familiarity with Eclipse would help me to be productive with Flex Builder.

A direct consequence of the Eclipse heritage is that there are two installations options for Flex Builder. You can install it "standalone" or as an Eclipse plugin. I have a lot of Eclipse plugins, but I've had some bad experiences with "bigger" plugins in the past. For example, when I was at Vitria, I was using Xml Spy for debugging complex XQuery expressions. I had the professional version of it, and it gave you the option of installing an Xml Spy-Eclipse plugin. I thought "cool, I can do my XQuery debugging inside Eclipse!" That may have been true, but I'll never know because it really hosed my Eclipse installation. I had to wipe it out and rebuild it. Rebuilding an Eclipse installation that involves lots of plugins is a real pain.

So needless to say that when confronted with a commercial application wanting to install itself inside Eclipse, I always decline. So I went with the standalone installation of Flex Builder. It was pretty quick and clean. One thing I noticed was that installed a JRE. Thankfully it only installed it inside its installation directory and it did not mess with any environment variables. I've been burned by Oracle installing its own JRE and then putting it on the path or even redefining $JAVA_HOME...

Still you would think that the Adobe installer would be a little smarter. It would be easy to detect if Java is present on the path. If it is, then don't bother installing a JRE and just use the system's JRE. Also, digging around I quickly found that the JRE they included was the HotSpot 1.4.2. Talk about old! Hopefully they'll skip 1.5 and move straight to 1.6. They may not get much advantage out of 1.5, but the speed improvement on 1.6 (particularly for a long-running process like an IDE) is definitely worth while.

Enough complaining about the installation... Here's what it looks like fresh out of the box on Windows.


Pretty similar to Eclipse. It seems like the big difference is the squarish windows. Of course the options in the menus are a lot different. They are very simplified with just options for creating Flex projects and objects. They did leave in the Software Updates, so you can easily install Eclipse plugins. That is very nice. All in all I am looking forward to building something Flashy.

XCode

I've been doing some development on the Mac lately. The tool that I've been most interested in is Dashcode, but I've also been using the seminal Mac development app, XCode. I thought it would be interesting to compare it to a couple of other multi-purpose IDEs: Visual Studio and Eclipse.

In some ways it's kind of ironic, but probably the thing that jumps out the most in such a comparison is that VS and Eclipse both have a lot more eye candy. They are more visually appealing programs, at least in my opinion. XCode is a little more stripped down, and not just in the eye candy department.

A popular feature in IDEs is code completion, popularized by VS's IntelliSense. I don't know if VS was the first IDE to have this, I just know it made it popular. I actually think Eclipse does this better than VS these days. XCode has this feature, too, but it is turned off by default. There is something appealing about that to me. Code completion can make developers lazy, and some would argue that it decreases your programming skill. It's hard to argue that it doesn't make you more productive, though. XCode should make better use of it and turn it on by default.

XCode is very good for running and debugging. I was impressed that it gave me an error code in a program that didn't clean itself up properly. Of course that error message was very cryptic, and was just a warning. Only after I fixed the problem did I realize that the weird warning was because I had left some garbage on the heap in the program.

All of this made me think, I wonder if there is an Eclipse plugin that's designed to enable Mac development? The answer is no, and for a good reason. Eclipse is a little clunky on the Mac because SWT is implemented in Carbon, not Cocoa. Most of those super-slick Mac apps out there use Cocoa. SWT binds the native UI elements on whatever system it is running on, so it could use Cocoa or Carbon on the Mac. The SWT developers chose Carbon. They had some very good reasons for doing so, but the end result is Eclipse is a little clunky. It's hard to convince somebody who wants to build a slick looking Cocoa app to use Eclipse.

Anyways, XCode holds up pretty good, though it definitely seems like a notch below VS and Eclipse. Let's face it, appealing to developers has never been Apple's strong suit. Dashcode is kind of promising, though widget development is definitely a niche at this point.

Python

I decided to go ahead and do Python versions of the programming assignments. I updated the ATM and Text Manipulation assignments to include Python versions. This is my first programming with Python. It seems pretty clean so far. Obviously it is similar to Ruby. It seems a little more procedural (lots of standard functions like ord(), len(), str()) whereas Ruby tries very hard to be object oriented. I think it is possible to be more OO with Python and more procedural with Ruby, but I'm not good enough at either to do so!

Python includes it's own IDE, IDLE. It seems pretty nice. I'm not sure how well it would work on a large project with many Python scripts/classes. I've been using Eclipse for Java and Ruby, and using Visual Studio for C# and C++. For easy things like these assignments, Eclipse is definitely the biggest pain to use...

Eclipse Tuning

Everybody loves Eclipse, right? It's become ubiquitous, right? It's been my primary IDE for a couple of years now. Lately, I've run across some issues with it though. And when I say issues, I mean crashes.

Eclipse has a relatively easy to find log file (in $project_home/.metadata/.log) and I quickly found the problem:

!MESSAGE Failed to execute runnable (java.lang.OutOfMemoryError: PermGen space)

The dreaded Java out of memory problem. I found a couple of interesting bits on this particular variant of the out of memory problem, i.e. PermGen space. This article points to using the JVM flags for increasing PermGen size, while this one claims that HotSpot has garbage collection problems on long running processes (I have Eclipse open all day usually) but that JRockit does not have these problems.

I have some experience with tuning my JVM, so I decided to tune Eclipse as my first option. To do this, you just have to edit $eclipse_home/eclipse.ini. Here is what mine looks like now:

-vmargs
-Xms256m
-Xmx512m
-Xmn128m
-XX:+UseParallelGC
-XX:MaxPermSize=128m

This seems to work pretty good. I haven't had any crashes since then and Eclipse launches much more quickly. I threw the UseParallelGC in there to take advantage of the extra core on my CPU, but I'm thinking of removing that. Seems like Eclipse is a little less responsive with that option, but that's very subjective.