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

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

[NewbieProgrammerMan]

Seeing that I have no personal experience with .Net, and seeing that this is Slashdot, I feel totally qualified to poke fun at its stupendous complexity with a quote:

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

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:Wow, that's a big fat ASS^H^HPI

[PPH]

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

Rube Goldberg is alive and working for Microsoft.

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

[CastrTroy]

Yeah, let's compare .Net to PHP. .Net has a very extensive API. PHP also has a very extensive framework. The .Net framework was very well thought out and is very well organized. The PHP framework is cobbled together piece-meal, with everything in the same namespace (Yes, I'm aware that it still doesn't have namespaces, and won't until PHP6 is out, but that's yet another disadvantage of PHP), and separate functions for each database they support, where all are very similarly named, but not exactly the same.

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

[IdeaMan]

"Any idiot can make something complicated. It takes a genius to make something simple" - F.O. Stanley

Say It!

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

[AKAImBatman]

And a stripped-down non-existent API is a way to make things simple?

Nope. Einstein said it best, I think:

"Everything should be made as simple as possible, but not simpler."

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.

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

[MrSteveSD]

I'm not saying that .NET isn't too complex, but having a large number of types does not necessarily increase complexity. In fact having less types often leads to more complexity.

Creating a new type abstracts away complexity and makes code easier to read. For example, you will often find that business software does a lot of comparing of dates. e.g. Checking whether a date is within a given range. More often than not you will find that programmers have just written things like...

If (EnteredDate >= StartDate) and (EnteredDate <= EndDate)
{
//Do stuff
}
else
{
//Tell the user they have entered an invalid date.
}

The logic of checking that dates are in a range is repeated all over the place and the more you have to type, the more likely it is that you will make mistakes. This is where adding a new type, a "Range" type will help. With a Range type you can just say something like...

If (AllowedRange.Contains(EnteredDate))
//blah blah

So adding a Range class actually reduces complexity rather than increasing it. There are plenty of examples of this sort of thing. Imagine writing a car ordering system without having a Car class to abstract away details about cars. You could do it, but the code would probably be a lot more sprawling and complex.

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

[daveime]

It is this level of function (mis)use that makes me cringe.

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

You can keep your Range object thanks.

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

[Gutboy]

Yeah, because right clicking on the code and selecting "Go to definition" from the pop-up menu is so difficult and takes so long to do.

You don't need to know the ranges to know if your code will work. By creating a range tester, you can test that code once, and use it everywhere. You seem to be advocating recreating a range test everywhere you need it, adding to the complexity of your code, making it harder to read and maintain.

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

[iluvcapra]

Monorails are efficient and sparkly shiny but are almost universally inappropriate except for certain very limited transportation scenarios (airport people-movers, theme parks, etc). They require alot of service and very expensive infrastructure. The old honda just needs a road, works on your schedule and is comparatively inexpensive to maintain on a per capita basis.

Just sayin.

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

[MrSteveSD]

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.

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

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.

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

[daveime]

Yes, I mean don't get me wrong, there are a lot of useful types out there.

The danger is "type overload", the obsession with using types for every sundry purpose, i.e. the same logic the parent displayed when automatically thinking that using the Range type was helping him or anyone else.

Anything that abstracts out the conditional tests you are doing, so that one or even both halves of the tests have to be looked up elsewhere, is a bad thing. But you give someone too many types to play with, and he'll feel obliged to use them whenever the can.

Give a man a hammer, and watch him build. Give a man 100 hammers, and watch him hit himself on the thumb.

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

[Siberwulf]

My two bits:

With .NET 3.0/3.5, you can create something called an extension method.  This would probably be better than creating a range class, or even the inline code the grandparent of this used... Lets look!

public static class DateExtensions
{
     public static bool IsBetween(this DateTime tested, DateTime start, DateTime end)
     {
          return (tested >= start && tested <= end);
     }
}

That leads to a great implementation that doesn't hide any variables or values and still allows for easy readability

DateTime Signup = (Fetch some value here);

if(Signup.IsBetween(DateTime.Now.AddDays(-1), DateTime.Now)))
.......

You get the jist... I know thats picky, but you don't have to give up anything these days, if you try hard enough.

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

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

[sapphire wyvern]

Monorails?

Is that a port of a Ruby web application framework to an open-source reimplementation of a (possibly patent-encumbered) proprietary common language runtime?

No wonder it sucks compared to a Honda! ;)

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

[StrawberryFrog]

Monorails?

Is that a port of a Ruby web application framework to an open-source reimplementation of a (possibly patent-encumbered) proprietary common language runtime?

Yes, but that's a rather negative way of looking at it'

What, you thought you were joking?

.NET is OOP gone stupid.

[Anonymous Coward]

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

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.

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

Re:.NET is OOP gone stupid.

[NewbieProgrammerMan]

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.

The first time I saw what you (supposedly) have to do to read from a file in Java, it pegged my OMGWTF meter. I'm sure there's totally valid reasons for making such simple (and common) tasks so complicated, but apparently I'm not smart enough to understand them. IMHO it's one thing to have the complexity available if it's needed, but it's another to make me endure all that complexity if I don't need it.

Re:.NET is OOP gone stupid.

[free space]

I kinda disagree.
To talk about your example: fopen( ) might be nice and simple, but the capabilities provided by .net and Java are much bigger in scope.

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

If you remove .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.

To be fair, .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.

Re:.NET is OOP gone stupid.

[LaskoVortex]

The first time I saw what you (supposedly) have to do to read from a file in Java, it pegged my OMGWTF meter.

The idea is that you could encapsulate all that complexity inside a method inside a class--instantiate that class inside a class that has a "main()" and then put the whole thing in a module. You call all of that method with the correct parameters in an instance of another class created and instantiated the same way. You then jar it up as bytecode and then run it on the JVM--making sure your users are running the right versions of the JVM.

On second thought, OMGWTF?

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.

Re:.NET is OOP gone stupid.

[n dot l]

My experiences with Java were painful, but they are out of date, so I'm only going to talk about .NET, which I actually use in my day-to-day work because it's actually the best tool for many of the jobs I do.

.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 .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 Seriously? You actually found string[] lines = File.ReadAllLines( string path ); to be difficult? Or are you just talking out your ass?

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 .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. Yeah? I find typing File[dot] and hunting through the fairly short list of methods easier than remembering what the valid values were for fopen's mode parameter are, and whether there was a platform-specific one I should be using to get the file-locking behavior I want. And file.Read( ... ) is a lot neater than fread( ..., file ). You can go on all you want about how I'm being lazy, but I have more important things to commit to memory than API entry points and the quirks of their parameters (like, say, the overall structure of my app, or the problem it's being written to solve). YMMV, of course.

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 .NET for, something you can't even begin to do in C until you've sat around for a while thinking about fun things like memory management for shared resources.

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.

Re:.NET is OOP gone stupid.

[Dilly Bar]

You may be right, but try another example for .NET. Here are some .NET APIs you can use to read a file:

byte[] File.ReadAllBytes(string path)
string[] File.ReadAllLines(string path)
string FileReadAllText(string path)

and write to one:

File.WriteAllBytes(string path, byte[] bytes)
File.WriteAllLines(string path, string[] contents)
File.WriteAllText(string path, string contents)

Oh, and you can still compose types for more complex scenarios.

Full disclosure - I work for MS on Visual Studio

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:.NET is OOP gone stupid.

[giminy]

I started as a unix developer and switched recently to programming in windows, and use .NET quite a bit (it was the job that was available at the time ;-)). .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.

Give me fopen() any day.

There are a lot of things that I don't like about .NET (and particularly visual studio :)), but I think these arguments are invalid. fopen() is fine and good, but opening a file is a lot more complicated than just one posix function -- you have race conditions, concurrency issues, etc, if you're working on anything bigger than an academic project. You can develop your own libraries for safely doing things if you want, but going from job to job that becomes difficult legally (who owns the library?). And, of course, using some extra library to wrap your posix is kind of an argument against posix being the be-all-end-all uncomplicated solution.

Programmers often have areas of specialization, and not knowing more than a small portion of a gigantic library isn't necessarily a bad thing. I know the '.NET methodology' (and it is quite consistent) well enough that I could use other parts of the library. Quite frankly for my line of work I don't anticipate ever having to, as it's fairly niche.

Reid

Re:.NET is OOP gone stupid.

[Mongoose Disciple]

The idea of using a garbage collected language in a production environment for a large project is just plain silly, for the simple fact that garbage collection does not scale well and it introduces nondeterminism in your code - two things which are fundamentally opposed to the proper operation of a large software system.

Define does not scale well. I worked on an enterprise .NET project a year or two ago that managed a variety of transactions amounting to millions of dollars worth of business every day for a Fortune 100 company. It required a lot less hardware than you'd guess to run. Garbage collection wasn't a problem at all.

The reality is that for every 100 developers that think they can write non-trivial, say, C++ code that does not leak memory, there's probably around 1-2 that can actually do it. Those people are hard to find and generally not cheap. For most applications, it does not make economic sense to insist on having the "better" software engineers. It's just not cost effective to pay more expensive people to take more time to write the app in the majority of cases where garbage collection vs. manual memory management just doesn't matter.

Further: the union of the set of developers that can reliably write code with good memory management in a language like that, and the set of developers that can make good architecture decisions for an enterprise-level app approaches the empty set. That second set of skills is ultimately much more important to the success or failure of most sizeable applications.

You can hate on GC if you want, but the business world moved on more than a decade ago.

Re:.NET is OOP gone stupid.

[trezor]

You expect PHP programmers of all people to understand the benefits of a thorough and consistent API with standarized interfaces and object-nesting?

Good luck with that.

.NET

[The Aethereal]

.NET really is an amazing framework on which to build software. It just needs more OS support and I would use it for programming other than what I do for a living. All those types are there, but they will not be loaded in to memory unless your software needs them.

goatse

[Nimey]

That's what I first thought of for visualizing .NET.

The goggles, etc.

Re:This is News?

[megaditto]

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.

If more types is bad, then Java is equally bad.

[Anonymous Coward]

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.

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

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.

Re:The horror!

[Lux]

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.

Correction

[TheSpoom]

If you're a Web developer, you should ignore .NET and use something much less bloated.

There, fixed that for you.

I love every single one of those lines of code.

[rice_burners_suck]

I remember JLG (the fearless leader of BeOS fame) once saying something to the effect that Windows has five billion lines of code in it and that he "loves every single one of those lines." I also seem to recall Bill Gates once saying that IBM liked software to be measured in k-locs, while he debated that it should be measured by what it does. He said something that I don't quite remember, but the jist was, "why would we do something in thousands of lines of code if it could be done in just a few?" How ironic. Hmmm... if JLG's comment was made a decade ago, and our dance teacher has 30,000 monkeys adding a k-loc or two to those five billion lines every day, then there are now about 21,500,000,000 lines of code to love, which seems about right, given how many different "please wait" messages there are.

Compare it to the Human Genome

[wbean]

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.

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. .NET has 8,000,000 instructions. Given the roughness of the comparison, this is pretty close.

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 .NET :))

Re:Compare it to the Human Genome

[Ambiguous Coward]

The difference between genetic code and any human-invented language is the following: have you ever tried to debug a genome? It's friggin' ridiculous. No documentation at all.

-G

Re:Compare it to the Human Genome

[megaditto]

Debugging an existing genome is hard. Forking it is easy (and fun, esp. with multiple copies).

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:Web developers?

[DAldredge]

FTN "ASP.NET is a web application framework marketed by Microsoft that programmers can use to build dynamic web sites, web applications and web services. It is part of Microsoft's .NET platform and is the successor to Microsoft's Active Server Pages (ASP) technology. ASP.NET is built on the Common Language Runtime, allowing programmers to write ASP.NET code using any Microsoft .NET language."

Re:This is News?

[thePowerOfGrayskull]

I don't know which is worse - the thought that you're making this comment without having read any of the extensive, working examples on the msdn site; or that you did read them and somehow still feel this way. .Net has plenty of flaws, but lack of documentation ain't one of 'em.

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.

Familiar punchline

[spaceyhackerlady]

This reminds me of an old joke:

Q: A Marketing executive and an RIAA lawyer jump off the top of a 50 story building. Who hits the ground first?

A: Who the hell cares?

laura, not a fan of .NET

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

Portable.NET

[Paiev]

GNU really has their work cut out for them here with their DotGNU project to provide a free implementation. Good luck rms and co; if you try hard enough, you might be able to implement it all before Duke Nukem Forever is released.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:The horror!

[DeadlyBattleRobot]

I have mod points, but this deserves about 10 of them so I reply in solidarity.
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 .net programming work. It's ironic that their worst enemy is essential to working with their system.

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.

Re:This is News?

[marc.andrysco]

Working my first programming job, I had to take over a project written in C#.NET without any experience in the language. The goal was to communicate through an RS-232 port for sending and receiving some data, including text and numbers. Looking at the previous code, I saw some really long, confusing method of converting a string to ASCII and sending it through. I really took me by surprise since I had never seen anything like it, and I proceeded by looking through documentation. I was hoping for something real nice with fwrite, but I instead I had to jump through some hoops to figure it out. The problem wasn't so much finding documentation, but figuring out what methods I needed to use. I felt overwhelmed with the number of options that were so similar, some of which appeared like they would work but some contained a small caveat that prevented it from working.

On another note, I was perplexed when I used a switch structure and attempted to let the code fall through to another label. The compiler complained and forced me to write a goto statement (is there a more elegant want to do that?). A little later, a senior programmer was reviewing my code an criticized me harshly for putting in a goto where it should simply fall through. I literally had to show him that it would not compile otherwise in order for him to believe me.

Re:Answer: No Thanks

[RobertM1968]

I hate to say it, but whether "Naughty Bob" is normally a troll or not, I suspect he is correct.

MS has yet to show the type of design innovation that foregoes bloated code. Instead, when something doesnt work, or wasnt planned out correctly, they just add a bunch more stuff, then a bunch more, then a bunch more... then pat themselves on the back for the "innovation" which they equate with the number of things added.

Writing an extensible framework - and then extensions (or example extensions) would have been smarter, smaller, faster, and easier for true developers to implement.

The "Everything - including the kitchen sink" attitude does not work well in the computer world - the fact that their programs and apps are getting far more bloated, barely gain additional functionality (regardless of their claims) and getting far more resource hungry (while not adding significant functionality) is a perfect example - and one I think they are following with .Net

To me, it looks more like they are trying to prove that they can compete with, and surpass, all their .Net competition by sheer number of "features"/"capabilities" - which does not make it better. Their .Net framework already scaled horrendously to many types of implementations (like the Service/Customer tracking unit CompUSA used to use - as any of you who worked in Tech or Business Sales can attest to - from fond memories of running a rather simple report, going out for coffee and a quick breakfast, coming back, and still having 10 minutes to wait (of a total 30-40 minutes) - nor were the data sets that big, or the front end complex).

I'm far happier with using ________________ (pick almost anything else used in the non-Windows world), and far happier extending base classes and functions, over using pre-written bloatware versions.

But then again, besides the competition aspect, I think they are also trying to woo companies that can hire even less expensive "developers" since sooooooooooo many more things have been added making development a matter of point and click (and requiring even less actual development skills)... it seems more like a two prong attack against their competition.

Great, that's fine... nothing wrong with that - if it's not at the sacrifice of security, performance, and interoperability. But of course, it does sacrifice all of those... and really doesnt seem to do much at all.

So many of the new methods and classes are all stuff that the originals should have allowed the extensibility for to begin with. And so many should be variants on the same method (SOM anyone? Compare the SOM/DSOM design to just the first few lines listed in the article).

...so tell me again, how is "Naughty Bob's" post flamebait? No one who has responded to him has yet said why.

Feel free to mod this anything you want... doing so wont change reality.

There's just a lot of features

[tjstork]

Simplicity? Internal logic?

Yes, actually. There's a ton of features in Windows at the SDK level and .NET is really designed to be a wrapper around all the different Windows services. A lot of things in Windows are rather difficult to program at the C or even the C++ level. The standard Win32 API isn't too bad to work with in C, but the windowing functions and the messages mechanism is enough to provoke tears. Really, Windows is terrible for programming in C compared to Linux, and so, at least .NET papers over all the crap.

