|
 I like the second one the best.
|
|
|
|
|
"My god, its full if 'car's"
|
|
|
|
|
I don't know about "largely", but there are some concerns. Like why ArgumentNullException and InvalidArgumentException don't agree on which order the parameter name and message should be in. 
(That's the only one that comes to mind at the moment.)
|
|
|
|
|
Two separate teams worked on each exception and they never spoke to each other 
Sunny Ahuwanya
"The beauty of the desert is that it hides a well somewhere"
-- Antoine de Saint Exupéry
|
|
|
|
|
Thank you, Captain Obvious.
|
|
|
|
|
PIEBALDconsult wrote: ArgumentNullException and InvalidArgumentException don't agree on which order the parameter name and message should be in
Mainly because there were really no defined standards for .NET when .NET 1.0 was first developed and it was something that "slipped through the cracks". Unfortunately, at the point it was discovered (after .NET 1.0 shipped), there was so much legacy code around that for Microsoft to have fixed it that they decided it was too large of a breaking change and so we are stuck with it.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
...er, and you get paid for that, right? 
|
|
|
|
|
I hate .net, but like I recently stated in the general discussion forum, when it comes to putting beans on the table, you gotta put philosophical considerations aside, and simply do what you gotta do.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: I hate .net, but like I recently stated in the general discussion forum, when it comes to putting beans on the table, you gotta put philosophical considerations aside, and simply do what you gotta do.
Agreed. It's why I have used classic VB for many years in the past. I try to hide that fact though. 
|
|
|
|
|
I guess I'm lucky. I don't have to use .NET: I put beans on the table using real C++, C, SQL, and the occasional bit of Python (for scripting) and rare assembly language (for performance).
Three sure signs that I probably don't want to install an (end-user) program:
- Requires VB runtime
- Requires Java runtime
- Requires .NET runtime
Maybe I just don't like runtime libraries!
I suppose since there are exceptions for .NET (I use Visual Studio, after all), it's the least of three evils. I've yet to see a Java or VB application that was what I consider commercial quality, though VB.NET certainly comes closer than earlier incarnations.
For me, .NET (and Java) put too many layers between the application and the hardware: too many unpredictable points of failure.
|
|
|
|
|
I've been coding, and paying the bills quite well with, C# for the last six or so years. Prior to that, years and years of VB classic. I cut my teeth on straight C for MS-DOS and am now forcing myself to learn C++ and the raw Windows API for one simple reason. I keep hitting brick walls when trying to deeply integrate with Windows using .NET for desktop and system type applications. It seems like Microsoft wants the rest of the world to write everything in the .NET language of their choice, but anything core to the OS or delivered with Windows is written in C++, the core stuff still being written in good ole C.
I have no intent of starting to develop everything in C++, that would be masochistic and just plain silly. But let's face it, there is a definite bias against using .NET internally within Microsoft itself. That speaks volumes. Just try and write a shell extension or integrate with Windows beyond the level built into .NET and you'll see where I'm coming from. It's as if a giant wall was erected with a sign that says ".NET developers travel no further, C/C++ developers welcome, come on in."
I understand they don't want us .NET developers venturing into dangerous Windows API territory, but if .NET is going to be all things to all people, then they need to do a better job of bridging the gap between the Windows API and .NET so .NET developers aren't forced to jump through inordinately painful hoops to get the job done.
|
|
|
|
|
You nailed it, Michael! I have only seen a couple of "real" applications come out of Redmond that are .NET. The first one that comes to mind is Office Accounting. Most things from them are C++.
You are right; that speaks volumes.
|
|
|
|
|
Matt Sollars wrote: You nailed it, Michael! I have only seen a couple of "real" applications come out of Redmond that are .NET. The first one that comes to mind is Office Accounting. Most things from them are C++.
ASP.NET, ASP.NET MVC and LinqToSQL/Entity Framework are 100% C# and there are lots of "real" applications being developed with those tools.
Todd Smith
|
|
|
|
|
Hi Todd,
I am pretty sure Michael was referring to Windows applications. I was certainly reading his comment that way when I replied.
I think Microsoft is definitely taking initiative with regards to developing Web applications on the .NET Framework. I credit Scott Guthrie for his absolute determination to drive excellence in the Web divisions of Microsoft.
|
|
|
|
|
Indeed I was referring to desktop applications and any other application that needs to deal with the Windows API in a manner not made readily accessible from .NET. There are certain types of applications that will never be written in .NET (at least not commercially viable ones). Imaging and multimedia applications come to mind most readily. Paint.NET is cool and I use it regularly, but it's no Photoshop and the thought of creating something like Photoshop in .NET is ludicrous. The same goes for video editing apps, audio processing applications, high end games, and a lot of other things. .NET is great for gluing together components, as was classic VB, but it's no replacement for C++ and I don't really think it was intended to be. Anything that needs to integrate with the Windows shell or attain the highest performance when manipulating bytes in memory will remain most comfortably in the domain of C/C++. Period.
Yes, for web development, .NET is awesome.
|
|
|
|
|
It's because C# is horrendously inefficient. Yes, this still matters even on quad core CPU's. There are things C# is good for, but for many many things it is appallingly incompetent.
C# and C/C++ pay my bills, and the largest C# project I'm involved in is currently getting optimized by converting a chunk at a time into native C or C++.
He said, "Boy I'm just old and lonely,
But thank you for your concern,
Here's wishing you a Happy New Year."
I wished him one back in return.
modified on Monday, February 9, 2009 1:53 PM
|
|
|
|
|
" It's because C# is horrendously inefficient. Yes, this still matters even on quad core CPU's. There are things C# is good for, but for many many things it is appallingly incompetent."
That depends on what you plan to use it for...
If it's the only item you reach for in the tool box for every item, then it really is like using a hammer on every job.
There are times you would want to use C++ instead of C, so why use C# for something better suited for C++?
"Many things" it's also very good at...
I.E. Usability, Compatibility, Flexibility, and Familiarity, which are IMO more important than efficiency alone.
I'd rather have a program run without hiccups and have plenty of support available than just run fast.
|
|
|
|
|
Michael A. McCloskey wrote: It seems like Microsoft wants the rest of the world to write everything in the .NET language of their choice, but anything core to the OS or delivered with Windows is written in C++, the core stuff still being written in good ole C.
I don't see a problem with this. Most programmers are developing business (or "enterprise" if you like buzzwords) applications and for that kind of development .NET is usually a better choice. MS is mostly developing system software and C/C++ rules that field.
|
|
|
|
|
Well said Nemanja. I don't understand this tendency to say or infer: "I can't write this type of application in .NET, or can't write it completely in .NET, therefore it's useless."
Kevin
|
|
|
|
|
Michael A. McCloskey wrote: I understand they don't want us .NET developers venturing into dangerous Windows API territory
I'm sorry, but that's just a bit silly.
MS may not want .NET apps used for some purposes, where the nature of the runtime would create system stability problems... but that's just common sense. If anything MS has too often gone in the other direction, adding features to languages that do little but introduce potential for serious problems - being able to load and call into arbitrary DLLs from their scripting engines for instance.
But regardless, that has nothing to do with you as a programmer. You're not a .NET developer, forever bound to a single framework; by your own admission, you've worked extensively with at least two languages and platforms prior to picking up .NET. Therefore, you are a programmer, able to use whatever tool makes sense to get the job done. As a former VB coder, you know what sort of idiocy was involved in calling system APIs from that language, and must surely realize that P/Invoke under C# is more or less the same deal; but whereas VB development allowed you to use C++ components to handle WinAPI-heavy tasks so long as they implemented a VB-friendly API, .NET provides C++/CLI to produce seemless integration between code leveraging PSDK headers and code wishing to call it. That's a huge step forward, IMHO.
As for the use of C++ inside of Microsoft... They're in pretty much the same situation i am, but to a much, much greater degree: decades of crucial legacy code too valuable to be tossed out on a whim, severe performance requirements, and a release schedule too tight to allow for moving to a new runtime without the hope of a serious, immediate, payoff. Don't ever look for MS to lead by example on this stuff; they're a gigantic software house with little in common with most of their customers. Use the tools that work for you, and ignore the rest.
|
|
|
|
|
Very well said. I'm doing exactly what you recommend. I've learned that .NET (or at least C#) isn't the right tool for many of the types of jobs I need or want to tackle. C#/.NET (and VB.NET) are the perfect tools for the vast majority of programming tasks (IMO). If I need to whip out a utility to do something, nine times out of ten it's going to be C# and .NET and I don't foresee that situation changing as I grow more dangerous with C++ and the Windows API. This is also true for gluing databases to a front end (rich client or web) and many other types of applications.
However... anything that involves dealing with the Windows API, beyond simple P/Invoke type stuff to get a control to do a new trick, is still overly painful from C# (although yes it is a LOT better than in VB classic). I maintain that .NET is viewed as something that the "customers" use within Microsoft. Anything cool and wonderful added to the OS is typically most approachable by C/C++ programmers using the raw API, then it gets wrapped and is made accessible to the MFC crowd, then if we are very, very lucky, it gets exposed through .NET, but by this time it's typically so watered down that many of the coolest features are inaccessible, or accessible only through herculean efforts.
WPF is a huge advance in UI architecture, but it lives on an island and doesn't play well with others. They try to wrap things up nicely for us (managed DirectX, GDI+), but leave out entire branches (DirectShow, MIDI and the other multimedia API's, etc.) As a .NET developer the question is always "Can I get there from here?", with C/C++, that's never a consideration. So I'm working to add it to my toolbox. I take solace in the notion that C/C++ will remain the dominant language for interacting with the Windows API and will always get first dibs on anything new added to the OS.
|
|
|
|
|
Shog9 wrote: MS may not want .NET apps used for some purposes, where the nature of the runtime would create system stability problems... but that's just common sense.
I think all this comes from the idea that .NET is not an all-embracing Windows programming platform, but a framework MS creates for us to write applications.
This subtle difference means that MS is not forced to "eat its dog food" - VS is not written in .NET.
Think about it: COM+ is used by MS, and it works: it is part of operating system. .NET is not a platform in which MS writes MS software, so it's not complete, its roadmap is changing ever so often (think about LINQ etc.)
(You know that you cannot get position of a contol within its Window in WPF - that is possible because MS does not care: VS is not written in WPF  )
Compare it with Java. There, NetBeans is written in Java (apart from small bootstrap start procces) since it needs to run on different platforms, and so Java is a complete operating environment.
Implications are obvious: you need unamanged code to tap into graphics - and Java accelerates imaging under the hood. Just because it has to.
So... that is how it's meant to be - are are given a limited set of classes for frequently used tasks. Be happy you have it. 
|
|
|
|
|
dmitri_sps wrote: (You know that you cannot get position of a contol within its Window in WPF - that is possible because MS does not care: VS is not written in WPF )
Actually, VS 2010 is written in WPF.
And you can easily get a control's position relative to any of its parents (parent panel, window, screen - whatever you want) - OK, its a tiny bit more difficult than in Windows Forms, but that's simply because the control could be rotated/scaled/whatever.
|
|
|
|
|
dmitri_sps wrote: VS is not written in .NET.
It's not written completely in .NET but parts of it are.
dmitri_sps wrote: .NET is not a platform in which MS writes MS software
This is not true. There is lots of MS software containing lots of .NET. Again, it may not be the case that 100% of a product is in .NET. But so what?
You can tell where .NET is being used by running Process Explorer and examining the .NET processes.
One very big product that is largely written in .NET is BizTalk. But I think you will find the newer the product the more likely it is that it will contain substantial portions of .NET.
Kevin
|
|
|
|
|
dmitri_sps wrote: This subtle difference means that MS is not forced to "eat its dog food" - VS is not written in .NET.
You picked a wrong example: VS is one of few MS desktop applications that are actually moving to .NET. The reason is the same as for NetBeans - IDEs benefit from CLR features such as reflection to help developers produce their applications faster. On the other hand, MS Office is native C/C++, but the same goes for Sun's OpenOffice. Windows is written with C/C++ - so is Solaris. CLR is written with C++, Java HotSpot as well.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
