The Daily WTF: Curious Perversions in Information Technology

2010-10-19 Reply Admin

TRWTF is Visual Basic

2010-10-19 Reply Admin

me:
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...
You see, this is exactly why VB must die. It encourages programmers to think ridiculous, nonsensical things like null should equal an empty string. I can't even begin to convey just how wrong this is, yet it's so familiar to VB devs that it's the norm to hear them make silly assertions like the one above.

I agree with this, and it's certainly a bad idea to build in null/empty equivalence into the language. However... I can't help but thinking how often I've written a method to return true if a String is null or empty. I can understand the impulse, wrong as it is.

2010-10-19 Reply Admin

wtf:
I can't help but thinking how often I've written a method to return true if a String is null or empty

string.IsNullOrEmpty(string value)

2010-10-19 Reply Admin

Matt Westwood:
Tuesday is Remy's responsibility, and there's a real good chance he's busy engaged in unimaginable homosexual activities.

Of which you are hoping being involved in?

CAPTCHA: letatio oh how appropriate!

2010-10-19 Reply Admin

TRWTF is that none of these two pieces of code compiles. Maybe you two should switch to VB..

hoodaticus · 2010-10-19 Reply Admin

me:
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...
You see, this is exactly why VB must die. It encourages programmers to think ridiculous, nonsensical things like null should equal an empty string. I can't even begin to convey just how wrong this is, yet it's so familiar to VB devs that it's the norm to hear them make silly assertions like the one above.

That's pretty funny. When I use VB, comparing Nothing to "" results in a null reference exception. And a database null casting to string throws an invalid cast exception.

2010-10-19 Reply Admin

zdux:
TRWTF is Visual Basic

Mindless, unoriginal, but absolutely true.

2010-10-19 Reply Admin

hoodaticus:
me:
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...
You see, this is exactly why VB must die. It encourages programmers to think ridiculous, nonsensical things like null should equal an empty string. I can't even begin to convey just how wrong this is, yet it's so familiar to VB devs that it's the norm to hear them make silly assertions like the one above.

That's pretty funny. When I use VB, comparing Nothing to "" results in a null reference exception. And a database null casting to string throws an invalid cast exception.

Really? I was going by Jaime's post but even if null and string.Empty aren't equal, I don't see why you would get a null ref exception. If you compare "" to null you should just get "false", since you are not calling any methods on the null object (the equality operator should handle null values to prevent any implicit method calls on the null object). I don't see how you'd get a null reference, unless you were explicitly calling Equals or ReferenceEquals on the null object.

2010-10-19 Reply Admin

Matt Westwood:
Cbuttius:
I would pay money if they would post an article every day.
Take it easy. Tuesday is Remy's responsibility, and there's a real good chance he's busy engaged in unimaginable homosexual activities.

I can imagine quite a lot...

2010-10-19 Reply Admin

McVaio:
What's wrong with variable variables?

In theory nothing, it's just syntactic sugar for reflection, however in practice it can lead to a lot of bad code.

2010-10-19 Reply Admin

Bus Logic:
English Man:
Mark:
Anonymous:
English Man:
Anonymous:
Awww, "beginner-targeted language" makes it sound so cute! Much better than "ungodly piece of crap" or "used exclusively by school children and bad CS students".
As for todays WTF, well, that's exactly what you get from an ungodly piece of crap that is used exlusively by school children and bad CS students.
It's entertaining when ignoramuses talk with such arrogance. Well done.
It's entertaining when VB coders talk with such clarity, instead of just screeching and flinging feces at each other like normal. Well done.
+1e100 for that retort
He's admitting to being a VB coder? Or he's admitting to screeching and flinging feces? Or he's complimenting me on my clarity? Hard to tell...
Surely as an "English Man" you should understand, you know, English. I understand exactly what he was saying and I thought it was a pretty sweet comeback as well.

I do understand English. But not his attempt at using it. If we deconstruct what he said, he's apparently claiming I'm a VB programmer and complimenting me. Since I never mentioned VB, I think we have to conclude he was so excited about trying to be a smart guy and re-use my sentence structure, that he forgot to type anything that could be considered coherent and just rambled a crap insult. It seems there is no beginning to his wit. If you think that makes a sweet comeback, more fool you.

