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.
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.
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!
.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.
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
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
... 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"?
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)
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?
I love it. Check out the By line on the article, and then the page on Meet the Team
Ian Elliot
Specialist subjects: JavaScript, web programming, .NET programming
As a freelance consultant Ian is used to meeting challenges in a range of arenas and using all the tools and skills a programmer has in their armoury. He has written numerous articles for VSJ mainly on web development.
So, he's NOT a DirectX expert? Javascript is listed first? I call bullshit that he ever even tried to interop on DirectX.
More Twoson than Cupertino
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.
Not true. Office 2010 is written in C++ and does not use WPF. In fact, the ribbon control introduced a few years ago is a free download from their web site, and you can only use it from C++.
Office 2010 does not use WPF
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.
How is that possible? Windows XP SP2 came with .NET 2.0. Vista includes 3.0, and Windows 7 includes 3.5.
Windows?
What are these "windows" of which you speak, strange visitor?
"Flyin' in just a sweet place,
Never been known to fail..."
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.
Microsoft has been trolling all the time since MS-Dos, so there is nothing new or surprising here.
The only result we get is a bigger and bigger backpack hanging on programmers containing contradicting technologies from Microsoft.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
How is that possible? Windows XP SP2 came with .NET 2.0. Vista includes 3.0, and Windows 7 includes 3.5.
So which of the various Frameworks do you build for?
And note that anything .Net won't run on my XP PC because at some point in the past I installed a .Net Framework service pack which screwed it up so badly that it can't install and can't uninstall and even the 'brute force uninstaller' from Microsoft won't fix the damn thing.
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.
Exchange and IIS are .Net. I know SQL server has a lot of .Net in it. The Visual Studio shell is WPF, and there's plenty of .Net in other places in VS.
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
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.
No LINQ, but the latest versions of Microsoft's C++ compiler can generate managed .NET code, and do support C++0x lambda expressions. Oh, and you can also use the managed target for catching memory errors while debugging, and then ship the native version.
I am TheRaven on Soylent News
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.
It's used a lot in web and line of business apps. It is pretty much a split market with Java and .Net for business web apps.
As to a killer app, try paint.net or pinta.
Michael J. Ryan - tracker1.info
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" )
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.
Heßischer you heathen!
I said no... but I missed and it came out yes.
"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.
I normally do not reply to AC but I hope you actually read this and get the hell out of the basement now and then.
Contrary to popular belief building native code apps is quite alive and well. It is faster and when built with .net ( I don't like it but have to respect it for what it is AND what it can do ) but it runs on any windows platform from XP on client AND server and has every hook built in for database work AND has data aware grid controls.
The web browser in its current incarnation is a MAJOR PITA to do serious work with requires VAST amounts of backend server code to do even the simplest of interactive task that amount to anything.
Hey KID! Yeah you, get the fuck off my lawn!
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.
It's not that you can't get work as a .NET programmer but it is that it didn't eradicate Java as MS had hoped. One of main reasons is that you really need to run it on Windows and businesses are loathe to replace their functioning Unix/Linux servers just for the sake of a development platform. Yes Mono exists but it isn't complete and doesn't work well with anything other than an Intel/AMD hardware.
Well, there's spam egg sausage and spam, that's not got much spam in it.
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.
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.
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.
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.
.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.
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.
MS didn't even use it for their own products
This is a stupid argument. Rewriting a product the size of Office in an entirely differently language is a massive undertaking, even for a company the size of Microsoft. Never mind all of the other hundreds of programs that they've got laying around that just don't happen to have the visibility of their two flagship products.
I'm sure they would love to completely abandon 25 years of crud and start fresh, but its just not practical. Not to mention it would require porting .NET to the Mac in order to support the Mac version of Office (and any other systems they might support), which may be stopped by more than the simple time and technical challenges (ie: Microsoft might not want .NET to be portable for sales reasons).
Newer stuff that they're doing DOES support .NET, and in fact a lot of it is built on .NET. XNA is a C# derivative for developing Xbox/Windows games in a somewhat cross-platform manner. .NET is the platform of choice for Windows Phone 7, etc.
As for a 'must have' .NET application... who cares? Its not that hard to include the redistributable with your application. If you're really worried about your users having .NET pre-installed, then just use an older version of .NET rather than hoping some random third party developer has already done the installation for you. Its extremely easy to switch your target output between 2.0/3.0/3.5/4.0 from within the Visual Studio project settings.
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.
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 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?
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).
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
No-one suggested that. He mentioned: there is no killer appplication for people to install the runtime. Not even an application from Microsoft themselfs.
New things are always on the horizon
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
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.
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.
Hi. People still develop thick-client apps. The company I work for, which isn't huge but not tiny either, develops a couple web clients, and several thick ones. Our customers are happy having both. I can understand the desire to have both, but I simply cannot understand peoples' desire to move everything to the browser and forget about thick clients. Yes, web apps have been getting increasingly friendly, but they're still hosted in a browser.
And for what it's worth, I love C#. I didn't think I would at first, but having been using it for a couple years now, I'm dreading going back to (win32) c++, its kludgy preprocessor, its dozen different types of strings, its... general unprettiness. Yes, C# might be less portable, but so? Our customers are governments and large businesses, they all run Windows anyway. (And for the public-facing application for people who just want to retrieve one piece of information from anywhere, who might be using anything, that's what web applications *are* good for.)
As noted in that article, most of those complaints were fixed, or addressed already. Additionally, they used WPF instead of the more mature WinForms and/or the newer Silverlight that didn't have many of these issues.
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.