C# versus VB.Net

[allfyre]

Fair enough, I was just trying to list some of the differences between
VB.NET and C#. As I've said for all practical purposes the two
languages are the same so my preference for C# really just comes down
to me preferring the C# syntax.

 

[allfyre]

By the same token though, if you're using option strict in your VB code
(I think you'd be surprised how many developers choose option sloppy)
then you really wouldn't be writing any extra code in C# to handle the
all the casting.

 

[Tom Spink]

I've worked extensively with both languages and functionally it doesn't
make a lick of difference one way or the other. C# has a few features
that you don't get in VB, mainly pertaining to the use of pointers and
"unmanaged" code which more or less manipulates memory directly.
You're probably not going to need to do it anyway.

Don't worry about the sale to management, they don't care what you use
one way or the other as long as they can get everything in
Excel/PowerPoint at the end of the day.

What you should do is discuss it with your team, discuss the merits and
pitfalls of working with either language and decide what you want to
use and tell management that you want to make the move to this language
or that because it's what your developers want to be working in.

As far as learning a new language goes, the important thing (and the
difficult thing) is learning the .NET framework and how to leverage it.
The languages themselves are easy. I think that VB.NET is more
different from VB6 than it is from C#. VB.NET even supports all the
same C/C++ operators now.

Also, there is no reason why you can't work in both languages as they
are completely interoperable. If you're working with VB.NET currently,
you could try a few small projects in C# and see how you like it. It
does take some getting used to coming from a VB background but
personally I prefer the C# syntax because it lets me write more concise
code, and because I like curly braces.

I've also worked on projects where both languages were employed. For
example a project where the ASP.NET page classes were written in VB.NET
and the middle tier and data access layers were done in C#.

Hi allfyre,

It's unsafe code that's available in C#, not unmanaged.

 

[Tom Spink]

So who exactly is going to find it perfectly logical and intuitive that
if you appear to call Sleep on a specific thread, you actually make a
completely different thread (the current one) sleep? What is the
*possible* benefit in that?

Some things are indeed subjective, but we really shouldn't let that be
a catch-all excuse for things which just shouldn't be the way they are.

Hi Jon,

What is the *possible* benefit in that?

Absolutely none.

 

[allfyre]

I prefer "Unmanaged" but feel free to call it whatever you like. I
think "unmanaged" or "partially managed" code is a more accurate term
than "unsafe."

 

[allfyre]

Better yet, how about "managementally challenged" code?

 

[Scott M.]

Unmanaged and unsafe mean completely different things. It's not a matter of
preference. They are accepted terms that have definate and different
meanings.

Unmanaged code is code that is not run within the context of the CLR.
Unsafe refers to code that does not enforce type casting until runtime.

 

[Tom Spink]

I prefer "Unmanaged" but feel free to call it whatever you like. I
think "unmanaged" or "partially managed" code is a more accurate term
than "unsafe."

Hi allfyre,

Unfortunately, the two are actually different concepts, calling one the
other would be incorrect.

Unsafe code is code that is called within managed code (i.e. code executed
by the CLI) that manipulates memory directly, e.g. using pointers.
Unmanaged code is native code that is not JIT compiled by the CLI. It's
code that can be natively executed, on the CPU.

 

[allfyre]

I see your point, however:

What the CLI "manages" is the memory required to sustain objects in
your application, no? By using the "unsafe" keyword, you are
essentially bypassing the management infrastructure therefore provided.
I don't like calling it "unsafe" because it's not, unless you make it
so. Perhaps "unmanaged" would have been a better keyword.

On the occasions where my team and I have to resort to this kind of
barbarity, we generally refer to the situation as "performing an
unmanaged operation," as in "This passes control to the Transform()
function which performs a few unmanaged operations."

We do this since the "Wayne Incident," whereby a mid-level manager
stumbled in on an IT meeting while we were discussing such a solution.
He heard the words "unsafe code" and "production servers" and his
little manager ears perked up and he stuck his head in and started
wanting to know what we were talking about.

We tried for a while to explain, but it just wasn't working so we had
to just throw letters and numbers at him for a few minutes until his
eyes finally glazed over, sending him into a blissful, managerial
trance that made him forget everything he heard and leave the room
smiling, confident that he was complete in control of the situation.

 

[Tom Spink]

I see your point, however:

What the CLI "manages" is the memory required to sustain objects in
your application, no? By using the "unsafe" keyword, you are
essentially bypassing the management infrastructure therefore provided.
I don't like calling it "unsafe" because it's not, unless you make it
so. Perhaps "unmanaged" would have been a better keyword.

On the occasions where my team and I have to resort to this kind of
barbarity, we generally refer to the situation as "performing an
unmanaged operation," as in "This passes control to the Transform()
function which performs a few unmanaged operations."

We do this since the "Wayne Incident," whereby a mid-level manager
stumbled in on an IT meeting while we were discussing such a solution.
He heard the words "unsafe code" and "production servers" and his
little manager ears perked up and he stuck his head in and started
wanting to know what we were talking about.

We tried for a while to explain, but it just wasn't working so we had
to just throw letters and numbers at him for a few minutes until his
eyes finally glazed over, sending him into a blissful, managerial
trance that made him forget everything he heard and leave the room
smiling, confident that he was complete in control of the situation.

Hi allfyre,

I don't like calling it "unsafe" because it's not, unless you make it
so .

But it /is/. Even if you code defensively, your code is unsafe. That is,
it's not protected by the runtime.

Performing an unmanaged operation could be viewed as calling some interop.
routine, like a 'public extern void Foo();', implemented in an /unmanaged/
DLL, like 'user32.dll'.