Jaime · 2010-10-19 Reply Admin

me:
hoodaticus:
me:
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...
You see, this is exactly why VB must die. It encourages programmers to think ridiculous, nonsensical things like null should equal an empty string. I can't even begin to convey just how wrong this is, yet it's so familiar to VB devs that it's the norm to hear them make silly assertions like the one above.
That's pretty funny. When I use VB, comparing Nothing to "" results in a null reference exception. And a database null casting to string throws an invalid cast exception.
Really? I was going by Jaime's post but even if null and string.Empty aren't equal, I don't see why you would get a null ref exception. If you compare "" to null you should just get "false", since you are not calling any methods on the null object (the equality operator should handle null values to prevent any implicit method calls on the null object). I don't see how you'd get a null reference, unless you were explicitly calling Equals or ReferenceEquals on the null object.

I just tried it to make sure I wasn't going insane and comparing a null string reference to an empty string evaluates to true in VB.Net. Calling any property or method of a null string variable will throw an exception.

Strings have tons of syntactic sugar poured all over them, there certainly is no universal right or wrong answer to "Is a null string equivalent to an empty string". The answer to this question is defined in the langauge spec. Personally, I would like a language to handle strings in the most convenient manner possible rather than "getting closer to the metal". I really don't care if a string is really a pointer to a char array any more than I care whether my integers are stored big-endian or little-endian. I don't care if that pointer might be uninitialized or might point to an zero element array.

The right answer to me is to make a string a value type, initialize it to empty string, make assigning null to a string variable reset it to empty string (just like VB already does with other value types like int), and make it immutable so it can live as a reference on the stack. Of course, like every other value type, it can be declared as nullable. This would make for a very sane and consistent experience. Today, a string has a mixture of a reference and value type behaviors, depending on context. What I find strange is that many defend the current string behaviors, and the number one defense of those behaviors seems to be "that's how it's always been" or "that's the right way". Languages will never evolve if no-one ever proposes changes.

2010-10-19 Reply Admin

me:
hoodaticus:
me:
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...
You see, this is exactly why VB must die. It encourages programmers to think ridiculous, nonsensical things like null should equal an empty string. I can't even begin to convey just how wrong this is, yet it's so familiar to VB devs that it's the norm to hear them make silly assertions like the one above.

Null, String.Empty and Nothing are all different animals. They are not interchangeable, and may not behave the way you expect. FYI.

That's pretty funny. When I use VB, comparing Nothing to "" results in a null reference exception. And a database null casting to string throws an invalid cast exception.
Really? I was going by Jaime's post but even if null and string.Empty aren't equal, I don't see why you would get a null ref exception. If you compare "" to null you should just get "false", since you are not calling any methods on the null object (the equality operator should handle null values to prevent any implicit method calls on the null object). I don't see how you'd get a null reference, unless you were explicitly calling Equals or ReferenceEquals on the null object.

2010-10-19 Reply Admin

My comments on the last post evaporated...

What I wanted to say was that nothing, string.empty (which is equivilent to "") and System.DBNull.Value are all different animals. They are not interchangeable, and may not behave the way you expect. That doesn't mean wrong, only that it doesn't work the way you think it should. FYI.

danixdefcon5 · 2010-10-19 Reply Admin

Null and Empty strings mean different things. It isn't just a language thing, it's a computing thing. Programming languages are meant to bridge humans with computers at a low level; so programmers must be aware of the limitations of the computer (or VM) and be capable to do defensive coding.

Empty strings usually mean that no data was inputted; Null strings mean that something went wrong, or that the data didn't exist, these should be explicitly checked for. Dumbing down this is a bad idea.

danixdefcon5 · 2010-10-19 Reply Admin

Cad Delworth:
... insanely long rant against C ...

Want a non-C language? There was Foxpro. MS pushed VB because of all the QuickBASIC guys, who owe their 31337 sk33llz to their earlier Apple II/C64/MSX programming experience on BASIC. The end result is that there are now a boatload of developers coding in a language that was not meant to be used on real software, but to introduce non-techies to the wonderful world of programming. In fact, PASCAL did a better job in that matter, so much that "pseudocode" reads much like Pascal.

