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.

11 comments:

  1. Your comparison between languages is brilliant. I really like how you tell it like it is. Though I must say that personally I find the Java libraries difficult to understand at times and hence difficult to recall. C# is indeed merely Microsoft's take on Java, but my personal belief is that the libraries are much easier to grasp and make sense of. You are right, so am I. Programming really is all about working with the tools and languages that work best for you! A place for everything and everything in its place :)

    ReplyDelete
  2. One of the reasons that I prefer working in Java compared to C# is the amount of useful Open Source libraries that are available. Sure you get Open Source in .Net but it just doesn't compare to Java.

    ReplyDelete
  3. productivity in java is surely better than in c++.

    But for c# it is a matter of taste as kanu already stated

    > which takes an extra step to build jars and deploy them to Apache Tomcat

    you should try jetty, where you can fire up your webapp in 1 or 2 seconds (class reloading)! even without jrebel

    ReplyDelete
  4. Thanks for the comments. I could have titled this "Why Java and C# beat C++ for productivity" but I was annoyed that day due to compile times for C# and I was really missing doing straight Java work. In general they are very darn close in a lot of ways.

    I have found, and used, a lot of open source projects in Java. Free with source code I can muck with is handy. Since Java source is pretty easy to read no matter who wrote it and Eclipse can reformat it to taste I actually tweak Java open source. It can be a bear to do that with C++ open source.

    Some of the Java library stuff is rather archaic for sure. Showing its age and parts are not allowed to go away so we are constantly backwards compatible. It is not perfect.

    I have not looked into Jetty. All of our stuff is jarred up and signed due to our access to the local file system etc. I really can't complain about an 8 second JAR process. I rarely have to bounce the Tomcat server as almost all my changes are to the front end side of things but even when I do that takes about 4 seconds with a simple button press in Eclipse thanks to a plug-in.

    Keep picking the right tool for the job. Sure makes life easier.

    ReplyDelete
  5. This comment has been removed by the author.

    ReplyDelete
  6. Love the article,

    To me is a matter of learning curve vs
    productivity.

    I started developing Java in 1999.

    To my knowledge c# has a quicker learning stage. Libraries seem more simple, and it is, in my opinion because they started implementing those libraries once the Java experiment was quiet far down the track. For example: for years java used java.util.Vector as it's default List implementation. Only later developers realized that synchronization was not neccesary and a later JDK introduced ArrayList.

    c#/.net didn't have to go around making the exact same mistakes.

    Any software innovation tends to follow the same steps: The initial release even though 95% "ideal" carries a few mistakes, things are not as simplified as they could be and it is only with the help of the community that libraries mature.

    To me, the bigger the adoption of a platform, the number of developers, the more mature the libraries become. (maturity = number of bugs, simplicity, speed)

    Java, in my eyes, had always had a very heart filling backwards compatibility approach and new features were added in a a way that could live happily with existing ones. Like Swing and AWT. All EJB versions. JDK byte code. Classes compiled to the JDK1.1 still run in JDK7.

    People criticise how difficult is to choose application server vs. simply sticking to IIS.

    How difficult is to choose IDE, JPA implementation, web framewoerk vs VisualStudio + MVC.

    Sure better coding that shuffling, better knocking off a project in 6 months than in 6 months + 1 month of technology choice research.


    To me it boils down to a matter of health on faith in god.

    A lot of c#/.net projects (maybe excluding web applications) are based on the assumption that Windows will predominate the os market for the entire life of the project.

    Cross platform compatibility of .NET is not a fact (not Mono). And totally contradicts the goal of a company for which 50% of their income comes from Ms Windows sales.

    To me, .NET is another of Microsoft's aid to Sell Windows, The revenue Microsoft gets from Microsoft Visual Studio licences is just nothing.

    If Ubuntu, chrome os or mac os start gaining terrain on the desktop os market and Android or similar stablish themselves on the mobile os, what are we going to do with .net desktop / mobile applications?

    Why would microsoft have any interest in making .net run smoothly in other operating systems?

    When Sun developed Java, have of the internet servers (Sun's main source of revenue) were from Sun Microsystems and they tought that aiding software development for the internet would increase the demand on servers and therefore their sales.

    Making .net run in other operating systems will reduce the sales of Microsoft and therefore their revenue.

    I don't see the way forwards towards cross platform for Microsoft.

    When it comes to the language, I could debate inheritance vs aggregation. Inheritance can introduce a lot of bugs. What to say of multiple inheritance.

    Even though many of the c# developers i talk have a "the more, the better" when it comes to language features. I see that a good balance of features and simplicity is actually "the better"

    Sure deal that front ends have different language requirements than back ends. But to me, java shows a better "average".

    ReplyDelete
  7. matter of taste (+1), I'm really productive in c#

    ReplyDelete
  8. For web applications, Java is best because you have Wicket. But Wicket would be even better if it could make use of features currently found only in C#.

    ReplyDelete
  9. C++ isn't as productive as C#/Java only in the projects you've worked on, so the comparison is slightly skewed. Indeed, one can't be productive enough with Java when they need to access some low level stuff.

    Furthermore, when comparing C# and Java especially in terms of building Windows application you should never forget that C# unlike Java allows you to create applications with a native look-and-feel, while desktop Java applications always look odd and a tad unresponsive.

    ReplyDelete
  10. In response to Mike Borozdin - I have worked on multiple projects with two similar clients, one written in C++ and one in Java. In all the cases I have experience in the Java application surpassed the C++ application in responsiveness and in overall speed.

    Why? Java is a newer language. It was designed with internationalization and threading in mind from the start. It is more difficult and error prone to write multithreaded applications in C++. It is harder to pick a single string format in C++ especially when you start mixing in 3rd party libraries. The language came out before these things were common.

    Could the C++ code have been rewritten to beat the responsiveness and speed of Java? Yes, I have no doubt it could be. This was a stock market program using real-time data so I am not talking about faster as showing a table of text for the user to click on from an SQL query. I am talking about hundreds of stock symbols updating in a massive grid along with Chinese and Japanese headlines scrolling in to another window along with various other views of stock data on screen.

    During our current SCRUM meetings I have observed the C++ team member will generally guess between 1.5x and 2x the amount of time to implement the same feature on their side than the Java team member. As the SCRUM moves forward these times are accurate. Some of it is the underlying design some of it the Language. When I write in Java I am thinking of the design first and the language syntax second. When I write in C++ I syntax and resources come to mind more often.

    If I have to write the code in both languages I tend to get it working in Java first then port it back to C++. This actually gives me really nice and clean C++ code as I am only thinking about language at that time.

    I had a rather large dialog with many child dialogs (let's not get into the design decisions on that right now) that needed to be written in MFC / C++ for news filtering. I wrote it all in C# / WinForms. During meetings I was sending new copies of the prototype as we spoke to the folks in London and Paris. In the end I converted it to C++ even writing new custom control to cover for a base control I used in C# that I forgot was not standard in MFC.

    I totally agree Java is the wrong tool to use for low level access. C# may or may not work in this area and C++ is the way to go.

    When writing similar tasks code - even if it is front end GUI based - I can type the code out faster, debug it easier and deliver it quicker in Java. Your mileage may vary.

    Using MigLayout and Swing loading the OS default look and feel is not perfect but it works pretty darn good. If you write a C++ program to work on Linux, Mac and Windows how does it look? Probably not native. Of course if multiple OS is not your target then this does not matter.

    I hope I did not come across as Java is the winner in all cases, it is not. When given a choice, and the project is not dependent OS specific features, I can get it running faster in Java. I get the bonus of having it run on other platforms.

    We have special cases in our Java software for the Mac and for Linux. We also have special cases when running on Vista/Win7. Java is not write one run anywhere if you care about its looks. Our C++ code only runs on Windows but it also has checks for 2000 vs XP vs Vista/Win7. Comes with the territory when writing custom GUI controls.

    I can find bad examples of programs written in nearly any computer language, even assembler which I have not touched in a long time. Properly written, designed and debugged C++, Java and C# programs can be written so well that you can't really tell what they were written in.

    When I develop in any language that is my goal, to give you a best I can with that tool and to not throw you for a loop and confuse you with the look and feel, button placement or other UI inconsistencies.

    After typing all this I feel it should have been a new blog entry.

    ReplyDelete