back to article 20 years of .NET: Reflecting on Microsoft's not-Java

Visual Studio .NET was released on February 13th 2002, marking the moment when Microsoft's Java alternative was declared ready for business. Microsoft .NET at PDC 2000: score? Screengrab from the announcement of Microsoft .NET at its Professional Developers Conference in 2000. Score? Dates are difficult. The .NET Framework …

  1. jzl

    Thank you for a great career so far

    I've built the majority of my career on writing software for .Net and I still love the platform. It's proven extensible, flexible and scalable, and I love the elegance of the CLR.

    C#, meanwhile, also just keeps getting better and in my opinion it remains one of the best programming languages ever created.

    Microsoft are a company with a checkered history: a lot of hits, a lot more misses and .Net is something they should be truly proud of.

    1. Plest Silver badge

      Re: Thank you for a great career so far

      I loved learning and coding in Java until I spent more time after work drinking with a good workmate and he introduced me to .Net and C#. To me as a casual coder C# feels like what Java should have been if Oracle had not taken a huge dump all over it.

      Not done much C# lately but it's one of the few languages I have a genuine fondness for, it feels fluid and easy on the eye, coded some fun PowerShell libs in C# for the ops teams. MS take a lot of stick but C# is one of those things that feels like they got it spot on.

      1. Ken Moorhouse Silver badge

        Re: drinking with a good workmate and he introduced me to .Net and C#

        That sounds like one of those addiction stories...

        Free downloads were they?

  2. Michael Hoffmann
    Unhappy

    Notably missing in action...

    The MAUI layer above Linux. I don't care if they pick one, a UI and framework, GNONE, KDE, Qt! X11 raw! Whatever.

    It's not there. What should that tell us about the level of commitment?

    1. Kristian Walsh

      Re: Notably missing in action...

      That’s the problem everyone has on Linux. There is no native UI, just a half-dozen pretenders to the title of “Linux UI”.

      I have faced it in my own work over the years: you start a project, and you first have to pick a UI library - a task that itself robs you of time, as you try to pick the facts out of various fanboy postings on the web. I’ve often regretted decisions that I made, or had forced on me, at project outset (e.g., the arse-pain of having to wrap existing datatypes in gObject boilerplate just to be able to have custom list-item views* in GTK+, or every single aspect of using Enlightenment).

      In the end, I settled on Qt for Linux GUI work, but it took a lot of dead-ends to get there (and did I mention the living hell of having to write a UI in Enlightenment?).

      Ironically, Windows suffers the same problem right now, with multiple competing UI kits leaving developers completely at a loss about what they should use for a new project (UWP, MFC/WPF, Win32??? Dammit, just tell me I have to use one, and I’ll use that, but you’re making me learn multiple platforms just to discard all but one of them). At least .Net 6 is fixing that issue.

      __

      * yes, this GTK+ example is probably over a decade out of date, but I have not forgotten how unpleasant, error-prone and time-consuming a task it was to do something so basic, and as a result, I resolved to never use GTK+ for a new project again. That’s another example of why this problem is such a problem on Linux: because there are so many other options, I bailed out on GTK+, rather than pushing the developers to fix the ball-ache, or writing a utility library to do it for me. As a result, the development of the toolkit slows down, and everyone ultimately loses out. And it’s the same for every library.

      1. minnsey231

        Re: Notably missing in action...

        Some people have been looking at using SharpGtk under MAUI AFAIK.

      2. StrangerHereMyself Bronze badge

        Re: Notably missing in action...

        Just use Win32. That will always work on any version of Windows.

        I mostly use the wxWidgets framework (there's also a Python based cousin: wxPython) for my UI development. It looks great, although somewhat archaic at times, but you could easily snazz it up with your own controls.

      3. Yet Another Anonymous coward Silver badge

        Re: Notably missing in action...

        So whats the UI for C++ on Windows?

        MFC, WPF with managed C++, raw Win32-C ?

        1. ThomH

          Re: Notably missing in action...

          Presumably C++/WinRT — a header-only projection of WinRT onto entirely-standard C++17.

          1. Yet Another Anonymous coward Silver badge

            Re: Notably missing in action...

            Ok, will see if they support it for more than 5mins.

            Have been using Qt since the last ice age

            1. ThomH

              Re: Notably missing in action...

              Agreed entirely; I’ve bothered to find out what the current solution is but I haven’t yet chanced my arm on using it.

      4. CommonBloke

        Know what's really ironic?

        Delphi made a unified UI all the way back in the early 90s and Lazarus offers the same ease with UI nowadays. The only "problem" is that it's all about programming in FreePascal, which a lot of people abhor because of the verbosity and other things that make it very different from C-like languages, such as :=

  3. Binraider Silver badge

    Success - from the perspective of creating jobs, legacy support dependencies and funnelling work to contractors; yes.

    Take development capability out of the hands of mere engineers and put it behind awful UI firewalls where you spend longer knowing the API than how to write algorithms.

    This isn't unique to .NET of course. And there is a very, very good reason Python and Numpy have become something of a standard for those that need to get stuff done; rather than write fluffy UIs.

    1. Kristian Walsh

      Yeah, only the exact kind of writing code against a supplied API that you happen to be doing is “real” programming.

    2. Loyal Commenter Silver badge

      "Oh no, I have to read and understand the documentation for a fully documented API. On occasion, I might have to google to find an example of its usage on Stack Overflow."

      I've yet to come across any tech stack that doesn't rely on APIs, with varying levels of documentation, and stability. On the whole, 'Net stuff tends towards being better documented and easier to use, although with some things the level of abstraction can be a bit mind-bending when you want to do something simple.

      As for Python. Well, whoever thought making indentation part of the syntax for any reason other than "because we can" needs a good thumping. Whenever I've come across it (for instance when tinkering with embedded programming), there has been a choice between Python and C/C++, and despite my C skills being somewhat rusty, that's still the preferable choice. Hell, I'd take PERL over Python.

      1. Loyal Commenter Silver badge

        Looks like I upset the Python bros. I'm sure there's a cracking use case that calls for an entirely new language with an ethos based on a 1960s comedy sketch show, that there were no existing tools and languages to cover, and I just missed the point entirely.

      2. William Towle
        Unhappy

        > Hell, I'd take PERL over Python.

        I'd have argued that myself based on initial experiences alone, but lately I've changed my mind.

        My early exposure to Perl was during the v4-to-v5 transition and the ability to `use strict` and `use warnings` meant a lot of the legacy code I ended up maintaining got a lot cleaner and a lot less buggy very quickly.

        Latterly with Python, I didn't find the whitespace rules any more annoying than in Makefiles, and found it does away with trivial arguments about cuddling braces and whether to use them at all around single lines of code nicely (modern compilers' warning about misleading indentation anyone?).

        Although with Python I had to Google error messages to make sense of them for a bit, I liked the feeling the interpreter was doing a thorough job of analysing code on your behalf (C#'s compiler likewise, incidentally); conversely, going back to Perl was tough going: either a case of getting errors to the effect of how anything "experimental" from early v5 is deprecated now, or of watching the parser fall over completely with no useful guidance how to reformat something so close to line noise ... and to make matters worse, then having to wonder what Google runes might possibly get me to a page explaining how to convert what I was trying into the working modern Perl equivalent. Ugh.

        1. Loyal Commenter Silver badge

          Of course, I may be being unduly harsh on Python; I just don't have a use case for it, and don't know the underlying reason for coming up with yet another programming language beyond "because we could" - what does it have that others don't? Genuine question!

          Is it just because some people don't like languages that use braces for delimiting blocks / scopes? The fact that they have become commonplace across so many languages kind of suggests that this is one thing that C got right.

        2. Loyal Commenter Silver badge

          To be fair, that was firmly tongue-in-cheek. I'm sure that PERL still has a place somewhere, but it's not a place that I or anyone I know has been to in the last 20 years.

      3. Yet Another Anonymous coward Silver badge

        >Well, whoever thought making indentation part of the syntax

        FORTRAN77 - remember we have the nukes and the rockets

  4. trevorde Silver badge

    Easier games to play

    Used to code in C++, MFC, Win32 API and COM until C# came along. My daughter's life would have to depend on it for me to go back there now.

    1. Peter D Bronze badge

      Re: Easier games to play

      Indeed. I sometimes have to revisit legacy C++/MFC code and, quite frankly, I turn to drink immediately afterwards.

      1. bombastic bob Silver badge
        Trollface

        Re: Easier games to play

        I started programming windows code around 1990, right around when Windows 3.0 came out. It was in C, required a message loop, and you had to think in terms of messages and events.

        I thought MFC with Visual C++ 1.0 was a pretty good step forward, once I got used to it. Its COM handling was also convenient.

        "So sorry" if people who code in C-pound and "dot Not" need their hands held by the framework or something. You trade efficiency for slavery to a framework and an inferior way of thinking. Things CAN be "too object oriented" to the point of stupidity, with things like (exaggerated sarcastically):

        multiverse.universe.galaxy.star.planet.continent.nation.province.city.street.house.person

        where you have to start with the MEGA COLLECTION and enumerators within probably bloat up memory to find the thing you REALLY wanted, where in Win32 it would be 'CreateWindow()" or something like it with a few parameters thrown in.

        FYI a cross-platform MFC-like framework exists: wxWidgets. With some effort, you can port an MFC application to wxWidgets and have it run EVERYWHERE. And if you're ME you static link it so that it does not need a boatload of shared / dynamically linked libraries (or just build from source everywhere). You know, code loads WAY FASTER when it doesn't use a boatload of monolithic shared libs...

        Compare "hello world" in C-pound to "hello world" in MFC. Just use the framework to generate it. See?

        1. Peter D Bronze badge

          Re: Easier games to play

          The Windows message loop has always been required even in the dread days of writing applications in C and still today in C#. I started as a C developer and the version 2.0 of MFC which you are misremembering was a nightmare but not as big a one as MFC 1.0 with C++ 7 which came in a box a yard long for the manuals in the shadow of OLE 2 (which later became COM) when you hand crafted virtual function tables. No sane person would today write a desktop presentation layer from scratch using even the latest version of MFC. It's not about handholding. It's common sense.

        2. Not Irrelevant

          Re: Easier games to play

          It sounds like you're confusing badly written object-oriented code with "the way you have to write code object oriented" If your C# UI code isn't massively easier to read and took half as long to write as an MCF UI you have done something wrong. Just because you CAN be an idiot, doesn't mean you have to be one.

        3. 9Rune5

          Re: Easier games to play

          I can only imagine what you would feel about a tool like reSharper which surely is the ultimate in hand-holding (and also a tool that saved me countless hours while refactoring other peoples' code).

        4. Loyal Commenter Silver badge

          Re: Easier games to play

          I guess your idea of writing multithreaded code is to FORK and manually use IPC, rather than just using async and letting the runtime manage it.

          Just because you can spend your life debugging race conditions, doesn't mean you should.

          Or is all your code strictly single-threaded, and runs a single processor core at 100% whilst leaving the other 7 idle?

          1. Peter D Bronze badge

            Re: Easier games to play

            "I guess your idea of writing multithreaded code is to FORK and manually use IPC, rather than just using async and letting the runtime manage it.

            Just because you can spend your life debugging race conditions, doesn't mean you should.

            Or is all your code strictly single-threaded, and runs a single processor core at 100% whilst leaving the other 7 idle?"

            Async/await in C# is nothing to do with multithreading. When an async function hits an await the function becomes split at that point and the code following gets wrapped as a completion routine which gets processed on the same synchronisation context so execution can return to the caller while it completes during idle time on the same thread. The async modifier indicates that the return result of the function will be wrapped in a Task generic for that type which can be awaited on. The code only becomes multithreaded if you create another Task on which you call Run. In most cases you remain single threaded and your code has full thread affinity. In short async can allow you to make optimum use of the synchronisation context to do different things while waiting whereas multithreading allows you to make use of multiple synchronisation contexts to do things in parallel. The reason async applications which are busy appear to be shared over multiple cores is scheduler hopping which may continue a thread on a different core to the one it was paused on. It's still one thread.

            1. 9Rune5

              Re: Easier games to play

              Absolutely.

              However, for most developers multithreading was a way to relatively easy carry out multiple IO operations in parallel. (because the OS' async functions were cumbersome to use, so for 80%+ of us those functions were never an alternative)

              async/await solves that in a comparatively elegant fashion.

              Plus, Task.Run() makes it easy to include CPU intensive operations (as a separate thread) within the same paradigm.

              1. Peter D Bronze badge

                Re: Easier games to play

                It does, indeed, allow you to mix styles. It still amazes me how many people I interview wrongly associate asynchronous coding with multithreading. Each can use the other but they aren't the same.

        5. katrinab Silver badge
          Paris Hilton

          Re: Easier games to play

          I liked the "Hello World" in Delphi, because you could put a text box on the screen, change its caption to "Hello World", and hit the Compile button.

          Why can't modern things be like that? I prefer to concentrate my coding efforts on actually doing stuff rather than having reams of code just to draw the UI on the screen.

          Also, Delphi could compile a fairly large project in no time at all on a Pentium with 16MB RAM. Why is my Threadripper with 128GB RAM so much slower?

          1. Loyal Commenter Silver badge

            Re: Easier games to play

            You do know that if you create a new console project in .Net 6, the default template does that without you actually having to write a line of code? They've even done away with the need for a namespace and default class / entry point method, although I prefer to still use them myself, because I have an implicit dislike for such things being implied.

            As for the usefulness of templating "hello world"? Well, you can make your own judgement on that...

      2. TDog

        Re: Easier games to play

        I turn to drink before.

        1. W.S.Gosset Silver badge

          Re: Easier games to play

          DON'T GO DOWN THAT ROUTE!!

          Keep the drink right in front of you.

  5. Gene Cash Silver badge

    Kerbal Space Program

    Written in Unity, runs on Linux using Mono, and thus I can play it, and it was mature enough to do so in mid-2013. Heck, it was the incentive for me to migrate my Debian box from 32 to 64 bits.

    Holy cow, have I been playing it for almost 10 years? The Register always makes me feel old, sad, and tired.

    1. StrangerHereMyself Bronze badge

      Re: Kerbal Space Program

      I've been playing BZFlag for more than 20 years. So go figure.

  6. Doctor Syntax Silver badge

    "So MAUI is a wrapper around existing UI stacks."

    Obligatory https://xkcd.com/927/

    1. Nugry Horace

      I was expecting https://xkcd.com/2347/

      1. David 132 Silver badge
        Thumb Up

        As Randall climbs ever onwards towards the 3000-strips mark, we are long past the point where there's an "oblig. XKCD for every topic".

        Nope. Now there are usually several of them.

        1. Yet Another Anonymous coward Silver badge

          So not only do we live in the Matrix but it's rendered as stick figures

          1. W.S.Gosset Silver badge

            "This is your last chance. After this, there is no turning back.

            "You take the blue pen — the story ends, you wake up in your bed and believe whatever you want to believe.

            "You take the red pen — you stay in Wonderland and I show you how deep the rabbit-hole goes."

            1. Nugry Horace

              https://xkcd.com/566/

  7. minnsey231
    Windows

    Alas poor SOAP!, I knew him

    I'm old and grumpy enough to remain stubbornly convinced that REST only triumphed over SOAP because of the shitty SOAP tooling in Java.

    In Visual Studio with C# SOAP was a doddle, "just worked" and did all the things.

    Anyway back to my hodge-podge of Java HTTP, JSON, JSON-SCHEMA, Swagger, OpenAPI etc to do some of the things ...

    Sigh.

    1. Charlie Clark Silver badge

      Re: Alas poor SOAP!, I knew him

      SOAP failed for more reasons than poor tooling: it was both bloated (because, well, XML) but also incredibly limited. There was the hope of universal mini-services that we'd all end up using but that was before people realised that nice APIs are hard™. Actually, all APIs are hard, nice one are even harder.

      1. badflorist

        Re: Alas poor SOAP!, I knew him

        SOAP failed because it couldn't be standardized. Well it could, but they it'd have to contend with what already worked identically i.e. PHP/C++/PERL/Java/whatever...

        "...the hope of universal mini-services"

        How about, the hope of locking people in with patented "web" API's...?

        Not sure about the "all APIs are hard" bit, can you give an example? If you mean the error-checking/security then sure, but if you mean the interfacing....?

        1. bombastic bob Silver badge
          Devil

          Re: Alas poor SOAP!, I knew him

          sometimes it is convenient to make a server API look like a web request. Something like:

          http://server.example/project/functionality/parameter/parameter/parameter

          there are many ways to implement handling this. The advantage is being able to use a simple utility like curl to invoke it, or if you are into client side script, invoke it from javascript (preferably using native asynchronous methods and NOT some bloaty-lib like JQuery, grump grump grump)

          (it's all about what is easier to parse, a URL like this or a bunch of GET parameters)

          1. LDS Silver badge

            "sometimes it is convenient"

            Yes. **Sometimes**

          2. badflorist

            Re: Alas poor SOAP!, I knew him

            "http://server.example/project/functionality/parameter/parameter/parameter"

            I stay away from that, but it's most certainly handy for "dead bang" stuff. I hit a pitfall with it once. Simply put, the parsing *could* hit a short link and seem valid. ie.assume both "/valid_token" and "/valid" have endpoints: /valid_token ... /valid/_token ... Yeh I'm not saying it actually comes up in the wild, but I'm paranoid :-P.

        2. Charlie Clark Silver badge

          Re: Alas poor SOAP!, I knew him

          Not sure about the "all APIs are hard" bit, can you give an example?

          I mean creating nice APIs. Like naming, it's one of those bits of IT that is often overlooked but when you're developing software, you often do it for yourself and know how you want to use it. The API, a bit like grammar in human language, only becomes necessary when someone else wants to use it.

          Then, once something has been released, you realise all the things that should have been done differently and would like to change: can you change the API?

          You're right, of course, about some of the ideas that companies had for extremely low value services that would then be proprietary but SOAP failed really because despite it's complexity it couldn't deliver anything very useful, not least because XML is shit for typing.

          The API stuff came on top: each online weather, travel, etc. service had a completely different API. JSON ended up promising less but delivering more (yes schemas are a problem, but at least basic types were supported) by being simpler a hell of a lot faster.

      2. LDS Silver badge
        Devil

        "but also incredibly limited"

        So we replaced it with more and more limited alternatives.... and "bloated" is the second name of any web "technology".

        1. badflorist

          Re: "but also incredibly limited"

          "...we replaced it with more and more limited alternatives"

          I feel it hasn't been replaced but just a lot more GET'n done. The reemergence of the concept of "REST" was more like a make-it-trendy-by-giving-it-a-name way of returning to how it was always done prior... GET.

          Even outside of FETCH/GET, WebSockets in languages all have the same API's, at least I can't think of 1 that doesn't (there probably is though), and nothing is hard about them.

          Websockets are a appreciated feature for me. It's handy when I just want to send bytes, not text. For example, if I read every byte of a 4-byte float on the server and send those bytes to the client (which parse back to float via DataView/WASM/whatever), it's significantly faster over a websocket than it is with FETCH/GET. In fact, I can send an entire payload of gyroscope , accelerometer and magnetometer data 10x vs. FETCH/GET :-/.

    2. Not Irrelevant

      Re: Alas poor SOAP!, I knew him

      I think it's because of JavaScript. Consuming SOAP in JS is painful. At least OpenAPI sort of, kind of, blunts the biggest issues with REST.

    3. Loyal Commenter Silver badge

      Re: Alas poor SOAP!, I knew him

      SOAP was anything but simple, relied on XML (and therefore massive, restrictive, schemata), and didn't have the flexibility of REST APIs, and the way most things are very forgiving in parsing JSON.

      For example, if a property is missing from a JSON structure, most APIs will assume the value for that is null. Similarly, if a chunk of JSON has an unexpected property, most APIs will ignore it. This allows for easy forward and backward compatibility for non-breaking changes, without having to have multiple schema versions, and versioned endpoints. In the Real World™ this happens a lot.

      Oh, and data size - JSON is much more compact than XML, even if you choose really short and meaningless tags for all your data. This has a real-world effect in things like network throughput and storage.

      So basically, REST killed SOAP, because JSON, rightfully, killed XML.

      1. badflorist

        Re: Alas poor SOAP!, I knew him

        "JSON is much more compact than XML"

        I'm on your side but... _MUCH_ more? No, not at all. People think this because they have horribly formatted XML, but if that XML is formatted identically to the spec. of what the JSON should be, you're going to be surprised. The killer here for XML is that you'll need either a white space between attributes or a "=" sign. However, that is countered in JSON with the colon (:) and comma (,).

        I've written a several things for "DAT" files for "ROM's" which use the bare basic XML syntax (no CDATA or anything crazy) and size is a flip of the coin if you should choose to compress. To be clear here, the things I've written are specifically for 2-way conversions of XML to other formats (XML, CSV, JSON, YAML, etc...) to be able to import into other "ROM managers". Uncompressed JSON compared to uncompressed XML, when both are formatted to the identical spec., is ~2% smaller, so JSON is a little smaller. Now if you do get crazy, you can use XML's CDATA (a.k.a. blob) and make things very small and still have some validation, but that's a PITA and most people don't want to deal with CDATA (rightfully). The real pain is converting BACK to XML with out a stem/source/reference of the original spec... that's a long explanation but I think everyone can envision that nightmare and people are EXTREMELY picky about their "ROM" collections (so you can't afford to fuck anything up).

        1. Loyal Commenter Silver badge

          Re: Alas poor SOAP!, I knew him

          Compare the following:

          <object><property>value</property></object> - 45 characters

          "object":{"property":"value"} - 29 characters

          I've chosen fairly short "object" and "property" names here as well; typically in a large XML document, they're going to be more specific, hence longer. Either way, in this example, the JSON is less than 65% of what the XML is, and that's before you start including things like DTDs and namespaces.

          Add to that the fact that JSON is much more human readable, and it's no wonder it's now the de-facto standard for data interchange.

          1. Anonymous Coward
            Anonymous Coward

            Re: Alas poor SOAP!, I knew him

            <object property=“value” />

            27 characters.

            1. Richard 12 Silver badge

              Re: Alas poor SOAP!, I knew him

              Nice try.

              Now add some sub-properties to property, or an array of values. Can't do that at all this way, so you'd have to radically change the schema.

              The removal of the tag name from the closing element means JSON is smaller in the vast majority of cases, and it's also easier to parse because you don't "need" to compare the closing tag name with the associated opening tag.

              Of course json does not permit open-a, open-b, close-a, close-b, but one shouldn't do that anyway.

          2. Missing Semicolon Silver badge

            Re: Alas poor SOAP!, I knew him

            But then some muppet tries to buck the requirement for a schema, and defines everything with <parameter><name>property</name><value>foobar</value></parameter>. Seen it done.

      2. bombastic bob Silver badge
        Meh

        Re: Alas poor SOAP!, I knew him

        because JSON, rightfully, killed XML.

        no, JSON did not kill XML. XML has its uses, and I suppose JSON has its uses also. Neither is a panacea, nor do they really compete. Handling XML in javascript is not that difficult really. Yes i have done it, No I do not use bloaty libs like JQuery. It's easier to implement XML in my opinion when you use something like PHP or a C language program to create it. But hey, some people prefer JSON. Whatever.

    4. Plest Silver badge

      Re: Alas poor SOAP!, I knew him

      VHS vs Betamax?

    5. rmullen0

      Re: Alas poor SOAP!, I knew him

      I agree. Writing REST at the "bare meta" is a total PITA. Advocates of it, never used SOAP where you just generate a client and you are done.

    6. rmullen0

      Re: Alas poor SOAP!, I knew him

      I should add the Microservices are a complete sham also.

  8. Oliver Reed

    Still have my copy of J++

    Boxed and in mint condition.

    Used once.

    1. Yet Another Anonymous coward Silver badge

      Re: Still have my copy of J++

      It's only worth anything if it's the original vinyl

  9. AMBxx Silver badge

    Memories!

    I went from VB6 to .Net. Biggest disappointment was that I still couldn't design a web UI in the same way as a windows UI. Still had to much about with styles and stuff.

    1. Ross 12

      Re: Memories!

      Good thing too! VB UIs were generally terrible

      1. captain veg Silver badge

        Re: Memories!

        Terrible they might have been, but supremely easy to construct. Even for people who had no idea of how to construct a UI. Which often resulted in them being terrible.

        -A.

    2. Loyal Commenter Silver badge

      Re: Memories!

      This is because the web separates (rightfully) semantics and presentation by design, whereas clunky old languages like VB (and the other one mentioned here in passing, FoxPro) didn't, leading to no separation of business logic and presentation layer, unless you enforced that yourself by strict discipline.

      I'd prefer to use a tech stack that is designed around doing things the right way, rather than having to beat other people's code into conformity in order to make software maintainable.

      1. emfiliane

        Re: Memories!

        You must not remember the web of the late 90's and early 00's, which began with rampant abuse of HTML tables, iframes, and early vendor-specific CSS and other non-standard styling methods. And flash/shockwave, java applets, and other plugins that replicated a desktop UI to a browser.

        It wouldn't really hit until 2005 or so that this was anti-everything and wouldn't be until ~2010ish that the web started really getting broadly on board with the idea. The increasingly rickety teetering tower of junk piled on top of the web is most likely what brought the W3C back to relevance, as well, as more big players decided they needed to invest in a better way forward, lest Flash take over the world.

        1. Loyal Commenter Silver badge

          Re: Memories!

          Indeed, "web 1.0" was all about markup - pure semantics, then, because it was still a niche thing, various people got in on the game and idiocies like <blink> and <marquee> were born. It was corrupted pretty early on. This wasn't helped by various competing scripting languages (anyone remember ECMAscript?), Flash, Java applets, et al. It was a free-for-all.

          Modern frameworks, 25 years on, do separate things out properly, but it has been a long journey getting there.

          Modern languages, similarly, make it easier to do things properly. VB, and VFP do not. Some of us poor folk still have to maintain 30+ year-old code written in these languages. You really come to appreciate the modern tools, like Visual Studio, and the tools it provides for refactoring when you find yourself in this position.

  10. Howard Sway Silver badge

    The influence of Java on .NET is complex

    Maybe in the details, but not at heart. The fundamental difference was :

    Java : write in one language, run on many operating systems

    .NET : write in many languages, run on one operating system

    I spent many years in the Java world, but I thought C# had some decent ideas too. But both have become monstrous messes, overly tied into countless terrible frameworks, which means almost no 2 teams of developers use the same tools and processes any more.

    I've gone back to C++, the modern features are lovely to use, and what was so hard about learning about compilers and how your OS actually works anyway? Sure beats having to use frameworks running within containers running within VMs........

    1. minnsey231

      Re: The influence of Java on .NET is complex

      For reasons beyond my understanding Java has tended to add modern language features purely at the language level,

      e.g. AFAIK generics are still actually compiled as old style Object collections, whereas .NETs (more brutal?) approach has meant new features like generics are implemented in the runtime.

      IMHO this gives much better features in C#, although the day job remains in Java.

    2. Anonymous Coward
      Anonymous Coward

      Re: The influence of Java on .NET is complex

      Current versions of .NET support Android, Ios, Windows, Mac and Linux.

      1. Anonymous Coward
        Anonymous Coward

        Re: The influence of Java on .NET is complex

        But .NET doesn't provide a graphical UI layer on anything other than M$ Windows.

        1. Loyal Commenter Silver badge

          Re: The influence of Java on .NET is complex

          The native Java UI is hideous, and always has been, and .Net provides lots of ways of interacting with the UI layer of the underlying OS. You can do lots of things cross-platform as well, like doing your UI layer as a web page (which, in case you hadn't noticed, is how a lot of business work in the present day), or using something like Xamarin, which is implemented in Mono, so is cross-platform.

        2. minnsey231

          Re: The influence of Java on .NET is complex

          There are a number of cross-OS UI implementations, Avalonia being perhaps the best.

          Xamarin also allows the use of the native UI framework.

        3. richardcox13

          Re: The influence of Java on .NET is complex

          > But .NET doesn't provide a graphical UI layer on anything other than M$ Windows.

          But Web Apps do.

          Who wants the distribution hassle of a local app when not needed? (This also applies to mobile: I suspect 90+% of mobile apps could be simpler as a PWA.)

  11. Peter D Bronze badge

    C# exists because of .NET

    And it's one hell of a language. It's very well thought out and incredibly powerful.

    1. LDS Silver badge

      Re: C# exists because of .NET

      Of course. It wasn't designed nor from the VB Team nor from the C++ one. It was designed by someone who designed far better languages...

      1. W.S.Gosset Silver badge

        Re: C# exists because of .NET

        > far better languages

        He reckoned his _overriding_ primary objective with C# (at least originally/core design) was fast compilation. Fast enough to compile as you typed.

        That's why it's only a 2-pass compiler (with about 37(?) steps, per an explanation+enumeration of his I read nearly a decade ago).

        (Similarly, various core design decisions in C++ were driven by Bjarne's goal of writing it as a 1-pass compiler. He couldn't quite manage it, hence 2-pass.)

        1. david 12 Silver badge

          Re: C# exists because of .NET

          Pascal lost all the battles, but won the war: modern languages and compilers, including modern c compilers, adopted the design decisions of Wirth Pascal, not K&R c.

  12. knarf

    20 Years of me DotNet-ing

    Still got my boxed version of VS2002

    been a wide ride, but you can get code out quickly and likely most .NET 1.1 code will compile (mostly) today.

    It did try stuff then abandon it with ease much to the demoanment of some devs and some of the "experiments" where truly awful.

    But on the whole its good to work with.

    Community has been really good and supportive over the years.

    1. Tom 7 Silver badge

      Re: 20 Years of me DotNet-ing

      Not sure 1.1 code compiles. When it came out I leapt in and wrote some pretty nifty stuff in C# and .Net. And then came 2.0 and you couldn't host the two on the same machine (All the bollocks about the end of DLL hell came to nothing). And most of my code wouldnt work on 2.0 without considerable reworking.

      I had to go back to VB because no-one else where I was working could understand C# and missed some of the aspect of C# but I never really agreed with the way .NET handled things, it always seemed to try and re-invent the way CSS/styling etc worked in HTML, sucking it into the code rather than CSS files but this was 25 years ago so my memory may need a dynamic refresh.

      1. david 12 Silver badge

        Re: 20 Years of me DotNet-ing

        Fascinating the off-hand comment about the new Windows menu system using c#. For the longest time, you could not use c# for shell extensions, only because it all ran in one process, and it couldn't run multiple .net versions in the same process.

  13. bombastic bob Silver badge
    Megaphone

    I am SO glad the article actualy points these things out

    the technology in .NET came from the Visual Basic team

    Why am I *NOT* Surprised!!!

    It was before its time. Computer hardware just wasn't ready for most of the ideas in Longhorn

    See, THIS is the *kind* of "thinking" that gets us BLOATY CRAPWARE in which the computer system performs WORSE than its predecessor did, even when the predecessor ran on INFERIOR HARDWARE!!

    so we did built the Start menu on .NET, on modern Windows

    Oh, the "Start Thing" was ALSO based on dot-CRAP then ? NO surprise either!!

    (and that word "modern" does not mean what they think it means...)

    according to StackOverflow surveys, .NET is top in one of the "most loved" categories

    Obviously not a representative survey. Most loved by "Copy Pasta" "developers" MAYBE...

    It's also notable that .NET applications are increasingly deployed on Linux.

    went from ONE to TWO then??? (obvious snark here, yeah)

    its appeal to new programmers is limited.

    One of my biggest GRIPES about Micros~1 hyping whatever "new shiny" they come up with is that it makes the assumption that senior developers MUST RE-LEARN this "new shiny" instead of being PRODUCTIVE with what they are ALREADY GOOD AT. Hesitancy is what results from this kind of "new shiny" "thinking".

    C# and the .NET platform have been a remarkable success

    I do not think "remarkable success" means what you think it means...

  14. Anonymous Coward
    Anonymous Coward

    "It is our intent to take the full intellectual property in this common language runtime and these class libraries and offer them to standards bodies so they can become a truly open set of standards,"

    (Quietly): "and then in our implementation, we'll ignore those standards in subtle but annoying ways"

    1. Fred Daggy Bronze badge

      (Quietly): "and then in our implementation, we'll ignore those standards in subtle, barely or not at all documented AND annoying ways"

      FTFY

  15. captain veg Silver badge

    nice article, but...

    > VB was wildly popular but not object-oriented

    Well, actually it was. Before VB4 the only objects you could instantiate were forms (and controls) admittedly, but thereafter it was totally oriented to objects.

    Not necessarily in the way that all of it's users might have wished, but there were classes and inheritance, polymorphism (of sorts) and, unlike .NET descendants, deterministic finalisation. Which was useful.

    > ... complex and intricate for advanced use with COM

    On the contrary, it made COM work without even thinking about it. As of VB4, the language became a wrapper around COM rather than User and GDI. Given that COM is short for Common Object Model, the "not object oriented" claim rings hollow. Writing C(++) code for COM was, I agree, somewhat complex.

    > bested in nearly every respect by Borland's Delphi

    If you like. Delphi executables were *enormous*, because the entire runtime got compiled in. And you could always tell a Delphi program for the non-standard look of the controls. No bad thing, in itself, but at the time we were trying to make programs that looked at home on Windows.

    -A.

    1. 9Rune5

      Re: nice article, but...

      Delphi gave you the option of linking everything in, but you could distribute runtime dlls just like you could with VB.

      However most of us kept things simple and actually preferred linking in everything. At least we had a choice. Odd thing to criticize a tool because it gives you a choice.

      As for non-standard look; that too was optional. Again: There was a choice.

      Back in 2009 I made a simple screen reader that would extract strings from edit controls. It worked wonderfully with all apps, except apps written in VB. VB's text entry control is anything but standard. I had to OCR that thing. There was nothing Windows standard about VB. Just because you were limited to ugly GUI with VB doesn't mean it was a great tool. (And MSFT never learned how to make a decent form designer -- feel free to check out how tab order is solved in Delphi)

    2. david 12 Silver badge

      Re: nice article, but...

      I don't remember Delphi executables being enormous: rather, I remember them being smaller than Visual c executables. But it was a long time ago and I could be wrong.

      However, Delphi always had a smart linker, and it was never necessary to link in the entire runtime. It had c++ like method tagging, which enabled the linker to exclude unused methods, and the object format included full dependency chains.

    3. Ken Moorhouse Silver badge

      Re: you could always tell a Delphi program for the non-standard look of the controls

      Ha, look at the Standard way of displaying controls now.

      A policy of inheriting from controls that NOW "look [more] at home on [legacy versions of] Windows" turns out to be a good choice IMHO.

    4. LDS Silver badge

      "because the entire runtime got compiled in."

      Delphi has no runtime - in the VB meaning. Delphi executables are plain Windows executables. Delphi application are by default linked statically so they have all the used libraries code linked into the executable. That makes distributing Delphi executable really "xcopy" - you need just one file. It is no different from a C/C++ application where you link everything statically.

      The executable also has several resources that are used to create windows and their controls, as the designer doesn't generate only code for that.

      You can link dynamically if you wish and distribute library DLLs with it (they are called "packages" because they have support for objects too, not plain functions only) - the sum of the file sizes will be larger than a single executable size.

      Delphi controls are exactly the Win32 controls but for those controls that don't exist in Win32 (i.e. grid controls). The VCL library simply wraps them into classes. You won't be able to tell an application is written in Delphi when it uses only the Win32 set of controls.

      Delphi never used the bwcc32.dll that delivered the "Borland Custom Controls" that was used by Borland C++.

  16. thames Silver badge

    Mono

    The section on Mono skipped over a lot of history which is important if you want to understand why it flopped on Linux. That's understandable because you could dedicate the whole article to the history of Mono and just scratch the surface. I'll just satisfy myself with adding in a few more details.

    Novell had bought Suze and was looking for life beyond Netware as an enterprise IT vendor. They bought Suze and were buying up various other assets. One of them was de Icaza's company (the name of which escapes me) which they bought for its management software (which didn't last long).

    De Icaza had been working on the idea of an open source equivalent of Java (which was still proprietary). He sold the idea to Novell that they couldn't be a real enterprise vendor if they didn't have their own complete "stack" like Sun or Microsoft. This role was to be filled by Mono, with Novell writing the cheques to finance development.

    Reception among developers however was cool. A few were openly hostile for a combination of reasons. One was concern about the legality of the licensing, as doing anything actually useful with Mono required going well beyond the specifications that Microsoft made open and required copying stuff that definitely was proprietary to Microsoft.

    Another reason was that de Icaza was going around trying to hijack other projects to get them to convert to using Mono in order to get some sort of a user base. He got a lot of push back from that. He also got his employees to write desktop applications for Gnome and used his personal connections with Gnome project managers to push them into Gnome as defaults. Once those people moved on to other things however, those applications were rapidly ejected from the defaults and replaced with stuff that actually worked reliably and without being resource hogs.

    The main reason Mono didn't succeed in its target though was the supreme indifference which most potential developers or users had towards it. Dot Net developers weren't going to use Mono because they used MS Windows and that had the original Dot Net already, which was covered under Microsoft support contracts. Why pay more money to Novell just for Mono support? Java developers had no interest in switching from Java. And finally all the other Linux users simply didn't see Mono solving any problems that they actually had. They had other languages and tools which did what they wanted with much less effort, and if they had wanted a Java clone they would have been using Java (which most weren't).

    Novell's strategy for reinventing themselves was faltering, and one of the casualties was their Mono subsidiary, which was spun off with de Icaza still in charge of it.

    De Icaza finally found a user base for Mono, one that he had never expected. This was as a run time for game engines in competition with Dot Net. Game engine companies felt they were being bent over a barrel by Microsoft and were looking for someone who would offer a compatible product with more reasonable licensing terms.

    Finally, here was a user base for Mono, and one that was willing to pay money to use it. De Icaza binned any ideas of being an enterprise full stack and focused on the game and mobile markets The core of Mono was still open source, but the profitable bits around it were taken proprietary.

    Eventually Microsoft bought them, although more for the game and mobile assets than Mono itself.

    I looked at Mono a few times to see if had potential use for a project, but always came away with a poor impression of it. It was slow and buggy, and documentation was pretty much non-existent once you tried to dig below the facade. Stuff may work if there was direct paying customer interest in it working, while for the rest it was haphazard as to whether it worked at all.

    Mono pretty much vanished without a trace from the Linux news years ago. Any interest now seems to be from people trying to move their legacy Windows Dot Net server applications from Windows to Linux cloud VMs to cut licensing costs.

    1. StrangerHereMyself Bronze badge

      Re: Mono

      It's slow and buggy just like Xamarin.Forms that's descendent of it.

      BTW Xamarin.Android is pretty fast and works just as well as the native Java stack.

    2. arctic_haze

      Re: Mono

      Also investing too much in Mono development was risking getting entangled in Microsoft legal wars if it went the Oracle way. A remote but not improbable constant threat.

  17. StrangerHereMyself Bronze badge

    AOT compiler

    I consider C# one of the greatest computer languages ever made, although I'm more and more skeptical of the endless additions to the language which solve only edge-cases and detract from keeping the language clean and simple.

    GC languages are the perfect solution for most programming problems since they allow a programmer to create objects left and right and let the computer figure out when to clean up the used memory. This is a natural way for a developer to work, although it does sometimes lead to inefficient or code which may exhibit memory-leaking type behavior (memory usage keeps increasing)..

    The ony thing I'm missing is a good AOT compiler. I know there are several but they're not in general use by Microsoft or only used in limited circumstances. Solving this could propel C# to truly become a C++ replacement.

  18. ettery

    Never mentioned: C# has been setting the pace over the last 10 years

    Yes, C# was Microsoft's answer to Java and took a lot from Java initially, but under the guidance of Anders Hejlsberg has matured better than Java, which is now playing catch-up.

    Features have been introduced which make coding in C# more concise and elegant, with better support for the functional and asynchronous paradigms than Java. This started in my mind with the introduction of LINQ in 2007 and has accelerated in the last 10 years. Java is following with the introduction of the Streams API (7 years after LINQ), Lambdas, pattern matching, async etc but are still behind, particularly in writing concise code. Going back to Java feels very clunky.

  19. stiine Silver badge
    Facepalm

    " so we did built the Start menu on .NET, on modern Windows, so there are remnants of that stuff around."

    That explains a lot...I think they need to add more whitespace...

  20. W.S.Gosset Silver badge

    Origin

    Something not described in the article: how/why .net came into being in the first place. Or rather, zeroth place.

    per some corporate insider articles I read mid-noughties-ish:

    The anti-trust legal action.

    The case was looking bad for Microsoft (the DOJ had learned their lesson after the last-minute debacle the first time), so Bill Gates personally prepped for handling the loss. To achieve a result acceptable to him personally.

    He would table a pre-fabbed plan to break up Microsoft into Windows and Apps, and to relinquish Windows (the real DOJ objective) and instead just take Apps. This would look like the DOJ had utterly won --and it'd be all ready to go and no dragged-out legal squabbles-- so they'd have difficulty justifying refusing it.

    And he didn't really care about Windows any more -- he'd won all the big fights; getting a bit boring.

    But Billiam still wanted control, or at least independence/insulation from idiocies by the new owners of Windows, and the web looked to be opening things up again. So he wanted an OS-agnostic/platform-agnostic layer which would look to the DOJ negotiators like not-OS-must-be-app. So he kicked off .net, and apparently drove the developers very hard in order to have something concrete come negotiation-time.

    Then his lawyers unexpectedly won the case.

    At this point the pressure was off, so he took his personal foot off the gas-pedal, and I believe handed it off to the usual Microsoft processes. Which takes us up to the beginning of what's described here as Project Cool.

    Summary: it was intended to be a defensive legal manoeuvre, which he turned out not to need. So it evolved fairly corporately thereafter (ie, scope drift, delays, etc).

    .

    At least, that's what I read. But it certainly matches his usual approach & thinking & lateral gamesmanship & drive, back in his hands-on days.

  21. arctic_haze
    Coat

    A circle of mutual adoration

    Everyone here seems to be in love of the ever changing Microsoft development tools while the future is... Rust.

  22. Korgonzolla

    Steve Ballmer really milked the old Microsoft model as far as he could. He was right though when he went on stage in some state of excitement and proclaimed 'developers, developers, developers'.

    C# is a flawed, but beautiful language for the type of programming it is needed for.

    Visual Studio and VSC are flawed, but beautiful environments for people who write software to work in.

    Powershell is a flawed, but competent environment for automation.

    Azure is a flawed, but competent environment for delivering computing workloads based upon the software being written by users.

    You might not like MS; but they have the nuance to remain relevant.

  23. Daniel von Asmuth
    Windows

    hailstorm

    Microsoft may have confused the competition with their .NET strategy. You had an MS Office .NET, Windows .NET, Visual Studio .NET, etc. If I remember correctly, the core part was their attempt to monopolise the web with Microsoft Hailstorm and Microsoft Passport. The rest of the computer industry would not follow the leader.

  24. rmullen0

    ASP.NET Core sucks IMHO

    I still need to investigate Blazor more, but, I think Microsoft did a poor job with ASP.NET post-Web Forms. MVC was a big step backwards IMHO. I think they should have kept and improved upon Web Forms. They should have added a robust set of UI controls like what Telerik offers. The idea of programming at the bare metal level is a bad one. It isn't productive. I'm still on Web Forms using Telerik controls for intranet apps. It is very productive. Maybe I will switch to Blazor, but, I am not convinced that it is fully baked. Microsoft has a tendency of coming out with new things and then killing them off. Personally, I think the original ASP.NET team did a better job. I'm not sure what happened, but, I think everyone on the original team must have left. Same thing for .NET Core. They did a relatively poor job with that whole port. The new stuff over does design patterns IMHO. It was easier to work with before. Maybe Blazor is finally a replacement for Web Forms, but, everything in between has sucked IMHO. I thought they had the design right to begin with. Then, they decided to parrot Ruby On Rails.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like

Biting the hand that feeds IT © 1998–2022