September 2003 - Posts
Miguel has interesting comments about Java and .NET.
We all know DataSets are not good when you want to serialize them, because they always are serialized as XML + the XML-Schema even if you are using a binary formatter. This implies you get a big serialization payload and bad serialization performance each time you transfer a DataSet using Remoting or when you store a DataSet in a ASP.NET session variable, just to mention two common scenarios.
I decided to check if that could be fixed, so we could give more value added to our DeKlarit customers, and it was really easy to fix.
I was able to reduce serialization times to about a 13%, deserialization times to about a 20% and serialization size about a 15%, when using the binary formatter.
More interesting, depending on the number of rows that were serialized, these numbers are similar to the ones you get when serializing a plain object array (i.e. Customer[]), and sometimes even better!
Read the details here.
It's quite usual to hear "the problem with code generators is that if you change the code they generate, you lose the changes the next time you generate the code".
I would say "the problem with code generator users is that they want to change the generated code" ;).
Code generators that let you modify the generated code and keep the changes the next time you regenerate are usually quite fragile. This is the best example:
#region Windows Form Designer generated code
/// <summary>
/// Required method for Designer support - do not modify
/// the contents of this method with the code editor.
/// </summary>
private void InitializeComponent()
{
this.components = new System.ComponentModel.Container();
this.Size = new System.Drawing.Size(300,300);
this.Text = "Form1";
}
#endregion
We all know what happens when you start messing up with the code inside InitializeComponent() ;)
But there is a more important reason for not to change the generated code. What happens if I want to refactor my code generator to take advantage of new features of the framework (i.e. Generics)? It will be impossible to keep the changes, so we lose one of the big advantages of code generation that is being able to completely change the way it generates code in the future.
There are a couple of ways to change the behavior of a code generator without changing the code. The best one is to improve the code generator metadata, so it generates the code you want. The other option is to use composition or inheritance to modify the behavior of the generated class. This last one adds more coupling to the generated code than the first one, but as it's using the public signature of the generated component, it's pretty safe.
I'm really happy to hear that see Don Box keeps talking about that they need to reduce surface area of the .NET framework.
If Don, whose audience has always been the core developer, thinks they needs to make things easier to the novice developer, then something interesting is happening ;)
If they make it right, then .NET will win.
When we design software we usually build abstractions on top of other abstractions that we or someone else built.
When we build a new abstraction we have to keep in mind that the goal of any abstraction should be to let the user of the abstraction express something more concrete than without using it. We need to build abstractions to make our app fit the way the user 'mental model'.
For example, if I'm using an email component library, I write:
mail.From = aaguiar@aaguiar.com;
mail.Send();
I'm using an abstraction someone built, but I'm really not doing anything abstract, I'm being as concrete as I can be.
When I say we need to build better tools for the corporate developer, I mean that we don't want to provide him ways to build better abstractions. We need to provide the corporate developers ways to express their knowledge in the most concrete way possible.
Both .NET and Java want to win the heart of the 'corporate developer' (aka known as the VB6/Powerbuilder/OracleTools/VisualFoxpro developer). If there is a winner in the .NET/Java war, it will be the one who captures that market.
The point is that the corporate developer really does not care about .NET and Java. They want to get their work done, and most of them were getting their work done with their previous tools. They don't like to learn new technologies a lot. They even don't like coding a lot.
What these developers need is to build applications with the least amount of programming possible.
Today, the amount of code we have to write to get our work done in .NET is less than in Java, but it's still a lot. That will improve with the upcoming releases of the .NET framework, but it will be still a lot.
This is from a Don Box post:
"Honestly, reducing surface area is important to all developers (not just VB devs) and keeping things manageable will be one of the biggest technical challenges we face over the next five years."
In VB6 there were a lot of 'black boxes', and in .NET one of the design goals was to not to have them. So they built a good core framework and then started to build things on top of it. This was the 'right' way to do it. The problem is that we need to wait until Microsoft builds all the abstractions on top of the framework so they can make the corporate developer's task as easy as it should be.
Even if it seems the right way, it is a very long way. I think they need to start from the other side. Start building the top black boxes, which is much easier than building white ones, and sometime they could eventually open those black boxes. The technical quality of the solution will be worse, but it will help them to win the war.
There are a lot of ISVs trying to do this kind of things. CASE tools were one failed example. Now we have MDA tools, rule engines, etc. Tools where you have an 'executable design' using code generation or any other technique. The problem is the big guys (Sun, IBM, MS) never embraced one, so these tools usually have a relatively small number of users, and are not an important force to push the platform.
These are the total number of votes for all of their magazines:
.NET : 2638
Java : 13784
ColdFusion : 2760
WebServices : 5484
LinuxWorld : 796
The .NET vs Java difference is really big, and it probably means something ;). At least it puts some recent claims about .NET vs Java adoption in doubt.
Two more JSRs from the 'let's catch .NET' chapter:
JSR-000114 JDBC Rowset Implementations (aka DataSets for Java)
JSR 173 Streaming API for XML (aka XMLReader for Java)
More Posts