Dynamic linking with LD_PRELOAD - get it compiled - Linux

This is a discussion on Dynamic linking with LD_PRELOAD - get it compiled - Linux ; On Mar 17, 11:04 pm, David Schwartz wrote: > On Mar 17, 9:33 am, "jason.cipri...@gmail.com" > > wrote: > > My major point is that it's unreasonable to claim that all > > applications should consist of portable and reusable ...

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 41 to 60 of 62

Thread: Dynamic linking with LD_PRELOAD - get it compiled

  1. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mar 17, 11:04 pm, David Schwartz wrote:
    > On Mar 17, 9:33 am, "jason.cipri...@gmail.com"
    >
    > wrote:
    > > My major point is that it's unreasonable to claim that all
    > > applications should consist of portable and reusable code.

    >
    > Well, since nobody claimed that, ...


    Your reactions in this thread, especially your immediate reaction to
    the original post, make it look like you are claiming that even though
    you aren't explicitly saying it. Also, it is an attitude that I have
    seen before and so, in my experience, it is not an uncommon claim to
    make. Therefore it is reasonable to assume that is your attitude.

    > > Another
    > > point I am making is that it is equally unreasonable to criticize
    > > (even mildly) an application that does not consist of portable/
    > > reusable code and that also makes no claims otherwise

    >
    > Why not? What if the code would have been more robust, easier to
    > understand, portable, and reusable with even less effort than it took
    > to make it non-portable and not reusable? Would you still argue that
    > it's unreasonable to criticize it just because it doesn't claim to be
    > portable or reusable?


    Absolutely. It is unreasonable to criticize an application that does
    not consist of portable/reusable code and that also makes no claims
    otherwise. That is what I meant. It does not vary case-by-case. The
    reason I would still argue it is that the application was already
    complete, already got the job done, and criticizing it after the fact
    changes nothing unless the author specifically asked for advice or
    could be convinced to go back and rewrite the application (or apply
    the concepts in the future).

    That is not to say that I don't think it's a good idea to try to write
    robust, easier to understand, portable, and reusable code, especially
    if it takes comparable or less effort than doing it otherwise. That is
    a good goal to strive for. However, it is not a rule that needs to be
    followed all of the time.

    That is also not to say that I don't think it's a good idea to give
    people advice with the intention of teaching them something new that
    will help them in the future. Perhaps you see their source code or a
    description of their application and say, "hey, by the way, I've found
    that if you do X here you save yourself a lot of work because of A, B,
    and C". It is nice to offer helpful advice. However, it is crucial to
    be constructive here. In the following dialog:

    Johannes Bauer writes:
    > I
    > always use void* in my declaration. I know it is not 100% correct, but
    > it works (at least on x86_64) - but how do I convince gcc to compile the
    > code anyways?


    David Schwartz writes:
    > You can't. The code is simply not sensible. Why do you say "it works"
    > when it generates a compiler error? It doesn't work at all.


    Johannes Bauer writes:
    > It only generates a compiler error if I include the appropriate header
    > files - which I usually don't. ...
    > Apart from you thinking the code is sensible or not - how
    > do I force the compiler to compile it anyways?


    David Schwartz writes:
    > It's funny, you say this:
    > ...
    > Yet you say this:
    > ...
    > So, you're going to GPL this for all the other people using the same
    > platform, same version of GCC, and the same libraries your application
    > links against?!
    > The moral is, never believe someone who says "it's not intended to be
    > portable", "it's a quick hack" or "nobody else will ever use this".
    > They're usually just lazy.


    Your criticism is harsh, contains no actual advice, no specific
    constructive criticism on anything in particular, and has a very
    aggressive attitude that is probably not conducing to teaching people
    a skill that may help them in the future. So while I do believe that
    criticism *can* be helpful, it also is reasonable to believe that your
    criticism was not intended to be positive or helpful.

    > > (of course, if
    > > somebody claims to have written a "cross-platform food processing
    > > library" but it only chops carrots on Windows, you're definitely
    > > justified in smacking them around a bit).

    >
    > Bad design and bad code is still bad even if nobody claims it's good.


    If it gets the job done and meets all of the requirements of the
    problem it hand, then it's really not a problem if the design or the
    code could have been improved. It also also not reasonable to say that
    if the design or code has room for improvement, even a lot of room,
    that it is bad. That is your fundamental misunderstanding here. I have
    a program on my Windows machine that does a quick image processing
    task, it is written in about 100 lines of VisualBASIC. It could have
    been designed better. It is nearly impossible to read. In two weeks if
    I look at it again I will have no idea what I was trying to do. It
    violates some of the most basic rules of thumb (rules of thumbs?) of
    VisualBASIC programming. It is also a perfectly good, functional
    application that did exactly what I needed it to do. It does not make
    sense to call it "bad". The program was a kludge, not a text book
    example for software design techniques. Calling it "bad" is like
    saying that your car is a poorly designed truck which, while somewhat
    amusing on further thought, isn't really a meaningful statement. Going
    on to criticize the car manufacturer for producing poorly designed
    trucks (because you really like trucks) is going to get you a few
    raised eyebrows but it will be hard to convince them of anything
    besides your desire to argue with them.

    > In many cases, it's actually harder to write the non-portable, non-
    > reusable code than it would have been to do it right.


    I completely agree. Your example is a good example, as well. However,
    there is one thing in your example I disagree with strongly:

    > A good example would be writing your own XML library because you "only
    > need a few simple capabilities". Not only is this likely to be more
    > work than using one that's already made, ...


    Absolutely. However:

    > ... but it will likely mishandle
    > a large number of corner cases that maintained XML libraries work hard
    > to get right.


    This should not be a motivating factor in your decision to use a pre-
    existing XML library instead of your own in the situation you describe
    (the situation where you only need a few simple capabilities). If you
    only need a few simple capabilities, and the "XML" library you tossed
    together meets all your requirements, then it does not matter if you
    mishandle corner cases. Handling corner cases properly was not the
    requirement, the requirement was "a few simple capabilities". If you
    want strange corner cases to be handled properly, *then* you use the
    pre-existing XML library -- but if that isn't one of your requirements
    then it's not a factor in your decision. Of course, the "more work
    than using a pre-existing XML library" reason is a very good one; but
    of the two reasons you listed so far, that is the only valid one.

    > It's likely not even faster in execution. And if it is, that doesn't
    > matter anyway since the assumption was that this was a limited-purpose
    > program. And, of course, that would be premature optimization.


    This is the attitude that I was referring to when I said: "My major
    point is that it's unreasonable to claim that all applications should
    consist of portable and reusable code."

    If you set out to design a limited-purpose program, and then you do
    just that, then there is nothing wrong with that. There is no
    "assumption that it is a limited-purpose program" -- you DECIDED that
    it would be a limited-purpose program. When was the last time somebody
    went to the Wendy's drive-thru and said "I'm assuming I would like a
    Jr. Bacon Cheeseburger, although this may be premature optimization"?
    (Ok, well, I can tell you that the next time I go to Wendy's will be
    the *first* time somebody has said that). The programmer is the one
    that sets the goals and requirements. If the requirement is for a
    limited-purpose program that performs a specific task, then making the
    program limited-use and able to only perform that task is not
    "premature optimization", it's "writing the exact program you set out
    to write".

    > It might take up less memory, but who cares? And in many cases, it
    > actually won't.


    This is true, but I don't think it is an important part of the
    original decision. If you decide to hack together an "XML" library
    because you only need some features, many times (sure, not every) the
    rationale is not related to performance so much as "I really feel like
    it would be easier for me to roll my own hacky XML library than to
    learn about a pre-existing one right now". That is not to say that you
    wouldn't benefit immensely in the future from learning how to use a
    pre-existing XML parsing library, but that also does not mean that it
    was wrong of you to base a decision on that logic.

    >
    > DS


    Jason

  2. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mar 17, 4:03 pm, phil-news-nos...@ipal.net wrote:
    > On Mon, 17 Mar 2008 09:33:26 -0700 (PDT) jason.cipri...@gmail.com wrote:
    >
    > | My major point is that it's unreasonable to claim that all
    > | applications should consist of portable and reusable code. Another
    > | point I am making is that it is equally unreasonable to criticize
    > | (even mildly) an application that does not consist of portable/
    > | reusable code and that also makes no claims otherwise (of course, if
    > | somebody claims to have written a "cross-platform food processing
    > | library" but it only chops carrots on Windows, you're definitely
    > | justified in smacking them around a bit).
    >
    > Windows? Isn't that for letting cherry pies cool down?


    A compelling statement indeed, but I'm not so sure anymore. Nowadays,
    I have generally come to believe that if all operating systems and
    platforms were ants on a log, then Windows would be the peanut butter,
    if not the celery... although that may go without saying.

    Jason

  3. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mar 17, 9:39 pm, "jason.cipri...@gmail.com"
    wrote:

    > > Why not? What if the code would have been more robust, easier to
    > > understand, portable, and reusable with even less effort than it took
    > > to make it non-portable and not reusable? Would you still argue that
    > > it's unreasonable to criticize it just because it doesn't claim to be
    > > portable or reusable?


    > Absolutely. It is unreasonable to criticize an application that does
    > not consist of portable/reusable code and that also makes no claims
    > otherwise. That is what I meant. It does not vary case-by-case. The
    > reason I would still argue it is that the application was already
    > complete, already got the job done, and criticizing it after the fact
    > changes nothing unless the author specifically asked for advice or
    > could be convinced to go back and rewrite the application (or apply
    > the concepts in the future).


    I don't know what to say except that I completely disagree with you.
    If you don't want your code used as an example for others, good or
    bad, don't talk about it on USENET.

    I could respond to you point-by-point but there's really no reason.

    DS

  4. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mar 17, 11:36 pm, "jason.cipri...@gmail.com"
    wrote:

    > You would have been better off not posting a reply at all, at least
    > that way you could have pretended to have no longer cared about the
    > topic. Now you've only shown that not only are you incapable of
    > creating constructive criticism, and that you may be a questionable
    > software engineer, but also that when presented with solid points, you
    > instead choose to ignore them and make vague blanket statements about
    > things like "USENET".


    Your defense of bad engineering is laughable. It doesn't merit a point-
    by-point refutation. It's easier and better to just do it right --
    really.

    > > I could respond to you point-by-point but there's really no reason.


    > In fact, I doubt that you can. My last post was fairly solid. I am
    > disappointed by the sudden change in the intensity of your interest in
    > this discussion. I will include it again below, so that it is not lost
    > in your attempt to change the subject:


    I'll point out the more absurd points, just to entertain anyone who
    reads this.

    > > That is not to say that I don't think it's a good idea to try to write
    > > robust, easier to understand, portable, and reusable code, especially
    > > if it takes comparable or less effort than doing it otherwise. That is
    > > a good goal to strive for. However, it is not a rule that needs to be
    > > followed all of the time.


    Which is precisely what I said.

    > > Your criticism is harsh, contains no actual advice, no specific
    > > constructive criticism on anything in particular, and has a very
    > > aggressive attitude that is probably not conducing to teaching people
    > > a skill that may help them in the future. So while I do believe that
    > > criticism *can* be helpful, it also is reasonable to believe that your
    > > criticism was not intended to be positive or helpful.


    Just as with you, it starts out nice and then it gets not-so-nice when
    the claims get more and more dangerous and outrageous. People
    listening to you can cause real damage, and it's important important
    to point out just how wrong you are to protect the people who read
    this group.

    > > > Bad design and bad code is still bad even if nobody claims it's good.


    > > If it gets the job done and meets all of the requirements of the
    > > problem it hand, then it's really not a problem if the design or the
    > > code could have been improved.


    Until the requirements change or someone uses it in a way that wasn't
    anticipated.

    Look, how much longer does it take to add code like:

    #ifndef __LP64
    #error This code has not been developed for or tested on LP64
    platforms
    #endif

    How much time does that take?

    You are also making the completely bogus argument that all solutions
    that meet requirements are equally good. That's simply not true. There
    are better and worse solutions, even among those that meet
    requirements.

    > > It also also not reasonable to say that
    > > if the design or code has room for improvement, even a lot of room,
    > > that it is bad.


    I agree, and I never said that.

    > > That is your fundamental misunderstanding here.


    What, the position you foist on me is my understanding?

    > > I have
    > > a program on my Windows machine that does a quick image processing
    > > task, it is written in about 100 lines of VisualBASIC. It could have
    > > been designed better. It is nearly impossible to read. In two weeks if
    > > I look at it again I will have no idea what I was trying to do. It
    > > violates some of the most basic rules of thumb (rules of thumbs?) of
    > > VisualBASIC programming. It is also a perfectly good, functional
    > > application that did exactly what I needed it to do. It does not make
    > > sense to call it "bad". The program was a kludge, not a text book
    > > example for software design techniques. Calling it "bad" is like
    > > saying that your car is a poorly designed truck which, while somewhat
    > > amusing on further thought, isn't really a meaningful statement. Going
    > > on to criticize the car manufacturer for producing poorly designed
    > > trucks (because you really like trucks) is going to get you a few
    > > raised eyebrows but it will be hard to convince them of anything
    > > besides your desire to argue with them.


    Nonsense, complete nonsense. A solution is not "good" just because it
    meets requirements, it's adequate. There could be a universe of
    possible soltions that meet requirements.

    As a silly example, consider two programs otherwise identical. One has
    no comments and variables like 'MyVariable1', the other is well-
    commented and has variables with names that immediately suggest their
    use. The former one is easier to understand, maintain, and debug. It
    even took less time to write because the programmer knew what his
    variables meant and occasionally found his own comments helpful to
    remind him why he did things the way he did.

    Now, will you seriously argue these are equally good?

    > > > A good example would be writing your own XML library because you "only
    > > > need a few simple capabilities". Not only is this likely to be more
    > > > work than using one that's already made, ...

    >
    > > Absolutely. However:

    >
    > > > ... but it will likely mishandle
    > > > a large number of corner cases that maintained XML libraries work hard
    > > > to get right.


    > > This should not be a motivating factor in your decision to use a pre-
    > > existing XML library instead of your own in the situation you describe
    > > (the situation where you only need a few simple capabilities). If you
    > > only need a few simple capabilities, and the "XML" library you tossed
    > > together meets all your requirements, then it does not matter if you
    > > mishandle corner cases. Handling corner cases properly was not the
    > > requirement, the requirement was "a few simple capabilities". If you
    > > want strange corner cases to be handled properly, *then* you use the
    > > pre-existing XML library -- but if that isn't one of your requirements
    > > then it's not a factor in your decision. Of course, the "more work
    > > than using a pre-existing XML library" reason is a very good one; but
    > > of the two reasons you listed so far, that is the only valid one.


    I picked this example because it really happened. Guess what, it turns
    out he needed the corner cases. The thing is, he didn't make an
    intelligent decision that he didn't need the corner cases because he
    didn't know what the corner cases were because he wasn't an XML
    expert.

    Do you know which of the following are valid and which not


    > > > matter anyway since the assumption was that this was a limited-purpose
    > > > program. And, of course, that would be premature optimization.

    > > This is the attitude that I was referring to when I said: "My major
    > > point is that it's unreasonable to claim that all applications should
    > > consist of portable and reusable code."


    Huh? How so?

    > > If you set out to design a limited-purpose program, and then you do
    > > just that, then there is nothing wrong with that. There is no
    > > "assumption that it is a limited-purpose program" -- you DECIDED that
    > > it would be a limited-purpose program. When was the last time somebody
    > > went to the Wendy's drive-thru and said "I'm assuming I would like a
    > > Jr. Bacon Cheeseburger, although this may be premature optimization"?


    I can't imagine how you think this responds to me or disagrees with
    me. If you were going to a job site fifty miles away, would you take a
    drill with a half-charged battery or a fully-charged one if you
    thought you'd only need about half a battery's worth?

    Sure, that means you don't add code outside the purpose. But it
    doesn't mean that two choices are automatically equally good just
    because they have no difference in effect outside the limited purpose.

    > > (Ok, well, I can tell you that the next time I go to Wendy's will be
    > > the *first* time somebody has said that). The programmer is the one
    > > that sets the goals and requirements. If the requirement is for a
    > > limited-purpose program that performs a specific task, then making the
    > > program limited-use and able to only perform that task is not
    > > "premature optimization", it's "writing the exact program you set out
    > > to write".


    That wasn't my example. My example was where you made a decision based
    on performance even though performance wasn't important given the
    limited purpose. In other words, the programmer *failed* to respect
    the limitation in purpose and I'm criticizing him for that. I don't
    know how you got it 100% backwards.

    > > > It might take up less memory, but who cares? And in many cases, it
    > > > actually won't.


    > > This is true, but I don't think it is an important part of the
    > > original decision. If you decide to hack together an "XML" library
    > > because you only need some features, many times (sure, not every) the
    > > rationale is not related to performance so much as "I really feel like
    > > it would be easier for me to roll my own hacky XML library than to
    > > learn about a pre-existing one right now". That is not to say that you
    > > wouldn't benefit immensely in the future from learning how to use a
    > > pre-existing XML parsing library, but that also does not mean that it
    > > was wrong of you to base a decision on that logic.


    Except, ironically, it turns out to be a lose all around. It takes
    longer to make the hacky library (Oh, there are some XML tags that
    aren't closed! Oh, where exactly are comments legal and when must I
    remove them? Oh, ...). It fails in corner cases you had no idea
    existed. It performs worse. And, the next time you really do need a
    full-featured XML library, you have to learn it anyway.

    It's a great example of a bad decision and it's precisely the type I'm
    warning people about here.

    DS

  5. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On 18 Mar, 09:05, David Schwartz wrote:

    > As a silly example, consider two programs otherwise identical. One has
    > no comments and variables like 'MyVariable1', the other is well-
    > commented and has variables with names that immediately suggest their
    > use. The former one is easier to understand, maintain, and debug.


    s/former/latter/g

    At least, I hope that's what you meant.

  6. Re: Dynamic linking with LD_PRELOAD - get it compiled

    David Schwartz wrote:
    > On Mar 17, 9:33 am, "jason.cipri...@gmail.com"
    > wrote:
    >
    >> My major point is that it's unreasonable to claim that all
    >> applications should consist of portable and reusable code.

    >
    > Well, since nobody claimed that, ...
    >
    >> Another
    >> point I am making is that it is equally unreasonable to criticize
    >> (even mildly) an application that does not consist of portable/
    >> reusable code and that also makes no claims otherwise

    >
    > Why not? What if the code would have been more robust, easier to
    > understand, portable, and reusable with even less effort than it took
    > to make it non-portable and not reusable? Would you still argue that
    > it's unreasonable to criticize it just because it doesn't claim to be
    > portable or reusable?


    You can posit anything, of course, but reality tends to be less
    theoretical.
    You keep making statements like this. I tend to ignore, if not
    openly ridicule statements that begin "what if".

    >
    >> (of course, if
    >> somebody claims to have written a "cross-platform food processing
    >> library" but it only chops carrots on Windows, you're definitely
    >> justified in smacking them around a bit).

    >
    > Bad design and bad code is still bad even if nobody claims it's good.
    > In many cases, it's actually harder to write the non-portable, non-
    > reusable code than it would have been to do it right.
    >


    According to _you_.
    You don't seem to consider little things like time constraints in your
    view of reality. This is software engineering, and like any
    engineering discipline, there are trade-offs.

    > A good example would be writing your own XML library because you "only
    > need a few simple capabilities". Not only is this likely to be more
    > work than using one that's already made, but it will likely mishandle
    > a large number of corner cases that maintained XML libraries work hard
    > to get right.
    >
    > It's likely not even faster in execution. And if it is, that doesn't
    > matter anyway since the assumption was that this was a limited-purpose
    > program. And, of course, that would be premature optimization.
    >
    > It might take up less memory, but who cares? And in many cases, it
    > actually won't.
    >
    > DS


  7. Re: Dynamic linking with LD_PRELOAD - get it compiled

    David Schwartz wrote:
    > On Mar 17, 9:39 pm, "jason.cipri...@gmail.com"
    > wrote:
    >
    >> > Why not? What if the code would have been more robust, easier to
    >> > understand, portable, and reusable with even less effort than it took
    >> > to make it non-portable and not reusable? Would you still argue that
    >> > it's unreasonable to criticize it just because it doesn't claim to be
    >> > portable or reusable?

    >
    >> Absolutely. It is unreasonable to criticize an application that does
    >> not consist of portable/reusable code and that also makes no claims
    >> otherwise. That is what I meant. It does not vary case-by-case. The
    >> reason I would still argue it is that the application was already
    >> complete, already got the job done, and criticizing it after the fact
    >> changes nothing unless the author specifically asked for advice or
    >> could be convinced to go back and rewrite the application (or apply
    >> the concepts in the future).

    >
    > I don't know what to say except that I completely disagree with you.
    > If you don't want your code used as an example for others, good or
    > bad, don't talk about it on USENET.
    >
    > I could respond to you point-by-point but there's really no reason.
    >
    > DS


    You keep acting like a pedantic acedemic. You keep talking about
    USENET as if it's something very special instead of a world spanning
    public bulletin board.

    Neither I, nor anyone else has to fulfill your expectations.

    Yes, I'll agree code _should_ be readable and maintainable,
    unfortunately there's an awful lot of _awful_ code out there (take a
    look at some of the old BSD apps, for example). Old code that's had a
    lot of different maintainers seems to fall into this category.o

    Jerry

  8. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mar 18, 12:01 pm, William Pursell wrote:

    > On 18 Mar, 09:05, David Schwartz wrote:


    > > As a silly example, consider two programs otherwise identical. One has
    > > no comments and variables like 'MyVariable1', the other is well-
    > > commented and has variables with names that immediately suggest their
    > > use. The former one is easier to understand, maintain, and debug.


    > s/former/latter/g
    >
    > At least, I hope that's what you meant.


    Nah, I hate comments, even good ones. And I love senseless variable
    names.

    Yeah, you're right.

    DS

  9. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mar 18, 1:14 pm, Jerry Peters wrote:

    > > Bad design and bad code is still bad even if nobody claims it's good.
    > > In many cases, it's actually harder to write the non-portable, non-
    > > reusable code than it would have been to do it right.


    > According to _you_.


    That's a great response. Save it. You can use it to respond to
    literally anything. My personal favorite is -- "that's what you
    think!" -- you are welcome to use that one.

    > You don't seem to consider little things like time constraints in your
    > view of reality. This is software engineering, and like any
    > engineering discipline, there are trade-offs.


    My whole post is about making sensible trade-offs. The section you are
    directly responding to points out that it usually takes longer to do
    it wrong than to do it right.

    DS

  10. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mar 18, 1:21 pm, Jerry Peters wrote:

    > > If you don't want your code used as an example for others, good or
    > > bad, don't talk about it on USENET.


    > You keep acting like a pedantic acedemic. You keep talking about
    > USENET as if it's something very special instead of a world spanning
    > public bulletin board.


    Err, what?!

    > Neither I, nor anyone else has to fulfill your expectations.


    Really? And where did I say or imply otherwise?

    That's a great generic reply -- you can use it to reply to any case
    where one person gives another advice.

    > Yes, I'll agree code _should_ be readable and maintainable,
    > unfortunately there's an awful lot of _awful_ code out there (take a
    > look at some of the old BSD apps, for example). Old code that's had a
    > lot of different maintainers seems to fall into this category.


    That code gets awful in various different ways. But one of the ways it
    gets awful is people who made bad trade-offs. They thought they were
    making a quick fix to code that wouldn't be re-used or wouldn't be
    ported, so they didn't add good comments or use sensible variable
    names, or whatever. My point is, quite often the very people who make
    these decisions pay for them personally, when they do in fact later
    have to modify or maintain the code.

    Whenever you catch yourself saying one of the following things, you
    need to make absolutely sure you understand what you're trading off
    and what you're getting for it, because it's frequently these thoughts
    that precede the making of a bad trade off:

    1) Nobody's is ever going to use this code again.

    2) This code will never be ported to another platform.

    3) I just need this limited functionality, so I'll roll my own.

    4) There's no need to comment this, nobody is going to look at this
    code.

    5) This works on my machine, so I'll do it that way.

    And so on.

    DS

  11. Re: Dynamic linking with LD_PRELOAD - get it compiled

    David Schwartz writes:
    > On Mar 17, 9:33 am, "jason.cipri...@gmail.com"


    [...]

    >> (of course, if
    >> somebody claims to have written a "cross-platform food processing
    >> library" but it only chops carrots on Windows, you're definitely
    >> justified in smacking them around a bit).

    >
    > Bad design and bad code is still bad even if nobody claims it's good.
    > In many cases, it's actually harder to write the non-portable, non-
    > reusable code than it would have been to do it right.


    I would still have to meet any such case. It is usually easier to not
    'design' and (preferably) not 'write code' but to just add some hacks
    to generic third party code to make it perform some functionality its
    originators would never have dreamed of. The net result of doing so
    will be a slow, bulky application exhibiting lots of weird behaviour
    in various corner cases (nobody has yet added the necessary hacks to
    deal with) and lots of basically unfixable bugs. But time-to-market
    will be really little.

    There you have the 'typical' proprietary, commercial application (I
    had the mispleasure to deal with so far).

    > A good example would be writing your own XML library because you "only
    > need a few simple capabilities".


    This is still a red herring: Someone needing 'a few simple
    capabilities' would not use XML to begin with (Ideally, that is). That
    someone would design a simple configuration language well adapted to
    his particular problem and use that.

    [...]

    > It's likely not even faster in execution.


    Parsing textual data is never fast. And neither should it ever matter
    exactly how slow it is.

  12. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mar 19, 3:24 am, Rainer Weikusat wrote:

    > > A good example would be writing your own XML library because you "only
    > > need a few simple capabilities".


    > This is still a red herring: Someone needing 'a few simple
    > capabilities' would not use XML to begin with (Ideally, that is). That
    > someone would design a simple configuration language well adapted to
    > his particular problem and use that.


    In the real example this was based on, XML was not the author's
    choice. The "quick and dirty hack" had to interoperate with another
    program that outputted XML. Things got ugly when the next version of
    the program it had to interoperate with slightly changed the XML
    output to output that is technically XML-equivalent.

    DS

  13. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mar 13, 6:02 am, phil-news-nos...@ipal.net wrote:

    > | But none of that will happen if you start out knowingly doing it
    > | wrong.


    > Not necessarily. I call it "prototyping". I see no reason not to let
    > it loose, as as long as you don't make any claims that it is believed to
    > be done right.


    Yeah, that's a fair point. It may ultimately be more efficient to do
    it a bit "fast and loose" the first time, rather than wasting time
    improving an implementation you are probably just going to throw away.
    If it happens to meet all of your requirements, and it turns out not
    to be too horribly awful, you're done. If it turns out not to and to
    be truly awful, at least you'll have gained some insight into what
    works, what doesn't, and why.

    I would still argue that you should at least put in appropriate
    cautionary comments, #ifdef's and #warning's.

    For algorithmic code, it's a very good idea to build in some test
    cases and check out the code on startup. A good example would be an
    application with a "quick and dirty" implementation of something like
    MD5. If you haven't checked it on systems with a different size for
    some of the types you use or a different endian-ness, a few quick
    check hashes on startup will catch a problem before it results in
    incorrect operation.

    DS

  14. Re: Dynamic linking with LD_PRELOAD - get it compiled

    David Schwartz wrote:
    > On Mar 18, 1:14 pm, Jerry Peters wrote:
    >
    >> > Bad design and bad code is still bad even if nobody claims it's good.
    >> > In many cases, it's actually harder to write the non-portable, non-
    >> > reusable code than it would have been to do it right.

    >
    >> According to _you_.

    >
    > That's a great response. Save it. You can use it to respond to
    > literally anything. My personal favorite is -- "that's what you
    > think!" -- you are welcome to use that one.
    >

    No, I can keep using it because you keep asserting things without any
    proof. I've been in the programming business long enough to know
    copious quantities of MBE when I see it.

    >> You don't seem to consider little things like time constraints in your
    >> view of reality. This is software engineering, and like any
    >> engineering discipline, there are trade-offs.

    >
    > My whole post is about making sensible trade-offs. The section you are
    > directly responding to points out that it usually takes longer to do
    > it wrong than to do it right.
    >
    > DS


    Again according to you. No proof. Also I see you say "usually".

    Jerry

  15. Re: Dynamic linking with LD_PRELOAD - get it compiled

    David Schwartz wrote:
    > On Mar 18, 1:21 pm, Jerry Peters wrote:
    >
    >> > If you don't want your code used as an example for others, good or
    >> > bad, don't talk about it on USENET.

    >
    >> You keep acting like a pedantic acedemic. You keep talking about
    >> USENET as if it's something very special instead of a world spanning
    >> public bulletin board.

    >
    > Err, what?!


    You keep telling the rest of us poor deluded fools how USENET works.

    >
    >> Neither I, nor anyone else has to fulfill your expectations.

    >
    > Really? And where did I say or imply otherwise?
    >

    Um, this thread perhaps?

    > That's a great generic reply -- you can use it to reply to any case
    > where one person gives another advice.
    >

    You've gone well past the point of giving advice, you've been
    preaching for the past several days.

    >> Yes, I'll agree code _should_ be readable and maintainable,
    >> unfortunately there's an awful lot of _awful_ code out there (take a
    >> look at some of the old BSD apps, for example). Old code that's had a
    >> lot of different maintainers seems to fall into this category.

    >
    > That code gets awful in various different ways. But one of the ways it
    > gets awful is people who made bad trade-offs. They thought they were
    > making a quick fix to code that wouldn't be re-used or wouldn't be
    > ported, so they didn't add good comments or use sensible variable
    > names, or whatever. My point is, quite often the very people who make
    > these decisions pay for them personally, when they do in fact later
    > have to modify or maintain the code.
    >

    Or, as I keep trying to point out to you, they had a severe time
    constraint to deal with. Perhaps a little thing like the bank can't
    clear checks. Ever worked in a bank? That's a _major_ crisis,
    something that has to be fixed _now_.

    > Whenever you catch yourself saying one of the following things, you
    > need to make absolutely sure you understand what you're trading off
    > and what you're getting for it, because it's frequently these thoughts
    > that precede the making of a bad trade off:
    >
    > 1) Nobody's is ever going to use this code again.
    >
    > 2) This code will never be ported to another platform.
    >
    > 3) I just need this limited functionality, so I'll roll my own.
    >
    > 4) There's no need to comment this, nobody is going to look at this
    > code.
    >
    > 5) This works on my machine, so I'll do it that way.
    >
    > And so on.
    >
    > DS


    Jerry

  16. Re: Dynamic linking with LD_PRELOAD - get it compiled

    David Schwartz writes:
    > On Mar 19, 3:24 am, Rainer Weikusat wrote:
    >> > A good example would be writing your own XML library because you "only
    >> > need a few simple capabilities".

    >
    >> This is still a red herring: Someone needing 'a few simple
    >> capabilities' would not use XML to begin with (Ideally, that is). That
    >> someone would design a simple configuration language well adapted to
    >> his particular problem and use that.

    >
    > In the real example this was based on, XML was not the author's
    > choice. The "quick and dirty hack" had to interoperate with another
    > program that outputted XML. Things got ugly when the next version of
    > the program it had to interoperate with slightly changed the XML
    > output to output that is technically XML-equivalent.


    If this was really a slight change, ie none affecting the semantic
    structure of the text, this would rather appear to be a problem caused
    by a badly written parser and/or lexical analyzer. But even then, the
    original choice could have been sensible for other reasons, depending
    on the situation. Eg, the w3c XML 'schema' page
    (http://www.w3.org/XML/Schema) lists an awful lot of tools whose main
    purpose is to get rid of XML in favor of something which can either be
    used more easily in a program or (even) be understood by a human when
    displayed. When a lot of people feel to need to program tools solving
    particular programming problems in a generally useful way, instead of
    solving real problems, this would be a strong hint that a certain
    something is actually way too complicated to be used by the same large
    number of people. The 'quick and dirty hack' was likely still more
    useful to the people wanting to process the data than a statement like
    "sorry, I don't understand this weird ****, go find someone else"
    would have been. Especially taking into account that really believing
    to understand something is very much different from actually
    understanding it.

    "We have (for some idiotic reason) chosen to use a utility which none
    of the people we employ could comprehend anymore, therefore, sorry, no
    product" doesn't exactly sound like a recommendation.


  17. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mar 19, 2:02 pm, Rainer Weikusat wrote:

    > > In the real example this was based on, XML was not the author's
    > > choice. The "quick and dirty hack" had to interoperate with another
    > > program that outputted XML. Things got ugly when the next version of
    > > the program it had to interoperate with slightly changed the XML
    > > output to output that is technically XML-equivalent.


    > If this was really a slight change, ie none affecting the semantic
    > structure of the text, this would rather appear to be a problem caused
    > by a badly written parser and/or lexical analyzer.


    Bingo. That's often what happens when you "roll your own" that does
    "just what you need". Often, and especially in "quick and dirty" mode,
    you dont' know what you need.

    > But even then, the
    > original choice could have been sensible for other reasons, depending
    > on the situation. Eg, the w3c XML 'schema' page
    > (http://www.w3.org/XML/Schema) lists an awful lot of tools whose main
    > purpose is to get rid of XML in favor of something which can either be
    > used more easily in a program or (even) be understood by a human when
    > displayed. When a lot of people feel to need to program tools solving
    > particular programming problems in a generally useful way, instead of
    > solving real problems, this would be a strong hint that a certain
    > something is actually way too complicated to be used by the same large
    > number of people. The 'quick and dirty hack' was likely still more
    > useful to the people wanting to process the data than a statement like
    > "sorry, I don't understand this weird ****, go find someone else"
    > would have been. Especially taking into account that really believing
    > to understand something is very much different from actually
    > understanding it.


    > "We have (for some idiotic reason) chosen to use a utility which none
    > of the people we employ could comprehend anymore, therefore, sorry, no
    > product" doesn't exactly sound like a recommendation.


    I agree. Ironically, in this particular case, I think XML was in fact
    badly chosen. I don't know the exact reasons since I wasn't involved
    in any way with the tool he had to interoperate with, but I think it
    was chosen just because XML was "cool".

    DS

  18. Re: Dynamic linking with LD_PRELOAD - get it compiled

    >>Right, but that mentality doesn't work any more. In the vast majority
    of programming applications, maintainability, understandability, and
    reusability are much more important than squeezing out a few bytes.
    <<

    > We need to lose the mentality from the 60s through the 90s that
    > performance and space efficiency are priority one. For the bulk of
    > code written today, correctness, understandability and maintainability
    > are extremely important. They should never be sacrificed for
    > performance or alleged convenience when there is no good reason to do
    > so.
    >


    This is directed at no one in particular, just my 5 cents worth...

    Professionally I nod and smile at this. And I agree in many cases. It
    makes sense, and if your manager preaches such things then you esp. want
    to get along. Maintainability and reuse should be kept in mind from the
    beginning.

    That being said, overall i've been kind of disgusted with the direction
    that the academic types have taken software development over the last 15
    years. I would include code bloggers with this group too. JoelOnSoftware
    types, 'you're all doing it wrong, look at me, look at me'. bah

    Its like we are writing source code now just for the sake of writing
    source code. HELLO!! the point is the binary! the execution! the user
    experience! and yes the performance! I use slow apps and slow websites
    all the time. Just today I opened a GNOME file browser dialog and had to
    wait 11 seconds for it to scan the folder. This on a very new machine.

    And code reuse is a myth. Code is maintained, ported, or replaced. Just
    like it always has been. I don't see how components have changed
    anything. I predicted .Net wouldn't last 5 years and it didn't. It
    lasted about 2 years and was replaced by .Net 2.0. Personally, the only
    thing i've truly seen reused, over a span of tens of years is database
    schema. Usually with new parts bolted on.

  19. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Mon, 31 Mar 2008 16:44:38 -0700 moe wrote:
    |>>Right, but that mentality doesn't work any more. In the vast majority
    | of programming applications, maintainability, understandability, and
    | reusability are much more important than squeezing out a few bytes.
    | <<
    |
    |> We need to lose the mentality from the 60s through the 90s that
    |> performance and space efficiency are priority one. For the bulk of
    |> code written today, correctness, understandability and maintainability
    |> are extremely important. They should never be sacrificed for
    |> performance or alleged convenience when there is no good reason to do
    |> so.
    |>
    |
    | This is directed at no one in particular, just my 5 cents worth...
    |
    | Professionally I nod and smile at this. And I agree in many cases. It
    | makes sense, and if your manager preaches such things then you esp. want
    | to get along. Maintainability and reuse should be kept in mind from the
    | beginning.
    |
    | That being said, overall i've been kind of disgusted with the direction
    | that the academic types have taken software development over the last 15
    | years. I would include code bloggers with this group too. JoelOnSoftware
    | types, 'you're all doing it wrong, look at me, look at me'. bah
    |
    | Its like we are writing source code now just for the sake of writing
    | source code. HELLO!! the point is the binary! the execution! the user
    | experience! and yes the performance! I use slow apps and slow websites
    | all the time. Just today I opened a GNOME file browser dialog and had to
    | wait 11 seconds for it to scan the folder. This on a very new machine.

    Maybe you have too many files in your folder. You know people like Joel
    would never, ever, have more than 255 files in their folder :-)

    FYI, I have too many files in my folder, too. The "ls" command can be
    quite painful. Oh wait, I should say "directory" since I do command
    line more.


    | And code reuse is a myth. Code is maintained, ported, or replaced. Just
    | like it always has been. I don't see how components have changed
    | anything. I predicted .Net wouldn't last 5 years and it didn't. It
    | lasted about 2 years and was replaced by .Net 2.0. Personally, the only
    | thing i've truly seen reused, over a span of tens of years is database
    | schema. Usually with new parts bolted on.

    What I see happening way, way, too often is code _repurposing_ to do things
    it was never expected to do, and in most cases, cannot do effectively.

    There seems to be too much emphasis on code _quantity_ instead of _quality_.
    Sure, if company A has a nice HR app then there's little reason company B
    should have to have one written from scratch for their HR dept. To me, that
    is the ultimate code reuse (use the same app in two or more instances of the
    need for exactly that app).

    Code should only be reused within the scope of what it was written for.
    The idea, then, would be to write code that has a very wide scope.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2008-04-01-1108@ipal.net |
    |------------------------------------/-------------------------------------|

  20. Re: Dynamic linking with LD_PRELOAD - get it compiled

    On Apr 1, 9:14 am, phil-news-nos...@ipal.net wrote:

    > Code should only be reused within the scope of what it was written for.
    > The idea, then, would be to write code that has a very wide scope.


    Or perhaps it's even possible to write code with a narrow scope but to
    facilitate expansion of the scope. Perhaps we should be thinking about
    extensible code.

    DS

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast