text: Visualizing the .NET Framework 320
  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."
  Wow, that's a big fat ASS^H^HPI (Score:5, Insightful)
  Re: (Score:2)
  May I just say... AMEN!
  Re: (Score:2, Funny)
  Say It!
  Re:Wow, that's a big fat ASS^H^HPI (Score:4, Informative).
  Re:Wow, that's a big fat ASS^H^HPI (Score:5, Insightful)
  Re: (Score:3, Funny)
  Re:Wow, that's a big fat ASS^H^HPI (Score:5, Interesting)
  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 (Score:5, Funny)
  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: (Score:3, Funny)
  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 [castleproject.org]'
  What, you thought you were joking?
  Re: (Score:2)
  Why?
  They're not remotely similar, or did you just want to pick the low-hanging fruit?
  Re:Wow, that's a big fat ASS^H^HPI (Score:4, Informative)
  Re: (Score:2).
  Actually, I was just trying to be funny; apparently I failed. I know there are applications that need all that complexity sometimes. But since you brought it up, when I was growing up, my family owned a horse. Maintaining a horse (without a buggy) is *far* more complex and inconvenient than my car. My car doesn't die if I fail to feed it regularly. I don't have to clean out my parking spot every few weeks. I can let my car sit in my driveway for weeks with no attention and it still works when I need it.
  Re: (Score:2)
  Re:Wow, that's a big fat ASS^H^HPI (Score:5, Insightful)
  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.
  The purpose of this complexity (Score:2, Insightful)
  The purpose of this complexity is to ensure the tool is obsolete before it is mastered.
  Since
  .NET platforms have an average lifespan of what, 18 months? You could spend that much time in a bootcamp drilling namespaces and methods all day and not get there before it's time to enroll in the next one. 384,000 methods? 12,324 public classes? How many of those are deprecated? How many soon will be? And of course if you use this junk to develop for windows, try to remember not to get uppity and make a market
  Re:The purpose of this complexity (Score:5, Insightful)
  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.
  Re:The purpose of this complexity (Score:4, Interesting)
  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
  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
  Re: (Score:3, Interesting)
  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
  Re:Wow, that's a big fat ASS^H^HPI (Score:5, Informative)
  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 (Score:5, Funny)
  -E. F. Schumacher
  Rube Goldberg is alive and working for Microsoft.
  Re: (Score:2)
  Re:Wow, that's a big fat ASS^H^HPI (Score:5, Insightful)
  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...
  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...
  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 (Score:5, Insightful)
  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.
  Re: (Score:2)
  Re: (Score:2, Insightful)
  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 o
  Re: (Score:2)
  I'm not sure I've seen many cases of "over abstraction". Can you think of a good example you have seen? Normally what I see is under-abstraction. People repeating the same logic again and again all over the place and failing to see that it can be abstracted away.
  Re: (Score:2, Insightful)
  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 (Score:5, Insightful)
  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.
  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 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.
  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.
  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 (Score:4, Insightful)
  With
  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: (Score:2)
  .NET is OOP gone stupid. (Score:4, Insightful)
  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
  Re:.NET is OOP gone stupid. (Score:5, Insightful)
  Re: (Score:2, Interesting)
  One example I came across recently was that I was able to couple one visualization library (that rendered to an on screen canvas) to a pdf library (that implemented the standard Graphics2D interface). With little more than a few lines of code, the full vector-based visualization appeared in a pdf file. Granted, I'm not a C++ programmer, but I doubt you could have g
  Re: (Score:2)
  I go back and forth on this.
  On one hand, Sun's javadocs for the base Java API are generally superior to MS's for the base
  On the other hand, a lot of things effectively fall into the
  Re:.NET is OOP gone stupid. (Score:5, Funny)
  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: (Score:2)
  Well, you don't! Ruby and Python are right here.
  Amazingly, every project I've worked on since 2002 has said "we'll write a prototype in (python|ruby), and then rewrite the slow parts in (Java|C)", and every one has just gone and shipped the "prototype".
  It's like these system architects don't realize that when your language is only responsible for hooking your GUI toolkit to an RDBMS in a different city, the (Python|Ruby) VM is not going to be your bottleneck.
  The complexity of Java (or C, or x86 assembly) is there if we ever need it; I doubt we ever will.
  My experience sounds similar to yours, and I generally default to writing most everything in Python and dropping out to C if necessary for optimization. The only drawback so far has been that languages like Ruby and Python make people with pointy hair uncomfortable because they're not backed by a Real Company (TM). YMMV of course; I don't work on enterprisey apps that need all the complexity that the Java/.NET people say is so important, so my approach is probably only appropriate for certain niches.
  Re: (Score:3, Insightful)
  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.
  Re:.NET is OOP gone stupid. (Score:5, Insightful)
  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,
  Re: (Score:3, Informative)
  Re: (Score:2)
  Incidently, I thought you were talking about C# 3.0 when I was reading the beginning of your post. In my opinion this is one of the reasons Microsoft has succeeded: They shamelessly steal the best features of other good products.
  While Java fan's were complaining that
  Re: (Score:2)
  Yup, I agree -- sometimes encapsulating and abstracting the problem is the right approach. Key word there? Sometimes.
  If you have a simple, well defined problem (e.g. 'write these 8 bytes to a file'), a 'nice and simple' solution often does the trick. Less code means less complexity and more clarity. With C++, for example, you could use a simple fopen() -- or you could wr
  Re: (Score:2)
  Many languages start with the goal of making everything simple and keep bolting on features gradually until the language becomes a mess and everyone complains about the inconsistencies and (ironically) excessive complexity. PHP is such an example.
  Sometimes it pays to design for complexity up-front. I don't mean anticipating every possible feature and bundling it in (like, say J2EE) but to be rea
  Re: (Score:2)
  No, you *have* to use them, and that is the problem.
  "Keep the simple things simple, and make the complex things achievable" is the goal of a good programming language.
  Not: "whatever your transport needs, a Boeing 747 is always the answer." Sometimes a pair of roller skates would be more practical.
  Re: (Score:2)
  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.
  The funny thing is, they (and unfortunately some employers) think it is great to try to learn it all rather than look it up when needed. They call it Microsoft Certification. You can never learn it all in any sufficient depth and even if you could, by the time you did, they would have changed everything anyway.
  I think the reason it's so big is because they have tried to address so much. They haven't necessarily done it stupidly, but they have addressed a huge problem domain so there are huge numbers
  Re: (Score:2)
  Honestly, I think 90% of the actual value of a
  Re: (Score:2)
  Honestly, I think 90% of the actual value of a
  .NET cert is that you're at least exposed to all the major features of the framework.
  I've never really been a big fan of trying to learn absolutely everything, especially when the things you are trying to learn are as transient as those of a particular Microsoft technology. If Microsoft kept completely changing physics every few years, I really wouldn't have bothered doing a physics degree. These Certification courses tend to be quite expensive and I know that the companies that do the training promise students (who fork over thousands) the Earth.
  Re: (Score:2)
  Well, that's true. Someone who's working with
  Re:.NET is OOP gone stupid. (Score:5, Insightful)
  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.
  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.
  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.
  Re: (Score:2)
  Re: (Score:2)
  It's slightly less straightforward in
  I worked on a
  Re: (Score:3, Insightful)
  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: (Score:2)
  Re: (Score:3, Informative)
  Re:.NET is OOP gone stupid. (Score:5, Informative)
  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:
  That is both tough and complex. I don't know how I can cope.
  Re: (Score:3, Informative)
  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 i
  Re: (Score:2)
  Re: (Score:3, Insightful)
  Define does not scale well. I worked on an enterprise
  Re: (Score:3, Insightful)
  Give me fopen() any day.
  There are a lot of things that I don't like about
  .NET (Score:3, Insightful)
  Re: (Score:2)
  goatse (Score:4, Funny)
  The goggles, etc.
  No bite. (Score:2)
  Sadly, that is not a good thing. I love PHP, but it's a mess and desperately needs an overhaul.
  (please note: This is my opinion... not out to start a pissing war.)
  p.s. - who the hell uses
  Hehe ok but you're a bit off. (Score:2)
  You're fanboyism of PHP is much appreciated (as I am myself a PHP developer) but PHP is actually smaller. Don't be deceived. This is a GOOD thing. Less bloat = more performance. PHP + *SQL + Memcache will always pack more punch in a smaller package then the
  Also I do have to point out that comparing PHP to
  If more types is bad, then Java is equally bad. (Score:5, Insightful)
  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.
  Re: (Score:2)
  Correction (Score:5, Funny)
  There, fixed that for you.
  I love every single one of those lines of code. (Score:2, Insightful)
  Compare it to the Human Genome (Score:5, Interesting)
  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
  Re: (Score:2)
  Re: (Score:2)
  Re: (Score:2)
  public static string[] ReadAllLines(string path)
  {
  return ReadAllLines(path, Encoding.UTF8);
  }
  Re:Compare it to the Human Genome (Score:5, Funny)
  -G
  Re: (Score:3, Funny)
  Familiar punchline (Score:4, Funny)
  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
  Portable.NET (Score:2, Funny)
  so what? (Score:2)
  So, wait a minute (Score:3, Insightful)
  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.
  most common .Net developer mistake (Score:4, Interesting)
  Re:This is News? (Score:5, Insightful)
  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.
  Re: (Score:2)
  Are you kidding? [microsoft.com]
  And that's just me randomly hitting a particular class. Most of them have examples.
  Re: (Score:2)
  Re:This is News? (Score:4, Insightful)
  Re: (Score:2, Interesting)
  Re: (Score:2)
  Or do 90% of
  Re: (Score:2)
  Personally, I'm glad the MS docs don't cater to the program-by-copy-paste crowd.
  Re: (Score:2)
  You don't get a speed advantage with C++, C++ is much harder to read and much easier to screw up.
  Plus you can just write the code much faster in C# and VB.Net.
  Re: (Score:2)
  Re: (Score:2)
  Probably more than that. I've worked on a lot of
  Re:The horror! (Score:5, Insightful)
  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.
  Re:The horror! (Score:5, Insightful)
  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 agree (Score:5, Informative)
  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: (Score:2)
  Re: (Score:3, Insightful)
  Re: (Score:2)
  Re: (Score:3, Informative)
  .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
  Re: (Score:3, Insightful)
  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 be
  There's just a lot of features (Score:3, Insightful)
  Yes, actually. There's a ton of features in Windows at the SDK level and
  Re:Answer: No Thanks (Score:5, Informative)
  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.
  Re:Answer: No Thanks (Score:5, Informative) [wikipedia.org]
  Re: (Score:2)