• (cs) in reply to KattMan
    KattMan:
    lanmind:
    maw:
    In VB it would be "Image4.Visible = t = 1" Scary.

    I didn't even know you could do that! But uh... I wouldn't. Anyone who uses this kind of structure is setting the project up for maintenance hell. TRWTF is any language that lets it be legal.

    Oh, and the the other TRWTF is languages that need special operators to tell the difference between assignment and comparison. Don't forget the "===" operator...

    You seem to contridict yourself here. in VB you don't need an additional operator for assignment or comparison. The context of the "=" is what determines its function.

    In VB x=y=z the first = is always an assignment all following = are comparisons. this si always true. THe problem comes when there is an implied assignment, as in "If x=y Then" there is an implied assigment to a boolean resulting from the listed comparison of "x=y". This is where the confusion between assignment and comparison happens. But the rule stays the same, the first implied or literal "=" is always assignment, all other "=" is comparison when looking at a line in VB.

    I'm not sure what you find contradictory. First, I say that VB - or any language - allowing you to do that is retarded. And it is. Then I go on to say that the need for separate operators is retarded. Some languages make you do that, but not VB. So... I'm talking about different things here. Clearer?

  • close (unregistered) in reply to Matt Westwood
    Matt Westwood:
    Tasty:
    Sizik:
    TheSHEEEP:
    "Image4.Visible := t = 1;"

    Yuck.

    Every "x = y" where x ends up not being y is scary, to say the least.

    In other languages, that'd be "Image4.Visible = t == 1;".

    Wirth deliberately gave Pascal those operators as a teaching tool. Assignment is not commutative and the colon in a := b; makes that clear. Equality is a single = in ordinary algebra, where (a = b) is the same as (a = b).

    Just because something is not common doesn't mean it's not better!

    French is rubbish because they say "oui" rather than "yes". German is not quite as rubbish because they say "yah" rather than "yes" which is nearly "yes" so it's not quite as rubbish. Russian is really rubbish because they say "dah" rather than "yes". Spanish is quite rubbish because they say "see" when they mean "yes". American is really rubbish because they say "yo", "yep", "yeah", "yup" and all sorts of other silly things when they mean "yes".

    See that paragraph above I just wrote? That's you stupid fucking programmers arguing about which of your stupid fucking programming languages is the best. Fuck off and sweep streets the fucking lot of you cunts.

    German = Ja Russian = да

    etc....

    Spanish = Si

  • Jack (unregistered) in reply to You sure?
    You sure?:
    Let p be a prime number Let i be square root of -1; Let x be an odd divisor of 12

    hmmm...sounds like assignment to me...

    No, those are definitions. They must not change within the context of your formula, or proof, or whatever it is.

    But maybe the difference is too subtle. And it's all semantic, anyway.

  • Jack (unregistered) in reply to Spewin Coffee
    Spewin Coffee:
    That's a very strange way to implement a Semafor.

    /YoureDoingItWrong

    Speaking of which, who spells it "semafor"?

  • [] (unregistered) in reply to Jack
    Jack:
    Spewin Coffee:
    That's a very strange way to implement a Semafor.

    /YoureDoingItWrong

    Speaking of which, who spells it "semafor"?

    Someone who doesn't know how to spell "semafour".

  • (cs) in reply to Peter
    Peter:
    foo:
    snoofle:
    Flash:
    This old-timer just demonstrated that he hadn't learned an important lesson of writing software: that "working fine" is not enough. Our code has to be maintainable, too. It should be easy to understand for the next person who comes along. If there are bugs, they should be easy to find. If a change is needed, it should be easy to make.
    Not to defend the old timer's attitude or code, but from the story, it appeared that the code was relatively understandable for the next person who came along, who also appeared to have little trouble changing it .
    So you have 1/3. What about the other two, finding bugs (esp. typos) and making changes?
    I make that 2/3.
    FTFY.

    Btw, seems 1.2/3 to me.

  • Chris Lively (unregistered)

    You could have simply placed all of the buttons on a TPanel and the stock photos on another TPanel.

    Then you could loop through all of the controls on each panel and never worry about having to modify the function..

    procedure TForm2.ImageMouseMove (Sender: TObject; Shift: TShiftState; X, Y: Integer); var t : integer; comp : TComponent; begin t := TImage(Sender).Tag; for comp in MyButtonPanel.Controls do begin comp.Visible := (comp.Tag = t); end;

    for comp in MyPhotosPanel.Controls do begin comp.Visible := (comp.Tag = t); end; end;

    Then again I haven't used Delphi in over a decade.

  • ozzie (unregistered) in reply to Jack
    Jack:
    Image4.Visible := t = 1;
    OK I don't know Pascal or Delphi, so I'm just going to take a guess at the array syntax, but why wouldn't you simply

    Image[t].Visible := 1;

    after clearing the entire array, of course?

    This isn't using arrays, the original statement is basically along the lines of:

    if (t = 1) set Image4.Visible to true, else set Image4.Visible to false

    CAPTHCHA: transverbero - A noun that's had a sex change?

  • (cs) in reply to bob
    bob:
    Roby McAndrew:
    I can see this from both sides. The old code is verbose, but it's not THAT ugly and unmaintainable. I guess it evolved that way. Cutting and pasting working code to get unchanged functionality is kind of good practice.

    I can't believe that people are defending the original code. It is completely atrocious. Duplication of substantially the same code with minor variations is always a bad smell. One reason is maintainability - if something needs to be changed it has to be done in mulitple places rather than one. The other is readability. There is so much noise there that it is difficult to see what the differences is between the cases. That not only makes it more likely that errors will be made but it also hides the intent of the code which is much clearer in the rewritten version.

    And BTW are you serious about cutting an pasting being good practice?

    I've been known to cut and paste, but I usually cut and paste for reference. Not because I'm going to use the code, but because I did something awesome and I needed to reference what I did to duplicate it properly elsewhere.

    And 1 time, I coded a 30 line function in javascript, And got it right the first time. I began to question if i was god. I haven't been able to do it since, so yes... The first draft tends to be a little rough around the edges 99 percent of the time.

  • Gert (unregistered) in reply to Nagesh

    I don't think that's correct Nagesh.

    procedure TForm2.ImageMouseMove (Sender: TObject; Shift: TShiftState; X, Y: Integer); var t : integer; begin

    // glow "buttons" t := TImage(Sender).Tag;

    The procedure is named IMAGEMOUSEMOVE, and the first thing he does is determine which image caused the event handler to fire; we don't have the code that he uses to assign events to this handler, but I'm guessing he assigns all the Image control's "MouseMove" events to this one handler, which is why he needs to firstly determine the sender with

    t := TImage(Sender).Tag;

    This is a pretty common practice in .NET as well.

  • sfs (unregistered) in reply to James C. L.
    James C. L.:
    While it depends on the environment, the first version looks to be more efficient. It only sets values if things have changed. The second version by Derek, while more concise, will be called every time the mouse moves on the form, doing the same comparisons, and setting values.
    Stop. Just stop. This is a totally bullshit evaluation of relative performance. We're not talking PHP or Ruby that just derps along. Delphi compiles to native code.

    Also, Derek's code has no branches, so there will be no lost cycles when the processor misses a branch prediction. Derek's code is also much smaller, and thus more cache-friendly.

    More to the point, however, you haven't profiled the code, so you really don't know. Derek's 14-line function is readable, clear, and far more maintainable than the original 280-line monster. If the 14-liner is a performance problem, it can be solved by adding an extra check to see if "t" changed. That makes it probably... 15-20 lines, which is more than 14, but far less than 280.

    Also, I personally don't like the pattern of setting a value to the result of a comparison (Image4.Visible := t = 1;). It may be concise, but it isn't clear.
    Seriously, how long have you been coding? The "BOOL_FUNC := BOOL_EXPR;" idiom is really common, and once you recognize it, the intent is just as clear as the verbose "if BOOL_EXPR then BOOL_FUNC := true;"
  • No Name Arsehole (unregistered) in reply to dogmatic
    dogmatic:
                        TForm1(FindComponent('Image'+k)).Visible := false;
                        TForm1(FindComponent('Button'+k+'On')).Visible := false;
    (...)            
                TForm1(FindComponent('Image'+senderIndex)).Visible := true;
                TForm1(FindComponent('Button'+senderIndex+'On')).Visible := true;
    
    Just because RTTI exists, doesn't mean you have to (ab)use it for everything.

    This whole thing would be much easier solved by just implementing a custom glow button (or using one of the million different ones already implemented).

  • Wim (unregistered) in reply to Flash
    Flash:
    'Phmph,' he grumbled, 'my way worked fine, too.'
    This old-timer just demonstrated that he hadn't learned an important lesson of writing software: that "working fine" is not enough. Our code has to be maintainable, too. It should be easy to understand for the next person who comes along. If there are bugs, they should be easy to find. If a change is needed, it should be easy to make.
    And why is the new code in that way better? The new code fails your criteria in my opinion. It is not easy to understand (no comments :)) A bug is more easily found in the first version, because there it is easy to follow what is happening, so changes are easier and it is more maintainable. I must admit, I like the new code better.
  • George (unregistered) in reply to Chelloveck
    Chelloveck:
    Bob:
    Many people can only understand what they're used to. This is generally considered stupid.

    I used to work in a C shop. All C, all the time. One of the old-timers complained when I used the '?:' conditional operator.

        x = (a > b) ? a : b;
    

    Like that, only with meaningful variable names.

    "What's this? That's not even legal C, that's just a proprietary compiler extension! What do you mean, 'it is legal'? Prove it! So what if it's in Kernighan and Ritchie? Who are they? Anyway, no one understands it. You need to change it to an if..else block."

    Amazing what some of these old timers think they know...

    Me, I'm just happy that it's 2012 and I can finally start using some of the constructs presented in the C99 spec.

    It is a stylistic choice. Neither approach is good or bad. When you work on a legacy code base with others you sometimes need to adopt the prevalent sytle to maintain readability even if you prefer a different style of doing things.

  • George (unregistered) in reply to Scrummy
    Scrummy:
    The first draft of pretty much any code is shit. Agile just accepts that as a reality, and allows for making it better at an appropriate time. Otherwise, you're just fooling yourself.

    The first draft is only shit if you throw analysis and system design out the window and jump straight into hammering out code so that some pointy headed boss can jump straight to micromanaging the crap out of you with lttle pieces of paper on a board. Wait, that is exactly what scrum and agile development is. Nevermind.

  • Derek (unregistered) in reply to callcopse

    "Visible" although it looks like variable is actually property, which means it is just automatic wrapper for getter and setter. Thus no blinking will occure, the setter looks like this:

    procedure TControl.SetVisible(Value: Boolean);
    begin
      if FVisible <> Value then
      begin
        ...actual visibility change
      end;
    end;
    
  • hyperly (unregistered) in reply to ochrist
    ochrist:
    Derek:
    OMG, they posted it. I submited this code about month ago, I thought it wasn't good enough, perhaps it took them that long just to decipher my non-native-english. Thanks!

    No, that's just because Alex is an older, more experienced programmer and wants you to know your place.

    Congratulations. You're the first person in a looooong while to get a featured comment.

    (looking at the general level of the commentary here, I'm not surprised)

  • (cs) in reply to Gunslinger
    Gunslinger:
    Looks like another great reason to stay away from Python.
    You need no reason other than the derp-y GIL to avoid Python. Putting a busy do-nothing loop in parallel speeds things up!? Trying to kill things makes it all worse? TRWTF…
  • (cs) in reply to Code Slave
    Code Slave:
    Kind of like the classic strcpy trick in C
    while (*dest = *(src++)) ;

    Perfectly valid... efficient... and it is important to understand how and WHY it works. However, so does:

    strcpy(dest,src);

    Take a closer look at your version of the strcpy trick... It doesn't work because you left the ++ off dest.

    And (just entering the willy-waving contest for a moment) it has more parens than it needs.

    while (*dest++ = *src++) ;

    This is what you want, except that in the real world, only the people who write strcpy itself should possibly be worried about this. Everyone else should just call strcpy.

    And either nobody else noticed, which is disappointing, or nobody else cared enough to comment, which is more disappointing.

  • Not Nagesh (unregistered) in reply to close
    close:

    French is rubbish because they say "oui" rather than "yes". German is not quite as rubbish because they say "yah" rather than "yes" which is nearly "yes" so it's not quite as rubbish. Russian is really rubbish because they say "dah" rather than "yes". Spanish is quite rubbish because they say "see" when they mean "yes". American is really rubbish because they say "yo", "yep", "yeah", "yup" and all sorts of other silly things when they mean "yes".

    See that paragraph above I just wrote? That's you stupid fucking programmers arguing about which of your stupid fucking programming languages is the best. Fuck off and sweep streets the fucking lot of you cunts.

    That's right. Languages like FORTRAN and Perl are just as good as Java and C#, so really no reason to have more than one. Why did Wirth invent Pascal anyway? So 30 years later, people on the Internet could cite his name when arguing the merits of his syntax selection.

  • Nagesh (unregistered)

    Why ain't Alex massaging another article yet?

  • Sectoid Dev (unregistered) in reply to Chelloveck
    I used to work in a C shop. All C, all the time. One of the old-timers complained when I used the '?:' conditional operator.
    x = (a > b) ? a : b;
    

    Like that, only with meaningful variable names.

    "What's this? That's not even legal C, that's just a proprietary compiler extension! What do you mean, 'it is legal'? Prove it! So what if it's in Kernighan and Ritchie? Who are they? Anyway, no one understands it. You need to change it to an if..else block."

    My current "team lead" also told me to use if/else blocks instead of ?: His rationale was that it would make porting our entire Perl code base to C much easier if the need ever arose.

    I've stopped listening to anything he has said since.

    Yes, I know TRWTF := Perl

  • Shinobu (unregistered) in reply to lanmind
    lanmind:
    maw:
    In VB it would be "Image4.Visible = t = 1" Scary.
    I didn't even know you could do that! But uh... I wouldn't. Anyone who uses this kind of structure is setting the project up for maintenance hell. TRWTF is any language that lets it be legal.
    There can be no confusion, since assignment is a statement, whereas comparison can only occur in expressions. This is the reason why VB doesn't have or need horrible kludges like := or == and if you don't know this, you have no business coding in the language. It's always the first thing you do when you meet a new language: study the syntax.
    KattMan:
    THe problem comes when there is an implied assignment, as in "If x=y Then" there is an implied assigment to a boolean resulting from the listed comparison of "x=y".
    There is no such thing. The statement here is If (hence not an assignment) and is followed by an expression. VB is immune to C's if(x = y) bug since assignment is a statement. People are always quick to dismiss VB but this is an example where VB syntax is clearly better than C or Pascal.
  • Scrummy (unregistered) in reply to George
    George:
    Scrummy:
    The first draft of pretty much any code is shit. Agile just accepts that as a reality, and allows for making it better at an appropriate time. Otherwise, you're just fooling yourself.

    The first draft is only shit if you throw analysis and system design out the window and jump straight into hammering out code so that some pointy headed boss can jump straight to micromanaging the crap out of you with lttle pieces of paper on a board. Wait, that is exactly what scrum and agile development is. Nevermind.

    The task board is a perfect metaphor for tracking work to be done. People who fear openness and accountability often poke fun at the task board. Some of us prefer to build code on time, that works, rather than hide behind project managers when the failures that were baked into the GANNT chart are realized. This is why we ship software that meets users' needs, instead of releasing a year late with features that were obsolete 1 month into the 6-month analysis phase.

  • Shinobu (unregistered) in reply to Chelloveck
    Chelloveck:
    x = (a > b) ? a : b;
    The ( ) are superfluous in that statement. It's precisely because of this intended use of the ? : operator that its precedence level is just above = and that all other operators apart from , have higher precedence.
  • M (unregistered) in reply to Shinobu
    Shinobu:
    lanmind:
    maw:
    In VB it would be "Image4.Visible = t = 1" Scary.
    I didn't even know you could do that! But uh... I wouldn't. Anyone who uses this kind of structure is setting the project up for maintenance hell. TRWTF is any language that lets it be legal.
    There can be no confusion, since assignment is a statement, whereas comparison can only occur in expressions. This is the reason why VB doesn't have or need horrible kludges like := or == and if you don't know this, you have no business coding in the language. It's always the first thing you do when you meet a new language: study the syntax.
    KattMan:
    THe problem comes when there is an implied assignment, as in "If x=y Then" there is an implied assigment to a boolean resulting from the listed comparison of "x=y".
    There is no such thing. The statement here is If (hence not an assignment) and is followed by an expression. VB is immune to C's if(x = y) bug since assignment is a statement. People are always quick to dismiss VB but this is an example where VB syntax is clearly better than C or Pascal.

    VB doesn't have horrible kludges....right.

    Dim x As Integer = 10 Dim y As Integer = 20 Dim z As Integer = 20 x = y = z

    What is x now? x is -1, y and z are unchanged.

    I much prefer C#'s transitive assignment to that kludge. Booleans aren't integers.

  • CharlesFoxston (unregistered)

    The world is full of dinosaurs. I was sacked from one job because my boss, being an ex-programmer, had a "been there, seen it, done it" attitude towards everything.

    "I was coding when you were a baby!", he would roar, before chuckling to himself and hauling his heavy mass through the office.

    Being a true Microsoft fan-boy, I enjoyed using Visual Studio, and love the way other companies spend a lot of money researching more intuitive ways of using the IDE, much to my boss' chagrin. One day he had had enough. He caught me with my licensed version of ReSharper, and promptly fired me for "disruptive behaviour". I probably shouldn't have called him out about his experience with .NET but I hate those poor souls who are so desperate to appear superior to everyone else.

    It is the way of the world, with some of those left after the .com bubble burst spending all their times thinking of the good old days when they were paid ridiculous sums for nothing. Thankfully, I now contract and see less bad practice but this particular TDWTF reminded me of this encounter.

    Last I heard, the company had closed down.

  • tego (unregistered) in reply to M
    M:
    Shinobu:
    lanmind:
    maw:
    In VB it would be "Image4.Visible = t = 1" Scary.
    I didn't even know you could do that! But uh... I wouldn't. Anyone who uses this kind of structure is setting the project up for maintenance hell. TRWTF is any language that lets it be legal.
    There can be no confusion, since assignment is a statement, whereas comparison can only occur in expressions. This is the reason why VB doesn't have or need horrible kludges like := or == and if you don't know this, you have no business coding in the language. It's always the first thing you do when you meet a new language: study the syntax.
    KattMan:
    THe problem comes when there is an implied assignment, as in "If x=y Then" there is an implied assigment to a boolean resulting from the listed comparison of "x=y".
    There is no such thing. The statement here is If (hence not an assignment) and is followed by an expression. VB is immune to C's if(x = y) bug since assignment is a statement. People are always quick to dismiss VB but this is an example where VB syntax is clearly better than C or Pascal.

    VB doesn't have horrible kludges....right.

    Dim x As Integer = 10 Dim y As Integer = 20 Dim z As Integer = 20 x = y = z

    What is x now? x is -1, y and z are unchanged.

    I much prefer C#'s transitive assignment to that kludge. Booleans aren't integers.

    Don't know much about the internal storage representation of variables, I suppose?

  • marty (unregistered) in reply to ochrist

    A witty, funny, non-frist post, first post. Awesome.

  • null (unregistered)

    So TRWTF is that they didn't store all the button/image names in XML, amirite? :)

    CAPTCHA 'illum', I feel illum when I lookum at this copypaste code.

  • it's friday (unregistered) in reply to AN AMAZING CODER
    AN AMAZING CODER:
    Scrummy:
    lanmind:
    Scrummy:
    Now if they were using Agile, it would be perfectly acceptable to write that code as it appeared originally, so long as it was eventually, and iteratively, refactored to Derek's solution.

    Sorry, try again. We've all dumped shit code into a project to get it out the door, but it isn't ever acceptable.

    The first draft of pretty much any code is shit. Agile just accepts that as a reality, and allows for making it better at an appropriate time. Otherwise, you're just fooling yourself.

    Incorrect. You don't seem to under

    Agile is not meant to "make shitty code acceptable", <snip>

    I'd say absolutely not. The "agile" procedures at my last job included an emphasis on test-driven development, and no checking code into version control until it's been seen by a second person, either via pair programming or informal peer review. As I understand it, the rationale is, we haven't got a proper spec, so WHEN the requirements change next week, we aren't going to be slowed down by shit code.
  • Martin (unregistered) in reply to Nagesh
    Nagesh:
    Martin:
    Remind again how this:
    begin Image4.Visible := true; Image9.Visible := false; Image11.Visible := false; Image7.Visible := false; Image5.Visible := false;
      Image2.Visible := true;
      Image8.Visible := true;
      Image10.Visible := true;
      Image6.Visible := true;
      Image3.Visible := true;
    
      Image12.Visible := true;
      Image13.Visible := false;
      Image14.Visible := false;
    
      semafor_pic1 := true;
      semafor_pic2 := false;
      semafor_pic3 := false;
      semafor_pic4 := false;
      semafor_pic5 := false;
    end;
    
    James C. L.:
    only sets values if things have changed.

    ?

    Look at the functions called. The original code is only called when the mouse moves over an image.

    The new code is called every time the mouse moves

    Really? I kinda thought

    procedure TForm2.ImageMouseMove

    would get called... exactly when the mouse moves over an image.

  • David (unregistered) in reply to Shinobu
    Shinobu:
    VB is immune to C's if(x = y) bug since assignment is a statement.

    If you do not know how to use (let alone exploit) a language feature, that does not make that feature a bug.

    Criticizing a language you clearly do not understand does, however, make you at the very least an incompetent critic.

    Shinobu:
    People are always quick to dismiss VB but this is an example where VB syntax is clearly better than C or Pascal.

    If "people are always quick to dismiss VB" could that perhaps be because its defenderz are always so utterly full of shit?

  • (cs) in reply to Shinobu
    Shinobu:
    There is no such thing. The statement here is If (hence not an assignment) and is followed by an expression. VB is immune to C's if(x = y) bug since assignment is a statement. People are always quick to dismiss VB but this is an example where VB syntax is clearly better than C or Pascal.
    "Better" depends on your basis for comparison.

    Having said that, most experienced programmers do not consider context-sensitive semantics (such as the same operator doing completely different things depending on the code around it) "better" than context-free semantics.

  • Paul Neumann (unregistered) in reply to lanmind
    lanmind:
    Oh, and the the other TRWTF is languages that need special operators to tell the difference between assignment and comparison. Don't forget the "===" operator...
    Yeah, and languages which need special operators to denote the difference between functional arguments and the next expression.
  • Your Name (unregistered)

    Well, the young whippersnapper's "solution" is certainly dysfunctional. It is hard on the seasoned programmers' mental faculties, leading to increased TCO and reduced ROI. In short, it is not enterprisey. Also, any and all capabilities to customize the individual buttons with funny copy-paste-stale-bugs are not provided. PHB not like dat.

  • Paul Neumann (unregistered) in reply to Roby McAndrew
    Roby McAndrew:
    M:
    Roby McAndrew:
    Blah

    Blah? blah. blah!

    Are you a moron? I thought anyone could see from a million miles across that it was a sarcastic comment.

    Troll status: FAIL! It is considered bad form to bash the starfish over the head when they first bite. Drag them along for a few comments and cause some emotional trauma first, at least.

  • dogmatic (unregistered) in reply to No Name Arsehole
    No Name Arsehole:
    dogmatic:
                        TForm1(FindComponent('Image'+k)).Visible := false;
                        TForm1(FindComponent('Button'+k+'On')).Visible := false;
    (...)            
                TForm1(FindComponent('Image'+senderIndex)).Visible := true;
                TForm1(FindComponent('Button'+senderIndex+'On')).Visible := true;
    
    Just because RTTI exists, doesn't mean you have to (ab)use it for everything.

    This whole thing would be much easier solved by just implementing a custom glow button (or using one of the million different ones already implemented).

    Err that's why I recommended using a button class, but since from the looks of their code they've never seen a class nor would know what to do with it, the code was an example of the least he could do to clean up that mess without too much refactoring.

  • AN AMAZING CODER (unregistered) in reply to Shinobu
    Shinobu:
    Chelloveck:
    x = (a > b) ? a : b;
    The ( ) are superfluous in that statement. It's precisely because of this intended use of the ? : operator that its precedence level is just above = and that all other operators apart from , have higher precedence.

    But it's way easier to read with the ( ) than without. Which is why you should add them.

    Yes, any experienced coder can figure it out if they stop and think about it, but the less stopping and thinking you have to do, the more time you can spend coding (and the easier it will be to spot bugs).

    I'm sure you could solve this equation:

    10 + 11 / 12 * 17 ^ 2 - -3 * 15

    But wouldn't it be 20 times easier if you didn't have to navigate order of operations in your head?

  • Roger Garrett (unregistered) in reply to meh

    I wish the last statement were true.

    When used in a hypothetical statement (as in a "wish") the word "were" is used instead of "was".

  • Roger Garrett (unregistered) in reply to Your Name

    We need a new construct in software. When you cut and paste the pasted code maintains a link back to the original so that when a change is made to the original it automatically is reflected in the corresponding pasted code.

    What fun THAT would produce!

  • Shark8 (unregistered) in reply to Roger Garrett
    Roger Garrett:
    We need a new construct in software. When you cut and paste the pasted code maintains a link back to the original so that when a change is made to the original it automatically is reflected in the corresponding pasted code.

    What fun THAT would produce!

    You mean generics? Or did you mean that you want it to update the original code when the copy-pasted version is updated (and obviously breaking the links to it from other instances of copy-pastism)?

  • foo (unregistered) in reply to Peter
    Peter:
    foo:
    snoofle:
    Flash:
    This old-timer just demonstrated that he hadn't learned an important lesson of writing software: that "working fine" is not enough. Our code has to be maintainable, too. It should be easy to understand for the next person who comes along. If there are bugs, they should be easy to find. If a change is needed, it should be easy to make.
    Not to defend the old timer's attitude or code, but from the story, it appeared that the code was relatively understandable for the next person who came along, who also appeared to have little trouble changing it.
    So you have 1/3. What about the other two, finding bugs (esp. typos) and making changes?
    I make that 2/3.
    Of course, you're right, since you're apparently a bot.

    A human, in contrast, would understand context. The point was about maintainability of the old code. The fact that someone rewrote it completely is not exactly an argument in favour, even though in both cases the verb "change" was used.

    Sorry, please update your semantics database to v0.2.

  • Nickster (unregistered) in reply to M
    M:
    VB doesn't have horrible kludges....right. ... I much prefer C#'s transitive assignment to that kludge. Booleans aren't integers.

    Explain your logic there.

    1. YourLang doesn't work the same way as MyLang
    2. I prefer how MyLang works.
    3. YourLang is a kludge.
  • M (unregistered)
    Nickster:
    M:
    VB doesn't have horrible kludges....right. ... I much prefer C#'s transitive assignment to that kludge. Booleans aren't integers.

    Explain your logic there.

    1. YourLang doesn't work the same way as MyLang
    2. I prefer how MyLang works.
    3. YourLang is a kludge.

    It has nothing to do with my language preference. Yes, I happend to prefer C#, but I use several languages daily, including VB.NET.

    It's a combination of things, perhaps to subtle for you:

    First, as has been pointed out, the = operator performs different tasks depending on context. You could call this alone a kludge, but let's continue on. Secondly vb requires option strict to use strong typing. This line will either give an answer or fail to compile based on a setting somewhere else in the code. Again, this seems rather 'kludgy, but maybe acceptable to those who prefer weak typed languages or came from the old vb world and have trouble learning new things. Lastly, if option strict is not set, the code compiles and gives the value -1 for x. The value -1 is dependent on the internal representation of a boolean from pre-.net vb, while .net booleans DON'T ACTUALLY USE THAT REPRESENTATION. Convert from bool to int using .net framework methods and you get a different value. - kludge, kludge, kludge.

  • bkDJ (unregistered) in reply to M

    Either younare being ridiculous or you're trolling. Your argument is BS, though. For one, the dot operator in C# does double duty of C++'s scope resolution operator :: and indirect member reference ->, and I'm sure there's a craggy developer out there who would complain that "the same operator accessing something on the heap and also accessing a static member" leads to horrible bugs, but I would take that statement as seriously as "assignment and comparison using the same operator is horrible and context sucks". You know what language you're dealing with, so you should know its strengths and weaknesses.

    Also, -1 is just all bits turned on, but who cares as long as it's not zero. It's your own fault for putting an implicit cast from bool to int in the code. If you want an int to be a certain value based on a bool condition, use if/else or the ternary operator and stop whining about how bad you are at coding in a language you don't code in. Handy tip: no matter pre-.net, post-.net, ANSI C, or anything really: a false bool to int will be 0 and a true bool to int will be something that isn't zero.

  • Nickster (unregistered) in reply to M
    M:
    First, as has been pointed out, the = operator performs different tasks depending on context.
    Yes, and in C the * and & operators perform different tasks depending on context. That doesn't really keep you from understanding how they work.
    Secondly vb requires option strict to use strong typing. This line will either give an answer or fail to compile based on a setting somewhere else in the code.
    In C, you can also have a line that gives an answer or fails to compile based on a setting somewhere else in the code, depending on whether you included the right headers.
    Lastly, if option strict is not set, the code compiles and gives the value -1 for x. The value -1 is dependent on the internal representation of a boolean from pre-.net vb, while .net booleans DON'T ACTUALLY USE THAT REPRESENTATION.
    Okay, this one is actually pretty kludgey, but backward compatibility always is. IMHO the only real kludges are inconsistencies deliberately included to get around some quirk of the syntax and semantics, but as long as you understand the code you read and what it will do, it's manageable. Perhaps VB has more of this than other languages. I don't know it as well as you do, to be frank.
  • M (unregistered) in reply to Nickster
    Nickster:
    Lastly, if option strict is not set, the code compiles and gives the value -1 for x. The value -1 is dependent on the internal representation of a boolean from pre-.net vb, while .net booleans DON'T ACTUALLY USE THAT REPRESENTATION.
    Okay, this one is actually pretty kludgey, but backward compatibility always is. IMHO the only real kludges are inconsistencies deliberately included to get around some quirk of the syntax and semantics, but as long as you understand the code you read and what it will do, it's manageable. Perhaps VB has more of this than other languages. I don't know it as well as you do, to be frank.

    I agree backwards compatibility is pretty much always messy. I'm not trying to say vb is worthless or anything of the kind. I was just responding to the post that said vb doesn't have or need kludges. It certainly does, but probably not much more than other languages. It's true I prefer C# to vb, but that's just my preference. I used to enjoy C++ but became spoiled by C# not needing header files. F# is a fun language as well with a some awesome features and probably a few wtf's.

  • (cs) in reply to wolfi
    wolfi:
    Tasty:
    Wirth deliberately gave Pascal those operators as a teaching tool. Assignment is not commutative and the colon in a := b; makes that clear. Equality is a single = in ordinary algebra, where (a = b) is the same as (a = b).

    Just because something is not common doesn't mean it's not better!

    ever heard Wirth ranting about C++? he seems to be very convinced about the superiority of his languages
    Say what you will about C++, but at least Pascal and Ada have proper modules. C++ doesn't, so you have include files, and to separate interface from implementation, and to maintain binary compatibility, there's this verbose abomination otherwise known as the PIMPL idiom. It's an abomination that not only makes you idly type silly getter/setter functions, but also makes every PIMPLed instance construction automatically allocate stuff on the heap, usually doubling the number of heap allocations. And if you care about performance, you can't use PIMPL at least for some members of the class, so you move them back to the private-yet-exposed interface file (a.k.a. header file). It's mind-numbingly dumb to even have to worry about such a thing, but hey, that's C++ for you.

    If Qt toolkit supported Pascal natively without using shims, I wouldn't be using C++.

  • My Name * (unregistered) in reply to Silverhill
    Silverhill:
    Jack:
    I'm pretty sure before programming, there was no concept of "assignment" in mathematics.
    Au contraire. "For a right circular cylinder of radius 3, ..."

    Of course, the difference is in the scoping. There is no notion of "re-assignment", as it breaks referential transparency.

    In other words, equality and assignment are the same things. What you are calling "assignment" is taking a first-order sentence as an axiom in a proof or function.

Leave a comment on “The Long Glow”

Log In or post as a guest

Replying to comment #:

« Return to Article