Forgot your password?
typodupeerror
Microsoft Programming

Was .NET All a Mistake? 688

Posted by samzenpus
from the in-hindsight dept.
mikejuk writes "The recent unsettling behavior at Microsoft concerning .NET makes it a good time to re-evaluate what the technology is all about. It may have been good technology, but with the systems guys building Windows preferring to stick with C++, the outcome was inevitable. Because they failed to support its way of doing things, .NET has always been a second-class Windows citizen unable to make direct use of the Windows APIs — especially the latest. .NET started out as Microsoft's best challenge to Java but now you have to ask: what has the excursion into managed code brought the Microsoft programmer, and indeed what good has it done Microsoft? From where we are now, it begins to look very much like an unnecessary forced detour, and Windows programmers are going to be living with the mess for years to come."
This discussion has been archived. No new comments can be posted.

Was .NET All a Mistake?

Comments Filter:
  • by Anonymous Coward

    Do you really need an entire article to give you the answer to that one?

  • by Anonymous Coward on Wednesday August 03, 2011 @05:05PM (#36977164)

    And the answer to my question is yes.

    But the answer to your question is a big fat no. And I have an entire functioning, blossoming eco-system to back that answer up.

    Oh, and while we're at it... Why post a question when you've already made your mind up? And posed the question in a biased way based on your pre-decided conclusion.

    XcepticZP

    • Re: (Score:2, Insightful)

      by FranTaylor (164577)

      "I have an entire functioning, blossoming eco-system"

      Yes YOU have it, but WE don't, and THAT is the failure.

      You CAN'T take your "functioning, blossoming eco-system" and share it with anyone that isn't running the same version of Windows as you. THAT is the loss.

      • You're going to have to go over that one in more detail, Sparky. I can share my 500,000 LOC document control system between users with Windows XP 32 and 64 bit and Windows 7 32 and 64 bit. There's no reason not to expect Vista would work as well, although there's also no real reason to try.
        • Re: (Score:3, Insightful)

          by FranTaylor (164577)

          Can you bundle your app into a single file, and run it by double-clicking it, on any one of a dozen platforms?

          Are your runtime requirements available on ALL of the commonly available platforms, so people don't have to change their platform to run your code?

          So you have the audacity to tell someone that they need to buy a new computer to run your code? Really I have to go out and spend hundreds of dollars to even try out your program, just because your taste in platforms is different from mine?

          • by SpryGuy (206254) on Wednesday August 03, 2011 @05:27PM (#36977534)

            Who cares? ALL my customers are on Windows. The tiny fragment of a market that can't run windows software is irrelevant to most people, especially those in the business of making money.

            Even the largest of those tiny minorities (Mac users) can run .Net using bootcamp or parallels or some such.

            And for the rest, there's Mono, which will run a subset of .Net stuff.

            Really, this notion that EVERY program must be able to run on EVERY platform is just ridiculous B.S. It never has been true and never will be true.

            And really, anyone that has to "buy new hardware" to run a .Net application has some pretty alien hardware to begin with. XP, Vista, and Win7 run on most things out there, and Win8 will add to the supported processors and form factors.

            Your post is a lot of hot smoke and arrogant ignorance. There's a huge ecosystem around .Net, and it's a lucrative framework in which to develop. That's a simple fact that no amount of foot-stamping will erase.

          • by digitig (1056110)

            Can you bundle your app into a single file, and run it by double-clicking it, on any one of a dozen platforms?

            Are your runtime requirements available on ALL of the commonly available platforms, so people don't have to change their platform to run your code?

            Does he have a requirement for any of those things? Cross-platform costs, and if those costs are not recovered from increased market then it's a bad business model.

          • So you have the audacity to tell someone that they need to buy a new computer to run your code?

            What audacity? You're rude and disrespectful if you make platform-specific code? And since when do you need to buy a completely new computer?

          • What does any of that have to do with running different versions of Windows? I don't need to bundle it, Microsoft's updater includes the .NET framework as a recommended update that most people go ahead and put on their computer because they're not a total idiot. I don't need to have runtimes on every platform, because Windows is my platform of choice. I don't need someone to buy a new computer, because if they're encountering my .NET code they're usually on Windows. And I don't care about your platform
          • Can you bundle your app into a single file, and run it by double-clicking it, on any one of a dozen platforms?

            No, and nothing like this exists anywhere else either. Technically, the closest thing to what you're describing that exists would be the OSX Universal binary, which runs on x86 and PowerPC.

            With everything else, there's going to be a native executable involved somewhere, be it a Java JVM or web browser, which you appear to realize as per your next point:

            Are your runtime requirements available on ALL of the commonly available platforms, so people don't have to change their platform to run your code?

            I've never really tried Mono, but I understand it has very good .NET support these days:

            The easiest way to describe what Mono currently supports is:
            Everything in .NET 4.0 except WPF, EntityFramework and WF, limited WCF.

            Mono runs on OSX, Linux, and the BSDs. And even on Windows.

      • Re: (Score:3, Insightful)

        by CaseCrash (1120869)

        You CAN'T take your "functioning, blossoming eco-system" and share it with anyone that isn't running the same version of Windows as you. THAT is the loss.

        I know, it sucks, I can only run .Net apps on any Windows system from the past 10 years! I can't run it on Windows 95, or Linux, or my iPhone. I'm also pissed off that I can't run this new iPhone app I got on my Commodore 64 or my blender! WTF? It should be able to run anywhere, just like those linux programs you wrote run everywhere.

        (</sarcasm> if you're too dumb to get it, which I think you might be based on your post)

      • by RingDev (879105) on Wednesday August 03, 2011 @05:42PM (#36977772) Homepage Journal

        You're on more crack than the author. You can run .Net apps on any machine with the same version of the .Net client installed, XP, 2k3, Vista, 2k8, 7, even Apple, and although it lags a little behind Mono gets us running on Linux.

        Sure, it's not quite as "runs on anything" as Java, but have you ever compared any of the Java IDEs with VS? Lets face it, if MS hosed up every other thing its ever done, Visual Studio is bar none the best coding IDE. .Net, like Java, are high level object orriented managed code languages. Yeah, if you try to write an OS in them, it would be rediculous. If you are trying to push the latest greatest graphics systems through them, you'll be disipointed. But if you're trying to develop desktop apps, web services, rapid software prototypes, etc... they are both great languages.

        Use the right tool for the job. .Net and Java are not the right tool for every job. But for those that they are designed to fulfill, they work wonderfully.

        -Rick

        • by sourcerror (1718066) on Wednesday August 03, 2011 @05:56PM (#36978004)

          "Sure, it's not quite as "runs on anything" as Java, but have you ever compared any of the Java IDEs with VS? Lets face it, if MS hosed up every other thing its ever done, Visual Studio is bar none the best coding IDE."

          That's a matter of taste. I always preferred Eclipse to VS even for C++ coding. (Let's just say I hate horizontal scrolling.)

    • Indeed you are correct, but this is Slashdot. Spare nothing, even invalid assumptions - as long as it allows us to skewer Microsoft?

      From the "story":

      Imagine for a moment that Microsoft hadn't forced us all to use .NET and instead VB 7 had been just an evolutionary upgrade. Presumably we would have settled on VB 7 for the "easy" applications and C++ for the more "demanding" applications.

      .NET was never meant to replace VB. That would be C#.

      • by PCM2 (4486)

        .NET was never meant to replace VB. That would be C#.

        I think you misunderstand. The last version of regular Visual Basic was Visual Basic 6. Visual Basic 7 wasn't called that; it was called Visual Basic .Net. Microsoft ended all support for Visual Basic 6 in 2008. So if you were a Visual Basic programmer, you were indeed forced to use .Net, and for all intents and purposes, .Net replaced Visual Basic.

  • No? (Score:5, Insightful)

    by bhcompy (1877290) on Wednesday August 03, 2011 @05:06PM (#36977178)
    Works fine for what it is. It's not meant to build OS's with. It's meant for the applications within, and certain applications at that. Works pretty damn well for that.
    • Agreed completely. I would much rather be writing LOB applications using .Net (C# specifically) then VB7 or C++ any day. The author of the original article is someone who spends a lot of time doing things that require C++ to do. And that's perfectly fine but that is a smaller and smaller % of development work. Heh.. can anyone really imagine writing a web site in C++?
    • Re:No? (Score:4, Insightful)

      by exhilaration (587191) on Wednesday August 03, 2011 @05:14PM (#36977324)
      Agreed, it's a perfectly fine language for plenty of things like business applications. If you want to build operating systems or first person shooters, you won't be using .Net or Java, that's just not what they're for.
      • by sjames (1099)

        It could be a decent language if it wasn't locked to a specific OS.

        • It could be a decent language if it wasn't locked to a specific OS.

          .NET isn't a languages, and the languages for it (C#, VB.NET, IronRuby, IronPython, etc.) aren't tied to a specific OS or even OS vendor.

          Some of the libraries are locked to a particular OS (or, more commonly, a family of OSs from a particular vendor).

          • by sjames (1099)

            So where is the variety of Apps in .Net running on all sorts of different OSes? I haven't seen much beyond proof of concept demos.

            It certainly doesn't seem that MS ever intended the Apps to work elsewhere.

            It's true that there is more than one language for .Net, but they all seem to be either brand new invented to run MS apps on MS OSes by MS or someone else's efforts.

            Java (for all it's many pitfalls) ran on multiple platforms right out of the box. .Net only came into existence when MS's efforts to pervert J

            • Re:No? (Score:4, Insightful)

              by tftp (111690) on Wednesday August 03, 2011 @08:02PM (#36979594) Homepage

              So where is the variety of Apps in .Net running on all sorts of different OSes?

              Most computer users are pragmatists. When they need a function they buy a program that does what they want, and a computer that runs that program. It just happens that Windows runs about 100% of all programs that anyone would be interested in[1], so the choice of the OS is quite obvious here.

              Of course MS is not going to port their libraries to other OSes. Not only it is not good for Windows, it is also not good for any ISV who would have such an idea. The market for .NET applications on Linux (or even Mac) is not very large, and it's hard to make a business case for that.

              But libraries, being defined by their interfaces, can be rewritten from scratch - and that's what Mono is doing, as I understand, beyond the C# itself. It's a lot of effort - especially when you dive into WPF which is a very complex programming framework.

              Java (for all it's many pitfalls) ran on multiple platforms right out of the box.

              Java was also unusable on all of them. .NET is really implemented only on Windows, but it works great. Java appears to be in a better shape now, but still I can't readily recall a major, large program that is written in Java. All Java applications that I ever came across come with their own JRE, talk about compatibility... However it's easy to find examples in .NET world - like Paint.Net - and they run on whatever is installed on your box. Java in interests of portability supports only the lowest common denominator; .NET supports the latest and greatest. Guess which one is more appealing to a new developer?

              By now we should know two facts about MS:

              1. MS never releases a quality product in rev. 1
              2. MS always releases a quality product in rev. 3

              Today main MS cash cows - Windows, Office, .NET, Visial Studio etc. - are in good shape. It would be unwise to summarily ignore thousands of man-years that went into their development.

              [1] Of course that shouldn't be taken literally. I sorely need Squid 3.1 for my IPv4 to IPv6 proxy at home. IPv6 is supported only in the latest rev. 3.1. But Squid on Windows is dead as a doornail, with major pieces missing [acmeconsulting.it]. I guess I need to splurge on another Ubuntu box, since nothing that I have can take another VM...

              • Re:No? (Score:4, Insightful)

                by SplashMyBandit (1543257) on Thursday August 04, 2011 @02:56AM (#36982578)
                You are talking about desktop apps as if that was the only programs out there. Many apps have moved to the Web, and a very large number of them are built in Java. Just because you can't see Java (because you have your eyes closed) doesn't mean you don't use it whenever you use the Web (same thing with Linux, which handles almost all the external-going mail you'll ever send, but this is also invisible to you because it works so damn well).
    • What happens? (Score:5, Insightful)

      by FranTaylor (164577) on Wednesday August 03, 2011 @05:27PM (#36977522)

      What happens when your vendor decides to move on, just like they have done many times before? Your application is now a ticking time bomb, set to explode at the support cutoff date.

      Hello did you learn the lesson from the mainframe era? Don't code to vendor specific APIs. Stay platform-neutral and you give yourself a much wider range of platforms for your application. It gives you much more leverage in your hardware purchasing, if you are free to choose any platform.

      The folks in the trucking industry figured this stuff out a long time ago. It is shocking to me to see people, today, intentionally choosing vendor lock-in.

      • Re:What happens? (Score:5, Insightful)

        by aztracker1 (702135) on Wednesday August 03, 2011 @06:05PM (#36978132) Homepage
        Sheesh, what a FUD trip this is.. there are non-MS implementations of .Net that are open-source and support cross platform migration as easily as any other managed runtime. As to TFS regarding not being able to access the system API, the author doesn't know WTF they are talking about. The ability to interact with system libraries is far easier in.Net than any other managed platform, even in a platform agnostic way.
        • Re:What happens? (Score:5, Insightful)

          by SplashMyBandit (1543257) on Thursday August 04, 2011 @02:59AM (#36982600)
          Yes, there are alternatives for the language implementation, but check the libraries out. With .NET you are locked into the libraries (unless you can afford to re-write your app in exotic [for Windows] Gnome technologies). Actually I found Java's JNA easier than .NET in working with system libraries, no matter what platform. Shame you don't know about it.
      • by bhcompy (1877290)
        It gets emulated, just like everything else. Emulated PICK, emulated AS400, etc. Code doesn't stop working because support is gone or the OS manufacturer went out of business. I have customers that run Win2k server VMs for particular software. Optimal? No, but platform independence just means more problems on the design side. The average business app designer doesn't have the time or the resources to ensure that his/her program is compatible/compilable in OSs that they don't even use or haven't been in
    • I agree for a different reason, examining .NET from a technological point of view... that's pointless. A java killer was already a not so good idea, a java killer without proper software freedom and platform independence is a joke, if I stick to one platform there's no point in doing stuff through a VM.

      It has been a success because it kept people under MS umbrella.

      And all it takes for MS to silence speculation is a new release with some cosmetic changes, I expect something like that, it is a good marketing

    • I definitely agree (Score:5, Insightful)

      by msobkow (48369) on Wednesday August 03, 2011 @05:41PM (#36977756) Homepage Journal

      The C#/.Net world is very well suited to front-end applications in the business world. You wouldn't want to write a video game or OS tools with it, but for it's target market, it's very effective. I particularly like how clean the class libraries are compared to the old Win32 SDK APIs.

  • by jra (5600)

    "Yes".

    • by Anonymous Coward on Wednesday August 03, 2011 @05:15PM (#36977336)

      Ditto. .NET drove me away from developing windows apps altogether... it killed visual studio for me.

      When it first launched, nobody had .NET framework installed, so you were screwed on that end. Then it started shipping with the OS, but it was never up to date it seemed like. The number of times I just wanted to download an app and have it run, only to be foiled by an out of date version of the .NET framework... which was also freaking HUGE!

      It was basically in theory the same idea as java, except with even more restrictions, limits, and headaches. On top of all that, it was force-fed down all of our throats by Microsoft for years, and still even up to this date.

      In short, it's like java, but a 10x bigger disaster.

      • by Rary (566291)

        In short, it's like java, but a 10x bigger disaster.

        And, incidentally, both it and Java are the two primary development platforms in the corporate world today, and still going strong. Pick either one, and you'll find work with little effort. Familiarize yourself with both, and companies will fight over you.

        Sure, it's not for everyone. Apparently it doesn't suit your purposes. But it's the right tool for certain jobs— and there are lots of those jobs.

  • Messy (Score:5, Funny)

    by flaming error (1041742) on Wednesday August 03, 2011 @05:08PM (#36977210) Journal

    > Windows programmers are going to be living with the
    > mess for years to come.

    It's a dirty job, and every other Friday I cry all the way to the bank.

  • by cosm (1072588) <thecosm3@@@gmail...com> on Wednesday August 03, 2011 @05:10PM (#36977240)
    We're a ~100 person .NET shop and we do about 10 million a year with small businesses. It's worked great for us!
  • by Kensai7 (1005287) on Wednesday August 03, 2011 @05:10PM (#36977248)

    According to an Ars Technica [arstechnica.com] article, .NET will be first-class citizen in Windows 8.

  • by roc97007 (608802) on Wednesday August 03, 2011 @05:10PM (#36977250) Journal

    What .NET has brought to the Microsoft programmer is a decade of lucrative employment. That's not a bad thing. The trick now is to convert back to C++ and ... I'm tempted to say "go out and get real jobs" but that would be unfair.

    • by bloodhawk (813939)
      Why would they want to convert back to C++, With .NET getting massive investment and becoming an even better target in Windows 8 there is less and less reason to go the C++ route. sure C++ is better for writing the OS etc, but .NET or Java remains the platforms of choice for fast application development. The article is basically some clueless idiot that doesn't understand what .NET and Java are for and mistakes Microsoft's lack of use for writing there OS with it as some sort of move away from .NET, nothing
  • A mistake? (Score:5, Funny)

    by Brummund (447393) on Wednesday August 03, 2011 @05:10PM (#36977252)

    Yeah, look at the flop that is asp.net, or how hard doing protocol agnostic services with WCF is. *sigh* .NET is a huge success in the corporate world, and hopefully c# will be one of the last nails in VB's coffin.

    If you measured Java's success based on the non-proliferation of applets, it too is a flop.

    (And if you are a Java programmer, I hope you get something similar to Linq soon :-)

    • Yeah, look at the flop that is asp.net, or how hard doing protocol agnostic services with WCF is. *sigh* .NET is a huge success in the corporate world, and hopefully c# will be one of the last nails in VB's coffin.

      C# has been around with .NET since .NET 1.0 and VB is still going strong. If Microsoft had kept supporting and actively pushed IronRuby and/or IronPython, they might have combined with C# to displace VB.NET

  • Asked "why should I use this"?

    Couldn't come up with a good answer.

    Went back to Win32 and C++

    Could it be that maybe I was right?

    • by causality (777677)

      Asked "why should I use this"?

      Couldn't come up with a good answer.

      Went back to Win32 and C++

      Could it be that maybe I was right?

      Well, yeah. You independently evaluated your own needs and chose the solution that was a best-fit. You did not jump on a bandwagon and learn a whole new skillset because "everybody's doing it" or merely because a vendor would like to push it on you.

      It's hard to be wrong when you do things this way.

    • Re: (Score:3, Interesting)

      by The MAZZTer (911996)

      This won't happen anymore (ideally). [google.com] Pretty much the whole point is to eliminate (as much as possible) buffer overflows, invalid memory accesses, memory leaks, and other low-level bugs that easily pop up in C++ programs. .NET abstracts away dealing with low-level pointers, everything is "managed" by the framework so it is freed when no longer used (it is still possible to leak memory by keeping references to things you don't use anymore, but the framework can only do so much for you), and various attempts

      • by josath (460165)
        You've never seen a .NET program crash in managed code? You must not run very many of them then...I've seen it all the time. It's perfectly possible to crash a program with unhandled errors etc, without having to touch unmanaged code at all.
        • I was guessing the GP was just ignoring unhandled exceptions in managed code, since it's obvious that a program can crash from a basic runtime error.
  • controls backfire (Score:2, Insightful)

    by roman_mir (125474)

    Any attempt at controlling technology, people, businesses via artificial mean backfire, so this is no different.

    IF .NET is just a managed environment that makes it easier to develop for Windows platforms, then it's not a wrong thing to do, but if it marketed as a VM for the sake of being a VM while being boxed into Windows only, then it loses purpose.

    What's the purpose of this VM that can only be used in Windows? Is it just to provide a managed environment for the developers? Because if that's all it is, it

  • Obviously it was not a mistake. Since what happened with .NET might have triggered what later happened to Java. People started to implement other languages in .NET and Java. Creating just in time versions of languages what once were only available precompiled. Best off all it actually was semi-crossplatform, and an alternative/competitor to Java.
  • Of course .NET was a mistake. It had all the drawbacks of an interpreted system with none of the benefits. Inherent cross-platform run-anywhere ability which was Java's purpose from the beginning was never intended for .net. Cross-platform is the only consideration that makes interpreted code worth the cost in resources. .NET was a needless (read useless) distraction, and the only "benefit" I can perceive is an across-the-board requirement for people to purchase more powerful hardware to accomplish the s

    • by realmolo (574068)

      You're right.

      MS would've been better off just giving developers the better automated tools that were "included" with .NET, and skipping the actual .NET part.

      The .NET *environment* is really nice, but the "managed code" aspect of it is more-or-less worthless.

    • by BasharTeg (71923) on Wednesday August 03, 2011 @05:39PM (#36977732) Homepage

      How exactly is .NET interpreted? CIL (formerly MSIL) is JIT compiled, just like Java is. The JIT compiles of assemblies are cached in the GAC, so it only happens once. After that it's native code for the platform you're running on, whether that's 32bit Intel, 64bit Intel, or Itanium. Or you can choose a specific platform in Visual Studio and compile directly to that platform and avoid the intermediate language altogether. From your description of .NET it seems like you have no knowledge of the platform.

      Insightful? Come on mods, do better.

      • A "just in time" compiler is a type of interpreter. I know it sounds confusing but that is the way it is.

    • by pxpt (40550) on Wednesday August 03, 2011 @05:39PM (#36977742) Journal

      I strongly disagree that .NET in general and C# in particular has all the drawbacks of an interpreted system with none of the benefits. I don't care whether it runs everywhere or not (although that would be nice). What I do care is the intelligent garbage collection that is only possible with this type of architecture. What I do care about is the enormous library available to me for offloading common programming tasks. What I do care about are generics, strong typing and collections. What I do care about is the easy database accessing. What I do care about is the intelligence available in Visual Studio that can work out refactoring for me. What I do care about is getting complex business apps out the door and being able to support the business with ever more complicated requirements. Sure I could do that with C++ but never in the same time frame. C# and the .NET Framework are my big programming lever.

  • Visual Studio Express Editions + SQL covers:
    - Web Services - ASP.Net Pages - Windows binaries

    Express Editions Completely free? Yes. Do they work and are they flexible? Yes? Properly documented? Yes. Solid and highly proliferated languages? Yes. Large job market for .NET devs? Yes. Large platform install base across the corporate and consumer realms? Yes. Large user-base online for support? Yes. Large selection of open-source .NET project available for tinkering? Yes and growing. Interopability with most
  • The article writer frets that there's an "undertow" to return to C++ and COM (I'd love to know where that undertow resides, because it ain't on these shores, let me tell you), but his original article was about how Microsoft is abandoning .NET for Javascript and HTML5. It's as if there is no possibility that these four could coexist and even *gasp* compliment one another. One begins to wonder what you whippersnappers are smoking.
  • [citation needed]

    Would it have killed the submitter to add a link to some demonstrable evidence of claimed "recent unsettling behavior", given that many of us don't live and breathe All Things Microsoft(TM)?

    • by The Moof (859402)
      The only rumblings (which were covered here [slashdot.org]) are about MS dropping Silverlight and going with HTML5/JavaScript for web. Somehow, the article took that and misconstrued it as MS abandoning .NET.
  • by erroneus (253617) on Wednesday August 03, 2011 @05:22PM (#36977436) Homepage

    ... and people here told me I was an idiot and didn't know what I was talking about and on and on and on. Good to know, at least, I'm not the only one.

    But I do see .NET for what it could have been -- the application programming API for the migration to the next Windows OS which isn't Win32/64 compatible. Microsoft still doesn't have the balls to shift to a brand new OS the way Apple did. But they should have done that a long, long time ago.

    • Why should Microsoft kill Windows, exactly? In pretty much all respects, it's a reasonably modern, secure, and stable operating system.
  • What recent unsettling behavior at MS concerning .NET? All I've heard about is Microsoft ditching Silverlight for HTML5, nothing about .NET being dropped as a whole. Even when the article tries to allude to it, they still only talk about Silverlight.

    One other thing....

    .NET has always been a second class Windows citizen unable to make direct use of the Windows APIs

    Really? [pinvoke.net]

  • I'm not a programmer by trade, but for the quick and dirty little apps that makes people's lives easier, I liked .NET. I could have a single use utility coded up in an afternoon that would save hours off of a day, from highly paid employees.

    • by Excelcia (906188)

      Delphi, C++ Builder, and the free cousin Lazarus are great tools for this. Lazarus is making some great cross-platform strides too. As a bonus, when you're done, you have real code. :)

  • by cdrguru (88047) on Wednesday August 03, 2011 @05:26PM (#36977498) Homepage

    What MFC was all about was hiding the nasty parts of writing applications for Windows inside of a framework that was supposed to make everything nice and orthogonal. For the most part, it failed in this task because you had to understand the underlying SDK-level API in order to make effective use of MFC.

    ActiveX was the next round of this and ATL was again supposed to hide things from the developer. It didn't do this, although it did make COM much simpler for a lot of the world. And Microsoft seemed to want to make COM into the "new" API for Windows without having it support any of the nasty parts.

    C# and VB.NET were the mostly the next round of this with COM as the primary path to getting anything done at all. If you like COM (or are forced into it), then C# and VB.NET make a lot of sense because now COM isn't some add-on to C or a template library that is 90% implemented - it is 100% there. But again, if you don't understand how Windows is doing things for you through the COM API functionality you will never understand why things are working the way they are.

    Yes, they added an entirely new GUI definition package and a whole lot of things as new COM interfaces to things that didn't have them before. The idea was clearly to make it possible to write applications completely in the COM world without ever having to touch the "native" API. And for the most part this succeeded because finally enough effort was put into the framework that a large number of application developers could get along with only the interfaces supplied.

    The problem with building an application framework ontop of a native API is that you can easily find yourself with a never-ending task if the native API keeps growing and changing, which it certainly has. Microsoft doesn't do well with never-ending tasks - priorities shift and where there were once hundreds of people working on something there might only be a few later on. Again, we have the MFC dilemma where you can write 90% of the application with MFC but that last 10% has to be done by someone familiar with both MFC and the native API. C# and VB.NET are mostly still better than that, but when you fall into a hole in the framework it takes someone familiar with three or four API levels, not just two as it was before.

    Is the idea of a processor-independent CLR a good one? Maybe. If the idea of Windows on multiple processor families (like MIPS and PPC, for example) ever amounted to anything it would be very useful. With 99.9999 of the hardware out there being x86 and x64 (x86 compatible) there is little point to it today. Those directions are very difficult to see and I suspect Microsoft was committed to the CLR approach long before the decision was made to abandon MIPS and PPC, as well as nearly every other hardware architecture other than x86/x64. This might change again in the future, but without huge memory and processor availability it is unlikely that much cross-platform application compatibility will really exist. It makes no sense to have a cross-platform application that relies on so much memory that it won't run on handheld devices when the choices are x86 desktops and other handheld devices only. The future of a non-x86 compatible desktop at this point is very much in question, probably to the point of it taking another 10 or 20 years before there is a real change there.

    Back in the 1970s IBM mainframe customers pretty much made certain that nothing that wasn't compatible with the 370 instruction set would sell, and we are living with that legacy today, still, 30+ years later. Somewhere around 1995 or so it was pretty plain that the market for non-x86 compatible hardware in the PC world was limited and perhaps non-existant. Alpha was still produced and Windows NT came out with MIPS, Alpha and PPC support. But the number of real applications that were ever ported to non-x86 platforms was exceedingly small. Not saying it couldn't possibly happen, but at this point the need to break away from x86/x64 is vanishingly small and betting

    • by pcause (209643) on Wednesday August 03, 2011 @05:53PM (#36977964)

      The key is that Microsoft is porting Windows to ARM. if you built you app with .Net and MS doesn't screw things up you should have an app that works on the ARM version of Windows 8. If that happens, then for MS and developers the entire .Net experience has been a HUGE win. MS will have a Win 8 ARM with a huge supply of apps and developers and developers will have access to the tablet market without having to do much new.

  • by MobyDisk (75490) on Wednesday August 03, 2011 @05:31PM (#36977584) Homepage

    The i-programmer.info site has been trolling several articles about the end of .NET. Wake me when they have something other than speculation.

    with the systems guys building Windows preferring to stick with C++ the outcome was inevitable.

    .NET is not a systems language. It never will be. Neither is Perl, Ruby, Python, Java, or HTML5. This does not mean those languages are mistakes or that they are going away.

    .NET has always been a second class Windows citizen unable to make direct use of the Windows APIs — especially the latest.

    Actually, the opposite is true. Microsoft has been adding new functionality to Windows that is only available to .NET, not to C++ code. WPF is the biggest example of this. They are actually deprecating Windows APIs with each new release of the OS.

    The author does not seem to realize that that Microsoft is working on a C# 5.0, and that much of Microsoft's new development is in .NET: Office, Visual Studio, and Sharepoint. All of this trolling stemmed from one demo where they showed some mobile HTML5 apps, and someone just leapt to the conclusion that .NET was dying.

  • Ian Elliot is a much bigger mistake than .NET ever will be.

  • Well, if you want to write an OS, a critical real-time system, or a high-performance scientific data analysis suite, then no, .NET is probably not for you (although .NET 4.0 and its parallel processing additions certainly improve matters there). But if you want to rapidly develop enterprise business applications (or indeed webapps - everyone here appears to have overlooked the massively popular ASP.NET), then .NET's pretty damn good.

    The strength isn't really in the idea of the CLR or whatever - that's an im

  • Purpose of .NET (Score:5, Insightful)

    by Sloppy (14984) on Wednesday August 03, 2011 @05:51PM (#36977934) Homepage Journal

    I thought the purpose of .NET was to lure developers away from writing portable apps in Java. As long as the apps stay unportable, those developers' customers remain stuck with Windows.

    (Whether Java was a credible threat at the time (pre-Android) we'll never know, but what's done is done and .NET happened.)

    Assuming that's what the purpose was, it pretty much did its job for the better part of a decade and can hardly be called a mistake. Let's see you try to prevent the spread of technology at the beginning of the 21st century, and then we'll talk about who makes "mistakes" and who is the meta-luddite genius.

    "Gentlemen," [All raise their drink glasses] "To Evil!" [Wild cheering]

  • by gstrickler (920733) on Wednesday August 03, 2011 @05:59PM (#36978046)

    And the big one was thinking that a dominant OS vendor could/would create anything that was truly cross platform. From the beginning it was clear that .NET was a Windows first system, anyone else would be on their own. No matter how good the design and concept of .NET may be, while it's under MS control, it is fundamentally subjugated to keeping people on Windows. And while that may have sounded good to the executives at MS, it's a terrible way to address any threat they felt from Java. There is also the pressure from MS to have .NET support all the latest/greatest things in Windows, which is a backwards model. If they really wanted a sustainable and/or cross platform development/runtime, the Windows developers should bring their latest/greatest to .NET, if there are comparable capabilities on other platforms, then the .NET team might extend it in a way that supports portability. If not, but the Windows features are compelling enough, then developers would use them with the knowledge that such things are platform specific.

    In short, the .NET team being part of MS put them in the position of having to support two masters, and that's always a no win scenario. They needed to be a separate entity with separate decision making authority and separate accounting, even if MS owned the majority of that entity.

When in doubt, mumble; when in trouble, delegate; when in charge, ponder. -- James H. Boren

Working...