Go away, or I shall taunt you a second time!


Some silly person (with a silly name) had the audacity to make the following claim yesterday in the feedback section of my C# express post:

“the vb and webdev express tools would be neat for our devs to try out. yes, smear vb all you want, it’s still the best tool for what we need to do. while they’re at it, i’ll see if they want to try c#. it’s nigh impossible to convince an army of supar-fast vb coders to switch to something else, but it looks like these express packages are a good way to play around.

Fuzu”

(so supAr-fast, they can’t even be bothered to spell right!!).

Well, her name isn’t actually all that silly (maybe an itsy bit. but then so is mine). And when you know her in real life she is actually pretty awesome. And there is a heck of a lot of truth in what she said. In fact, she’s definately not the first to say it here. Kavan and others have been pretty adamant that there are features whose lack in C# causes serious development woes after being accustomed to them in VB.

As many of you have seen, I usually play a pretty strong Devil’s Advocate (i.e. “someone who takes the worse side just for the sake of argument”) when people suggest changes or features. I do this pretty much because I won’t want to work on something unless I thought it was worth it. And if you can convince me that it’s worth it after I take the opposing position, then it is probably a pretty darn good idea :-)

So I’d like to know what it is about the VB language/toolset that you not only love, but you think makes you a better (in whatever way you measure it) developer, and which you find noticeably, and detrimentally, absent when you’re in C#.

I’m going to head off the pass by saying that we’re very aware of Edit&Continue. We completely understand that there are many out there that find it an indispensable tool. About the only thing that would change that opinion is if we suddenly got a wave of negative reactions to it, and so far that hasn’t happened yet. Of course, you’re absolutely free to mention it :-) Named parametes and optional parameters we’ve already had a long discussion on, but I’m still looking for examples to help convince me that they’re a good thing in the end.

Interestingly enough, when we’ve brought this up other times, one of the most common responses was: “In VB, when you call a method that takes an Enum, the Enum automatically comes up preselected, so I can just select the value”. We heard this so much that we’ve added that to whidbey. However, I feel that there are other things that are also much more important then that editing boost and we would really like to know what they are for you.

Alternatively, if there are things in VB that you really dislike and definitely do not want to see in C#, let us know about those as well. Currently we feel that we don’t want to throw in everything, but based on how you feel that might change in the future.

Oh, and Fuzu, if you can stop being the maniacal task-mistress for 5 minutes, we’d really appreciate it if you could get a dev or two to tell us why VB makes them sup4r-f4st!! There’s a free dinner (or more) in it for you if you do!


