So what happens at runtime if theDataTable("Column") is integer? It bombs
presumably?

Yep, we had that in FoxPro and I hated it....except it was ; rather than _.

LOL

I would have done much better in Swedish. English is not my first language.
Now go away Troll. There is no food here! Or do you have an opinion youself?

- Michael S

<snip>

Better than no generics. You might also want to look into Java's enums
before thinking that C# is better in all respects... when using C# I
long for rich, OO enums like Java has.

(I also long for an IDE which matches Eclipse, but that's another
matter...)

I'll give you some more 'ammo' for your meeting:

1. Strict Option Off
You are allowed to turn explicit casting off. This was done to make porting
of VB6 code easier. Also why they gave the language AndAlso and OrElse. The
whole syntax is created for easy-porting-purposes. The problem is that
porting Object-Based code into Object-Oriented code is a dumb idea from the
start. Who would 'port' JavaScript into C++? You don't port stuff like that.
You re-write the code and only port (re-use) the idea and feature, not the
design.

C# was not designed for porting, but to be a clever language. I think it is.

2. No-mans land.
At my work we mostly do Java, C#, C++ and Delphi (which is not really a
no-mans land, as most Delphites knows C++ ).

I say mostly - as sometimes our customers wants and insists on VB.NET. And,
like the dirty whores we are, we are happy to supply such a perverted
service. We hide behind the old - The Customer Is Always Right, as not to
offend whores. =)

However, for projects written in C#, we can always call on a Java or C++
developer to help us out if we are out of girl-power. While having a Javait
in your code, not coding a property Count, but insists on writing a
getCount() method, things are not that bad. Atleast the code is dandy and
written in a good pace. And while it may take her some time before she
fathoms that why she can't seem to find a StringBuffer anywhere, not even in
System.Text, is that it is called StringBuilder in .NET. She might grunt a
bit and may need some help, but she gets the job done.

If the same girl was to venture into a VB.NET project she would be doomed.
How would she know that she can't use And but must use AndAlso to get her
if-statements to work. How would you tell her that there are no braces and
that 'for' meets 'next', 'if' meets a 'end if', while 'while' meets a
'wend'.

Actually, I've seen this happen. But it was a guy and not a girl. And he got
so mad he almost screamed at me in frustration - Get me out of this NOW, or
I'll RESIGN!

3. Visual Basic Sucks So Hard It Bends Light.
This is my E=mc^2 argument. I think VB.NET is a gravity-well. Not really a
black-hole as time doesn't really stop, but it slows down a bit, and as time
== money, it earns you less money. While I don't care so much about money, I
rather see it as doing more work for less result.

While a VBers (or Delphites, like myself) may always claim, - 'I write so
fast in my favourite language, you won't know the difference'; both basic
and pascal are verbose languages and you could go faster. Once you talk
Algol-style languages like C#, C++ and Java fluently, you are quite fast in
doing JavaScript for a browser also.

4. Cognition
Our brains are wired to grasp the world in the following order; type,
identity and value.
For the science of this, please use google. I've written several posts on
this here, so you could always google groups for my long (and quite funny)
example.

Anyways, here is a short example;

int i = 5; //type first, identity second and value last.

Dim i as Long 'Dim is useless, identity comes before type. What is it's
value?
i = 5 'Value is not in context with type or identity.

While few studies have been done and nothing proven (how do you prove this?)
our brains tend to work harder when we code basic and pascal, and spend less
energy when doing the algol-style coding our brains like. Wirth did it wrong
when he designed pascal, while Ritchie just happened to get it right. I
don't think any of them even gave it a thought.

Well, there you have another four reasons for staying away from VB.NET.

Happy Coding
- Michael S

Hi,

Does anybody knows what  DLinq in VB.NET looks like?
The syntax  in C# is abstract, so who knows what the VB guys will invent to
express it :)

Possibly. However, I disagree with your assertion (if I understand it
correctly) that C# 3.0 will be the same as VB 9.0. Having converged
somewhat, the languages are likely to *diverge* significantly in the
next release or two.

I don't know. Do you?

Not at all. I just want to have a stab at VB whenever I can.
You must have seen that I'm not really worried of this.

I didn't know that.

But a funny thing is that I've seen a vb.net-coder, forced to do C#,
reference that namespace the first thing he did. But he's not the brightest
human in the world either, and makes for a poor example.

I think most people in this thread are very good at what they do, regardless
of language. What I'm trying to say is that *most* C# developers are more
interested in 'How It Actually Works', while *most* VB.NETers don't as much.

To turn the question on it's knees:

If you was forced to hire (and keep) 10 coders for a looong .NET-project
(management told you so), and you have 20 candidates fluent in VB.NET and
another 20 fluent in C#. But you are only allowed to intreview 12 of them.
Who would you call?

Did I make my point?
- Michael S

Not quite: *public* class and member names cannot differ only by case.

For instance:

using System;

[assembly:CLSCompliant(true)]

public class Test
{
   public static void Main()
   {
   }
   
   static void main()
   {
   }
}

compiles fine. Make main() public and you'll get a compiler warning.

<snip>