Right off the wheel, I can think of a couple of things that are easier to do in .NET than in the native C++ in Windows. Writing services in C++ is basically torture. In .NET, services are very easy to write. In C++, cracking messages in Windows forms natively is a tad like pulling teeth. MFC is aweful and ATL/WTL are better, but, I would prefer a native C++ framework like what was done with BeOS. Still, GDI+ in C++ is pretty much the same as using GDI+ in .NET, except that .NET actually gives you more convenient handling of images and fonts. Files are much easier to work with in .NET than in C++. The Path combining classes are entirely welcome and those things are great. .NET String is better than the STL string, by far, and I really like that Microsoft stole the Java idea of a StringBuilder.

Of course, .NET forms are ugly and slow. The presentation framework looks cool, but, that's now two libraries for user interface, not counting all the web stuff.

Speaking of Java... I wonder how many lines of code are in THAT framework?

Re:The purpose of this complexity

[bladesjester]

I realize that you're one of those "Anything but Microsoft at any cost" people, but I have some news for you.

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 .NET isn't really any worse than when I was dealing with it in C, C++, or any other language that I've used.

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.

Re:The purpose of this complexity

[AKAImBatman]

FWIW, he does have something of a point. Microsoft cycles its platforms at an incredible rate that just is not natural for the industry. As soon as one gets used to the existing API, Microsoft deprecates it and creates a new one. What's the advantage of the new one over the old one? In many cases, no one knows.

Why did Microsoft rearrange the VBA API from Access 97 to Access 2000? Heck if I know. Why did Microsoft make IIS extensions written in .NET 1.x incompatible with 2.0? No idea. All I know is that Microsoft does these things. Evidence suggests that Microsoft does it intentionally to lock out competitors. (source: Barbarians Led by Bill Gates) If that's true, then it certainly doesn't cast Microsoft in a good light.

That being said, you are also correct in saying that C# is a superior desktop development platform. If you're developing for Windows, I don't see any real reason not to use it. It's a fairly decent platform with tons of modern features. The only time it's really inappropriate is when your program needs to be cross platform. In which case Java might be the best choice despite the inherent difficulty in developing a good GUI in Swing. (Or SWT if you prefer. Don't even think about using Mono. Trust me, it's bad juju. Even the Mono devs will tell you that compatibility with .NET is NOT their primary goal.)

So, wait a minute

[glwtta]

Having a large class library is a bad thing now? You don't like it when other people do work for you?

It's all properly namespaced (unlike some languages I could name), having a bunch of classes you don't need to use does not add to your mental footprint.

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.

most common .Net developer mistake

[192939495969798999]

The most common .Net developer mistake now is that people don't bother finding the function they need -- instead they just reinvent it and waste everyone's time when maintaining that code later. The problem with 30,000+ items is that there's no good way to teach people where to look for something that's already in there. If it were organized in such a way that one could easily not reinvent the wheel, then it would be an awesome language. Without that, though, it becomes yet another way for people to create crappy date parsers.

Re:The purpose of this complexity

[SunTzuWarmaster]

No, no, you're right. Linux tools and whatnot have lifespans significantly longer than those short-lived .NET things.

Maybe I'm just bitter because I tried to get mySQL++ working with MSVS only to have it update after a week and work better... (less than a year)

Or the time that I pulled off an offline installation of Fedora Core 3 with all drivers and library dependencies resolved (hey, this was my first linux attemp!), only to have Fedora Core 4 come out THE NEXT WEEK.

Microsoft at least has the decency to change in large steps.

Re:Answer: No Thanks

[metallic]

To me, it looks more like they are trying to prove that they can compete with, and surpass, all their .Net competition by sheer number of "features"/"capabilities" - which does not make it better. Their .Net framework already scaled horrendously to many types of implementations (like the Service/Customer tracking unit CompUSA used to use - as any of you who worked in Tech or Business Sales can attest to - from fond memories of running a rather simple report, going out for coffee and a quick breakfast, coming back, and still having 10 minutes to wait (of a total 30-40 minutes) - nor were the data sets that big, or the front end complex). Did it ever occur to you that the software in question was probably crap? I've done reporting using .NET and SQL Server over a moderate data set (a few gigabytes) and always had the report generate in a few seconds. The .NET framework would be the last thing I would look at for performance problems.