Is linq the final straw for VB?

[Michel Posseth [MCP]]

Cor ,

Indeed i was already thinking about an analogy for Spanish and German but as
from my point of view German is a much more strict language as Spanish
i was afraid that someone might be offended with it .

But indeed Dutch and English would do also my first guess , Dutch is
then C# and English VB ;-)



regards

Michel

Michel,

Eigenlijk een beetje hetzelfde als Engels en Nederlands.

Als je beide echter nooit hebt geleerd, dan zie je gauw dat het toch
allemaal wat anders is dan het lijkt voor degene die goed overweg kunnen
met deze talen.

Geef even een reactie Michel (in het Engels)?



Cor

You confirm here my first point, this wasn`t a posting with a valid
question it was again just bashing VB
C# the better choice ? for a Java , C++ and all other mathmetatical
syntax developers it is , for a logical syntax developer or annyone
who likes a

It seems most of the VBers think that C# and VB.net are very different
languages. This is not true, they are pretty much exactly the same. You
design forms in the same way, you create classes in the same way, the
coding is pretty much the same. They are so similar that a machine can
translate from one to the other with a very high degree of accuracy. All
the differences that people here discuss such as office automation and
creating events are side issues because they are not used all that often.
The real differences are much more subtle and come down to syntax,
intellisense, compiler warnings, lack of legacy keywords and other minor
issues. These might sound fairly minor but if you're stuck using VB day
after day all the extra typing can really drag you down. I think the
compiler warnings are a significant one, if the compiler can pick
something up for you then why not? The lack of legacy stuff such as
option strict and on error goto is also significant in C#. My experience
is that when working in a team if there is a crappy feature some idiot
will use it. It's simply better not to have these features at all.

RAD language VB is the better choice .

I've read this here several times here always with no further
explanation. Why do you think that VB is the better choice for RAD? I
think this was once true when comparing vb6 to C++ but now that C# exists
this is no longer true. Being that the major differences are really
fairly minor how could VB be that much quicker to develop in? Especially
seeing that in VB you have to do more typing in pretty much all cases how
can it possibly be quicker?

Personally i believe that VB developers are overall more modest an
logical thinking people , they can see that every language suits a
certain need , we are more multicultural in terms of programming
languages , however the bashers that come by in this group seem to
believe in only one super language and everything else has no right of
existence and is inferior .

Who said anything about 1 superior langauge? Obviously you can't say C++
is superior to C# because both serve a different purpose. C++ is superior
for writing drivers while C# could be considered superior for writing
windows apps. However seeing VB and C# are pretty much the same and do
the same task I think you can say that C# is the better choice.

Well the c# syntax there is clearly superior because you can do
anything you like. Step can be a log function if you want and you can
increment 2 variables which often comes in handy, eg

int* ptr = GetSomePointer();
for (int i = 1; i <= 10; i += 2, ptr++)

Interesting that you brought up this example and then snip it in your
reply....

Huh ? wel for the sake of your case you forgot the other points i made
like "optional and named parameters "

Actually I thought that was covered in my statement that VB has the
occasional saving in typing but these cases are rare when you have
written Dim, End If, Next, Function, Sub, Property etc 1000+ times in day
(no exaggeration!).

cause you do not have a valid alternative, for optional you could have
argued that method overloading is the valid way to mimic the same
behavior , however this costs a lot more typing and would be pathetic in
contradiction to your above argument, so good for you that you did not
step in that trap

Personally I much prefer not to have optionals and in 10+ years of
programming I can't remember ever using named parameters.

But a lot more typing in VB ? hmmmm

if (Object.ReferenceEquals(a, b))
{
// variables refer to the same instance
}

VS If a Is b Then
' variables refer to the same instance
End If

Great, I can't remember ever using ReferenceEquals either.

if ((a == null && b == null) || (a != null && b != null) && a.equals(b))
VSIf a = b Then

I think you're confused there. Why can't I just do "if(a == b)"?

And about logic int [] ages = new int[n]; ( integer ages is new
integer in n dimensions )VS Dim ages(n) as Integer ( Ages in n
dimensions as integer ) why do i have to tell C# 2 times wich datatype
or object type it is dealling with ? Just some rare examples who seem to
be not so rare do they ?

Actually you've hit on the very point I was going to make. These are rare
when you compare it to the big ones such as Dim, Function, Sub etc that
you need to type over and over and over every day. It always seems that
the VBer point out the rare cases in an attempt to "prove" that there is
more typing in C#. You've pretty much proven this by bringing up the
ReferenceEquals case.

i can dig up a lot more if you want however honesty needs me to say that
i could also do the same against VB in favor of C# and ofcourse if
() { }is a lot shorter as If () ThenEnd if
But the VB IDE team found something verry smart for that , you only
type If () and press enter and the IDE does the rest , a true RAD
language in a true RAD environment by the way you can discuss
whateveryou want about the language but a true fact is that the IDE of
VB is superior to that of C# in every way

That's pretty much completely not true. Intellisense is very much
inferior in VB. I listed 10 significant problems with the VB intellisense
in this group and there was pretty much no response. In a newsgroup the
closest thing you get to agreement is a non-response.

That is also the reasson why VB was a bit behind on C# in some new
features as the 2 dev teams focussed on 2 different points , C# dev team
language enhancements , VB dev team getting all the nice features back
that the VB6 IDE already had ( background compilation

yuk! One of the best features of C# is the lack of background compile. A
lot of corporate machines are lagging behind in specs. I'm still on a
celeron 2.6 with 1gb ram at work while I have a quad core at home. VB was
downright slow on the celery while C# was quite acceptable.

, debug,pause , change and continue without recompiling etc etc etc... )

Didn't VB and C# get these features at the same time?

and then enhance the IDE so it has "more" to offer .

More wizards?

IMHO :>> Both have there pro`s and con`s due to just
the simple fact that both dev >> teams give different priorities to some
implementations in the languages >> and syntaxtical> > The only real
advantage I can see with VB is the late binding office > automation
thing. I'm yet to try this to see what a real issue it is.yes indeed and
all other Automation , COM interop thingies especially when you want to
use Late bindingand ofcourse LINQ to XML wich is superior in VB at the
moment and

How is linq to xml superior in VB?

................ >> but i do not need C# fanboys in the VB groups
telling me that VB is less >> mature as C# they are brothers of the
same kind but it is mostly the C# >> coder running around as Kaïn ,
in the end you might kill us, but it is >> Abel who is and stays the
most beloved in this group> > Then don't read this thread. I was asking
a valid question, with a complex > linq query you have to write
Function(i) over and over which is a pain.> > Michael IMHO : And when i
reread the thread and the responses from my fellow peers your posting
is interpreted as yetanother atack on the VB comunity , the Title was
enough for me to let me think "Oh no not again" oh.. another thingy
about VB developers in contradiction to "other" groups we are pretty
social peoplehere and like to keep the discussion nice and with respect
to each other . I hope you get my overall point i both love VB and
C# i just favor VB a bit more , i also wonder what will happen if F#
developers will behave how C# developers behave now towards VB
developers .That there are and will be differences between the diverse
languages is a common fact and as a smart developer once said "Language
choice is as much an emotional as a logical decision."RegardsMichel
Posseth

For some reason the formatting here has gotten a little screwed up so I'm
not sure what part is your text and others.

Michael

 

[Jack the Ripper]

Nope. Just nosing around. Personally I wouldn't use anything that is a
product of Micro$oft other than the stuff I already have.

Mike

No one cares what you'll use or won't use. So, why even bring it up?

 

[Michel Posseth [MCP]]

I'm really not sure what that is meant to prove. I presume you're speaking
dutch which would take me months or years to learn even though I already
know english. As opposed to C# which took me 1 single day to learn (from
knowing vb.net). If anything your post proves how similar C# and VB are.
ie most VBers could simply just start reading C# with minimal trouble (and
vice versa).

Michael

Months or Years ? even if you live in the Netherlands for decades you only
have to speak a few words
and they hear inmediatly that you are a non native speaker .

The only persons who are having an adavantage are German speaking persons .
Although they catched German undercover agents in the second world war on
the spot with only one simple question "say this loud `s Gravenhage "
fonetic " sggraavenhaage " where the g is of such a way that only a
native can pronounce it fluent,
the Germans have a hard g and can not prenounce it "our" way .