However, it does seem that C# is gaining traction to an extent; most .NET devs have either switched to C# or began with C# skipping VB entirely. The rest are either doing Java, PHP, or that other weird thing called Ruby. The mere fact that this thread has more VB-haters than VB-lovers shows this is the case.

Jaime · 2010-10-19 Reply Admin

danixdefcon5:
Null and Empty strings mean different things. It isn't just a language thing, it's a computing thing. Programming languages are meant to bridge humans with computers at a low level; so programmers must be aware of the limitations of the computer (or VM) and be capable to do defensive coding.
Empty strings usually mean that no data was inputted; Null strings mean that something went wrong, or that the data didn't exist, these should be explicitly checked for. Dumbing down this is a bad idea.

You are describing the current state of things, but you have given no reason why it should be this way. You describe the situation as if it is unavoidable, but it is. The fact that a string can be uninitialized is a rusty bit of the innards of the computer sticking out where it doesn't belong. C# and VB have a perfectly good way of representing null data without requiring a null reference (nullable types).

I am advocating choice -- the ability to make a non-nullable string where appropriate and a nullable string where appropriate. You are advocating that all strings under all circumstances should be nullable. Why would you be against this choice?

C# hides reference addresses, that would be a form of "dumbing down", is it a bad idea? Garbage collection, connection pooling, object-oriented programming, and just-in-time compilation are all forms of "dumbing down". I'm sure all of the C programmers out there would argue that all of these are bad ideas, but many well-respected people would also argue they are good ideas.

2010-10-20 Reply Admin

IsDemo(600000) = True

It is over nine thousaaand!

Severity One · 2010-10-20 Reply Admin

chrismcb:
Severity One:
You forgot two-byte signed integers that couldn't exceed 32767.
At least, Niklaus Wirth fixed that in Modula-2, which also had the cardinal type.

Which was an two-byte unsigned integer that couldn't exceed 65535.
WOW Niklaus made it so a two-byte signed integer could exceed 32767? That is quite an accomplishment.

I'm trying to see the flaw in my original comment, but not really managing. Perhaps I should have written ', which' instead of 'that' in the first and third sentences, but the point was to point out that two bytes is really not an awful lot if you want to denote, say, revenue of a company - even in the early seventies.

2010-10-20 Reply Admin

Joey:
You really should thank MS for vb. All Kids and beginners would use C#, Java or C++ instead. And if this happens, we are all doomed. xD

Oh, it is happening now. The big dragons of the consulting industry is sending people right out of school on a one week training in C# or Java and are them selling them as "experts", because they need every person they can find to fulfill their contracts.

In a decade, the same flames directed against VB now will be directed against C#.

Severity One · 2010-10-20 Reply Admin

Elric:
Severity One:
Anonymous:
Awww, "beginner-targeted language" makes it sound so cute!
Pretty much like Pascal, and like Pascal, in its original incarnation totally unsuitable to write real software.

Define "real software". You are probably right that in most cases it is unsuitable for shrink wrapped or "enterprise grade" software. But "real software" is more than that IMO.

VB has its limitations but it is useful for the casual "programmer" who wants to build something for themselves or say a small community of users.

Also small/medium businesses use applications built in VB and other such tools. They have low upfront costs in general compared to much larger more "robust, extensible, portable etc" solutions.

Anyway some of you can sneer away - I am sure it makes you look more attractive to chicks if you dis VB in front of them!

Please be careful what you remove from a quote: I was talking about BASIC in its original incarnation, not the juggernaut called Visual Basic.

Original BASIC lets you do PRINT and INPUT statements, GOTO, GOSUB and RETURN, and some simple arithmetic and string manipulation. And that's more or less it.

Which is fine if you write Dijkstra-like programs, but not for real software: software that actually does something useful.

Severity One · 2010-10-20 Reply Admin

