Why C# Is not a "Better" Language Than VB.NET
-
Paul Selormey wrote: Simple! because there are many who can hardly work with non-C/C++ syntax language. ROTFL - that's pretty funny. So you're saying that the VB programmers are barely able to work as it stands, if you add some semicolons and mathematical symbols, they are lost ? Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
No, what he says is the exact opposite: that us, poor C/C++/C# guys are not able to come to terms with the begin/end thingy And he's partially right. But it's not lack of technical skills or low IQ, it's just the fact that the VB syntax is sooo convoluted and illogical that we avoid it whenever we can (which is not nearly often enogh :-) ) OGR
-
No, what he says is the exact opposite: that us, poor C/C++/C# guys are not able to come to terms with the begin/end thingy And he's partially right. But it's not lack of technical skills or low IQ, it's just the fact that the VB syntax is sooo convoluted and illogical that we avoid it whenever we can (which is not nearly often enogh :-) ) OGR
ogrig wrote: No, what he says is the exact opposite: Yeah, I know :-) I was pointing out that it's the VB guys who have the problem. We can read English, it's just not an efficient way to design a language. They are the ones unable to learn what a bunch of symbols mean. ogrig wrote: VB syntax is sooo convoluted and illogical And a double AMEN to that. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
-
No, what he says is the exact opposite: that us, poor C/C++/C# guys are not able to come to terms with the begin/end thingy And he's partially right. But it's not lack of technical skills or low IQ, it's just the fact that the VB syntax is sooo convoluted and illogical that we avoid it whenever we can (which is not nearly often enogh :-) ) OGR
FWIW, i've been using BASIC-derived languages far longer than i've been using C-derived languages. While i find C syntax easier to scan quickly, i can code comfortably in both (provided i'm using a good editor). That said, VBScript is the only BASIC-syntax language that isn't a waste of time on Windows. And in truth, it's really a stretch to call the syntax BASIC-derived.
Shog9
I'm not the Jack of Diamonds... I'm not the six of spades. I don't know what you thought; I'm not your astronaut...
-
No, what he says is the exact opposite: that us, poor C/C++/C# guys are not able to come to terms with the begin/end thingy And he's partially right. But it's not lack of technical skills or low IQ, it's just the fact that the VB syntax is sooo convoluted and illogical that we avoid it whenever we can (which is not nearly often enogh :-) ) OGR
ogrig wrote: No, what he says is the exact opposite: that us, poor C/C++/C# guys are not able to come to terms with the begin/end thingy But accept
<begin> Say XML! </begin>
and its related friends. Best regards, Paul. Jesus Christ is LOVE! Please tell somebody.
-
FWIW, i've been using BASIC-derived languages far longer than i've been using C-derived languages. While i find C syntax easier to scan quickly, i can code comfortably in both (provided i'm using a good editor). That said, VBScript is the only BASIC-syntax language that isn't a waste of time on Windows. And in truth, it's really a stretch to call the syntax BASIC-derived.
Shog9
I'm not the Jack of Diamonds... I'm not the six of spades. I don't know what you thought; I'm not your astronaut...
Yeah, and FORTRAN/Fortran gave me my degrees. Best regards, Paul. Jesus Christ is LOVE! Please tell somebody.
-
ogrig wrote: No, what he says is the exact opposite: that us, poor C/C++/C# guys are not able to come to terms with the begin/end thingy But accept
<begin> Say XML! </begin>
and its related friends. Best regards, Paul. Jesus Christ is LOVE! Please tell somebody.
To be honest, I think XML is overrated because it's so verbose, but for some applications, it's brilliant. begin/end is annoying, but it's pretty much bottom of my list of VB complaints. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
-
FWIW, i've been using BASIC-derived languages far longer than i've been using C-derived languages. While i find C syntax easier to scan quickly, i can code comfortably in both (provided i'm using a good editor). That said, VBScript is the only BASIC-syntax language that isn't a waste of time on Windows. And in truth, it's really a stretch to call the syntax BASIC-derived.
Shog9
I'm not the Jack of Diamonds... I'm not the six of spades. I don't know what you thought; I'm not your astronaut...
Shog9 wrote: FWIW, i've been using BASIC-derived languages far longer than i've been using C-derived languages. Yeah, me too. I learned programming in BASIC in the early eighties, and I taught myself C++ in 1999. Shog9 wrote: While i find C syntax easier to scan quickly, i can code comfortably in both (provided i'm using a good editor). Agreed - I've done ASP.NET sites in VB.NET, and a few other things. It's not that it's hard. Shog9 wrote: That said, VBScript is the only BASIC-syntax language that isn't a waste of time on Windows. ROTFL - that gets my 5 !!! Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
-
That's too funny. From the article : Perl.NET can do things that C# cannot. Does that make Perl.NET a better language than C#? No. It just makes it a better choice in some cases. If you need to use unsafe mode, you need C#. You cannot overload operators in VB.NET. You might find VB.NET's late binding feature more convenient than using the reflection API in C#. You might like background compilation in VB.NET. It is is possible, that for certain features the IL that C# generates is more efficient than the IL that VB.NET does Things to note: 1/ He lists several things that C# can do that VB.NET cannot. 2/ He lists some things that the two languages do differently and suggests that some might prefer the VB way ( fair enough, but C# still does things VB.NET cannot ) 3/ He has to reach for PERL (!!!) to make a point about languages that can do things C# cannot ( further implying that VB.NET cannot do anything that C# cannot ). Perl is a very different language to C#. VB.NET really isn't, except for the baggage it carries from VB6. As far as I'm concerned, C# is a better language because the authors had a fresh slate to create a language from. C++ suffers at times from comprimises made to keep as much C compatibility as possible, a decision that was made because at the time, C compatibility was paramount for the language to survive. VB.NET suffers from the same sickness, and right next door is a shiny new language, without all the problems. If VB.NET and C# are equal, why did Microsoft need to create C# ? The answer is that there are so many truly terrible VB hackers out there that the name of VB is beyond redemption, no matter how good the language they tie it to. Managers love VB, because they reckognise that 'anyone' can use it. Most jobs I go for, the first thing I have to do is steer them away from the idea that VB will give them easy code that anyone can maintain for them. As I said the other day in the soapbox, there are two groups of Windows coders, those who asked 'what's the best language', and those who asked 'what's the easiest'. Those who asked the first question took up C++, and may have moved to C#. Those who asked the second are lobbying for VB6 support from Microsoft, because they're scared to learn something new, or begrudgingly moving to VB.NET or ( if they know how to code ) are moving to C#. At least, that's what my experience leads me to believe. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weir
Christian Graus wrote: further implying that VB.NET cannot do anything that C# cannot Well, VB.NET can do at least one thing that C# cannot - design-time event handling. In C#, you have to subscribe to an event at runtime (whether its hidden by the designer or you do it by hand, that's still what happens). In VB.NET, you can use the "Handles" keyword after a method definition to indicate that it handles a particular event on a particular object. There's no way to duplicate that behaviour in C#. There may very well be other things - I haven't really looked into it in detail.
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
-
Christian Graus wrote: further implying that VB.NET cannot do anything that C# cannot Well, VB.NET can do at least one thing that C# cannot - design-time event handling. In C#, you have to subscribe to an event at runtime (whether its hidden by the designer or you do it by hand, that's still what happens). In VB.NET, you can use the "Handles" keyword after a method definition to indicate that it handles a particular event on a particular object. There's no way to duplicate that behaviour in C#. There may very well be other things - I haven't really looked into it in detail.
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
This is one of the things that the guy mentioned in terms of doing the same thing differently. How do events occur/get handled at design time ? The syntax is different, but how does the behaviour differ ? ( FWIW, I like the VB syntax here, but I don't see how it's more than syntactic sugar ) Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
-
That's too funny. From the article : Perl.NET can do things that C# cannot. Does that make Perl.NET a better language than C#? No. It just makes it a better choice in some cases. If you need to use unsafe mode, you need C#. You cannot overload operators in VB.NET. You might find VB.NET's late binding feature more convenient than using the reflection API in C#. You might like background compilation in VB.NET. It is is possible, that for certain features the IL that C# generates is more efficient than the IL that VB.NET does Things to note: 1/ He lists several things that C# can do that VB.NET cannot. 2/ He lists some things that the two languages do differently and suggests that some might prefer the VB way ( fair enough, but C# still does things VB.NET cannot ) 3/ He has to reach for PERL (!!!) to make a point about languages that can do things C# cannot ( further implying that VB.NET cannot do anything that C# cannot ). Perl is a very different language to C#. VB.NET really isn't, except for the baggage it carries from VB6. As far as I'm concerned, C# is a better language because the authors had a fresh slate to create a language from. C++ suffers at times from comprimises made to keep as much C compatibility as possible, a decision that was made because at the time, C compatibility was paramount for the language to survive. VB.NET suffers from the same sickness, and right next door is a shiny new language, without all the problems. If VB.NET and C# are equal, why did Microsoft need to create C# ? The answer is that there are so many truly terrible VB hackers out there that the name of VB is beyond redemption, no matter how good the language they tie it to. Managers love VB, because they reckognise that 'anyone' can use it. Most jobs I go for, the first thing I have to do is steer them away from the idea that VB will give them easy code that anyone can maintain for them. As I said the other day in the soapbox, there are two groups of Windows coders, those who asked 'what's the best language', and those who asked 'what's the easiest'. Those who asked the first question took up C++, and may have moved to C#. Those who asked the second are lobbying for VB6 support from Microsoft, because they're scared to learn something new, or begrudgingly moving to VB.NET or ( if they know how to code ) are moving to C#. At least, that's what my experience leads me to believe. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weir
Christian Graus wrote: why did Microsoft need to create C# Marketing and because they were pissed at Sun. There is absolutely NO reason that many of the issues with C/C++ would not have been properly fixed, and then made "toggleable" with compiler switches to turn off the MS specific parts. For example, there is no reason that I can see that adding a simple property to arrays so that it's current length can be properly determined could not have been added. Nor is there any reason a new, real, bona-fide "string" primitive could not have been added with full support for unicode. Nor is there any reason an *optional* GC could not have been added. Etc, etc, etc. And ALL of this could have been done with out a huge friggin 23 MB runtime, and the requirement of running under a stupid byte-code "managed code" framework. ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF!
-
This is one of the things that the guy mentioned in terms of doing the same thing differently. How do events occur/get handled at design time ? The syntax is different, but how does the behaviour differ ? ( FWIW, I like the VB syntax here, but I don't see how it's more than syntactic sugar ) Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
Christian Graus wrote: How do events occur/get handled at design time ? The syntax is different, but how does the behaviour differ ? I'm not sure how it gets wired up. There's not a lot of difference, except if you change the name of the method, you only have to change it in one place (great for forgetful people like me ;)) Christian Graus wrote: I like the VB syntax here, but I don't see how it's more than syntactic sugar Isn't that the whole point of the article? There's very little difference between the two languages except for syntax?
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
-
Christian Graus wrote: why did Microsoft need to create C# Marketing and because they were pissed at Sun. There is absolutely NO reason that many of the issues with C/C++ would not have been properly fixed, and then made "toggleable" with compiler switches to turn off the MS specific parts. For example, there is no reason that I can see that adding a simple property to arrays so that it's current length can be properly determined could not have been added. Nor is there any reason a new, real, bona-fide "string" primitive could not have been added with full support for unicode. Nor is there any reason an *optional* GC could not have been added. Etc, etc, etc. And ALL of this could have been done with out a huge friggin 23 MB runtime, and the requirement of running under a stupid byte-code "managed code" framework. ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF!
Jim Crafton wrote: Marketing and because they were pissed at Sun. I agree. But in equal parts. Why was it needed for marketing ? Because the VB name was/is beyond redemption. There will always be a large number of developers who will not take anything tied to VB seriously. Jim Crafton wrote: There is absolutely NO reason that many of the issues with C/C++ would not have been properly fixed, and then made "toggleable" with compiler switches to turn off the MS specific parts. Yeah, but that would have had the C++ community up in arms. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
-
Christian Graus wrote: How do events occur/get handled at design time ? The syntax is different, but how does the behaviour differ ? I'm not sure how it gets wired up. There's not a lot of difference, except if you change the name of the method, you only have to change it in one place (great for forgetful people like me ;)) Christian Graus wrote: I like the VB syntax here, but I don't see how it's more than syntactic sugar Isn't that the whole point of the article? There's very little difference between the two languages except for syntax?
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
Ryan Binns wrote: Isn't that the whole point of the article? There's very little difference between the two languages except for syntax? Yeah, and MY point was that even the article mentioned things C# can do that VB.NET cannot, and failed to mention anything in the other direction. So there IS difference apart from syntax, and it's all in C#'s favour ( can do more/doesn't have crappy legacy VB6 'features' ) But I agree in part - the Handles keyword is nice and compact, it's where you'd expect it to be, and I for one would be happy to see C# support it. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
-
Why C# is not a better language than VB.NET[^]. Interesting read. cheers, Chris Maunder
I know I have mentioned before, I don't consider any language "better" than all the others. Each language has their superior qualities. Lisp handles data expressions better than most languages, I certainly would not consider it "better" than C/C++ or C# just because of how it handles data. Assembly can do almost anything, but its nature of being too close to machine code and difficulty reading makes it powerful and difficult to use at the same time. Thus we have higher languages to make things easier. Very little can beat hand-optimized assembly for speed. But time wise justifies that extra effort only in the most extreme cases. I like the various C incarnations as a general purpose system for its balance between flexibility and power. That doesn't mean I fall in the VB haters group. Heck I used to write basic, even wrote my own interpreter for basic for other languages to make it easier to maintain code. In almost every case you can find at least one point in any language comparison that one side does better than the others.... Except maybe Cobol. X| Cobol used to be the language of choice to make fun of, now it is Basic. It neither bothers, nor excites me wether VB lives or dies. I write C++, and will probably migrate to C# someday, it doesn't matter to me if someone else doesn't. I say live and let live. _________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Why C# is not a better language than VB.NET[^]. Interesting read. cheers, Chris Maunder
I don't think any real career programmers ever have the luxury of this silly ongoing debate. Judging by what I've seen here in the past it's no wonder managers are outsourcing programming -- the North American programmers are sounding more and more like a bunch of spoiled children. Does a waiter get to choose which customers they deal with? Does a ditch digger get to choose what type of soil they will dig? What kind of shovel they will use? Does a construction worker specialize in a certain kind of nail? Or hammer? Come on people, some of you are starting to sound terminally unemployable.
-
I don't think any real career programmers ever have the luxury of this silly ongoing debate. Judging by what I've seen here in the past it's no wonder managers are outsourcing programming -- the North American programmers are sounding more and more like a bunch of spoiled children. Does a waiter get to choose which customers they deal with? Does a ditch digger get to choose what type of soil they will dig? What kind of shovel they will use? Does a construction worker specialize in a certain kind of nail? Or hammer? Come on people, some of you are starting to sound terminally unemployable.
John Cardinal wrote: Does a waiter get to choose which customers they deal with? Does a chef get to choose his saucepan ? John Cardinal wrote: Does a ditch digger get to choose what type of soil they will dig? Of course not. No-one is complaining about the sort of application they get asked to write. John Cardinal wrote: What kind of shovel they will use? Almost certainly. John Cardinal wrote: Does a construction worker specialize in a certain kind of nail? Or hammer? They probably know that a $2 hammer is crap, and would never use it. They may well have a variety of decent hammers to choose from. John Cardinal wrote: Come on people, some of you are starting to sound terminally unemployable. I'm not sure why you think that. Any programmer who is unable to discuss the arguments for/against a given language surely has no brain at all ? Your analogies mostly fall flat, I am sorry, unless you're having a shot at the VB6 programmers who are running scared because they can't cope with VB.NET. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
-
Jim Crafton wrote: Marketing and because they were pissed at Sun. I agree. But in equal parts. Why was it needed for marketing ? Because the VB name was/is beyond redemption. There will always be a large number of developers who will not take anything tied to VB seriously. Jim Crafton wrote: There is absolutely NO reason that many of the issues with C/C++ would not have been properly fixed, and then made "toggleable" with compiler switches to turn off the MS specific parts. Yeah, but that would have had the C++ community up in arms. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
no way! While I love C++ and used it for millennia, it simply isn't good enough for the things where it's not the only option: doing things fast and with full control over resources (assembler would be better, but it has too many other issues: lack of portability, size of code, ..., you name it). And it doesn't take long to notice that for most of the stuff you work with Perl is much faster to write and maintain. Yes, it's not a compiled language, and that raises another lot of issues. On top of this there are the new directions in programming languages: patterns, portablity and security. The result are pseudo-languages like Java, C# and VB.NET, that are based on garbage collection (the death of the C++ destructors) and that don't exists without their libraries/virtual machines (You can write the C standard libraries in C, C# simply doesn't exist without .NET). Yes, you also have the marketing push to sell the whole thing (lines like: "garbage collection is the way of the future because developers are too stupid to manage mamery allocation on themselves"), but at the end of the day this is all you have: - security (garbage collection) - portability - patterns - script-like features for "standard" things (working with string and string representations) IMHO, saying "m-soft was pissed at Sun" misses the point completely. OGR
-
Why C# is not a better language than VB.NET[^]. Interesting read. cheers, Chris Maunder
When people argue if vb.net is as good as c# they tend to list things that vb.net can do. and sure, vb.net can do almost everything that c# does , and it also have a few own things like late binding and indexed properties ( != indexers ) what makes vb.net BAAAD , is the fact that allows sloppy coding. and it also allows casting in ways that are really really strange.. eg: Dim myBool as Boolean myBool = nothing if myBool == false then ' this will fire because vb.net compiler casts "nothing" to "false" if assigned to a bool end if and this was NOT possible in vb6 , so god knows for what reason they did that in vb.net //Roger
-
When people argue if vb.net is as good as c# they tend to list things that vb.net can do. and sure, vb.net can do almost everything that c# does , and it also have a few own things like late binding and indexed properties ( != indexers ) what makes vb.net BAAAD , is the fact that allows sloppy coding. and it also allows casting in ways that are really really strange.. eg: Dim myBool as Boolean myBool = nothing if myBool == false then ' this will fire because vb.net compiler casts "nothing" to "false" if assigned to a bool end if and this was NOT possible in vb6 , so god knows for what reason they did that in vb.net //Roger
1. The absence of the "using" statement for calling IDisposable creates resource-hungry programs. VB programmers simply do not call IDisposable, or do not call it in a reliable way. 2. "Unstructured error handling". Aka "On Error Goto". Aka bad code. 3. "On Error Resume Next". Aka "On Error F**k off". This is one of my favorites: in case of an error, resume the execution point on the next statement. Lots of fun here. 4. "On Error Goto 0" and "On Error Goto -1". I'm yet to find a VB programmer who can tell the difference between the two. 5. The "Mid" statement. No, not the function, the statement. Isn't it a work of a genius naming a statement and a function with the same name? 6. "Modules". Aka "I don't need any stinking classes". Aka "I won't ever need thread safety" 7. The "With" statement. Aka "I don't need any stinking methods. I manipulate an object outside the class definition and I call it information hiding". Aka the "data class" bad code smell. Aka "deriving a class is too much work". 8. "Option Compare Text". Aka "I don't need performance when comparing strings" 9. "Option Explicit Off". Aka "There's only one type, the powerful Object". Aka "I want to give away performance because I'm lazy typing variable declarations". Aka "I don't want a compiler checking the variable names for me. If I mistype a name, just create another one for me, pleeeease." 10. "Option Strict Off". Aka "What? Why can't I just assing this string variable to this integer variable?" 11. The hidden return variable. All functions have a hidden variable that is named with the same name as the function. Don't forget to assign to it. In any code path. If you forget, VB choses a default value for you and won't warn you. 12. BTW, there are no warnings. And this is meant to be "a productive language?" 13. REM. It'd be fun seeing a program entirely commented using exclusively REM. 14. "Array Covariance". I'm yet to know a VB programmer who can tell me what's this (BTW, I know). 15. The "Like" operator. The syntax is incompatible with the .NET Regex syntax. Answer quickly: should "x**y" match "xy" and "xay"? The answer is none. Can you explain why? 16. The "Concatenation Operator". Quoting MSDN: 'Also, there is a special case in that Nothing is treated in concatenation expressions as if it were the empty string literal ""' 17. I'm yet to find a VB programmer who can declare a char constant. 18. x!abc. Aka x("abc") 19. Copy-in/copy-out semantics when passing an argument passed to a reference parameter and the argument needs to
-
1. The absence of the "using" statement for calling IDisposable creates resource-hungry programs. VB programmers simply do not call IDisposable, or do not call it in a reliable way. 2. "Unstructured error handling". Aka "On Error Goto". Aka bad code. 3. "On Error Resume Next". Aka "On Error F**k off". This is one of my favorites: in case of an error, resume the execution point on the next statement. Lots of fun here. 4. "On Error Goto 0" and "On Error Goto -1". I'm yet to find a VB programmer who can tell the difference between the two. 5. The "Mid" statement. No, not the function, the statement. Isn't it a work of a genius naming a statement and a function with the same name? 6. "Modules". Aka "I don't need any stinking classes". Aka "I won't ever need thread safety" 7. The "With" statement. Aka "I don't need any stinking methods. I manipulate an object outside the class definition and I call it information hiding". Aka the "data class" bad code smell. Aka "deriving a class is too much work". 8. "Option Compare Text". Aka "I don't need performance when comparing strings" 9. "Option Explicit Off". Aka "There's only one type, the powerful Object". Aka "I want to give away performance because I'm lazy typing variable declarations". Aka "I don't want a compiler checking the variable names for me. If I mistype a name, just create another one for me, pleeeease." 10. "Option Strict Off". Aka "What? Why can't I just assing this string variable to this integer variable?" 11. The hidden return variable. All functions have a hidden variable that is named with the same name as the function. Don't forget to assign to it. In any code path. If you forget, VB choses a default value for you and won't warn you. 12. BTW, there are no warnings. And this is meant to be "a productive language?" 13. REM. It'd be fun seeing a program entirely commented using exclusively REM. 14. "Array Covariance". I'm yet to know a VB programmer who can tell me what's this (BTW, I know). 15. The "Like" operator. The syntax is incompatible with the .NET Regex syntax. Answer quickly: should "x**y" match "xy" and "xay"? The answer is none. Can you explain why? 16. The "Concatenation Operator". Quoting MSDN: 'Also, there is a special case in that Nothing is treated in concatenation expressions as if it were the empty string literal ""' 17. I'm yet to find a VB programmer who can declare a char constant. 18. x!abc. Aka x("abc") 19. Copy-in/copy-out semantics when passing an argument passed to a reference parameter and the argument needs to
I would say the biggest effect of VB on myself is that having started to self-learn C# I find that I am somewhat lost on quite important aspects of modern coding. VB has slowly over the last 8-10 years eroded some skills I had learned during my FORTRAN years. The use of classes has never been one of my strong points and as VB lets you slap any old code together to make something that works I have never had a pressing reason to come to grips with them until now. The trouble is with tight deadlines and changing specifications (yes - i know that shouldnt happen but it does :) ) the main job is to get the product written and out earning money. VB is quick, easy and dirty and it gets the job done - however it doesn't encourage decent programming in my opinion. I still remember having to write your own code in FORTRAN rather than be a cut and paste merchant being pampered by colour coded Intellisense - ahh proper programming - those were the days :)