Linked by Eugenia Loli-Queru on Wed 20th Feb 2002 18:45 UTC
A lot of people have trouble understanding what .NET really is and what its goals are. Mostly because Microsoft has done a good job of confusing everybody using terms that are not self-explanatory or with terms that mean more that one thing. This editorial will present my thoughts on .NET, what it really is, what its motivations and goals are, and why it is the next "big thing." Should we embrace it or fear it? Both, I daresay.
Permalink for comment
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Thank you, Roger
Code re-use!! This is exactly the problem with all of this stuff. I know there is all this talk about how it will make development simpler, but how is it simpler if I as a developer am now expected to know how to interface with ten thousand mismatched libraries from around the world? So you can trade objects and methods around; big deal. Will this make my life better as a developer? I tend to doubt it. Sounds more like a developer's nightmare. How do you know exactly what that remote class is going to do to your application, or when it will be changed? Developers: expect a lot more late-night phone calls from clients about this or that feature suddenly bieng broken. (It was working this morning, what did you do?)
Evolution?:
Object-Oriented programming was supposed to make development simpler: all you had to do was know the API of a certain class and you could interact with it, without knowing what goes on inside. But honestly, once you start really working with this, it seems like you can take one of two roads: 1) yes, use O-O stuff, but spend the time to look inside every class you work with, so you can optimize usage, and know exactly what is going on, or 2) Just use 'what-you-understand' of each class, and extend the classes with all kinds of garbage, or load more different classes than you really need, because you only understand this or that little piece of each. (I seem to see that second scenario happening a lot with Java).
So, in the end, with O-O you don't see a true revolution in simplicity. In fact, sometimes it's the opposite. To write nice, tight code, you still have to practice most of the same things you did with procedural code, otherwise, it becomes a mess. I predict this will be even worse with .NET!! There will be a proliferation of garbage code such as the world has never seen. One kind of developer will write applications which assemble collections of mismatched crap from all over the world, hoping that 'code reuse' is all they need, with a wizard-driven thin few lines of their own code to tie these together, while other developers will pretty much work the same way as always: they will experiment with the new things they can do with .NET, and will sparingly apply them where they make sense.
I intend to be the latter. This will not require a carte-blanche giving in to Microsoft dominance.
I know the businesspeople involved are drooling over the idea of a "plug-n-play" universe of code, which will turn applications into rental cash-registers instead of shrink-wrapped disks which get traded around by friends. But the plug-n-play aspect promises to make Quality Assurance a nightmare. Oh, and welcome to a whole new world of viruses that can just "plug in" to that place where your application is expecting a remote module.
And why the confusion: is it evolution or revolution? The two are not the same. This will be a revolution in operating systems, while .NET is merely an evolutionary step? No, the operating system will not become just an incidental. It will just be sharing mind-space with one more level between the bare hardware and the user.
As far as the evolutionary part, most of those things are possible RIGHT NOW, without bothering to 'give in' to Microsoft's vision.
"Web Services eliminate the huge IT workload that needs to be carried out to make a company or a number of companies exchange data via databases. Services can be summed up as Remote Procedure Calls which can be invoked by posting a blob of XML over HTTP."
Duh... and it requires the fatherly hand of .NET to accomplish this? NO. XML-RPC, SOAP, can be done without giving any mindshare to Microsoft.
And finally... Oh yes, it's great that now Word software will be able to load a function from just about any other piece of software on the planet. How much functionality do we need our software to have? Most users don't even use 1% of what their existing software is capable of already. If anything, we should be reducing the feature set of software, and making it run better and more securely.
The real problem that .NET will open up is this: we will still have the same brains, with the same personal bandwidth limitations. Users--now your software can do anything--great, but you still don't know what most of the features are, or what they can do, or why I would want them. Developers-- you will now be able to interface with 2 million modules. Great, now you only have to dig through 400 million pages of specifications, if you want to actually understand what your software is doing.