The Daily WTF: Curious Perversions in Information Technology

Jaime · 2010-10-18 Reply Admin

Bus Logic:
JJ:
Bus Logic:
frits:
Bus Logic:
frits:
Bus Logic:
This bizarre ambiguity between properties and functions is just one item on a very long list of inherent issues with VB.NET. I honestly have no idea why anyone would choose it over C# when targeting the .NET framework, unless they're just so bad at writing code that they can't make the switch from Microsoft's kiddie code to a real language.

But properties and methods are the same thing in .Net, really. Properties are just syntatical sugar for getters and setters that can be abused to cause side effects and block indefinitely. The same is true for indexers. I'm not sure why you think C# is any better, because the underlying mechanism is the same. Disclaimer: I don't even like VB.Net.

SYNTAX! The underlying mechanism may be the same but the C# syntax is vastly better because it removes the ambiguity. Did I really need to explain that to you? The whole point of today's article is the dodgy syntax, please keep up.

Reading is fundamental. When two things are the same, there is no ambiguity.

I'm not sure it's my reading comprehension that's at fault here but whatever, I'll try again. The syntax for property accessors is different between C# and VB.NET. It is the improved syntax of C# that makes it a superior language to VB. It doesn't matter whether this is "syntactic sugar" for some underlying concept, the simple fact remains that the syntax of C# is superior to the syntax of VB in regard to properties. What don't you understand here? I'm not trying to be difficult, I honestly don't understand where the confusion lies. I know perfectly well that properties are syntactic sugar for getters and setters but it doesn't change the fact that C# has a far better syntax when dealing with properties than VB.
What are you talking about? You either do
x = SomeObject.SomeProperty

or

SomeObject.SomeProperty = x

Minus the semicolon at the end of the statements, the syntax is identical. The only difference between VB.NET and C# syntax is the fact that VB.NET has the concept of indexed properties, a carrythrough (throwback, if you will) from older versions of VB. Basically it was meant to allow a property to act like an array, and it is this functionality that was totally abused in the article.

What exactly is the "superior" syntax of C#? Merely the fact that it doesn't include the functionality described above?
You just explained it to yourself - C# has a superior syntax because it does not allow such abusable constructs as indexed properties, which by your own admission are a throw-back from a previous era and clearly have no place here. Simple.

Yet the System.Data.DataRow class has an indexed property named "Item" that is widely used. I wonder if Microsoft wrote System.Data in C++ or VB (don't bother answering, I'm sure they wrote it in C++)? They certainly didn't write it in C#. If you look at intellisense for System.Data.DataRow in C#, you won't see an Item property because it can't be expressed properly in C#, but the class indexer actually redirects to the Item property's indexer. Reflector clearly shows that the indexed property really exists. Of course, in VB, you can access it using the proper indexed property syntax or the C# style class indexer syntax.

This also brings up a similar ambiguity in C#. Having both class indexers and arrays of classes is equally ambiguous. I don't see any of the C# guys clamoring to get indexers removed from C#.

2010-10-18 Reply Admin

sino:
boog:
Markp:
akatherder:
A poor craftsman blames his tools.
So does a good craftsman who has crappy tools.
What good craftsman willingly uses crappy tools?
I suppose he may not have a choice, but then wouldn't he still make the best of what he has? He wouldn't need to blame the tools (or anything else) if he succeeds.

And if there's no chance of succeeding despite his best efforts due to tools/resources/work conditions/etc., I think a good craftsman would see that beforehand and avoid a project he knows would fail. Otherwise, would you really call him a good craftsman, and if so, by what standard are you measuring to derive the term "good"?
Close, but the correct response is:

"No, a good craftsman uses the crappy tools he's dealt to build good ones, then moves the fuck on with my mom."

FTFY

2010-10-18 Reply Admin

boog:
Alan:
Jaime:
Alan:
In VB you also cannot call methods for bit shifting. XOR etc
Please do your research before posting. VB has both.
Library methods don't count.
Well done! Take a claim, then try to refute it using a straw man fallacy. It certainly is harder to [b]win an argument with someone who understands logic[b].

I believe that's what you meant to write above.

Max Peck · 2010-10-18 Reply Admin

