Has a Decade of .NET Delivered On Microsoft's Promises?
558
cyclocommuter writes with this snippet from The Register's assessment of whether
Microsoft's .NET framework has been a success: "If the goal of .NET was to see off Java, it was at least partially successful. Java did not die, but enterprise Java became mired in complexity, making .NET an easy sell as a more productive alternative. C# has steadily grown in popularity, and is now the first choice for most Windows development. ASP.NET has been a popular business web framework. The common language runtime has proved robust and flexible. ... Job trend figures here show steadily increasing demand for C#, which is now mentioned in around 32 per cent of UK IT programming vacancies, ahead of Java at 26 per cent."
Depends on the goals (Score:4, Interesting)
It depends what the goals were.
If they wanted to completely depose Java then no, Java is still there.
If they wanted to introduce a Windows-centric alternative to re-invigorate desktop development and replace the horrors of C++ and VB with something with more modern and useful layers of abstraction and code checking that were already in Java (typed delegates, generic types, garbage collection, etc) then it seems to have done all right.
If they wanted to tear the OSS world in two with arguments over whether it .Net "teh evilz" or not then that'd be a definite yes, even thought more and more patent covenants are coming in to cover Mono (despite the fact that patent covenants shouldn't even be necessary if the legal system was sensible enough not to allow the patenting of software).
No Java or C# please (Score:4, Interesting)
I was initially excited by .net when it was first released and have preferred it over Java, which as a language seemed to have stagnate. Now, I am finding C# quite a disappointment with Microsoft not investing the time and energy to ensure the features they add to the language are polished:
* Adding extension methods without also adding extension properties
* Refusing to implementing covariant return types
* Adding type inference, but disallowing it for class method return types
As so forth. Microsoft simply doesn't have the discipline to finish any feature addition to the language before moving to the next.
That doesn't mean I prefer Java either. I only use Java and C# at work out of necessity.
My language of choice is now Scala.
Re:.Not (Score:1, Interesting)
> Joking aside, Java is multiplatform in practice and .Net is only in theory.
Well except for all the software written in C# to run on Mono...
Yes (Score:2, Interesting)
If web application development was still as horrible as it was with asp.net 1.1, I would have given up years ago. With .NET 2.0, it finally became usable. When they introduced AJAX update panels, it became far better than anything else in the market.
I've been using asp.net 3.5 lately, and I have to say that I am very happy with this development environment. Every other data access layer feel like a complete waste of time compared to LINQ to SQL. I love the way it helps me produce insanely good work very quickly.
I can't even begin to express my gratitude for the programming language that has paid my bills for the last 3 years.
Almost (Score:3, Interesting)
Speaking strictly from a Windows development perspective, I think .NET has improved the experience somewhat compared to other kludgy frameworks (MFC / ATL). Assuming you don't plan on any cross platform deployments, you can implement your application within .NET using all of the capabilities of the operating system in an object oriented fashion. It's quick - it's easy - and C# is close enough to C/C++ that anyone with a programming background can pick it up.
Where Microsoft missed the mark is on the promise that their own applications would migrate to .NET. For example, Microsoft Office would get re-written as a .NET application. Ironically, I think it's because of the lack of cross platform capability that .NET was unable to meet this need. Microsoft has a number of key software products that need to run on both Mac and Windows. While native C/C++ can be easily ported, without a compatible CLR moving to Mac isn't that easy.
Had they been able to meet the portability objective (which they never promised), I think .NET could have been much more prevalent. For now, it will continue to be a second-best development environment for Windows computers (with C/C++ being the primary).
It is not a Java vs .NET world (Score:4, Interesting)
Re:.Not (Score:4, Interesting)
The interesting thing was that Sun used WORA as a surrogate argument to accept the validity of virtual machines. It's hard to imagine now, but there was a time when VMs were treated with scepticism or outright hostility by most programmers.
These days it's hard to imagine creating a programming language that wouldn't adopt a VM of some kind.
Neither the CLR or the JVM truly enable WORA, but it doesn't matter. We have learned that VMs have a value to a programming language *far* beyond that rather limited concern.
Re:.Not (Score:2, Interesting)
So what?
I'm on the verge of abandoning Java for my projects. Currently, there's just almost no business reason to use it. Microsoft tools (+ReSharper) are now as nice as tools for Java, ASP.NET is as good as any Java web framework, and WPF totally kills SWING on the client.
Oh, and Microsoft _really_ supports multi-language programming. MSVS 2010 has full official support for F# (Ocaml clone) and extensions for dynamic languages in the CLI. And even plain C# is _much_ nicer than Java (LINQ, anonymous types, type inference, real generics, closures, etc.).
It wouldn't be as bad if Java was improving. But right now it's stagnating fast.
Oh, of course there's Scala. But it exists mostly to prove that JVM is not really for Java, but it's also suitable for horrible hacks required to run other languages. And in any case, there are no good IDEs for Scala development.
.NET or .NOT? (Score:5, Interesting)
The answer is, as always, it depends.
If you expected cure for cancer, it failed miserably.
However, if you were involved with any of the likes of MFC, ATL, Visual Basic 6 and bellow, DAO, Interop & COM (to name just a few), it is to be regarded as the second coming of Christ.
Goods and Bads (Score:4, Interesting)
On the other hand,
Overall, I'd say I'm on the fence. I wish Sun would remove head from ass and get the JRE to a better versioning system that allows old apps to keep running along with new apps, similar to the
Re:Asp.Net is NOT a 'popular' business framework. (Score:5, Interesting)
Well of course you will. The projects on those sites are looking for cheap implementation and damn any sort of quality or maintainability. The register didn't look at those sorts of sites, they looked at recruiting sites instead, the ones businesses use. Using the slime pool that is the "Write me a twitter clone for $100" sites to say LAMP is the most popular in businesses is laughable.
Re:Java too complex (Score:3, Interesting)
You're right, of course. Microsoft Research has a number of fellows who are at the very cutting edge of programming language research, including the likes of Simon Peyton Jones (Mr Haskell) and Don Syme.
And these people have had a direct hand in the evolution of C# (through its type inference, lambdas and LINQ), through F# (which started as a project to port Haskell, and then O'Caml to the CLR), the DLR, Parallel Extensions...
The level of geekiness that Microsoft encourages at the top end of .NET is remarkable.
MS really does care about making devs happy (Score:5, Interesting)
Of course their reasons for doing it are not benevolent, they want software designed for Windows so that users want to use Windows. Regardless, they produce extremely slick dev tools because of it. Often the things maligned by self proclaimed "real" programmers are actually quite useful dev tools in the right situations.
Visual Basic is a good example, all sorts of geeks liked to hate on VB as being stupid. While they were on to something in that VB wasn't powerful like C/C++, they missed that the reason was that VB was a managed language back before such a thing was popular. It allowed you to easily churn out UIs and things like that with minimal effort and without the need to check for the gotchas you got with something like C. Hence it was quite popular.
What MS has done real well is realized that most developers out there are NOT the hard core "Give me a text editor or give me death!" types. They are people in business trying to get something done, and get it done with minimal fuss and hassle. They also likely have to put up with management idiots who want to change the requirements every 5 minutes and thus being able to rapidly change the software is a benefit.
They really do seem to be a company that is in touch with what developers want.
Re:Java too complex (Score:5, Interesting)
Powershell is pervasive now. Every MS product now has powershell hooks. Most command-line utilities are being folded into Powershell extensions. While the language itself is not to my taste(I much prefer the *nix shells still), it's a big improvement alright.
Re:Java too complex (Score:5, Interesting)
Java only has lost the war if you thing the entire world runs on windows and develops for Windows only, sorry it is like that!
I work in banking environments where the language is very strong, the reason simply is you develop on windows, then deploy on Unix and the deployment scales up to the big irons from IBM if you need to!
All I can see on C# side for now is that it has gotten the ground that VB and ASP had before, that is the market of develop for windows deploy on windows. Ok this is quite a big market but this is only one part of the picture.
Now with Android we also have a serious push of java being a very popular platform programming language for mobile phones again instead of the trash of J2ME.
It is not branded java but the Dalvik VM has clearly java roots!
As I said C# has mostly gathered the ground which was occupied by Microsoft before anyway, quite a big ground but territory java never had.
Re:Java too complex (Score:1, Interesting)
Except of course on the iPhone ... which can run games written in C# (e.g.using MonoTouch or Unity3D) just fine, but not those written in Java.
Steve Jobs is quoted as saying "Java's not worth building in. Nobody uses Java anymore. It's this big heavyweight ball and chain." (had to Google that to get the wording right).
The sad part is, it's true. Not quite all, but NEARLY all mobile games in Java preform very poorly, even on high end phones. That's not J2ME's problem entirely, neither is it J2ME's fault the online stores sucked, or the phones had crappy button layouts or poor hardware specs, or crappy operating system interfaces - but they did, and it tanked with them.
Sure, in theory, J2ME could be said to be dominant on mobile devices.
In reality, the iPhone SDK blows it out of the water in turns of how many in-use mobile apps use it and how much revenue it generates.
Re:Java too complex (Score:3, Interesting)
While all that is undoubtedly true, I question the extent to which its responsible for Java's loss in market share. Honestly, how many Java developers do you imagine even know what a "Hindley-Milner type inference" even is? Answer: not many.
I'd point to some other misc. reasons:
No, They Made Huge Mistakes (Score:3, Interesting)
2. Again, VB related, for the first time you couldn't take your VB code, compile it in a new version of Visual Studio and get all the benefits. Expecting people to throw away millions of lines of code and start fresh for no benefit whatsoever is an epic fail and Microsoft diverged totally from their past views on this.
3. VB related again, but there is still no RAD environment for
4. As such, a great deal of applications, mostly VB, that could went web based and weren't re-written in
5. There is still a ton of stuff written with COM, and interacting with it is still a huge PITA when it comes to deployment issues. They should have focused on simplifying this as much as possible. The
6. There are still a lot of applications where developers are not comfortable running it in a VM.
7. One area where
Microsoft has lost a great deal of what made their development platforms attractive because they think they are losing money by doing it and there are too many divisions like MSDN wanting a piece of the action.
Re:Java too complex (Score:1, Interesting)
The problem with "making all those decisions for you" is that writing good programs is hard and writing good frameworks is harder. Therefore, all else being equal the chances are that any given framework will suck. Five years ago Java had several hundred web development frameworks. 99% of those sucked and nobody used them, the others were built on the lessons learned from the sucky frameworks' mistakes, as well as the rare bit of genuine technical vision.
We've ended up with the Spring framework [springframework.org] in Java, which is a top-notch web development framework; the first one I've met that really truly does not suck, and web development isn't even the main point of Spring. Contrast that with the decision Microsoft made for your web development needs in the form of ASP.NET, which is pure unalloyed garbage. It's built around some completely ridiculous metaphors and tries to fight every reality of the web platform, leaving you with a programming environment that's about as flexible as a brick. You can build dumb intranet web views that are completely un-abstracted and welded to the tables you've laid out in your SQL Server database, with rather limited control over any non-elementary features over the DBMS, and if you try to step one inch outside of that mindset then it fights you every step of the way.
That isn't even an indictment of Microsoft's technical development practices as it is a reflection of the fact that they only tried once and (since the odds were against them) they blew it. Many Java frameworks that were as bad as ASP.NET or worse came and went, what survives today is far more likely to be made of stronger stuff.
Fortunately for Microsoft that doesn't matter, because in most organisations the people responsible who choose the organisation's preferred technical platforms are not the people who actually have to use them. As long as their effort can be used to rapidly create a facsimilie of the equivalent demos found in the Java glossies and the number printed by wc -l is smaller in their version than Sun's they're fine.
Re:Java too complex (Score:3, Interesting)
Re:MS really does care about making devs happy (Score:3, Interesting)
Hardly. They care about making companies happy sure; when "development" requires little skill, more people will line up for the job, pay will be less.
And, isn't that the point? Haven't we always said that programmers would automate themselves out of a job? I embrace that... I wouldn't want to be stuck programming in Assembler or C the rest of my life... I rather like other aspects a lot more... then again I'm not a hardcore programmer, I'm one of the business programmer types the GP mentioned.
Re:MS really does care about making devs happy (Score:3, Interesting)
Visual Basic is a good example, all sorts of geeks liked to hate on VB as being stupid. While they were on to something in that VB wasn't powerful like C/C++, they missed that the reason was that VB was a managed language back before such a thing was popular. It allowed you to easily churn out UIs and things like that with minimal effort and without the need to check for the gotchas you got with something like C. Hence it was quite popular.
It was very popular. Millions upon millions of lines of code were written in VB. The company I used to work for had invested a lot of money over many years in their VB apps. Then microsoft dumped VB6. We tried upgrading to VB.NET (using various wizards) but it proved virtually impossible. Basically we were screwed. The company that made the language we depended on had totally shafted us. We just didn't have the finances to rewrite everything in .NET and at the time I left the company, they still had no real way forward. I suspect similar stories have occurred in small software houses all over the world.
This is a real danger when using a proprietary language. If they stop making it, you're screwed.
Re:Alternate JVM languages will carry the JVM. (Score:4, Interesting)
Although Java-the-language has stagnated a bit (I don't know if JDK 7 will ever be complete, due to all the feature cramming), but there's been a lot of activity during the past few years on other languages that run on Java-the-platform. Groovy and Rhino (Javascript) have been available for the JVM for quite a while. JRuby is actually faster than "native" Ruby for a lot of real-world applications. The Lisp-like Clojure language has a lot of fans. IMO, Scala is the most interesting out of all of these, with a very sophisticated type system, as well as functional features that the cool OCaml and Haskell kids seem to love.
All those third-party JVM-hosted languages have two big problems hampering their adoption.
The first one is lack of proper IDE support. And the problem with this target is that it shifts constantly - ten years ago we had much less than we have today. Think about how many automated Java refactorings a typical Java IDE offers today. Then there are things like code pattern search in IDEA. And so on... the challenge of making a new language is making all the tooling for it as well, and it inevitably competes with feature-rich and mature solutions that already exist for Java.
The second problem, which is probably even bigger, is the lack of a big corporate backer. With Java, there's Sun and Google. With C#, there's Microsoft. With C++, there are way too many to list - Intel, IBM, Apple, Sun, Google, Microsoft all have major stakes in it, and consequently work on language design together in the ISO committee. But something like Scala? What's the guarantee that it will be around tomorrow?
Which is a real pity, to be honest. Scala is an awesome language, probably the perfect in its (pragmatical hybrid OO/FP) niche. If e.g. Google were to seriously back it, it would really help its adoption. Unfortunately, it doesn't look like it's happening.
In contrast, the adoption drive behind F# (yes, there are fairly large companies out there using F# in production code) is largely because of Microsoft backing it, officially supporting it as part of VS, and so on - which is why I suspect it will keep growing.
Classic ASP (Score:2, Interesting)
If Microsoft really cared about devs, then the next version of IIS would allow Classic ASP and ASP.NET to share session state.
Nothing like releasing ASP.NET and obsoleting millions of lines of code.
Unlike VB6 to VB.NET there is no migration path from Classic ASP to ASP.NET other than a complete rewrite.
Re:Ease of writing doesn't convince me (Score:3, Interesting)
I am not so sure that having properties in C# is a great idea, because their very purpose is to hide that code invocation happens.
Nope. The very purpose is to simplify code usage. I don't gain anything by saying o.setName("name") when I can semantically get the same by saying o.name = "name". It was one of the greatest things that came out of Delphi, and there is a reason why it is the default way to access bean properties in EL/JSTL (firmly a Java technology) as well as in Groovy.
Unless that verbosity gets me something (clarity, better semantics) it is just syntactic salt with no associated benefit and certainly with an associated cost. When you start working with a whole bunch of goddam POJOs, you'd wish you'd have properties. I used to be in that camp that worshiped verbosity for the sake of it. Fortunately, first hand work experience in its associated cost helped me grew out of it.
I don't gain anything in knowing whether o.name = "name" executes code or not. I want that name to be "set". Whether that "set" operation carries additional semantics beyond assignment (.ie. synchronization, reference count or what not), I don't need to know. I don't want to know. Just as I would not want to know the "hidden" internals of calling a method in an object.
In fact, YOU WANT TO HIDE THE CODE INVOCATION. In programming, you simplify out of a context the things that you don't need to know. If you have two constructs that, by design-by-contract, carry the same semantics, you opt for the less verbose one. Always.
And I positively dislike the opt-out from declaring which exceptions a method throws. Exception handling is simply too important.
Prove to me that "good" exception handling absolutely requires checked exceptions, and then you might have an argument. In my experience, the worst exception handling mechanisms I've seen have been implemented with checked exceptions. No other language introduces them.
Now think about this. The folks implementing Groovy, Scala, C# as well as those that support and extend the C++ standard, these are all people experienced in programming language theory (not counting their industrial experience). And, by what they know, and by their industrial experience, they opt not to implement checked exceptions. Moreover, there are a lot of systems implemented in Java and otherwise that have excellent exception handling without checked exceptions. What should that tell you? Checked exceptions sounded good on paper, but it turned out not to be the case.
Exception handling (or design by contract for that matter) does not require checked exceptions. Sorry. Checked exceptions introduce code entanglement at various levels, and Java does not provide a way to abstract them out. The only way to really use checked exceptions in a controlled manner would be if Java provided a mechanism to declare exceptions as checked within a scope (say a package or an architectural layer) or by concentrating them within template patterns (which is basically what I have to do in a project I'm working on.)
Re:Ease of writing doesn't convince me (Score:3, Interesting)
I think that maintainability of code is helped most by writing the code in a way that closely follows the high-level model of the program. Neither C# nor Java are very good for that, because both require you to add a lot of boilerplate code and neither offers elegant metaprogramming. In other words, understanding the code is going to be hard because of the sheer amount of noise in it.
Sure, offering more powerful constructs such as macros would offer more ways to make the program a horrible mess, and some of the extra annotations that are in Java and C# code actually give some clue as to what is happening, so the knife cuts both ways. But I think bad programmers are going to write bad code in any language simply because they don't have the right mindset, whereas good programmers are going to write better code in a language that doesn't restrict them as much as C# and Java do.