Even children from imigrants ( mostly marokkans ) who are born in this
country , but speak to much there own language ( at home and on the
streets )
because they refuse to participate in "normal" Dutch society , are mistaken
for newcomers as we here an accent in there speach .

But indeed the funny thing is that for us learning English is pretty simple
, every Dutch person speaks English even young children might surprise you
and when i am at a holliday and speak English a lot , people often mistake
me for a native English speaker wich i am obviously not .

For me well i program in Basic language since the mid eighties i was
theirteen years old when i brought my first working program to school
on a 60 minutes tape to show to my infomatica teacher ( superior calculator
;-) i called it )
, it was made on the Commodore CBM64 , i am now 35 years old
So i guess that there is 22 years of basic syntax stored in my brain ( CBM ,
QBasic , VB , VB.Net ) and then i should now abbandon my logic language
wich i grew up with for a mathmetical language ? , and you call it a brand
new language but did you ever thought why MS decided to bring up F# to the
front ?
C# has just as manny constructs inherited from C , C++ and Java as VB.Net
from VB legacy , i guess that you just made your choice for the wrong
reassons
and you are still searching for ways to convince yourself that you made the
right choice .

I am a VB DotNet Coder and i wear the VB part with pride

regards

Michel

 

[Herfried K. Wagner [MVP]]

