What do you want in the next version of VS/C#
-
Heath: I'm going to have to disgree with you on this. The features that people requested were much talked about and were made by people who do understand both C# and the .NET Framework. Note: The items in the list are just summaries because I didn't want to use up too much space. "support for checkin enum values" goes beyond what is currently possible with the Enum class, etc. Could you tell me what enhancements to intellisense are intended for lazy people? On the intellisense team we try to think of things in a code focussed manner. A person is sitting in their code trying to get a specific job done. Everytime we force them to get distracted and work on something else (or navigate elsewhere) that means they can't be as focussed at the job at hand. We feel that reducing these annoyances goes a long way to making people more productive developers. I love to hear more on your opinions, however, so would a lot of other people as well. You are free to add feedback to these posts on my blog -- Cyrus (http://blogs.msdn.com/cyrusn)
IMO, IntelliSense itself is for lazy programmers. Sure, I benefit from it; it saves me a lot of time from having to type out methods and properties (especially those long ones like
FormsAuthentication.HashPasswordForStoringInConfigFile- but I also know what's in the BCL. Chris Sells himself once admitted in a .NET Show episode about writing his own MD5 implementation because he didn't know the .NET BCL already contained an MD5 implementation. Sorry, but there's no excuse for that; IntelliSense won't help you there, either. I'm not saying IntelliSense is a bad thing. It definitely saves time. But far too many people rely on IntelliSense to write code (something I find distinctly different from developing software). I reply to about 700+ questions a month in the C# forum (and sometimes a few other forums) here and answer many direct emails and see this happening a lot. Of course those that actually do read the .NET Framework SDK will most likely not have questions, so the sample is skewed; but the fact remains that many of these enhancements (like the new keyword completion; keywords are something anyone programming in C# should at least know already) simply foster lazy programming - the very programming you touched on: not having to leave the IDE to look-up help. With attitudes like that, it's no wonder why software stability is going down hill and that the means to make the software stable is being pushed into the frameworks (perhaps not entirely a bad thing), but even throughout articles in MSDN online does it touch on the fact that many programmers using RAD don't think (or flat-out just don't know) what's going on in the background and write extremely inefficient code. They said it in nicer terms, but it's clear what they were getting at. Besides, with the previous default settings in VS.NET 2002/03, help was integrated with the IDE. I noticed that in VS 2005 (at least in the Express build - I haven't received my full installation from MSDN Subscriptions yet and don't have the means to burn the DVD ISO at this time) that the default is to display external help. If the various teams responsible for .NET, Visual Studio, etc. agree with you about leaving to view other applications, these settings should be set to display internal help again (since the main page has gone back to using MSHTML in some form or another, unlike in VS.NET 2003). -
VI mode :eek: Some people are just sick!
"You can have everything in life you want if you will just help enough other people get what they want." --Zig Ziglar The Second EuroCPian Event will be in Brussels on the 4th of September Can't manage to P/Invoke that Win32 API in .NET? Why not do interop the wiki way! My Blog
Why not? VS 2005 supports Emacs and Brief emulation. I'm a VIM user myself (use it to write most of the sample code before posting it in the C# forum, in fact, using the command-line compiler to boot)...not that I'd personally like emulation for it in Visual Studio. :)
Microsoft MVP, Visual C# My Articles
-
Ramanan: No. If C# is not evolving the way you want it. Then get involved with the C# team by providing feedback on our blogs. You can also go to http://msdn.microsoft.com/ProductFeedback to report issues or sugggestions. All of these will be addressed and responded to. The purpose of the blog (as I have stated in posts in it) is to try and get closer to the xP ideals of communication and feedback. The belief is that with both you end up with the product the customer wants. However, if you don't participate in that then we won't know if we're going down the wrong path for you -- Cyrus (http://blogs.msdn.com/cyrusn)
Thanks for providing that link. I know that many people here would like to participate and provide (in most cases far more learned) opinions about C#'s evolution. Re: The blogs on msdn. There are soooo many. I check in every few days and I'm linked only to Raymond Chen's right now. I'm still trying to link to decide which other ones I can spend time reading. Anyways, thanks :) "I believe I referred to her personality as a potential science exhibit." - Elaine, about Ellen, in "The Dog"
-
Keyboard commands? That's so 20th century!;) Seriously though, if I can't use my mouse to do it, chances are it's not going to happen. (I remember the pre-mouse days of computers very well, in fact I wrote a lot of code back then, I'd just as soon have a little square box at the bottom of a region I can click on to collapse it.) Control m-control m still means I have to navigate to the bottom of the region to use it, if they can come up with a keyboard shortcut that will just collapse the current region only I would be very impressed and would definitely consider using it.
An election is nothing more than the advanced auction of stolen goods. - Ambrose BierceIt would be fairly simple to create a macro that searches for and moves down to the #endregion, then toggles the expansion state. Then, you can assign it to whatever keypress you want! [edit] Based on your other posts, desiring a way to do this with the mouse... You could also make a toolbar button for that macro if you want to use the mouse to run it. Though, you are confusing me. How do you write code using the mouse? Or is there some other reason your hand is on the mouse more often than the keyboard? [/edit] John
"You said a whole sentence with no words in it, and I understood you!" -- my wife as she cries about slowly becoming a geek. -
IMO, IntelliSense itself is for lazy programmers. Sure, I benefit from it; it saves me a lot of time from having to type out methods and properties (especially those long ones like
FormsAuthentication.HashPasswordForStoringInConfigFile- but I also know what's in the BCL. Chris Sells himself once admitted in a .NET Show episode about writing his own MD5 implementation because he didn't know the .NET BCL already contained an MD5 implementation. Sorry, but there's no excuse for that; IntelliSense won't help you there, either. I'm not saying IntelliSense is a bad thing. It definitely saves time. But far too many people rely on IntelliSense to write code (something I find distinctly different from developing software). I reply to about 700+ questions a month in the C# forum (and sometimes a few other forums) here and answer many direct emails and see this happening a lot. Of course those that actually do read the .NET Framework SDK will most likely not have questions, so the sample is skewed; but the fact remains that many of these enhancements (like the new keyword completion; keywords are something anyone programming in C# should at least know already) simply foster lazy programming - the very programming you touched on: not having to leave the IDE to look-up help. With attitudes like that, it's no wonder why software stability is going down hill and that the means to make the software stable is being pushed into the frameworks (perhaps not entirely a bad thing), but even throughout articles in MSDN online does it touch on the fact that many programmers using RAD don't think (or flat-out just don't know) what's going on in the background and write extremely inefficient code. They said it in nicer terms, but it's clear what they were getting at. Besides, with the previous default settings in VS.NET 2002/03, help was integrated with the IDE. I noticed that in VS 2005 (at least in the Express build - I haven't received my full installation from MSDN Subscriptions yet and don't have the means to burn the DVD ISO at this time) that the default is to display external help. If the various teams responsible for .NET, Visual Studio, etc. agree with you about leaving to view other applications, these settings should be set to display internal help again (since the main page has gone back to using MSHTML in some form or another, unlike in VS.NET 2003).Heath: A few points. First: " but the fact remains that many of these enhancements (like the new keyword completion; keywords are something anyone programming in C# should at least know already) simply foster lazy programming " I disagree. Having keywords in completion lists is intended to benefit those of us who find typing to be an incredibly slow cumbersome process compared to what our minds have already written out. Why type out the entire word "protected" when "pr" will do? Second: "With attitudes like that, it's no wonder why software stability is going down hill and that the means to make the software stable is being pushed into the frameworks" ... "many programmers using RAD don't think (or flat-out just don't know) what's going on in the background and write extremely inefficient code. They said it in nicer terms, but it's clear what they were getting at." I've heard that argument before. The first time was moving from assembly to C. Then it was C to C++. Then C++ to C#, etc. etc. :-) Inefficiency is a matter of perspective. I could write a code block that takes 100 times longer to do something than something you write. However, in the grand scheme of things, my way takes only .01 seconds. Is it inefficient? Sure. Do I care? No. I measure effciency in terms of my productivity, not just the final resulting code. And, if the code is too innefficient, then I will profile and improve it, either at the code level, or at the design level. But I won't put the pedal to the metal unless it's necessary. Third: Why would you need to burn express to a DVD? It's only 25 MB :-) Also, external/internal help is irrelevant here. Both require you to leave the code you are currently typing. What we are working on is trying ot make it so you have to go to help less and less. Fourth: As the the MD5 thing. I recently blogged about an feature I added to the IDE and was soliciting feedback on it. You can read about it here : http://blogs.msdn.com/cyrusn/archive/2004/06/22/163114.aspx The basic idea would be that he could have typed: "MD5" and we would have told him about the available types related to that. I've been trying to work on ways to incorporate "discoverability" into the IDE so that one can learn more of the BCL (which can be a daunting task). -- Cyrus (http://blogs.msdn.com/cyrusn)
-
If you read many of the blogs, the architects like Anders Hejlsberg said that things like
throwswill not be included for many different reasons, along with other things asked for in the list. Generics in the CLI were proposed long ago but due to time constraints were never implemented. While it was a new feature to the CLI recently, it wasn't a new idea in the minds of the architects. This has been blogged about as well.Microsoft MVP, Visual C# My Articles
Heath: I work a few doors down from Anders. Nothing is set or certain about the future of the platform or the language. We're constantly trying to improve both and we're looking toward the community to find out what people want. Also, I'm not sure where you are getting this thing about "throws". It wasn't in the list and it was never discussed by anyone as being something they wanted... Note: there isn't anything on that list that we're opposed to doing. Well, except for any feature that would break existing code (like making methods virtual by default). Also, almost none of them are new ideas either. However, the reasons we haven't done them so far relate to a combination of factors. Including how much time we have, how much customers want the feature and how much benefit we think they will get out of it. So, as you can see, it's the same as generics for us. We've been aware of it for a long time, we haven't had the time to do it, and now we're trying to figure out what users want the most so we can factor that into our decisions. Again. I ask that if you have issues with the things on this list that you bring your objections over to the feedback section on the blog and carefully explain your position. Different points of views can then be discussed with the others who have contributed so far. These discussions will play a large part in hte choices we make in the future. And if you don't give us this feedback then it's likely we'll pick things from this list that you will not want. -- Cyrus (http://blogs.msdn.com/cyrusn)
-
Thanks for providing that link. I know that many people here would like to participate and provide (in most cases far more learned) opinions about C#'s evolution. Re: The blogs on msdn. There are soooo many. I check in every few days and I'm linked only to Raymond Chen's right now. I'm still trying to link to decide which other ones I can spend time reading. Anyways, thanks :) "I believe I referred to her personality as a potential science exhibit." - Elaine, about Ellen, in "The Dog"
Yup. There are tons :-) It's a problem when everyone is excited and wants to talk to the entire community about all the exciting stuff they're working on. -- Cyrus (http://blogs.msdn.com/cyrusn)
-
Heath: A few points. First: " but the fact remains that many of these enhancements (like the new keyword completion; keywords are something anyone programming in C# should at least know already) simply foster lazy programming " I disagree. Having keywords in completion lists is intended to benefit those of us who find typing to be an incredibly slow cumbersome process compared to what our minds have already written out. Why type out the entire word "protected" when "pr" will do? Second: "With attitudes like that, it's no wonder why software stability is going down hill and that the means to make the software stable is being pushed into the frameworks" ... "many programmers using RAD don't think (or flat-out just don't know) what's going on in the background and write extremely inefficient code. They said it in nicer terms, but it's clear what they were getting at." I've heard that argument before. The first time was moving from assembly to C. Then it was C to C++. Then C++ to C#, etc. etc. :-) Inefficiency is a matter of perspective. I could write a code block that takes 100 times longer to do something than something you write. However, in the grand scheme of things, my way takes only .01 seconds. Is it inefficient? Sure. Do I care? No. I measure effciency in terms of my productivity, not just the final resulting code. And, if the code is too innefficient, then I will profile and improve it, either at the code level, or at the design level. But I won't put the pedal to the metal unless it's necessary. Third: Why would you need to burn express to a DVD? It's only 25 MB :-) Also, external/internal help is irrelevant here. Both require you to leave the code you are currently typing. What we are working on is trying ot make it so you have to go to help less and less. Fourth: As the the MD5 thing. I recently blogged about an feature I added to the IDE and was soliciting feedback on it. You can read about it here : http://blogs.msdn.com/cyrusn/archive/2004/06/22/163114.aspx The basic idea would be that he could have typed: "MD5" and we would have told him about the available types related to that. I've been trying to work on ways to incorporate "discoverability" into the IDE so that one can learn more of the BCL (which can be a daunting task). -- Cyrus (http://blogs.msdn.com/cyrusn)
Metasyntactic wrote: Third: Why would you need to burn express to a DVD? It's only 25 MB I'm talking about the full Visual Studio 2005 Enterprise build up on MSDN Subscription Downloads. At over 3.5 GB (IIRC), I'll definitely need it on DVD. I hate having to swap out CDs (with an installation process that long, it's nice to just walk away for a while). Learning the BCL can be a daunting task, but even with discoverability features the best way for people to learn is to at least browse through the BCL. This is what I recommend quite frequently. At least gaining familiarity with what's available might help down the road when you need a particular class. I realize that you work at Microsoft and know your stuff and I only know what I read in your blogs and what I've learned from experience in the trenches (studying the .NET Framework in-depth - down to the IL, PE/COFF EATs, etc.) and working with the people using it. If experience answering questions has taught me anything, it's that far too many programmers are trying to take the easy way out and IntelliSense plays right into that. Sure, it can help productivity, but it should be no replacement for learning. Education requires reading and experience, and there's no substitute for that (I'm sure that even old assembler hacks would agree, if any are still sane :)). In fact, just the other day a former coworker of mine and a good friend who works for another company now was commenting that they picked up code from some company that was in the process of creating DLL hell...with assemblies. They didn't know what the GAC was; they didn't know what strong naming was or how to do it; they really didn't much of anything except that they were programming in C# (the concept of the CLI was unknown to them). This is a company selling major software at a high price. My friend told them about the GAC and how it could solve the problem. Now how does IntelliSense or the new discovery feature you're conceptualizing help that? People need to read. Every day the regular forum members including myself are confronted with questions like "What does method XX do?" IntelliSense provides the summary and param info, but does not (nor could it, concievably) show the remarks and examples. Again, I'm not opposed to IntelliSense. It can help boost productivity but it it should not be a replacement for reading (even if it's just skimming the BCL docs to see what's available).
-
Heath: I work a few doors down from Anders. Nothing is set or certain about the future of the platform or the language. We're constantly trying to improve both and we're looking toward the community to find out what people want. Also, I'm not sure where you are getting this thing about "throws". It wasn't in the list and it was never discussed by anyone as being something they wanted... Note: there isn't anything on that list that we're opposed to doing. Well, except for any feature that would break existing code (like making methods virtual by default). Also, almost none of them are new ideas either. However, the reasons we haven't done them so far relate to a combination of factors. Including how much time we have, how much customers want the feature and how much benefit we think they will get out of it. So, as you can see, it's the same as generics for us. We've been aware of it for a long time, we haven't had the time to do it, and now we're trying to figure out what users want the most so we can factor that into our decisions. Again. I ask that if you have issues with the things on this list that you bring your objections over to the feedback section on the blog and carefully explain your position. Different points of views can then be discussed with the others who have contributed so far. These discussions will play a large part in hte choices we make in the future. And if you don't give us this feedback then it's likely we'll pick things from this list that you will not want. -- Cyrus (http://blogs.msdn.com/cyrusn)
As far as the "throws" bit, this was discussed in the multi-part series of articles Anders did with some online mag (it was a while back, so I don't remember the details). "Throws" was brought up several times. Sure nothing is written in stone with the future of either C# or the CLI but the last thing I'd want to see is a bloated framework. Metasyntactic wrote: Again. I ask that if you have issues with the things on this list that you bring your objections over to the feedback section on the blog and carefully explain your position. Different points of views can then be discussed with the others who have contributed so far. Perhaps. I'm not fond of a large discussion in a flat format (non-nested). Unless people are quoting other responses (or something along those lines) it's very difficult to follow. Sites like CodeProject and Slashdot (while I hate their constant and often groundless/mindless Microsoft bashing) are much easier to follow. I will check it out, though. Normally I just read the blog item and skim the comments.
Microsoft MVP, Visual C# My Articles
-
As far as the "throws" bit, this was discussed in the multi-part series of articles Anders did with some online mag (it was a while back, so I don't remember the details). "Throws" was brought up several times. Sure nothing is written in stone with the future of either C# or the CLI but the last thing I'd want to see is a bloated framework. Metasyntactic wrote: Again. I ask that if you have issues with the things on this list that you bring your objections over to the feedback section on the blog and carefully explain your position. Different points of views can then be discussed with the others who have contributed so far. Perhaps. I'm not fond of a large discussion in a flat format (non-nested). Unless people are quoting other responses (or something along those lines) it's very difficult to follow. Sites like CodeProject and Slashdot (while I hate their constant and often groundless/mindless Microsoft bashing) are much easier to follow. I will check it out, though. Normally I just read the blog item and skim the comments.
Microsoft MVP, Visual C# My Articles
I'd like to clarify the part on "throws". While we might be against the specific way that exceptions have been handled in other languages in the past, we are very open to addressing this issue if enough people are interested in it. So, if you had seen something in the list like "better support for exceptions (like 'throws')" that wouldn't mean "we're going to add throws exactly like it's been done in the past with all the same problems that we've seen crop up. It means that we're going to work on a solution that helps out with the problems that users are having. I do appreciate you looking at the articles. Constructive feedback there is a chance to get the outcome you would like out of all of this. -- Cyrus (http://blogs.msdn.com/cyrusn)