• A More Skilled Programmer than "Some Guy" (unregistered) in reply to wtf
    wtf:
    A More Skilled Programmer than "Some Guy":
    Some Guy:
    wtf:
    A More Skilled Programmer than "Some Guy":
    C#:
    public string GetJunk()
    {
      return "1";
    }
    
    FTFY

    Not a C# guy, but in most languages that would return "true", which is not what the VB or the original looked like they were doing. Am I missing something, or is your chosen screen name for this post taking on a bitter irony in your mouth right about now?

    Also, he misspelled "than".

    Well, at least my code would actually compile, sir.

    Um, no. Sorry. The code you "corrected" demonstrated a point about C# vs VB. Yours demonstrated your failure to grasp the point. Passing the compiler is sort of irrelevant in this case, don't you think?

    How can you possibly say that code that does not compile is a good example of how the language works?
  • wtf (unregistered) in reply to frits

    [quote user="frits"

    Reading is fundamental. When two things are the same, there is no ambiguity. [/quote]

    Strictly speaking, no. But anybody who cares to can construct two expressions in some propositional calculus (or in two related species of propositional calculus) that evaluate to the same thing, but are not obviously identical. They might not be ambiguous - each evaluates unambiguously to the same unambiguous expression - but the the syntax in which they are expressed does in fact matter greatly to comprehensibility.

    If two programs, one in C# and VB, generate the same intermediate code, there is no ambiguity, but one might be easier to write than the other, and one might be easier to read than the other. I think that was the point of the quoted comment - the word ambiguity was not used strictly, but we're not so pedantic that that should matter, are we?

    (I haven't had occasion to use any of the .net products, so I've got no dog in the fight - I'm just trying to keep the squabbling on track)

  • (cs) in reply to Markp
    Markp:
    Well that's where the analogy to a craftsman fails since craftsmen are often self-employed people pretty much fully in charge of their situation (and tools). I on the other hand worked for 4 months (co-op term) at a software shop that was supporting software running on versions of Java and 3rd party libraries that were 8-10 years out of support. 20% of the bugs that came in would be fixed by upgrading to newer versions of our dependencies. 5% of the new code we wrote already belonged to the newer standard libraries. Our development environment was centred around Netbeans 3.5 when 6.5 was 10 years newer and free.

    Can you imagine our frustration when every time we tried to invest in new tools and dependencies, management accused us of blaming our poor productivity and quality on our tools?

    Can you understand why we eventually would take a stance of blaming things on our tools?

    Fair enough, but it sounds like the tools weren't the only thing to blame there. In fact, I'd suggest that the tools weren't the cause of failure, but rather were effects from failure elsewhere (namely management). Then again, I'm just making assumptions; you certainly know your own situation better than I do.

    Either way, I can relate, having been in similar situations myself. Also, I agree with you that the craftsman analogy fails in this case (it tends to do so frequently when applied to programming).

  • m (unregistered) in reply to Jeff Dege
    Jeff Dege:
    B: the way ANSI said it should work (which was different that B).
    I don’t think it is so bad…
  • wtf (unregistered) in reply to A More Skilled Programmer than "Some Guy"
    A More Skilled Programmer than "Some Guy":
    How can you possibly say that code that does not compile is a good example of how the language works?

    If the one demonstrates a point about the issue in question - which, if you'll recall, was whether there is a fundamental difference in the capacities of VB and C# - and has a typo, and the other has no typos but not only fails to make any point about that issue, but doesn't even do what the "corrected" code was meant to do, then I'd say that the one with the typo was the better example.

    Clearly, "Some Guy" understands something about the underlying framework, and he was able to make his point. Your point seems to be that you don't get the point. But there's still time to actually say something useful, if you want, the day is still young.

  • Bus Logic (unregistered) in reply to frits
    frits:
    Bus Logic:
    frits:
    Bus Logic:
    This bizarre ambiguity between properties and functions is just one item on a very long list of inherent issues with VB.NET. I honestly have no idea why anyone would choose it over C# when targeting the .NET framework, unless they're just so bad at writing code that they can't make the switch from Microsoft's kiddie code to a real language.

    But properties and methods are the same thing in .Net, really. Properties are just syntatical sugar for getters and setters that can be abused to cause side effects and block indefinitely. The same is true for indexers. I'm not sure why you think C# is any better, because the underlying mechanism is the same. Disclaimer: I don't even like VB.Net.

    SYNTAX! The underlying mechanism may be the same but the C# syntax is vastly better because it removes the ambiguity. Did I really need to explain that to you? The whole point of today's article is the dodgy syntax, please keep up.

    Reading is fundamental. When two things are the same, there is no ambiguity.

    I'm not sure it's my reading comprehension that's at fault here but whatever, I'll try again. The syntax for property accessors is different between C# and VB.NET. It is the improved syntax of C# that makes it a superior language to VB. It doesn't matter whether this is "syntactic sugar" for some underlying concept, the simple fact remains that the syntax of C# is superior to the syntax of VB in regard to properties. What don't you understand here? I'm not trying to be difficult, I honestly don't understand where the confusion lies. I know perfectly well that properties are syntactic sugar for getters and setters but it doesn't change the fact that C# has a far better syntax when dealing with properties than VB.
  • John Holmes (unregistered) in reply to Anonymous

    I started on an Apple II in about 1980. My first home computer was also a VIC-20, but I had the 16K ram expansion. That gives me a good two inches on you. Length and circumference, buddy.

  • A More Skilled Programmer than "Some Guy" (unregistered) in reply to wtf
    wtf:
    A More Skilled Programmer than "Some Guy":
    How can you possibly say that code that does not compile is a good example of how the language works?

    If the one demonstrates a point about the issue in question - which, if you'll recall, was whether there is a fundamental difference in the capacities of VB and C# - and has a typo, and the other has no typos but not only fails to make any point about that issue, but doesn't even do what the "corrected" code was meant to do, then I'd say that the one with the typo was the better example.

    Clearly, "Some Guy" understands something about the underlying framework, and he was able to make his point. Your point seems to be that you don't get the point. But there's still time to actually say something useful, if you want, the day is still young.

    I have re-written the code to meet your less-than-rigorous standards:

    C#:

    public string GetJunk
      string junk is "1";
      if junk is "1" then return junk
    

    Your right, C# is easier than VB!

  • John Holmes (unregistered) in reply to Anonymous
    Anonymous:
    Steve The Cynic:
    Severity One:
    Steve The Cynic:
    Only me. And you, although maybe you went and looked it up.
    Alas... tomorrow is my 41st birthday, and I've been programming since the age of 13 (starting with BASIC on the TRS-80 model I). I also know what COBOL and APL stand for.

    COmmon Business Oriented Language A Programming Language.

    Signs of a mis-spent youth? Maybe.

    And I have 3.5 years on you. I started on a Commodore Pet, with the built-in cassette drive and the ghastly horrible keyboard. From there I progressed (?) to a Sinclair ZX80 (bounce, bounce, bounce).

    ((Editor's note: the only way to understand that last remark is to have used a ZX80, on a TV where the vertical hold control was set just, but only just, on the stable side of completely losing hold.))

    But, hey, my mother started programming on a LEO 3.

    In 1963.

    Awesome, it's fun to see the programmer's equivalent of dick measuring. I started coding on a Commodore VIC-20 so you guys both beat me, but only just. I remember sneering at the TRS-80 and its measly 4KB of RAM (I had 5KB, whoopee!).

    I started on an Apple II in about 1980. My first home computer was also a VIC-20, but I had the 16K ram expansion. That gives me a good two inches on you. Length and circumference, buddy.

    (whoops, it just isn't the same without quoting the original thread.)

  • (cs) in reply to Mark
    Mark:
    A Summary:
    Alex Papadimoulis:
    TRWTF is VB.

    Now that that's out of the way... let the actual commenting begin...

    Unoriginal Poster 1:
    VB sucks, and you should use C#.

    <snipped unoriginal quotes>

    Fascinating development: all posts are simple restating exactly what Alex wrote in the article.

    At least we're repeating what was in the article - you're repeating people repeating what was in the article, so you're the bottom feeder in this equation. How does that ass taste?
    Well you're simply restating what someone said who restated what people restated about what Alex said in the article. So who's the bottom feeder now?! HA!

    Wait...

  • wtf (unregistered) in reply to A More Skilled Programmer than "Some Guy"
    A More Skilled Programmer than "Some Guy":
    I have re-written the code to meet your less-than-rigorous standards:

    C#:

    public string GetJunk
      string junk is "1";
      if junk is "1" then return junk
    

    Your right, C# is easier than VB!

    Nope, you're still useless. Keep trying, though. Eventually you'll come up with something worth saying.

    Hint: if you think the point of the original code is to return the value of "junk" then you've missed it.

  • (cs)

    Properties are TRWTF, am I right or am I right?

  • Anonymous (unregistered) in reply to John Holmes
    John Holmes:
    I started on an Apple II in about 1980. My first home computer was also a VIC-20, but I had the 16K ram expansion. That gives me a good two inches on you. Length and circumference, buddy.
    Damn you, I could only ever dream of that memory expansion pack! Mind you, I still remember getting a Commodore 64 with its whopping 64KB RAM.
  • John Holmes (unregistered) in reply to Anonymous
    Anonymous:
    John Holmes:
    I started on an Apple II in about 1980. My first home computer was also a VIC-20, but I had the 16K ram expansion. That gives me a good two inches on you. Length and circumference, buddy.
    Damn you, I could only ever dream of that memory expansion pack! Mind you, I still remember getting a Commodore 64 with its whopping 64KB RAM.

    I skipped the C64 and got the C128 instead. Schwing!

  • Leo (unregistered) in reply to JohnFx
    JohnFx:
    On a related note: Isn't Ruby often touted for it's simplicity also? I guess Ruby is still too new for its haters club to have as many members.

    Ruby comes from (and is mostly associated with) Unix-land, which shields it from the type of hate that VB gets. The type of moronic point-and-click "developers" that VB attracts wouldn't know Unix if they tripped over a csh at the beach.

    Also, I like how you used both "its" and "it's" in the same way in your two sentences there. Makes it so you're sure to be 50% right.

  • (cs) in reply to Alex Papadimoulis
    Alex Papadimoulis:
    TRWTF is VB.

    Now that that's out of the way... let the actual commenting begin...

    Amen!

    You would expect MS to have taken the golden opportunity to kill VB when .NET came out, but they didn't want to lose the VB code monkeys. The () working as both the array pointer and a function comes from the fact that VB didn't use the C style syntax because BASIC didn't have C-style functions. Bolting on functions made the syntax grow ugly.

    For GUI stuff, Foxpro was much better than VB back in the days of VB4. Too bad that MS didn't push Foxpro as well as they should've done, instead pushing VB.

    The VB language has no real defense. It is a beefed-up version of BASIC, which was never intended to be used for anything other than home computing, mostly for beginners. QuickBASIC and its Windows-ized version, VB were uncalled for.

  • Jay (unregistered) in reply to Anonymous
    Anonymous:
    John Holmes:
    I started on an Apple II in about 1980. My first home computer was also a VIC-20, but I had the 16K ram expansion. That gives me a good two inches on you. Length and circumference, buddy.
    Damn you, I could only ever dream of that memory expansion pack! Mind you, I still remember getting a Commodore 64 with its whopping 64KB RAM.

    I recall paying $120 for the 16KB RAM expansion for my VIC-20. So memory is worth about about $8 per KB. At that rate, the 2 GB of mmemory on my current laptop are worth $16 million! I'm rich!

  • (cs) in reply to Some Guy
    Some Guy:
    Larry David Jr:
    Here's a challenge for you all then. Give a piece of code which is 'better' in C# than in VB (.NET).

    Go.

    Easy.

    VB:

    Public Function GetJunk() As String
    Dim junk As String = "1"
    If junk = "1" Then
    Return junk
    End If
    End Function

    C#:

    public string GetJunk()
    {
    string junk = "1";
    if(junk == "1") return junk;
    }

    For the string comparison, the VB version calls a bunch of VB string comparison crap kept around for backward compatibility with old VB (6 and earlier). The C# version calls op_Equality() which is a much more efficient method.

    If you don't believe me, compare the MSIL. If you want to make your VB more efficient, rewrite that string comparison to

    If String.op_Equality(junk, "1") Then...
    I would argue that VB string comparison is better in many respects. String comparison in C# is faster, but VB implicity treats null strings as empty strings for comparison purposes. This is almost always what the programmer wants and has to be coded manually in C#. Also, VB does compare lengths first in its internal comparison routine, so it almost always executes very efficiently.

  • Jay (unregistered)

    I'm no fan of VB (obligatory disclaimer), but all this talk about how proerties are dangerous because they can be abused ... Well, here's an exercise for the reader: Name a feature of any language, that cannot possibly be used in a way that creates a difficult-to-maintain program.

    I recall the time an associate of mine wrote something like this in C++:

    while (getMessage());
    {
    ... process message ...
    }
    

    By eliding most of the code I've made the error obvious, but after she asked for my help, I think the two of us spent a couple of hours trying to figure out the problem.

    Even as plain a feature as semi-colon can be abused.

  • (cs) in reply to Leo
    Leo:
    JohnFx:
    On a related note: Isn't Ruby often touted for it's simplicity also? I guess Ruby is still too new for its haters club to have as many members.

    Ruby comes from (and is mostly associated with) Unix-land, which shields it from the type of hate that VB gets. The type of moronic point-and-click "developers" that VB attracts wouldn't know Unix if they tripped over a csh at the beach.

    Also, I like how you used both "its" and "it's" in the same way in your two sentences there. Makes it so you're sure to be 50% right.

    Ruby's got its fair share of haters as well. It will probably end up being "the new PHP"; though I don't consider PHP to have a crappy syntax like VB or other languages labeled as crappy.

  • (cs) in reply to Anonymous
    Anonymous:
    John Holmes:
    I started on an Apple II in about 1980. My first home computer was also a VIC-20, but I had the 16K ram expansion. That gives me a good two inches on you. Length and circumference, buddy.
    Damn you, I could only ever dream of that memory expansion pack! Mind you, I still remember getting a Commodore 64 with its whopping 64KB RAM.
    So did I. But given that I got the floppy drive about 4 years after I actually had the C64, most of the stuff I did on that C64 went poof every time I hit the "off" switch. :(

    I just know that someone's bound to 1-UP all of these comments and claim to have programmed on a PDP-11, or having used FORTRAN.

  • Larry (unregistered) in reply to airdrik
    airdrik:
    Perl (where you can easily write entire programs without using any alphabetic characters)
    Gentlemen, I think we've been given a challenge!

    What is the longest / most useful (actually does something, for various values of something) Perl program that can be written using no letters in the executable code? (The shebang line, filename, command line etc. don't count.)

    To get us started:

    perl -e '@{[]}=(0..99999999)'

    will help you measure the adequacy of your hardware. (You've been warned...)

  • Bus Logic (unregistered) in reply to frits
    frits:
    Properties are TRWTF, am I right or am I right?
    Ha, I'll go with that! I never had any problem with a few methods called get<PropName> set<PropName>. What you see is what you get, screw all this syntactic sugar.
  • wtf (unregistered) in reply to danixdefcon5
    danixdefcon5:

    I just know that someone's bound to 1-UP all of these comments and claim to have programmed on a PDP-11, or having used FORTRAN.

    I can't claim to have programmed on a PDP-11, but I do recall my dad signing me in to his account so I could play adventure and crime and the like. I still can't be arsed with the games they're making today, but larn is good fun.

    (My first attempts at programming were in fact trying to write a zork-like game in BASIC - I was about 9, and had no idea what I was doing, so it was a hopeless job, but I felt pretty smart while I was trying to do it!)

    Telnet into twenex.org if you want to get that retro rush. Remember: ^Q to continue scrolling in TOPS-20.

  • Jeff (unregistered)

    First program was on a Texas Instruments programmable calculator. I think it had some 300 or 400 "locations" which could be used to store either an instruction or data.

    When I upgraded to an Atari 800 with cassette recorder for your software library, it was like having a supercomputer! I even had room to write my own driver for the external RS232 interface to the 300 baud acoustic modem!

    If you can't whistle into a modem and get the remote mainframe to respond, tuck your dick back into your pants in shame.

  • old timer (unregistered)

    When talking about the shortcomings of Pascal we must recall the times in which that language was invented as a teaching tool.

    It was fabulous at the time (1970) when the other options were COBOL and FORTRAN. C was not to show up for another 2 years.

    There were some other options, but not widely used or horrible: SNOBOL, RPG, Simula67, PL/1, Lisp.

  • Mark (unregistered) in reply to Jaime
    Jaime:
    I would argue that VB string comparison is better in many respects. String comparison in C# is faster, but VB implicity treats null strings as empty strings for comparison purposes. This is almost always what the programmer wants and has to be coded manually in C#.
    I can tell you're a VB coder by that statement. No, it's not always what the programmer wants unless you're a VB programmer in which case it is just what you've come to expect. Null strings and empty strings are very different constructs with very different meanings. They are not analogous and they should never be used to mean the same thing. The fact that VB seems to think they are the same thing is plain wrong and just another black mark against it as a language.
  • C# Coder (unregistered) in reply to A More Skilled Programmer than "Some Guy"

    For the love of God... neither example will compile. The original example will yield a "not all code paths return a value" compiler error. You have to return something if junk != "1".

  • Ken B. (unregistered) in reply to Sam Sneed
    Sam Sneed:
    How about plain old BASIC? ...like the one I used to use on the TTY?

    100 PRINT "HELLO WORLD" 200 GOTO 100

    Obviously, you didn't use BASIC correctly, as everyone knows you number lines by 10, not 100.

    http://www.amazon.com/Basic-BASIC-Introduction-Programming-programming/dp/0810451069

    (Sorry, I could only find the 1978 reprint, not the original version I learned on.)

  • C# Coder (unregistered) in reply to Mark
    Mark:
    Jaime:
    I would argue that VB string comparison is better in many respects. String comparison in C# is faster, but VB implicity treats null strings as empty strings for comparison purposes. This is almost always what the programmer wants and has to be coded manually in C#.
    I can tell you're a VB coder by that statement. No, it's not always what the programmer wants unless you're a VB programmer in which case it is just what you've come to expect. Null strings and empty strings are very different constructs with very different meanings. They are not analogous and they should never be used to mean the same thing. The fact that VB seems to think they are the same thing is plain wrong and just another black mark against it as a language.

    Exactly. I do the following all the time:

    private string _foo = null;

    public string Foo { get { return _foo ?? (_foo = "whatever"); } }

    Do something that pretty in VB...

  • (cs) in reply to Anonymous
    Anonymous:
    Steve The Cynic:
    Severity One:
    Steve The Cynic:
    Only me. And you, although maybe you went and looked it up.
    Alas... tomorrow is my 41st birthday, and I've been programming since the age of 13 (starting with BASIC on the TRS-80 model I). I also know what COBOL and APL stand for.

    COmmon Business Oriented Language A Programming Language.

    Signs of a mis-spent youth? Maybe.

    And I have 3.5 years on you. I started on a Commodore Pet, with the built-in cassette drive and the ghastly horrible keyboard. From there I progressed (?) to a Sinclair ZX80 (bounce, bounce, bounce).

    ((Editor's note: the only way to understand that last remark is to have used a ZX80, on a TV where the vertical hold control was set just, but only just, on the stable side of completely losing hold.))

    But, hey, my mother started programming on a LEO 3.

    In 1963.

    Awesome, it's fun to see the programmer's equivalent of dick measuring. I started coding on a Commodore VIC-20 so you guys both beat me, but only just. I remember sneering at the TRS-80 and its measly 4KB of RAM (I had 5KB, whoopee!).

    Are you saying Steve's mother's is larger than yours?

    Just asking...

  • (cs)

    Once again, Alex, I have to wonder: of all the things to hate about PHP, why do you always harp on variable variables, which aren't that different (conceptually) from a pointer, and aren't even unique to PHP?

  • JJ (unregistered) in reply to Bus Logic
    Bus Logic:
    frits:
    Bus Logic:
    frits:
    Bus Logic:
    This bizarre ambiguity between properties and functions is just one item on a very long list of inherent issues with VB.NET. I honestly have no idea why anyone would choose it over C# when targeting the .NET framework, unless they're just so bad at writing code that they can't make the switch from Microsoft's kiddie code to a real language.

    But properties and methods are the same thing in .Net, really. Properties are just syntatical sugar for getters and setters that can be abused to cause side effects and block indefinitely. The same is true for indexers. I'm not sure why you think C# is any better, because the underlying mechanism is the same. Disclaimer: I don't even like VB.Net.

    SYNTAX! The underlying mechanism may be the same but the C# syntax is vastly better because it removes the ambiguity. Did I really need to explain that to you? The whole point of today's article is the dodgy syntax, please keep up.

    Reading is fundamental. When two things are the same, there is no ambiguity.

    I'm not sure it's my reading comprehension that's at fault here but whatever, I'll try again. The syntax for property accessors is different between C# and VB.NET. It is the improved syntax of C# that makes it a superior language to VB. It doesn't matter whether this is "syntactic sugar" for some underlying concept, the simple fact remains that the syntax of C# is superior to the syntax of VB in regard to properties. What don't you understand here? I'm not trying to be difficult, I honestly don't understand where the confusion lies. I know perfectly well that properties are syntactic sugar for getters and setters but it doesn't change the fact that C# has a far better syntax when dealing with properties than VB.
    What are you talking about? You either do

    x = SomeObject.SomeProperty

    or

    SomeObject.SomeProperty = x

    Minus the semicolon at the end of the statements, the syntax is identical. The only difference between VB.NET and C# syntax is the fact that VB.NET has the concept of indexed properties, a carrythrough (throwback, if you will) from older versions of VB. Basically it was meant to allow a property to act like an array, and it is this functionality that was totally abused in the article.

    What exactly is the "superior" syntax of C#? Merely the fact that it doesn't include the functionality described above?

  • MS Expert (unregistered) in reply to C# Coder
    C# Coder:
    For the love of God... neither example will compile. The original example will yield a "not all code paths return a value" compiler error. You have to return something if junk != "1".
    Neither example needs to compile. Remember, this is C#, which is an interpreted language.
  • Jellineck (unregistered)

    TRWTF is how many posters in these comments are using 'VB' and 'VB.NET' interchangeably.

  • Alan (unregistered) in reply to Chris Haas

    In VB you also cannot call methods for bit shifting. XOR etc

  • Ken B. (unregistered) in reply to John Holmes
    John Holmes:
    I started on an Apple II in about 1980. My first home computer was also a VIC-20, but I had the 16K ram expansion. That gives me a good two inches on you. Length and circumference, buddy.
    I started with an ASR-33 connected via 110 baud (yes, "110", no multiplier suffix) acoustic coupler, talking to an HP-2000 halfway across the county. The first computer I owned was an Apple-][ Plus, though I was able to scrounge up enough money for a 32K expansion (a whopping 80K total), and a 70-track floppy.

    How many inches is that? :-)

  • boog (unregistered) in reply to MS Expert
    MS Expert:
    C# Coder:
    For the love of God... neither example will compile. The original example will yield a "not all code paths return a value" compiler error. You have to return something if junk != "1".
    Neither example needs to compile. Remember, this is C#, which is an interpreted language.
    Close...earlier versions were compiled, after which they switched to interpreted-only for a couple of years. The outrage at the performance problems this caused almost killed C#, but when Microsoft announced they were discontinuing the C compiler, they saved it. Around the same time, Bill Gates finally realized that making it a compiled language again (along with open-sourcing the library code) was a wise idea.

    So, in essence, you can still run it interpreted on Windows, but not on Linux or Macs.

  • 1TBS (unregistered) in reply to Jay
    Jay:
    I'm no fan of VB (obligatory disclaimer), but all this talk about how proerties are dangerous because they can be abused ... Well, here's an exercise for the reader: Name a feature of any language, that cannot possibly be used in a way that creates a difficult-to-maintain program.

    I recall the time an associate of mine wrote something like this in C++:

    while (getMessage());
    {
    ... process message ...
    }
    

    By eliding most of the code I've made the error obvious, but after she asked for my help, I think the two of us spent a couple of hours trying to figure out the problem.

    Even as plain a feature as semi-colon can be abused.

    Well, that wouldn't have happened with a reasonable brace style. Cue flamewar in 3, 2, 1 ...

  • (cs) in reply to Alan
    Alan:
    In VB you also cannot call methods for bit shifting. XOR etc
    Please do your research before posting. VB has both.
  • boog (unregistered) in reply to 1TBS
    1TBS:
    Jay:
    I'm no fan of VB (obligatory disclaimer), but all this talk about how proerties are dangerous because they can be abused ... Well, here's an exercise for the reader: Name a feature of any language, that cannot possibly be used in a way that creates a difficult-to-maintain program.

    I recall the time an associate of mine wrote something like this in C++:

    while (getMessage());
    {
    ... process message ...
    }
    

    By eliding most of the code I've made the error obvious, but after she asked for my help, I think the two of us spent a couple of hours trying to figure out the problem.

    Even as plain a feature as semi-colon can be abused.

    Well, that wouldn't have happened with Java™. Cue flamewar in 3, 2, 1 ...

  • Bus Logic (unregistered) in reply to JJ
    JJ:
    Bus Logic:
    frits:
    Bus Logic:
    frits:
    Bus Logic:
    This bizarre ambiguity between properties and functions is just one item on a very long list of inherent issues with VB.NET. I honestly have no idea why anyone would choose it over C# when targeting the .NET framework, unless they're just so bad at writing code that they can't make the switch from Microsoft's kiddie code to a real language.

    But properties and methods are the same thing in .Net, really. Properties are just syntatical sugar for getters and setters that can be abused to cause side effects and block indefinitely. The same is true for indexers. I'm not sure why you think C# is any better, because the underlying mechanism is the same. Disclaimer: I don't even like VB.Net.

    SYNTAX! The underlying mechanism may be the same but the C# syntax is vastly better because it removes the ambiguity. Did I really need to explain that to you? The whole point of today's article is the dodgy syntax, please keep up.

    Reading is fundamental. When two things are the same, there is no ambiguity.

    I'm not sure it's my reading comprehension that's at fault here but whatever, I'll try again. The syntax for property accessors is different between C# and VB.NET. It is the improved syntax of C# that makes it a superior language to VB. It doesn't matter whether this is "syntactic sugar" for some underlying concept, the simple fact remains that the syntax of C# is superior to the syntax of VB in regard to properties. What don't you understand here? I'm not trying to be difficult, I honestly don't understand where the confusion lies. I know perfectly well that properties are syntactic sugar for getters and setters but it doesn't change the fact that C# has a far better syntax when dealing with properties than VB.
    What are you talking about? You either do

    x = SomeObject.SomeProperty

    or

    SomeObject.SomeProperty = x

    Minus the semicolon at the end of the statements, the syntax is identical. The only difference between VB.NET and C# syntax is the fact that VB.NET has the concept of indexed properties, a carrythrough (throwback, if you will) from older versions of VB. Basically it was meant to allow a property to act like an array, and it is this functionality that was totally abused in the article.

    What exactly is the "superior" syntax of C#? Merely the fact that it doesn't include the functionality described above?

    You just explained it to yourself - C# has a superior syntax because it does not allow such abusable constructs as indexed properties, which by your own admission are a throw-back from a previous era and clearly have no place here. Simple.

  • Alan (unregistered) in reply to Jaime
    Jaime:
    Alan:
    In VB you also cannot call methods for bit shifting. XOR etc
    Please do your research before posting. VB has both.
    Library methods don't count.
  • (cs) in reply to Alan
    Alan:
    Jaime:
    Alan:
    In VB you also cannot call methods for bit shifting. XOR etc
    Please do your research before posting. VB has both.
    Library methods don't count.
    VB has operators for both. << and >> for shifting and Xor for XOR.
  • ideo (unregistered) in reply to Jaime
    Jaime:
    Some guy:
    Spivonious:
    There is nothing you can do in C# that I can't do in VB.

    The real issue isn't that there is nothing you can do in C# that you can't do in VB. The issue is that there is plenty you CAN do in VB that you can't with C#.

    For example:

    Private Function _getFoo as Int Return 1 End Function

    Public Readonly Property Foo as Int Get _getFoo() End Get End Property

    The above would compile, and if you ever accessed Foo, you'd get 0.
    Just modify the project to stop ignoring compiler warning 42107. It will gladly tell you that the property doesn't return a value on all code paths. This is more of a WTF with Visual Studio than VB as the compiler chokes on this by default, it's only the default project template in VS that turns it off.
    wat.

    That's a couple of orders of magnitude more retarded than the current banter between the language camps.

  • qbasic (unregistered) in reply to Sam Sneed

    100 PRINT "shup up" : goto 100

    This is how I did it on qbasic :)

  • sino (unregistered) in reply to boog
    boog:
    Markp:
    akatherder:
    A poor craftsman blames his tools.
    So does a good craftsman who has crappy tools.
    What good craftsman willingly uses crappy tools?

    I suppose he may not have a choice, but then wouldn't he still make the best of what he has? He wouldn't need to blame the tools (or anything else) if he succeeds.

    And if there's no chance of succeeding despite his best efforts due to tools/resources/work conditions/etc., I think a good craftsman would see that beforehand and avoid a project he knows would fail. Otherwise, would you really call him a good craftsman, and if so, by what standard are you measuring to derive the term "good"?

    Close, but the correct response is:

    "No, a good craftsman uses the crappy tools he's dealt to build good ones, then moves the fuck on with his life."

  • quisling (unregistered) in reply to Mike D
    Bremer:
    if you ask me, verbosity is much easier to read then stupid nipple brackets.
    And some of us prefer nipples to verbosity. Especially the intelligence-challenged ones. Funny ol' world, eh?

    :D

  • (cs) in reply to sino
    sino:
    boog:
    Markp:
    akatherder:
    A poor craftsman blames his tools.
    So does a good craftsman who has crappy tools.
    What good craftsman willingly uses crappy tools? ...
    Close, but the correct response is:

    "No, a good craftsman uses the crappy tools he's dealt to build good ones, then moves the fuck on with his life."

    Fair enough.

  • (cs) in reply to Alan
    Alan:
    Jaime:
    Alan:
    In VB you also cannot call methods for bit shifting. XOR etc
    Please do your research before posting. VB has both.
    Library methods don't count.
    Well done! Make a claim, then when it's refuted, quickly change the conditions. It certainly is harder to hit a moving target.

Leave a comment on “Property Basics”

Log In or post as a guest

Replying to comment #:

« Return to Article