The $30k Web App



  • Some time ago, a certain company outsourced a re-write of a site from  Java to .NET, and the word was to keep MVC, and that everything should be coded in C#. Of course, they dilligently did most of the site in VB.NET (first fail) and stuck all the Page_Load() code on the .aspx files (second fail). The login screens are smart enough to check for SQL injection attacks ... but the GET query strings did not (third fail). I actually was able to deface the dev site with a simple URL as a proof of concept, and to ask for a complete rewrite of this site. Note: This was the DEV site, not production site, and yes I backed up the database before this. The problem  has usually been that

    - The "site" cost something like $30k

    - They were still asking the original devs to update the thing.

    Of course, they haven't done anything in over a year, so "Project: Recode" has finally been greenlighted. While on the job, one of the new devs found this gem:

     <FONT color=#ff0000><asp:Button id="LoginButton" CssClass="button" runat="server" Text=":: Login ::" OnClick="srch_mail"/></asp:button>
    </FONT>



  • @danixdefcon5 said:

    Text=":: Login ::" OnClick="srch_mail"
    Clearly security through obscurity.



  • "srch_mail"? WTF? Does it log users in using an SMTP server as a backend?



  • @danixdefcon5 said:

    ...and stuck all the Page_Load() code on the .aspx files...
     

    @danixdefcon5 said:

    <asp:Button id="LoginButton"
    CssClass="button" runat="server" Text=":: Login ::"
    OnClick="srch_mail"/></asp:button>
     

    Care to explain either of these for those of us who don't know anything about .NET web development?



  • Of course not, it is clearly using POP3 instead.



  • @danixdefcon5 said:

    Some time ago, a certain company outsourced a re-write of a site from  Java to .NET, and the word was to keep MVC, and that everything should be coded in C#. Of course, they dilligently did most of the site in VB.NET (first fail) and stuck all the Page_Load() code on the .aspx files (second fail). The login screens are smart enough to check for SQL injection attacks ... but the GET query strings did not (third fail). I actually was able to deface the dev site with a simple URL as a proof of concept, and to ask for a complete rewrite of this site. Note: This was the DEV site, not production site, and yes I backed up the database before this. The problem  has usually been that

    - The "site" cost something like $30k

    - They were still asking the original devs to update the thing.

    Of course, they haven't done anything in over a year, so "Project: Recode" has finally been greenlighted. While on the job, one of the new devs found this gem:

     <FONT color=#ff0000><asp:Button id="LoginButton" CssClass="button" runat="server" Text=":: Login ::" OnClick="srch_mail"/></asp:button>
    </FONT>

    First of all, VB.Net isn't a fail.  Every stupidity that happened would have still happened if you forced them to do in all in C#.

    Second, anyone who creates a web site with a single SQL Injection vulnerability has no idea what they are doing.  If they had to "check for SQL injection attacks", then they were doing it wrong.  If you do it any one of ten right ways, you can completely forget about injection forever.

    Third, $30k isn't a big deal, even outsourced.  I paid well into six figures for my last outsourced conversion of a 30,000 line VB6 app converted to .Net.

    To me this is a huge project oversight fail.  Someone should have reviewed the site as it was being developed.  They should have noticed these patterns very early in the cycle and demanded a new team or training.  The outsourcing companies have tons of employees and seem to assign new people or bad coders to the projects that don't complain.  If you speak up, the issues will be addressed.



  • @Someone You Know said:

    Care to explain either of these for those of us who don't know anything about .NET web development?

    @Someone You Know said:

    @danixdefcon5 said:
    ...and stuck all the Page_Load() code on the .aspx files...
     

    Bad, because it mixes layout and procedural code in the same file.

    @Someone You Know said:

    @danixdefcon5 said:
    <asp:Button id="LoginButton"
    CssClass="button" runat="server" Text=":: Login ::"
    OnClick="srch_mail"/></asp:button>

    Only thing I can see here is the "ID" is in small letters, and C# web apps are case sensitive - sometimes this builds properly, sometimes not. Also, a login button is calling a function named "srch_mail" - which sounds wrong if you speak English.



  • @Someone You Know said:

    @danixdefcon5 said:

    ...and stuck all the Page_Load() code on the .aspx files...
     

    @danixdefcon5 said:

    <asp:Button id="LoginButton" CssClass="button" runat="server" Text=":: Login ::" OnClick="srch_mail"/></asp:button>
     

    Care to explain either of these for those of us who don't know anything about .NET web development?

    Check that asp tag closely. It uses XML-ish tags, where you can have the following:

    <asp:tag attribute="something"></asp:tag>

    or

    <asp:tag attribute="something" />

    Now check the tag. Notice something ... weird? ;)

    Oh, and the Page_Load() thingy is because .NET uses a clever design for separating code from the "view" stuff (that is, HTML stuff). All the HTML goes on dummy.aspx, all the code goes on dummy.aspx.cs or dummy.aspx.vb, depending on which language you're using.



  • @Someone You Know said:

    @danixdefcon5 said:

    ...and stuck all the Page_Load() code on the .aspx files...
     

    @danixdefcon5 said:

    <asp:Button id="LoginButton"
    CssClass="button" runat="server" Text=":: Login ::"
    OnClick="srch_mail"/></asp:button>
     

    Care to explain either of these for those of us who don't know anything about .NET web development?



    Page_Load() is called whenever the page is loading, it is generally bad form to do much there.

    As for the second one, the value of the attribute 'OnClick' is the name of the function called on the backend when the button is clicked (the Load one mentioned above also is called).  The example given looks technically valid, but in the way that makes one nervous about the quality of the code.



  • @Jaime said:

    First of all, VB.Net isn't a fail. 
    It is if they initially decided they were going to use C#.@Jaime said:
    Second, anyone who creates a web site with a single SQL Injection vulnerability has no idea what they are doing.  If they had to "check for SQL injection attacks", then they were doing it wrong.  If you do it any one of ten right ways, you can completely forget about injection forever.
    Agreed.@Jaime said:
    To me this is a huge project oversight fail.  Someone should have reviewed the site as it was being developed.  They should have noticed these patterns very early in the cycle and demanded a new team or training.  The outsourcing companies have tons of employees and seem to assign new people or bad coders to the projects that don't complain.  If you speak up, the issues will be addressed.
    Agreed.



  • @locallunatic said:

    @Someone You Know said:

    @danixdefcon5 said:

    ...and stuck all the Page_Load() code on the .aspx files...
     

    @danixdefcon5 said:

    <asp:Button id="LoginButton"
    CssClass="button" runat="server" Text=":: Login ::"
    OnClick="srch_mail"/></asp:button>
     

    Care to explain either of these for those of us who don't know anything about .NET web development?



    Me being dumb
     

    Looking back over things I'll just fix that last post of mine.



  • @Jaime said:

    Second, anyone who creates a web site with a single SQL Injection vulnerability has no idea what they are doing.  If they had to "check for SQL injection attacks", then they were doing it wrong.  If you do it any one of ten right ways, you can completely forget about injection forever.

    The fun thing is that 'checking for SQL Injection attacks' wasn't in our list, at least not originally. It was after one of the management guys started reading about SQL Injection stuff that we started probing the app. But then again, the fact that the thing was already a boo-boo was pretty much common knowledge, so anything would be expected. Note: the app also crashed after 30-ish users loaded the main page ... because some of the DB code didn't even close the DB connections.

    The rewrite is actually implementing "SQL injection safe" stuff.

    @Jaime said:

    Third, $30k isn't a big deal, even outsourced.  I paid well into six figures for my last outsourced conversion of a 30,000 line VB6 app converted to .Net.

    Check my location. $30k is well over my yearly income, and I'm  already in the upper side of the average income for Sysadmin/DBA people. But the resulting code is something I'd expect from someone being paid $20.

    @Jaime said:

    To me this is a huge project oversight fail.  Someone should have reviewed the site as it was being developed.  They should have noticed these patterns very early in the cycle and demanded a new team or training.  The outsourcing companies have tons of employees and seem to assign new people or bad coders to the projects that don't complain.  If you speak up, the issues will be addressed.

    Agreed on the oversight, however I forgot to mention that the "outsourcing company" actually consists in something like 5 people coding away. In this case, it seems that all of them  are bad coders. I'm pretty sure that they will never get another project again. The SQL Injection finding was reported to them ... more than a year ago. They haven't fixed it, so the in-house devs are fixing those things as well.



  • Just out of interest, have the outsourcers actually received any cash for this rubbish?



  • @danixdefcon5 said:

    @Jaime said:

    Third, $30k isn't a big deal, even outsourced.  I paid well into six figures for my last outsourced conversion of a 30,000 line VB6 app converted to .Net.

    Check my location. $30k is well over my yearly income, and I'm  already in the upper side of the average income for Sysadmin/DBA people. But the resulting code is something I'd expect from someone being paid $20.

    I noticed your location when you I originally posted.  I can see why we outsource to India and China here in the US, we save a ton of money but lose oversight.  We usually end up spending a lot of the savings fixing exactly the problems you are experiencing.  What I can't understand is why anyone would outsource to the land of $15US-per-hour programmers when local programmers cost about the same.  Outsourcing barely makes economic sense here in the US, why are you even considering it?  Just because the outsourced programmers don't make much less than you doesn't mean you should expect higher quality from them.  Outsourcing takes a lot of management if you want good results.

    @danixdefcon5 said:

    @Jaime said:

    Second, anyone who creates a web site with a single SQL Injection vulnerability has no idea what they are doing.  If they had to "check for SQL injection attacks", then they were doing it wrong.  If you do it any one of ten right ways, you can completely forget about injection forever.

    The fun thing is that 'checking for SQL Injection attacks' wasn't in our list, at least not originally. It was after one of the management guys started reading about SQL Injection stuff that we started probing the app. But then again, the fact that the thing was already a boo-boo was pretty much common knowledge, so anything would be expected. Note: the app also crashed after 30-ish users loaded the main page ... because some of the DB code didn't even close the DB connections.

    The rewrite is actually implementing "SQL injection safe" stuff.

    If you guys just learned about SQL Injection, you shouldn't be writing web apps.  Wait until you learn about cross-site scripting, or "Padding Oracle" attacks.



  • @Jaime said:

    I noticed your location when you I originally posted.  I can see why we outsource to India and China here in the US, we save a ton of money but lose oversight.  We usually end up spending a lot of the savings fixing exactly the problems you are experiencing.  What I can't understand is why anyone would outsource to the land of $15US-per-hour programmers when local programmers cost about the same.  Outsourcing barely makes economic sense here in the US, why are you even considering it?  Just because the outsourced programmers don't make much less than you doesn't mean you should expect higher quality from them.  Outsourcing takes a lot of management if you want good results.
    I was thinking about that, but presumably if a job's not what you do, you would expect to hire in someone from outside to do it. A lot of outsourcing isn't done to cut costs, but because people imagine it will be done better, or with more come-back, than if done in-house.



  • I know that outsourcing is ridiculous, and it wasn't to India ... it was a local developer house which shall remain unnamed. These guys just learned it the hard way ... the project was already going to hell when I started working there. Even then, it took them a full year to finally realize everything was FUBAR'd. I'd like to add that no-one had even checked out the source code before sending it into production. The $30k was only for the stuff that actually crawled its way into production, I think the total cost was going to be something like $200k... but that's been obvioulsy cancelled.

    @Jaime said:
    If you guys just learned about SQL Injection, you shouldn't be writing web apps.  Wait until you learn about cross-site scripting, or "Padding Oracle" attacks.

    SQL Injection was one of the key issues I pointed out in my original plan. All the in-house stuff has been coded from the ground up to avoid those attacks; the problem  was that the outsourced project didn't follow those guidelines.



  • @Jaime said:

    First of all, VB.Net isn't a fail.  Every stupidity that happened would have still happened if you forced them to do in all in C#.
    You are absolutely correct.  The only real-world difference between VB.NET and C# is the color of the candy coating.  After compiling, the chocolate inside (the MSIL instructions) are the same.

    Outside of real-world differences, there are a few things that have implementations in C# that weren't implemented in VB.NET.  Even VB6 wasn't bad as long as you didn't try to go beyond the limitations it had.  If you were running into VB6's limits, you were using the wrong tool for the job.

    I've said it before to many people:  Bad code in Visual Basic will crash the app.  Bad code in C++ will crash the OS.  (and the reason there are more bad coders in VB is because the ones that did it in C++ have their heads on pikes due to the angry mob of users)



  • @henke37 said:

    Of course not, it is clearly using POP3 instead.

    Oh, ok. I was going to say...



  • @Jaime said:

    First of all, VB.Net isn't a fail.  Every stupidity that happened would have still happened if you forced them to do in all in C#.

    Sorry, but VB.NET is a fail. Of course you can fail in C#, too, but...well, I've recently been forced to work on a legacy ASP.NET site in VB.NET (I normally do C#), and about every other day I find myself cursing VB.NET to the bowels of hell for some stupid syntax thing or another.



  • @toth said:

    Sorry, but VB.NET is a fail. Of course you can fail in C#, too, but...well, I've recently been forced to work on a legacy ASP.NET site in VB.NET (I normally do C#), and about every other day I find myself cursing VB.NET to the bowels of hell for some stupid syntax thing or another.

    I'm with you on this one. I'm maintaining a horrid winforms app right now that was originally written in VB6 and then ported to VB.NET. This steaming pile of fail has If blocks nested six deep (wtf) with no curly braces (wtf). It contains such gems as a 1500-line method (wtf) that takes eight string parameters by reference (wtf), plus four by value. Yes this atrocity could have been just as easily committed in C#, but in VB the missing braces and ByVal ByRef And Also Not For Each bullshit makes me downright homicidal.



  • @Smitty said:

    I'm with you on this one. I'm maintaining a horrid winforms app right now that was originally written in VB6 and then ported to VB.NET. This steaming pile of fail has If blocks nested six deep (wtf) with no curly braces (wtf). It contains such gems as a 1500-line method (wtf) that takes eight string parameters by reference (wtf), plus four by value. Yes this atrocity could have been just as easily committed in C#, but in VB the missing braces and ByVal ByRef And Also Not For Each bullshit makes me downright homicidal.
    I'll give you sympathy for having to deal with auto-converted VB6->VB.NET monstrosities, but being unable to cope with type-specific block identifiers instead of generic block identifiers is a failure to adapt.  Is there a reason why the parameters are being passed in by reference instead of by value?  If they are being modified within the method (to then be used outside of the method), they should be passed in by reference.

    However, I just did some research on ByVal and ByRef in VB.NET, and apparently some funky crap is going on in some cases where even though you pass in by value, what you are actually passing in is a reference (the value you are passing in is a pointer to the object and passing it in by reference would actually make a pointer to the pointer to the object, which the compiler will complain about)

    This makes me glad that I have switched to Perl.



  • @smbarbour said:

    ...However, I just did some research on ByVal and ByRef in VB.NET, and apparently some funky crap is going on in some cases where even though you pass in by value, what you are actually passing in is a reference (the value you are passing in is a pointer to the object and passing it in by reference would actually make a pointer to the pointer to the object, which the compiler will complain about)...

    VB's pass by reference/value semantics are no different than pretty much every major language out there.  In VB, if you pass a reference (pointer) by value, then the procedure can mess with the object (you don't make a copy of the object, just the reference).  Same thing happens in C#, C, C++, and Java.  The C equivalent of VB's pass by value is to simply pass in a pointer variable, it behaves exactly the same way.  The C equivalent of VB's pass by reference is to use the & operator.



  • @danixdefcon5 said:

    Some time ago, a certain company outsourced a re-write of a site from  Java to .NET, ...

    I'd call this TRWTF. What the hell is a point in doing that? Both are well supported, neither performs significantly better and neither has shortage of programmers who know it.

    @danixdefcon5 said:

    ... and the word was to keep MVC, and that everything should be coded in C#. Of course, they dilligently did most of the site in VB.NET (first fail) and stuck all the Page_Load() code on the .aspx files (second fail). The login screens are smart enough to check for SQL injection attacks ... but the GET query strings did not (third fail). I actually was able to deface the dev site with a simple URL as a proof of concept, and to ask for a complete rewrite of this site.

    So it didn't fulfil the requirements. It should simply not be accepted—and not paid for, of course. Having option not to accept a bad work is supposed to be the advantage of outsourcing, no?



  • @danixdefcon5 said:

    a re-write of a site from  Java to .NET, and the word was to keep MVC, and that everything should be coded in C#. Of course, they dilligently did most of the site in VB.NET (first fail) and stuck all the Page_Load() code on the .aspx files (second fail).
    Going from Java to .NET is not a WTF. But going from a Java MVC application to an ASP.NET [b]Webforms[/b] application is where things went wrong.


    Why didn't they migrate to ASP.NET MVC?



  • @toth said:

    Seriously who decided to make the indexing operator and function call operator the same?
    Unless you want to index a function (is that even possible in VB? I think not), what's the big deal?

    Having said that, yes VB has a lot of stupid syntax IIRC (I try not to recall)

    @smbarmour said:

    This makes me glad that I have switched to Perl.
    My impression of Perl's syntax is that it's worse than VB. But that's just my informed opinion.



  • @Smitty said:

    Yes this atrocity could have been just as easily committed in C#, but in VB the missing braces and ByVal ByRef And Also Not For Each bullshit makes me downright homicidal.

    And of course poor devs can keep it all running with a liberal shake of On Error Resume Next. That one wtf alone deserves a place in the Seventh Circle of the Inferno.



  • @bjolling said:

    Why didn't they migrate to ASP.NET MVC?

    @danixdefcon5 said:

    Some time ago, a certain company outsourced a re-write of a site from  Java to .NET, and the word was to keep MVC, and that everything should be coded in C#. Of course, they dilligently did most of the site in VB.NET(...)



  • @Julia said:

    @Smitty said:
    Yes this atrocity could have been just as easily committed in C#, but in VB the missing braces and ByVal ByRef And Also Not For Each bullshit makes me downright homicidal.
    And of course poor devs can keep it all running with a liberal shake of On Error Resume Next. That one wtf alone deserves a place in the Seventh Circle of the Inferno.

    No, they usually can't.  VB.Net won't let you mix exception handling and "On Error" style error handling.  So, if an exception handler already exists, they won't be able to add On Error Resume Next.



  • @Zecc said:

    @toth said:
    Seriously who decided to make the indexing operator and function call operator the same?
    Unless you want to index a function (is that even possible in VB? I think not), what's the big deal?

    Imagine you are coming from another .NET language (like C#) and you come across this line of code:


    ...New ISomeInterface()...

    as I did. It took me a minute to realize that no, it wasn't instantiating an interface (which is what had me scratching my head), it was instantiating an array of interface types.




    Or you see this:


    IsVisible(aParameter)

    Is it a method call? Or an indexed property? Sure, if the code is nicely designed then the identifier should make it clear whether it's a property or a method, but if the code is designed by the sort of outsourced developers who have database schemas that include fields called "Varchar1" and "Date1", then good luck assuming competence.




    Oh, and how about the line continuation operator? Granted, I haven't worked with every language, but I haven't encountered a single other language that requires you to add a "_" to the end of a line if you're continuing it on the next line. And apparently it's impossible to do something like this:


    New String() { _
    "Value1", _ 'this value represents blah
    "Value2" _ 'this value represents foo
    }

    I guess the parser regards comments as code...for this purpose alone.




    I could go on...



  • @toth said:

    Oh, and how about the line continuation operator? Granted, I haven't worked with every language, but I haven't encountered a single other language that requires you to add a "_" to the end of a line if you're continuing it on the next line. And apparently it's impossible to do something like this:
    New String() { _
    "Value1", _ 'this value represents blah
    "Value2" _ 'this value represents foo
    }

    I guess the parser regards comments as code...for this purpose alone.

    VB.Net doesn't do that any more.  Line continuation is now implicit.  Line continuation is different in VB because line ends aren't simply whitespace.  As a trade-off, you can't make a misplaced semicolon error in VB -- some of those are really difficult to figure out.

    The technical reason why you couldn't put a comment at those location is that the parser sees line continuation as any line that ends in <space><underscore>.  Neither of those two lines end properly.  This allowed the prepocessor to combine continued lines before parsing them.  In VB.Net 2010, the parser simultaneously combines lines and parses them, which is a fairly complicated task.



  • @toth said:

    Imagine you are coming from another .NET language (like C#) and you come across this line of code:

    ...New ISomeInterface()...

    as I did. It took me a minute to realize that no, it wasn't instantiating an interface (which is what had me scratching my head), it was instantiating an array of interface types.




    Or you see this:

    IsVisible(aParameter)

    Is it a method call? Or an indexed property? Sure, if the code is nicely designed then the identifier should make it clear whether it's a property or a method, but if the code is designed by the sort of outsourced developers who have database schemas that include fields called "Varchar1" and "Date1", then good luck assuming competence.

    Okay, I stand corrected. The first case in particular looks pretty painful.@Jaime said:
    In VB.Net 2010, the parser simultaneously combines lines and parses them, which is a fairly complicated task.
    Is that the metallic taste of irony I feel in my mouth?



  • @Jaime said:

    VB.Net doesn't do that any more.  Line continuation is now implicit.  Line continuation is different in VB because line ends aren't simply whitespace.  As a trade-off, you can't make a misplaced semicolon error in VB -- some of those are really difficult to figure out.

    The technical reason why you couldn't put a comment at those location is that the parser sees line continuation as any line that ends in <space><underscore>.  Neither of those two lines end properly.  This allowed the prepocessor to combine continued lines before parsing them.  In VB.Net 2010, the parser simultaneously combines lines and parses them, which is a fairly complicated task.

    By "anymore", I assume you mean as of .NET 4.0? Because this project is targeting 3.5 and it throws up without them. And as much as I would love to be on 4.0, there are things that are holding that transition up, so I'm stuck with 3.5 for now.



  • @toth said:

    @Zecc said:
    @toth said:
    Seriously who decided to make the indexing operator and function call operator the same?
    Unless you want to index a function (is that even possible in VB? I think not), what's the big deal?
    Imagine you are coming from another .NET language (like C#) and you come across this line of code:
    ...New ISomeInterface()...

    as I did. It took me a minute to realize that no, it wasn't instantiating an interface (which is what had me scratching my head), it was instantiating an array of interface types. 

    Here is what it looks like in the IDE:

    The tooltip clearly states that it is an interface and the syntax isn't identical.  Notice that an array instantiation requires a literal, while a class instantiation does not.

    The declaration is equally clear.  Here is the tooltip if you hover over x:

    In short, you are not familiar with the language and you got confused over the syntax.  Not a WTF.



  • I'm able to read and understand VB just fine; I still find the syntax to be verbose, fugly and hold-your-hand-ish.



  • @Jaime said:

    Notice that an array instantiation requires a literal, while a class instantiation does not.
     

    Unless that class's only constructor takes an Integer.



  • @Jaime said:

    @toth said:
    @Zecc said:
    @toth said:
    Seriously who decided to make the indexing operator and function call operator the same?
    Unless you want to index a function (is that even possible in VB? I think not), what's the big deal?
    Imagine you are coming from another .NET language (like C#) and you come across this line of code:
    ...New ISomeInterface()...

    as I did. It took me a minute to realize that no, it wasn't instantiating an interface (which is what had me scratching my head), it was instantiating an array of interface types. 

    Here is what it looks like in the IDE:

    The tooltip clearly states that it is an interface and the syntax isn't identical.  Notice that an array instantiation requires a literal, while a class instantiation does not.

    The declaration is equally clear.  Here is the tooltip if you hover over x:

    In short, you are not familiar with the language and you got confused over the syntax.  Not a WTF.

    No; in short, it uses the same operator for two vastly different operations, contrary to virtually every other modern language. The point isn't that I can't figure out VB.NET, it's that it uses stupid, clumsy syntax.



  • @powerlord said:

    @Jaime said:

    Notice that an array instantiation requires a literal, while a class instantiation does not.
     

    Unless that class's only constructor takes an Integer.

    Still not the same, an array literal is in curly braces.

    Class with single integer constructor:

    x = New ISomeClass(4)

    Interface array:

    x = ISomeInterface() {}



  • @toth said:

    By "anymore", I assume you mean as of .NET 4.0? Because this project is targeting 3.5 and it throws up without them. And as much as I would love to be on 4.0, there are things that are holding that transition up, so I'm stuck with 3.5 for now.
    Ah, you're also in the same predicament we are. We were supposed to switch over to 4.0 with the new Visual Studio 2010 upgrade ... except somebody made a doo-doo and bought the VS 2008 upgrade instead.

    So now we're stuck with 3.5, fortunately most of our stuff was targeted at 3.5 so no harm done. One of the WTFs on this project is that most of the devs were using VS 2010 Beta for the project. Sheesh.

    BTW, some may see the Java to .NET as a WTF, some may not ... but given the reason why this switch was mandated, and  the fact that the switch rendered a $1million+ recently-purchased UNIX server + BEA Weblogic licenses obsolete. The why they changed ... well... one of the dev guys was trying to keep the job, as he doesn't know anything beyond .net. Meh.



  • @toth said:

    @Jaime said:
    @toth said:
    @Zecc said:
    @toth said:
    Seriously who decided to make the indexing operator and function call operator the same?
    Unless you want to index a function (is that even possible in VB? I think not), what's the big deal?
    Imagine you are coming from another .NET language (like C#) and you come across this line of code:
    ...New ISomeInterface()...

    as I did. It took me a minute to realize that no, it wasn't instantiating an interface (which is what had me scratching my head), it was instantiating an array of interface types. 

    Here is what it looks like in the IDE:

    The tooltip clearly states that it is an interface and the syntax isn't identical.  Notice that an array instantiation requires a literal, while a class instantiation does not.

    The declaration is equally clear.  Here is the tooltip if you hover over x:

    In short, you are not familiar with the language and you got confused over the syntax.  Not a WTF.

    No; in short, it uses the same operator for two vastly different operations, contrary to virtually every other modern language. The point isn't that I can't figure out VB.NET, it's that it uses stupid, clumsy syntax.
    I never made a rebuttal on the indexer versus method confusion, I agree they can sometimes be confused.  It's a fairly minor point.  I'll trade that for VB's event syntax any day.  The C# event syntax is the classic case of inappropriate operator overloading.  The other use of parentheses that can get confusing is with generics.  Once again, it's something I deal with every day and it's one negative that comes with a heap of positives.  For example, since you're stuck on 3.5, that means you still can't use optional or named parameters.

    However, the point of my reply that you replied to was about interface arrays vs. constructors, which are easy to tell apart as the arrays instantiation always has curly braces and class construction never has curly braces.  The only way you could be confused is if you weren't familiar with the syntax.  The original line of code you posted ( ... New ISomeInterface() ... ) wasn't complete and wouldn't compile as is.  Once you fix it, it isn't confusing any more, hence my conclusion that you were confused due to unfamiliarity, not syntax.



  • @toth said:

    No; in short, it uses the same operator for two vastly different operations, contrary to virtually every other modern language. The point isn't that I can't figure out VB.NET, it's that it uses stupid, clumsy syntax.

    Agreed. VB should've gone the way of COBOL, but there was no Dijkstra around this time to tell CS majors to sod off that language. MS actually had a chance when they went into .NET, but it seems that they feared losing the VB code monkeys. So they morphed it into something that looks like VB, but is actually C# with goofy syntax.



  • @danixdefcon5 said:

    @toth said:

    No; in short, it uses the same operator for two vastly different operations, contrary to virtually every other modern language. The point isn't that I can't figure out VB.NET, it's that it uses stupid, clumsy syntax.

    Agreed. VB should've gone the way of COBOL, but there was no Dijkstra around this time to tell CS majors to sod off that language. MS actually had a chance when they went into .NET, but it seems that they feared losing the VB code monkeys. So they morphed it into something that looks like VB, but is actually C# with goofy syntax.

    Filed under: <FONT color=#698d73>On Error Resume Next should be banned.</FONT>

    On Error Resume Next was banned, 10 years ago.  Stop with the straw man arguments.

    Complaining about VB because of the atrocities you've seen committed in it is like not liking people because of the language they speak.  Let me give you an example:

    Bob is a bigot.  Bob's only exposure to Spanish speaking people has been being mugged by gang members speaking Spanish, losing a menial job due to competiton from illegal workers that speak Spanish, and all of the Spanish speaking people that rob the public health care system on his dime (Bob's perspective, of course).  Bob thinks that all Spanish speaking people are lazy law breakers that want his money.  Bob thinks the world would be a better place if the Spanish language was banned.

    That rediculous story is a very close parallel to your argument against VB.  The term "VB code monkeys" is as close to a racial slur as you can get on a topic other than race.  BTW, Microsoft has not only not killed VB, but they have committed to introducing new language features in VB and C# simultaneously.



  • @Jaime said:

    On Error Resume Next was banned, 10 years ago.

     

     VB .NET isn't 10 years old yet.  And VB6 not only allows but in certain unusual cases requires "On Error Goto Next"; there are certain errors that do not get caught with On Error Goto label.



  • @Cat said:

    @Jaime said:

    On Error Resume Next was banned, 10 years ago.

     

     VB .NET isn't 10 years old yet.  And VB6 not only allows but in certain unusual cases requires "On Error Goto Next"; there are certain errors that do not get caught with On Error Goto label.

    I was teaching beta versions of .Net 10 years ago.  I only rounded up about 16 months for the release version.  As for VB6, who cares if it allows or requires On Error Resume Next?  Extended support for VB6 ended years ago.

    However, since you brought it up, it's strange that the C# guys are bringing up On Error Resume Next as an evil feature of VB6.  On Error Resume Next allows error handling very similar to traditional C error handling.  In modern terminology, C functions gave a "no-throw guarantee" and often indicated success or failure by setting a global variable named "errno".  On Error Resume Next also gives a "no-throw guarantee" and sets Err.Number if the call fails.  Old-fashioned C programmers often used On Error Resume Next when forced to write VB, so the error handling patterns they knew would still apply.  Personally I'm a "strong guarantee" type of guy, I like to throw exceptions instead of returning error codes because it becomes immediately obvious when someone forget to do error handling.  See this reference if you are unfamiliar with exception guarantees.

    As for On Error Goto label not working, the only time I've seen this is if you use something other than Resume to jump out of the previous error handler, which is not allowed.

    BTW, I once met someone that refused to upgrade to VB.Net because Gosub had been dropped from the language.  Anyone using On Error Resume Next after 2/13/2002 is in the same category as that guy.



  • @Jaime said:

    BTW, Microsoft has not only not killed VB, but they have committed to introducing new language features in VB and C# simultaneously.


    In fact VB.NET and C# are not separate languages. They are just two syntaxes for the same language. You can, using standard .NET components (System.CodeDom.Compiler), parse VB and write it back as C# and vice versa.



  • @bjolling said:

    Going from Java to .NET is not a WTF.

    Yes, it is. Just as going from Java to .NET would be. As long as the old code was working, the platform it used is still supported and the new platform is not revolutionary better, starting from scratch is throwing money out of the window.

    It can take almost zero advantage of the work done on the old version, usually having all the bugs that were already fixed or worked around in the old version and taking as long as the old version did to develop. On the other hand refactoring tends not to reintroduce problems and they can be fixed early since working version is available throughout, which can even be deployed if the need arises. So unless the new platform makes development, operation or maintenance that much cheaper, it does not pay to switch.



  • @smbarbour said:

    Bad code in C++ will crash the OS.

    Only true for ancient operating systems like DOS and pre-NT windowses. Mac OS 9 and earlier too I think. Not sure about OS/2. Any halfway modern OS uses protected mode which prevents applications from messing with each other and with the OS.

    Of course, most operating systems require drivers to be written in C, and bad driver code can crash the OS. So in that sense it's not possible to crash the OS with VB code.



  • @tdb said:

    Not sure about OS/2

    No, OS/2 kept running merrily along. It was one of the nice things about it.



  • @Jaime said:

    I never made a rebuttal on the indexer versus method confusion, I agree they can sometimes be confused.  It's a fairly minor point.  I'll trade that for VB's event syntax any day.  The C# event syntax is the classic case of inappropriate operator overloading.  The other use of parentheses that can get confusing is with generics.  Once again, it's something I deal with every day and it's one negative that comes with a heap of positives.  For example, since you're stuck on 3.5, that means you still can't use optional or named parameters.

    However, the point of my reply that you replied to was about interface arrays vs. constructors, which are easy to tell apart as the arrays instantiation always has curly braces and class construction never has curly braces.  The only way you could be confused is if you weren't familiar with the syntax.  The original line of code you posted ( ... New ISomeInterface() ... ) wasn't complete and wouldn't compile as is.  Once you fix it, it isn't confusing any more, hence my conclusion that you were confused due to unfamiliarity, not syntax.

    But compare it to, say, C#, and the confusion (that particular confusion, that is) wouldn't happen. Even at a glance, new ISomeInterface() is different from new ISomeInterface[]. And square brackets are the standard CS idiom for subscripting. I assume that VB.NET's use of parens is a leftover from being adapted from VB6, in that they wanted to make it easier for VB6 developers to switch to VB.NET? Still, you'd think they could correct it to be in line with, well, pretty much every other language currently in use. Oh yeah, and the generics syntax is fucking annoying, too, thanks for reminding me.



  • @Cat said:

    And VB6 not only allows but in certain unusual cases requires "On Error Goto Next"; there are certain errors that do not get caught with On Error Goto label.
     

    This I didn't know (and I've spent many years with VB and have done unmentionable things with it). I seem to remember some instances where normal programming wouldn't catch an error; I think with the common dialog you need to have an on error goto to handle the case where a user cancelled the dialog. But I've never seen a case where on error goto label wouldn't work and on error resume next would.

    However, http://msdn.microsoft.com/en-us/library/5hsw66as%28VS.80%29.aspx tells me:

    @MSDN said:

    The On Error Resume Next construct may be preferable to On Error GoTo when handling errors generated during access to other objects. Checking Err
    after each interaction with an object removes ambiguity about which
    object was accessed by the code. You can be sure which object placed the
    error code in Err.Number, as well as which object originally generated the error (the object specified in Err.Source).



  • @toth said:

    No; in short, it uses the same operator for two vastly different operations, contrary to virtually every other modern language. The point isn't that I can't figure out VB.NET, it's that it uses stupid, clumsy syntax.

    Nope, sorry. From the other thread, we know it's impossible to dislike C++'s features without being "too dumb to write C++." The only logical conclusion to draw here is that you're simply too dumb to write VB.net. Sorry.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.