Slashdot Mirror
Was .NET All a Mistake?
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."
Do you really need an entire article to give you the answer to that one?
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
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.
"Yes".
Sometimes this community really disappoints me. This is no exception.
A 9 minute demo of a new UI for Windows 8 Tablets at a trade conference means that Microsoft is abandoning .NET somehow, just because HTML 5 markup will be used for the UI work.
> 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.
Is this just a troll?
You gotta love those huge .NET runtime DLLs and packages giving a nice big overhead to everything, and those odd looking flat buttons!
We're a ~100 person .NET shop and we do about 10 million a year with small businesses. It's worked great for us!
'We are trying to prove ourselves wrong as quickly as possible, because only in that way can we find progress.' RPF
According to an Ars Technica article, .NET will be first-class citizen in Windows 8.
"Sum Ergo Cogito"
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.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
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 :-)
Now if I could get into said market if it is healthy ;-)
.NET is an incredibly easy to use, powerful programming language. It integrates well with Visual Studio, and for 99% of all applications, it works as well as it could possibly need to.
It's brought about 10 solid years of reduced development effort and increased productivity, and tons of cool and useful applications.
Direct use of the Windows APIs? Who cares? Unless you're writing seriously low-level stuff, you'll never need that access, and in that case you'd probably want to avoid managed code altogether anyway.
Troll...
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?
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 can have a niche use, but it cannot compete with VMs that can run the same code on multiple platforms. In any case, I always saw it as a trap and not the kind I'd walk into, because my applications run on real operating systems and not on desktop toys.
You can't handle the truth.
Mostly a stupid article written by a guy who is mostly clueless. I love statements such as:
Try using DirectX 10 or later from C# for example.
Was this supposed to be something hard to accomplish or has the guy never heard of XNA Game Studio?
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.
Support Eachother, Copy Dutch Property!
No language is going to simultaneously be better than C++ and Java at everything. C# has a great many strengths, a few weaknesses, and a definite place in windows development. Yes, a few of Microsoft's flagship products are still C++. Some of that is for performance considerations, mostly though, it's because MSFT is a company looking to profitably ship software and not rewrite a massive code base just because a new shiny language came out.
(Tangent: Posting as anon since I can't seem to stay logged in using IE9, FF4, or Chrome :( )
if you are working in an all microsoft environment such as a large corporation, .net and all the associated dev tools and frameworks are really kind of great.
i think a lot of people are either upset that it isn't as easy to shoehorn into their existing workflow as they'd like, or haven't actually done any in depth development with microsoft's products in many years.
.NET isn't intended for system programming. It's intended for enterprise/LoB apps, Windows Phone, traditional desktop apps, etc... Try writing a large distributed application in C++, unless you absolutely need extreme high performance (real time, e.g. trading app or something like that), you don't know what you're doing if you use C++ instead of .NET (or Java, I guess).
If people are using C++ for these types of apps either they have specialized needs or they just don't know what they're doing and like to spend 2X the time developing shit.
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 same goals.
Submitter clearly has no idea. See here.
Visual Studio Express Editions + SQL covers:
.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 Win32 API calls? Yes. What is the issue here troll?
.NET stack in a Glen Beck style question. Is Linux ever going to be a good platform? Is Apple ever going to be more than turdshine? Is the article poster a troll?
- 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
Of course every platform has its limitations, but you can't paint the entire
'We are trying to prove ourselves wrong as quickly as possible, because only in that way can we find progress.' RPF
FTA: "There has been, throughout the life of .NET, a steady but growing undertow to return to C++ and COM. Now the undertow seems to be growing and this is what prompts these thoughts."
Sorry, but I've never had any desire to go back to C++ if it wasn't necessary. LINQ and lambda expressions are awesome. Managed code, even with the overhead is totally worth it if that's what you need. I'm tired of hearing of these commandments that everything in the programming/systems have to be a certain way.
And who cares if it's not platform independent? It's built for Rapid Application Development and it does it very well. So what if it's not like Java in that regard?
Like Java was a "first-class citizen" on OS X.
/. users are still smoking crack.
Would you build an OS in Java? Ruby? Scala? ?
No. Same with .NET. But I also wouldn't build a CMS or line-of-business app in C++. .NET is used in a lot of places _within_ MSFT, eg SQL Server, Exchange, Biztalk, not to mention to run sites like microsoft.com, msdn.microsoft.com, asp.net (and those are just the MSFT ones). Also, if you happen to be an iphone person, a lot of the top games are written in C# (google for "unity"), along with a fair number of other apps (google: monotouch). And if you are an android user, try googleing for "mono for android".
Pull you head out of your backside and go troll on.... oh, wait. You are trolling on /. already. Sorry. My mistake.
Cya in another 5 years. I'm sure the conversation will not have moved on much.
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)?
#DeleteChrome
As per my comment title. My major issue with using .NET for any project is the fact the framework is massive, many people still don't actually have it (or a recent version of it) - but most importantly, there is no 'must have' .NET application that spurs people to install it themselves. MS didn't even use it for their own products
... 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.
One other thing....
.NET has always been a second class Windows citizen unable to make direct use of the Windows APIs
Really?
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.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
Used to be. Even supported Cocoa libraries, but nobody used it.
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
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.
Wasn't it supposed to be a first-class citizen in Windows Vista? Like one of the "pillars of Longhorn"?
I agree. Most C++ programmers aren't that good at C++ and should be using something like C# especially, as the parent implies, when writing business applications. Most programmers are not writing high performance applications and they don't need the power (and problems) associated with C++.
Microsoft is simply lost. First Java, Python, et. al. take over the server side. MS is okay with that because the real power is the desktop. Then the iPad comes along and kicks their money maker out from under them. For the longest time MS said that tablets were any good and, lo, Apple makes a good table!
MS was never good at one thing, it just that the things they did worked together. Now they're big attacked on several fronts and they don't know what to do.
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.
Please, use commas when you write; the summary was extremely difficult to read. Also, Joel Spolsky has a great blog entry on Microsoft's tendency to vacillate between different frameworks (the article, though a decade old, is still relevant): http://www.joelonsoftware.com/articles/fog0000000339.html
what what
If you want the typical bloated, slow, resource sucking, application with all the bells and whistles that runs only on Windows platform, then go for it. Pony up the cash, saddle up and ride away. If you can convince customers to pay good money for the ride, then more power to you. .NET application is totally stuck in the muck. Don't even think about moving it, you will have all kinds of IP problems, and will be unable to make any kind of efficient move to another platform anyway. Was .NET more about locking business into the myopic servitude of a Windows-only world? It succeeded at that. ...but egads! its no longer a Windows-only world.
On the other hand, if you want to be able to leverage code artifacts to the fullest and reuse solutions for other, more cost efficient platforms, say Linux, then your
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 implementation detail. It's the huge framework of ready-made classes that accelerate development. Sure, there are plenty of PHP frameworks and so on, but with .NET, and C# in particular, you've got a massive library ready, tightly integration tested, and virtually guaranteed to run on anything from Windows XP up... oh, and I've rarely found a .NET app compiled for Windows which wouldn't run without modification under Mono.
As I suggested in the subject line, it's a matter of tools for the job. I regularly do C#, Obj-C, C, JavaScript, Perl and the odd bit of PHP and Java, and C#'s my favourite for headache-free development. It's not perfect for *every* job, but for the ones where it works, it works very well indeed.
sig:- (wit >= sarcasm)
1) platform dependency on Windows, and by extension, Microsoft's development staff
2) application code is trivially reverse-engineerable, in fact it could be argued in court that the source code is effectively being shipped with the code so the authors have made the app "shared source" just by the act of releasing the binaries (this is a problem with Java as well). Even if the courts reject that argument, well, we see how well the music industry has been able to protect their IP.
This professional programmer should stick to programming; I couldn't even make it through his blog post.
Someone buy him another box of commas. Please.
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.
I do not fail; I succeed at finding out what does not work.
I know it's not .NET in particular, but it certainly applies: What Languages Fix. The problem that C# was invented to fix? Java is controlled by Sun. Same goes for .NET vs. JVM.
Nathan's blog
Sure. That and WinFS.
Dilbert RSS feed
If C# compiled and ran 20% faster than VB, I could understand the animosity, but C# and VB both compile to the same intermediate language and offer pretty much identical performance. I've been working with both and in some instances, the only difference between the two is putting a ";" at the end of the line or typing out "Next" instead of "}."
For all the MS bashing, this is one thing they did right with ASP.NET. Let people choose the language they want to work in, but produce the same results in the end.
This is Slash "Freedom of Choice" Dot, but we must kill off languages we don't like...because in VB you have to type a few more words out.
Really, if it wasn't for VB, you would have less people to feel superior to. Why would you want the final nail?
Doctors destroy health, lawyers destroy justice, universities destroy knowledge, religion destroys spirituality
Mono tried to provide an alternative platform environment, but as far as I know even that was limited to Intel/AMD architecture Linux boxen. Without support from mainframes, AS400, Macintosh, portable devices, etc. it never even approached being a "cross platform" tool.
And the Mono project was an abject failure, lacking even fundamental communications security implementations that are critical for securing business applications communication.
I do not fail; I succeed at finding out what does not work.
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.
There are two, possibly unrelated factors to take into account here: 1) appropriate support for .NET, and 2) the value of managed code.
I would argue that the last thing one wants to do, in general, is to NOT use managed code for application development, in particular application code that is subject to continuous modifications and deployments.
That Windows systems developers prefer to stick to C++ (and actually C as you go deeper), that should not come as a surprise. I would be a surprise if anyone half-literate in software development would think otherwise. I would be more surprised if anyone would expect anyone but a dumb-wit to do low-level systems development with managed code.
So, I don't understand why an understandable preference to do systems development with a systems language (which just so happens to be C or C++, but which could have been Ada or Pascal) would have a detrimental impact on using a managed code platform and stack for the general case of application-level development.
Me no get it. Does not compute.
Moreover, it seems that the author of this piece is conflating issues here. This is what the author seems to be going about:
1. Fact: MS seems to be moving towards JavaScript and HTML5 as the main development stack for application development instead of .NET
2. Fact: System-level Windows programmers use a systems level programming language (C++) for systems-level development.
-----------
Ergo: Oh shit, the later caused the former!(10+1)
Correlation does not mean causation. And in fact, there isn't even a correlation at all. Whether MS drops .NET in favor of HTM5 and JavaScript does not mean anything about MS venturing into managed code land. And I would be hard-pressed to imagine that MS does not have any plans for the significant investment it has made in the .NET platform.
The funniest thing of all is that the author seems to miss this important fact: JavaScript is managed code. So in essence, MS is simply moving from one managed code stack "a" to another managed code stack "b". That's all. Fundamentally, it is just that, a change of managed stacks, a reflection (or adjustment) to the changes, to the paradigm shifts in application delivery. Nothing more.
How a preference for C++ for Windows systems level programming is even in the picture here, it beats the hell out of me.
What .NET really did was it allowed IT shops/departments to have all of the advantages/disadvantages of Java but still remain a 100% Microsoft shop. Yes .NET improved upon some Java things, but ultimately, it wasn't enough of an improvement to kill Java. It didn't kill Java, but it did kill Visual Basic.
As for the notion that .NET was supposed to replace C++ for Windows development, that was naive. As long as major applications were written in C++ and needed to be maintained in C++, C++ is going to still be what Windows developers will use. Just like COBOL was supposed to be dead a long time ago, and yet COBOL programmers are still in demand for large mainframe systems.
Well I write .Net code for a living, VB Mostly instead of C#
I've also been into Linux for a long while (originally Mandrake, now Gentoo)
if nothing else it can be used as a fast prototyping language and it's miles better than the old VB6
our entire business is based on it websites / processing applications
it works well and you can write code for it very quickly and easily
and it's not a language but a platform (language + standard libs for common operations)
In the old days it was all about squeezing as much as you could from the processor .Net as upper layer for business logic
(I know this more than most, assembler on the Z80 / Spectrum, Atari 68000 etc)
each language has it's place depending on the trade off between simplicity and performance
I've always seen C as driver low level, C++ as mid OS GUI / 3D abstraction level
and the likes of Java / PHP /
But where it comes to actual applications or websites that sit on top of the OS not a part of the OS .Net
where business logic not performance counts
where it's key to be able to change something quickly at the cost of a small performance hit
(becuase you have a server with umpteen CPU's and massive memory in a rack, so performance comes secondary)
you need a higher level language than C++ to do these things quickly / simply
and I'm ashamed to say as a Linux geek I've not found anything that I could write cleaner or quicker code in than
I really have tried with java and netbeans, but I hate it's Enums and namespacing, I've even considered scalar
netbeans also has this habbit of completley changing they're platform / libs layout (which sits on top of the java platform)
if I want to write a simple line of text to a text file, I can do it in a single line
System.IO.file.appendalltext(filepath, content)
with C++ unless you count the STL there's no fixed standard list of libs to use for common tasks
it can vary between platforms (less so with open source)
so typically I end up opening a file handle creating an int to store it in, making sure my string is null terminated
etc etc for somethinhg that should be a simple job
having the language managed, and catching exceptions which mean something is an added bonus
I know there are a lot of wrapper libs for this sort of thing like QT .Net's
kdevelop has auto-completion but it's still not a patch on the ease of use of Studio /
simply because of the differences in language design
In an ideal world I'd like to write .Net VB apps that use QT as a GUI backend .Net you could create these very easily
and that can run under windows or Linux via Qyoto and mono
given that KDE's smoke has recently been split into seperate parts under Gentoo and that Qyoto has been updated to 4.7
I'm hoping this might finally be possible
Linux is missing a lot of GUI based apps for configuration front ends vs windows
and with
But at the end of the day it's all about personal preference .Net depending on what they're more familar with
some people can probably write code in C++ more quickly than
also we don't have the same patent issues over here in the UK as the USA (for now at least)
It may have been good technology but with the systems guys building Windows preferring to stick with C++ the outcome was inevitable.
Why should the fact that some microsoft developers prefer C++ for the job mean that C#/.NET is unsuitable for other tasks? If I had to choose ONE platform for all apps, it would definitely be .NET over unmanaged development. I.e., I'd rather write a webapp, an office plugin and a mobile app in C#, than write all 3 in C++.
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.
Ask 100 .NET developers if they feel that .NET is a second class citizen. They will have no Idea what you are talking about of course, as 90 of them are doing ASP.NET applications (which is a joy compared to classic asp). The remaining 10 are doing other things such as office plugins, WinPhone7-apps etc. etc. But if you ask 1000 .NET developers, you may find one that actually uses .NET in the sense that might expose it as being a second class citizen in windows. I write heavy desktop applications in C#, and sometimes feel that frustration, but I can imagine the envy goes both ways. I wouldn't want to write anything db related without LINQ for example.
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]
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Java / .Net / BASIC are all interpreted languages - BASIC was a great learning tool, when I was 12. I assume Java and .NET serve similar (and different) purposes today.
Whenever I start a significant project, I ask myself: "Am I going to regret my choice of platform before this is over?" - if what you are doing doesn't need the ultimate in speed, power, and portability - then .NET may well be your best choice.
Enough of what I do does require every last bit of speed, or portability between platforms, that I have stayed away from interpreted languages - and if you get familiar enough with C++, it's not really any easier to work with a "managed environment," not enough easier to justify keeping proficiency up in both languages at once.
I'm looking forward to the Year of the .Net Desktop.
That, Strong AI, and flying cars.
Welcome to the Panopticon. Used to be a prison, now it's your home.
There is very little to compare with .NET & C# and Win32 & C++. There really is no comparison.
Windows?
What are these "windows" of which you speak, strange visitor?
"Flyin' in just a sweet place,
Never been known to fail..."
it'll never be so long as it's interpreted bytecode. first class means native binaries without a vm.
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.
make imaginary.friends COUNT=100 VISIBLE=false
The whole thing is just going dot nut.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
It seems ontopic and news: the new Delphi XE2 also compiles for OSX and x64. It may not be much, but for the first time i am more optimistic about Delphi programming. Did not see this negative .NET article coming though, it seems solid and establieched to mex especially with Windows 8 and ARM platforms.
The Win32 API is, and always was, too hard to use. Simple operations often take a dozen function calls, with a lot of frictional code that just translates one kind of handle to another. Error checking every returned value is a real pain. You get used to it, in the same way you get used to living with a mildly abusive spouse.
The .NET API is much easier to use. It is object-oriented with a good, well-thought-out conventions for the applications programmer to use. Borland Delphi was once popular precisely because the Delphi API (called the VCL) provided a full encapsulation of the native Win32 API but was much easier to use. This is not a coincidence: The improvement to the Microsoft APIs got easier right when Microsoft hired Anders Hejlsberg away from Borland. Or to put it another way, you no longer have to pay Borland a premium to get a good Anders Hejlsberg-designed API, because now you can get it straight from Microsoft. This is an uncomplicatedly good thing.
Nearly unrelatedly, it was also decided to have .NET compile applications to a managed instruction set and execute them in a virtual machine. This design desicion was made at a time when x86 seemed threatened, x86-64 was a second-class citizen that Intel had sworn never to support, and the world thought we might someday all wind up running on Itanium or PowerPC or some other as-yet-unknown 64-bit instruction set resulting from an Intel purchase of AMD, or something. So it kind of made sense to give .NET applications the potential to maybe run OK on a non-x86 platform. As things turned out, it wasn't very helpful, but nobody could have known that at the time.
So even if "managed code" turned out to be a lot of work for no purpose, the .NET Framework is still a much more usable API than raw-Win32, MFC, ATL, etc. ever were.
When Suse started using mono for its update service (forcing me to make a script to kill and restart the update service daily), I dumped Suse for my desktop OS. Congratulations, Microsoft. Your strategy worked. Now I use Ubuntu, but I'll probably switch to Debian if the UI debacle doesn't clear up soon.
"Longhorn" was a truly epic vision, apparently not within the capability of Microsoft's organization to deliver within any reasonable time frame. That may have made Vista as delivered ... an epic fail. (rimshot)
I have to give them proper respect for what they did manage to do: stuff in the NT 6 kernel, a compositing window manager, concurrent user support in Client-Side Caching (which I heard was a nightmare to add) ... and, unfortunately, a whole cargo shipload of slowdown inducing stuff like creating persistent local shadow copies by default or doing plug-and-play rescans for no easily apparent reason. Can't win 'em all, I guess.
...when you're writing a game...tweak the difficulty of "Easy" to something [your mother] can cope with. -- onion2k
This whole article is written from the perspective of a thick-client developer. At this point, who is still developing thick-client apps? Most of us have moved on to the web a long time ago: no framework to download, no nothing. With ASP.NET MVC you can write standards-compliant web apps easily.
With all due respect to Slashdot for what it once was, this article really smacks of irrelevance.
Writing in .Net is productive. It's fast, effiicent, and easy to write for.
.net I can happily lay a cheap foundation for given project and just go for it. If I have made a mistake it's still a pain to correct, but it's not nearly as damaging as in can be found in an unmanaged environment. The CLR, and C# almost insist that you play around with it to get the right solution for your thinking, and like I say, it's mostly productive tinkering your doing. It's not about class resources, or static entry points it's about developing the solution and solving the problem.
.net worth it's weight in floppy disks, and punchcards(I'm using measurement to ensure the crumdugeonly posters before me can follow my level of praise). Then you have Visual Studio's tool chain, at which point I'm going to get misty eyed, and making hooting noises, because it's undeniably fantastic.
.net too! It's a little unweidly. .net allows to me solve problems by writing code, rather than creating a frame to phrase problem, that lets me to solve problem using code.
The tremendous Base Class Library, and all the extra technologies(LINQ et al) won't make me a better programmer, but they do make me nimble, and allows for fast structural changes.
When I code in C++ (I only learned GNU not Microsoft all those '__' make me nervous), I spend a lot of time plumbing, ensuring patterns are correct, and resources are correctly allocated to be correctly disposed. I spend a lot of time laying out corner stones, and taking measurements. In
For that alone I find
I'm a Sharepoint developer (Put the sarcasm down), which from an API standpoint sits on top of a truck of COM objects and IIS, and boy do we know about it. SPWeb.Dispose() (for a given context of SPWeb), is a founding tennent of SharePoint development, not only does it leak, it costs. Sharepoint Sandbox development takes even further but actually assigning a cost (points) based on the actions of the application, thanks to a amanged code environ. SharePoint is a system that ties into AD, Exchange, Office, IIS and SQL Server, out of the box. If you did not have a managed code environment to resting over all of that plumbing, communication, instation of objects, threads (IIS, and Windows and SQL) etc then how on earth could a product like that exist in the first place? For example the Open Text offering (I forget the name of the product, one part used to be called red dot), needs two servers to handle publishing, and moves between, python, java, asp and some
In short:
Anyway back to my Windows only technology, and the IE/Firefox/Opera/Safari cross broswer Sharepoint site I've been building.
I would say that .net died around the time of Sharepoint. Too much of the .net API started to support more and more of Microsoft's products and solve fewer and fewer of my problems as a programmer. When .net version 1.0 came out I was able to delete dozens of functions I had written for interacting with email and web servers from an application. Then 1.1 was even better. I would say that Java even was feeling a bit of heat from .net. But 2.0 started to get a bit weird; still good but weird. Microsoft lost me with 2.5. Simply didn't upgrade and soon moved to LAMP. I can't tell you what the last version of .net is. All my application programming has been with QT and C++. It works and is rock solid. It looks like Nokia is now screwing up QT so I will eventually have to move but I won't be leaving C++. .net starting to go wrong was that it was telling me how to program. Also each upgrade was very painful to deploy. .net 2.5 was basically hostile to machines that hadn't seen an upgrade in a while. Whereas with C++ I do whatever I damn well please. If I think of a feature then I can build the feature without some part of the architecture tripping me up. And as for deployment: worst case scenario you pile the libraries in with the executable. I also find with C++ that old code stays around for a much longer time. With .net code I found myself recoding/updating it over and over.
Where I found
should rule them all. I get the distinct feeling from a lot of guys who cut their teeth on C++ that any other language is a cheat, vaguely sinful and one should wash one's hands after handling. I happily use my own .net applications to manage an automated testing system. It's quick, easy and the price is right (i.e. free). The advantages are much like those of (Horrors) VB6.
Look guys, the guy building a house doesn't have to know about optimal melting temperatures and cooling rates for the metal in the nails he pounds, or optimal pitch rates in the the screws he uses. Any box of nails screws has already had these details worked out by specialized engineers. That box represents a series of solved, and not very interesting problems.
The guy building a monitoring application doesn't need to know if the variables are passed by reference, whether a numeric type takes 16 bytes or 32, or what a pointer is or what happens to the memory when the application closes. Any decent modern language had these details worked out by specialized developers. That language, full of pre-made components, represents a series of solved, and not very interesting problems.
Many of us have to write some software. NOT everyone aspires to be a C++ alpha-geek, the best programmer in the shop, or anything else. Most of us are trying to make a living. Software is a means to an end, NOT an end in itself.
Please do not read this sig. Thank you.
Could Microsoft have created a new C/C++ standard library that was .NET enabled? Effectively giving the advantages of .NET (managed code) to standard C/C++ programs? Or maybe a better question would be could the VS compiler create .NET byte code from C/C++ programs? If doable this would have been an interesting solution as all programs compiled for Windows using VS and/or Microsoft's standard libraries would automatically become .NET applications.
I prefer C, C++, Python, and OCaml. I make much of my living from writing portable code.
That given: Not all code needs to or should be shared. Really. In most business ecosystems, no one gives a rat's ass about Linux or BSD or whatever outside the server room. And for vertical apps and internal code, C# is very nice, sort of a Java with better libraries. Microsoft won't abandon it, no one cares if these apps port, and code development is quick and easy.
Please, you zealots wouldn't even be interested in the C# I write. It's not cool, it's not innovative, it's freaking GUI data entry crap.
Well, okay, I have one C# app on my web site, a nice piece of signal visualization written at the behest of a now defunct company. The original was tied to proprietary hardware with proprietary drivers that only worked on Windows. The company went tits up, but I liked the code so much, I removed the hardware dependencies and released it for fun. That company, however, was creating a commercial product, and I *told* them C#/Windows was a mistake. They're dead now. But that's a different story from where most C# is used, which is for vertical market and internal apps in shops where no one is or will be running anything other than Windows.
I'm revising the signal program, BTW. in portable C++. C# is not a good solution in many cases, but that doesn't make it crap, either.
But I'm sure no facts will lessen the anti-MS zealotry.
All about me
In Frisian "dot net" is phonetically the same as "Don't do it". ( it's like " do it not" )
That was when NT 6 was supposed to be part of Longhorn.
Then Longhorn got released (NT 5.2 as Server 2003 R2) and NT 6 was nowhere to be found.
Then they rewrote the driver model and put aside the make-.Net-equal-to-Win32 bullet point. That became NT 6 (Vista).
Then they cleaned up the mess from the release of Vista, released NT 6.1 (as Windows 7), and then started on the effort to make .Net a first-class environment.
Why then? Windows Phone and XBox (XNA). The underlying Windows OS is now ready for .Net, and as a bonus, they have an ass-ton of developers ready to go. The experiment was with .Net 1.0 and 1.1. If it had no developer support at that point, it would have gone away. But then they sank some real dev effort into making it not suck with Whidbey (.Net 2.0).
That was the moment of truth. It left the labs and became The Next Big Thing at that point. After the release of .Net 2.0 in late 2005, there was no question whether it would be the primary API some day. MFC is dead. Win32 is an aging dinosaur (especially with 64-bit becoming mainstream, even the name is out of date). There has been minimal support for "traditional" development in the primary IDE (Visual Studio) for over a decade now. There was no chance that .Net was going to just go away at the point it got the 2.0 release.
Now, they're prepping Windows 8 for full support of .Net as the primary API. The business-class stuff is already there. The game framework is coming along nicely (XNA).
And once again, Microsoft has aced everyone else out of the possibility of competing with them on level ground. Want to write a database? Good luck with that. They don't support anything that isn't through the .Net framework. You used an API that was unsupported, and therefore, your broken stuff is your problem not theirs. Nevermind the fact that writing a database in .Net would be akin to stabbing your eye with a rusty spork. Want a database on Windows? SQL Server to the rescue! Want a cheaper database on Windows? Too bad.
Either the lock-in is just beginning, or the end of Windows is nigh. I would bet on both, and I'll ride it for all the cash I can get. One born every minute...
There are two distinct points in the history of .net
1) Take Over Everything
2) Ouch, that hurt, stick to making decent tools
2)When .net was first proposed, it scared the hell out of me. It was an MS powerplay for _everything_. .net + Passport was meant to be the single authentication service to rule them all. It was obvious that if MS had put that in place, then one day the authentication service for any non-sanctioned MS platform was simply stop working. Basically, Microsoft tried to embrace & extend the authentication infrastructure of the internet (such as it was in '01) and, by extension, anything that wanted to connect via TCP/IP. It never really caught on, though, so MS licked their wounds and continued with... .net" to "Um, yeah, .net, um, we support that, too..."
2) VisualStudio.net, Windows Server.net, SQL Server.net got renamed to their original monikers overnight. Passport was dead and MS faced a huge task: Write or cobble together support libraries for the clr to match the maturity of the Java ecosystem. After a lot of hard work, they managed to do it. I saw C# go from "how do I connect to LDAP? Apparently I write my own code..." to a mature, stable system that is pleasant to work with. This is the part that Microsoft is apparently killing with a pocket veto. The development tools have gone from "Blah Blah Blah for
I'm not sure that letting .net die that way is a good idea. All of a sudden, MS opens themselves up to competing tools and toolchains, a problem they haven't had since they put a stake through Delphi's heart. Maybe it's inevitable if they want to avoid being a bubble of non-conformity in a sea of standards. That would mean that they learned the lesson of the UNIX wars, which ironically they won with the Windows desktop. Still, I think that the death of the local .exe is greatly exaggerated.
It will be really interesting to see how this plays out.
Performance of compiled code isn't the only important productivity contributor.
Planning .NET (this isn't specific at all to ASP.NET, so I don't know why you would refer to that) from the outset as a multilanguage VM was a good choice. And I understand the market reasons why VB.NET (to transition VB users -- both desktop and ASP -- onto the platform) and C# (to provide a migration path for Java users) were the choices. And I know why the feature sets of the two languages are so closely aligned. The design decisions make perfect sense if you are Microsoft. They're just a headache if you aren't Microsoft.
I have an aesthetic distaste for VB.NET and wish it would fade over time to reduce unproductive complexity on projects I run into, but I certainly wouldn't say I must kill it off, just that the IT world would be a better place if it were to fade away.
I don't feel superior to people who use VB.NET, I just wish it would go away since it doesn't (unlike F#, IronRuby, IronPython, or any of quite a lot of other languages that run on .NET that aren't C#) have any compelling use case to favor it over C#, but I keep running into environments where the two are mixed with no real rationale for the use of each language. Diversity that adds value is good, diversity that adds support overhead without adding value isn't.
I love .NET and I had written even my own .net compiler for fun and its a very good specification and with mono you have support on several plataforms, and for information systems is a very good option for java, mostly because visual studio IDE and debuggers rocks when you try to do a fast and cheap work (as I should do almost everytime) while building customized information systems and for this kind of programs .net is a very good option from my point of view.
Heßischer you heathen!
I said no... but I missed and it came out yes.
It did its job of killing Sun Microsystems and "winning" in Billy G's head. Not saying that simply violating Sun's licensing by making Visual J totally native byte code incompatible didn't work either. Yes, Microsoft lost in court, but by then the damage was done, just as they did with the OS war on PC compatibles and Internet Explorer vs Netscape before that.
"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"
I heard that Win8 will have many new APIs that you can't call in unmanaged code. It should start to swing the other way. MS is currently trying to "start over" with a lot of their APIs and clean them up.
they don't want to kill it right off the bat because that really would piss off those diehard followers who took the .Net plunge. So they'll make a home for it in this obscure .Net for embedded systems. It won't look like they are killing it but the effect is letting die a slow death.
Maybe this is the reason for that instead of trying to beat out Googles ADK or even Arduino.
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
Funny, the only .NET app I have ever written from the ground up interfaced with a MySQL server. It worked pretty well, but the ADO.NET connector for it was in its early stages back in 2004 and not up to the ease of use of Microsoft's provided database connectors.
Such "detours" are Microsoft's history. If it's innovation you want you need to look at their Legal Dept. When Microsoft was laying the groundwork for their domination of the industry most of the pundits here were still pissing their nappies. But they see fit to lecture, it would appear.
What a lot of people seem to be missing is that the HTML5/JS crap is for UI - it isn't, and can't be, used for real app development. Just as with conventional web development, where the UI has to be based in HTML and JavaScript (which, we all know, we use because we have to, not because it's a good platform), your server-side language of choice is still doing the real work. Even in the exceedingly unlikely event that Winforms and WPF are depracated, .NET is still going to be the real workhorse of any application that's not built in C++. .NET is embedded in the industry as a whole - the vast majority of Windows software is built in a .NET language these days, and the vast majority of software written is for Windows. Even Microsoft's products rely heavily upon the framework - for instance, the entire VS2010 UI is WPF.
This reminds me of the guy I sat in a meeting with two years ago who claimed that using stored procedures was stupid because MS was removing support from SQL Server.
Yeah - not bloody likely.
Gotta love the trolls.
His view is that if MS had stuck with C++ and just iterated on VB6 we'd all be in a better place. My question to the author is this, "Did you ever use VB6?". C# and even VB.NET are worlds better than anything that VB6 could have evolved in to.
Angry .NET "developer" goes psycho because people are criticizing the only language he knows. Kind of pathetic. But then, aren't all .NOT 'developers'?
that everyone develops the same types of applications he does, or would seriously benefit by switching to C++?
Yeah, let's develop all desktop and web applications in C++. Right, big productivity boost there.
I suspect Microsoft can't stand paying anyone royalties for anything, that is why there is WMA/WMV instead of MP3, MP4, OGG and that is why there is a .NET runtime instead of a Sun JAVA runtime..
The author should read this article.
I'll program any language on any platform, they all suck in one way or another. I must say that .NET is outstanding and easy when working with enterprise Microsoft platforms. Also, unlike what is noted in this little opus, you can call whatever API you need from .NET... pinvoke...duh
Anyway, it's clear the person who wrote this slash never had to write enterprise automation using ATL COM.
Serves him right.
Look, VB had it uses and time of glory in the nineties.
I have not seen a new VB(.NET) project started in the last 5 years, and for me, that is a sign VB will be dead and buried by C#. Most have converted to VB.NET and transitioned to C# at some point, and either replaced or retrained the programmers. But by all means, if you want to be the last person standing at the Visual Basic Alamo, be my guest.
Actually you can write video games with C#/.NET. Every single WP7 game is written in C#/.NET as well as XBOX XBLA games, plus many PC games. C# is actually pretty snazzy fast. .NET, among all its other wonders, wraps DirectX.
.NET was written in anticipation of Itanium. Instead, the growth area is mobiles, pads, pdas and such, which use an eclectic mix of chips. The .NET option of generate-code-on-install doesn't apply to mobile apps, where the app store only has what the platform can use. And the big CLR doesn't always fit.
Apple is making a mint on hand-helds, and now has about 70 billion dollars in cash for a rainy day. Apple is huge. The comeback of the integrated hardware-software combination (Apple) changed the marketplace.
Now the Nokia-Microsoft deal is all about putting .NET on phones, so .NET is making a comeback there, or .NET will bankrupt Nokia.
1) That story is bogus or
2)
3)
I18N == Intergalacticization
Well it did manage to provide an upgrade path for the many millions of developers of small business / custom application development. (It kept the money train moving and lots of people employed during a time period when there wasn't much reason to continue development.) PHB: Hey look at the cool elite new things I can do without having to invest large amounts of time or money and the customer will be glad that were using leading edge software. M$ Has always coddled the developer's as it locks end uses into an upgrade path. Reminds me when VB 4 or 5 came out and all of sudden.... Vendors were like Opps sorry your going to need to upgrade to IE 4 if you want to install the help files...
oh i hate java personally, and i used eclipse and wrote my first android app. Only thing i could really complain about was java's odd idea of scope. When i write inline anonymous functions in c#, they have the scope of where they are. In jva, the scope is a different class. Annoying! otherwise, both sides please stfu. Apples and oranges are both good fruit.
Your fact #1 is not a fact, merely a bunch of chicken littles misinterpreting a MS demo.
to keep people busy learning new MS ways of doing old tricks and stop looking into competing products.
After 10 years it's fair to say that It has fully achieved it's goal. It seems like now it's time for a rerun.
The two problems with .NET is that it promised a lot of things that are either false or pointless. The other problem is the fanboys that keep preaching these features even when they are false and/or pointless.
And please don't tell me PHP/Ruby/Python has fanboys too, I'm not arguing that. Let me review some of the fantastic claims of .NET although let me admit that I only worked with .NET for a living for a little over 2 years.
1) It's cross-platform!
No it's not. Not in any adventitious way. For a lot of users this involves the very lengthy and slow -albeit simple- process of installing the .NET runtime. Now get this, if cross-platform by installing extra runtimes is your definition of cross-platform then python, ruby and of course Java are cross-platform too.
1.1) My code is compatible with all the important operative systems because only Windows matters and only idiots don't have .NET installed hur hur!
No ass-hat, and yes this is an argument people are making here in slashdot. Now I understand that all your clients work in Windows, I understand that you don't need platform independence, but you don't get to brag about platform independence when you don't have it, it's a have your cake or eat it matter.
1.2) But it runs on XP and W7, it *is* cross-platform!
Again, not in any meaningful way. XP and W7 are not different enough to get called different platforms. I have yet to find an XP program that doesn't run on W7, if random C/C++/Delphi apps for XP run fine on W7 cross-platformness is not an advantage of .NET
1.3) Mono...
Mono can't run .NET apps. .NET may run Mono apps, but that's an argument in favor of Mono, not .NET. Probably you would have to code in a subset of Mono, this coupled with the fact that Mono will always play catch up to .NET means that developing cross-platform apps in Mono will always place severe restrictions on you. Now I admit that this might be worthy for the people who want to code in C# AND care about cross-platformness. If you are going to code in something else than C# you are better off coding directly to that environment, like Python or Ruby. So it's only half a point.
2) It's language independent!
Again, not in any meaningful way. Not only does IronPython and IronRuby have little syntax differences, they have huge library ones. A non trivial Python program has little chance to run unmodified in IronPython. An IronPython one has zero-chance to run in a real Python interpreter.
And of course there is an easy way to write python/ruby programs that are cross-platform. Write for the real interpreter!
2.1) But I can share libraries!
Sure to an extent. However calling dynamic typed code from static typed code is still cumbersome and you wouldn't want to do it since static type coders avoid dynamic languages like the plague.
Calling static code from dynamic code on the other hand is a very good use case. Python/Ruby/PHP/etc already have great support for calling code from compiled libraries. Of course, since Iron$language is incompatible with $language, it means that you have to port code, which you wouldn't't do if you choose to remain compatible with real $language.
So calling C# code from your Iron$language code is only an option if you forgo compatibility with $language but still hate C#, except C# is the crown jewel of .NET you can't hate it.
2.2) Not true! Lot's of people mix multiple languages in .NET
The only two languages that people ordinarily mix on .NET are C# and VB.NET and VB.NET is a microcosmos of failure on it's own. VB.NET was built on the premise that it was compatible with VB, which it isn't. On the 2+ years I spent on that .NET shop, the only two VB.NET projects I worked on suffered from it. As the resident language gu
But... the future refused to change.
C# doesn't need to kill VB because it's assimilating it. Thanks to the CLR, they become more alike with every release. While it was almost impossible to write good code in VB4 and earlier, VB6 made it possible to write maintainable code, and VB.Net is effectively a different dialect of C#.
just so 1 installer application will work, really outside of independent programmers who uses this, why do I need 4 versions of it, 2 or 3 service packs, and a fuckton of security updates EACH.
Shit biscuits, I reinstalled a XP machine earlier this week and thought I was going to nailgun my face to the desk over what these bloatware things require.
The majority of Windows programmers need a Java-like environment and C# + .NET fills that need very nicely: Proper exception handling, managed memory, a well-designed library, etc. You get a lot, if you don't mind the bit of overhead and occasionally unpredictable performance (garbage collection).
If anything, Microsoft's "mistake" is in making C++ the only viable choice for systems coding. In fact, and while it probably won't be easy, it'd be at least interesting if Microsoft introduced a minimally-modified variant of C# for exactly this.
You might not write a AAA title like Doom 4 or Borderlands 2 in C#, but it's just fine for lots of games. Xbox Live Indie Games are all C#, as are some XBLA games. Windows Phone 7 games are all C#, not that anyone is buying Windows Phones. Games written in C# are starting to show up on Steam, despite Microsoft not having an indie game channel for PCs. Casual game developers are also using Unity to target PCs, Macs, consoles, phones, and browsers with the Mono flavor of C#.
C# is perfectly capable of meeting high performance gaming needs if you know what you're doing. You can write poor code in any language ;-)
I agree that no sane person would make an O/S with it, but it is a great platform for video games, including 3d shooters. In fact, that's what my business partner and I are developing our game with. C# + XNA. Admittedly, our game is 2d, but only because we don't have the resources to create 3d assets, not because XNA is somehow lacking. Our time to production will be cut way, way short because of the simplicity and elegance of XNA. The only thing that makes it difficult is that the XBox version will require us to pre-allocate ALL of our objects, because the garbage collector on the XBox sucks. This does make things a bit trickier, you have to create object pools and crap that you normally would expect the GC to do for you, but it's still the bee's-knees in terms of coding time.
Most of the work of modern games is done on the graphics hardware, not the CPUs. For the tiny amount that is done on the CPUs, C# is plenty fast enough. I can put like 6000 sprites on the screen, rotating and scaling, before I drop below 60fps. And that's only due to my graphics hardware. The game code is hardly doing anything.
Furthermore, the tools to develop against the XBox are just freaking cool. I can debug the console exactly as though it were running on my local box, set a break point, inspect variables, etc, and I can't even tell it's a remote process. It just works.
And finally, the lead developer for XNA is the same guy who made Allegro in the 90s. I don't know if you were programming games back then, or playing around with it, but Allegro was great. The main problem is that it was slow. Well, Sean has had nearly 20 years to refine his techniques, and of hardware advances, and he has it down to an art. You barely need to write any code to have a game up and running. The vast majority of your time is spent in game logic, not looking up arcane DirectX commands. DX is mostly abstracted away.
C#, like Java, is just-in-time (JIT) compiled, not interpreted. In addition, both can be compiled to native code, although in general, JIT will be faster.
I wrote a long post, but in the name of bandwidth, I cut it down. The short answer: Yes. Its another redundant Microsoft framework/technology/language that the rest of the world already does, better. Who will be most affected by its demise? Independent microsoft "developers, developers, developers, developers" (repeat ad nauseum).
I wish it were so, but VB.NET is firmly entrenched in many sectors of the corporate world, probably because it hides complexity from the developers and that appeals to management and pseudo developers (though the complexity eventually tends to rip the lining of that 'safety blanket' anyway). Nevertheless, VB, like COBOL before it, isn't going to disappear any time soon, you just won't see it out in the open as much.
You just take an environment, lock it and make sure you have enough resources for your app to finish in the amount of time required. It's been done all the time. True, it's not a real time OS, but the entire apparatus does the job real time. Most of todays telco stuff is done that way, VOIP, SMS and all those protocols largely run on systems designed this way. True, they're almost never run on Windows, but rather Solaris and Linux, but the principles are the same.
I was promised a flying car. Where is my flying car?
The problem with Microsoft is they just have no taste. They have absolutely no taste. And I don't mean that in a small way, I mean that in a big way, including the design of API's.
Dead serious.
Evernote Abandons Microsoft .NET
"The blurry fonts, slow startup times, large memory footprint, and poor support for certain graphics cards were all issues that the technology behind 3.5 was incapable of resolving. As a result, we ended up chasing down platform bugs rather than adding the great features our users wanted"
“There is a substantive effort in open source to bring such an implementation of .Net to market, known as Mono and being driven by Novell, and one of the attributes of the agreement we made with Novell is that the intellectual property associated with that is available to Novell customers” link
This is beyond silly. .Net is not a language. Both CLR and JVM bytecodes can be interpreted when you're not on the beaten path. Once a piece of code gets hot, the JIT compiler compiles to native code and that's the end of interpreting that. There are plenty of flavors of Basic, some of them run on either CLR or JVM and thus automagically get compiled. There are also freestanding Basics that get compiled. Your whole rant about "interpreted" languages is based on some fantasy you have that is simply not true today, and hasn't been for a good while.
A successful API design takes a mixture of software design and pedagogy.
I read that article. The author mostly (and repeatedly) complains about the lack of cross-platform compatibility. So what? Objective C is perfect for Mac OS X and C++ is just fine for Linux. The bottom line -- C#.NET is well much alive and kicking, thank you for asking. No programmers were harmed during its cohabitation with C++ on Windows (except, perhaps, on a psychological level).
Well it did give Miguel de Icaza something harmless to do for ten years. Well mostly harmless.
whenever we say this you ms people are going berserk. silverlight has been dropped, this that, the talk of net being dropped. they WILL drop net. it doesnt do much for them.
it doesnt matter whether net is cool, useful, you like it, this that - it is not serving microsoft's aims. so just like any profit oriented company would, they will drop any such thing and concentrate on other stuff which may serve their aims.
you should switch to something that is not tied to the whim of a private company as soon as you can.
Read radical news here
It proves that the original statement that Humble Bundle makes more money from Linux & Mac combined than from Windows
The pie chart reads "Total Payments by Platform."
Windows payments about 60% of the total. Mac and Linux payments each about 20%.
This even though individual sales average about $12 for Linux, $7 for the Mac and $4 for Windows.
Luckily, i see others 'defending' .NET here too. Cause just because it's from Microsoft 'it must be bad' is a very invalid statement. That it isn't portable is simply a troll too, that just depends on the libraries you use, very much like any other language. There's .NET, there's mono. If portability is a key, use mono (or make sure it compiles on mono), and you'r pretty much set. .NET for long time too, just for the same invalid reasons, until i actually gave it a shot.. Let me state a few conclusions:
I rejected
* The language itself is a beauty. Really. It's the best and most beautiful programming language i ever met. It's powerful, it has very nice language constructs, it has about everything a programmer could wish for - and more. From the beauty stance of view, C# is Claudia Shiffer whereas Java would be the average south european, Python the average german, Ruby the average american, pearl the average russian geek and c++ just a plain troll from the tundra.
* It is very portable. I developed some standalone specialiced servers. To deploy it on my linux server, i just copy the frikking binaries. No more. No less. It _just_ _works_. Yes, there are some details. 32 vs 64 bit, for example. Or platform-dependant assemblies. It is hardly an issue. Of course, integrating IE in your app would be windows only. Or take winforms, it is what it sais: forms for windows. Use GTK if you need cross-platform UI's, for example, as mono defaults too.
* It's versatile. From UI's, stand alone server apps, http integration (ASP). Actually, a lot of ASP solutions run on apache + mono. Stating that C# has only use for a few niches is simply false. Of course, take the right tool for the job, up to you to decide, but there's not much that could be excluded by definition.
Now, the cons:
* It's managed code, rendering it a bit slower than strictly needed. However, this has the advantage of easifying cross-platform binaries. The same as Java does. So, this con as a pre same time.
* Microsoft refrained from creating (and thus supporting) a cross platform implementation themselves. They rely on (cooperation with) the mono project for this. Having said they, MS clearly stated they embrace the mono project.
* Microsoft created it. The name alone blinds zealots. Please, spend a few weeks or months learning the language, then come back and say what you think.
A glitch a day keeps the bugs away.
While I'm looking at my other screen.
All I wonder is, if Windows Explorer will ever get it right when predicting how long it takes to copy or zip something.
It has been saying for atleast for 4 minutes: 10 seconds remaining and now it says 5 seconds remaining. Right, eventhough the bar says: only 85% done.
right...
New things are always on the horizon
"Programmers at the time (...) and mourned the passing of VB 6 "
BWAHAHAHAHAHAHAHAHAHAHAHAHAHHAHAHAAAA... HAHAHA... Ha.... No. They didnt.
Funny - I was able to use Windows API calls in .NET, specifically VB.NET in fact:
".NET has always been a second class Windows citizen unable to make direct use of the Windows APIs" - mikejuk http://developers.slashdot.org/story/11/08/03/2027207/Was-NET-All-a-Mistake
AND, I was doing so YEARS ago in Visual Studio 2003 &/or 2005, in VB.NET to do it (but, I sacrificed the protections .NET gave you to do it)!
(That statement I quoted above's a truckload of "FUD"/B.S., & that's not just "my opinion", it's FACT!)
APK
P.S.=> It wasn't anymore difficult to do than doing API work in VB6 using DECLARE directives for Windows API's or even 3rd party lib/dll ones!
... apk
I believe the real purpose of .NET is to prepare the big move from NT OS line to Cingularity or whatever it will be called at the time. When all application development is no longer dependent on Win API, NT can be ditched in favor of another OS, and all you really have to do is provide .NET runtime for that OS. The fact that Office is being ported over to .NET (afaik) reaffirms this theory. The transition will be less painful than Apple's - no need for "universal binaries" etc. If I'm right, then it's a great and well executed plan.
Your fact #1 is not a fact, merely a bunch of chicken littles misinterpreting a MS demo.
It is a demo of what? Flipping burgers? No. It is a demo of a possible dev stack. Ergo, I used the word "seems" rather than "will".
1. Fact: MS seems to be moving towards JavaScript and HTML5 as the main development stack for application development instead of .NET
2. Fact: System-level Windows programmers use a systems level programming language (C++) for systems-level development.
Your first "fact" is blatantly wrong. It is a misconception pushed by MS detractors. What they build this contention on is the idea that because MS did *not* mention Silverlight when they demonstrated the Windows 8 tiles, Silverlight had somehow fallen out of grace. If all the technologies *not* mentioned by MS in a random demo must be assumed to be slated for EOL there wouldn't be anything left.
The *real* fact is that Silverlight is very much alive, it is the cornerstone of Phone 7 and will have a very prominent position in Windows 8 as well (more so than in previous versions of Windows). Silverlight and WPF are moving closer (as they should be). The HTML5 emphasis in Windows 8 is a bridge to allow websites to run as seamless Windows 8 tiles. Your favorite sites can offer tiles by simply marking up their website with certain micro-formats. To get an idea look at IE7+ webslices. When you browse to such a site, the tile-able elements will lit up and you can mark them as tiles on Windows 8 desktop. After that, the tiles run as small browsers in which javascript can execute and change content/appearance. But for actuall local apps development, expect to find Silverlight front and center.
And when was Silverlight equated with .NET anyway? .NET > Silverlight. Silverlight is a .NET application, not the entire framework.
Your second "fact" is somewhat correct. But the TFA gives the impression that using Win32 API is somehow difficult or even impossible from .NET. Which is blatantly false. P/Invoke is direct way to make system calls (on any platform). Unlike Java/JNI it directly supports marshalling parameters with no external glue code required whatsoever.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
> The thing is, Microsoft has actually nailed down the whole security thing quite well on the server now
That line speaks volumes and there isn't really anything you can say in MS favour after that, so I stopped reading at that point.
"nailed down" as a process of incremental security is quite vivid.
"quite well" as the limit of "nailing down" is also very expressive.
blog.sam.liddicott.com
Yessy yeserton
Microsoft could have easily adopted C++ as its programming language of choice. After all, if little Trolltech can make Qt, Microsoft could do better.
But, adopting C++ means your code can be ported to other platforms easier than a totally proprietary platform. Thus, Microsoft had VB, and then .NET. Anyone investing in those technologies was locked into Windows.
But now that the computer world has a lot more diversity (with all the consoles, phones and pads), Microsoft no longer is in a dominant position, and hence people don't chose Microsoft to develop their applications, and therefore a very proprietary platform like .NET doesn't encourage developers to chose the Microsoft platform.
And that's why Microsoft's love for C++ is reborn.
.NET has democratised both application & web development. It has provided lucrative opportunities for a small number of competent programmers who spend their time fixing the mess that the rest of .NET's drag & drop, coding-by-numbers 'developers' produce, usually in the time it takes the average .NET application to open.
The fundamental premise of this article is a bit flawed. It assumes that .NET was created to write windows applications instead of C++/MFC.
If we look at history here, .NET came along with a pretty clear objective - keep people from switching to Java. In the mid-late 90's there were throngs of Business IT developers who were looking to get their stuff online in the .COM boom. Their main choices were ASP, Java and a bunch of smaller choices like ColdFusion and such. ASP became popular with IT shops, but it quickly became clear that it lacked the framework support of Java, was all top-down, didn't scale especially well, lacked a lot of important features, and was easily spaghetti'ed. And with new programmers coming out of the colleges and tech schools and so forth with backgrounds in Java instead of Pascal or Basic, Microsoft realized that they were going to lose their dev marketshare quick if they didn't somehow get on board the web-focused, OO train, particualrly one that would allow them to integrate their web-dev platform and desktop dev platform (at least in some small, marketable way).
Hence, .NET.
Yeah, it's gotten a little ridiculously large, it had a shaky start (v1.0 was pretty dreadful) and some of the language features were slow in coming (how long was it before we got generics?), but strategically speaking it was a smart move for MS - it kept their very large business development base from abandoning them for a competitor. And that is a HUGE market for them. .NET also gave MS room to grow. Adding chunks to the framework like AJAX or LINQ wasn't exactly simple, but it was a lot easier than it would've been if they'd stuck to the old VB model.
It's never really been about whether it's better or worse than MFC or whether Microsoft wants to focus everything on managed code. It's always been about "keeping enterprise developers from abandoning Microsoft for competitors like Java." It's doubtful they'll abandon it entirely, and if they do, it'll be a long slow transition to something else, simply because they've staked a huge and very IT-conservative enterprise market on .NET as a complete end-to-end platform.
----
"I used to listen to Null Device before they sold out."
Fair competition is almost always a good thing. .NET probably pushed some good things into other languages like Java. However, let it pine for the fjords.
The person who wrote the underlying article is an idiot. These technology choices aren't an all-or-nothing proposition. If Windows 8 supports an HTML5/JavaScript development model that does NOT mean that other models aren't supported either. Plenty of apps will continue to be developed in .NET, as plenty of things are still developed using C++. The real goal of the future is the right tool for the right job.
im programming now a few years applications with the .net-Framework. Microsoft isn't fameous for creating end-user solutions that are exciting or revolutionary but for developers they created, i think, just that. .Net Environment. You get a language that is - compared to c/c++ and java - beautiful. You get a Framework that is thought-out and like a fine machine that helps you to do what you want to do. Its like the iPhone.
Its like, you get a IDE that fits perfekt for the
And beside of that, the author of that article mix up the technologies for the front-end and the rest. In fact he is right, Microsoft does some confusing thinks about how they will support WPF, Winforms etc. in future. But that doesn't change the 80 % of the applications intelligence at the back-end. For that you can go very fine with .net. That intelligence can be on a server - in the cloud or somewere else.
A classic windows application on the client that need to be installed will be dead anyway.
I find it hard to believe that you have ever developed anything in .NET. For the developer of business applications, developing in .NET is easier than any other MS-centric system out there. Besides supporting a huge variety of languages and programming systems, it has a very easy-to-use API that allows you to access pretty much anything you want. And if you need to get down to the Windows API level P/Invoke is not that hard to implement. Stick to you your Java if you want, but I'll program using C# and .NET anyday.
People keep using the term "manged code" in a manner I do not understand. Per WikiPedia Managed Code = Code managed by the CLR, thus by extension, code that runs on a VM. So if I write C++ that compiles to a normal binary, it is unmanaged code. If I write C++ that compiles to bytecode that runs on the CLR, then it is managed code. Managed Code certainly sounds better than Unmanaged Code. Wtih unmanaged having so many negative connotations who would want the old broken down badness, instead of the new hotness?
If "the value of managed code" means it byte code and runs on a VM that only runs on the win32/win64 platform then that sucks. If what people mean is garbage collection, and a rapid development gui/debugger then that is another thing. However at that point, I don't think the term "managed code" is appropriate. Unless you are also saying that Java is managed code. Since it is bytecode that runs on a VM that provides a garbage collector.
vi +
Everything (computer language wise) is a good deal faster than when I was 12 - and also a good deal more muddled - then it was relatively simple, less than a dozen "languages" total, and they broke down into 3 categories: Assembly, Compiled (automagic writing of usually (at the time) non-optimal assembly), and Interpreted. For a given problem, you could usually count on a slowdown factor from Assembly of ~2 for compiled and ~50 for interpreted. For any significant project, you could also count on a code writing time speedup factor of 10 to 100 using a compiled or interpreted language vs Assembly. Today, it "feels" like there are hundreds of "languages" to choose from, and performance of the modern ones has been converging on both the execution speed and development time sides. The three traditional distinctions are mostly gone, and even hardcore assembly writers usually start with a high level language and then just tweak the important parts.
If .NET floats your boat, stay with it - it's not evil or lame. I have stayed away from it because skills developed for it don't cross well to embedded / Linux / Mac - the "speed" thing is mostly irrelevant today, unless you're in a $10/copy embedded system with 64K of RAM running at 4MHz, on 0.1mW of power.
But, still, JIT is the very same thing that 1982 TRS-80 BASIC did when you ran a program - the main improvement in .NET and modern Java is that they only do the JIT step once and cache the "native code" that everybody is so gaga for, but it's still at run-time. If the byte-code were portable to anything but Windows, I might be impressed, but, then, I've been waiting to be impressed by Java for nearly 15 years...
The one thing that has impressed me for performance + portability + ease of implementation is Qt. It's not the end-all, but it serves very well as a robust library of convenience routines, is more (easily and gracefully) portable than anything else I have ever seen, and the C/C++ skills that I keep sharp while using it are also very useful in other environments.
On the downside, when I go looking for a job, they aren't as plentiful as .NET positions - but the higher paying ones tend to be easier to find.
I agree about Qt. Have been using it seriously since 2.x times.
The TRS-80 BASIC, and most other basics of that era, did not do any sort of JIT. It didn't even do what Python does -- no bytecode interpretation. The level 1 BASIC was a port of Tiny Basic, I remember that I first saw TB in Dr. Dobb's Journal of Computer Calisthenics and Orthodontia that my dad got his hands on -- behind the Iron Courtain, too. This was IIRC an untokenized, on-the-fly interpreter. The level 2 BASIC was MS BASIC, and it too doesn't use a bytecode, just tokens. There is a difference between bytecode and tokens: the bytecode represents assembly-type operations on a low-level virtual machine of some sort. The tokens are simply a more compact representation of the source code, and are fairly high level. The tokenized stream is fed to a parser that eventually calls upon the evaluator with the abstract syntax expression tree of some sort. Most of this is constructed on the fly, since the memory is tight.
Luxor's ABC-800 had a very fast BASIC that did use bytecodes, and was much closer to today's Python than other BASICs of the time. I have a bunch of ABC-802s and their BASIC is faster than MS-BASIC was on PC-XT.
A successful API design takes a mixture of software design and pedagogy.
Nobody says you have to like .Net for anything, you're entitled to your negative opinion.
But there is something wrong with this type of reasoning: platform X does not fulfill all my expectations of it, therefore platform X is all a mistake.
Otherwise, along the same lines, one could easily argue that "Java was all a mistake" and considering that most developers have left it by now, "C++ was all a mistake" too. Now the entire field of software development is quickly starting to look like "it's all a mistake". Unless of course this is your actual opinion, which begs the question if there was a particular reason to focus on .Net.
Não creio que o .NET vá deixa de existir. É uma das coisas mais certas que a Microsoft resolveu bancar!
Talvez exista ponto que precisam ser melhorados, mas é tão infinitamente mais benéfico!
Com as mudanças radicais no comportamento dos usuários, os sistemas tiveram que evoluir, e isso leva cada plataforma seja .NET, Java, ObjC, etc, a buscarem evoluções para atenderem as novas necessidades que esse novo comportamento exige.
Mudanças virão! e isso é extremamente necessário sempre!
Who is this 'mikejuk' ?
I have never heard this name in the programming world.... Guys..this person is trying to gain cheap publicity in the same way in the same way monika lewinsky gained publicity by blaming Bill C. .NET platform is the most advanced technology till date. It has everything a programmer needs ..desktop apps, web apps, web services, windows services, game development ..
The success lies in the fact that more than 50% of the software currently developed is in .NET ...
Mike , if you have really gone to school ..atleast for some period of your life, then talk in numbers....
.Net has an enormous following when it comes to building business applications. And is only gaining steam as it builds on itself and further simplifies complexities of distributed systems (WCF for SOAP and REST), modular web development (MVC) and data access (LINQ). Yes, there have been some costly missteps (i.e. asp.net webforms), but it works great for most application needs out there.