December 2005 - Posts
Today I saw this blogpost: http://blogs.msdn.com/tparks/archive/2005/12/30/508164.aspx, titled 'Java only is bad mmmkay?'. It's a blogpost inspired on some article by Joel: http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html.
I wondered: "Would that Microsoft employee have written 'C# only is bad mmmkay', if C# was the major language of choice at universities? We'll never know but I have the feeling that we never would have seen the post. The reason is that the whole debate which languages are used at universities to teach students programming is one of those debates which shows who gets it and who doesn't. Before you point your finger at me and yell "Haha you now painted yourself into a corner, bozo!!!11", let me explain.
Repeat after me: "It doesn't matter which language is used to teach programming principles".
Ok, again and now a little louder.
Great, your neighbours are again very pleased you live next to them, but I hope you get the point. So if a university opts for Java, or whatever other language, it doesn't matter: it's not the language that's taught, but the principle of writing software: from abstract definition of algorithm to a physical representation of the algorithm in the form of working source code.
There's something else though, and it's plain, filthy marketing crap: the languages students work with at universities are often the languages they pick first after they graduate and get real jobs. So, every student who is exposed to Java is potentially a Java user for a long time. This is one of the reasons why universities are a battleground for software language developers, like Sun and Microsoft. It's sad normal developers participate in these marketing campains.
If people want to contribute to the science of software engineering, that's great. But they should start by leaving the marketing poop out of it. If the concepts of 'OO' have to be taught, you can perfectly use Java, as the tools are free, there is a lot of sourcecode available and above all: a lot of articles and books. Also, many books about Object Oriented software engineering are using Java to explain the concepts. What's wrong with that? The university I went to used Lisp to explain interpreters, used Prolog to explain writing AI, used Miranda to explain functional programming and used C to teach basic programming techniques (and a dozen other languages to teach other principles). Why does a student have to learn C++ as well, if Java serves the purpose of teaching OO (for example, you can also use it for teaching programming and OO, as the students by then already know Java so they don't spend time on learning the syntax, but can fully concentrate on the concepts taught).
To close, I'd like to comment on one quote I grabbed from Joel's article:
Instead what I'd like to claim is that Java is not, generally, a hard enough programming language that it can be used to discriminate between great programmers and mediocre programmers.
What a pile of BS. Programming has nothing to do with the language you use, Joel. Implementing an algorithm so it can be run on the other hand does, which is an activity performed after the programming phase is finished. The design of the algorithm, that's the real programming and in
that phase you'll recognize who's a great programmer and who's a mediocre programmer. The phase after that, which is the one I'd like to call the 'code generator from the stone-age phase' (I just made that up, but it drives the point home
), is the phase where human beings try to be smart and type in text which they think represent the result of the conversion from the abstract algorithm definition to executable source code. That phase can also be done by a program, it's just that the current state of algorithm describing languages isn't mature enough to outclass plain sourcecode but we'll get there eventually.
And why does a computer language have to be 'hard'? What kind of logic is that? "It's not hard enough, I don't want to use it". As if writing software today is so easy that it's hard to make mistakes and include bugs, isn't it, Joel? You sell bugtracking software, so you should know . So, to extend that logic, pick one of the most arcane languages out there and see if someone can write a solid piece of software in it. If s/he fails, it must be a mediocre programmer! 
Use this rule of thumb: you once in a while have these fun threads on programmer forums where everyone posts their most complex piece of code they've ever written. If you want to participate in that thread but can't find anything complex looking code, because all code you wrote is straight forward, easy to understand and clear to the point, you can gratulate yourself: you're a great programmer.
On a day like Christmas day, people can often lose themselves in old memories. As an old demoscene member (1989-2002), I have tons of great memories about writing endless assembler to plot pixels on an Amiga 500, demo parties etc. etc. Some time ago I had written a simple port of my old rotozoomer code in Java, and today I thought: wouldn't it be great to release that on a day like Christmas day, so my fellow nerd programmer friends have something else to mess with instead of grandma's cake?
Download the source (C#, .NET 2.0) here.
Not familiar with what a rotozoomer is? (you've missed a lot!), check the image below.
Of course, in the light of what an average ATi / nVidia card can spit out every frame, this is not that worth mentioning, but it's about what you can do with solely code and some free time.
Please read the bugreport at ladybug first. The example code there illustrates what's going on. These two issues doesn't only occur with datasets, but also with collections and custom classes.
Other issues
There are two more issues with design time databinding, which are serious, though take a bit more work to reproduce. The first is when you bind an IBindingList implementing collection at design time to a DataGridView. The grid will call AddNew(), to try to grab the property descriptors for the columns. All fine and dandy. Ok, now proceed with the following steps:
- Add a textbox a form
- Add a DataGridView to the form
- Add a BindingSource to the form
- Add an instance of the IBindingList implementing collection to the form (drag from toolbox)
- Select the collection as the datasource for the bindingsource
- Set the DataGridView's DataSource to the BindingSource
- Select the textbox, go to the properties pane and under 'Data', click open '(DataBindings)' and click on the combo-box next to 'Text'.
- VS.NET 2005 goes into an infinite loop, 100% Cpu usage.
The cause of this is that the design time databinding code calls AddNew(), then Remove(), then AddNew(), then Remove() on the collection, if the collection fires IBindingList.ListChanged() events when the Remove() method is called. It works if the ListChanged event for ItemDeleted isn't fired in design mode. Now it would be great if Microsoft for once would start writing some proper do-cu-men-ta-tion for design time databinding supporting code.
But I'm not done yet. If you allow AddNew() to fire ListChanged events you'll get another error: 'Index 0 doesn't have a correct value' or similar when you change a textbox' binding from one BindingSource field to another. Surpressing the ListChanged event for ItemAdded doesn't give this error. The strange thing is that if you add another BindingSource and set that one's DataSource property to the first BindingSource and use that second one to set the textbox' binding, it works!
What's a real misery in all this is that developing software which supports design time databinding is a true pain, and sucks big time. The real kicker isn't even the cumbersome debugging, it's the true lack of any good documentation and any form of stacktraces and proper information where an exception originates from. Like the silly error mentioned above, even if you're in debug mode (having the design time code attached to another instance of VS.NET 2005, testing the code there) no exception is thrown in your own code, so you have to perform true trial/error activities to see what causes this. It was dumb luck that this was found by disabling all events in design mode.
No generics
What's also a major let-down is the lack of support for generic collections in design time databinding. Generic collections are supported for databinding at runtime, but it's impossible to setup the databinding at design time: the designers simply refuse to look at generic classes and ignore them altogether. Now, in a way I can understand that, as instantiating a generic class needs another type, but you can work around that by specifying the type when dragging it from the toolbox onto the form. Or even specify it in the VS.NET's own designer for BindingSource when you create a datasource for your project. However that's not possible.
The real problem of this occurs when the developer actually wants to bind to a generic collection at runtime: s/he can't re-use the collection used for databinding, setup in the designer, but has to create a new instance of a generic collection, and hope that the properties exposed by the generic collection are matching the setup columns in the designer.
So if you're a developer of a class library with generic collections and you want to offer the library users design time databinding, be sure to include wrapper classes which are not generic.
Let's hope in H1 of 2006, when the Service Pack for VS.NET 2005 is supposed to be released (as Microsoft promissed), things get better. Till then, design time databinding support development is as horrible as debugging large C files in the gnu command line debugger (for the gdb impaired: it's like eating asphalt for breakfast for a week)
First, read the article @ C|Net.. According to Gartner analysts, Windows Vista stores meta-data, used for search and entered by the OS user, inside the object and owner of the meta-data 
. This of course gives problems if the user sends the object, for example a Word document, or image, to another person, as the meta-data is still inside the document, image etc.
I simply can't believe this. If you embed meta-data usage inside your OS, why on earth would you store the meta-data inside the actual file it belongs to? It's opening up all kinds of problems, like the one brought forward by Gartner. The obvious, lame and not working pandora's box solution is to offer some kind of tool no-one will use at every moment to remove the meta-data, or to do a lot of post-processing to make sure meta-data is stripped off.
IMHO a very bad design flaw, which can lead to a lot of problems in the coming years, if Microsoft keeps the meta-data inside the objects. Oh, and before I forget: if you now think "Oh, but I never enter meta-data", that might be true, but programs will add it for you. That's even worse: you're not aware there was meta-data inside the file you just sent to that customer, but unfortunately, there was...
Jon Skeet wrote an excellent article about Eclipse vs. VS.NET and where VS.NET stands compared to other IDEs. In the case you're believing the myth VS.NET is the IDE on the planet and that there's no better IDE out there, this article is a must read. For others, it's a good read too.
Please vote for this issue here:
http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx?feedbackId=FDBK42687
To reproduce, see the attached project.
The problem is potentially major: a .NET exception brings down the complete IDE. This is a problem, if a control wants to throw an exception at design time because it encounters wrong input data: it can bring down the complete IDE by doing so. If you attach a debugger after the crash occurs, you'll see that the exception not being handled is one thrown by the code in TheView class, normal .NET code.
Writing code for design time databinding is already a true nightmare and this kind of stuff doesn't really help as well. Let's hope MS solves this one quickly and for all of us.
ps: if you're trying out the example project, first build it, then open the Form1 in the designer.
ps2: Workaround: don't use the smart-tags (as they're not that smart apparently). Even if you attach a debugger to a new devenv.exe instance, load the test project there, the code won't stop where the exception is originating, but when you select the datasource from the properties grid, it will.
First, read the sillyness in all its glory here.
Now, before you step up on your soapbox and cry from the top of your lungs: "YES! I KNEW IT!", keep in mind that the number game of usage percentages is perhaps not in Java's favor, but the rest simply is: AOP, O/R mapping, DDD, TDD, usage of 3GL inside a database... technologies and tools which we now start to see appearing on the .NET platform, are common and mainstream on Java for many years already.
Until .NET is the platform where core technologies are invented and tried out first, it's not there yet, not by far and people should stop writing [insert tech here] vs. .NET articles which have the conclusion .NET apparently is on the upper hand.
This isn't meant to be a pessimistic babble, just a reality check: .NET is on track, but not there yet. Until then, let's keep our heads down and focus on what really matters to Software Engineering and make .NET the platform for core and new CS technologies, instead of losing ourselves in number voodoo practised by suits.
So, there you are, with your shiny new .NET 2.0 generic collection using library, trying to push some objects over the wire via remoting. Works great, well, if you use the BinaryFormatter that is. Try using the SoapFormatter, and you're in for a big surprise: Soap Serializer does not support serializing Generic Types.
I couldn't believe my eyes. So of course, I googled and I ran into this thread on forums.microsoft.com. Let me quote what an MS employee posted there:
[...]We have decided not to invest in any significant new feature work for the SoapFormatter in Whidbey.[...]
And another employee:
the SoapFormatter is and will continue to become less important as time passes.
If you need an Xml projection of a CLR type, the XmlSerializer is an excellent option until Indigo ships.
I can't draw any other conclusion than: "Starting from .NET 2.0, stay away from the SoapFormatter, or you'll burn your hands sooner or later". This decision of Microsoft is very unfortunate, to put it nicely. The reason for that is that if you write code which should be remotable, you have to implement ISerializable on every class with generic serializable members and after you've done so, that implementation has to migrate any generic type first to a non-generic type (Hashtable, Arraylist) before serialization and in the case of deserialization, it has to migrate the data back to generic types. This, well, sucks big time because the BinaryFormatter can handle generic types just fine, so if the developer uses the objects with a BinaryFormatter, the serialization is unnecessarily slower due to the conversion, left alone the extra work of implementing ISerializable on every class with generic typed members.
The alternative is of course to simply not use SoapFormatter when using .NET 2.0 code. I simply can't understand why Microsoft didn't update SoapFormatter for usage with Generic types. It's not as if Indigo, or what's its name today, is available at the moment. So, if you're doing remoting, do yourself a favor: already start using the BinaryFormatter, so you won't run into this problem later on, or of course avoid Generic Types (yeah, like that's an alternative... )
If you're porting code from .NET 1.x to .NET 2.0, like I'm doing at the moment, and your .NET 1.x code uses Hashtables(), be aware of the following if you decide to migrate your Hashtables to Dictionary<TKey, TValue> variables.
In .NET 1.x, you'd do:
Hashtable myData = new Hashtable();
//... fill it
SomeType value = (SomeType)myData[key];
if(value==null)
{
// key not there, handle...
}
now, if you port this to .NET 2.0, you normally end up with this code:
Dictionary<KeyType, SomeType> myData = new Dictionary<KeyType, SomeType>();
//... fill it
SomeType value = myData[key];
if(value==null)
{
// key not there, handle...
}
Though, this doesn't work. It compiles ok, but something changed in .NET 2.0: if key isn't found, you no longer get null back but you get a nice exception. So the code above should be reworked to:
Dictionary<KeyType, SomeType> myData = new Dictionary<KeyType, SomeType>();
//... fill it
SomeType value = null;
if(!myData.ContainsKey(key))
{
// key not there, handle...
}
else
{
value = myData[key];
}
The sad part is: often the code to port isn't small, and you first try to get it compiled. If you don't keep the above difference in mind, you'll probably have a lovely time fixing bugs after the tests have run. So you've been warned
UPDATE: Wilco Bauwer posted in the comments another work-around, which is even more preferable: TryGetValue(). Sometimes you overlook the most obvious things! 
Reworking my example above, it will look like:
Dictionary<KeyType, SomeType> myData = new Dictionary<KeyType, SomeType>();
//... fill it
SomeType value = null;
if(!myData.TryGetValue(key, out value))
{
// key not there, handle...
}
Right before the launch of Visual Studio.NET 2005 I reported about a hang of the C# IDE while you were typing code. The hotfix is now available through Microsoft's PSS, and the KB article can be found under this link:
http://support.microsoft.com/default.aspx?scid=kb;en-us;910832
This isn't a publically available fix, you have to call PSS to obtain it. Personally I don't understand why Microsoft still tortures its customers to go through this overhead to obtain a fix: the customer first has to explain everything to the PSS employee, then the customer will receive a URL, then the customer has to go to that URL to download the hotfix. Why not cut out the hassle with calling PSS, explaining what's the problem and let the customer download the darn hotfix by themselves? We're all adults here, the customer can perfectly decide what to do and what not to do, IMHO. Because, the time the customer spends on this is often not 'free' and often the time period between initial finding the hotfix KB article and actually obtaining the hotfix .exe is quite long, especially when you're outside the US.
Now, before you start babbling about legal issues and other irrelevant nonsense, take a moment and go to http://download.micrsoft.com and type in 'Fix' and just select 'All' products. You would expect 0 results, right? No, you get a lot of results back. A lot of them are intermediate releases, non-security related fixes. Why are those released to the public and others aren't?
I mean: who decides if a fix should become a public fix or a fix to obtain through PSS? It's not as if a customer is denied to obtain this particular fix, as it's a bug, a fix is there, so no support calls are charged, there's just overhead: the customer has to spend precious time waiting for the fix for no reason at all, and PSS has to perform actions which are completely irrelevant: the customer will get the fix anyway.
I also wonder how much progress Microsoft has made with that central place where known issues of VS.NET 2005/.NET 2.0 are listed...
More Posts