Thinking in or out of programming languages

I remember the first time I took a look at C#. As a C++ programmer, I was impressed not by the language but by the IDE. I could do without multiple inheritance, but there were no templates either; case was closed, for good, I thought. Fortunately, many did not close the case. It did not took long for Microsoft to release C# 2.0; however, to me, damage was done. I am not talking about the huge .NET libraries, for which generics could help a lot. Real victims were the developers; there are still programs being written as if in C# 1.0. I don’t want to go into details of this matter right now. If you want to discuss, please don’t hesitate to comment.

Anyway, I started to use C# and I was happy until 3.0. Wait, wait, I know what is going to happen if I don’t make myself clear. C# is my language of choice when I need UI; but, you can never stop programming in C++. If I happen to use both of them for a project, I constantly switch between C++, C++CLI and C#. This is where the trouble begins. Before C# 3.0, I could say that my productivity was pretty much the same in each one of them. After 3.0, I caught myself trying to accomplish everything in C# as much as I could. Easiest way is not always the right way. Again, I have got to skip this if I want to finish this post. The point is, I use C# more and more everyday.

I have always had complaints about C# but a few days ago, I realized that some differences in programming languages are harder to overcome than I thought. I usually make a mistake, caused by experiences in another language, once or twice. What I have found out is that, if I can’t rationalize the difference, I make it all the time.

Suppose you wrote an interface which has a property with no setter. You also wrote lots of classes, implementing this interface. As long as these classes implement a public getter for the property, there is no problem, right? One day, you realize that number of these classes will increase and all will benefit from an abstract base class. (As a side note; there are no distinctions as interfaces or abstract classes in C++. There are classes without any implementation and partially implemented classes which could stand as counter-parts respectively. So, the following problems have no counter-part in C++) First of all, your new base class must declare (copy) all members of the interface as abstract members if there is no implementation. Is this really necessary? Secondly, you have to mark all of your previous implementations with override. I hear you saying, I can do all of these with a couple keyboard shortcuts, thanks to my refactoring tool. Last but not least, you can not do this all the time without changing your design of previously written classes. That’s right! Suppose one of your implementations also provide a public setter for our non-problematic-looking property, and another one with a private setter. Can you tell the problem?

Do you think in or out of your language?

P.S. This post is a side product of a project, I promised earlier, GeoStructor. Its code does not contain a solution to the problem above, so has lots of repetition. Actually, code requires lots of changes. When that happens, I will probably write another WPF related article which will include some techniques (regarding XamlReader/XamlWriter, Dragging, etc.) I used.


P.P.S. Initially, I tried to explain a problem without codes in order to provoke thinking. However, discussions will be healthier with a sample. Please expand to see the code. Sorry about the naming.

4 thoughts on “Thinking in or out of programming languages”

  1. I added a code sample, at the bottom of the post. Please try to insert an abstract class in between the inheritance hierarchy while keeping the setters.
    Ibrahim: If your tool, which shall not be named ;) , can accomplish this, I will start using it.
    It all comes down to an inconsistency in placement of modifier keywords. It is not a big deal, though. C# 4.2 will save us all.

  2. I am also sorry that I didn’t make it clear in my first comment. I had understood your point without the code sample. I have tried exactly the same way. What I wanted to emphasize was that refactoring tool – which is reaching version 4.2 faster than c# does – have that refactoring as a single action. Therefore it checks code structure prior to applying refactoring and warns you that it cannot be done without modifying the implementers by giving the exact source locations causing the problem. So you can modify implementers of the interface and it is not a big deal.

    Of course I agree that it would be disaster if it would start refactoring right away and ended up with an unwanted code state. IMHO that is the difference between a good tool and a poor tool. That was my point.

    P.S. Since you are dealing with XAML, you should definitely check its capabilities. It may blow your mind off when you see what it does with XAML ;)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">