• (cs) in reply to bob
    Anonymous:

    No, it's definitely Delphi, even VB.NET isn't lame enough to use := when it means =.




    Not to mention C++ uses != when it means <>.  C++ must suck.
  • (cs)

    --NEVER-- post anything like that again, there has to be a law against it somwhere, there HAS to be. (shudder)

  • (cs) in reply to masklinn
    masklinn:

    Yeah, and C++ and Smalltalk aren't that different either. They are both objet oriented and while each has a few concepts that the other lacks (C++ is a damn heap of messy poo while Smalltalk is structured and streamlined) the same basic abilities are there.


    Don't feed the trolls... don't feed the trolls... don't feed...

  • Gil (unregistered)

    So I guess this means I don't get the job?

  • (cs) in reply to Anonymous
    Anonymous:
    perl -wle 'print map chr, 73,32,102,105,110,100,32,121,111,117,114,32,117,115,101,32,111,102,32,112,101,114,108,32,100,105,115,116,117,114,98,105,110,103,10'


    perl -we 'print pack "(B*)*" , split / /, "01000100 01101001 01110011 01110100 01110101 01110010 01100010 01100101 01100100 00101100 00100000 01100001 01110010 01100101 00100000 01111001 01101111 01110101 00111111 00100000 01000001 01100010 01101111 01110101 01110100 00100000 01010000 01100101 01110010 01101100 00101101 01100110 01110101 00101100 00100000 01101101 01110101 01100011 01101000 00100000 01110100 01101111 00100000 01101100 01100101 01100001 01110010 01101110 00100000 01101000 01100001 01110110 01100101 00100000 01111001 01101111 01110101 00101100 00100000 01111001 01101111 01110101 01101110 01100111 00100000 01010000 01100001 01100100 01100001 01110111 01100001 01101110 00101110 00101110 00101110 00001010";'
  • (cs) 

    BUTTON1.Visible:=FALSE;

    When would you ever hide a button, unless you were hiding the panel that contained it too (and therefore wouldn't need to set the button visibility[right?])?
    Deactivate it, sure, but it just seems like bad GUI design to make it disappear altogether...

    Of course, this could be even worse... the phantom button might not ever be visible. It's impossible to tell from the snippet, really.

  • (cs) in reply to bob

    Anonymous:
    Disagree- the general concensus was that there was no reason to rename a UI element (like a panel) unless you actually addressed it in code. If it was just an element on the form, there's no reason to waste time renaming it- there're often many panels, etc.

    Yes and no. I find that naming _every_ control on a form is useful in the long run when maintenance hits you. When you first desing the form, a lot of controls aren't used in code, but later you will start using them. I find it a lot easier to pick up an old form (or someone else's form) and start adding new code if all the controls are named properly to begin with. Saves me time, makes me more efficient, and it's just the mark of a lazy programmer...

    Anonymous:
    No, it's definitely Delphi, even VB.NET isn't lame enough to use := when it means =.

    Heh that's funny. What exactly does = mean in VB? Assignment, equality, what is it?

    -shnar

     

  • (cs) in reply to bob
    Anonymous:

    >Subclass the edit field object and add a doSomething() method that performs the correct action

    Yes you could do that if you wanted-there're better ways than that, but there's no excuse for that crap code, hence the WTF.

    This is the problem when crossing languages, something that might work well in one language may not be the best way to do in another language. For *visual* controls in Delphi, it's a *lot* easier to simply have the one event handler that's called by the many different controls (Delphi allows you to have one event handler assigned to many different controls of different types even).

    -shnar

  • (cs) in reply to random_garbage

    random_garbage:
    Anonymous:
    perl -wle 'print map chr, 73,32,102,105,110,100,32,121,111,117,114,32,117,115,101,32,111,102,32,112,101,114,108,32,100,105,115,116,117,114,98,105,110,103,10'


    perl -we 'print pack "(B*)*" , split / /, "01000100 01101001 01110011 01110100 01110101 01110010 01100010 01100101 01100100 00101100 00100000 01100001 01110010 01100101 00100000 01111001 01101111 01110101 00111111 00100000 01000001 01100010 01101111 01110101 01110100 00100000 01010000 01100101 01110010 01101100 00101101 01100110 01110101 00101100 00100000 01101101 01110101 01100011 01101000 00100000 01110100 01101111 00100000 01101100 01100101 01100001 01110010 01101110 00100000 01101000 01100001 01110110 01100101 00100000 01111001 01101111 01110101 00101100 00100000 01111001 01101111 01110101 01101110 01100111 00100000 01010000 01100001 01100100 01100001 01110111 01100001 01101110 00101110 00101110 00101110 00001010";'

     

    perl -e "print map chr,78,111,119,32,119,101,39,114,101,32,116,97,108,107,105,110,39,33; # Welcome, Friends of the New World Order "
  • (cs)
    Alex Papadimoulis:

     and even the most incompetent developer could surely throw together an elegant solution if he put enough hours into it.



    There are some arguments to be made against this statement, actually.  http://www.joelonsoftware.com/articles/HighNotes.html

    The results of Joel's research indicate that the quality of code and the amount of time spent on it are completely uncorrelated.  Incompetent developers will simply never throw together an elegant solution, no matter how much time they put into it.  Just like some people fundamentally don't understand pointers, and never will.

    On the plus side, for today's examples, these are - in at least one sense - not WTFs.  By being so blatantly bad, they make it very easy for the interviewer to say "No Hire!" and move on to the next candidate.  What's so bad about that?

  • Jeff (unregistered) in reply to Edgar Plonk
    Edgar Plonk:
    "was"?! Is it gone now?
    Perhaps not, but since Borland is selling it off it looks pretty grim.  I'm sure that many Delphi lovers would disagree here, but I can't see tying any new development to a tool with such an unclear future.  So for me it is a "was"; perhaps not for the industry yet.
  • (cs) in reply to Jojosh_the_Pi
    Jojosh_the_Pi:
    Anonymous:
    No, it's definitely Delphi, even VB.NET isn't lame enough to use := when it means =.


    Not to mention C++ uses != when it means <>.  C++ must suck.


    != means not equal to; <> means less than or greater than.  These are not always the same.  Consider complex numbers which do not have less than or greater than.  With them != is legitimate, and <> is undefined.

    Sincerely,

    Gene Wirchenko

  • Jeff (unregistered) in reply to masklinn
    Yeah, and C++ and Smalltalk aren't that different either. They are both objet oriented and while each has a few concepts that the other lacks (C++ is a damn heap of messy poo while Smalltalk is structured and streamlined) the same basic abilities are there.

    Anyone would seriously disagree with what you've said because it's stupid, you basically used the good ol' strawman "my language's Turing Complete and yours is too so they're equivalent".


    All I know is that I had to translate between C++ and Delphi for some of my projects and most of the work invovled just changing the syntax.  Unless specific libraries were referenced, this was generally a very simple process.  Probably would have been the same for Java or C# as well.  Every concept I use in my dailing programming was included in both languages when I worked with them.  The only thing we could do in C/C++ that we couldn't do in Delphi was to write a device driver for Windows NT.

    I was also factoring into my thinking that when looking at Delphi and C++ Builder, the two products were almost identical (even using the same VCL I believe)  I think that would have have been very difficult to manage if there were drastic differences between the capabilities of object pascal and C.
  • Jeff (unregistered) in reply to Jeff
    I think that would have have been very difficult to manage if there were drastic differences between the capabilities of object pascal and C.

    Should be C++, there, obviously.
  • Jeff (unregistered) in reply to KenW
    KenW:
    Actually, anyone with any Delphi knowledge at all would know that you can assign the same event handler to more than
    one control; instead of double-clicking on the control, you just use the dropdown list in the Object Inspector. The "Sender"
    parameter to the event handler tells you which control generated the event.


    In my exprience, there are plenty of people with SOME "Delphi knowledge" (depending on your definition of "knowledge") who don't get this at all.  I know, I've worked with them.  And then there are some who get that you CAN do this, but don't really have any idea why they'd ever want to.  It's just so much simpler to click the form (or the object inspector if you absolutely must) and let it create a method for you.  None of this picking a method that already exists nonsense- that's just too complicated.

    I'm not disagreeing with you here, but it is amazing how many people can figure out the basics of a tool like Delphi and still have no idea how to use it.  Sometimes you're just giving them more rope . . .
  • (cs) in reply to Stan James

    I've been enjoying some of the witty comments in this forum for a while now, and I've noticed that a lot of the folks that authored the code that was submitted seem to be the type of folks who would say something a friend of mine once wise-cracked to me:

    "Grog no understand complicated computer thingy - just wanna count toes, pick toes, pick nose"

  • (cs) in reply to Jeff

    Jeff:
    Edgar Plonk:
    "was"?! Is it gone now?
    Perhaps not, but since Borland is selling it off it looks pretty grim.  I'm sure that many Delphi lovers would disagree here, but I can't see tying any new development to a tool with such an unclear future.  So for me it is a "was"; perhaps not for the industry yet.

    Just the opposite. Delphi "lovers" have been frustrated for years seeing the profits of Delphi not being reinvested into Delphi, but rather going to fund one of Borland's pet projects such as Inprise, Visibroker, ALM junk, etc. If Delphi would put just 10% of their profits into marketing, you'd see a much larger marketshare. I mean, when was the last time you saw an add that said "1 source, 3 platforms (Linux, Win32, DotNet), all with Delphi" or something like, "Backwards compatible since 1995" (as has been mentioned on this board already).

    At any rate, Delphi is alive and well, ver2006 just barely came out and the beta for 2007 is active. Delphi "lovers" are excited that the tool they love is being moved into a company that will hopefully love it as much as they do.

    -shnar

  • Robert Ehteshamzadeh (unregistered) in reply to Edgar Plonk

    A favorite quote of mine is from Albert Einstein:
    "you should make things as simple as possible, but not simpler."

    Pascal, and even more so it's derivative Delphi, try to avoid unnecessary complexity, and most of the time don't lose expressiveness in the process. This lowers the barrier to entry to technical people who are not exclusively programmers. ( Economists, Engineers, Physicists, etc ).  Frequently, this results in better code, since the code can be written by the person who understands the what the code is needed to do.

    Of course, to write good code, you need to have a logical mind. You also have to value clarity and simplicity, which the interviewees obviously did not.

    There are many examples of very well written Delphi code, which is far easier to study and learn from than C++ or java, due to it's compact syntax.

    http://www.delphi-gems.com/

  • (cs) in reply to Murdocj

    Anonymous:
    What I like are jerks who think they are superior to other people because they disdain certain programming languages (speaking as someone who has programmed in a variety of assemblers, Pascal, C, C++, VB, VB.net, Java, and a variety of other languages).

    Guess what... VB is a perfectly good language.  Works fine.  Generates code that runs fine.  I wouldn't write a web server in it, but for client-side applications it's a reasonable choice.

    Deal with it...

    Actualy VB is not a perfectly good language.

    Yes VB is a language.

    Yes you can do a lot with it.

    No it is not a perfectly good language. It is several flaws in it. Some flaws make it very difficult to write code in the language.


    I'm not saying don't use VB, I'm just pointing out the flaw in your argument

  • Jeff (unregistered) in reply to shnar
    shnar:

    Jeff:
    Edgar Plonk:
    "was"?! Is it gone now?
    Perhaps not, but since Borland is selling it off it looks pretty grim.  I'm sure that many Delphi lovers would disagree here, but I can't see tying any new development to a tool with such an unclear future.  So for me it is a "was"; perhaps not for the industry yet.

    Just the opposite. Delphi "lovers" have been frustrated for years seeing the profits of Delphi not being reinvested into Delphi, but rather going to fund one of Borland's pet projects such as Inprise, Visibroker, ALM junk, etc. If Delphi would put just 10% of their profits into marketing, you'd see a much larger marketshare. I mean, when was the last time you saw an add that said "1 source, 3 platforms (Linux, Win32, DotNet), all with Delphi" or something like, "Backwards compatible since 1995" (as has been mentioned on this board already).

    At any rate, Delphi is alive and well, ver2006 just barely came out and the beta for 2007 is active. Delphi "lovers" are excited that the tool they love is being moved into a company that will hopefully love it as much as they do.

    -shnar



    I fear you're wrong about the future of Delphi, but I hope you're right.  I completely agree with the assessment about how much better Delphi would have done had Borland continued to push it, but unless someone with deep pockets (like Oracle) buys the product, it's going to be difficult getting users and companies to trust it as a long term solution.  And if Oracle was to buy it, heaven help us all!

    My company actually purchased the 2006 version of their C# product because we were considering using ECO for a new project and wanted to evaluate it.  The DAY after we received our copy Borland made the announcement, effectively ending our trial.  No way was my company going to commit to a product with such an unclear future, and I can't say I blame them.

    I agree that it would be great if a company would by the tools and make it work.  I'm skeptical that there is anyone out there with both the interest and deep enough pockets to do it.
  • (cs) in reply to Jeff
    Jeff:
    Perhaps not, but since Borland is selling it off it looks pretty grim.  I'm sure that many Delphi lovers would disagree here, but I can't see tying any new development to a tool with such an unclear future.  So for me it is a "was"; perhaps not for the industry yet.


    Hmmm... You're in a vast minority. Most Delphi programmers I know are really pleased with the direction being taken
    with Delphi (myself included).
  • Anon (unregistered) in reply to ben
    ben:
    Note that this could stack overflow because C doesn't do tail call elimination.

    Funny you should say that because in my Advanced Compiler Building course we did examine this optimization technique.

    Granted, the designers of C did not put any provisions into the language to make tail recursion easy for the compiler, so the principle 'when in doubt, don't optimize' applies. But that doesn't mean it isn't done, instead it depends on how clever a compiler's developers were.

Leave a comment on “Take-home Trouble”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article