if henry could see us now ...

I have been working with C#/.NET for a couple of years now, and have come to really like what Microsoft has accomplished with the platform, even when compared with JAVA. Some colleagues of mine would choke up a lung to hear me say this now. Don't get me wrong, I was a JAVA developer, promoter and evangelist long before I got involved with C#, but there are some things I like more about C#, even if it is only syntactic sugar or based on a subjective esthetic judgement. Take Attributes, for example. You can use interfaces to do the same thing in other languages like JAVA, but it's harder to get the same code re-use and you typically have to write more code to get similar results. I also agree with the approach of designing the features of a language to limit behavior by default -- things are private until made public, and so forth. That is a good thing. However, since most things proceed along the path of least resistance, better development tools are those that make it easier to do the right thing in the first place. So, I ask this -- when would you not want a class to be imbued with the [Serializable] attribute? Just about every object will need to be passed over the wire if it ends up part of a non-trivial application at some point in its lifetime. Leave it out by mistake and you catch it sometime later in the debugger, but that costs time. It's actually hard to enumerate cases where you definitively know that an object will never need to be serialized. For this reason some languages make a special case of [Serializable] and make that the default. You should expect to work to explicitly disable it, since that's the exception, not the rule. It's not a big deal, just a simple productivity issue. If Henry Ford (a master at optimizing worker productivity) was monitoring software developers he would have cut out the need to type these fourteen [Serializable] characters on the assembly line day one and made every part come with the right pieces before it hit his factory yard.