R
Rory Becker
Hello Tom,
Absolutely. I'm also aware that there are command line tools to allow me
to use GIT(Source Control) aswell as SVN.
However the jump from SVN to GIT is considerably harder given that most of
my shop uses TortoiseSVN. once TortoiseGIT becomes available I will see it
as a reasonable alternative. I have to wait because I cannot afford the time
to spend training me and the rest of my team on a concept that is so far
from what they are already used to. Especially with everything else there
is to process.
Likewise Notepad and csc.exe or vbc.exe can be used but let's be fair, >
90% of us are using Studio.
I'm sure that's the case for you, but the languages will always be uneven.
For example (IMHO):
VB.Net could really deal with a Yield Keyword.
C# could really deal with inline XML Support.
Is MS really suggesting that I should have to choose ahead of time which
of these I should choose to make available to myself?
They are each concepts which force me to make a choice. I just feel that
I should not have to make that choice.
Even if each language should develop the feature that the other one is currently
missing in the next version then there will be something else missing.
I would have nothing against this if I were able to mix languages inside
a given project.
I'm not asking for multi-language files, just the ability to add .vb files
and .cs files to the same project would be fine. Ok yes I would love to be
able to have different language partial classes, but I could go without those
if I had the basic version.
Any sensible .Net programmer will recognise that there are relatively few
differences between C# and VB.Net to make understanding one when you know
the other fairly trivial. So why not include this as an optional possibility.
You have stated that you don't think there is demand enough, and on this
I agree. I do however find it unfortunate.
I am curious why though, it has been possible in many languages in the past,
to write inline assembler.
Why was this feature deemed worth and my suggestion, not so?
I would argue that both VB.Net and C# are, shall we say, a tad more popular
than assembler ever was?
If my idea was implemented you wouldn't have to wait for C# 4 VS10 (I'm guessing
mid 2009 at best)
Again this may be true, but it doesn't mean it's a bad idea.
I'm sure you know, it is technically possible to create multi-language
assemblies - there just is no support in the ide. You have to compile
from the command line to accomplish it.
Absolutely. I'm also aware that there are command line tools to allow me
to use GIT(Source Control) aswell as SVN.
However the jump from SVN to GIT is considerably harder given that most of
my shop uses TortoiseSVN. once TortoiseGIT becomes available I will see it
as a reasonable alternative. I have to wait because I cannot afford the time
to spend training me and the rest of my team on a concept that is so far
from what they are already used to. Especially with everything else there
is to process.
Likewise Notepad and csc.exe or vbc.exe can be used but let's be fair, >
90% of us are using Studio.
The problem is that, I just don't really see the point of it. There
have been precious few times when I have wanted to mix languages, and
solution level support was more then adequate.
I'm sure that's the case for you, but the languages will always be uneven.
For example (IMHO):
VB.Net could really deal with a Yield Keyword.
C# could really deal with inline XML Support.
Is MS really suggesting that I should have to choose ahead of time which
of these I should choose to make available to myself?
They are each concepts which force me to make a choice. I just feel that
I should not have to make that choice.
Even if each language should develop the feature that the other one is currently
missing in the next version then there will be something else missing.
I would have nothing against this if I were able to mix languages inside
a given project.
I'm not asking for multi-language files, just the ability to add .vb files
and .cs files to the same project would be fine. Ok yes I would love to be
able to have different language partial classes, but I could go without those
if I had the basic version.
Any sensible .Net programmer will recognise that there are relatively few
differences between C# and VB.Net to make understanding one when you know
the other fairly trivial. So why not include this as an optional possibility.
You have stated that you don't think there is demand enough, and on this
I agree. I do however find it unfortunate.
I am curious why though, it has been possible in many languages in the past,
to write inline assembler.
Why was this feature deemed worth and my suggestion, not so?
I would argue that both VB.Net and C# are, shall we say, a tad more popular
than assembler ever was?
The only time, that I
can really think of is using VB.NET for office automation, simply
because it is much easier and cleaner to use VB.NET for late-bound
scenarios - though, it looks as if that might change in C# v4.
If my idea was implemented you wouldn't have to wait for C# 4 VS10 (I'm guessing
mid 2009 at best)
I just don't see this as a feature that many developers will be
clamoring for.
Again this may be true, but it doesn't mean it's a bad idea.