Google+ Badge

Tuesday, September 7, 2010

Why Java beats C++ and C# when you really want to be productive

I have programmed in a lot of languages over time and the one I always come back to when I want quick productivity, notice I did not necessarily say quick run time, is Java. Why would that be?

First off you can just start typing your ideas and get the program running quickly. In C++ every time you write a few lines of code you have to think about writing the anti-lines too. Create it and clean it up. C# is a dead tie with Java here usually. The one are that gets a little annoying is being in the Dialog editor, clicking on a control, click on "OnClick" event and having it pop you back into editor to write the code. There are a lot of times I know I want "OnClick" events for 5 buttons on a dialog, I don't want it switching to the editor over and over. I want to stay on the Dialog until all 5 stubs are in place then I will do my code editing.

I have done a lot of code reviews. When we reviewed C++ code you could take a single CPP file and find all sorts of issues - potential memory leaks - unnecessary string conversions - etc. Reviewing Java code means looking and how multiple objects interact. Basically the language eliminates the chances of making a lot of stupid mistakes. It cleans up memory usage, there is only one String class. This allowed us to look at the architecture instead of just the syntax. I was not doing C# when I was doing C++ vs. Java code reviews but I have a feeling it would be very similar to Java.

If I need to do a simple dialog box to say open a file, read in settings and allow a user to change settings and save them back I use C# / WinForms. The only reason for this is WinForms makes it so easy to lay out a dialog box. Not that Java is super hard but you have to think about what layouts to use, how to lay them out in relationship to each other and write all the code to create the controls and panels. I do it all day long but that does not mean I enjoy it. WinForms is a clear winner in this area for me most of the time. There are odd anchoring situations that WinForms can just not handle where a GridBagLayout of MigLayout in Java are coded with ease.

When you get into C# / WPF you are basically back in the Java world. Sure there is an editor but it is not the most friendly thing in the world. Add to this you are looking in two files, XAML and CS, to keep it all tied together and you lose a little bit to Java side as a programmer. I know the XAML split makes it much easier if you have a designer and developer working in tandem. In the end it is probably the correct way to split the presentation from the code and data.

C++ has a Dialog editor of course but it stinks when you need to resize and move controls about. Then you have to deal with MFC on the back side which is really a terrible thin wrapper over the Win32 API and it is not object oriented. MFC has a very limited set of controls and they are hard to customize adding to your pain. When I was doing a lot of dialog work with a team in London I would do all the prototypes in C# and after many meetings getting the look hammered out I would convert it to C++ / MFC. This seems to be a great approach as WinForms allowed nearly instant tweaks so I could send a prototype back to them in the middle of the conference call which would have taken too much coding effort to pull off in MFC.

The one huge issue that hits home once a project starts to grow in size is compile time speed. In Java using Eclipse the program is basically always built. You know all the compile time errors instantly and when you hit run it just runs. Even the web project I work on, which takes an extra step to build jars and deploy them to Apache Tomcat, is an ANT script I wrote that takes an average of 8 seconds to build 4 jar files totaling 6.4 meg. That allows me to update code, JAR it and test it in seconds. We have multiple projects that share the same common Java code. I keep them all loaded in Eclipse so I instantly know if any code changes I make in the common areas break other projects.

The C++ project takes 45 minutes to build. We have build errors nightly on that project as people build and test small parts of code but don't build and test the whole thing. Who has time to do that more than once a day? Plus if there is shared code you have to build multiple projects to know if you broke other areas. That pretty much never happens.

The C# project, which is barely functional as we are just getting it off the ground, takes 5 minutes to build. I really feel the wasted time. In Java I stay in my constant coding cycle all day long. I rarely mess with the C++ code. For the C# cycle you get bored waiting on the compile so you check out a blog or other websites while you wait then you forget to check back to see it is done building. Finally you get to test your code if you can remember what you were even trying to fix 10 minutes later. This project is being written in a modular manner with various DLLs and a single EXE tied together using MEF. This adds to the compile time as files due to HD access for all the file copies that are going on. I am sure this could be sped up. Stand alone smaller applications I have worked on in the past seemed to build a lot faster, nearly Java speed.

It can be a wash at the start of a project when you are writing large amounts of code between compiles but let's say you are trying to tweak a small area of fix a little bug where the debugger is just not giving enough info. I ran into this when dealing with the 3rd party license issue with C#. Add two lines of code, build, run, try again. I have done that plenty in Java but it became quickly painful and very unproductive feeling in C#.

Java wins for being the most productive over the life of a product. Plus it runs on multiple platforms and I can use it write stand alone applications or Web apps. It is not the most friendly for building the initial UI or Dialogs but it is very flexible in this area and all your dialogs are resizable for (almost) free allowing for easier internationalization.

C# / WinForms wins for small dialog based products. Quick to layout and quick to build and test. Best used for standalone apps. Harder to internationalize as the localization folks need to touch every dialog. Limited to one OS.

I feel like I have the most control over the look and feel in C# / WPF as you can get very fancy with very little programming effort. Every control is custom draw because even list box elements can be a panel with anything in it you want and data binding is very easy. Can be used for both stand alone and Web apps although you switch to Silverlight with it owns set of special limitations to go that route. I have a feeling all the flexibility will cause things to run slower as the application grows. There is always a penalty to be paid for eye candy.

Expertly written C++ can be the winner for stand alone applications if you want pure speed and want to be able to use every ounce of the OS you are running against. You can talk to every device hanging off your system or network. There are times that needs to happen but those times are getting rarer. You can use QT for cross platform. I don't think many would choose C++ for Web apps. You do pay the price at development time, harder to find and fix bugs, longer compile times and older tools across the board to help you out. Great language for a lot of uses, always handy to know how to read it.

So there you have it, I like Java the best right now. C# / WPF might grow on me if we can get in there and optimize the compile time and delve into all the flexibility with a designer by my side . C# / WinForms seems to have its uses but is not the direction MS is going at this time. C++ still has many uses but is not where I would start to write smaller utilities or to write a fancy pants UI.