Comments (92)

  1. Aaron Junod says:

    I am a c# guy stuck in a vb.net world. Although my roots have quite a bit of vb, when .net came I took to c#. Now my job requires I do most of my coding in vb.net.

    I admit, vb.net allows alot of things to be done quicker. The little things like enum intellisense help me move faster. I also like being able to turn option strict off for writing unit tests (unless something would stub out my "tested" methods/classes as I add test stubs).

    But, in the end, I still miss c#. Or maybe just the compiler. Even with option strict on, you never see things like "Not all code paths return a value", or the errors when you have initilized a variable. Although in some cases this is nice (writing tests), when it comes to my actual code I want to know this at compile time. Now I have to wait to build time, and hope my unit tests accuratley test scenerios where that could be a problem.

    In writing this, I just realized something. I think someone should draw a line between writing tests, and actual program code, and then offer different options based on that. They are totally diff coding paradigms, and really merrit diff behaviors not only in the compiler, but the IDE.. Hmm.. think I gotta think about this more.

  2. Aaron: OMG. About tests vs. code. I’m going to let Jay blog about that as well so I don’t steal his thunder :-)

    could you explain a little more about stubbing out tests?

    We added a new feature called "generate method stub" that would, based on a call to a non-existent method, allow you to automatically generate the method in the right location. Would that work for you?

    Anything else that makes you able to do things quicker?

  3. adam says:

    I don’t want to see in C#

    * vb "with" statement (in fact if you can take it out of vb that’d be good :)

    * background compiler unless it has _exactly_ zero impact on the editor (speed/response) on a low spec machine or you can _easily_ turn it off (if you can get that option into vb, that’d be good).

    I couldn’t care less about EnC in C#. Modifying variables and manipulating the IP are good enough. After EnC you would still have to re-run after a full re-compile anyway. And EnC will enable you to locate a bug and then skip the _very_ important "write test to catch bug and fix and proved test passes" stage.

    I’d like to;

    * have the ability to execute as much as possible in the immediate window during debug.

    * reference exe assemblies not just dlls

    * easily switch off the Watch window property execution to avoid those ever so nasty ‘bugs’ I’ve seen.

  4. x says:

    I wish the switch statement in C# was more like the case statement in vb where it allowed to use a range as a condition for a case (like case "A" to "Z", i < 20).

  5. Adam: can VB reference executables?

    You can switch of "func-eval" in the watch window through the debugger options.

  6. x: it seems like:

    if (foo >= "A" && foo <= "Z")

    and

    if (i < 20)

    Are just as equally brief as the ‘case’ counterpart. What does that gain you?

  7. fuzu says:

    Just some fair warning – we’re not a software house. Ultimately, we are a financial services firm. We don’t have builds or code trees or massive sprawling projects transcending libraries across the universe. Our devs are here to handle data and develop ad hoc features for others to view that data and easily create transactions. One of the key tools that we and all our clients use is MS Office. That being said, one of the advantages of vb for us is how easily it plugs into all the Office apps. When someone throws us a request "Hey, we need to import this Excel data into another Excel file, model this financial transaction using some custom functions, graph the results into a formal report, then spit out a Word mail merge using some of the resulting fields, along with the envelopes to mail the letters out in, then automatically send e-mails to these 5 managers that the merge has been completed."

    Well, I’m guessing you can do that in C#, but it’s so much easier to just open the vb editor from within each Office app…

  8. Adam: Do you find VB perf being an issue for you? I’ve heard they’ve worked on this a lot for 2k5. If you try it can you let us know if you find it ok now? Thanks!

  9. Adam Young says:

    I dispute that VB makes you a faster developer; I think there’s a subtle difference between VB and other languages that improves productivity, and that is the fact that VB (the *language*) is targetted at beginners and inexperienced developers, in order to make these kinds of people productive immediately (rem: Beginner’s All purpose Symbolic Instuction Code). MS are continuing this tradition with features such as the My namespace and classes, which will make devs unaccustomed to .net development (VB6 coders) extremely productive.

    The IDE features that VB showcased in its early versions, such as edit & continue intellisense, a visual forms designer, and so on, are nothing to do with the language per se, and most of these VB-IDE features have been absorbed into vs.net; they do get comfortable, and it’s the lack of these in C# that shocks and horrifies the VBer, not the language (I lie – it’s also the fact that the veil over OO dev that has blinded them for years is suddenly pulled back).

    I think VB will continue to be positioned as a quick-way-in to development for those without a dev background, or non-technical users, or for learning purposes. Experienced VB-ers who have reached enlightenment, who find themselves constrained by the lanuage, will turn to C#. I’d like to see edit & continue added to C#, as much as anyone else. I would be horrified if optional params were added to C# – that’s what overloading is for!

  10. Luc Cluitmans says:

    (sorry for taking this slightly off the original topic, but the issue of ‘C# features’ triggers my blog-response fingers… Background: I have zero VB background and try to stay away from it as far as possible)

    Quote(adam): "* reference exe assemblies not just dlls"

    Yes please!

    Note that in some cases you can work around this using ILMerge (downloadable from research.microsoft.com): you can use ILMerge on any collection of assemblies (that dont contain native code) to fuse them, and emit the result as a DLL or EXE. That includes the special case of ILMerging a single .EXE to a single .DLL :-) Btw, is there any chance of ILMerge becoming an official tool in the .NET SDK?

    And on the topic of the ‘switch’ statement:

    It is probably too late to change that ever, but if you were redesigning C# from scratch, please redesign the switch statement so those horrible breaks are not necessary anymore. I tend to wrap my case statements in braces, why not require them? For example (dunno if the formatting will show up correctly):

    switch(foo)

    {

    case 1:

    {

    DoFoo();

    break;

    }

    case 2:

    {

    DoBar();

    break;

    }

    }

    I would prefer it if the breaks could have been left out. The fact that the breaks *must* be left out if the case block ends with a return or throw is a bit of a wart too.

  11. Karl says:

    I think C# totally needs to implement on error resume next!

    Seriously though, the IDE is definetly one of the biggest ways in which vb.net is superior. Improved intellisense across the board, and greatly improved in whidbey. C#’s IDE support is so weak, I turn off the features and rely on 3rd party tools such as CodeSMART and especially Reshaper.

    The other thing is case-sensitivity. This to me is a mixed bag, since the .net framework itself is mostly case sensitive, it’s useful to have always-on case-sensitvitiy. On the flip side, i often find it a pain. i think my particular problem comes from switching back and forth between the two languages.

    Background-compilation in vb.net is for the most part extremely useful, and is getting better with every release.

    I agree, keep the "with" out.

  12. Karl says:

    Luc:

    How do you flow from one case into another, if you take out the break? This is something that comes up every once and a while and can’t be done in vb.net

  13. Simon says:

    Cyrus: In reference to fuzu’s comment about VB in office – this is why I said someplace else (what don’t you want to see in c#) about hating that they used VB in office and never wanting to see it again anywhere. It’d be fine if you could use any .NET language in office for macros – but you can’t.

    Your office manipulating .NET code needs to run as an addin or an out of process controller for the actual office products.

    As it is it breeds vb developers, and that’s never a good thing, since in my experience vb developers like vb and that’s just… wrong.

    Uh, I mean, since in my experience vb developers have a tendancy to write things without properly thinking them through first, without proper error checking or thinking about bounds or if the user is going to put obscenely wrong data in, etc. – just generally poor quality code with the attitude that vb is quick. In reality it’s that they’re leaving important bits out.

    If you write the same code in several high level languages there should be a negligible time difference in development.

    All this is assuming similar IDE features of course… Which would be nice.

  14. Dave Rothgery says:

    Luc – IIRC, you can’t do C-style fall through in C#; fall through is only allowed if you do case X: case Y: …. . This isn’t needed in VB, because you can do Case X, Y.

    Adam Young – starting with VB.NET 2002, there was very little you could do in C# that you couldn’t do easily in VB.NET (and vis versa). In Everett, the gap closed a little more. In Whidbey, the C#-only features seem really esoteric to me (annonymous methods, ‘yield’ iterators, unsafe code), while the VB-only features mostly have real value to line of business developers (case insensitivity, the My namespace, delcarative event handling). Exception filters are VB only just so that we VB types have one VB-only esoteric feature :).

  15. John Cavnar-Johnson says:

    The biggest reason I stay with VB is a feature that I never expect to see in C#: case insensitivity. Actually case sensitivity is just a symptom of a broader philosophical leaning of the C family of languages. In the beginning, I viewed C as a portable assembly language. I think that’s a valid description of C (but not the only valid description). As such, C has influenced all of its derivative languages with a very hardware-oriented perspective. From the perspective of a computer, there’s no relationship between the representation of ‘A’ and ‘a’. To people, on the other hand, those symbols have a very deep intrinsic connection.

    Every program we write has two audiences: the computer and the other programmer (the one who will maintain my code. Even if that’s me in 3 months, it’s another progammer). C-style languages tend to express more directly what we want the computer to understand while VB (and, I know everybody hates this, but it’s true COBOL) does a better job of expressing what we people understand. As our development environments move further and further away from the hardware, the C approach seems more and more out of place. I don’t expect to make any converts with this argument, but I would like folks to recognize that some of us have thought a lot about why what Fuzu said is true. It’s not a particular feature of VB, it’s something much more fundamental.

  16. D. Brian Ellis says:

    Ick. I guess this is where you see the differences in coders…

    1) I love the break; statement in switches. Do not take it out

    2) I will go back to Ada or something equally horrible if you take out the case sensitivity in C#

    3) Edit and Continue isn’t that important to me.

    4) I agree that optional parameters are not needed, that’s what overloading is for.

    So what do I want?

    Mostly just better fixes for what’s already there, especially better handling of Indexers and function calls in the watch window.

    P.S. Re: Adam: You can already reference .exe files as .NET components, they just took it out of the IDE for various reasons (Best practices, thought nobody would want to, who knows?). You can reference .exe .NET components though if you’re compiling from the command line. FYI.

    Brian

  17. James says:

    The feature I’d like is more part of the IDE, in an area of the code view who’s name I do not know exactly.

    First, I’d love to see VB.NET’s Handles event hookup for one in C#.

    Secondly, dependent on that, I’d like to see the two drop down boxes above the code window in C# be like VB.NET: that is, showing not only the methods and events you have implemented, but those that you could override or implement. In VB.NET, I can just drop that box down, find the method, click on it, and a stub is created automatically.In C#, those dropdowns duplicate the functionality of the Class View, and just shortcut to methods I’ve already implemented. I find navigating through the Class View in C# to take significantly more time than using the dropdown in VB.NET.

    I’m natively a C# developer, but in doing a VB.NET project the last 6 months, this is one feature I’ve grown to really enjoy.

  18. I would really like to see an "uncastable" operator, so that if I have something like this:

    public class Foo<T> {

    private List<T> aList_;

    public IEnumerable<T> Items {

    get {

    return aList_;

    }

    }

    that I can protect the returned enumerator from being cast down to a list and then modified. To do this currently I would have to create a wrapper type that implemented the interface. However, having to do this manually is a bit irritating. It would be nice if the compiler could do it for me, or if the runtime could just prevent the type from being down cast. Something like this would be nice:

    public class Foo<T> {

    private List<T> aList_;

    public IEnumerable<T> Items {

    return uncastable(aList_ as IEnumerable<T>);

    }

    }

  19. Munish Gupta says:

    I agree with John Cavnar-Johnson that case-insensitivty is a big reason for me to stay with VB.NET. I have been a C/C++ developer for about 9 years now and I can type with a decent speed. But remembering if a variable was named "count" or "Count" is always a hassle.

    Even worse is keeping track of "similar" looking variable names used for totally different purposes. With VB I don’t have to worry if I pressed the ‘shift’ key at the right places or if I have the caps lock on. Typing is atleast 50% faster! It ‘auto-cases’ for me and if it fails to do that then its instant compilation (in most cases) telling that I am not using the right function or variable. Ofcourse with excellent Intellisense in whidbey that’s redundant.

    Also with its ‘auto-casing’ it forces me to choose variable names that are different in more than just case. Its much more useful than you would initially think.

  20. E says:

    I am a C# developer.

    I hate case-insensitivity. Class names start with UPPER CASE letters (Person), instances start with lower case letters (person). Immediately, I know the meaning based on the case.

    Someone suggested that switch-case fallthrough was not possible, though in fact, it is, and here is how:

    switch(i) {

    case 1:

    // do something

    goto case 2;

    case 2:

    // do something else

    break;

    }

    You can also do "goto default;"

    I think the worst things about VB is that its the compiler is too lenient, and so what should be compile time errors (or warnings), become runtime errors. Why even bother running code if the compiler can tell you its broken?

    "on error resume next" is the other big one. If I look at VB code and see this line at the top of file, I know that the dev who wrote it had no idea what they were doing. A lot of inexperienced VB devs (the majority?) use "on error resume next" as Neosporin for their code. They just slather it on and watch their errors dissappear.

  21. Derek says:

    When I started out on .Net, I was a VB developer. I changed jobs a little over a year ago, and I had to change to c#. There is absolutely no way I would want to go back to VB.Net. I thought that I would hate case-sensitivity, but now I like it much better than case-insensitivity.

    The 1 thing that I miss from VB.Net is the optional parameters. I understand that most cases where this is needed can easily be done with overloading, but I think optional parameters are much more readable in the intellisense because it tells you they are optional and tells you what the default value is.

  22. Optional parameters should never be allowed in a truly object oriented programming language. I’d recommend that it be removed from the VB language as well. It was a bad idea that lead to bad programming. Just look at the Microsoft Office API’s if you think optional parameters are a good thing. It starts out innocent enough with 1 or 2 optional parameters and soon your function has 10+ optional parameters and anybody using your code has no idea what the function does without very detailed documentation, which let’s face, it very rarely happens (my documentation for most things is nothing more than the object browser).

  23. Dave Rothgery says:

    e – The comment on switch-case fall through was mine. I’d say that if you have to use a goto to achieve it, then it’s just as possible in VB as it is in C#, and rarely good programming practice in either.

  24. Fuzu: "Just some fair warning – we’re not a software house. Ultimately, we are a financial services firm"

    You’re a customer and we couldn’t care less if your using it for some small in house tools, or large scale enterprise level applications. If we can make our tools better for you and everyone else, then we want to do it :-)

    Really good point about the embedded VB support in office today. I know with VW2k5 we’re shipping some sort of integrated Office/VS solution (Which you can use C# in). But I know very little about it. I’ll try to get you some more information on how this will help you with both VB and C# development!

  25. Adam: "The IDE features that VB showcased in its early versions, such as edit & continue intellisense, a visual forms designer, and so on, are nothing to do with the language per se, and most of these VB-IDE features have been absorbed into vs.net; they do get comfortable, and it’s the lack of these in C# that shocks and horrifies the VBer, not the language"

    I agree. But I was talking about oth tools and the langauge. The IDE is just a tool, but if it’s massivley benefitting the VB customer in ways that C# developers miss, then we’ld like to know about it.

  26. Luc: Break statements are required so that you make your intent perfectly clear. Either you are breaking our of the switch or you are continuing on to another case label. By making that explicit an entire class of common bugs is removed with no lack of expressive power. That’s our justification at least :-)

  27. Karl: "Improved intellisense across the board, and greatly improved in whidbey. C#’s IDE support is so weak, I turn off the features and rely on 3rd party tools such as CodeSMART and especially Reshaper. "

    Karl!!!! Please be more specific!!!! I’m dying to know why you think the IDE support is weak. This is exaclty the feedback I’m looking for here. How can we make our tools better for you???

    "The other thing is case-sensitivity. This to me is a mixed bag, since the .net framework itself is mostly case sensitive, it’s useful to have always-on case-sensitvitiy. On the flip side, i often find it a pain. i think my particular problem comes from switching back and forth between the two languages"

    Karl: We’ve improved this experience in whidbey (try out C# express!!). If you are a case insensitive person then:

    a) You are going to be naming things differently, not just with different casing.

    b) Our new completion model will allow you to then type something like:

    metadata and we will correct that to metaData if that’s the only thing matching. This allows you to type in a case insensitive manner while still allowing you to name things the way you want to. Let us know if this helps you!!

    I can explain more if anyone is interested.

  28. Simon: There are poor developers across all langauges. But I do agree that tools can be abused and that it’s vital to teach good use and good practises along with everything else we do.

  29. D. Brian: "Mostly just better fixes for what’s already there, especially better handling of Indexers and function calls in the watch window"

    Could you please give me more information on this! Thanks!

  30. James: "First, I’d love to see VB.NET’s Handles event hookup for one in C#.

    Secondly, dependent on that, I’d like to see the two drop down boxes above the code window in C# be like VB.NET: that is, showing not only the methods and events you have implemented, but those that you could override or implement. In VB.NET, I can just drop that box down, find the method, click on it, and a stub is created automatically.In C#, those dropdowns duplicate the functionality of the Class View, and just shortcut to methods I’ve already implemented. I find navigating through the Class View in C# to take significantly more time than using the dropdown in VB.NET. "

    Thanks james! Those are both very interesting suggestions. We do have the += syntax to attach a method to an event. But it sounds like you want stronger tying in from us in this regard like how VB does it.

    I like the drop down box idea. Definitely something for us to consider. We already have the "override" autocomplete, but yours serves both utility and helps in exploring/understanding the system.

  31. Scott: "To do this currently I would have to create a wrapper type that implemented the interface. However, having to do this manually is a bit irritating."

    You don’t have to do this scott.

    YOu can do:

    return myList.AsReadOnly();

    which will do the same thing for you.

  32. Munish: Would you like to know more abuot how C# helps in this area now?

    I gave a presentation of that at tech-ed and actually got applause. So i think that people who appreciate this feature of VB like you do will be happy that C# now handles htis a lot better for you.

  33. Vince Pacella says:

    Cyrus: Can you explain exactly what your "job" is, and I dont mean in some philosophical sense :).. It will help me put your posts into context. I know I got to your blog from somewhere that said what it was but I’ll be damned if I could remember it now.

  34. Duncan Godwin says:

    An editor feature I would like to see for rich validation could save compile time errors – Method parameters could be validated i.e. will the parameter work directly, though a specified cast, or though an IConvertible become an acceptable parameter in a given position.

    This could also work for return values.

    I have a method:

    void DoSomething(int value) {}

    If I type

    DoSomething("45");

    The 45 would be underlined in some colour indicating it’s not an int.

  35. Duncan: Yup. I’m working on something like that. Can’t give you any promises though :(

  36. Sjoerd Verweij says:

    Cyrus: Forget about reshaper — it’s a refactoring add-in for VS2003.

  37. Sjoerd: Why do you want me to forget about that? We consider refactorings to be incredibly important now and in future releases. I want to know how these help everybody and what we can do to make the experience as awesome (or better) as the existing tools

  38. Fuzu: Check out: http://blogs.msdn.com/vsto2/archive/2004/06/30/170315.aspx

    To hear about Visual Studio Tools for Office 2005 (can’t we come up with names that are less of a mouthful?)

  39. Dave Rothgery says:

    Cyrus – it’s okay to admit that C# does some things the way it does just to be more familiar to C++ and Java developers, even though in a vacuum they’re kind of silly. Requiring break in switch is one of those things.

    VB7+ (since the VS.NET and VB.NET names are going away with Whidbey, I’m trying to phase out their usage now) doesn’t default to Option Strict On, has True = -1, and has AndAlso and OrElse for short-circuit boolean operators instead of And and Or for much the same reason.

  40. Dave: Could you clarify that? Why is requiring a break in a switch silly? :-)

  41. fuzu says:

    Cyrus: Thanks for the link. We’re going to be upgrading a couple workstations shortly, so I think I’ll take one of the old ones and use it for some VSTO testing (don’t want to destroy any production machines 😛 ).

    As for naming, if you knuckleheads just move the ‘2005’ it makes a lot more sense: "Visual Studio 2005 Tools for Office"

  42. Fuzu: Genius!! You should be in marketting!

  43. Vince Pacella says:

    I just had VS2003 C# blow up one of my Windows forms. This happens about once a month (not to mention the daily can’t-build-because-one-of-the-DLLs-i-manage-is-locked errors.

    Though in the past it was always a mystery to me on why some of my controls and components would just poof vanish.. but as I was comparing versions in SS I noticed the RESX files were not checked in always (at least today) and the last check in was the file that was completely managed. If I didn’t think to look there, I wouldn’t have been able to even make a guess why my hard work had been obliterated. I hope this doesn’t continue.

  44. Vince: Both issues are things that got a lot of attention and investigation to eliminate.

    We think we have found (and eliminated) the "control went missing" problem. That was due to an excellent investigation by Renaud on our team and the developers on the WinForms team. It turned out to be due to a 1 line perf enhancement that could non-deterministically cause problems. I probably can’t tell you what it was exactly, but it was a major pain (like most non-deterministic things) to find and solve.

    The dll locking issue is also something that has been (and is being) addressed. We’ve gotten so much feedback that all the teams working on producing and consuming dlls have done serious work to make sure that this won’t happen.

  45. Vince Pacella says:

    Cool man. Those two problems are pretty big ones (especially the raptured component) however I kept my cool about it because VS2003 is/was the best IDE I had ever used. Before late last year my last programming work was in 2000 in Java using IBM’s IDE which was so bad the name escapes me right now. I’m so glad Windows clients are coming back, In mid 90s I was forced to turn one of my old Access programs (I am now scorned by everyone :)) into an ASP app and while I was glad to done with JET/Access and happy to use 6.5, creating and using an HTML interface was the pits. Now i have to reconstruct my form from the ashes.

  46. Luc Cluitmans says:

    Quote(Karl): " Luc:

    How do you flow from one case into another, if you take out the break?"

    You don’t. Cases should never flow into another, that is actually the heart of what I was trying to say. Having a ‘break’ suggests that it would be possible to flow from one case to another (which in C# it isn’t, unless you use ‘goto’).

    I have been burnt a few times too many by cases flowing into another accidentally in C/C++/Java, and that is why I would like to make it clearer that fall-through should never happen.

    I have to admit that currently the switch statement is so similar in syntax to C/C++/Java that people will expect support for fall-through, and therefore a break is required. If C# would be redesigned today, I would suggest using some other construct that doesn’t look so much like a C/C++/C# switch that people will expect this behaviour. For example, it could be based on keywords used in other languages, such as the XSLT choose-when-otherwise constructs. It does the same as switch-case-default, but without the inherent fall-through expectation.

    To turn this discussion back on topic, what is the VB equivalent of the switch statement (as mentioned, I know zero about VB)? Can you fall through there, or are fall-thoughs automatically prevented by the syntax?

  47. Luc: I understand everything you are saying. However, I’m not seeing the benefit to that system over the current one.

    Sorry, I don’t know about VB. But you can ask Paul Vick about it :-)

    http://www.panopticoncentral.net/

  48. Luc Cluitmans says:

    (Eh, how do I fix typos in a comment? Obviously the phrase ‘C/C++/C# switch’ occurring in the fourth paragraph of my previous message should have read ‘C/C++/Java switch’)

    And Cyrus:

    Yes, as you can read from my message above, I am fully aware that you put in the ‘break’ requirement to prevent accidental fallthrough. What I was trying to say is that that shouldn’t have required an explicit break statement, fallthrough should simply never be allowed, no syntax required.

  49. interesting. Without fallthrough I really don’t see any need for a switch whatsoever. If we took it that far I would say that we should just limit you to if/else statements.

  50. Luc Cluitmans says:

    Well, I prefer the switch syntax to a long chain of if{}else-if{}else-if{}else{}.

    If only for the fact that you cannot accidentally forget an ‘else’ in the middle of a switch… I have had some debugging sessions where that was the root cause of the bug I was tracking down (originating from a bad cut’n’paste), causing the chain to be split in two independent chains, for which the second ‘default’ (final ‘else’) case would unintentionally fire for anything handled by the first chain as well.

    Also, I like to use ‘switch’ when handling all cases of an enum, adding an Assert to ensure the ‘default’ case doesn’t happen.

    And I love the automatic handling by the C# compiler of handling a switch on a string value; there is no simple equivalent of that in if-else chains that is equally efficient and elegant.

  51. Luc: Ok. Fair enough :-)

  52. John Lam says:

    As a reformed C++ dev, I would LOVE to see an option strict off option for C#. This would let me get closer to dynamic typed goodness in a language with semicolons. I’m seriously thinking about spending some time in IronPython in the future so that I can get a better feel for dynamic typed languages. But for the time being, VB will have to do.

    I’ve spent far too long in the mindset of "my compiler will catch most of my bugs for me therefore unit testing is optional". My gut feel is that decent unit test coverage will eliminate the subtle bugs that option strict off can sometimes cause. In return, I have less friction when writing code.

    Like someone said around here, a debugger can be a crutch. I would argue that a compiler can be a crutch as well.

  53. Sjoerd Verweij says:

    C# 2005 Express kicks serious butt. Really. Most of the gripes about refactoring etc. on here have been taken care of, and taken care of well.

    My wishlist:

    – Immediate window

    – E & C

    – Better/more flexible autoformatting. Please make this the first IDE to support my style:

    private class

    MyClass

    {

    int i;

    }

    etc.

  54. Ron says:

    Luc and Cyrus,

    You can’t fall through with C#’s switch statement. Well, you can, but only if your case is empty. You have to explicitly use goto in order to use the code in another case (or default). If you try to fall through, you get a compiler error.

    The VB syntax is Select Case-Case-Else-End Select. VB doesn’t allow fall-through, though it can be faked with labels and GoTo. VB also allows dynamic cases. Meaning,

    Dim letter As Char = "a"c

    Dim someotherletter As Char = "a"c

    Select Case letter

    Case someotherletter

    Dim i As Integer = 1

    Case "b"c

    Dim j As Integer = 2

    End Select

    will evaluate true in the first case. I know the technical reasons why switch doesn’t do this, but iti would still be a nice feature if it did allow it.

    Like Luc, I really like the switch syntax over a long chain of if-else if-else if-else. It’s just cleaner to look at.

    I would second the call to add the potential events to the dropdown lists in the C# editor. It provides a consistent way of getting to these events (between VB and C#).

    I personally like case-insensitivity, but I’m not hung up on it. As for the issue of definition vs. instance, it may seem logical to use

    Person person = new Person()

    when you consider this in isolation. However, what happens when you need another new Person in the same scope? That’s right, you name the variables differently.

    Cyrus,

    I think the request for adding a similar event declaration mechanism to C# is in reference to the Handles keyword. I don’t have an appropriate C-style syntax (and I’m not suggesting it be added, just tying to clarify the request), but in essense they are asking for

    //maybe could replace handles with : or <- or << or …

    private void button1_Click(object sender, EventHandler e) handles button1.Click

    {



    }

  55. Sjoerd: We’e had the immediate window in 2k3. What are you looking for beyond that?

    Thanks for your thoughts on E&C :-)

    Kevin’s formatting engine should support that case there. But not all cases. If there is something that it screws up then please file a bug with

    msdn.microsoft.com/ProductFeedback

    Have you had a chance to try out 2k5 express?

  56. John: Can you give me an example of where you would like "option strict" turned off?

  57. Ron: Yup. We’ve been asked to do that many times :-)

    We’re just unsure if there is that much benefit into adding that support instead of just having:

    button1.Click += button1_Click

    :-)

  58. Ron: Actually, i just got an email from you and the code looks like:

    private class

    MyClass

    ..{

    …..int i;

    ..}

    With the <dots> replaced with spaces.

    RIght now we dont’ support that. But please go file a bug and we’ll consider it (especially if you can get other people to vote for it!!)

  59. Ron: YOu can also visit Kevin’s page (the formatting code is his) to have a convo with him on this:

    blogs.msdn.com/KevinPilchBisson

  60. Daniel O'Connell says:

    I don’t really like the handles concept, primarily because I dislike the concept of non-dynamic linkup becoming standard and that I don’t think any proper choice is makeable as far as dealing with nulls and avoiding the WithEvents type behavior in VB.

    I also consider it to be a specialization that is primarily used with UI’s, which just isn’t common enough to justify a syntax addition, IMHO. Things that simplify UI’s are *tool* features, not language features. I think its really to confusing to use in other situations.

    Of course, I’ve never liked vb’s event handling, seems to witch doctory to me.

    As for edit and continue, anyone who reads the whidbey newsgroups probably has a pretty good handle on what I think of that, ;).

    If you don’t cyrus, you really should, atleast once in a while.

  61. Daniel: You’re right. I should read those. Can you give me a pointer to them? Thanks!

  62. John Lam says:

    How’s about:

    int i = TextBox1.Text;

    or (for non-generic collections)

    ArrayList al = new ArrayList();

    al.Add(3);

    int i = al[0];

    To me, it’s about avoiding calls to Convert.ToXXX() and casts that do not much more than "shut up the compiler" which is the second case. I will admit that generics will make the need for the second case to go away, but there are still the cases where I want to do stuff like:

    string s = al[0];

    but this is really another example of the first case.

  63. John: Your latter example will work if that type has an implicit conversion to string.

    How would you intend for this code ot owrk now?

    Would it to:

    al[0].ToString()

    Convert.ToString(al[0], someBase).

    al[0].Format(some format provider)

    etc. etc.

    Unnecessary casts will be removed with generics, and what you asking for is possible. But this is not a C# issue, this is a library issue.

    However, when you add implicit conversions many bugs tend to crop up and people (in general) get very very confused. So we force you to handle it instead.

    I don’t know how many times Perl has horked me because it just converts things back and forth from any type and in the end I have no idea what it actually is.

  64. Daniel O'Connell says:

    Cyrus: Instructions are at http://communities.microsoft.com/newsgroups/default.asp?icp=whidbey&amp;slcid=us

    The E&C specific discussion took place in microsoft.private.whidbey.csharp.general under a few different threads. There is a weath of other informatino there as well. Not as much as some groups, but there is some information of note.

  65. John Lam says:

    I agree that this is another example of the evils of implicit type-casting. However, I would make the counter-argument that you need to write unit tests to verify the semantics of your code- surely you don’t just ship because the compiler said you didn’t attempt to do any illegal conversions / casts! Well-written unit tests will allow you to catch these types of bugs in the code – as willl experience.

    The nice thing about not explicitly converting types is that it lets me write code in a lower-friction environment. This seems to be the feeling that lots of folks get when they swtich from statically typed languages like Java/C++/C# towards dynamically typed languages like Python.

    I will admit that I was a member of the statically-typed camp for many years. However, I personally feel that it was largely because all of my friends were statically-typed bigots as well – a danger that I call the perils of self-referential groups. Essentially the entire MS dev community is a giant statically typed community. Lots of VB folks avoid option strict off because of the overall community bias against dynamic typing.

    However, in the non-MS world, lots of folks get lots of software written in dynamically typed languages – and very quickly at that. Witness the success of Perl / Python / PHP.

    I don’t claim to have any real experience in any of those languages, however. But I’m really enjoying the VB.NET option strict off experience. I type what I mean – and most of the time the compiler gives me what I want. In the cases where it isn’t, I either figure it out while I’m typing the code, or my unit test catches it for me.

    Yes, there is a performance cost that is associated with dynamic typing. However, I would much rather write code in a low friction environment first and then isolate the sections that are on the rate-limiting-path through measurement. I can then optimize by statically typing that stuff at that point in time. This gives me the best of both worlds, right?

    However, I realize that dynamic typing is against the "spirit" of C#. But I don’t think it would be all that difficult to implement in the compiler – you just have to call the VB.NET library helper methods :)

  66. JOhnl: I dont’ consider the MS camp to be bigoted. Merely that there have been many dangers involved in loose typing that static typing seem to eliminate completely.

    The attitude is "why test for something the compiler can tell you for free". You say move to unit tests. But then, at that point I say, well, don’t have the compiler do any checking at all. I mean, it can all be done with unit tests :-)

    Point of fact: I like Python. Also, I don’t care about perf issues. If it’s slower, but better, I’m for it. I’m not against dynamic typing. I’m just against the idea of saying "if I have unit tests, then I dont’ need the compiler anymore". Unit tests are written by humans and just add to the amount of surface area where bugs might be introduced. A compiler might have bugs, but usually they will be found and squashed, and everyone benefits. A type-bug that a good compiler could catch could go unnoticed in a system without strong typing even wiht great unit tests.

    The ultimate in flexibility is the C system which basically says "you can do whatever the hell you want. I don’t care, go nuts" And we’ve seen all the problems that have arisen out of that. I’ve dealt with enough crap code coming out of that where the coder thought they could do all these fun unsafe things which of course broke at some point and just had to be ripped out in the end. It’s not fun :-)

    Currently I was dealing with the fact that coder wanted the ultimate in flexibility and so he took over the memory management system and operated on raw streams of bytes, embedding functions and data in it in any way he saw fit. Was this powerful? Yes. In the end, was it a good idea? FOr us, no. Maintainability and understandability were far more important. Strong typeing is a way of ensuring that. If I go and read some Perl I often have to ask myself… "what is that getting converted into. Was taht intentional?". So I se eit being powerful for a developer to quickly get what they want done, but a nightmare for the long term. For what I consider important, I have to go to langauges that will not cause me such grief.

    Note: I love funcitonal langauges, specifically OCaml, where you never have to declare a type for anything, but which retains strong static typing.

    THat’s a system that I would prefer us to move to in the future. You have all the power of a loosely typed system where you don’t have to bother declare something. But you have the benefits where the system will say "nope, sorry, you are dead wrong. Dont’ even both with this because it makes no sense".

  67. Karl says:

    Cyrus, about the intellisense, it isn’t exactly weak, only when compared to vb’s background-compilation-enabled intellisense, would I considering it weak. Anyways, some examples:

    – Enumerations auto-popup which I know has been addressed

    – Type declaration:

    #C – IDE won’t provide any intellisense at all for:

    catch (Exception ex){

    //intellisense only popups when I type "System."

    Vb.Net – IDE is very helpful, intellisense pop’ed after "as’

    catch ex as Excetion

    (I realize the syntax of vb.net in this case, and maybe other cases, makes it a lot easier to popup the intellisense after "as" here.)

    The C# solution would be fine, but I’m already importing the System namespace, and now I have code like this:

    using System;

    public class t{

    public t(){

    Try{}catch(System.Excetion ex){}

    }

    }

    If it’ll force me to type ‘System.’ to get intellisense, it should clean up the code and shorten my qualified reference.

    – Error reporting

    C# – IDE doesn’t report error until compilation

    public class test : ICollection{ } //implementation missing

    You can even do

    public class test : SomethingThatDoesNotExist

    and C# won’t complain ’til compilation.

    Vb.Net – IDE reports error immediately and enters implementation stub when I hit enter (mixed feelings about this last part)

    Public Class Class1 Implements ICollection

    – You can type "int i = string.Empty" and it won’t complain until compilation

    – More Intellisense

    Typing < for an attribute in VB.Net pop’s up intellisense, typing [ in C# does not. If there’s one place i need my intellisense its for attributes :)

    Again, it works if I type "System." first.

    – In vb.net whidbey intellisense is actually smart, typing something like "throw new" will pop up intellisense that’ll list only classes that inherit from System.Exception. I believe this also applies for attributes.

    I guess most of what I’ve come up with this morning is strictly related to background-compilation and how intellisense works (or sometimes doesn’t) in C#.

    I’ll think of more stuff…

  68. John Cavnar-Johnson says:

    Wow. Cyrus says: I dont’ consider the MS camp to be bigoted. Merely that there have been many dangers involved in loose typing that static typing seem to eliminate completely.

    If that’s not evidence of how completely the static typing bias has permeated the Microsoft culture, I don’t know what is. I could easily turn that statement around ( there have been many dangers involved in static typing that loose typing seem to eliminate completely). The point you’re missing is that VB gives you a choice about how strongly typed you need to be to best accomplish the task at hand. I think most developers at Microsoft make the fundamental mistake of assuming that they do the same thing as their developer customers. Most of us aren’t building memory management systems, to use your example. We mostly build software to support business processes and loose typing often (but not always) is the best model for the realities we face. I can pull out numerous examples of situations where code in a staticly typed language is more convoluted, error-prone, and less reliable than using a loosely typed system, but that’s not the point. The point is that VB gives me a choice about how I want to work on a particular project whereas C# has made that decision for me.

  69. Karl says:

    John:

    VB.Net also gives you the choice to use unstructured error handling, Microsoft.VisualBasic.FileOpen, and option explicit off. Just because choices are are offered doesn’t necessarily make them good. In Paul Vick’s VB.Net language reference, there are constant reminders to make sure you develop with option strict on.

    Frankly, when you are shipping products to a client, almost anything you can do to push errors from the runtime to compile time is worth it. Sure you can unit test, but unit tests themselves can have bugs, or holes in them. What else do you gain? Better performance, and most importantly of all is easier maintainability (late-bound code can be very hard to maintain in my opinion).

    Karl

  70. John Cavnar-Johnson says:

    Karl,

    Perhaps I wasn’t clear about the point I’m making. I’m arguing that loose (actually dynamic) typing is sometimes a good thing, therefore having the choice is a good thing. I’m not arguing that unstructured exception handling or FileOpen are good things. I have a lot of respect for Paul Vick, but you just reinforced my point about the bias that permeates Microsoft.

    Frankly, the "shipping products to a client" mindset is part of the problem. Not all code, in fact, not even the majority of code is "shipped" as part of a shrinkwrapped product. I agree with you in regards to shrinkwrapped software. I’m focussing the stuff that’s often called "IT systems" or in-house software. This conversation started with a comment from Fuzu about VB being the best tool for her team. I’m just trying help explain why that’s true and why I don’t think that will change. I’m not even disputing that there are the downsides to dynamic typing that you and Cyrus have talked about (although his arguments about C are really irrelevant to this discussion). I’m pointing out that there are upsides to dynamic typing (especially for particular types of programming tasks) that need to be considered.

  71. John: Fair point. "Bigoted" means to me that i would not ever consider that way, or ever even use it. That is patently not the case. I am "biased" toward safety first though and allowing power afterwards. This has to do with responsibility and resources. We have limited resources here and with them we are trying to provide tools that fit with the TWC ideals. So "safe by default" is extremely important to us. Adding more power later is something we are very open to, just as long as we see it as a good use of resources compared to everything else that people want.

    It is a bias? Yes. Is it an unfounded bias? That depends on your point of view. Because we have evidence of the problems caused by these systems, and because we don’t want to push that burden onto the programmer we made a choice about which to support (since we didn’t have time to do both).

    BTW: which would you prefer. E&C, or non-strict coding? Those are the types of choices that need to be made. Biases and user feedback help us decide which to go with. But it is not because of bigotry.

  72. Karl: Big post:

    "Cyrus, about the intellisense, it isn’t exactly weak, only when compared to vb’s background-compilation-enabled intellisense, would I considering it weak. Anyways, some examples: "

    Bring em on :-)

    "- Enumerations auto-popup which I know has been addressed "

    Yup.

    "- Type declaration:

    #C – IDE won’t provide any intellisense at all for:

    catch (Exception ex){

    //intellisense only popups when I type "System." "

    Fixed. When you type E (or ctrl<space> or ctrl-j) you’ll get a completion list. It will also be filtered down to things that extend from System.Exception

    "Vb.Net – IDE is very helpful, intellisense pop’ed after "as’

    catch ex as Excetion

    (I realize the syntax of vb.net in this case, and maybe other cases, makes it a lot easier to popup the intellisense after "as" here.) "

    Fixed. We pop up after "as" and filter down to non value types

    "- Error reporting

    C# – IDE doesn’t report error until compilation

    public class test : ICollection{ } //implementation missing

    You can even do

    public class test : SomethingThatDoesNotExist

    and C# won’t complain ’til compilation.

    Vb.Net – IDE reports error immediately and enters implementation stub when I hit enter (mixed feelings about this last part)

    Public Class Class1 Implements ICollection "

    Not fixed. Sorry :(

    Would love to have this feature

    "- You can type "int i = string.Empty" and it won’t complain until compilation "

    Not fixed. But I’m working on it :-)

    "- More Intellisense

    Typing < for an attribute in VB.Net pop’s up intellisense, typing [ in C# does not. If there’s one place i need my intellisense its for attributes :) "

    Fixed. Same as exceptions. Nicely filtered to just attribute types.

    "- In vb.net whidbey intellisense is actually smart, typing something like "throw new" will pop up intellisense that’ll list only classes that inherit from System.Exception. I believe this also applies for attributes. "

    Not-fxed. By design. People do write things like: throw new FooBarBaz().SomeStaticException"

    It’s uncommon, but we’re very much against screwing up with legal code.

    We’re actively investigating ways to handle this issue. And I’ve mentioned them in previous blog posts. Things like splitting the completion list into a "common" section where we use heurisitcs (like above) to filter the list down, and an "complete" section where we include everything legal

    "I guess most of what I’ve come up with this morning is strictly related to background-compilation and how intellisense works (or sometimes doesn’t) in C#. "

    Yup. It’s a great feature. I want it :-)

    "I’ll think of more stuff… "

    Excellent!!

  73. JOhn: "there have been many dangers involved in static typing that loose typing seem to eliminate completely": Can you tell me some of the dangers involved in static typing?

  74. Karl says:

    Cyrus:

    I just got home, uninstalled Reshaper and started coding. I immediately noticed some stuff which was a real "ughhh", probably wouldn’t be so bad if I wasn’t so used to it working a certain way. These are probably all tied to the same issues already mentioned, but just incase they are different:

    public class test{

    public test(){

    test2.y;

    }

    }

    public sealed class test2{

    private test2(){}

    public static void x(){}

    }

    so I do a little typo and type "y" instead of "x". As discussed before, don’t see this error before I compile. What bugs me is that after I’ve compiled, the "y" becomes underlined. So I correct it by switching the "y" to "x", but the underline stays.

    I couldn’t believe that the code let me type:

    int x = UndefinedVariable;

    I guess its the same as implementing an undefined interface or inhering from an undefined class. I guess just having used Vb.Net and Reshaper for so long I got lazy and kinda just expected this to be picked up. In my mind, it’s like having Option Explicit off until compile-time. Also like above, if I correct the error, it still stays partly underlined and in my task list.

    Also, something VB.Net doesn’t have, but whidbey will, is the always useful "not all code paths return a value". C# has this 2, but once again, VB.Net whidbey will provide the information at design time as opposed to compile time. I believe in whidbey the "unreachable code detected" will work the same.

    In short, there’s little doubt in my mind that I prefer to have errors pushed from the runtime to compile time. The boost in quality and producitivy is huge. While I don’t think the boost is nearly as high, I believe VB.Net’s ability to push things up to design-time does indeed help in a measurable way.

  75. Karl: You’re preaching to the choir here :-)

    I completely agree. Waiting until an explicit build to figure out things like this is unfortunate and I wish we did better here :(

    Please keep the suggestions coming.

  76. Kavan says:

    Cyrus: Do you think that C# programmers generally want things to pop up at design time? Here’s an article I found some time ago that suggests this is a fundamental difference between a C# and a VB.NET programmer.

    http://www.fawcette.com/vsm/2004_01/online/dias/page8.aspx

    (at the end of the article: PM: How does someone decide between C# and VB?)

    Maybe you’re in the wrong camp :)

  77. Kavan: Very interesting. I would say "yes" but I’m biased. I’m also used to langauges like OCaml and environments for language like smalltalk and java that give you this sort of instantaneous feedback in a subtle way. I.e. they dont’ interfere with coding, they just put gentle reminders to you that there are things you need to do before you’ll be finished.

    They’re especially helpful when you just want to get in to compile and you hate how much time it takes to build->fix 1 error->build->fix one error->build->etc.

    Note: the C# system already tells you this with lexical and parse errors. I think it’s a natural evolution to take that to semantic errors.

    That’s my _personal_ opinion of course!!

  78. Karl says:

    Kavan: I partly agree with you. Some of the pop ups in whidbey (vb.net) are down right intrusive (mostly because of their size). Maybe I’ll get used to it. On the flip side, some of the basic stuff I’ve mentioned doesn’t exactly interfere with your programming. Such as not marking something as an error which has been fixed and telling you that you are using an undefined type via a simple underline (again,you’ll get the underlined one way or another when you compile).

    Just my $0.02

    Cyrus:

    Something else I noticed vb.net and reshapher do that c# doesn’t is provide intellisense for newly added functions. I think you need to compile first. Which isn’t too bad, but what is much worse is, I’m pretty sure if you change a method’s signature, the intellisense will still popup with the old signature. In this case, the intellisense is actually instructing you to write code which won’t compile. not 100% sure on this though.

    Karl

  79. Karl: what do mean "c# doesn’t is provide intellisense for newly added functions"

    :(

    That’s bad :(

    In the past if you added a type/method to another project you’d need to recompile before it was visible in other projects. We’ve removed that restriction in 2005 :-)

  80. Karl says:

    forgot a comma:

    "Something else I noticed vb.net and reshapher do, that c# doesn’t, is provide intellisense for newly added function"

  81. Karl: Can you please explain that…

    Give me a repro case :(

    I want to see this happening so I can make sure it’s no longer a problem.

    Are you still seeing this in C#2005?

  82. John Cavnar-Johnson says:

    Cyrus,

    The danger of static typing is the cost it imposes on the developer. John Lam described it (see above) as friction and I think that’s an appropriate term. Friction slows things down and that’s not always a bad thing. Think about driving a car. You use friction (your brakes) to slow the car. The C# approach is similar to a car that is designed to automatically apply the brakes every time you change direction, based on the degree of change. If you learned to drive a car like that, you would be horrified at the thought of a car that didn’t apply the brakes every time (my gosh, the driver would have to remember to do it on their own without any help from the car). The problem with that system would be that it applies the same amount of friction under all driving conditions. It’s unsafe to drive on snow or ice. If you lived in San Diego, you would have a hard time figuring out why the folks in Omaha and Minneapolis didn’t like that design. Developers at Microsoft pretty much live in San Diego (metaphorically speaking). Static typing rarely imposes an unnecesary burden on them. A lot of your customers live in Omaha or Minneapolis.

  83. Kavan says:

    John: I completely agree with what you’re saying. The idea is not to throw away auto breaking, but to make it optional. Depending on what you’re doing you need different amount of friction. When I’m developing class libraries I always use option strict on. When I get to the highest level of programming, scripting, I turn it off. That’s why users like Fuzu don’t like C#. It’s not suitable for that kind of job. There is always a compromise between development time and long term maintainability. You as developer know the lifetime of the project. If what you’re doing is just a prototype you don’t want all the development speed you can get. And having automatic breaks doesn’t help here.

    In a broader picture I see that C# language is evolving in a way that when feature can be useful but can be misused, it gets discarded. If some developers are stupid it’s better to take it away from everyone. I’m more for the idea that developer should get an option to decide what’s useful to him. There will always be bad developers, you can’t change that. You might say that this was the case with C++. That’s not true, it lacked important features like memory management and many others. Another thing is that sometimes including a feature would have impact on complexity of the whole language. That’s what happened to C++.NET compared to C# and VB.NET. All the clutter of managed extensions gives you just as much friction as explicit casting.

  84. John: I like your analogy. :)

    However, one thing we’ve noticed in Omaha and Mi is the higher rate of speeding and crashes vs. the rest of the country :-)

    Given our lack of time to support what both sides want, we went with safety first. Again, something that most of our customers were asking for.

  85. Kavan: C++ has memory management. C++ even has automatic memory management. C++ even has automatic garbage collection as well :-)

    What other features did it lack?

    You’re absolutely right that each feature you add also adds complexity and friction. This is why we usually won’t add something to the language if there is the equivalent way to do it that is relatively as easy.

    This is something we would be worried about with strict/nonstrict. Would it have to be something you declared in the code? If so, then it adds clutter to the language. If you didn’t have to declare it in the code, but instead set a compiler option, then suddenly when someone comes and looks at that code then they could get very confused when wondering how it is that your code even works.

    A possible option is to extend the unsafe context to embody what you are asking for. So in unsafe contexts you could not initialize variables, or you could not return a result through all code paths even when required, etc. That would sort of follow the meaning of "unsafe". i.e. "i’m going to do things that the compiler can’t verify and I’m going to take responsibility for that myself." It’s something I’ll propose.

  86. Darren Oakey says:

    Cyrus

    This was an interesting question – I used to _LOVE_ VB… In those days I’d be coding mostly in VB with a little C++ backing me up…

    I’ll start with a caveat that EVERYTHING I liked about VB was destroyed with VB.Net – I wouldn’t touch it with a barge pole – C# is just… better.

    However – everything I miss about VB comes down to two concepts – boundaries and readability.

    boundaries: I think people always lose sight of the fact that more boundaries = faster development. Sure, sometimes there were things you had to "work around" – but when it came down to it, if there is just "one way" to do something – then that’s how you do it. Look at the C++ world, where it’s quite common to have developers go off on just a complete tangent to produce a"beatiful" template structure, when an ugly hack would have done the job fine.. People have to realise – increased "Flexibility" ALMOST ALWAYS _decreases_ productivity (but of course might have other good effects – increased quality/ robustness/ elegance/ maintainability or something).

    readability: to me, as I always say, code readability is the single most important constraint when coding. Nothing else comes even close. And I define code readability as "how long would it take someone who has never seen a computer before to understand this function" – I do NOT accept the argument that code should be written to be clear to an expert in the language – I want code to be just written _clearly_ – not "clearly if you understand all of this to begin with".

    So – specifically, what I miss about VB? (in order)

    — compilation speed —

    I used the compiler as a task list – I’d write a test and make stubs with garbage like "asdfasdfjash" – hit f5, start coding out what I’m doing, get halfway through a line, realise I need a helper function, go code that, maybe repeated two or three levels down – hit f5, continue from where I was at, hit f5 fill in something else as well. It told me what I was doing, where I was up to, and that what I’ve done so far was ok. I still code like that, but just FAR FAR more slowly.

    — my error handling libraries —

    My roll-your-own exception handler library gave me the values of the parameters in a function. Because I think and program largely functionally, this meant that in the case of an error, I basically had the entire relevant state of the system sitting in front of me – debugging was rarely necessary – even production bugs were trivial to track down and fix, because you didn’t first have to reproduce the problem.

    — binary compatibility —

    you could actually safely give out code libraries, and have reasonable confidence that you aren’t going to break anything when you give out the next version of your library.

    — predictable garbage collection —

    I liked the VB garbage collector and hate the .NET one. I know how I code. I NEVER EVER have a bidirectional link between two classes, (except through the observer pattern) – so a reference counted solution suits me fine. I am quite comfortable I’ll never code a memory leak… However, I do like the fact that things go away at predictable times.

    I know dispose exists (and I use it heavily, I can tell you) – but I would just like EVERY class to "require" a dispose, and dispose to automatically be called when they go out of scope :)

    We have had so many GC related errors. Lots to do with forgetting disposes of course when people did things like open connections, but we’ve stamped a lot of them out – but more because the GC isn’t even vaguely as active as I’d like it to be – .NET programs are memory pigs. For instance, we had a problem with our build server where we noticed it was slowing down all day – a build in the morning was 20 minutes, but by the evening it was up to 1 hr. We narrowed the problem down to the web tests. I put the words GC.Collect() – GC.WaitForFinalizers() into the load of the master page – the initial build went up to about 21minutes, and NEVER slowed down again…

    — no brackets on subs or empty functions —

    I liked seeing code like:

    > foreach employeeToNotify in theListOfLateEmployees

    > NotifyThe employeeToNotify

    — only interface inheritance —

    generally, I think inheritance is the single most badly used, over used, least understood concept in programming. I LOVED the fact that VB gave you all the benefits of inheritance with none of the disadvantages, by forcing you to always to an interface based inheritance

    — english operators and/or vs & | —

    > if theEmployee.IsValid andAlso theEmployee.HasBeenChanged then Save theEmployee

    is so much more readable than

    > if (theEmployee.IsValid() && theEmployee.HasBeenChanged()) Save( theEmployee);

    one looks like code, the other looks like english…

    — no visible plumbing —

    with vb, if you dropped a control on a form – you didn’t see the control definition, you didn’t see code setting it up, you couldn’t break it, you couldn’t meddle with it. increased robustness + increased readability – good stuff

    — "with" —

    while I would _never_ nest a with block, I thought with was a very elegant syntax – especially for doing things like populating a set of controls from an object, or vice versa

    > with theEmployeeToDisplay

    > NameDisplay.Text = .Name;

    > PhoneDisplay.Text = .Phone;

    > BirthDateDisplay.Date = .Birthdate;

    > end with

    — case insensitivity —

    (although I wouldn’t change it about c# – they are different languages)

    – but I used to USE case insensitivity as a tool – I would ALWAYS type in an INVALID case – when I moved to the next symbol I always knew if I’d got stuff right, because the symbol would change – sounds silly, but it improved my productivity.

    (note – I’ve ignored all the common ones, like e&c – because you all know them already)

    Mind you – I’m not coding in VB, so I can’t miss’m all that much :)

  87. Best says:

    Interesting info