wtf:
Severity One:
... if all you have are getter and setter methods that, well, get or set the value, you might as well make the property public.
Well, you don't want to just throw getters and setters on everything, but it's substantially better to have some control on the distribution and setting of information than to simply make it public. A setter, for example, can validate the new value and inform the classes concerned when a value is changed, which can't happen if you simply make the field public and let anyone change it at whim, and a getter can be used check a value before returning it, if that is a concern.
However, it's much better, in my view, to inflict changes on objects as actions taken on them than to allow classes to set their values freely. Getters pose less potential harm, I suppose, but they do betray a failure of design: why does class B need class A's data? Why can't class A do its own work?

My point is that, all too often, you see a class that basically holds data and doesn't do anything itself, with all fields private and a getter and setter method for each field, which doesn't actually do anything other than getting or setting the value.

For example, if you have a web service that returns a complex set of data, you would use such an object.

In such a case, and also because JAX-WS/JAXB requires that you have a no-argument constructor, the accessor methods become a bit useless.

Yes, you can use them for 'future compatibility', but with web services, where an object returned via SOAP cannot have any logic in it, there is no point in creating the accessor methods. It just makes the code longer and less legible.

In a proper non-web service API it's different of course, and you'd want to provide read-only access to certain fields.

2010-10-20 Reply Admin

TRWTF is six pages of squabbling about VB AGAIN!!!

2010-10-20 Reply Admin

Larry David Jr:
TRWTF is six pages of squabbling about VB AGAIN!!!

Squabbling? I don't know what you're talking about, a clear 80% of people here hate VB and the other 20% are school kids. It almost sounds like a concensus to me.

hoodaticus · 2010-10-20 Reply Admin

@Jamie

Yeah, that was my dumbass about the null string reference. I forgot the basic fact that operators are static members of the class.

I owe you one! I was quite likely to use null string references to discriminate between empty strings at some point!

Thank you.

hoodaticus · 2010-10-20 Reply Admin

Severity One:
... but with web services, where an object returned via SOAP cannot have any logic in it, there is no point in creating the accessor methods. It just makes the code longer and less legible.
In a proper non-web service API it's different of course, and you'd want to provide read-only access to certain fields.

Good point; just keep in mind you can't databind to non-property fields of a class.

2010-10-20 Reply Admin

hoodaticus:
me:
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...
You see, this is exactly why VB must die. It encourages programmers to think ridiculous, nonsensical things like null should equal an empty string. I can't even begin to convey just how wrong this is, yet it's so familiar to VB devs that it's the norm to hear them make silly assertions like the one above.

That's pretty funny. When I use VB, comparing Nothing to "" results in a null reference exception. And a database null casting to string throws an invalid cast exception.

Your DBMS of choice isn't Oracle, I take it.

2010-10-20 Reply Admin

toth:
Larry David Jr:
Here's a challenge for you all then. Give a piece of code which is 'better' in C# than in VB (.NET).
Go.

C#
List<string> myList = new List<string> { "Hi", "there", "I'm", "a", "list" };
VB.NET
Dim myList As List(Of String) = New List(Of String)(New String() { "Hi", "there", "I'm", "a", "list" })
Or, even worse:
Dim myList As List(Of String) = New List(Of String)()
myList.AddRange(New String()  { "Hi", "there", "I'm", "a", "list" })
Oh, and while I'm at it, any code that uses a method with an empty parameter list, considering VB.NET makes parens optional in such cases (I refuse to leave them off in my own VB.NET code, but unfortunately, others are not as considerate).

P.S.: No citing .NET 4.0. I'm not able to use it yet.

how about

Dim list = (New String() {"Hi", "there", "I'm", "a", "list"}).ToList

2010-10-20 Reply Admin

Sorry I missed this originally. How is this 'better' par se? I admit I haven't the time right now to compile both and compare the IL so I don't know if that;s where I'll see a difference ....

2010-10-20 Reply Admin

toth:
Larry David Jr:
Here's a challenge for you all then. Give a piece of code which is 'better' in C# than in VB (.NET).
Go.

