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."

Comments

Re:Wow, that's a big fat ASS^H^HPI

[nmb3000]

Any third-rate engineer or researcher can increase complexity; but it takes a certain flair of real insight to make things simple. -E. F. Schumacher

And a stripped-down non-existent API is a way to make things simple? Pretty much all modern languages have very detailed and complete API/framework, and all for the same reason: Why should a programmer have to re-write common routines and data structures for every program? Why bother using a big external library (which can just becomes another dependency) when it can be built into the runtime?

Horse and buggy carriages were much simpler than complex modern cars. We should probably go back to those.

Re:.NET is OOP gone stupid.

[Watson Ladd]

I just use parametric types. To make a sortable data type I define the type and a comparison, and my sort function uses any comparator passed to it. If I want to sort backwards one time, no problem. I just use lambda to make a quick reversed comparison operator. Want to access a different file encoding? No problem, just supply the functions as an argument. Threadsafe? I have immutable variables, so nothing bad can happen. What language do I use? Standard ML.

I agree

[grahamsz]

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.

Re:Answer: No Thanks

[Anonymous Coward]

Let me get this straight.

1. You argue that .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.

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 .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?

We await your answers, mighty Naughty Bob.

Re:Answer: No Thanks

[diamondmagic]

Did you bother clicking the link to "Mono?" It links to this URL:
http://en.wikipedia.org/wiki/Infectious_mononucleosis

Re:.NET is OOP gone stupid.

[Anonymous Coward]

The .NET framework in almost all parts is designed to be a "multi-level API", with simple high-level types built on top of more detailed lower-level API's.

Basically when deciding between flexibility and simplicity the .NET framework choses "both". This increases the apparent complexity of the framework when measured by the number of types and methods, but doesn't make the framework more difficult for the average programmer.

I really appreciate, for instance, having an HTTP library that provides access to protocol details when necessary, and has a super-simple wrapper for common scenarios. By contrast in Java, I often had to use Apache's HTTP library or use raw sockets.

Re:.NET is OOP gone stupid.

[batkiwi]

In .NET:

byte[] fileContents = System.IO.File.ReadAllBytes("myBinary.blah");
string fileText = System.IO.File.ReadAllText("myText.txt");

That's if you want to read it all in as quickly as possible (no buffering). What's tough about that?

Obviously if you need buffering you have to do some REALLY complex work:

while (s.Position < s.Length)
{ //process your stream... read one byte at a time out of it
    int oneLittleByte = s.ReadByte(); //or chunk 50 bytes out of it, don't hardcode like this kids!
    byte[] someBytes = new byte[50];
    int bytesRead = s.Read(someBytes, s.Position, someBytes.Length);
}

That is both tough and complex. I don't know how I can cope.

Re:.NET is OOP gone stupid.

[jesterzog]

Although they supposedly give more flexibility, something as essential as reading from and writing to a file becomes a hassle with .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.

I've been writing code in a Windows shop using .NET for a couple of years now. I like coding in C at times and still do for some things, but when I'm writing .NET apps I don't really have much of an issue with it. That's what documentation is for, and MSDN's pretty good and up to date. Personally I find the following a lot easier to use than something like fopen():

using(Stream fs = new FileStream("somefile.txt")) { // Do stuff... }

It opens the file, lets you do stuff, and makes absolutely sure it's closed when you're finished irrespective of what happens. When I've tried to write something similar in C it's more direct, but there's a lot more need to think about error conditions rather than what I'm actually trying to do.

I agree with you that sometimes it gets a bit confusing discerning between all the different helper and wrapper classes, but I've usually found there are good reasons for them once I get into using them, and it for me it does make it easier to manage all kinds of potential input without having to care too much. Trying to keep track of all the exceptions that might potentially pop up from within all the wrappers is a real pain, though.

Re:.NET is OOP gone stupid.

[Dilly Bar]

You can stream files as well in .NET. I wanted to point out that .NET typically has a level of API that makes simple scenarios easy and more complex scenarios possible (as easy as possible :-)) as in this case.

Re:Wow, that's a big fat ASS^H^HPI

[AKAImBatman]

Have a chip on your shoulder much? Most of what you're saying is simply incorrect. e.g. Java does not have half-a-dozen containers. Yes, the switch from the STL-inspired Vector to the more Java-ish ArrayList was annoying. Same with HashTable to HashMap. But beyond that, all those different containers you think you see are actually interfaces for wiring up complex functionality. Either that or completely different data structures with different performance characteristics. (Remember your CompSci courses?) The Java Collections package (which seems to be the only thing in Java you're remotely familiar with) provides enough functionality to write a complete database engine. Which, as a matter of fact, has been done quite a few times. (Sorry, ran out of words to link. Doh! Still more. Ah, to hell with it.)

The rest of the Java API is also not bloat. There are libraries for printing, crytography, sound, graphics, DOM, file I/O, text parsing, text formatting, text display, mathematics, directory interfaces (e.g. LDAP), distributed object systems, reflection, security, SQL database interface, logging, cross-platform preferences, regular expressions, ZIP/GZip support, accessibility, networking, the compiler, scripting engines, etc., etc., etc. Very little of the core API is redundant, with most of the (few!) redundancies being a result of the early days of Java before they moved away from the C++ style objects.

Nearly all of the post-1.0 APIs were done correctly the first time. Which means that the core Java API is actually quite slim for the amount of functionality it provides. And even then, there is a HUGE number of official expansion APIs for mail, multimedia codecs, network request/response handlers (e.g. servlets), 3D graphics, 3D sound, text-to-speech, speech recognition, telephony, SOAP, REST, USB, Bluetooth, scientific units, cross-platform desktop integration, Instant Messaging, P2P, and quite a bit more. And that's just the official JSR-approved expansions! The OSS and (bleh) commercial worlds are full of unofficial libraries to deal with nearly any problem you can come up with.

If you want bloat, stop looking at Java. Try compiling a few Linux apps sometime and tell me how many redundant libraries you come across. If you know what they all do (which is a miracle in of itself), compiling just ONE of those programs is enough to make a person blush with embarrassment. Not to mention that when a platform IS solidified (e.g. GNOME), it suffers from versionitis. (i.e. The constant need to upgrade your version of the libraries because this latest program no longer targets the version you just compiled. Or even worse, it requires a specific minor release, thus requiring you to have multiple minor releases of the library compiled and installed.) I won't even go into Microsoft's practice of inventing a new API for the same technology over, and over, and over again. (ODBC, DAO, ADO, JET, anyone?)

Now I happen to think that a lot of the choice that Linux offers is good. But don't point fingers at other platforms when there are more than enough examples of far worse situations close to home.

Re:Web developers?

[_Shad0w_]

.NET is the name of the framework, not the language. The languages are called C#, VB.NET, J# and F#.

J# is pretty much dead, no serious coder works in VB.NET if they have a choice - it's the language everyone takes the piss out of at MS-centric developer conferences - and F# is the OCaml like functional language which isn't actually part of the VS collection yet, but is available as a separate download. Which leaves you with C#, which is what most people work in.

Although I agree with the fact that the name was a pretty dumb choice, but we're stuck with it now. Still doesn't make the framework itself bad. It's actually very nice to work with.

.NET warms the cockles of my heart. Mostly by putting money in my bank account at the end of each month.

Re:Wow, that's a big fat ASS^H^HPI

[TLLOTS]

Just a small correction. PHP will actually get namespaces in 5.3 which is due out soon-ish I believe.