• (cs) in reply to eVil
    eVil:
    Well, VB is really for business owners, who would be intelligent enough to be able to roughly formulate models of their business in logical "maths-y" ways, but who are not engineers and are not really interested in making something efficiently.

    Because COBOL wasn't easy enough for business users to master ;)

  • faoileag (unregistered) in reply to chubertdev
    chubertdev:
    QJo:
    So you can increase the processing speed profoundly by turning ...+ " Set " + "@" +... into ...+ " Set @" +...

    http://en.wikipedia.org/wiki/String_interning

    Nice link - I'm pretty sure I've read about string interning before, but I tend to forget such compiler internals :-(

  • (cs)

    As obligatory as a link after an XKCD reference.

  • tree_hugger (unregistered) in reply to eVil
    eVil:
    HerrDerSchatten:
    Honestly, if you are not using Option Strict on in Vb.NET you are the wtf. Building a bigger program without that option is like building on mud. Even if you are doing Office interop, you can use strict on, with the possible exception of late binding.

    TBH, using VB.NET when C# is available (e.g., always) is the real WTF, Option Strict or not.

    Obviously you do not need to be anywhere near a keyboard. Bad code can be written in any language.

  • (cs)

    For those who say that there are few differences between C# and VB.NET, you can't have really thought about the problem too deeply. Just because something compiles to CIL doesn't mean it's the same language. Rust, C++, FORTRAN and even Go (I didn't want Ben L to feel left out) are compiled to the same machine code, but differ vastly in the constructs and paradigms employed. In terms of "capability" and what one can do with a language, once it's turing complete, it can do anything (so we could all be still writing x86ASM or even in BF and "technically" still get our jobs done). But instead we chose a language which facilitates abstractions which suite our domain and application (even our personalities) and it makes us more productive.

    C# is a vastly improved Java, which doesn't stray too far from it's Statically Typed, OO roots, and since V3 has added some cool functional constructs with LINQ, and some dynamic language constructs (albeit all using reflection under the hood).

    VB.NET is an unfortunate attempt to let VB6 programmers muddle along. I'm pretty sure there are COBOL implementations available for the JVM too.

  • faoileag (unregistered) in reply to Tom
    Tom:
    Actually, + and @ are equivelant for string concatenation in VB. The & is the explicit string concatenation operator, as it always returns a string, but + is perfectly acceptable.
    From what I found on stack overflow I thought it wouldn't be, since the "+" will always try to numerically add its two operands.

    So that even with "foo" + "bar" the compiler would at least try to convert one operand into an integer before performing a string concatenation.

    But I maybe wrong, I haven't touched Visual Basic in a decade or so.

    Tom:
    StringBuilder is intended for code where you do something like a = a + "something" in a loop. Using StringBuilder for a single line variable assignment isn't going to buy you much, and it might even take you backward, since allocating and deleting objects has its own overhead.
    Actually I'm not sure if your are right or wrong here - if I get the workings of the Compiler correctly, then even in a variable assignment the string is assembled seperate piece by separate piece using a temporary string, so you could interpret a chain of assignments as an unrolled loop. And if the string variable assigned to does not have the right capacity, you will have the same effect.
    Tom:
    This whole code section is a newbie mistake, but it doesn't so much make scream out in anguish as just shake my head.
    The wrong operator for string concatenation, the global variable, the comments... yeah, nothing out of the ordinary.

    But the fact that a database request is made for every column in every row of the DataSet generated from an XML that can be up to 50MB in size: that's one hell of a big issue.

  • (cs) in reply to caffiend
    caffiend:
    For those who say that there are few differences between C# and VB.NET, you can't have really thought about the problem too deeply. Just because something compiles to CIL doesn't mean it's the same language. Rust, C++, FORTRAN and even Go (I didn't want Ben L to feel left out) are compiled to the same machine code, but differ vastly in the constructs and paradigms employed. In terms of "capability" and what one can do with a language, once it's turing complete, it can do anything (so we could all be still writing x86ASM or even in BF and "technically" still get our jobs done). But instead we chose a language which facilitates abstractions which suite our domain and application (even our personalities) and it makes us more productive.

    C# is a vastly improved Java, which doesn't stray too far from it's Statically Typed, OO roots, and since V3 has added some cool functional constructs with LINQ, and some dynamic language constructs (albeit all using reflection under the hood).

    VB.NET is an unfortunate attempt to let VB6 programmers muddle along. I'm pretty sure there are COBOL implementations available for the JVM too.

    And those examples of things that C# .NET can do that VB .NET can't would be...

  • I don't think so (unregistered)

    And this looks surprisingly like code I get to run on servers I'm responsible for.

    1. Except the code is written in Java for a servlet container
    2. The code does not use a DOM structure
    3. Except the XML has no DTD or XSD, therefore not validated
    4. Except that the file is hand-edited at over 500 lines
    5. Except that the file is read for every request
    6. The read happens in a synchronized block

    The developer responsible for this had a few things to say.

    The person complaining about editing an unverifiable 500 line XML file was just a complainer who didn't want to learn anything new.

    We won't worry about web performance issues until someone complains.

    And no, there's no chance of fixed code making it into production (even though I've written the replacement).

  • (cs) in reply to chubertdev
    chubertdev:
    And those examples of things that C# .NET can do that VB .NET can't would be...

    As far as I'm concerned, C# can stick around and have a cookie, whereas VB.NET can fuck off and die. That was the question, right?

  • Anonymous (unregistered) in reply to faoileag
    faoileag:
    aragaer:
    I am starting to like stories where the fun part is a huge chunk of code in a language I don't know.
    Pffft, Visual Basic is easy. Wait until an article appears in which you are presented a huge chunk of LISP :-)
    Or. Linus forbid, Perl.
  • Wyrm (unregistered)

    The conclusion is a classic. A well-known rule of development is "if it's not broken, don't fix it." A widespread rule of management is "if no one complains, don't fix it."

  • (cs) in reply to vali1005
    vali1005:
    Management's response was a WTF from the point of view of a common-sense developer ("always strive to do/implement things the right way").

    But, from management's point of view, if the customers are not complaining, then it ain't broke, therefore, it doesn't need fixing, therefore, development resources can be put to use on more urgent matters.

    Yeah, and its much harder to break code you DO NOT change. Whenever you modify code, you run the risk of breaking it. Hence the judgement call -- no reported issues vs risk of broken code. Easy call to make.

  • (cs) in reply to eViLegion
    eViLegion:
    chubertdev:
    And those examples of things that C# .NET can do that VB .NET can't would be...

    As far as I'm concerned, C# can stick around and have a cookie, whereas VB.NET can fuck off and die. That was the question, right?

    "VB sucks because it was misused in 1998!"

  • (cs) in reply to Anonymous
    Anonymous:
    faoileag:
    aragaer:
    I am starting to like stories where the fun part is a huge chunk of code in a language I don't know.
    Pffft, Visual Basic is easy. Wait until an article appears in which you are presented a huge chunk of LISP :-)
    Or. Linus forbid, Perl.

    Isn't Perl just holding down the shift key and banging your head on the top row of keys?

  • (cs) in reply to chubertdev
    chubertdev:
    caffiend:
    For those who say that there are few differences between C# and VB.NET, you can't have really thought about the problem too deeply. Just because something compiles to CIL doesn't mean it's the same language. Rust, C++, FORTRAN and even Go (I didn't want Ben L to feel left out) are compiled to the same machine code, but differ vastly in the constructs and paradigms employed. In terms of "capability" and what one can do with a language, once it's turing complete, it can do anything (so we could all be still writing x86ASM or even in BF and "technically" still get our jobs done). But instead we chose a language which facilitates abstractions which suite our domain and application (even our personalities) and it makes us more productive.

    C# is a vastly improved Java, which doesn't stray too far from it's Statically Typed, OO roots, and since V3 has added some cool functional constructs with LINQ, and some dynamic language constructs (albeit all using reflection under the hood).

    VB.NET is an unfortunate attempt to let VB6 programmers muddle along. I'm pretty sure there are COBOL implementations available for the JVM too.

    And those examples of things that C# .NET can do that VB .NET can't would be...

    http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Visual_Basic_.NET#Features_of_Visual_Basic_.NET_not_found_in_C.23

  • (cs) in reply to chubertdev
    chubertdev:
    "VB sucks because it was misused in 1998!"

    Not sure how you inferred that... No VB sucks because that's my opinion; it needs no justification. That my opinion appears to be loosely correlated with a bunch of anecdotal evidence of shoddy VB code and VB coders is a bonus, but ultimately my main argument is the ill feeling it gives me in the pit of my stomach.

  • J (unregistered) in reply to Dogsworth
    Dogsworth:
    Wow, that response from Herb Jenkins really is icing on the cake.

    I don't think that response is so bad. Perhaps they already have plenty of work fixing problems that the users ARE complaining about.

  • Yazeran (unregistered) in reply to chubertdev
    chubertdev:
    Anonymous:
    faoileag:
    aragaer:
    I am starting to like stories where the fun part is a huge chunk of code in a language I don't know.
    Pffft, Visual Basic is easy. Wait until an article appears in which you are presented a huge chunk of LISP :-)
    Or. Linus forbid, Perl.

    Isn't Perl just holding down the shift key and banging your head on the top row of keys?

    Well no, there may be some edge cases where the resulting code wont parse... :-)

    (Disclaimer: I do make applications in Perl on a daily basis, but I make sure to use strict and warnings for all modules and scripts)

    Yours Yazeran

    Plan: To go to mars one day with a hammer

  • (cs) in reply to DrPepper
    DrPepper:
    chubertdev:
    caffiend:
    For those who say that there are few differences between C# and VB.NET, you can't have really thought about the problem too deeply. Just because something compiles to CIL doesn't mean it's the same language. Rust, C++, FORTRAN and even Go (I didn't want Ben L to feel left out) are compiled to the same machine code, but differ vastly in the constructs and paradigms employed. In terms of "capability" and what one can do with a language, once it's turing complete, it can do anything (so we could all be still writing x86ASM or even in BF and "technically" still get our jobs done). But instead we chose a language which facilitates abstractions which suite our domain and application (even our personalities) and it makes us more productive.

    C# is a vastly improved Java, which doesn't stray too far from it's Statically Typed, OO roots, and since V3 has added some cool functional constructs with LINQ, and some dynamic language constructs (albeit all using reflection under the hood).

    VB.NET is an unfortunate attempt to let VB6 programmers muddle along. I'm pretty sure there are COBOL implementations available for the JVM too.

    And those examples of things that C# .NET can do that VB .NET can't would be...

    http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Visual_Basic_.NET#Features_of_Visual_Basic_.NET_not_found_in_C.23

    Gracias. Now the technical part: are these things crucial to picking your everyday language?

    -Allows blocks of unsafe code (like C++/CLI) via the unsafe keyword and support for pointers -Partial Interfaces -Multi-line and intra-line comments (The Visual Studio IDE supports multi-line commenting for Visual Basic .NET.) -Static classes (Classes which cannot contain any non-static members, although VB's Modules are essentially sealed static classes with additional semantics.) -Can use checked and unchecked contexts for fine-grained control of overflow/underflow checking

  • (cs) in reply to Yazeran
    Yazeran:
    chubertdev:
    Anonymous:
    faoileag:
    aragaer:
    I am starting to like stories where the fun part is a huge chunk of code in a language I don't know.
    Pffft, Visual Basic is easy. Wait until an article appears in which you are presented a huge chunk of LISP :-)
    Or. Linus forbid, Perl.

    Isn't Perl just holding down the shift key and banging your head on the top row of keys?

    Well no, there may be some edge cases where the resulting code wont parse... :-)

    (Disclaimer: I do make applications in Perl on a daily basis, but I make sure to use strict and warnings for all modules and scripts)

    Yours Yazeran

    Plan: To go to mars one day with a hammer

    Holy Carp!

  • (cs) in reply to DaveK
    DaveK:
    Bring back MFD!
    MFD was at least entertaining. Not like the drivel they've been "writing" lately.
  • (cs) in reply to Rennis Ditchie
    Rennis Ditchie:
    Every time I see code like this I get the feeling it was written by a believer in the church of "premature optimisation is the root of all evil".
    "Believer"? More like a fanatical zealot, who tries to write the code as inefficiently as possible so he doesn't optimize something prematurely by accident.
  • (cs) in reply to Anonymouse
    Anonymouse:
    Rennis Ditchie:
    Every time I see code like this I get the feeling it was written by a believer in the church of "premature optimisation is the root of all evil".
    "Believer"? More like a fanatical zealot, who tries to write the code as inefficiently as possible so he doesn't optimize something prematurely by accident.

    I suspect it was probably written by the technique of "This is how to do it. No, that didn't work, better fix it. Oh dear, something else I didn't think of, fix that. Still doesn't work, why not? Oh sod it, I've got to check this. Right now I've learned how to concatenate, you don't use + you use &. Oh yeah, so I'll ad this bit properly this time. Hmm. Yeah that seems to work."

    Alternatively, like some developers I've known, he / she believed that you must never emove code. At the very most, you may comment it out. Otherwise you lose the history of how it was developed. Therefore you can't remove old buggy stuff, you're only allowed to amend it. But look here sunshine, I'm a software developer, not an archaeologist.

  • eVil (unregistered) in reply to Matt Westwood
    Matt Westwood:
    Alternatively, like some developers I've known, he / she believed that you must never emove code. At the very most, you may comment it out. Otherwise you lose the history of how it was developed. Therefore you can't remove old buggy stuff, you're only allowed to amend it. But look here sunshine, I'm a software developer, not an archaeologist.

    +1 for use of sunshine as a derogatory "term of endearment".

  • (cs) in reply to eVil
    eVil:
    Matt Westwood:
    Alternatively, like some developers I've known, he / she believed that you must never emove code. At the very most, you may comment it out. Otherwise you lose the history of how it was developed. Therefore you can't remove old buggy stuff, you're only allowed to amend it. But look here sunshine, I'm a software developer, not an archaeologist.

    +1 for use of sunshine as a derogatory "term of endearment".

    Oh yeah, that. It's ironically calling someone by a name that suggests they're bright, but who's actually unbelievably stupid. Popular turn of phrase in the UK, particularly (if the soaps are to be believed) in the police force. Glad you appreciate.

  • iMalc (unregistered)

    Classic business stupidity: Let's wait until someone complains about it...

    Never mind the fact that 95% of users wont bother to complain, instead just getting used to the fact that your product is crap. Then of the few who would consider complaining, most of those will just wait to see it it's fixed in the next version first. Then of those who do still use your product and do complain, the complaint almost never reaches those who can actually keep track of such things, or who has the power to do anything about it. And finally when the complaint does reach someone who can schedule something to be done about it, all they do is mandate a progress bar or loading animation that slows it down even more in an attempt to keep the customer entertained. The developer isn't even allowed to do the half hour fix because "most customers seem to be happy with it how it is".

  • eVil (unregistered) in reply to Matt Westwood
    Matt Westwood:
    Oh yeah, that. It's ironically calling someone by a name that suggests they're bright, but who's actually unbelievably stupid. Popular turn of phrase in the UK, particularly (if the soaps are to be believed) in the police force. Glad you appreciate.

    It reminds me of Eric Morcombe: http://www.youtube.com/watch?v=R7GeKLE0x3s&feature=youtu.be&t=11m

  • Mike Dimmick (unregistered) in reply to QJo
    QJo:
    I've found TRWTF:

    setValues = setValues + " Set " + "@" + dataTable.Columns(i).ColumnName.ToString() + "=" & ConvertedSetVal.ToString & ";"

    Everybody knows how inefficient string concatenation is. So you can increase the processing speed profoundly by turning ...+ " Set " + "@" +... into ...+ " Set @" +...

    Surely you don't need management approval for that?

    The VB.NET compiler performs constant folding. It converts concatenation of two or more string literals into a single string literal in the compiled code.

    It also turns a sequence of concatenation operators in the same statement - where some of the operands are not literals or constants - into a single call to String.Concat, using the appropriate overload (there are overloads taking two, three and four String parameters, and one taking a String array).

  • (cs) in reply to chubertdev
    chubertdev:
    There are things that I like and things that I HATE about VB. If you compare VB's Select Case to any C-syntax switch statement, it's far superior. But when you look at the Iif() function, using + as a string concatenation operator, and all these little things that try to make what was VB6 more .NET-ish, it just ends up being a bunch more WTFs.

    It's not superior. C switch lets you fall through from one case to another, which is very useful in certain cases, where VB does not, which makes for some awkward code in those cases. I've never had to use Iif(), + for string concat makes sense (you can do it in C++ too), and the .NET stuff just adds options, you don't have to use all of it.

  • Sir Galahad the Pure (unregistered) in reply to DaveK
    DaveK:
    Bring back MFD!
    +1
  • Sir Galahad the Pure (unregistered) in reply to faoileag
    faoileag:
    aragaer:
    I am starting to like stories where the fun part is a huge chunk of code in a language I don't know.
    Pffft, Visual Basic is easy. Wait until an article appears in which you are presented a huge chunk of LISP :-)

    Should we brace ourselves for that?

  • (cs) in reply to Gunslnger
    Gunslnger:
    chubertdev:
    There are things that I like and things that I HATE about VB. If you compare VB's Select Case to any C-syntax switch statement, it's far superior. But when you look at the Iif() function, using + as a string concatenation operator, and all these little things that try to make what was VB6 more .NET-ish, it just ends up being a bunch more WTFs.

    It's not superior. C switch lets you fall through from one case to another, which is very useful in certain cases, where VB does not, which makes for some awkward code in those cases. I've never had to use Iif(), + for string concat makes sense (you can do it in C++ too), and the .NET stuff just adds options, you don't have to use all of it.

    That's you not knowing the code.

    pseudo-codish

    switch(var) {
       case 1:
       case 2:
          doSomething();
          break;
    }
    

    vs

    Select Case
       case 1, 2:
          doSomething();
    End Select
    
  • Klimax (unregistered) in reply to chubertdev
    chubertdev:
    Gunslnger:
    chubertdev:
    There are things that I like and things that I HATE about VB. If you compare VB's Select Case to any C-syntax switch statement, it's far superior. But when you look at the Iif() function, using + as a string concatenation operator, and all these little things that try to make what was VB6 more .NET-ish, it just ends up being a bunch more WTFs.

    It's not superior. C switch lets you fall through from one case to another, which is very useful in certain cases, where VB does not, which makes for some awkward code in those cases. I've never had to use Iif(), + for string concat makes sense (you can do it in C++ too), and the .NET stuff just adds options, you don't have to use all of it.

    That's you not knowing the code.

    pseudo-codish

    switch(var) {
       case 1:
       case 2:
          doSomething();
          break;
    }
    

    vs

    Select Case
       case 1, 2:
          doSomething();
    End Select
    
    switch(var) {
       case 1:
           doSomething1()
       case 2:
          doSomething2();
          break;
    }
    

    Aka skipping for a case a step... (while a case has both)

  • (cs) in reply to Klimax
    Klimax:
    switch(var) {
       case 1:
           doSomething1()
       case 2:
          doSomething2();
          break;
    }
    
    Aka skipping for a case a step... (while a case has both)

    Easy:

    If 1 Then doSomething1()
    If 1 OrElse 2 doSomething2()
    

    I'm not debating which is cleaner, I'm saying that you can do it in either language. The difference between what you posted and what I did is very minimal. Much, MUCH smaller than what VB case statements can do that C# ones can't.

    Select Case
       Case Is 5, 10 To 15
          doSomething1()
       Case Else
          doSomething2()
    End Select
    
  • Andrew (unregistered) in reply to QJo

    Hopefully the VB compiler can figure out how to concatenate static strings at compile time.

  • Qvazar (unregistered)

    Wow, this is so familiar to what I just rebuilt 2 weeks ago. Except it was in LINQ. A 30mb file took 45 minutes to process. Now, 27 seconds.

  • Brad (unregistered)

    The original developer figured out how to construct a SQL Server merge statement in code (difficult enough in straight TSQL). Gotta be some bonus points for that.

  • coyo (unregistered)

    TTWTF is that the careless merge wasn't about source control.

    captcha: usitas. Us? It? As??

  • Graypz (unregistered) in reply to faoileag

    I think I interviewed this person already. After asking about physical implementation of a many to many relationship in the database, they said - "Why are you asking me these things?" I replied, "This is a job interview - I ask questions you answer them".

  • anonymous (unregistered) in reply to Graypz
    Graypz:
    I think I interviewed this person already. After asking about physical implementation of a many to many relationship in the database, they said - "Why are you asking me these things?" I replied, "This is a job interview - I ask questions you answer them".
    To be fair, it sounded like a pretty inappropriate question until you got to the "in the database" part.

Leave a comment on “A Careless Merge”

Log In or post as a guest

Replying to comment #:

« Return to Article