C#
List<string> myList = new List<string> { "Hi", "there", "I'm", "a", "list" };
VB.NET
Dim myList As List(Of String) = New List(Of String)(New String() { "Hi", "there", "I'm", "a", "list" })
Or, even worse:
Dim myList As List(Of String) = New List(Of String)()
myList.AddRange(New String()  { "Hi", "there", "I'm", "a", "list" })
Oh, and while I'm at it, any code that uses a method with an empty parameter list, considering VB.NET makes parens optional in such cases (I refuse to leave them off in my own VB.NET code, but unfortunately, others are not as considerate).

P.S.: No citing .NET 4.0. I'm not able to use it yet.

[pea-roast as I forgot to quote]

Sorry I missed this originally. How is this 'better' par se? I admit I haven't the time right now to compile both and compare the IL so I don't know if that;s where I'll see a difference ....

2010-10-20 Reply Admin

Cat:
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.

No, we just saw that it fell out of the loop after only one iteration, and scratched our heads trying to figure out why getMessage retuned false the second time it was called, or what else was terminating the loop. Yes, if we'd been thinking clearly we would have noticed that it never called getMessage a second time. But if we were thinking clearly we would have noticed the extra semi-colon. I'm sure a large percentage of bugs are of the "man, that was stupid!" variety. Including my own, of course.

2010-10-20 Reply Admin

The MAZZTer:
The key is knowing when to use a property and when to use a function instead.
In this case, it was not a proper time for a property...

Of course if it had been more like this:

Obj.DemoTimeOut = 60000 ' Starts timer at 1 minute Obj.DemoTimeOut = -1 ' Stops timer.

It works a bit better, but properties generally shouldn't do anything except get/set some sort of ... property, or setting. Firing off a timer is not something i would expect a property to do. Something like this would be more expected:

Obj.DemoTimeOut = 60000 Obj.StartDemo()

That's kind of what makes properties TRWTF. When you do X.Y = 10, you expect you're doing a simple variable assignment. But thanks to properties, you no longer have any clue as to what's going on when you write that simple code. At least with X.setY(10), you know just by reading the code that you're calling a function, and that there's the possibility it's doing something more than assigning a value.

toth · 2010-10-20 Reply Admin

Larry David Jr:
toth:
Larry David Jr:
Here's a challenge for you all then. Give a piece of code which is 'better' in C# than in VB (.NET).
Go.

C#
List<string> myList = new List<string> { "Hi", "there", "I'm", "a", "list" };
VB.NET
Dim myList As List(Of String) = New List(Of String)(New String() { "Hi", "there", "I'm", "a", "list" })
Or, even worse:
Dim myList As List(Of String) = New List(Of String)()
myList.AddRange(New String()  { "Hi", "there", "I'm", "a", "list" })
Oh, and while I'm at it, any code that uses a method with an empty parameter list, considering VB.NET makes parens optional in such cases (I refuse to leave them off in my own VB.NET code, but unfortunately, others are not as considerate).

P.S.: No citing .NET 4.0. I'm not able to use it yet.
[pea-roast as I forgot to quote]

Sorry I missed this originally. How is this 'better' par se? I admit I haven't the time right now to compile both and compare the IL so I don't know if that;s where I'll see a difference ....

I'm not talking about performance. I'm talking about syntax. Sure, there are ways to initialize lists (although, as far as I know, not dictionaries), but they're all things like passing a new array instance to the constructor (or, as someone mentioned above, ToList(), which seems to be pretty much just as bad). If I want to initialize a collection, I should be able to without resorting to workarounds like that. To me, at any rate, new CollectionObject {initial values} is much more readable (and may or may not be more efficient).

2010-10-20 Reply Admin

Severity One:
chrismcb:
Severity One:
You forgot two-byte signed integers that couldn't exceed 32767.
At least, Niklaus Wirth fixed that in Modula-2, which also had the cardinal type.

Which was an two-byte unsigned integer that couldn't exceed 65535.
WOW Niklaus made it so a two-byte signed integer could exceed 32767? That is quite an accomplishment.
I'm trying to see the flaw in my original comment, but not really managing. Perhaps I should have written ', which' instead of 'that' in the first and third sentences, but the point was to point out that two bytes is really not an awful lot if you want to denote, say, revenue of a company - even in the early seventies.

