#3, Development Environments

I wrote my first computer program in 1985 when I was a university freshman studying Electrical Engineering. Michael Jackson's Thriller, hair bands and breakdance were the popular things, and girls looked so colourful and had big hairs, shoulder pads, and big belts. The PC era had just started. Our school was still using IBM mainframes primarily. If you were lucky, you'd get to use a dumb terminal, a text-based IO device that connected users to the mainframe computer. The Terminal (or Console or Command Prompt) window in today's computers simulates that experience. For us poor first-years, off-line batch processing was the way. We wrote our code on a punch card machine (http://en.wikipedia.org/wiki/Punch_card). Each line of code had to be written on one card, the set of cards would then go to computer room as a "job". After the batch of jobs was processed, we would get our results as a print-out usually the next day. Imagine our disappointment when we saw a simple syntax error had wasted our whole day! BTW, my first programming language was FORTRAN. Later I moved to simple personal systems like Commodore 64 and ZX Spectrum to write and run BASIC programs in real-time (the joy of that!). By the time I got to my senior year, we were using IBM PC (8-bit XT and 16-bit AT) and I moved to Assembly programming for micro-controllers like Z80 and later my only successful love affair, 8051. MS-DOS had no GUI and we used a simple text editor and then the command-line compiler/assembler and linker. I experienced the pleasure of Integrated Development Environment (IDE) and C/C++ programming when I graduated and started working as a computer engineer. My first IDE was Borland C++. My first PC at work was a 386DX that could actually fly compared to old XT and AT. I did AutoLisp programming on it for AutoCAD. It needed 10 floppy discs to install and had a real setup program that looked so confusing to me I had to call a friend to come to our office and help me without anybody noticing. I was considered AutoCAD pro! (Nobody else knew how to write code for AutoCAD. Neither did I, but I claimed I did and I learned quickly). I saw my first OS GUI on Amiga and then Windows 3 which wasn't really an OS because you still needed DOS to boot. And so started a long journey of coding in DOS, Windows, and Unix.

Considering my history as a software programmer, naturally one of my major curiosities when I started using a Mac was related to application development. This of course was intensified by all the recent talks about Apple and application developers. I've always believed that the popularity of PCs was due to the availability of applications and ease of programming and customization (and of course lower prices). Mac became an iconic graphics workstation because of graphics software made available on it (thanks to Adobe! It seems that history has a sense of irony). It is now becoming more popular because more applications are being developed for it (not to deny other reasons). After all, applications are what we want, not computers by themselves. A smart OS/hardware company makes it as easy as possible for developers to build new applications. What I really find unacceptable about Apple's policies is the way they force developers to use Apple's technologies. I don't believe these restrictions are about, for example, Flash not being a good technology. On iPhone, developers can't use any non-Apple technology, no matter how good or bad. It is Apple's intention to keep their control over the app market, not their care for HTML5 or users. They could support other older technologies while there is no strong alternative, and let users decide for their own what they want to use. On Mac, the situation is not much different from iPhone, and Apple (just like Microsoft) is pushing for it's own proprietary technologies (Objective-C language for example) but in a less restrictive fashion than iPhone case. Anyway, my first impression of native development tools on Mac was what I wanted to talk about this week.

Let me start by giving you a kinda big picture idea first.
1- Although there are 3rd party development tools and languages (especially for web applications) such as Flash/ActionScript, the primary tools for application development are Microsoft Visual Studio and Apple Xcode.
2- Both Windows and OSX provide support for basic console applications written in standard C/C++, and also common technologies such as OpenGL. Windows no longer comes with built-in OpenGL support but the library is easily available. OSX comes with built-in OpenGL but Apple also promotes its own OpenCL.
3- Both Windows and OSX come with their own native API for multimedia and GUI programming in C/C++. These programs won't be compatible with other platforms due to the use of OS-specific libraries such as Win32/GDI and DirectX on Windows, and OpenCL, Carbon and Quartz on OSX.
4- Both Windows and OSX have offered new frameworks with their own native languages and the promise of providing more features and similar development on multiple hardware (e.g. mobile devices from the same company). These are .NET framework on Windows with C# language and Cocoa framework with Objective-C. Compact .NET and Cocoa Touch are the mobile versions of these frameworks.

For comparing Windows and OSX development tools, I use the following criteria:
1- User Interface
2- API Functionality and Complexity
3- Compatibility
4- Documentation
5- Samples

So far my review and comparison seems the easiest when it comes to development tools. Pretty much in all the above criteria, Windows is superior! This may sound too quick an opinion (and probably is). I still have a primitive knowledge of Mac development tools and frameworks, and I expect my judgment to change when I get to know them better. Also many things on Mac seem difficult due to the fact that I'm used to Windows and Visual Studio. So expect some of the following statements to be revised later, but for now here is what I've seen.

Microsoft has definitely done a good job providing easy to use development tools with lots of functionality at your finger tips. Compared to Visual Studio, Xcode looks awkward unintuitive and not integrated properly. For example Interface Builder is a separate program in Xcode. Object Browser, Class/Function/Resource Views, and Debugging tools are limited or non-existing (or well-hidden) in Xcode. Visual Studio provides way more information in the source code editor (e.g. function syntax or object members, go to definition, etc). The interface in Visual Studio is more customizable and toolbars way more effective and manageable (Xcode has only one toolbar). Even things like Find and Replace are harder to use in Xcode and not integrated well with source code editor. Visual Studio's hierarchical view from Solution (non-existing in Xcode) and Project, to File/Class/Function/Resource, and it's arrangement of Output/Find windows, are more practical.

It is too early for me to compare the full functionality and complexity of Windows and OSX APIs. Apple is pushing for Cocoa that is based on Objective-C. The C-based APIs are being removed and not supported by Xcode project wizard (you don't have them as an option for a new project). Unlike that, Visual Studio still supports a variety of applications and APIs based on C/C++. In return of using proprietary .NET and C#, Windows programmers get an easy-to-use class library and GUI for making applications. The least I can say about Cocoa and Objective-C at this time is that programming is certainly not as easy as C#, to some level because of the interface and also complexities inherited from C that don't exist in C#. Relative complexity of Objective-C comes with an advantage: it is easier to combine C and Objective-C code than it is to do so for C and C#.

As far as compatibility is concerned, Xcode and Visual Studio are not that different. Unless you do standard C/C++ or use portable libraries like OpenGL (or my favourite educational tool, Allegro), you will lose compatibility. Porting your code to other devices like smartphones is tricky in both cases. Visual Studio does provide libraries like XNA that are really cross-platform. .NET provides a certain level of code portability between Windows on PC and other Microsoft platforms. I'm not so sure about differences, for example, between Cocoa and Cocoa Touch code and how portable they are.

MSDN library is the central knowledge base for Windows and .NET programming. Compared to MSDN library, Apple's documentations for Xcode and supported APIs are weak, hard-to-use and limited. There are also much more 3rd party online support and documentation for Windows programming. Same thing applies to sample codes.

Finally, two quick general notes:
1- Mac startup is definitely faster. From power-up to successfully opening Chrome: OSX 40 seconds, Windows 80 seconds
2- Why Mac doesn't come with a simple Paint program? There are free tools though. I downloaded a decent one called Paintbrush (old name in Windows before Paint). I found Gimp a little awkward and slow. Another missing simple tool is SoundRecorder which BTW was much better in XP than the Win7/Vista version. On Mac I installed free Audacity which is more than a simple SoundRecorder but is easy to use and does the job.

My next step: working on API functionality

I'LL BE BACK!