Is linq the final straw for VB?

  • Thread starter Thread starter Michael C
  • Start date Start date
Mike Williams said:
Nope. Just nosing around. Personally I wouldn't use anything that is a
product of Micro$oft other than the stuff I already have.

Aren't you cutting off your nose to spite your face? Obviously you've gained
much pleasure from learning and programming in VB6 all these years. The
enjoyment must be less now because you know it very well so have less to
learn about it now. You could learn all sorts of wonderful things with dot
net (linq is really quite amazing to see). Yet you punish yourself to
deprive Billy boy of some dollars he won't even notice. Any you can even use
dot net for free anyway!

Michael
 
Mike said:
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?

Do I care? Maybe, you should ask that first.
 
Michael C said:
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 :-)

I never use single-line 'If...Then' statements. By using the above most of
the code will be generated automatically (only 'If x < 0' must be typed) and
it's much easier to extend by additional statements inside the block than
the single-line version. This also applies to C#.
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?

Obviously that's a matter of personal preference. I agree with Alex'
opinion on lambda functions.
 
Do I care? Maybe, you should ask that first.

There is no reason for me to ask that first because I don't care whether you
care. The answer would be irrelevant.

Your turn.
 
Michael C said:
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?

I wouldn't, but when there are half a dozen different places in the Linq
statement that require Lambdas that are looking at deep properties of the
object I'm selecting, *then* I start factoring them out into real functions.
Because of the one-line limitation on Lambdas right now, that often means I
can rationalise multiple Lambdas into one multi-line function anyway. To
me, that looks *far* more readable because I'm simply calling "...Where
IsRadioActiveAndUnstable(element)..." instead of having a to create a few
separate Lambdas. It's more terse, lol.
Optimisation will probably eliminate duplicate functions anyway. Even VB6
would do this.

That isn't the point. If I have multiple different Linq statements that
perform similar or identical filters on the sequences I'm selecting from,
then doing it the Lambda way means I still have to write those Lambda
expressions multiple times. What happens when I want to change a filter
parameter slightly? I have multiple different Linq queries where I have to
alter those same Lambdas.

Regardless of what optimisations the compiler does, *I* want my code
centralised and flexible. Embedding multiple complex Lambda functions into
query statements is not the way to achieve that, IMO.

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.

You're correct, my analogy was flawed.

A more correct analogy is to say "wood is a better material than stone
because I prefer using saws". Which, as you can see, is even more
ridiculous. Wood may be easier for you to work with due to your familiarity
with saws, it may be far more suitable for you because you find the masonry
tools clumsy, but a stone-mason will disagree with you for all the same
reasons.

It doesn't make one material better than the other - unless you're talking
in subjective terms.
 
Hello Michael,
for example I can't see why people would write this:

If x< 0 then
x = 1
End If

I guess because it's much nicer than
if x<0
{
x = 1;
}


Having a German keyboard, I have to press AltGr + 7 to reach
{ and AltGr+0 for }.

So BASIC is much easier to type. Not everybody uses an English keyboard,
you know...

Best wishes,

Martin
 
Mike said:
There is no reason for me to ask that first because I don't care whether
you care. The answer would be irrelevant.

Your turn.

You can go lay down now as you're becoming boring.
 
You can go lay down now as you're becoming boring.

A nice well honed, well thought out and intelligent response! Is that really
the best you can do! It doesn't matter though because I'm off for another
holiday in the morning so you can have the field to yourself for a while and
you'll be able to say whatever you want without worrying about actually
getting it right and without needing to make any sense. But then of course
failing to get it right and talking nonesense has never bothered you before,
so I'm sure it won't bother you now. You can even pretend to yourself that
you have "won a point" by the fact that I will not respond to you for a
while, but you will just be kidding yourself, as usual. See you in about a
week, troll. Good fun this, isn't it. Don't go away now. Your trolling of
this group is becoming a lot of fun ;-)

Over to you, sonny boy.
 
Herfried K. Wagner said:
I never use single-line 'If...Then' statements. By using the above most
of the code will be generated automatically (only 'If x < 0' must be
typed) and it's much easier to extend by additional statements inside the
block than the single-line version. This also applies to C#.

It's not a typing thing, it's just good to minimise lines of code imo
(without going overboard of course). Using 3 lines to keep a variable above
zero is a bit much imo.
Obviously that's a matter of personal preference. I agree with Alex'
opinion on lambda functions.

See my reply to his post.

Michael
 
Alex Clark said:
I wouldn't, but when there are half a dozen different places in the Linq
statement that require Lambdas that are looking at deep properties of the
object I'm selecting, *then* I start factoring them out into real
functions. Because of the one-line limitation on Lambdas right now, that
often means I can rationalise multiple Lambdas into one multi-line
function anyway. To me, that looks *far* more readable because I'm simply
calling "...Where IsRadioActiveAndUnstable(element)..." instead of having
a to create a few separate Lambdas. It's more terse, lol.

