Developer paths beyond the Visual Studio juggernaut
I have just purchased a Mac laptop and am planning to partition it to run OSX and Ubuntu. Currently I use Microsoft Visual Studio on Windows for development projects. My concern is whether there is an equivalent to Visual Studio and the Microsoft Developer Network (MSDN) on OS X or Ubuntu?
Today I was asked this question, one which is very similar to others I have been asked and answered in the past. In Windows the decisions a developer must make prior to starting coding are relatively simple because it is an environment dominated by Visual Studio. When making the move to OSX or Linux the decisions facing the developer are more complicated because no single company dominates these platforms in the same way Microsoft does Windows.
Outside of this Microsoft’s sphere of influence is a large number of avenues to consider which can significantly influence the productivity and even success, of your software project. The short answer is there no direct equivalent to Visual Studio and MSDN for OSX or Ubuntu, but there are plenty of satisfactory alternatives. In making your decision consider what languages you use now, or are interested in learning in the future. Also identify what general platform you wish to develop for; be it the desktop, server, web or mobile. And always remember whilst none of these discussed paths are wrong, some are more right than others depending on the project.
Mono - The Cross-Platform Windows .Net Framework
For a developer used to Microsoft’s .Net framework and C# or Visual Basic, the easiest place to start is Mono. Mono is an open source implementation of the .Net Common Language Runtime (CLR) which can run on OSX and Linux. With Mono you program using the C# and Visual Basic syntax you are used to, but the compiled binary executes on OSX and Linux.
Unfortunately because the Mono team is a re-implementing an existing framework they are always one step behind what is available on Windows. For example the current 2.2 release supports the language features of version 2.0 of the .Net framework. Consequently you cannot take advantage of the new features in the .Net 3.0 until version 3.0 of Mono is released, which may take a while to materialise. Another thing to keep in mind is that many of the supporting libraries found in Windows .Net maybe different or unavailable in Mono. This is largely due to Mono's cross-platform nature and the fact .Net leverages many Windows-only libraries that will never be ported to other platforms.
Whilst the Mono runtime is very mature and compares well to its Windows equivalent, the development environment and community is not nearly as strong. Compared to Microsoft's Visual Studio the Mono Develop Integrated Development Environment (IDE) is significantly behind in terms of functionality and polish. In time this situation will improve, but for the foreseeable future those making the jump from Visual Studio to Mono Develop will be very disappointed. This is not to say that development in Mono Develop is impossible, it is just that nearly all of Visual Studio's handholding and helper tools are not yet present.
In terms of an online developer community, Mono's is small compared to alternative open source languages such as Java, Ruby, Python and PHP. However Mono developers can benefit from its .Net lineage by leveraging the wealth of MSDN documentation available for C#, Visual Basic and Windows Forms. When doing so it is important to keep in mind the practical differences between Mono and .Net, as whilst the syntax is generally the same, the tools and supporting libraries used may differ substantially.
Java - A Mature Cross-Platform Environment
When talking cross-platform development Java is the ten-thousand pound gorilla in the room. Whilst technically not the first cross-platform programming environment, Sun’s marketing department popularised the concept of "write once, run anywhere" during the 1990s. This was later referred to as “write once, debug everywhere” by Java’s detractors. Like C# and the .Net CLR, Java is both a language and a runtime environment, in fact Microsoft “borrowed” many of Java concepts when developing .Net. The major benefit of Java is that the environment and community around it is very large and mature. Unfortunately this is a double edged sword; on one hand this means there is a wealth of tools and support available, but on the other the options are so varied and complicated the learning curve can be extreme at times.
Like .Net, Java is an excellent environment to learn if you are unsure of what platform, be it desktop, web or mobile, you wish to write applications for. Whilst each platform has its own mannerisms and libraries to learn, many of the underlying concepts and tools can be universally applied. Again this has its own benefits and drawbacks. From a career perspective Java is ubiquitous and no matter what the problem space or context, it can almost certainly be put to use. Unfortunately this diversity has lead to a lot of coding inefficiencies when compared to a language dedicated to a certain problem space or context. The most prominent case of this in recent times has been the meteoric rise in popularity of Ruby on Rails amongst Java developers.
When it comes to Java development tools there are plenty of good ones to choose from, for example Eclipse, NetBeans and IntelliJ. All three compare very favorably to Visual Studio in terms of features and developer community support. Personally I use NetBeans as it has a very good 'out of the box' experience and has excellent support for Java web development and languages such as Ruby and PHP. Eclipse is the most widely used Java IDE and has a vast number of third-party extensions that add a huge amount of functionality. However Eclipse's depth can be problematic as its default installation is minimal and its extensibility often poses more questions than it answers. As a result setting up your ideal development environment can take some time. IntelliJ, unlike Eclipse and Netbeans, is not open source and requires the purchase of a software license. This initial cost is outweighed in a commercial environment by its teamwork functionality and support provided. However in a single developer environment justifying this purchase when both Eclipse and NetBeans are free and so powerful is in my view much more difficult.
Other Languages on the Java VM
In a similar way to .Net and Mono, the difference between the Java version of a language and its native equivalent (e.g. JRuby <=> Ruby) is its ability to leverage supporting libraries. Generally the majority of the language syntax is the same, but whilst Ruby can leverage a system’s C libraries, JRuby has access to those within the Java VM. In these cases this can lead to significant coding differences, but if you write an application using only core Ruby libraries there is a very strong chance it will run unmodified on both the Ruby and JRuby runtime environments.
Objective-C, Cocoa and Carbon
Writing cross-platform is a nice idea, but there are considerable benefits to be gained by targeting a specific platform. Objective-C is not an OSX specific language, but it has gained notoriety thanks to its close relationship to the OSX Cocoa framework and its associated user interface functionality.
Whilst the Cocoa framework is available on a variety of platforms, it is most well known for its OSX implementation where Apple has injected a considerable amount of additional functionality. Unfortunately much of this functionality relies on libraries present only within OSX, and as a result the cross-platform, open source implementation of Cocoa, GNUstep, is viewed by many as its poor cousin. For a good discussion of Cocoa, OSX and GNUstep checkout the interview with a couple of GNUstep developers on FLOSS Weekly.
The other significant development framework on OSX is Carbon, but this is primarily intended as a compatibility library between the "classic" MacOS and OSX. Any new development should be undertaken in Cocoa simply because this is where all the action is. Plus, if Apple stays true to form, support for Carbon will cease in the not too distant future.
As far as development environments go the OSX-only XCode from Apple is far and away the best IDE for developing in Objective-C and Cocoa. XCode and its accompanying tools are shipped free as part of OSX, plus there is a large developer community and Apple Developer Connection (ADC) to call on for support. Paid membership to ADC can be expensive depending on your needs, but like MSDN this grants you improved access to Apple’s internal development processes and pre-release software. Unfortunately on other platforms such as Ubuntu the tooling for Cocoa and Objective-C is not so strong. GNUstep has the ProjectCenter IDE, but this does not compare well to Visual Studio, Java IDEs or XCode in terms of its functionality or polish.
Life without an IDE - Text Editors and Command Lines
Whilst it may sound strange for someone used to operating within Visual Studio's padded walls, some of the best cross-platform development environments you can create yourself using a text editor and command line tools. Unlike C# and Java, languages such as Ruby and Python have grown to where they are now without significant support from complex IDEs. Learning a new language using these limited tools can also prove beneficial because you are not shielded from a language’s complexities by a "helpful" IDE. The end result is you gain a much better understanding of a language and its runtime environment than you would if you were to continually rely on an IDE’s wizards.
When using such an approach it is easy to move between different operating systems because each has an excellent suite of text editors. On OSX this choice ranges from the free TextWrangler through to the moderately expensive TextMate. As far as Linux goes it really depends on your operating environment (Gnome, KDE, etc) and preference for GUI or command line tools. Needless to say like most things open source, there are extensive and intense debates about the pros and cons of various text editors.
Version Control is the Key
No matter what language or development approach you choose the most important to setup and use is some form of version control. Systems like Subversion or Git make it easy for developers to move between OSX, Linux and Windows without having to worry about shared filesystems. There some very good GUI tools for version control management, for example the tools built into Java IDEs and standalone applications such as Versions (OSX only) and RapidSVN.
Version control is especially important in cross-platform development because no matter how hard you try, chances are you will inadvertently introduce a bug that affects one or more of your target platforms. When this happens it is important that you can quickly find out what was changed, or what changed on your target platform, and work up a patch. This may involve reverting to a previous version of your code, or creating a platform specific branch.
Unlike the .Net/Visual Studio dominated world of Windows the choices available to a developer on OSX and Linux are many and varied. There is certainly no right answer, but more often than not there is one language that fits the problem space or context you are working in better than others. Personally I prefer the breadth and depth of the Java development world. Not only is arguably the most cross-platform, but it also has a strong developer community and tooling that is on par with, and at times better than, Visual Studio.
Unfortunately if it is a desktop application you wish to develop, Java is in a state of flux until JavaFX gains more adoption and is released on platforms other than Windows. With this in mind the functionality offered from Mono and its WinForms implementation is hard to pass by, even if the tooling support available in Mono Develop is immature at present.
Perhaps the most difficult development decisions arise if you wish to develop for mobile devices. In terms of a lucrative market the iPhone with its Cocoa framework is hard to ignore. However a version of Java, be it Micro Edition or Dalvik, is available on most other mobile devices. Fortunately I am not a developer in this space, but if I were I would probably take the iPhone route given its proven market. This being said I would keep a close eye on the growth of Android as its openness may prove the winner in the long-term.