The lack of legacy stuff such as option strict and on error goto is also
significant in C#. My experience is that when working in a team if there
is a crappy feature some idiot will use it. It's simply better not to have
these features at all.

This really depends on what you consider "legacy stuff". Personally I
consider 'unsafe' blocks (the ability to bypass the CLR checks) in C#
"legacy stuff". Nevertheless, I do not think that C# is worse than VB
because of that.

Actually I thought that was covered in my statement that VB has the
occasional saving in typing but these cases are rare when you have written
Dim, End If, Next, Function, Sub, Property etc 1000+ times in day (no
exaggeration!).

I have hardly ever written 'End If', for example!

Great, I can't remember ever using ReferenceEquals either.

Well, the problem (call it "design decision" if you want) is that C#
overloads the '==' operator for both value and reference comparison.

 

[Mike Williams]

No one cares what you'll use or won't use.
So, why even bring it up?

No one cares what you think about what other people care about, so why even
bring it up?

Mike

 

[Tom Shelton]

This really depends on what you consider "legacy stuff". Personally I
consider 'unsafe' blocks (the ability to bypass the CLR checks) in C#
"legacy stuff". Nevertheless, I do not think that C# is worse than VB
because of that.

I would have to agree with this, for the most part. Most of the time, this
facility is only used for interop with existing legacy code/libraries. But,
it is occasionaly useful in a managed environment - as it can greatly speed up
certain types of operations, such as image manipulation. That said, I can
honestly say, I've very rarely had a need to use "unsafe" code.

I have hardly ever written 'End If', for example!

No, but because of the crappy implementaion of the VB IDE intellisense, you
make up for it by typeing <ESC> all the time. Seriously, I have NOTHING
against the VB.NET language it's self (I chose C# as my primary .NET langauge
simply because I prefere the terser syntax of C-style languages and I loath
case-insensitivity), but the IDE is an exercise in frustration after using
the vastly superior C# ide...

