Why C# Is not a "Better" Language Than VB.NET
-
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 :)
-
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
Daniel Turini wrote: what's the point of having a feature that can only be used in sloppy coding? It WILL be abused. Backwards compatability?
-
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!
-
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
That's a great list. How can anyone argue with that list? Given that they probably can't, why would anyone defend VB? Why would anyone use VB? The answer is that they are witless, which just goes to promote that VB is defended by bad programmers. :-D Marc MyXaml Advanced Unit Testing YAPO
-
Why C# is not a better language than VB.NET[^]. Interesting read. cheers, Chris Maunder
Chris Maunder wrote: Interesting read. I refuse to read articles from sites where the text width is smaller than the width of the advertising panels. It's impossible to read! That site must have been designed by VB programmers. Marc MyXaml Advanced Unit Testing YAPO
-
Why C# is not a better language than VB.NET[^]. Interesting read. cheers, Chris Maunder
Well, finally with .NET, it really does not matter much which language you use. However, I am not falling in that "right tool for the right job" garbage. I use C# for one reason, I like it! I do not use VB.NET for one reason, I hate the syntax! That is how simple it really is, all these wars one which language is best is nothing but a joke. The only language that makes any different is C++ and that only due to possible performance gains. That is going to be the nice part about the next version of VS.NET, it will be able to combine C#/VB.NET, C++ or any other .NET language all in the same assembly. You spot something in VB you want to use in your code, drop it in. Microsoft should come up with a wonderbangger cross translator so that when you click a C# tab, all your code is in C#, you click the VB.NET tab and all your code is in VB.NET, now that would surely solve the problem ;) Rocky <>< TechTV's ScreenSavers death blow![^]
-
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
ogrig wrote: 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). This is nonsense :) patterns - have NOTHING to do with the language. I can write singleton patterns in VB, C/C++/C#/ObjectiveC/ObjectPascal/Python, the list goes on. portablity - is only marginally tied to the language, it's definitely tied to the implementation. But there is little in most languages that is completely non-portable to other platforms. security - again has little to do with the language and *everything* to do with the runtime library that comes with it. Unless you're referring to overflow error exploits, and then I'd agree, that's definitely language related. ¡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!
-
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
Christian Graus wrote: 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. You and others here are somehow missing the overwhelming point of this issue: a language is a tool to solve a problem. There is much merit in arguing the strengths and weaknesses of a language versus a specific problem. There is nothing but wind and noise in arguing about which language is better. Condemning people who primarily use VB is way off the mark and arrogant. They may be working wonders under trying circumstances. If I drive a $38K sports car should I snear at all those who could only afford an economy car? You act as though those VB people have a *choice* in the matter. Most often I suspect they don't. They are fellow programmers trying to earn a living. To dismiss them as stupid or inept is shameful arrogance and I'm tired of it. Some people here are exhibiting the "Neutered cat" mentality of such gross contentment that they think they can still dictate and pick the cream of the jobs. A true professional should be proficient in any language they are likely to find work in. The days of being a career programmer are long gone if they ever existed in the first place.
-
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
-
Well, finally with .NET, it really does not matter much which language you use. However, I am not falling in that "right tool for the right job" garbage. I use C# for one reason, I like it! I do not use VB.NET for one reason, I hate the syntax! That is how simple it really is, all these wars one which language is best is nothing but a joke. The only language that makes any different is C++ and that only due to possible performance gains. That is going to be the nice part about the next version of VS.NET, it will be able to combine C#/VB.NET, C++ or any other .NET language all in the same assembly. You spot something in VB you want to use in your code, drop it in. Microsoft should come up with a wonderbangger cross translator so that when you click a C# tab, all your code is in C#, you click the VB.NET tab and all your code is in VB.NET, now that would surely solve the problem ;) Rocky <>< TechTV's ScreenSavers death blow![^]
Rocky Moore wrote: That is going to be the nice part about the next version of VS.NET, it will be able to combine C#/VB.NET, C++ or any other .NET language all in the same assembly. You spot something in VB you want to use in your code, drop it in. Um...not sure what you mean here, I am working on a project right now with the business object framework layer written in VB.NET, my business objects are in C#. No problems at all.
-
Rocky Moore wrote: That is going to be the nice part about the next version of VS.NET, it will be able to combine C#/VB.NET, C++ or any other .NET language all in the same assembly. You spot something in VB you want to use in your code, drop it in. Um...not sure what you mean here, I am working on a project right now with the business object framework layer written in VB.NET, my business objects are in C#. No problems at all.
The point is that the next version of VS.NET (if you can afford it) will allow mixed sources in the "same" assembly, not requiring them to be in different dlls. In your project view, you can have a mix of any .NET languages instead of just one. Rocky <>< TechTV's ScreenSavers death blow![^]
-
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
ogrig wrote: 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 What did I say that makes you think I disagree with this ? ogrig wrote: 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. I work in websites and image processing. If Perl does a better job for what you do, more power to you. None of my comments were against Perl. ogrig wrote: On top of this there are the new directions in programming languages: patterns, portablity and security. How are they new ? ogrig wrote: 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). This is a dumb argument. At some point, your C code turns into assembler, so does my C# code. The existence of a VM is really not a major issue. I would agree that I find the absence of deterministic destruction annoying. ogrig wrote: security (garbage collection) These are unrelated. ogrig wrote: portability The world is full of portable C code. ogrig wrote: patterns The original patterns book ( GoF ) did not need any of the languages you refer to in order to impliment their patterns. ogrig wrote: IMHO, saying "m-soft was pissed at Sun" misses the point completely. Not at all. If that were not the case, they would have contributed to Java instead of creating a competitor. Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
-
Christian Graus wrote: 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. You and others here are somehow missing the overwhelming point of this issue: a language is a tool to solve a problem. There is much merit in arguing the strengths and weaknesses of a language versus a specific problem. There is nothing but wind and noise in arguing about which language is better. Condemning people who primarily use VB is way off the mark and arrogant. They may be working wonders under trying circumstances. If I drive a $38K sports car should I snear at all those who could only afford an economy car? You act as though those VB people have a *choice* in the matter. Most often I suspect they don't. They are fellow programmers trying to earn a living. To dismiss them as stupid or inept is shameful arrogance and I'm tired of it. Some people here are exhibiting the "Neutered cat" mentality of such gross contentment that they think they can still dictate and pick the cream of the jobs. A true professional should be proficient in any language they are likely to find work in. The days of being a career programmer are long gone if they ever existed in the first place.
John Cardinal wrote: There is nothing but wind and noise in arguing about which language is better. Really ? So if a language has unnatural syntax, or 'features' that encourage sloppy programming, those things should not be mentioned ? On what basis does language evolution happen then ? John Cardinal wrote: Condemning people who primarily use VB is way off the mark and arrogant. They may be working wonders under trying circumstances. Hell, I've always admitted that probably 5% of VB users can code. No argument there. I'm not interested in condemning anyone, I'm interested in discussing the usefulness of VB as a tool. If a hammer was made of balsa wood, and a lot of people were using it, would it be invalid to discuss the usefulness of a balsa wood hammer ? John Cardinal wrote: You act as though those VB people have a *choice* in the matter. Most often I suspect they don't. They are fellow programmers trying to earn a living. To dismiss them as stupid or inept is shameful arrogance and I'm tired of it. Really ? You're saying that people learn VB, not by choice ? Then why are so many VB users not versed in other languages ? How did they become 'programmers' against their will ? I've done some VB work, because there have been a couple of cases where I could not move the client to C# or C++. That's fine. I'm sure others are in the same boat, due to ignorant end users. My comments are directed at the language, not the users, and they are based on personal experience. John Cardinal wrote: Some people here are exhibiting the "Neutered cat" mentality of such gross contentment that they think they can still dictate and pick the cream of the jobs. I guess it depends on the market you are in, but I have in fact knocked back jobs because they involved VB, and come out in front for it. John Cardinal wrote: A true professional should be proficient in any language they are likely to find work in. See above - I've done VB and VB.NET work, I'm not for a moment suggesting I am unable to use VB ( although the reason I had to is that management recognised that most people in the pool they draw from are incapable of using C# or C++ ). Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
-
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
This rocks. Got my 5, and a copy of the list made for future discussions :-) Christian I have several lifelong friends that are New Yorkers but I have always gravitated toward the weirdo's. - Richard Stringer
-
ogrig wrote: 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). This is nonsense :) patterns - have NOTHING to do with the language. I can write singleton patterns in VB, C/C++/C#/ObjectiveC/ObjectPascal/Python, the list goes on. portablity - is only marginally tied to the language, it's definitely tied to the implementation. But there is little in most languages that is completely non-portable to other platforms. security - again has little to do with the language and *everything* to do with the runtime library that comes with it. Unless you're referring to overflow error exploits, and then I'd agree, that's definitely language related. ¡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!
no, please read my message again: With C/C++ you directly access the OS, with Java, C#, VB.NET you don't. Of course you don't want to rewrite all the libraries, but you can do that with C/C++. Not with Java and *.NET "Patterns have NOTHING to do with the language"? Really? Have another look at some of the new things done in C#. Or try to read a bit about Ruby. You'll find that there are languages out there that implement or use themselves certain patterns. That makes your work faster and more reliable, which results in a better language. Of course you can implement patterns even in VB opr assembler, the point is that some of there work is already done for you. "Portability only marginally tied to the language"? Thanks, I didn't know that was the purpose of the Java VM, I'll try to use it in conversation from now on. "Security has little to do with the language and *everything* to do with the runtime library". Of course, but only when you have a clear delimitation between the language and what you call "runtime library". But you are right, the image of the pissed m-soft is sooo much more poetic OGR
-
Daniel Turini wrote: what's the point of having a feature that can only be used in sloppy coding? It WILL be abused. Backwards compatability?
Richard Day wrote: Backwards compatability? Wasn't VB.NET supposed to remove bad features from the VB language at the cost of backwards compatability? I see dead pixels Yes, even I am blogging now!