Ok, fair enough I think I misread what you wrote. I thought you meant you
wouldn't use more than 1 lambda express in a statement. I agree that if the
lambda gets too complicated then it should possibly be a function, although
That isn't the point. If I have multiple different Linq statements that
perform similar or identical filters on the sequences I'm selecting from,
then doing it the Lambda way means I still have to write those Lambda
expressions multiple times. What happens when I want to change a filter
parameter slightly? I have multiple different Linq queries where I have
to alter those same Lambdas.

Regardless of what optimisations the compiler does, *I* want my code
centralised and flexible. Embedding multiple complex Lambda functions
into query statements is not the way to achieve that, IMO.

Fair enough.
You're correct, my analogy was flawed.

A more correct analogy is to say "wood is a better material than stone
because I prefer using saws". Which, as you can see, is even more
ridiculous. Wood may be easier for you to work with due to your
familiarity with saws, it may be far more suitable for you because you
find the masonry tools clumsy, but a stone-mason will disagree with you
for all the same reasons.

It doesn't make one material better than the other - unless you're talking
in subjective terms.

Your analogy is still flawed. A better analogy is to say I prefer using an
electric saw to build a house instead of a handsaw because using an electic
saw is faster. That is perfectly valid and I still end up with a house in
the end, just faster and possibly a better quality house (due to the fact
that my saw has better compiler checks and is a stricter saw).

Michael
 
Martin H. said:
Hello Michael,


I guess because it's much nicer than
if x<0
{
x = 1;
}


Having a German keyboard, I have to press AltGr + 7 to reach
{ and AltGr+0 for }.

So BASIC is much easier to type. Not everybody uses an English keyboard,
you know...

Spend 5 deutchmarks to get an english keyboard then. But why not just write
it all on one line?

Michael
 
Michael C said:
That "huge" amount of code is a couple of extra lines and well worth it to
avoid on error resume next.

You wrote:

| Anyway, my point is that with VB you need to write Function(i) instead of
| just i => which seems to defeat a lot of the point of linq which is to
write
| short consice code.

Sorry, I do not understand why you worry about the few additional characters
of VB's 'Function(i)' compared to C#'s '=>' if you do not worry about
additional characters in C#.

I do not think that the number of code characters required for a certain
task is a suitable metric to measure the quality of a programming language.
 
Michael C said:
Spend 5 deutchmarks to get an english keyboard then. But why not just
write it all on one line?

There is no Deutsche Mark any more ;-).

However, for people who are typing "blindly" changing the keyboard layout in
Windows should be sufficient too.
 
Herfried K. Wagner said:
There is no Deutsche Mark any more ;-).

So these 2 Deutsche Marks I have here are now worthless? ;-)
However, for people who are typing "blindly" changing the keyboard layout
in Windows should be sufficient too.

Actually AltGr + 7 is still only 2 keystrokes anyway, same as Shift + {.

Michael
 
Herfried K. Wagner said:
You wrote:

| Anyway, my point is that with VB you need to write Function(i) instead
of
| just i => which seems to defeat a lot of the point of linq which is to
write
| short consice code.

Sorry, I do not understand why you worry about the few additional
characters of VB's 'Function(i)' compared to C#'s '=>' if you do not worry
about additional characters in C#.

In the case of lambda expressions a big part of the reason we use them is to
save typing. If we use them several times in the one query then the
Function(i) becomes cumbersome.

As for On Error Resume Next it hardly needs to be said that it is worth a
bit extra typing to get rid of that. Generally it's something you use once
per year, compared to many times per day for a lambda.
I do not think that the number of code characters required for a certain
task is a suitable metric to measure the quality of a programming
language.

I never said it was. I said that it is affects how easy the language is to
use.

Michael
 
Hello Michael,
Spend 5 deutchmarks to get an english keyboard then.
We have Euros... ;)

Besides: Why should I use a keymap which does not have the layout I'm
used to and does not show Umlauts äöüß? The English keymap is not
sufficient if you want to write German.
But why not just write
it all on one line?

Your VB example was also not on one line...
If x < 0 Then x= 1

Best regards,

Martin
 
Michael D. Ober said:
Actually, I have discovered that when someone tries to sell this group on
the "death of VB" they turn out to be either uninformed or trolls. Thus
my question.

Yep I guess anyone who is critical of VB must be either raving mad or a
troll. There couldn't possibly any other reason, I mean VB is perfect of
course ;-)

Michael
 
Back
Top