Reason #84883 I hate VB.net


  • Garbage Person

    So I'm really bored with working through the bug queue and have no looming feature deadlines, so I'm turning towards the warnings Visual Studio issues on compile. Extraneous HTML tags, stuff like that. And then I get to this:

    Warning    13    Function without an 'As' clause; return type of Object assumed.    C:\Users\Tony\Documents\Visual Studio 2008\Projects\Customer\CustomerInternal\ManageUserGroups.aspx.vb    91    22    C:\...\CustomerInternal\

    I'm thinking "Oh god what have my cohorts done!?" and dive in to fix the crisis waiting to happen. And then I find this:

        Private Function clearForm()
            gvwUserGroups.DataBind()
            txtGroupDescription.Text = ""
            txtGroupName.Text = ""

            For Each item In cblGroupRoles.Items()
                item.Selected = False
            Next
            Return Nothing
        End Function
     

    *headdesk*

    I guess it's understandable - VB doesn't have a "void" return type and the original team WAS trained in Java, C# and C++ - so why should they be expected to instinctively know that VB is a bastard and calls void methods "sub"?


  • Garbage Person

     And now I'm REALLY bored - because I've cleared the entire Warnings queue. Shit.



  • @Weng said:

    VB doesn't have a "void" return type and the original team WAS trained in Java, C# and C++ - so why should they be expected to instinctively know that VB is a bastard and calls void methods "sub"?
    Seriously? I had seen that differentiation in Ada 95 (don't ask) and though it was the dumbest thing I'd seen in a language. No idea it existed in modern (so to speak) languages.Well, seeing as you have nothing else to do, you might as well start porting it to a different language :P



  • Yes, VB uses subs instead of functions with return type Void. Pick up a copy VB for Dummies and it'll be on page 3 I suppose. The fact that the dev team had no proper training is no excuse because VB uses subs extensively in auto-generated code (for instance, event handlers for buttons and the likes)

     Anyway, REAL developers would have turned on Option Strict, and we wouldn't be talking about this...

    EDIT: Real developers forced to work wih VB, that is...


  • TRWTF is using VB.net. Especially when you are skilled in C#, which is also .net, can be combined with VB (in case you already have some VB codebase to reuse) and is actually a decent language.



  • @Bulb said:

    TRWTF is using VB.net. Especially when you are skilled in C#, which is also .net, can be combined with VB (in case you already have some VB codebase to reuse) and is actually a decent language.
    Some of our employers dictate that we must use VB.NET instead of C#. It's not a WTF to use VB. It's a WTF to use VB with option strict off, though. And it's a WTF to use a language without learning it or heeding its warnings, as the OP's peers did.



  • Delphi/Pascal also differentiates between "procedure" and "function". To make matters worse, if there are no parameters, the proc/func can be called without parentheses, so it's sometimes hard to tell the difference between

     a = some_var_or_object

    and

    a = some_function



  • @gramie said:

    Delphi/Pascal also differentiates between "procedure" and "function". To make matters worse, if there are no parameters, the proc/func can be called without parentheses, so it's sometimes hard to tell the difference between

     a = some_var_or_object

    and

    a = some_function

    Be glad you didn't work with pre-.NET versions of VB then. Those didn't have a "return" statement.
    Instead, you assigned the return value to a special variable that has the same name as the function you're in. Yes, this was in addition to the afromentioned rule about parantheses. And yes, if your function had parameters (so there is no ambiguity for the compiler) you could also read from that special variable.

    All of that, together with recursive calls could give you some of the most beautiful possibillities for obfuscation...

    Public Function TreeToString(Root as Node) as String
     Dim i as Node
     TreeToString = Root.Name & "("
     For Each i in Root.Children
      TreeToString = TreeToString & TreeToString(i)
     Next i
     TreeToString = TreeToString & ")"
    End Function



  • Wow?  Someone else to clean up all my warnings?  How do I sign up for this??

    I stupidly spend all the time at the end of a project clearing up warnings and adding annotation.



  • @PSWorx said:

    Be glad you didn't work with pre-.NET versions of VB then.


    And don't forget VBScript that was sort of like VB but not quite. Unfortunately I can't forget VBScript .. it is the scripting language of choice for a major commercial product I use.



  • @Weng said:

    So I'm really bored with working through the bug queue and have no looming feature deadlines, so I'm turning towards the warnings Visual Studio issues on compile. Extraneous HTML tags, stuff like that.

    Anywhere I work we have a strict rule that the code always compiles without warnings and you do not check anything in if it generates one.


  • @DaveK said:

    @Weng said:

    So I'm really bored with working through the bug queue and have no looming feature deadlines, so I'm turning towards the warnings Visual Studio issues on compile. Extraneous HTML tags, stuff like that.

    Anywhere I work we have a strict rule that the code always compiles without warnings and you do not check anything in if it generates one.
     

    It also depends on the language and compiler/tool that is generating the warnings.  For instance, java can get cluttered with useless warnings because of unused imports and not having a serialization ID.



  • @DaveK said:

    Anywhere I work we have a strict rule that the code always compiles without warnings and you do not check anything in if it generates one.

     

    hmmm... wasn't there someone else who was really keen on solving all warnings...?

     @tster said:

    It also depends on the language and compiler/tool that is generating the warnings.  For instance, java can get cluttered with useless warnings because of unused imports and not having a serialization ID.

    And, as your example shows, from the editor/IDE you're using. Those Java warnings are really useless indeed, but at least if you're using Eclipse, you can get rid of them in a matter of clicks.



  • This sub-vs-function thing goes back to at least QuickBASIC 4.5. I don't know if it's a Microsoft thing or a line-number-less-BASIC thing.



  • @tster said:

    @DaveK said:

    @Weng said:

    So I'm really bored with working through the bug queue and have no looming feature deadlines, so I'm turning towards the warnings Visual Studio issues on compile. Extraneous HTML tags, stuff like that.

    Anywhere I work we have a strict rule that the code always compiles without warnings and you do not check anything in if it generates one.
     

    It also depends on the language and compiler/tool that is generating the warnings.  For instance, java can get cluttered with useless warnings because of unused imports and not having a serialization ID.

    Agreed.  PHP generates so many useless "notice" and "strict" warnings it's sad.  Dealing with them all would add significant time to any project and results in tons of boilerplate code that bloats file size, slows execution, increases the number of places a bug could slip in and creates more work for maintenance programmers.


  • Garbage Person

    @DaveK said:

    Anywhere I work we have a strict rule that the code always compiles without warnings and you do not check anything in if it generates one.
    Excuse me for a moment while I channel the project managers (there were five of them - at once - on a team of 17) from the initial buildup to 1.0 for this project - "That's not agile. It adds extra needless time between iterations and slows down velocity."

    Interestingly enough, this is also the reason why we were programming in VB - and also why we bought^h^h^h^h^h^h^hlicensed for six months a $15,000 piece of software (called Mingle if anyone is unlucky to be familiar with it) that amounts to nothing more than a very shiny, ajaxy bugtracker that ticks all the Agilista vocabulary boxes.

    Of course the BARE MINIMUM features weren't actually usable or to-spec until v1.1.6 - three months after project transfer from the agile team (which celebrated its huge success at v1.0) to a single-man team (me) and v1.2.0 is getting built tonight, v1.2.1 by Friday - and I don't intend to actually sign off to the maintainers until v2.0.<functional minor release>



  • @Weng said:

    @DaveK said:
    Anywhere I work we have a strict rule that the code always compiles without warnings and you do not check anything in if it generates one.
    Excuse me for a moment while I channel the project managers (there were five of them - at once - on a team of 17) from the initial buildup to 1.0 for this project - "That's not agile. It adds extra needless time between iterations and slows down velocity."

    Given the number of bugs I've found and fixed *because* of heeding warnings, I'd say the converse is true: ignoring the warnings is slowing down velocity by introducing bugs which could have been fixed quicker up front.

    Of course, Morbius will simply point out all the useless warnings from PHP, and I'll point out that's an indication he should get a real programming language, where warnings mean something.  And he'll probably say he has a real programming language, or something like that.  Could we just skip all that somehow?


  • Garbage Person

     @tgape said:

    I'd say the converse is true: ignoring the warnings is slowing down velocity by introducing bugs which could have been fixed quicker up front.
    Excuse me while I channel my project managers again: "Agile produces bug-free code because of frequent inspection by the customer."

    Here's a hint on just how bad code quality (and spec quality - I've NEVER seen so many contradictory spec changes in my life) throughout this project was: Average velocity was 3, with 1 being the target. We "finished" exactly on schedule, and only because of some absolute heroism from some dev team members.



  • @tgape said:

    Of course, Morbius will simply point out all the useless warnings from PHP, and I'll point out that's an indication he should get a real programming language, where warnings mean something.  And he'll probably say he has a real programming language, or something like that.  Could we just skip all that somehow?

    So quality of the warnings is what makes a "real" programming language?  The warnings in PHP often are retarded but they are easy to silence.  As it is, it's a minor gripe and I like PHP.  It's not great--no language is--but it's good which is more than most languages can lay claim to.  What do you think a "real" language would be?


  • Garbage Person

    @morbiuswilters said:

    I like PHP.
    And to think I used to like you.

     Then again, maybe my problem with PHP isn't so much the language as the quality of code most people manage to write with it.... And the quality of programmer that considers themselves the hottest thing since sliced bread.



  • @Weng said:

    @morbiuswilters said:
    I like PHP.
    And to think I used to like you.

    I still like you... *sniffle*

     

    @Weng said:

    Then again, maybe my problem with PHP isn't so much the language as the quality of code most people manage to write with it.... And the quality of programmer that considers themselves the hottest thing since sliced bread.

    Agreed.  This is actually one of the reasons I like PHP--it acts as sort of a litmus test for bad programmers.  Whereas mediocre programmers can usually bluff their way through stricter languages because of the stiff requirements of the compiler, PHP requires a bit more self-discipline.  In my experience, you can quickly tell the programmers who lack discipline and don't understand the language very well.  Of course, that doesn't do much to reduce the amount of shitty PHP code, but it helps me size up the quality of a developer or library in short order.



  • @Sir Twist said:

    This sub-vs-function thing goes back to at least QuickBASIC 4.5. I don't know if it's a Microsoft thing or a line-number-less-BASIC thing.

    Neither.  It goes back [i]at least[/i] as far as the original PASCAL, which is a few years older than Microsoft, and the idea is very likely older still.

    Microsoft didn't even introduce it to BASIC.  It was present in at least one 1980s dialect of BASIC which had nothing to do with Microsoft (and did have line numbers).



  • @PSWorx said:

    @DaveK said:

    Anywhere I work we have a strict rule that the code always compiles without warnings and you do not check anything in if it generates one.

     

    hmmm... wasn't there someone else who was really keen on solving all warnings...?

      It should be pointed out that valgrind warnings are an entirely different kind of thing from compiler warnings, far more complex to interpret and know what to do with.

    And yeh, we have another rule that you don't just fix a warning by (e.g.) blindly adding a cast without understanding what's going on.




  • @tgape said:

    @Weng said:
    @DaveK said:
    Anywhere I work we have a strict rule that the code always compiles without warnings and you do not check anything in if it generates one.
    Excuse me for a moment while I channel the project managers (there were five of them - at once - on a team of 17) from the initial buildup to 1.0 for this project - "That's not agile. It adds extra needless time between iterations and slows down velocity."

    Given the number of bugs I've found and fixed *because* of heeding warnings, I'd say the converse is true: ignoring the warnings is slowing down velocity by introducing bugs which could have been fixed quicker up front.

    I think to judge from the sarcasm in Weng's post he probably agrees with you....  The one thing that is absolutely for sure is that if your devs are used to being faced with page after page of interminable warnings during a build, they will learn to tune it out, and will not notice when a new one starts appearing, even though it might indicate something serious.

     



  • @Iago said:

    @Sir Twist said:

    This sub-vs-function thing goes back to at least QuickBASIC 4.5. I don't know if it's a Microsoft thing or a line-number-less-BASIC thing.

    Neither.  It goes back at least as far as the original PASCAL, which is a few years older than Microsoft, and the idea is very likely older still.

    Microsoft didn't even introduce it to BASIC.  It was present in at least one 1980s dialect of BASIC which had nothing to do with Microsoft (and did have line numbers).

    BBC BASIC (1981) had named procedures and functions - and line numbers. I'm sure there are others. :)



  • @OzPeter said:

    Unfortunately I can't forget VBScript .. it is the scripting language of choice for a major commercial product I use.

    You don't have to anonymize Windows.



  •  @Weng said:

    Here's a hint on just how bad code quality ...throughout this project was: Average velocity was 3, with 1 being the target.

    It must be some indication on the metric usefulness of 'velocity' when the quote above immediately makes me think "What is the airspeed velocity of a laden swallow?" "three!" "no, one!"

    (Especially because, as a pedantic engineer, velocity must be a vector quantity and have units of "something per unit time". I hate debugging control system software where the units of parameters are not defined...and even this link didn't make me feel better about the term 'velocity' - it in fact made me more concerned about poor word choice.)



  • The SUBROUTINE versus FUNCTION distinction goes back as far as FORTRAN, mid-1950's. Some of us old geezers are still uncomfortable with "returns void" being a synonym for "doesn't return anything".



  • @AndyCanfield said:

    The SUBROUTINE versus FUNCTION distinction goes back as far as FORTRAN, mid-1950's. Some of us old geezers are still uncomfortable with "returns void" being a synonym for "doesn't return anything".

    Actually, it goes back to CAVTRAN, the oldest programming language, from caveman times.  Some of us old geezers are still uncomfortable with keyboards and sabretooth attacks.



  • @morbiuswilters said:

    Actually, it goes back to CAVTRAN, the oldest programming language, from caveman times.  Some of us old geezers are still uncomfortable with keyboards and sabretooth attacks.
    Ah, CAVTRAN.  Remember that major cockup when that rock we threw at the fiery sky god completely missed because of a units of measurement conversion error between "distance I could run before being caught by a saber-toothed tiger" and "distance I can throw a spear with enough power to piece the hide of a wooly mammoth"?



  • @gramie said:

    To make matters worse, if there are no parameters, the proc/func can be called without parentheses, so it's sometimes hard to tell the difference between

     a = some_var_or_object

    and

    a = some_function

    In Ruby, that is a feature. And you can even use it when there is parameters.



  • @Buzer said:

    @gramie said:

    To make matters worse, if there are no parameters, the proc/func can be called without parentheses, so it's sometimes hard to tell the difference between

     a = some_var_or_object

    and

    a = some_function

    In Ruby, that is a feature. And you can even use it when there is parameters.

    Yes, a "feature"...  Seriously, I find it easier to read Ruby code if the parens are there for function calls, even parameterless ones.



  • @morbiuswilters said:

    @Buzer said:

    @gramie said:

    To make matters worse, if there are no parameters, the proc/func can be called without parentheses, so it's sometimes hard to tell the difference between

     a = some_var_or_object

    and

    a = some_function

    In Ruby, that is a feature. And you can even use it when there is parameters.

    Yes, a "feature"...  Seriously, I find it easier to read Ruby code if the parens are there for function calls, even parameterless ones.

    I disagree.  They allow you to blur the line between attribute and method.


  • @bstorer said:

    @morbiuswilters said:

    @Buzer said:

    @gramie said:

    To make matters worse, if there are no parameters, the proc/func can be called without parentheses, so it's sometimes hard to tell the difference between

     a = some_var_or_object

    and

    a = some_function

    In Ruby, that is a feature. And you can even use it when there is parameters.

    Yes, a "feature"...  Seriously, I find it easier to read Ruby code if the parens are there for function calls, even parameterless ones.

    I disagree.  They allow you to blur the line between attribute and method.

    Yeah, but there are better (IMHO, at least) ways to do this, with properties (or whatever C# calls them).  It's not hard to emulate it in PHP, either.  I even though there was a better way to do it in Ruby, with operator overloading or method_missing.  I just don't like the lack of clarity that not using parens results in.  Maybe I'm just too stuck in my ways to appreciate Ruby, but there are aspects of C-style syntax that I find comforting and that help me quickly read and write code.



  • @bstorer said:

    @morbiuswilters said:

    @Buzer said:

    @gramie said:

    To make matters worse, if there are no parameters, the proc/func can be called without parentheses, so it's sometimes hard to tell the difference between

     a = some_var_or_object

    and

    a = some_function

    In Ruby, that is a feature. And you can even use it when there is parameters.

    Yes, a "feature"...  Seriously, I find it easier to read Ruby code if the parens are there for function calls, even parameterless ones.

    I disagree.  They allow you to blur the line between attribute and method.
    And how is that a good thing?


  •  @morbiuswilters said:

    Yeah, but there are better (IMHO, at least) ways to do this, with properties (or whatever C# calls them).
    Ruby cribs from Smalltalk, such that properties are methods are messages.  Ruby's attributes behave very similarly to C#.

    @morbiuswilters said:

    I even though there was a better way to do it in Ruby, with operator overloading or method_missing.
    The correct way to do it is to use attr_reader, attr_writer, and attr_accessor, or to write your own foo and foo= methods for a property named foo.

     @morbiuswilters said:

    I just don't like the lack of clarity that not using parens results in.
    I don't see a lack of clarity at all.  x.foo.bar is cleaner to me than x.foo().bar().

    @morbiuswilters said:

    Maybe I'm just too stuck in my ways to appreciate Ruby, but there are aspects of C-style syntax that I find comforting and that help me quickly read and write code.
    I'm not fond of Ruby's begin/end syntax, but I wouldn't want to go back to C, either.  I'd much prefer Python's indentation-based syntax.



  • @DescentJS said:

    @bstorer said:

    @morbiuswilters said:

    @Buzer said:

    @gramie said:

    To make matters worse, if there are no parameters, the proc/func can be called without parentheses, so it's sometimes hard to tell the difference between

     a = some_var_or_object

    and

    a = some_function

    In Ruby, that is a feature. And you can even use it when there is parameters.

    Yes, a "feature"...  Seriously, I find it easier to read Ruby code if the parens are there for function calls, even parameterless ones.

    I disagree.  They allow you to blur the line between attribute and method.
    And how is that a good thing?
    Take a language like C#.  You can create properties which generate wrappers around attributes.  Despite the fact that these properties can be complex functions, they don't use parens.  Member functions, on the other hand, do.  There's a false distinction created here.  What's the real difference between setting a point's x coordinate and moving it?


  • @bstorer said:

    @DescentJS said:

    @bstorer said:

    @morbiuswilters said:

    @Buzer said:

    @gramie said:

    To make matters worse, if there are no parameters, the proc/func can be called without parentheses, so it's sometimes hard to tell the difference between

     a = some_var_or_object

    and

    a = some_function

    In Ruby, that is a feature. And you can even use it when there is parameters.

    Yes, a "feature"...  Seriously, I find it easier to read Ruby code if the parens are there for function calls, even parameterless ones.

    I disagree.  They allow you to blur the line between attribute and method.
    And how is that a good thing?

    Take a language like C#.  You can create properties which generate wrappers around attributes.  Despite the fact that these properties can be complex functions, they don't use parens.  Member functions, on the other hand, do.  There's a false distinction created here.  What's the real difference between setting a point's x coordinate and moving it?

    Really, it's a continuation of the C++/Java idiom of "no public variables".  But instead of writing gobs of boilerplate accessor/mutator garbage, you get syntactic sugar to handle it for you.  I don't see the blurring as a bad thing (and neither do most people, considering the accessor/mutator idiom).  I guess I just prefer consistency in my method calls.  You can pass parameters without parens in ruby, but to me that is very messy looking.  Maybe I will get used to dropping parens on parameterless methods...



  • @bstorer said:

    x.foo.bar is cleaner to me than x.foo().bar().
     

    I guess that only is the case when you're already used to te concepts of properties not actually existing separately from methods.

    In languages where there are no getters/setters for properties, it's important to add the parens and keep the distinction explicit. In fact, in languages where functions ar first-class, such as Javascript, x.foo.bar has an entirely different meaning from x.foo().bar(). This is a much-loved feature, not an inconvenience.

    I prefer explicit code anyway, so I'd add the parens no matter what. But maybe that's a matter of blub.



  • @dhromed said:

    @bstorer said:

    x.foo.bar is cleaner to me than x.foo().bar().
     

    I guess that only is the case when you're already used to te concepts of properties not actually existing separately from methods.

    In languages where there are no getters/setters for properties, it's important to add the parens and keep the distinction explicit. In fact, in languages where functions ar first-class, such as Javascript, x.foo.bar has an entirely different meaning from x.foo().bar(). This is a much-loved feature, not an inconvenience.

    I prefer explicit code anyway, so I'd add the parens no matter what. But maybe that's a matter of blub.

     

    I'll weigh in:

    Methods on objects should either be an action (possibly with side effects) or a way to get something from an object that is not trivial (like have an object calculate a value that it needs to aggregate from it's members).  It is acceptable (but not recommended) for this "get" to have side effects. Methods can take as long as they want to return and can throw exceptions.

    Properties on object should never have side effects.  They should get soemthing trivial or simple.  They should almost never throw exceptions or do IO (note: this is not a hard rule).  Properties should be fast.  Specifically, you should be able to call a property many thousands of times in a loop without worrying about the performance.

     

    Here is my typical usage:

    I have an object with attributes and I wrap them with getter properties.  In the property definition I make sure that my attributes are loaded then I return.  The first time it is called it loads the attributes, then the second time it already has them so it just returns them.



  • @morbiuswilters said:

    Really, it's a continuation of the C++/Java idiom of "no public variables".  But instead of writing gobs of boilerplate accessor/mutator garbage, you get syntactic sugar to handle it for you.
    In Ruby's case it's actually a continuation of Smalltalk's private state/public messages structure.  All instance variables are private in Ruby. Without said sugar, people would get irritated really quickly.@morbiuswilters said:
    I guess I just prefer consistency in my method calls.  You can pass parameters without parens in ruby, but to me that is very messy looking.  Maybe I will get used to dropping parens on parameterless methods...
    In Ruby it's a stylistic choice.  You're welcome to use them, just as you can end lines with semicolons if it feels more comfortable for you.  But idiomatically, parens are used to remove ambiguity.



  • @tster said:

    I'll weigh in:

    Methods on objects should either be an action (possibly with side effects) or a way to get something from an object that is not trivial (like have an object calculate a value that it needs to aggregate from it's members).  It is acceptable (but not recommended) for this "get" to have side effects. Methods can take as long as they want to return and can throw exceptions.

    Properties on object should never have side effects.  They should get soemthing trivial or simple.  They should almost never throw exceptions or do IO (note: this is not a hard rule).  Properties should be fast.  Specifically, you should be able to call a property many thousands of times in a loop without worrying about the performance.

     

    Here is my typical usage:

    I have an object with attributes and I wrap them with getter properties.  In the property definition I make sure that my attributes are loaded then I return.  The first time it is called it loads the attributes, then the second time it already has them so it just returns them.

    Didn't you just break your own rule?  The first call to a property will "load" the data, if I'm understanding you.  I use properties mostly the way you do, except I don't do the loading in the getter.  For record-/ORM-type objects I usually do loading in the constructor if an ID or what-have-you is passed in or just make a "blank" object if nothing is passed.  Since the object knows if it was loaded or populated as a blank it can properly determine if it needs to do a SQL UPDATE or INSERT when the save() method is called.



  • @tster said:

    Properties on object should never have side effects.  They should get soemthing trivial or simple.  They should almost never throw exceptions or do IO (note: this is not a hard rule). 

     

    Agreed on the side effects. Still, there can be lots of situations where the property can't take all values of the underlying type and you'd very much want the getter to be able to throw exceptions.For example, if some bug assigns [code]null[/code] to a property that should always contain an object, I'd rather like my program to fail when the property is assigned than decades later, in a completely unrelated place, when the object is used.



  • @morbiuswilters said:

    So quality of the warnings is what makes a "real" programming language?

    One element of thousands.

    @morbiuswilters said:

    What do you think a "real" language would be?

    Perl 8.

    Yeah, I know - I'm not going to live that long.  A man can dream.



  • @morbiuswilters said:

    Agreed.  This is actually one of the reasons I like PHP--it acts as sort of a litmus test for bad programmers.  Whereas mediocre programmers can usually bluff their way through stricter languages because of the stiff requirements of the compiler, PHP requires a bit more self-discipline.  In my experience, you can quickly tell the programmers who lack discipline and don't understand the language very well.

    In that case, you should *love* Perl.  It has all kinds of features that sound neat, but turn out to be unwise.  I think that peaked around perl 5.8.8 or so... (well, technically, they didn't remove any of those features in perl 5.8.9, they just deprecated a bunch.)

    @morbiuswilters said:

    Of course, that doesn't do much to reduce the amount of shitty PHP code, but it helps me size up the quality of a developer or library in short order.

    And therein lies the real fly in the ointment.  With Perl, this fly's pretty ginormous.  (Although, since Perl's been declared dead, I think we're getting better - it seems a disproportionately large number of the bad coders have moved on to other languages, like PHP and Python.)



  • @tgape said:

    @morbiuswilters said:
    Agreed.  This is actually one of the reasons I like PHP--it acts as sort of a litmus test for bad programmers.  Whereas mediocre programmers can usually bluff their way through stricter languages because of the stiff requirements of the compiler, PHP requires a bit more self-discipline.  In my experience, you can quickly tell the programmers who lack discipline and don't understand the language very well.

    In that case, you should *love* Perl.  It has all kinds of features that sound neat, but turn out to be unwise.  I think that peaked around perl 5.8.8 or so... (well, technically, they didn't remove any of those features in perl 5.8.9, they just deprecated a bunch.)

    @morbiuswilters said:

    Of course, that doesn't do much to reduce the amount of shitty PHP code, but it helps me size up the quality of a developer or library in short order.

    And therein lies the real fly in the ointment.  With Perl, this fly's pretty ginormous.  (Although, since Perl's been declared dead, I think we're getting better - it seems a disproportionately large number of the bad coders have moved on to other languages, like PHP and Python.)

    Meh, shitty programmers have to go somewhere and it makes sense they'd go to a language made for the web that is fairly easy to use.  Honestly, I don't care much for language wars.  All languages have their strengths and weaknesses, period.  The only languages that piss me off are ones that make programming immensely tedious and overly complicated, like C++ and Java.



  • @morbiuswilters said:

    Meh, shitty programmers have to go somewhere

    I just wish it was to something that they could excel at, rather than staying in a field which requires more logic and coherency than they possess.  I was not attempting to make a dig at either PHP or Python, simply because I've met a few dozen mediocre Perl programmers who decided to infest the PHP and Python communities instead.

    @morbiuswilters said:

    The only languages that piss me off are ones that make programming immensely tedious and overly complicated, like C++ and Java.

    Personally, I think C++ has a valid excuse - when it was new, it was an improvement over the norm.  Not that I'm saying people should be using it now.  (Although, it does have its moments.  If I'm wanting to do some object-oriented code which is performance critical, C++ may make more sense than C or Objective C.  Usually, however, the actual performance-critical piece isn't itself object-oriented, so C works fine.  And, in any event, since it's only the performance-critical section, we're only talking 10-50 lines of code, normally.)



  • @tgape said:

    @morbiuswilters said:
    Meh, shitty programmers have to go somewhere

    I just wish it was to something that they could excel at, rather than staying in a field which requires more logic and coherency than they possess.  I was not attempting to make a dig at either PHP or Python, simply because I've met a few dozen mediocre Perl programmers who decided to infest the PHP and Python communities instead.

    Agreed.

     

    @tgape said:

    @morbiuswilters said:
    The only languages that piss me off are ones that make programming immensely tedious and overly complicated, like C++ and Java.

    Personally, I think C++ has a valid excuse - when it was new, it was an improvement over the norm.  Not that I'm saying people should be using it now.  (Although, it does have its moments.  If I'm wanting to do some object-oriented code which is performance critical, C++ may make more sense than C or Objective C.  Usually, however, the actual performance-critical piece isn't itself object-oriented, so C works fine.  And, in any event, since it's only the performance-critical section, we're only talking 10-50 lines of code, normally.)

    I have to disagree here.  Smalltalk precedes C++, as do several other good OO languages.  They weren't fast, usually, so I guess C++ was good there.  I wouldn't consider C++ a high-performance language.  It can be pretty good, but dynamic languages that run on a good VM (like the CLR) can kick ass.  If you really need performance, C is still the way to go.



  • @morbiuswilters said:

    I have to disagree here.  Smalltalk precedes C++, as do several other good OO languages.  They weren't fast, usually, so I guess C++ was good there.  I wouldn't consider C++ a high-performance language.  It can be pretty good, but dynamic languages that run on a good VM (like the CLR) can kick ass.  If you really need performance, C is still the way to go.


    Why do you consider the speed of C and C++ to be different? C++ with classes, but without the use of virtual functions is effectively C as the class vtables will be full of direct function pointers. And polymorphism isn't going to introduce too much overhead scanning down the hierarchy to find the actual function.



  • @Iago said:

    @Sir Twist said:

    This sub-vs-function thing goes back to at least QuickBASIC 4.5. I don't know if it's a Microsoft thing or a line-number-less-BASIC thing.

    Neither.  It goes back at least as far as the original PASCAL, which is a few years older than Microsoft, and the idea is very likely older still.

    Microsoft didn't even introduce it to BASIC.  It was present in at least one 1980s dialect of BASIC which had nothing to do with Microsoft (and did have line numbers).

     

    Goes back to the original fortran I believe.So does assigning to a variable with the same name as the function


Log in to reply