Archive for February, 2007

Drinking The MacBook Pro and OS X Kool-Aid

Monday, February 26th, 2007

This past Friday marked the end of the second week at my new job which has brought many changes for me. I left a good sized development team at large company for the uncertainty for a VC funded start-up without revenue, I’m miles from a ColdFusion server and instead am working on a Java distributed platform (though I had been working in Java exclusively for about 6 months before changing jobs), and I switched to a MacBook Pro among other changes. All of the changes have been great choices so far, and it was good time to make a big jump just from a personal standpoint as I felt that I was starting to stagnate. I pretty much had the option to use whatever platform worked best for me, and I took a leap of faith and decided to go with a MacBook. I got equipped with a very nice one– I have the 2.33 Ghz Dual Core w/ 2 GB of RAM.

The first day or two I felt like a bull in a China shop on the MacBook. The process for installing software didn’t make any sense to me, I kept using the control key for common shortcuts, and in general I was trying to figure-out how to setup the full software stack I’m now working on without really having a good understanding of the OS I was using on my workstation. I’m sure I’ve looked retarded to my new co-workers for the most part so far, but I feel like making the switch is really starting to pay dividends.

For starters, there is just no comparison between the fit and feel of a MacBook Pro to a Dell laptop. My Dell seems like a total piece of crap now, and it annoys me to have to use it. It’s big, heavy, clumsy, and shodily assembled compared to the MacBook. I look at some of my co-workers Dell laptops and am very glad that I picked the Mac, though some of them have some 12″ Lenovo’s which are pretty sweet.

Since I’m only a couple of weeks in, I hesitate to list all of the various software and so forth that I’ve found useful, but I’ll get around to posting that in a couple of weeks once I feel like that list is more finalized. Instead, I thought it might be useful to post some of the pros and cons I’ve noticed coming from using Windows and Linux:

Pros:

  • Unix with a very nice GUI. That’s really enough to sell someone right there. I’m a command line junkie and it’s nice to have Bash and all of the assorted Unix facilities and software available
  • The hardware is really good– it has great fit and finish. I can even use the MacBook Pro on my lap without getting scalded. There are just so many little things that you notice over time about the MacBook which are ingenious (like the light sensitive keyboard backlighting for instance)
  • Everything just works. Had I attempted to set the same environment up on Windows I would have had to bludgeon myself with Cygwin. I haven’t had to deal with any of the annoying dependency problems that Linux has.
  • I actually like the hardware lock-in. It makes it much easier to find accessories for your given hardware, and you can easily compare specs and application performance with other users, etc. I’m sure this also helps make the OS a lot better as well since they don’t have to support every chipset and piece of hardware under the sun.

Cons:

  • Some of the software seems like it’s dumbed down too much. I understand it’s a design philosophy of the Mac, but with some software I find myself looking for the “Advanced” mode. I’m not sure what you would call the file browsing software, but it was my primary complaint until I found Path Finder
  • The concept of Free Software seems to be beyond a lot of people in the Mac community. Every little add-on that makes software suck less is likely to cost you $12-$15.
  • There aren’t really any Mac specific ergonomic keyboards. I’m currently using an MS Natural keyboard when I dock at work, but I find it hard to get used to shortcuts because I’m still using a keyboard with a Windows layout

All that I can say is that from the perspective of a big Unix fan who does Java development, I feel like the Mac offers a great platform for both software development as well as an everyday workstation OS. I’ll get around to posting a list of software that I’ve found to be useful in a couple of weeks once I feel like I’ve got most of what I need.

Correcting Logical Fallacies: Why Java Is Not Slow

Thursday, February 8th, 2007

Not to directly pick on Peter Bell at all (he’s a very smart guy and I really enjoy his blog, so this is nothing personal at all), I just noticed something he mentioned in a recent comment on a blog entry and felt that it was something I should address in a blog post rather than a comment. Also, writing this entry gives me a good reference point later to send to people when they present the same talking point to me.

Anyhow, here is the comment that Peter made which inspired this blog entry (which in context, is a quip):