The flaw in your original argument is that you claim that the low maximum amount of a two-byte signed integer was fixed by the addition of a two-byte unsigned integer type with a higher maximum. Throwing out the negative side isn't 'fixing' the existing signed integer type at all.

Severity One · 2010-10-21 Reply Admin

Anone:
The flaw in your original argument is that you claim that the low maximum amount of a two-byte signed integer was fixed by the addition of a two-byte unsigned integer type with a higher maximum. Throwing out the negative side isn't 'fixing' the existing signed integer type at all.

Maybe next time I should specifically mention the use of sarcasm, for those who are not so quick on the pick-up?

In other words, you're making a fool of yourself.

2010-10-21 Reply Admin

toth:
Larry David Jr:
toth:
Larry David Jr:
Here's a challenge for you all then. Give a piece of code which is 'better' in C# than in VB (.NET).
Go.

C#
List<string> myList = new List<string> { "Hi", "there", "I'm", "a", "list" };
VB.NET
Dim myList As List(Of String) = New List(Of String)(New String() { "Hi", "there", "I'm", "a", "list" })
Or, even worse:
Dim myList As List(Of String) = New List(Of String)()
myList.AddRange(New String()  { "Hi", "there", "I'm", "a", "list" })
Oh, and while I'm at it, any code that uses a method with an empty parameter list, considering VB.NET makes parens optional in such cases (I refuse to leave them off in my own VB.NET code, but unfortunately, others are not as considerate).

P.S.: No citing .NET 4.0. I'm not able to use it yet.
[pea-roast as I forgot to quote]

Sorry I missed this originally. How is this 'better' par se? I admit I haven't the time right now to compile both and compare the IL so I don't know if that;s where I'll see a difference ....
I'm not talking about performance. I'm talking about syntax. Sure, there are ways to initialize lists (although, as far as I know, not dictionaries), but they're all things like passing a new array instance to the constructor (or, as someone mentioned above, ToList(), which seems to be pretty much just as bad). If I want to initialize a collection, I should be able to without resorting to workarounds like that. To me, at any rate, new CollectionObject {initial values} is much more readable (and may or may not be more efficient).

OK well, syntax I don't think can really be regarded as 'better' or 'worse', its more of a personal preference, but that's just my opinion. What really matters IMO is what it gets compiled to, and how well that code performs.

You could argue that certain syntaxes encourage people to do things in less effective or efficient ways I suppose, but that's not really the matter I was trying to encourage some perspective on :)

2010-10-21 Reply Admin

Rereading your original quote I have to agree with what you said.

Apologies for the misquote.

2010-10-21 Reply Admin

Severity One:
Elric:
Severity One:
Anonymous:
Awww, "beginner-targeted language" makes it sound so cute!
Pretty much like Pascal, and like Pascal, in its original incarnation totally unsuitable to write real software.

Define "real software". You are probably right that in most cases it is unsuitable for shrink wrapped or "enterprise grade" software. But "real software" is more than that IMO.

VB has its limitations but it is useful for the casual "programmer" who wants to build something for themselves or say a small community of users.

Also small/medium businesses use applications built in VB and other such tools. They have low upfront costs in general compared to much larger more "robust, extensible, portable etc" solutions.

Anyway some of you can sneer away - I am sure it makes you look more attractive to chicks if you dis VB in front of them!
Please be careful what you remove from a quote: I was talking about BASIC in its original incarnation, not the juggernaut called Visual Basic.

Original BASIC lets you do PRINT and INPUT statements, GOTO, GOSUB and RETURN, and some simple arithmetic and string manipulation. And that's more or less it.

Which is fine if you write Dijkstra-like programs, but not for real software: software that actually does something useful.

Rereading your OP I have to agree with you re BASIC.

Apologies for the misquote.

2010-10-21 Reply Admin

Larry David Jr:
Here's a challenge for you all then. Give a piece of code which is 'better' in C# than in VB (.NET).
Go.

Err um hurr? The answer is "C# properties don't take other arguments", right? Or is this a trick question?

2010-10-21 Reply Admin

