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."
[b.belong('us') for b in bases if b.owner() == 'you']
.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.
.NET or Java. It's easy to get lost in whether we need a FileInputStream, or whether we should wrap a FileInputReader in a TextInputBuffer, and so forth. Give me fopen() any day.
.NET standard class libraries. Meanwhile, the POSIX API offers just as much flexibility, but is far easier to work with. Not to mention that programs using it are far more efficient.
Although they supposedly give more flexibility, something as essential as reading from and writing to a file becomes a hassle with
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
It doesn't suck because it's made by MS or ripped off from something. It sucks because the documentation is piss-poor. And there isn't a single working (i.e. cut-and-paste) example for a single API (someone told me they break them on purpose so that newbies don't cut-paste themselves into security holes without understanding exactly how the thing works, but hell!)
I noticed the same thing when Apple released their Cocoa framework (with over half of help pages saying "TODO: descrition, example"). Some Quicktime documentation is still that way today!
How anyone expects the undocumented API stuff to be useful is beyond me.
Obama likes poor people so much, he wants to make more of them.
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.
If you're a Web developer, you should ignore .NET and use something much less bloated.
There, fixed that for you.
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
The comparison to the human genome is interesting. The genome contains about 3 billion base pairs and 30,000 coding genes. As best I can see, .NET is quite a bit bigger: The closest thing to a gene is a method (an object that can be used, or not used, and which does something). The genome has 30,000 and .NET has 384,000. So even if it takes 10 methods to do what one gene does, they are equivalent.
.NET has 8,000,000 instructions. Given the roughness of the comparison, this is pretty close.
.NET :))
It takes 3 base pairs to code for a single protein, perhaps the closest we can come to an instruction. Each gene has an average of 3,000 base pairs, equivalent to 1,000 instructions. So we are looking at 30,000 genes x 1,000 instructions/gene or about 30,000,000 instructions in the genome.
The point here is that we are creating programs that are roughly equal in complexity to the human genome. If we were better programers, then perhaps we'd have come up with intelligent design.
Finally, it's worth noting that the functions are unknown for over 50% of discovered genes. It may be about the same for
The biggest plus to working in Java is that the documentation Sun provide is comprehensive (and once you figure your way around it) easy to access.
Microsoft is getting better but, for a framework that's quite clearly a java rip-off, they could have ripped its documentation style too.
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.
Did you bother clicking the link to "Mono?" It links to this URL:
http://en.wikipedia.org/wiki/Infectious_mononucleosis
Wonder what the public key field is for?
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.
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.