No, it's NOT fair to say that VB has WAAY more than most. I've been at this for 35 years. I've seen bad code in a number of languages from C, to VB, to FORTRAN to Assembly (need I go on?).

OTOH, I can write clean, efficient well-designed code in ANY of the languages I use. I have a 100,000 line Rules Engine that was originally in C, then had to be converted to VB6 so it could be a COM component then into VB.Net. There are bad legacy sections in there and good code that I've more recently added as I became more proficient in OO design techniques.

I really have to laugh when everybody gets into these "my daddy can beat your daddy" kinds of discussions. It really brings out the "High School" in the community. Both VB.Net and C# are competent development tools. Yes, I now prefer C# for anything new I develop but 10+ years working with VB has not hurt my ability to craft good code, nor does VB help a bad coder to craft good code.

Heh ... keep arguing guys - it really makes a difference!

-Max

2010-10-18 Reply Admin

Miniature Pecker:
No, it's NOT fair to say that VB has WAAY more than most. I've been at this for 35 years. I've seen bad code in a number of languages from C, to VB, to FORTRAN to Assembly (need I go on?).
OTOH, I can write clean, efficient well-designed code in ANY of the languages I use. I have a 100,000 line Rules Engine that was originally in C, then had to be converted to VB6 so it could be a COM component then into VB.Net. There are bad legacy sections in there and good code that I've more recently added as I became more proficient in OO design techniques.

I really have to laugh when everybody gets into these "my daddy can beat your daddy" kinds of discussions. It really brings out the "High School" in the community. Both VB.Net and C# are competent development tools. Yes, I now prefer C# for anything new I develop but 10+ years working with VB has not hurt my ability to craft good code, nor does VB help a bad coder to craft good code.

Heh ... keep arguing guys - it really makes a difference!

-Max

Pragmatic programmers suck.

Sutherlands · 2010-10-18 Reply Admin

Max Peck:
... I have a 100,000 line Rules Engine that was originally in C, then had to be converted to VB6 so it could be a COM component ...

Wait, what??

2010-10-18 Reply Admin

The first step to recovery is admitting you have a problem.

toth · 2010-10-18 Reply Admin

Jaime:
I would argue that VB string comparison is better in many respects. String comparison in C# is faster, but VB implicity treats null strings as empty strings for comparison purposes. This is almost always what the programmer wants and has to be coded manually in C#. Also, VB does compare lengths first in its internal comparison routine, so it almost always executes very efficiently.

I will grant you that, most of the time, I find that

string.IsNullOrEmpty(str)

is what I want (rather than, say,

str == string.Empty

), but I strongly disagree that it's a good thing for a language to treat them as equal, because they're not. Conceptually, they're entirely different things, even if they often have a similar (or identical) meaning in a given context. I think it's far, far better to make your requirements explicit (i.e., this string can either be null or empty for this code path to run) than to say "Well, if the string is a null-ish kind of value then this code path will execute."

toth · 2010-10-18 Reply Admin

TRWTF is that VB.NET uses the same operator for equality tests and for assignment.

2010-10-18 Reply Admin

toth:
TRWTF is that VB.NET.

FTFY

boog · 2010-10-18 Reply Admin

Alan:
boog:
Alan:
Jaime:
Alan:
In VB you also cannot call methods for bit shifting. XOR etc
Please do your research before posting. VB has both.
Library methods don't count.
Well done! Take a claim, then try to refute it using a straw man fallacy. It certainly is harder to [b]win an argument with someone who understands logic[b].
I believe that's what you meant to write above.

No, I'm pretty sure I meant what I said the first time. That is, unless you can explain to me exactly how anyone used a straw man fallacy in this particular discussion (I suggest you re-read the definition of "straw man" carefully).

2010-10-18 Reply Admin

As usual, TDWTF comments contain more than enough WTF'ery to make up for the actual article. Keep 'em comin', folks!

2010-10-18 Reply Admin

boog:
Alan:
boog:
Alan:
Jaime:
Alan:
In VB you also cannot use build-in operators for bit shifting. XOR etc
Please do your research before posting. VB has both.
Library methods don't count.
Well done! Take a claim, then try to refute it using a straw man fallacy. It certainly is harder to [b]win an argument with someone who understands logic[b].
I believe that's what you meant to write above.
No, I'm pretty sure I meant what I said the first time. That is, unless you can explain to me exactly how anyone used a straw man fallacy in this particular discussion (I suggest you re-read the definition of "straw man" carefully).

Straw man: attacking the periphery of a statement and trying to make it look like it's the core of the argument. I did not state that it was impossible to do bit operations (as that would be ludicrous on any turing-complete system), only that VB makes it prohibitively difficult by not providing very basic features that are commonplace in almost every other language.

Jaime · 2010-10-18 Reply Admin

Alan:
boog:
Alan:
boog:
Alan:
Jaime:
Alan:
In VB you also cannot use build-in operators for bit shifting. XOR etc
Please do your research before posting. VB has both.
Library methods don't count.
Well done! Take a claim, then try to refute it using a straw man fallacy. It certainly is harder to [b]win an argument with someone who understands logic[b].
I believe that's what you meant to write above.
No, I'm pretty sure I meant what I said the first time. That is, unless you can explain to me exactly how anyone used a straw man fallacy in this particular discussion (I suggest you re-read the definition of "straw man" carefully).
Straw man: attacking the periphery of a statement and trying to make it look like it's the core of the argument. I did not state that it was impossible to do bit operations (as that would be ludicrous on any turing-complete system), only that VB makes it prohibitively difficult by not providing very basic features that are commonplace in almost every other language.

But you are wrong. This is legal VB:

x = 1234567 << 4

It means exactly the same thing in VB as it does in C#. Please explain how this is "prohibitively difficult".

2010-10-18 Reply Admin

Jaime:
Alan:
boog:
Alan:
boog:
Alan:
Jaime:
Alan:
In VB you also cannot use build-in operators for bit shifting. XOR etc
Please do your research before posting. VB has both.
Library methods don't count.
Well done! Take a claim, then try to refute it using a straw man fallacy. It certainly is harder to win an argument with someone who understands logic.
I believe that's what you meant to write above.
No, I'm pretty sure I meant what I said the first time. That is, unless you can explain to me exactly how anyone used a straw man fallacy in this particular discussion (I suggest you re-read the definition of "straw man" carefully).
Straw man: attacking the periphery of a statement and trying to make it look like it's the core of the argument. I did not state that it was impossible to do bit operations (as that would be ludicrous on any turing-complete system), only that VB makes it prohibitively difficult by not providing very basic features that are commonplace in almost every other language.
But you are wrong. This is legal VB:
x = 1234567 << 4

It means exactly the same thing in VB.Net as it does in C#. Please explain how this is "prohibitively difficult".

koff

Carry on.

boog · 2010-10-18 Reply Admin

Alan:
boog:
Alan:
boog:
Alan:
Jaime:
Alan:
In VB you also cannot use build-in operators for bit shifting. XOR etc
Please do your research before posting. VB has both.
Library methods don't count.
Well done! Take a claim, then try to refute it using a straw man fallacy. It certainly is harder to [b]win an argument with someone who understands logic[b].
I believe that's what you meant to write above.
No, I'm pretty sure I meant what I said the first time. That is, unless you can explain to me exactly how anyone used a straw man fallacy in this particular discussion (I suggest you re-read the definition of "straw man" carefully).
Straw man: attacking the periphery of a statement and trying to make it look like it's the core of the argument. I did not state that it was impossible to do bit operations (as that would be ludicrous on any turing-complete system), only that VB makes it prohibitively difficult by not providing very basic features that are commonplace in almost every other language.

Cute, but you actually said you cannot call methods for bit shifting, and no amount of misquoting yourself will change that.

If you originally misspoke, that's fine (we all do from time to time), but Jaime's response was hardly a straw man.

2010-10-18 Reply Admin

Jaime:
This is legal VB:
x = 1234567 << 4
It means exactly the same thing in VB as it does in C#. Please explain how this is "prohibitively difficult".

What if I don't want to set x to false? On most systems, this syntax will result in a compile-time error, as the chevron is actually an output operator. Now, if you were to write the following:

x = 1234567 <<4

x would be 1234567 / 16. Never the less, you have still failed to give an example of bitwise OR, XOR, etc (eg. |, ^, |=, &, &=).

2010-10-18 Reply Admin

Bert Glanstron:
Jaime:
This is legal VB:
x = 1234567 << 4
It means exactly the same thing in VB as it does in C#. Please explain how this is "prohibitively difficult".
What if I don't want to set x to false? On most systems, this syntax will result in a compile-time error, as the chevron is actually an output operator. Now, if you were to write the following:
x = 1234567 <<4
x would be 1234567 / 16. Never the less, you have still failed to give an example of bitwise OR, XOR, etc (eg. |, ^, |=, &, &=).

Why not use the built-in methods?

2010-10-18 Reply Admin

boog:
Alan:
Jaime:
This is legal VB:
x = 1234567 << 4
It means exactly the same thing in VB as it does in C#. Please explain how this is "prohibitively difficult".
What if I don't want to set x to false? On most systems, this syntax will result in a compile-time error, as the chevron is actually an output operator. Now, if you were to write the following:
x = 1234567 <<4
x would be 1234567 / 16. Never the less, you have still failed to give an example of bitwise OR, XOR, etc (eg. |, ^, |=, &, &=).
Why not use the built-in methods?

New to the party? I was talking about built-in operators. How does your foot taste?

Smitty · 2010-10-18 Reply Admin

toth:
TRWTF is that VB.NET uses the same operator for equality tests and for assignment.

+1

2010-10-18 Reply Admin

Alan:
boog:
Alan:
Jaime:
This is legal VB:
x = 1234567 << 4
It means exactly the same thing in VB as it does in C#. Please explain how this is "prohibitively difficult".
What if I don't want to set x to false? On most systems, this syntax will result in a compile-time error, as the chevron is actually an output operator. Now, if you were to write the following:
x = 1234567 <<4
x would be 1234567 / 16. Never the less, you have still failed to give an example of bitwise OR, XOR, etc (eg. |, ^, |=, &, &=).
Why not use the built-in methods?
New to the party? I was talking about built-in operators. How does your foot taste?

Boog's foot actually tastes very, very delicious.

2010-10-18 Reply Admin

1TBS:
Jay:
I'm no fan of VB (obligatory disclaimer), but all this talk about how proerties are dangerous because they can be abused ... Well, here's an exercise for the reader: Name a feature of any language, that cannot possibly be used in a way that creates a difficult-to-maintain program.
I recall the time an associate of mine wrote something like this in C++:
while (getMessage());
{
... process message ...
}
By eliding most of the code I've made the error obvious, but after she asked for my help, I think the two of us spent a couple of hours trying to figure out the problem.

Even as plain a feature as semi-colon can be abused.
Well, that wouldn't have happened with a reasonable brace style. Cue flamewar in 3, 2, 1 ...

<span style="color:"black";">I lub tacos! FUCK AKISMET!!!

2010-10-18 Reply Admin

MacHaggis:
My head just exploded, and the universe is about to as well

Fucking solipsists!

boog · 2010-10-18 Reply Admin

wint:
Jaime:
This is legal VB:
x = 1234567 << 4

It means exactly the same thing in VB.Net as it does in C#. Please explain how this is "prohibitively difficult".
koff

Carry on.

And now to turn the tables on Jaime: this is particularly funny after last week's comments on using "VB" as a generic name.

I actually don't know whether wint's correction is valid or not; I generally stay away from VB myself. Still funny though.

boog · 2010-10-18 Reply Admin

Alan:
boog (unregistered):
<snip>
New to the party? I was talking about built-in operators. How does your foot taste?

Please ignore the impostor.

Jaime · 2010-10-18 Reply Admin

toth:
Jaime:
I would argue that VB string comparison is better in many respects. String comparison in C# is faster, but VB implicity treats null strings as empty strings for comparison purposes. This is almost always what the programmer wants and has to be coded manually in C#. Also, VB does compare lengths first in its internal comparison routine, so it almost always executes very efficiently.

I will grant you that, most of the time, I find that
string.IsNullOrEmpty(str)
is what I want (rather than, say,
str == string.Empty
), but I strongly disagree that it's a good thing for a language to treat them as equal, because they're not. Conceptually, they're entirely different things, even if they often have a similar (or identical) meaning in a given context. I think it's far, far better to make your requirements explicit (i.e., this string can either be null or empty for this code path to run) than to say "Well, if the string is a null-ish kind of value then this code path will execute."

I would much rather have modern languages complete the transition of string to a value type and then use nullable types to reference null strings. The problem with the current implementation is that every string is nullable, not only the ones where it makes sense. If the concept of a null string went away, we would lose nothing in terms of representing information. Null strings are an artefact of their implementation, not an intentional design element.

I find that whenever I am handling data going to or coming from a database, I always need a different pattern for a string than I do for any other data type. For example, I can represent a nullable integer with int? (or Nullable(Of Integer) in VB), but when it comes to strings, I'm forced to null check the reference instead of using the HasValue property that works on everything else. All of my other nullables throw compiler errors when I accidentally forget to check for null, but strings wait until run time to throw an exception. Note: I just tried it in C# and I am very disappointed to report that C# does not throw a compiler error if you compare a nullable type without null guarding. However, it doesn't error. C# does behave more sanely than VB when using a nullable in an expression.

Jaime · 2010-10-18 Reply Admin

boog:
wint:
Jaime:
This is legal VB:
x = 1234567 << 4

It means exactly the same thing in VB.Net as it does in C#. Please explain how this is "prohibitively difficult".
koff

Carry on.
And now to turn the tables on Jaime: this is particularly funny after last week's comments on using "VB" as a generic name.

I actually don't know whether wint's correction is valid or not; I generally stay away from VB myself. Still funny though.

I'm not sure how this turns the tables on me. Last week I was of the opinion that VB meant every version of VB, including VB.Net. My posts today are consistent with last week's.

hoodaticus · 2010-10-18 Reply Admin

dan:
And of course, the average quality of developers for the language. For every good VB dev, there's a hell of a lot of bad ones. Why aren't there so many bad devs for C#?

Is that a joke? Finding really terrible C# code is a trivial exercise.

With the CLR underneath, this entire debate becomes like Dr. Seuss's tale of the Zooks and the Yooks, at war with each other over which side of the bread to butter. I code in whatever the shop I'm working at uses.

C# is easier to use for some things, like event hookups. But only marginally so. I also like how it has a default access modifier. And I also like how buttering the bottom part of the bread prevents butter from dripping on my hand on a hot day.

Addendum (2010-10-18 17:48): For examples of bad C# code, just randomly trawl codeproject or something.

2010-10-18 Reply Admin

[image]

Jaime · 2010-10-18 Reply Admin

Bert Glanstron:
Jaime:
This is legal VB:
x = 1234567 << 4
It means exactly the same thing in VB as it does in C#. Please explain how this is "prohibitively difficult".
What if I don't want to set x to false? On most systems, this syntax will result in a compile-time error, as the chevron is actually an output operator. Now, if you were to write the following:
x = 1234567 <<4
x would be 1234567 / 16. Never the less, you have still failed to give an example of bitwise OR, XOR, etc (eg. |, ^, |=, &, &=).

Are you actually saying that a language that causes a single innucous space to radically change the meaning of an expression is a good thing? At least C# has the good sense to compile my original variation as a bit shift.

x = 1234567 Xor 42 x = 1234567 And 42 x = 1234567 Or 42

These are all bitwise operations. In these cases, the standard operator isn't used in VB, but VB certainly does have an operator for them, and it is far from "prohibitively difficult".

boog · 2010-10-18 Reply Admin

Jaime:
boog:
And now to turn the tables on Jaime: this is particularly funny after last week's comments on using "VB" as a generic name.
I actually don't know whether wint's correction is valid or not; I generally stay away from VB myself. Still funny though.
I'm not sure how this turns the tables on me. Last week I was of the opinion that VB meant every version of VB, including VB.Net. My posts today are consistent with last week's.

I took what you said last week to be a gripe about VB being used as a generic term by opponents of VB6 to deliberately confuse others into thinking VB.Net. I took wint's correction (if it's valid) to mean that you were doing more-or-less the same (except promoting VB instead of mocking it). Perhaps I misunderstood.

As for "turning the tables", I jokingly meant I was switching sides of the argument.

2010-10-18 Reply Admin

Ahh good old "Visual Beginners All-Purpose Symbolic Instruction Code"

Its been awhile since i've held you tight in my bed... but i've found something new, nipple braces! and i just love nipples.

So i'll always remember you VB but farewell.

hoodaticus · 2010-10-18 Reply Admin

Smitty:
toth:
TRWTF is that VB.NET uses the same operator for equality tests and for assignment.
+1

And this is a problem because ????

2010-10-18 Reply Admin

Jaime:
boog:
wint:
Jaime:
This is legal VB:
x = 1234567 << 4

It means exactly the same thing in VB.Net as it does in C#. Please explain how this is "prohibitively difficult".
koff

Carry on.
And now to turn the tables on Jaime: this is particularly funny after last week's comments on using "VB" as a generic name.

I actually don't know whether wint's correction is valid or not; I generally stay away from VB myself. Still funny though.
I'm not sure how this turns the tables on me. Last week I was of the opinion that VB meant every version of VB, including VB.Net. My posts today are consistent with last week's.

Your current uncertainty is a large part of the problem. As it were.

Hell, as you were.

2010-10-18 Reply Admin

hoodaticus:
Smitty:
toth:
TRWTF is that VB.NET uses the same operator for equality tests and for assignment.
+1

And this is a problem because ????

What, I... sputter, because, you... fluster... I...! checks username.... oh. Hoodaticus, you magnificent bastard! You damn near caught me out, this time.

...this time.

McVaio · 2010-10-18 Reply Admin

What's wrong with variable variables?

2010-10-18 Reply Admin

Jeff:
If you can't whistle into a modem and get the remote mainframe to respond, tuck your dick back into your pants in shame.

I think I just found my new auto-sig!

2010-10-18 Reply Admin

If you write software long enough, you learn that a regular paycheck is more important than any language argument. If I get paid, I will write your applications in VB, C#, or BrainFck, and produce a decent, usable product. Before anybody gets too upset over this kind of attitude, remember what they say in the graveyard:

As I was, you are.
As I am, you shall be.

hoodaticus · 2010-10-18 Reply Admin

iToad:
If you write software long enough, you learn that a regular paycheck is more important than any language argument. If I get paid, I will write your applications in VB, C#, or Br*ainF*ck, and produce a decent, usable product. Before anybody gets too upset over this kind of attitude, remember what they say in the graveyard:

As I was, you are.

As I am, you shall be.

This.

boog · 2010-10-18 Reply Admin

iToad:
If you write software long enough, you learn that a regular paycheck is more important than any language argument. If I get paid, I will write your applications in VB, C#, or Br*ainF*ck, and produce a decent, usable product. Before anybody gets too upset over this kind of attitude, remember what they say in the graveyard:

As I was, you are.

As I am, you shall be.

Regular paychecks are important, but so is sanity (perceived or otherwise). Some customers have no idea which language you should use in a given situation. Have you ever tried to write a full-featured ERP in Br*ainF*ck?

Seriously though, arguments over which language is the best are pretty irrelevant, as you say. Certain languages are better suited for certain tasks than others. Personally, I like the idea of letting a project's design constraints drive the decision of which language to use, with personal preferences weighing in last. It's a shame it rarely works that way.

2010-10-18 Reply Admin

I don't get all the VB bashing. I generally program in C or C++, but I know Basic, Pascal, Fortran, VB, perl, python, etc. When I'm making a quick app for myself or for a specific task, and it needs a GUI, writing it in VB is infinitely quicker than trying to remember or look up how to do all the GUI crap in C. It really is just an issue of whether the programmer is good or not. The example here isn't really "bad" as far as the language is concerned, it's only bad because the thing being done isn't really a property, and so it should be a method instead. That's just a misuse of the language and not a failure of the language itself.

2010-10-18 Reply Admin

danixdefcon5:
I just know that someone's bound to 1-UP all of these comments and claim to have programmed on a PDP-11, or having used FORTRAN.

I've written an assembly program for the PDP-1 (and boy, does it have some weird instruction names). Granted, I did it this year...

2010-10-18 Reply Admin

STDP (wish there was an "edit post" feature here...)

Gunslinger:
When I'm making a quick app for myself or for a specific task, and it needs a GUI, writing it in VB is infinitely quicker than trying to remember or look up how to do all the GUI crap in C.

That's what C# is for.

Sutherlands · 2010-10-18 Reply Admin

Jaime:
I would much rather have modern languages complete the transition of string to a value type and then use nullable types to reference null strings.

And have strings copied on the stack every time you call a method with one as a parameter? No thank you, sir! (or madam!)

2010-10-18 Reply Admin

The Typinator:
STDP (wish there was an "edit post" feature here...)

There is, but of course only for registered users. It's only available for a short time, though. Normally it expires about five seconds after the post shows up (that's part of why I usually can't bother to log in).

2010-10-18 Reply Admin

I started writing software in 1966. I booted PDP-8s by toggling in the bootloader from front panel switches. I programmed a PDP-11 using an ASR-33, paper tape and TECO. I programmed FORTRAN using punched cards and green-bar paper on IBM, Univac, and CDC mainframes.

Back in 1983, I told everybody that if they knew COBOL and CICS, then they were set for life. Wrong...

2010-10-18 Reply Admin

Well, I've been using various versions of VB for ten years, and I've met a lot of professionals that use it. I also have to point out that, except for syntax and a few minor differences, VB.Net and C#.Net are identical. Also, some would argue that C# is a faster, more sane ripoff of Java.

Also, I would like to say that VB is not the only language I use. I also use C++, NASM, occationally C#, and if I feel treating myself to some pain, Java.

Visual Basic - The Rodney Dangerfield of programming languages.

Cad Delworth · 2010-10-18 Reply Admin

Bus Logic:
I don't understand why people would choose VB.NET over C#

Perhaps because MS insisted that VC was 'only necessary if you want to write system-level code like drivers, or commercial apps. like Office,' and so forth? Meaning that LOTS of programmers used some version of VB (or VBA), and only the clinically obsessed or very sad used VC.

Bus Logic:
why use a langauge like VB.NET that has some horrible behaviour and only just qualifies as an OO langauge at all, when you could use the clean and logical syntax of C#?

Well, I never understood why anyone thinks C syntax is more 'clean and logical' than VB syntax, based as it is on Pascal syntax, which is as clean and logical as a crack whore IMHO. I don't understand why any language needs a statement-end character, or lots of braces around everything.

Bus Logic:
VB.NET is kiddie code. Just because it compiles down to an intermediate code that can be produced by other langauges it doesn't mean that this particular langauge is any good.

I suppose you would make the same comment about APL.NET, or <anything-else-that-isn't-C#>.NET, wouldn't you?

Look, let's face it: .NET was MS's attempt to force every language to look and work more like C. That's why VB.NET source code always looks so 'verbose' compared to VB6, because you're forced to use this alien stuff like Includes, and lots of .To<sometype> statements to convert values into a different type, even if all you're doing is building a string for a message box.

So, you've already got your wish: with .NET, MS forced every language to jump through hoops and start looking nothing like itself, all to force every language to work as much as possible like your beloved C … so stop moaning about it, already!

2010-10-18 Reply Admin

I would indeed argue that Obj.DemoTimeOut = 60000 and X = Obj.DemoTimeOut is more elegant then "moderns" laguage construct where you use an ugly Obj.setDemoTimeOut(60000) or X = Obj.getDemoTimeOut()

2010-10-18 Reply Admin

Jay:
By eliding most of the code I've made the error obvious, but after she asked for my help, I think the two of us spent a couple of hours trying to figure out the problem.

What were you using that you didn't have breakpoints? One single breakpoint on the first line of the body of the "loop" would have located the problem.

Anyhow, VB.NET is not bad, but VB6 really is TRWTF. My favorite is array and collection indexing -- certain ones always index 0...N-1. Some always index 1...N. Some index either 0...N-1 or 1...N depending on the settings. And some allow the user to specify ANY starting index.

Property Basics

Leave a comment on “Property Basics”