Lord almighty, not another of these pissing contests?

I've programmed in pretty much any language you can think of at some point - C, C#, C++, PROLOG at uni - which I actually liked, Ada and SMALLTALK, proprietary ones that would make some of you young folks cack it, Delphi / Pascal, Assembly etc, even the monstrosity that was VB for DOS, and I prefer VB.NET to C#, sorry. I like it more verbose = more explicit, to me.

String comparisons stupid in VB? Don't make me laugh - when was that ever a bottleneck in any serious application.

C# does have some kind of late binding with variants. I do appreciate strong typing which is fully possible in VB - and can be overridden on a per file basis if needed, but it has never stopped any of the really serious shooting self in foot incidents that are possible.

If you are seriously saying it is possible to do interop with Excel or Word with C#, it is - just very stupid. Just write a shim library in VB to handle it - like I do with C# if VB stops short - which is pretty rare.

I've seen godawful code in many forms - VB most commonly, because it has been written by someone who has moved over from VBA. Means nothing. If C had that kind of base then it would have been corrupted the same.

Yes, I am pragmatic but I have always got my projects in on time, had fun doing them and been paid - that is all really

2010-10-21 Reply Admin

callcopse:
If you are seriously saying it is possible to do interop with Excel or Word with C#, it is - just very stupid.

C# supports optional parameters now so there is no need to supply 50 odd "Type.Missing" objects to fill in the parameters you don't care about. However, even before optional parameters were supported, I still used C# over VB and would just supply the 50 odd Type.Missing parameters. Our flagship app uses Office interop a lot but that didn't stop me from banning our devs from using VB.NET and I have no intention of ever allowing it. Supplying a bunch of superfluous parameters in C# is far better than the alternative of dirtying ourselves with VB.

2010-10-21 Reply Admin

Are you sure? I am certain I can come up with a couple of things that are only possible in C#. One of them is Extension Methods.

frits · 2010-10-21 Reply Admin

Mr Tired:
Are you sure? I am certain I can come up with a couple of things that are only possible in C#. One of them is Extension Methods.

?

http://msdn.microsoft.com/en-us/library/bb384936.aspx.

2010-10-21 Reply Admin

Spivonious:
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.

Kiddie code? There is nothing you can do in C# that I can't do in VB. It all comes down to whether you prefer the verbosity of VB or the conciseness of C#.

Yes, yes there is http://msdn.microsoft.com/en-us/library/aa288474(VS.71).aspx

And also VB has a checkbox "Hide Advanced Members" checked by default... C# does not have this checkbox...hmmm

SEMI-HYBRID code · 2010-10-21 Reply Admin

TRWTF in this case is definately the trackback link - the linking article seems to list this entry as a serious vb property how-to...

2010-10-22 Reply Admin

callcopse:
Lord almighty, not another of these pissing contests?
I've programmed in pretty much any language you can think of at some point - C, C#, C++, PROLOG at uni - which I actually liked, Ada and SMALLTALK, proprietary ones that would make some of you young folks cack it, Delphi / Pascal, Assembly etc, even the monstrosity that was VB for DOS, and I prefer VB.NET to C#, sorry. I like it more verbose = more explicit, to me.

String comparisons stupid in VB? Don't make me laugh - when was that ever a bottleneck in any serious application.

C# does have some kind of late binding with variants. I do appreciate strong typing which is fully possible in VB - and can be overridden on a per file basis if needed, but it has never stopped any of the really serious shooting self in foot incidents that are possible.

If you are seriously saying it is possible to do interop with Excel or Word with C#, it is - just very stupid. Just write a shim library in VB to handle it - like I do with C# if VB stops short - which is pretty rare.

I've seen godawful code in many forms - VB most commonly, because it has been written by someone who has moved over from VBA. Means nothing. If C had that kind of base then it would have been corrupted the same.

Yes, I am pragmatic but I have always got my projects in on time, had fun doing them and been paid - that is all really

<shakes head at squawking, snobby noobs>

+1 for 'pissing contests'

2010-10-22 Reply Admin

