The Demise of C#

[Kevin Spencer]

I tend to see it as a difference between VB6 and .net, rather than VB6 and

C#. The reason, is that even by using VB.Net, I would have locked myself
out
from all the "unproper" features, such as Option Explicit Off, Option
Strict
Off etc etc...

This part I don't understand. By default Option Explicit is turned ON in
VB.Net, and it's a simple matter to turn Option Strict ON as well...

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[Guest]

You can use unmanaged code and pointers in VB.NET. I've used the dllImport
attribute to make calls to functions in DLLs like User32 and the like, and
there's the AddressOf operator for creating pointers to functions and such...
I think there is something C# can do that VB.NET can't, but I can't remember
what it is. I do know that C# doesn't have ParamArrays while VB.NET does,
but that's just indicitive of the main reason to choose one .NET language
over the other: personal preference.

- Dave

 

[Guest]

Yes it would seem they have!

 

[Kevin Spencer]

The AddressOf operator is not for creating pointers. It is for creating
procedure delegates. You can't use pointers in .Net without unsafe code.
VB.Net does not allow unsafe code.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[Guest]

Even in VB6 i was able to emulate using pointers when i had to, you just
have to think a bit harder.

using a byte array as a stream and an index as the pointer with a couple of
funtions to return the position of objects in the stream you can emulate
pointers, although you do end up having to use some non approved
functionality to bypass safe types.

I had to use VB6 although i wanted to use C++. I needed to return some
performance data for message queues from the registry. it was maybe not quite
as fast as pointers but it was pretty close.

 

[Kevin Spencer]

Well, now, Alan, that's pretty clever. Still, it's the hard way around. I
commend you for your creativity!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[Guest]

Thank you for your commendation.

This does prove Rob's point though that you can use almost any language you
like to do whatever you want without a severe drop in performance.

Each language may have strengths and weaknesses but they can be worked
around and I am sure even your project with the images could be done in
VB.Net without costing an order of magnitude in processing if some thought
was put into it.

I have been using C# almost since its first beta, it was chosen by the dev
team who were mostly all VB6 programmers in a vote, the main reason given was
that they (me included) thought it would look better on CV than VB.Net, I had
done C and C++ City and Guilds when i was trying to become a programmer but
only had practical commercial experience of VB6, the transition was fairly
easy for me but some had problems and didnt fully understand objects properly
even though VB6 does support OOP to a certain extent.

I would reiterate the comment lots of people have made, its the programmer
who makes the difference not the language.

But on my CV I wanted C# as I believed it would look better to employers.

 

[Kevin Spencer]

Well now, Alan, don't push your luck! ;-)

I would prefer not to get into details, but what you described, while
emulating a pointer to a small degree, is far from actually USING pointers.

I will simply reiterate: There are times when unmanaged code is absolutely
necessary. Thankfully, they are not often. Still, I prefer to have that
option when I need it, which is apparently a good bit more often than the
average.

A good mechanic has a machine shop. While a good mechanic would generally
prefer to buy pre-built parts, there is the occasion when the mechanic must
use the machine shop to build a custom part. A not-so-good mechanic has no
machine shop, and has no knowledge of how to use one. Therefore, he has to
pay someone to build his custom parts. And if the custom part doesn't work
as advertised, the not-so-good mechanic can't fix it, and has no recourse
but to replace it with another custom part from some other mechanic.

You think the CLR was written in entirely managed code? Think again. After
all, if unmanaged code was never necessary, Microsoft could have saved a
good bit of money that was spent allowing for it.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[Guest]

