You could argue that MS doesn't care about you, but only in the sense that no company actually cares about people. The company itself is the servent of its shareholders and will do what the shareholders want. That said, MS is full of multitudes of people who do care deeply about the individuals who use their products. For many, like myself, it's one of the most important reasons we develop software (the others being that it's fun, it's a great challenge, and heck you might just be able to make the world a better place doing it). The reason I care about feedback is because I truly want to make the most amazing product possible, and I have a better chance of doing that if I know how people feel. It's not about money. If I had my way I would then give it away for free to everyone, and that's something that I'm trying very hard to get done! :-) If you visit http://blogs.msdn.com/ you'll see tons of MS people who care so much about the community that they've taken on the additional role of interacting and bringing transparency of our processes because we care a lot and we feel that in the past we weren't doing enough for you. -- Cyrus (http://blogs.msdn.com/cyrusn)
Metasyntactic
Posts
-
Microsoft's politics -
What do you want in the next version of VS/C#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)
-
What do you want in the next version of VS/C#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)
-
What do you want in the next version of VS/C#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)
-
What do you want in the next version of VS/C#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)
-
Thoughts on Mono?Nemanja: Code that uses PInvoke will work on mono. As long as you link to a library that exports the function you are calling. This is similar to any other language. For example, if you use JNI you must ensure that the native code you are calling is provided on all platforms you want to run on. Similarly with C++ as well :-) -- Cyrus (http://blogs.msdn.com/cyrusn)
-
What do you want in the next version of VS/C#John: I highly recommend blogs.msdn.com. You'll find a lot of people from teh developer devision at MS who are posting a lot of information and who are all soliciting feedback. At this point everyone is trying to get feedback on the 2005 Betas so that we can make changes in time to ship on time. Now's really the time to let us know. If you don't, then it'll probably be on the order of a year later until we could do anything about it :-) -- Cyrus (http://blogs.msdn.com/cyrusn)
-
What do you want in the next version of VS/C#John: I come from a background using languages where there is no code/compile/link/debug/stop/code/compile/link/debug cycle. Instead, there's just coding. It's amazing how much time gets wasted waiting for these stages, and how productive you can get when you eliminate all of them and just let a developer develop :-) Note: In C++ today linking itself (not just the compile) is at the fastest on the order of 2 minutes. That means that at a maximum I can only relink 30 times an hour. Now, if I'm unlucky i'll make a chance that causes a full (or large) rebuild of our source which cane take around 5 minutes. That means that making a single change can end up wasting ~7 minutes of my time. not to mention the time that's lost if I need to get to right stage in debugging. However, I notice that in C# i don't need this functionality? Why? Because I use unit tests and never have methods longer than 1 or 2 statments long. I use many small classes with many small methods that are tested very carefully. Because of this I've never found the need to step into the debugger to tell what's going wrong. However, I am not representative of our customers. The debugger and debugging experience is a crucial part of the cycle for them and if we can add a feature that significantly improves that experience for a majority of them, then we will strongly consider it. Given the work I do in C++ i can certainly see why they would want this. -- Cyrus (http://blogs.msdn.com/cyrusn)
-
What do you want in the next version of VS/C#Marc/Daniel: I want to second this. This exact question came up on the blog: "what would you use aspects for". There were no good responses. In the end people wanted more flexibility anyways and the feature "allow attributes on more locations" seemed to subsume it. We'd like to get this functinality in a way that encapsulates Aspects and things like Pre/Postconditions in a natural way without overly affecting the language negatively. -- Cyrus (http://blogs.msdn.com/cyrusn)
-
What do you want in the next version of VS/C#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)
-
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)
-
What do you want in the next version of VS/C#Heath: Why are these not possible? One could have easily said the same about the previous most requested item "generics". It wasn't supported by the CLI, but we got it done anyways. If you read the previous posts on this topic you'll see that items were split into categories. Specifically, items the C# team could do on its own. Items that the C# team would work with others on. And items for other teams to work on. As to C#=VB. You might want to look in the feedback section for the previous posts on this topic. If you feel that it is a bad idea, please voice your opinion as to why, and tell us if you find fault with the reasoning that people are currently giving. The purpose of the blog is to find out what the community feels/wants. If you don't raise these issues there, then we run the risk of taking an idea here that you don't like and running with it. -- Cyrus (http://blogs.msdn.com/cyrusn)
-
What do you want in the next version of VS/C#John: That's interesting. I wrote an earlier post on how features could be harmful. One of the direct examples I used (along with E&C) was using regions to mask complexity in code and to make it appear simple. A 500+ line region indicates to me a bad code smell. Making regions and collapsing more advanced isn't necessarily the best thing to do in these cases. There is often a trade-off between power and risk in any IDE feature, and we work very hard to try and make it so that people will get the most benefit out of features without abusing them -- Cyrus (http://blogs.msdn.com/cyrusn)
-
What do you want in the next version of VS/C#John: "What a wierd survey, I suspect that people got together and jammed the ballot box so to speak because I can't imagine that being a top priority for the averge c# programmer. " There was no ballot stuffing. I got individual responses from real people. Almost all of whom justified why these were the features they wanted. If you read the original post on this you will see that I asked for that as part of the submission. That way I wouldn't just get votes from people saying "i want that because it's nifty" -- Cyrus (http://blogs.msdn.com/cyrusn)
-
What do you want in the next version of VS/C#John: "Are those people high on drugs or something? Who the hell ever used that when it was available previously?" If you read many of the previous posts made by myself or jaybas_ms, you'll see that there is indeed a large number of people who want this feature. Coming from a java background, I've used this myself. And, of course, in language environments like Smalltalk/OCaml you just get this naturally. For many, the ability to have edit and continue is a great boon to a common problem that occurs in the development cycle, namely that it's a cycle and it can take a long time to return back to a certain point. Anything you can do to reduce that time can be a benefit. Also, there are many (as I have learned) people who use E&C as a means to explore the system. How does a certain function respond to certain inputs? I dunno, I'll just fire up and app and try it out on all the inputs I want. It's very handy for prototyping out behavior and then implementing it once all the niggling questions have been answered. -- Cyrus (http://blogs.msdn.com/cyrusn)