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

Article
06/30/2004

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

Anonymous
June 29, 2004
The comment has been removed
Anonymous
June 29, 2004
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?
Anonymous
June 29, 2004
The comment has been removed
Anonymous
June 29, 2004
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).
Anonymous
June 29, 2004
Adam: can VB reference executables?

You can switch of "func-eval" in the watch window through the debugger options.
Anonymous
June 29, 2004
The comment has been removed
Anonymous
June 29, 2004
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...
Anonymous
June 29, 2004
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!
Anonymous
June 29, 2004
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!
Anonymous
June 29, 2004
The comment has been removed
Anonymous
June 29, 2004
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.
Anonymous
June 29, 2004
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
Anonymous
June 29, 2004
The comment has been removed
Anonymous
June 29, 2004
The comment has been removed
Anonymous
June 29, 2004
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.
Anonymous
June 30, 2004
The comment has been removed
Anonymous
June 30, 2004
The comment has been removed
Anonymous
June 30, 2004
The comment has been removed
Anonymous
June 30, 2004
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.
Anonymous
June 30, 2004
The comment has been removed
Anonymous
June 30, 2004
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.
Anonymous
June 30, 2004
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).
Anonymous
June 30, 2004
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.
Anonymous
June 30, 2004
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!
Anonymous
June 30, 2004
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.
Anonymous
June 30, 2004
The comment has been removed
Anonymous
June 30, 2004
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.
Anonymous
June 30, 2004
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.
Anonymous
June 30, 2004
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!
Anonymous
June 30, 2004
The comment has been removed
Anonymous
June 30, 2004
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.
Anonymous
June 30, 2004
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.
Anonymous
June 30, 2004
The comment has been removed
Anonymous
June 30, 2004
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.
Anonymous
June 30, 2004
Duncan: Yup. I'm working on something like that. Can't give you any promises though :(
Anonymous
June 30, 2004
Cyrus: Forget about reshaper -- it's a refactoring add-in for VS2003.
Anonymous
June 30, 2004
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
Anonymous
June 30, 2004
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?)
Anonymous
June 30, 2004
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.
Anonymous
June 30, 2004
Dave: Could you clarify that? Why is requiring a break in a switch silly? :-)
Anonymous
June 30, 2004
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 :-P ).

As for naming, if you knuckleheads just move the '2005' it makes a lot more sense: "Visual Studio 2005 Tools for Office"
Anonymous
June 30, 2004
Fuzu: Genius!! You should be in marketting!
Anonymous
June 30, 2004
The comment has been removed
Anonymous
June 30, 2004
The comment has been removed
Anonymous
June 30, 2004
The comment has been removed
Anonymous
June 30, 2004
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?
Anonymous
June 30, 2004
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/
Anonymous
June 30, 2004
The comment has been removed
Anonymous
June 30, 2004
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.
Anonymous
June 30, 2004
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.
Anonymous
June 30, 2004
Luc: Ok. Fair enough :-)
Anonymous
June 30, 2004
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.
Anonymous
July 01, 2004
The comment has been removed
Anonymous
July 01, 2004
The comment has been removed
Anonymous
July 01, 2004
The comment has been removed
Anonymous
July 01, 2004
John: Can you give me an example of where you would like "option strict" turned off?
Anonymous
July 01, 2004
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

:-)
Anonymous
July 01, 2004
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!!)
Anonymous
July 01, 2004
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
Anonymous
July 01, 2004
The comment has been removed
Anonymous
July 01, 2004
Daniel: You're right. I should read those. Can you give me a pointer to them? Thanks!
Anonymous
July 01, 2004
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.
Anonymous
July 01, 2004
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.
Anonymous
July 01, 2004
Cyrus: Instructions are at http://communities.microsoft.com/newsgroups/default.asp?icp=whidbey&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.
Anonymous
July 01, 2004
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 :)
Anonymous
July 01, 2004
The comment has been removed
Anonymous
July 01, 2004
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...
Anonymous
July 01, 2004
The comment has been removed
Anonymous
July 02, 2004
The comment has been removed
Anonymous
July 02, 2004
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.
Anonymous
July 02, 2004
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.
Anonymous
July 02, 2004
The comment has been removed
Anonymous
July 02, 2004
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?
Anonymous
July 02, 2004
The comment has been removed
Anonymous
July 02, 2004
The comment has been removed
Anonymous
July 02, 2004
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 :)
Anonymous
July 02, 2004
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!!
Anonymous
July 02, 2004
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
Anonymous
July 02, 2004
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 :-)
Anonymous
July 02, 2004
forgot a comma:

"Something else I noticed vb.net and reshapher do, that c# doesn't, is provide intellisense for newly added function"
Anonymous
July 02, 2004
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?
Anonymous
July 02, 2004
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.
Anonymous
July 03, 2004
The comment has been removed
Anonymous
July 03, 2004
The comment has been removed
Anonymous
July 03, 2004
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.
Anonymous
July 07, 2004
The comment has been removed
Anonymous
September 02, 2005
Interesting info
Anonymous
January 25, 2008
PingBack from http://websitescripts.247blogging.info/cyrus-blather-go-away-or-i-shall-taunt-you-a-second-time/
Anonymous
May 29, 2009
PingBack from http://paidsurveyshub.info/story.php?title=cyrus-blather-go-away-or-i-shall-taunt-you-a-second-time
Anonymous
June 16, 2009
PingBack from http://lowcostcarinsurances.info/story.php?id=6933
Anonymous
June 18, 2009
PingBack from http://firepitidea.info/story.php?id=13

Partager via

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

Comments

Ressources supplémentaires