I am a Basic developer turned VB Developer turned VBscript / ASP developer
and now because my company wants a homogeneous code base I have turned C#
developer. I have been developing web sites since before the Web when they
were just text based sites over the ARPanet that ran in browsers such as
Archie and Veronica. To make a long story short now that I am developing in a
true OO environment utilizing a language like C# I will never turn back, not
because it is harder but because it is actually easier in many ways. People
always talk about C and C++ programmers like they are on the top of the food
chain as far as programming. As web developers we have to be proficient in a
number of languages. If we came to work everyday and wrote the same code with
the same syntax hell we'd be really good at it too. As it stands I think
anyone who makes the switch from VB to C# will experience exactly what I am
experiencing. Once over the learning curve it is in my opinion much easier to
code in.

And by the way I was at a VS.Net usergroup meeting sponsored by a local head
hunter last week. There were a number of companies represented all looking
for ASP.net with C# and not one for ASP.net VB. Someone in the crowd asked if
they were seeing any employers asking for VB.net and the answer was an
emphatic no. So wether or not VB is good to bet your career on is up to you,
as for me maybe corporations are a bit misled but it is the common perception
that C# is better than VB and you know what they say, perception is reality.

 

[Guest]

Hi Kevin,

I am not exactly sure of your meaning with the mechanic analogy, it sounds
as though you mean a good programmer would always use the appropriate
language but the choice of language is not always up to the programmer.

I accept that sometimes unmanaged code is needed, but when performance is
vital surley it would be better to use something like C++ to write the
unmanaged code as it is faster than C#, and if you did then VB.Net or C#
would be able to use the unmanaged code.

 

[Guest]

Hey Kevin,
I agree with you for the most part. Most C# programmers I know are .NET
lovers who just use a different syntax than programmers using VB.NET. Few are
better off using C#, except that they're forced to explicitly cast objects
and perform dynamic binding and the sort.

I think that when it comes to design capabilities, the one with C++
experience is going to do better, as someone who appreciates the STL is far
more likely to understand how to develop efficient, robust, flexible code
than someone who thinks the collection classes and the enumeration methods of
the .NET classes are the best thing there is.

 

[Guest]

On a further note, I know many C# and VB.NET programmers, and many are very
good at getting a small-scale application job done. However, most of these
guys don't know the first thing about efficient design. They don't even
separate the logic processing from the GUI code, and rarely design new
classes or functions that aren't already required by the form designer.

 

[Guest]

Also, with regard to .NET in general with its various languages, I think the
language variety really isn't the big thing it's hyped up to be, as people
have mentioned here. The languages are practically the same save for some
minor syntactic differences and some variations in what's allowed (implicit
dynamic binding in VB.NET as well as global functions).

To me, I like having both VB.NET and C#. I prefer VB.NET when I'm lazy, and
the globals are nice for small-scale GUI applications as opposed to just
emulating globals through a class with static (shared) members. C# is nicer
for larger scale applications as it has a lot more safety checks in place.

Still, those two should be it. It requires Microsoft to put a lot of extra
effort to create documentation for both VB.NET and C# and Managed C++ and J#.
They should at least cut out the documentation for a couple of these, as they
are all basically the same thing, and the learning curve doesn't vary much
(even with VB.NET, you still have to learn about classes, inheritance,
polymorphism, static binding, dynamic binding, and probably template-like
generics in the upcoming version, as well as all the .NET concepts - it's
really not any easier than C# save for some really minor syntactic
simplicities and slightly looser rules).

 

[Guest]

I wish I could edit posts, as I keep thinking of new things to say.

With experienced C++ programmers not being as suited for specific .NET tasks
like developing with ASP, I think a lot of that has to do with the fact that
most C++ programmers have a history of working with platform independence. To
become fluent in .NET, you really need to become intimate with the .NET
platform, and a lot of these programmers don't like being restricted to a
single platform, especially when working with such a high-level,
heavily-layered architecture where the underlying system isn't even
recognizable, especially when you consider the rather bulky and limited
design of the .NET framework library.

 

[Kevin Spencer]

I accept that sometimes unmanaged code is needed, but when performance is

vital surley it would be better to use something like C++ to write the
unmanaged code as it is faster than C#, and if you did then VB.Net or C#
would be able to use the unmanaged code.

