Slashdot Mirror
Visualizing the .NET Framework
eldavojohn writes "If you're a Web developer, you should check out a quick post about the number of types, methods, & fields in the .NET framework. This was done using NDepend. The numbers are quite large — e.g. 39,509 types. The blogger went on to generate tree maps and a dependency matrix."
Before you impugn Microsoft with your short-sided emotional appeals against the sheer number of classes, use a hint of logic and realize that since MS copied Java shamelessly and ruthlessly (improving on some debacles in the Java classes, such as the crap IO classes that had to be redone from scratch), you'd be blasting Java, KDE, Python, and most any other class library as well.
.NET class library beats them all easily. It is obvious that the designers did their homework and stole from each library what worked well, while dropping what didn't. If they were smart they'd take Java's excellent concurrency constructs such as the BlockingQueue and put them in (they may already have, I don't program much in .NET lately). Most of my beefs with the class library are the fact that it is huge (footprint size), and I don't agree with some of the modeling. But that is minor.
Look, in a class library that purports to help most everyone, there's going to be an awful lot of code. Class library implies that classes are used to organize the abstractions provided by the library. Proper OO design favors designing more types with smaller number of features rather than God-objects that do many things. Fine-grained objects are simpler to unit test and are much easier to reuse. The downside is the propagation of types and the verbosity level of the code generally goes up. But that is a fair trade-off in my opinion, since the most important work on the code happens in the maintenance phase, when someone else can come along and at least get a vague idea of what is going on.
I've used the class libraries in Java, KDE, MFC, and Python, and the
There's a reason Miguel wanted to make this happen on Linux. It is close to making programming fun again, instead of squinting at hyper-abbreviated function names like sprintf and mucking around with idiotic string representations such as C's.
Hallelujah, brother!
What bugs the snot out of me is that a lot of that stuff is documented really well, but only on developers' blogs. What the hell kind of insulting documentation non-strategy is that? And of course, there's no cross-referencing between msdn and "the blogosphere." So you get to churn away at a search engine until you find a blog entry that's kind of addressing what you want to know.
That said, I do like a lot of stuff about C#. Delegates, for example rank high on that list. And C# 3.5 offers some pretty cool new stuff as well. I likey the lambda expressions, inferred typing, and LINQ.
But the documentation does make me cry at night, sometimes. Sometimes.
I kinda disagree. .net and Java are much bigger in scope.
.net provide standard interfaces and hooks to link your own code. Want arrays of your new data type to have automatic sorting capabilities? just implement IComparable. A little bit of work would let your new collection class bind automatically to Winforms' data grid control. And many more examples.
.net's huge libraries, you get a situation like C++ where there are half a dozen pseudo-standard libraries for encryption, networking, GUI and stuff. You have projects with incompatible dependencies and a lot of wasted effort writing, debugging and maintaining all those libraries. Microsoft may have a lot of problems with their products but .net is one of the most well designed things they've produced.
.net inherited a lot of this from Java, but they improved on it. Java, in turn, adapted/improved the Smalltalk libraries that have helped pave the way for the "language with everything included" paradigm.
To talk about your example: fopen( ) might be nice and simple, but the capabilities provided by
You can use them to read and write files with different encodings, you can treat a lot of other things as files, and combined with formatters you could serialize your data to binary files or XML almost without writing code.
Even more, the different classes are orthogonal, so you can mix and match different encodings, formattings, and file operations without the combinatoric explosion of having a separate function for every possible operation. It's an elegant design in my opinion.
Furthermore, the libraries of Java and
If you remove
To be fair,
Nope. Einstein said it best, I think:
It's a given that new features will increase complexity. (Which, surprisingly, is not always true. But stick with me for a moment.) The key is to increase the complexity only as much as necessary. If you increase the complexity any farther, you have failed.
I can't count how many times I have seen code that is overly complex. e.g. Someone piled up layer upon redundant layer of code, hoping to get simplicity out of each one. Instead, they create more maintenance, more points of failure, and more bugs. Probably one of the most egregious examples was a company that wanted me to use a go-between piece of software on another server to make a real-time request for XML. They had a lot of weak excuses for this decision, not one of which held water. After peeling back the layers of nonsense, I found out that the reason why they wanted it used is because they had already sunk $10,000 into it.
While not all examples I've seen are motivated by money or CYA, I have certainly seen a lot of examples that were motivated by blind adherence to company standards or existing technologies. Never mind that this particular module doesn't need any of the features of Struts, the company policy says use it, so we use it. Never mind that ADO isn't a good API. We have it, so we should wrap it. Never mind that we could just plug in a lib to do the secure transfer directly, we need to Rube Goldberg it through 5 different machines, protocols, and scripts written in 7 different languages!
There's a reason why engineers harp on the KISS principle. KISS is all about engineering a solution that will last for a long time to come. A solution that can be understood by others, maintained, is reliable, and exceeds the specs wherever reasonable. As Einstein said, make it as simple as possible and no simpler.
Javascript + Nintendo DSi = DSiCade
Let me get this straight.
.NET lacks "internal logic" and "simplicity" after pointing to the article. Never mind that the article merely only reported statistics about the .NET framework instead of asserting that it, does, in fact, support your arguments. So this claim remains baseless, unless you're trying to say lots of types somehow means it lacks internal logic and simplicity. We are waiting for your keen insight on this point.
.NET that runs on non-MS platforms and is compatible at the bytecode level. What sort of examination have you done on the source code of it to determine that it has "simplicity" and "internal logic?" How does it meet those goals, yet have the same external API of .NET? How does it not suffer from "bloatedness" if it has at least as many publically available classes as .NET?
1. You argue that
2. Another user questions your assumption rather innocently.
3. You imply that they did not read the article (which is rather hilarious considering the previous point) and then, to add the icing to the cake, indicate you'd much rather work on Mono. Mono is a version of
We await your answers, mighty Naughty Bob.
.NET and Java are both prime examples of object-oriented programming gone stupid. Their class libraries have become so utterly huge that it becomes damn near impossible for an individual developer to suitably grasp anything more than a small portion of them. Interestingly enough, an individual developer does not need to grasp anything more than a small portion of them. An individual developer needs to know the basics of the core class library and whatever else he needs to get his job done. The vastness of the ASP.NET (or whatever) libraries is not an impediment to one who does not use them.Also, there is documentation, and Intellisense (freely available, now), and a naming convention that actually makes sense after a while. F1 isn't that hard to press. Although they supposedly give more flexibility, something as essential as reading from and writing to a file becomes a hassle with
Of course, there are more complicated examples, but that's usually because they're either years out of date (.NET 1.0), or just plain doing more. OO was supposed to solve the problems of writing applications in languages like C, Pascal and Fortran. All it has done is brought in a new level of complexity that results in monstrosities like the Java and
As for plain C applications being more efficient, well, what exactly does that have to do with what methods are named and what namespaces they do (or do not) reside in? Second, that's not the point. Getting a quick GUI app up and running in a hurry is more what you'd use
Yes, C is valuable and it's still pretty much the best choice for writing tight, high-performance loops that do lots of pointer-manipulating, bit-twiddling evil - that's what I and every other sane programmer I know uses it for. But it's also a damn waste of my time to be using it to write Win32 GUIs for art tools. My time is more valuable than a few CPU cycles.
It is this level of function (mis)use that makes me cringe.
... not all range checking will use the same ranges ... so then some bright spark will create Range2, Range3, Range4 objects with different ranges in each one. You see how this function does nothing for either readability or speed of debugging, but simply hides information that a programmer NEEDS to know in the context of the line he is looking at ?
So instead of being able to see both the variable AND the range it is being tested against IN THE SAME LINE, I now have to go trawling back through the code looking for the place where you created the Range object to find the low and high boundaries of it.
So yet more jumping all over the place hunting for stuff, when the original version was completely fit for purpose, clear, and most importantly, IN ONE BLOODY PLACE.
Of course, it get's even "better"
You can keep your Range object thanks.
I have mod points, but this deserves about 10 of them so I reply in solidarity. .net programming work. It's ironic that their worst enemy is essential to working with their system.
The msdn docs are not enough, there are too many useless empty API pages. If it weren't for Google I couldn't do any
Often the most useful documentation and samples are scattered over a zillion forums (all requiring logins!), newsgroups, blogs, 3rd party books, etc.
This has always been the case with microsoft development libraries, but it's getting worse because early on (internet time) it was mostly just usenet.
You seem to be assuming that there would be a hard coded range. The allowable range may be defined in a database or elsewhere. Checking against the same range may occur in many different places, so you certainly would not want to have the range hard-coded in every routine you need to do such checking.
Imagine that the Date range object was intended to check the date of birth of new employees (e.g. You want prevent mistakes like they were born 200 years ago or 50 years in the future). If you are smart you will have created some kind of Employee class, and this Date Range checking object could just be a static variable of the class itself. It would be pretty easy to see where it was set.
So yet more jumping all over the place hunting for stuff, when the original version was completely fit for purpose, clear, and most importantly, IN ONE BLOODY PLACE.
The whole point is to reduce the unnecessary repetition of logic. Imagine if you wanted to do something more complex like check if one date range was contained within another. Suddenly you start repeating quite a lot of logic without a Range object.
Of course, it get's even "better"
Of course there will be different ranges. What does that have to do with anything? If anyone names variables "Range1, Range2" etc, they need some quick re-education.
You see how this function does nothing for either readability or speed of debugging, but simply hides information that a programmer NEEDS to know in the context of the line he is looking at ?
It's interesting that you think information is being hidden. This would only be the case if you compare it to the situation of hard coding things everywhere, which is generally a very bad practice. The information in a Range object is no more hidden that the case where your limits are two separate variables called "StartDate" and "EndDate" (Variables which might be initialized when the application first starts). What is really being hidden is logic. That's what object oriented programming is really all about, i.e. trying to abstract away complexity into new types.
You can keep your Range object thanks.
It's not really mine. Martin Fowler wrote about it in Analysis Patterns, although I'm quite sure it was being used long before it occurred to him.
I realize that you're one of those "Anything but Microsoft at any cost" people, but I have some news for you.
.NET isn't really any worse than when I was dealing with it in C, C++, or any other language that I've used.
1) You don't have to memorize what is in every namespace in *any* language. You just have to have a good enough overview of them to know where to look effectively for something you need. Spending all of your time trying to memorize everything in libraries is a waste of time and usually only done by undergads who think that they know it all.
2) These are just toys to keep you occupied
I hate to break it to you, but there is a great deal of business that is done on Microsoft software. There are a number of reasons for that (admittedly, not all of them are good reasons). One of them is that MS has done something Linux and the others haven't - they make software that makes it fairly simple for most businesses and people to do 80% of what they need to easily. In addition, needs which are not met by MS itself, and a number of needs which are, are covered by various 3rd parties.
As for "toys to keep you occupied", I'm one heck of a lot more productive using C# in Visual Studio for most of the things that I have to do than I was using C or C++ in xemacs. C and C++ are fine tools for doing things closer to the metal. Most applications don't need that.
In addition, dealing with deprecation in
You need to learn to use the right tools for the job. Instead, you want to bash tools on an idealogical basis. It's a sign that you really need to grow up.
Everything I need to know I learned by killing smart people and eating their brains.