Anonymous:
callcopse:
If you are seriously saying it is possible to do interop with Excel or Word with C#, it is - just very stupid.
C# supports optional parameters now so there is no need to supply 50 odd "Type.Missing" objects to fill in the parameters you don't care about. However, even before optional parameters were supported, I still used C# over VB and would just supply the 50 odd Type.Missing parameters. Our flagship app uses Office interop a lot but that didn't stop me from banning our devs from using VB.NET and I have no intention of ever allowing it. Supplying a bunch of superfluous parameters in C# is far better than the alternative of dirtying ourselves with VB.

Dear Sir or madam, I am glad c# can do the optional parameter thing - I had not spotted that. My central point remains - by all means avoid use of VB.NET. By all means order your underlings to avoid such usage in a power crazed fit of rank pulling. Just drop the supercilious attitude. Unless you wish to correctly be viewed as a bit of a twunt.

2010-10-23 Reply Admin

Buffled:
When you do X.Y = 10, you expect you're doing a simple variable assignment.

Not true. If the location of X.Y happens to have been swapped to disk, it will trigger a page fault, which can invoke an arbitrary amount of code, discarding disposable memory, swapping old memory to disk, displaying a low-memory pop-up balloon, and swapping the memory from the pagefile back into main memory. Not realising this can cause horrible performance, as Raymond Chen once famously pointed out. Plus, the fact remains that even if you want X.Y = 5, there may come a point at which you decide you want X.setY(5). In some cases you may want this only for profiling or debugging purposes, but sometimes circumstances have changed. Turns out you want to log when certain values change, or that an action needs to be taken to keep values consistent with each other. This is why in languages like Java you are always forced to make all your fields private and write accessors for them, even if the implementation is completely boiler-plate. Properties solve that problem, and do so elegantly, as well as allowing you to document that certain methods (for example to change a window title) have property-like characteristics.

2010-10-24 Reply Admin

Reading code: C# problems:

When you see a } you don't know if it's ending a function, a property, an if, a switch...

That's harder to read.

Since you read from left to right, when you see a line starting: [type] [identifier] (as in "int foo...") you have to read the entire line to know if it's a function or a variable. (Today C# is approaching VB. Now you have "var" in C#)

switch+break statement vs select case: Switch it's an old prehistoric dinosaur. When C was compiled to assembler, "switch/break" makes sense (if you know what a conditinal jmp is, you'll understand) But today it's a very bad tool, at least compared to VB select case.

Quit the "VB is for kids!" nonsense. You're revealing yourself as an ignorant. c# programmers are not c programmers. if you don't what char **p; means: you're in the managed NET league, where c# and VB.NET are almost the same thing: just "flavors" over MSIL+NET. In this regard, VB is a more powerful tool.

Jaime · 2010-10-24 Reply Admin

Buffled:
The MAZZTer:
The key is knowing when to use a property and when to use a function instead.
In this case, it was not a proper time for a property...

Of course if it had been more like this:

Obj.DemoTimeOut = 60000 ' Starts timer at 1 minute Obj.DemoTimeOut = -1 ' Stops timer.

It works a bit better, but properties generally shouldn't do anything except get/set some sort of ... property, or setting. Firing off a timer is not something i would expect a property to do. Something like this would be more expected:

Obj.DemoTimeOut = 60000 Obj.StartDemo()
That's kind of what makes properties TRWTF. When you do X.Y = 10, you expect you're doing a simple variable assignment. But thanks to properties, you no longer have any clue as to what's going on when you write that simple code. At least with X.setY(10), you know just by reading the code that you're calling a function, and that there's the possibility it's doing something more than assigning a value.

You're not supposed to have a clue. If you change a form's title bar text with a property, you don't care if it writes directly to memory, or mails a certified letter to Bill Gates, as long as it works (and as long as the implementation is as efficient as possible, but that's not your responsibity, it's the developer of the class's responsibility). Object oriented programming allows you to break tasks up into pieces and think about chunks of the application abstractly. As I once told a coworker of mine - "If you insist on knowing every implementation detail of everything your code does, then you will never work on a project larger than can fit into your head at one time."

Property Basics

Leave a comment on “Property Basics”