Archive for April, 2011In the past couple of weeks I have been programming in .NET for the first time since 2006. My last stint was actually mostly C++-stuff in a code base based on MFC, so the .NET parts were really not that prominent, and I did not touch C# at all. This means that I was new to C# in all relevant aspects when the current project started. The project is integration work – we are embedding a thin C# client in third party software to enable integration between that software and our main product implemented in Java. Starting out, the first expression is really how similar C# and Java are. As a Java developer there are no problems getting started – mostly it’s just new APIs to learn. You will also of course have to switch IDEs – in my case from Eclipse to Visual Studio .NET 2010. Still, the main difference is the keyboard shortcuts, and I am amazed how quickly my brain can replace hardwired shortcut commands such as Ctrl+/ for comment section to Ctrl+k, Ctrl+c. Even stranger is when you go back to Eclipse and you are suddenly dumbfounded when you can’t remember the old shortcut anymore. Of course, after a while you start to notice other things – the perks, the annoyances and the little differences. I will spend the rest of this post listing some of the stuff I have noticed. Visual Studio vs Eclipse Visual Studio is more polished, feels quicker and is much more user friendly. I was surprised at this, because that was definitely not my impression five years ago. Now, Visual Studio just feels more modern. The one thing I lack is Maven, or something similar. We are two developers on our current project, and we have set up our projects a little bit differently, so we keep overwriting our project files in the SVN repository. It is annoying to have to manually update the project references after every SVN update, and I really detest having to include binaries in the SVN. Of course we could just work out a common setup, but in Eclipse with Maven this problem would not exist in the first place – dependencies would just be automagically resolved. Properties In C#, a class can have properties, which is basically variables with getters and setters. (The property concept allows for much more, but this is mostly how I have seen it used.) At times, this is really neat, but I don’t like it because it seems to promote get/set programming as opposed to Tell, Don’t Ask. Of course nobody is forcing you to use properties, but it is an easy enough trap to fall in – I feel I have already begun to overuse it. Delegates Delegates seems like a powerful thing, but I have not seen it used in the code base, which makes me kind of hesitant to try it out. The delegate concept actually promotes OOP (as opposed to e.g. properties) since it makes it possible to send a function as an argument to a method. In Java, this would be handled by declaring an interface with a single method and implementing an anonymous inner class. In comparison, the delegate concept seems much more elegant. Java apparently will get closures Any Day Now, which I really look forward to. Naming of Classes and Interfaces This really bugs me with C#. In something that must be the last remnant of the (blissfully) long dead Hungarian notation, interfaces in the .NET API are prefixed with the letter “I”. I don’t see the point of this at all – quite the contrary, it is downright harmful. Compare these two method declarations in C#:
The second example just feels cleaner. It’s just not right that you are punished aesthetically by programming to an interface. Compare with these Java declarations:
Here, the declaration using the interface is much cleaner. This might seem like a small thing, but it’s really not – the Java API is subtly guiding you into OOP, while C# is doing the opposite. Another important issue is that in the C# version the reasons for programming to an interface are not clear. It looks as if
Tags: C#, Java, OOP Well, first of all the “Java Software Stack” is not so much a stack as it is a forest of possibilities. At every level there are multiple choices: what application server to use (Tomcat, JBoss, WebSphere, Jetty…), what IDE to use (Eclipse, NetBeans, IntelliJ…), what OS to run on (Windows, Linux…), what framework to use (Spring, Struts…), what to use for the database persistance layer (Hibernate, IBATIS…), what DBMS to use (Oracle, SQL Server, mySQL…) and so on. Even such basic things as choice of programming language can be put to the question, with other JVM languages such as Groovy and Scala vying for attention, and there are also multiple implementations of the JVM itself. How can a developer who is introduced to these choices possibly be expected to come up with a combination that works? Some of these choices are more important than others, and in other cases the choice is truly just a matter of personal preference. The fragmentation also leads to tools that are not exactly the most user friendly you will use (Eclipse – I am looking at you) since they need to support many different choices for other parts of the stack. The fragmentation is somewhat paradoxical since the thing I like most about the Java programming language is that it is constrained. There is often just one way to do something. All code must be part of a class. All .java files must represent one class. Checked exceptions. Statical typing. Garbage collection. In my opinion, these features all contribute to make Java very maintainable. I do not think that it is a coincidence that Java and C# still rule the application programming space, even though more dynamic languages have taken over elsewhere. For teams of programmers, it is important that, in a sense, all code looks the same, as enforced by the language constraints and naming conventions. The constraints also makes it possible to implement really nice IDEs for development, lightening some of the burdens the constraints bring with them (such as verbosity). For C#, the constraints continue all through the software stack. You run it on Windows in the .NET framework, with ASP as a template language, on IIS with an MS SQL Server database. You develop in MS Visual Studio. You can even extend the Microsoft stack even further, for example by adding their version control system. All this makes C# a really good choice for building Windows only applications. The integration is superb, and is something Java will never have. I suppose it is the curse of “open” that fragments the Java stack. When something is “open”, everyone will have their own idea on how to use it, so the Java stack becomes a bazaar rather than a cathedral. This is, of course, both good and bad. The bad part is that you can easily get lost among the different alternatives, and get stuck trying to integrate different components with eachother. The C# programmer has no such problems – it Just Works. Microsoft is to developers what Apple is to end users. Since my job involves mostly Java SE stuff, I can blissfully leave most of the difficult choices behind. And stripped down to its core, I will stick to my guns and proclaim Java a really nice language. Apart from the fact that it is constrained in a good way, the main advantage is one of the things that leads to fragmentation in the first place: its platform independence. Because, you know, sometimes you might actually want to run your program on Linux, or even (God forbid) Mac. In fact, these cases are really common. Without getting into details, I would say I vastly prefer Linux to Windows as a server platform, while on the desktop it is the other way around. With Java, this is no problem. The program works the same on both platforms, so I can happily develop and test on my Windows box, and still be certain that it will work on Linux as well, provided I implemented my program in a correct way (for example, remembering to handle character sets etc, which I really should take care to do in any case). Sure, Java could use some tidying up, but until something better comes along, I will stick with it. I just wish that some things weren’t quite so, well, clunky. Tags: Java, Programming languages This week I decided to play around a little bit with Spring MVC. I am not a web programmer by occupation, but it is something I want to learn, and I decided to start with this tutorial. The choice of Spring was rather random, except for the fact that I wanted to use Java as a programming language since this is familiar territory for me. To complicate matters, I decided to run the latest version of Spring, 3.1, instead of 2.x as suggested in the tutorial. With jar names changed I also quickly decided to abandon ant for Maven, which overall turned out to be a good choice. Maven can certainly be a little (or a lot) clunky, but the dependency management makes it all worthwhile. Luckily, I found another guide that comprehensively describes the Maven integration. For development environment I used Eclipse, which despite its various shortcomings is my first choice for Java development. Setting up the Tomcat application server was more complicated. Keep in mind that I have only coded very basic web applications before, so it was a lot of work to get the debug environment up and running. While I am sure there must be an easier way to do it in Eclipse via a Server project, I ended up running a standalone Tomcat installation, redirecting via
I then had to include all the Tomcat jars from the installation as external jars in my Eclipse project before I could finally start the server in debug mode by calling the startup class directly. Cumbersome as this may be it works for now, although I will probably have to revisit this in the future. My general impression of Spring is mixed. On one hand, I suppose it is nice to have the code separated into Model/View/Controller with configuration in XML, but on the other hand it is easy to see how this whole approach could get completely out of hand. XML may be a good tool for many things (configuration, data specification etc), but it is crappy as a program language. Moving implementation into XML files via excessive use of beans seems like a terrible idea, yet I can easily imagine how one would end up in this situation in Spring when programming for “configurability”. So does Spring speed up the process of getting a website up quickly? Well, not really. Of the limited options I have tried to get a website up in the quickest possible way PHP wins hands down. This is surprising to me, since I figured all the newer neat frameworks (Ruby on Rails, Grails, Spring etc) would help with this, but the reality is that they have a steep learning curve. In PHP, what you need to know from start basically boils down to the language itself and some basic SQL, while with these other frameworks you have to grasp the relationship between model, view and controller, and probably at least two different programming languages (one for templating and one for code) as well. Not to mention all the work you need to put in to get a test environment up and running, where in PHP you would just copy your files to a folder. PHP also seems to be supported more at inexpensive web hotels, at least in my limited experience. Having said this, PHP certainly has its drawbacks. It is a mess of black magic calls to global structures, and I suspect it fosters horrible programming habits when it comes to OOP concepts etc. I think I will stick with Spring for now, mostly because it is based on something I have good knowledge of (Java). My next project will be to upgrade my code from the tutorial to use the Spring 3.1 features in full, by replacing all the calls to deprecated functions and take more advantage of the annotation based framework.
Tags: Java, Spring Time to get my tech blogging rolling. Here we go. Posted in: Uncategorized | No Comments » |