What I'm referring to is unsafe code blocks, which you don't code in C#. You
write it in C/C++, INSIDE a C# app.
--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[Kevin Spencer]

And by the way I was at a VS.Net usergroup meeting sponsored by a local

head
hunter last week. There were a number of companies represented all looking
for ASP.net with C# and not one for ASP.net VB. Someone in the crowd asked
if
they were seeing any employers asking for VB.net and the answer was an
emphatic no.

I think I'd steer clear of THAT group of employers. Sounds like a bunch of
monkey-see-monkee-do Dilberts.

But your point is well-taken!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[Guest]

I think I'd steer clear of THAT group of employers. Sounds like a bunch of

monkey-see-monkee-do Dilberts

Kevin, aren't all employers?
This is representative of the Denver IS employment market. I don't think I
have met a management team yet in my 10 + years as a programmer that I
haven't thought were total morons when it comes to technology. Until more
tech types decide to take the management track I think this cravass between
the knowledgeable and the ignorant will only grow. It is unfortunate but it
is the reality.

I think the big picture here is that the .Net runtime is supporting many
languages and hopefully we will see a sparkle again in the eyes of Cobol,
Delphi, VB, and other languages the runtime supports as the powers that be
come to realize that they all have their place.

 

[Kevin Spencer]

Kevin, aren't all employers?

No. For example, mine is certainly not. Which is why I continue to work for
my employer for less salary than I could make elsewhere. I love the type of
work that my company does (mostly R&D for Government SBIRs), and they let me
run my team the way I know I should. We are respected, and truly have the
ear of our employer. Our CEO listens when I give advice, and our CTO is a
geek like us.

I realize that is rare. But it does exist!

If you don't believe that something exists, you will never seek it, and
very likely never find it. Unfortunately, many people don't realize that
"What you seek is what you get" as Uncle Chutney would put it, and tend to
think the whole world is like most of the world.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[Guest]

Hmmm, having myself been a programmer for more years than I care to admit.
Fashions come and go for what passes as the programming paridigm de jour.

Problem is its going to change so radically in the future, your best off
going back to school again.

Micosoft's Avalon is the new graphics architecture for WIndows. Having used
POV-RAY for eons, I saw many familiar concepts about models, textures etc.
The user interfact uses the idea of a camera looking at something, so code is
going to need to be developed with this in mind.

So when hiring talent, sometimes skills in unrelated areas of research can
quickly become mainstream as the rest of the world catches up.

So when your want to port your product to Longhorn, these VB and C# skills
look kinda useless to me.

Worse, the world is going parallel and most programing languages are
sequential, so back to school.

 

[Guest]

I personally think there are some really great things in VB.NET and it's a
real crime how C# doesn't implement them. If you ask me, VB.NET is a better
language for the rapid-application development needs of most .NET developers.
I still code in C# over VB most of the time, but there are many things I envy
in VB that I find lacking in C#.

For instance, take the string concatenation operator from VB, &, which
automatically converts the left and right operands to strings and returns a
combined string. Why is there no equivalent in C#? Sure the '&' character
would conflict with the bitwise and, but there are plenty of other symbols
(ex - Lua's '..') that could be used in place, and it's absolutely silly that
someone has to write:

some_string_output_function("Blah blah: " + x.ToString() + ", " +
y.Totring() + " blah blah " + z.ToString + ", " q.ToString() );

when they could have simply wrote something like:

some_string_output_function("Blah blah: " .. x .. ", " .. y .. " blah blah "
... z .. ", " .. q);

There's nothing implicit going on here; the operator has clearly-defined
behavior. It makes little sense to me why C# does not have things like this
that would do nothing but make the code a little more readable and convenient
to write.

I can understand many of the reasons for C#'s more explicit nature like
requiring explicit casts (safety) and explicitly indicating where you want to
use dynamic binding (performance), but it's silly to deprive a language of
something useful just because it isn't characteristic of the language from
which it was modeled.