For just one example type in an expression that utilizes an object that is in
a reference assembly, but has no import defined (using in C#) - and compare
the difference in behavior. C# will offer to include the using as you type,
rather then wait for you to type the entire expression and then hit enter.

Well, the problem (call it "design decision" if you want) is that C#
overloads the '==' operator for both value and reference comparison.

I've been playing with C# since the PDC bits, and it has been my primary
langauge professionally since 2001 (yes, that was before the official release
in 2002) - and I can honestly say that I've written code like the above only a
handfull of times. The fact is that most of the time, what you want is
equality that makes sense for the object, and that means calling the objects
..Equals method (==). The only time I've used the Object.ReferenceEquals is
when I want to make sure that I'm doing a reference compare...

 

[Tom Shelton]

<<<<< WARNING The following reflects my personal opinion regarding
postings like this >>>>>

My personal opinion is that it is a bit odd that people come here in the
VB.Net group for the sole reasson to bash VB

It's unfortunate that this happens - never the less, it is par for the course
for usenet.

There are so manny things that are a lot easier in VB as in C# , do you see
anny of us posting this in the C# groups with offensive titles as "is
office interop the final straw for C# ? " just to call one or what did you
thought about optional and named parameters lots of succes with that in C#
( at least until framework 4.0 )

The only time that optional and named params have any real utility is when
dealing with COM interop, IMHO. I am, a bit concerend about there inclusion
in C# version 4. I hope that they are not overused and abused. IMHO,
using function overloading is a much more appropriate method of creating
functions that take different arguments.

or no this one is also stil a favorite one of mine

C#
for (int i = 1; (i <= 10);
i = (i + 2))
{
// Do your stuff
}

Are you purposefully trying to make that look bad?

for (int i = 1; i <= 10; i += 2)
{
// do your stuff
}

Seriously, what's with all the extra parens? Beyond the syntax, what about
all of the things that a C# for loop can do that a VB.NET for loop can't - for
instance track multiple values?

or okay option 2 for (int i = 1; i <= 10; i += 2) { // Do your stuff
}VBFor i = 1 To 10 Step 2
'Do your stuff
Next
Pick the one that seems easiest to code and understand

For me, the first (when coded correctly and realistically) - for you maybe the second.

But hey i am just a stupid VB guy who ocasionally uses C# just for the sole
reasson that a lot of open libs are written in C# and i do not want to
completely rewrite them but just change them and import them in my solution
as C# as i do not have a aversion against C# .

Good. I don't have an aversion to VB.NET - beyond a preference for the
C-style syntax.

IMHO :
Both have there pro`s and con`s due to just the simple fact that both dev
teams give different priorities to some implementations in the languages and
syntaxtical
but i do not need C# fanboys in the VB groups telling me that VB is less
mature as C# they are brothers of the same kind but it is mostly the C#
coder running around as Kaïn , in the end you might kill us, but it is
Abel who is and stays the most beloved in this group

Very true. There are a few things, such as com interop and linq-to-xml that
are a little easier in VB.NET then C#. But, there are things in C# that are
simpler then VB.NET - for instance simple property declaration:

C#:
public class SomeClass
{
public int AnInteger {get; set;}
}

VB.NET:
Public Class SomeClass
Private _anInteger As Integer

Public Property AnInteger() As Integer
Get
Return _anInteger
End Get
Set (ByVal value As Integer)
_anInteger = value
End Set
End Property
End Class

Or, using List(Of T).ForEach...

C#:

void Main (string[] args)
{
var ints = new List<int>() {1, 2, 3, 4, 5};
ints.ForEach ( i => Console.WriteLine (i) );
}


VB.NET
Sub Main()
Dim ints As New List(Of Integer)(New Integer() {1, 2, 3, 4, 5})
ints.ForEach(New Action(Of Integer)(AddressOf Print))
End Sub

Sub Print(ByVal i As Integer)
Console.WriteLine(i)
End Sub

Want more examples?

 

[Jack the Ripper]

No one cares what you think about what other people care about, so why
even bring it up?

Mike

I defer to you. Why did you bring it up? I think you're just trolling
the person and running your mouth.

 

[Tom Shelton]

You confirm here my first point, this wasn`t a posting with a valid question
it was again just bashing VB
C# the better choice ? for a Java , C++ and all other mathmetatical syntax
developers it is , for a logical syntax developer or annyone who likes a
RAD language VB is the better choice .

Personally i believe that VB developers are overall more modest an logical
thinking people , they can see that every language suits a certain need , we
are more multicultural in terms of programming languages , however the
bashers that come by in this group seem to believe in only one super
language and everything else has no right of existence and is inferior .


Huh ? wel for the sake of your case you forgot the other points i made like
"optional and named parameters "
cause you do not have a valid alternative, for optional you could have
argued that method overloading is the valid way to mimic the same behavior ,
however this costs a lot more typing and would be pathetic in contradiction
to your above argument, so good for you that you did not step in that trap
.

It might be more typing, but I believe more correct. It isn't all about how
many keystrokes something takes you know - but, if you want to play that game
overall VB.NET requires more kestrokes for most activities...

But a lot more typing in VB ? hmmmm

if (Object.ReferenceEquals(a, b))
{
// variables refer to the same instance
}

Huh? I've use that construct only a handfull of times in the last nine years.
You would only use that in cases where you wanted to guarentee reference
equality. The vast majority of times:

if (a == b)

Is quite sufficient, and in fact what you want.

VS If a Is b Then
' variables refer to the same instance
End If
if ((a == null && b == null) || (a != null && b != null) && a.equals(b))

What the heck is that?
if (a == b)
{
}

accomplishes the same thing... I think your puposely trying to exagerate the
differences between the two langauges.

VSIf a = b Then

And about logic int [] ages = new int[n]; ( integer ages is new integer

var ages = new int[5];

Even so, int[] is a different type then int - which is true in VB.NET as well.
C# syntax makes you declare the type - in some cases that may result in longer
code then VB.NET syntax... Oh, well.

in n dimensions )VS Dim ages(n) as Integer ( Ages in n dimensions as
integer ) why do i have to tell C# 2 times wich datatype or object type it
is dealling with ?

Well technically, your not telling it twice. Your telling it the first time
with int[], the secont int[n] is calling the constructor.

Just some rare examples who seem to be not so rare do
they ? i can dig up a lot more if you want however honesty needs me to say
that i could also do the same against VB in favor of C# and ofcourse if
() { }is a lot shorter as If () ThenEnd if
But the VB IDE team found something verry smart for that , you only

Now your starting down a path that VB will loose badley on... The VB.NET IDE
is a mess and has been very much inferior to the C# experience since the 2005
release.

type If () and press enter and the IDE does the rest , a true RAD language

so does C#.

in a true RAD environment by the way you can discuss whateveryou want about
the language but a true fact is that the IDE of VB is superior to that of C#
in every way

Really, intellisense pops up at bad times, causing a lot of extaneous hitting
of the escape key. The auto-generating of imports statements sucks, because
it makes you complete the entire expression before and hit enter before it
suggests adding the import statement. Same with the auto implementation of
interfaces and abstract base classes...

No, the VB.NET IDE is in many ways it's greatest liablity, IMHO.

That is also the reasson why VB was a bit behind on C# in some
new features as the 2 dev teams focussed on 2 different points , C# dev team
language enhancements , VB dev team getting all the nice features back that
the VB6 IDE already had ( background compilation , debug,pause , change and
continue without recompiling etc etc etc... )

C# got E&C at the sametime VB.NET did. And as for background compile, that's
been a menace since day one for larger projects. Though, that may equalize
with the 2008 release since C# now has that as well. Though, I can honestly
say that on this old XP box, the C# ide still seems to be more responsive then
the VB.NET IDE - even with background compile.

and then enhance the IDE so it
has "more" to offer .>> IMHO :>> Both have there pro`s and con`s due to just
the simple fact that both dev >> teams give different priorities to some
implementations in the languages >> and syntaxtical> > The only real
advantage I can see with VB is the late binding office > automation thing.
I'm yet to try this to see what a real issue it is.yes indeed and all other
Automation , COM interop thingies especially when you want to use Late
bindingand ofcourse LINQ to XML wich is superior in VB at the moment and

I agree about COM interop - and maybe slightly on LINQ to XML... Some of the
inline xml stuff is nice. Overall though, LINQ in general is much nicer in
C#, because of it's fuller support for lamba expressions.

 

[Mike Williams]

I defer to you. Why did you bring it up? I think you're
just trolling the person and running your mouth.

I defer to you. Why did you bring it up? No one cares what you think. I
think your just trolling and running your mouth.

 

[Michael C]

C# has just as manny constructs inherited from C , C++ and Java as VB.Net
from VB legacy , i guess that you just made your choice for the wrong
reassons
and you are still searching for ways to convince yourself that you made
the right choice .

I don't think so. Just to poor intellisense is enough for me to move C#
without all the other very good reasons.

 

[Michael C]

This really depends on what you consider "legacy stuff". Personally I
consider 'unsafe' blocks (the ability to bypass the CLR checks) in C#
"legacy stuff". Nevertheless, I do not think that C# is worse than VB
because of that.

That is not legacy, it is a useful feature that still comes in handy.
Computers still use memory and still use pointers. On the other hand on
error goto has well and truly been replaced.

I have hardly ever written 'End If', for example!

True but you've still written many of the others. The really annoying one is
public readonly property. Why intellisense shows each of these keywords but
forces you to down arrow on each of them is beyond me. And why we need to
write the word readonly when leaving out the set block should suffice.

Well, the problem (call it "design decision" if you want) is that C#
overloads the '==' operator for both value and reference comparison.

It's not really a problem.

Michael

 

[Herfried K. Wagner [MVP]]

That is not legacy, it is a useful feature that still comes in handy.

Well, there are cases in which 'On Error Resume Next' makes perfect sense
too as it would require to write a huge amount of code otherwise.

Computers still use memory and still use pointers. On the other hand on
error goto has well and truly been replaced.

That's your opinion, but I disagree. Pointers have been replaced by (safe)
references -- already in Classic VB! Pointers add a huge potential for
errors and exploits.

True but you've still written many of the others. The really annoying one
is public readonly property. Why intellisense shows each of these keywords
but forces you to down arrow on each of them is beyond me. And why we need
to write the word readonly when leaving out the set block should suffice.

Sure, there is much potential of improvement. However, other people may
argue that they use code snippets for code generation and thus do not suffer
from most of the problems you describe related to IntelliSense.

 

[Michael C]

Well, there are cases in which 'On Error Resume Next' makes perfect sense
too as it would require to write a huge amount of code otherwise.

That "huge" amount of code is a couple of extra lines and well worth it to
avoid on error resume next. If you're using on error resume next on large
blocks of code then something is very very wrong with what you are coding.
While I have used on error resume next in VB6 I have never found a need to
do it on more than one line of code at a time.

That's your opinion, but I disagree. Pointers have been replaced by
(safe) references -- already in Classic VB! Pointers add a huge potential
for errors and exploits.

Of course you need to be very careful with pointers. However, pointers are
still alive and well and used extensively in modern computing despite your
opinion. The whole computer would not run without pointers. In C# the need
for them is rare (depending on the type of work you do I guess) but when you
need them they are very useful. For example you can manipulate a live video
stream very easily with pointers. To compare a trump feature like pointers
with on error goto is pretty far out really.

Sure, there is much potential of improvement. However, other people may
argue that they use code snippets for code generation and thus do not
suffer from most of the problems you describe related to IntelliSense.

They might be able to find some ways around some of the problems with vb's
intellisense but there are still other problems. For example, when selecting
the name of control VB defaults to the control's event (eg
txtWhatEver_Click). In all my years of programming I've never called an
event directly but VB selects it every time and that it just one example.

Michael

 

[Jack the Ripper]

I defer to you. Why did you bring it up? No one cares what you think. I
think your just trolling and running your mouth.

Is this the best that you can do? Pitiful!

 

[Michael C]

Really, intellisense pops up at bad times, causing a lot of extaneous
hitting
of the escape key.

This is so true, I got sick to death with pushing escape over and over all
day long. If you code from left to right then it works ok-ish in VB but if
you make mistakes, change your mind, go back (which I do a lot) then VB is a
right pita.

Michael

 

[Alex Clark]

Maybe so but at the very basic level linq is a little too long winded in

VB.

Which if you're really honest, is a matter of personal taste isn't it? This
is basically the same discussion that you, I, Tom Shelton, and a few others
from this thread all had in the "When is VB getting anonymous delegates"
thread a few weeks prior.

If you prefer terse code, then Linq in VB is not going to be to your taste -
in fact nothing in VB will be, because it's inherently more wordy and
verbose than C-derived languages. That's pretty much what makes it VB.

Personally when Linq expressions get to the level of using multiple Lambdas,
I believe they're going to be harder to maintain and understand down the
line regardless of which language you choose. I would prefer to see, in
clear language, that part of the expression is using a Lambda because I feel
it makes it a little easier to read - but I stress the point that this is
*my* preference. Someone who codes more in C# than VB is likely to prefer
the terse syntax.

I'm not the biggest fan of dumping loads of Lambdas into a Linq expression
anyway, as I think it creates hellish debugging scenarios and makes for poor
maintainability. Unless it's something particularly simple I'd rather write
real functions and call out to them from the Linq expression - chances are
good I may end up using them again somewhere else anyway, which makes for
more efficient code in the long term.

As far as VB's intellisense goes, yes - it's great if that's all you use,
but not so great when you start to compare it to C#'s intellisense. I named
at least half a dozen really obvious problems (bugs) with it in the previous
thread we all had, and it really does feel like MS put less effort into it
for VB than C#. That should (and hopefully will) be standardised on for VS
2010.

However, holding the tool against the language is a bit silly IMO. That's
like saying you prefer wood houses to brick houses because saws are easier
to use than masonry tools.

 

[Michel Posseth [MCP]]

The actuall troll was the first post made, aka the start post of this
thread

 

[Mike Williams]

Is this the best that you can do? Pitiful!

It's certainly no more pitiful than making the unqualified statement, "Is
this is the best you can do", as you did!

Is that the best you can do?

 

[Michael C]

Which if you're really honest, is a matter of personal taste isn't it?
This is basically the same discussion that you, I, Tom Shelton, and a few
others from this thread all had in the "When is VB getting anonymous
delegates" thread a few weeks prior.

No, this discussion is completely unique. No-one has ever discussed vb-vs-c#
before on usenet ;-)))

If you prefer terse code, then Linq in VB is not going to be to your
taste - in fact nothing in VB will be, because it's inherently more wordy
and verbose than C-derived languages. That's pretty much what makes it
VB.

I did prefer VB for many years but once I tried C# I found that it is much
more to my taste. When using VB I pretty much always chose the shorter code,
for example I can't see why people would write this:

If x < 0 then
x = 1
End If

IMO, there is absolutely no reason that shouldn't be one line of code. Once
I started using C# I found I could take more short concise code one step
further. And once linq was release a whole step further again

Personally when Linq expressions get to the level of using multiple
Lambdas, I believe they're going to be harder to maintain and understand
down the line regardless of which language you choose. I would prefer to
see, in clear language, that part of the expression is using a Lambda
because I feel it makes it a little easier to read - but I stress the
point that this is *my* preference. Someone who codes more in C# than VB
is likely to prefer the terse syntax.

I'm not the biggest fan of dumping loads of Lambdas into a Linq expression
anyway, as I think it creates hellish debugging scenarios and makes for
poor maintainability. Unless it's something particularly simple I'd
rather write real functions and call out to them from the Linq
expression - chances are good I may end up using them again somewhere else
anyway,

You'd absolutely hate my code then. I don't really see why you'd place such
restrictions on yourself really. Why would you write a function with just
"return x> 5" in it? Surely that's more difficult to read?

which makes for more efficient code in the long term.

Optimisation will probably eliminate duplicate functions anyway. Even VB6
would do this.

As far as VB's intellisense goes, yes - it's great if that's all you use,
but not so great when you start to compare it to C#'s intellisense. I
named at least half a dozen really obvious problems (bugs) with it in the
previous thread we all had, and it really does feel like MS put less
effort into it for VB than C#. That should (and hopefully will) be
standardised on for VS 2010.

Yep, I think I listed a similar number of problems. Some of these problems
are *really* annoying because you encounter them literally 100s of times a
day (without exaggerations).

However, holding the tool against the language is a bit silly IMO.

I made this same point myself in the previous thread. These problems are not
really problems with the VB syntax. However these are still problems with VB
and problems you will encounter possibly for many years to come if you use
it.

That's like saying you prefer wood houses to brick houses because saws are
easier to use than masonry tools.

But we are the builder of houses and it's perfectly valid to decide to build
wood houses because it's easier to cut. Although the analogy is not 100%
accurate because we end up with the same product whichever tool we choose.

Michael