I also have to question why you’d even consider using CF for a performance critical app - even Java is a little sluggish. If you want bare metal performance and think your time is worth less than the cost of a server, go for it and write the darn app in C++!

I wanted to point out and correct a common fallacy that I see repeated over and over again are statements rooted in comments like “If you need speed, you could convert your Java application to C or C++”. I don’t claim to be a Java expert by any means, but I do think I have a good enough understanding of the Java platform as well as basic operating systems & compiler theory and the like to explain why this is a false argument. The answer is actually more along the lines of “it depends on what you are doing”, and I’ll explain why.

It’s very easy to see where this misconception started– pretty much every software developer or system administrator has encountered a slow Swing/AWT based Java application which took forever to start, and generally seemed pretty sluggish. Not to mention it probably looked terrible. One of the best Java based desktop applications, Eclipse, even takes awhile to start. On the contrary, C++ desktop applications typically start very quickly, and are very responsive to user input. Generally speaking the symptoms of running a Java desktop application match the reality– C++ is almost always faster for short running programs such as desktop applications.

Another common assumption is that it would seem that the JVM itself is an abstraction above machine level code because it acts as an interpreter, and that C/C++ will always be faster because the resulting compiled code is “closer to the hardware” which is also false. In the early days of Java, the JVM did in fact interpret code, but eventually it started using a Just In Time compiler in Java 1.2 to compile the code down to the machine level. Different implementations of the JVM use various JIT compilers, but the Sun JVM uses the HotSpot JIT. Not only are Java programs compiled down to machine specific code, but the longer a program runs, the better it gets optimized.

The HotSpot compiler monitors and analyzes an applications performance over time, and uses adaptive optimization to eliminate bottlenecks in the machine code, known as “hotspots”. It essentially looks for pieces of code that are ran time and time again, and marks them for optimization. Those pieces of code are then recompiled again into machine specific code for performance. This allows for ongoing performance enhancements that you would never get from machine code produced by a C or C++ compiler such as branch prediction hints.

All of these things are not just unfounded theory, there have been several independent studies about this including this one by the University of Southern California.

Java is now nearly equal to (or faster than) C++ on low-level and numeric benchmarks. This should not be surprising: Java is a compiled language (albeit JIT compiled).

This study is several years old now and doesn’t include testing against the many performance enhancements which were made available in the 1.5 JVM, so I’d be interested in seeing an updated study.

That said, Java is probably much faster than you think. One way I’ve seen the Hotspot compiler in action (and you can try at home) is when working on a simple “Hello World” JSP and keeping track of it’s execution time. Typically on the initial run or two, the JSP page is pretty quick, but then after a few calls of the page the Hotspot compiler kicks in and makes it wicked fast so that it’s execution time is effectively nil.

Now that we’ve spoke to the “Java Is Slow” audience, we should cover the answer to the earlier question of “Is Java slower than C/C++?”. This is more of an “it depends” answer. Generally speaking C++ has the advantage in short running applications, and Java is as fast if not faster than C/C++ in long running applications such as servers, web applications, etc. It also might surprise you to know that Java is also very good in real time systems, but that is another blog post of its own.

Open Source ColdFusion: Smith Project To Be Released As Open Source

Monday, February 5th, 2007

While doing my normal nightly browsing, I saw an “Open Source ColdFusion Server” digg which mentioned that the Smith Project, a free and lightweight CFML implementation, is going to be Open Sourced. This is great news for the community, and I’m definitely anticipating it’s release as an open source project.

Before I came across Smith a few months ago or so, I’d been long thinking about writing a Java based parser generator with support for a very limited subset of CFML type tags just to have a light markup language that could seamlessly call Java objects and services without the pain of JSP or overhead and cost of a full-featured CFML implementation. I think this will certainly fit that need for me once it’s open sourced, and will save me a lot of time from having to implement it myself. :)

On a related note, this is the first ColdFusion related digg I’ve seen that hasn’t turned into a “PHP/RoR PWNS COLDFUZION U N00B LOLZ” type discussion. Knock on wood.