49 ms·

A series of assertions and "I just don't see it"-s presented as self-evident when they are anything but. No examples of real cases where OO does in fact "suck"

A series of assertions and "I just don't see it"-s presented as self-evident when they are anything but. No examples of real cases where OO does in fact "suck", ending with the claim that in order to understand the popularity of OO one should "follow the money". What? I mean, I don't even...

MortenK 14y ago
Indeed, it's a very odd piece. No arguments except opinions ("state is bad", "functions and data shouldn't mix" etc). I fail to see the underlying reasoning for any of his gripes. It just comes of as a frustrated computer scientist / mathematician complaining that his theoretically correct way of making machines do his bidding, is not loved by all.
comex 14y ago
harmful.cat-v.org has a lot of odd opinions: http://harmful.cat-v.org/software/dynamic-linking/ http://harmful.cat-v.org/software/dynamic-linking/ http://harmful.cat-v.org/political-correctness/girls-in-CS http://harmful.cat-v.org/political-correctness/girls-in-CS
- arrakeen 14y ago
  i'd take anything i read at cat-v.org with a grain of salt, they seem to appreciate the art of trolling: http://gofy.cat-v.org http://gofy.cat-v.org
- masry 14y ago
  OFFTOPIC - Man I can't believe how often I am coming across "sexist in IT" stuff now. I read your second link and I thought to myself it all makes sense. Demanding that compsci have more women is like demanding [insert women dominated field here] have more men, even though most men just aren't interested in the stuff. Why bother? Why not just let people work on what they want to work on? Is this making me a sexist misogynistic jerk? I am not trolling, I am honestly curious. Explain to me why I am wrong. I will reflect and make up my mind and be intense and stuff.
- Locke1689 14y ago
  Dynamic linking seems to be a rather straightforward technical argument. I'm not sure what to tell you if you can't or won't parse it.
  - comex 14y ago
    I've had a conversation about it on HN in the past: http://news.ycombinator.com/item?id=4112517 http://news.ycombinator.com/item?id=4112517 I wouldn't mind discussing it again.
    - einhverfr 14y ago
      when zlib had that double-free bug a while back, how many programs had to be updated because of static linking? I think the problem is that in most of these cases, people only count one side of the ledger. On the whole, I think static linking causes more security issues than dynamic linking, but dynamic linking causes some other problems that are less well accounted for.
      - rapala 14y ago
        A security hole in a library is "automatically distributed" to every program dynamically linked against it. Yes, the coin has two sides.
        einhverfr 14y ago
        I am not saying that dynamic linking is perfect. However, a lot of it comes down to how manageable is security. How many programs do I have to update? How sure am I as the sysadmin that I got them all? This is easier with dynamic linking than with something ubiquitous but often statically linked like zlib. Yeah there is a tradeoff. I am not saying there is no downside. I am just saying security-wise, I prefer a single-point-of-correction to a case where I may not know where the weakest link is.
- discussit 14y ago
  The second link is to gibberish from reddit. Not sure if it's a joke or if it represents the opinions of cat-v. But the first link is on the money. I would not call it "odd" as that seems to carry a negative connotation. Rather, it's sensible, albeit irreverent, thinking to question dynamic linking (as the Plan 9 people have) and alas the mainstream of software development has a difficult time thinking sensibly and prefers to "follow the herd". Dynamic linking is anything but a clear "win", using the silly web lingo of today. It's one of those many engineering trade offs we continue to live with even though the original rationale for its adoption no longer exists. Here's the problem as I see it. You link to a library of n functions where, e.g., n > 10. But your program only uses 1 or 2 of those functions. There is no accounting method for keeping track of which functions each of those "4000" different binaries uses. How easy is it to tell me what functions each of those "4000" binaries uses, and which libraries they reside in? I have to resort to binutils hackery to extract this info, but it seems like basic information that should be easily available... because it should be used in making decisions. Why link to a library with, e.g., > 10 functions when your program only uses, e.g., 2 of them? How many functions in those libraries that your program links to are not used by your program? No big deal you say. And that's true. Because of dynamic linking. Dynamic linking to some degree makes us disregard this wasteful "black box" approach to use of library functions. But what if we started static linking? Then maybe we start to think more about those functions that are in the linked library but are not used. We might even question the whole idea of libraries. What if we took an accounting of all the unused functions? How much space would they account for? Why package functions together in libraries? Whatever the original reasons were for adopting this practice, do they still exist today? How many libraries do you have installed on your system that are only used by one or a few programs? Is there a threshhold for how many programs need to use a group of functions before it justifies creating a library tobe shared? If we really want to have functions that are to be shared among many disparate programs, and we have "4000" programs (cf. the no. of programs on a system in the 1980's) then it makes less sense to place them in arbitrary libraries (how many people know the location of every C fucntion purely based on library names intuition?) that have to be linked to as a unit. We perpetuate a black box. It makes more sense to have each function available on its own, and each program can select only those functions that it needs. This is if we were static linking. I do a lot of static linking because I move programs from system to system. It works very well. Another thing that I sometimes think about is the sticky bit. We try to achieve the same effect with caching. You call a program for the first time, it take some time to load. You call it a second time and hopefully it's all in the cache, and it is much more "responsive". But what if it cannot fit in the cache? What if another program displace it? Why can't we conscisouly keep a program in a "cache"? We give control to the OS, and we hope everything works as intended. Dynamic linking reminds me very much of package management systems, particularly those that build form source. It's extremely difficult to tell what a particular install procedure consists of. You type "make" and what happens next is in many respects a black box. Only so much information can be reliably extracted from the system. For example, if you wanted to know all the possible Makefile variables in the package management system, it's virtually impossible to get a list. You can get most, but not all. The way thse systems work is a lot like shared libraries. The mainatiners err on the side of overinclusion of dependencies, some of which may not actually be needed, in order to keep the black box working reliably.

MortenK 14y ago

Indeed, it's a very odd piece. No arguments except opinions ("state is bad", "functions and data shouldn't mix" etc). I fail to see the underlying reasoning for any of his gripes. It just comes of as a frustrated computer scientist / mathematician complaining that his theoretically correct way of making machines do his bidding, is not loved by all.

comex 14y ago

harmful.cat-v.org has a lot of odd opinions: http://harmful.cat-v.org/software/dynamic-linking/ http://harmful.cat-v.org/software/dynamic-linking/ http://harmful.cat-v.org/political-correctness/girls-in-CS http://harmful.cat-v.org/political-correctness/girls-in-CS

arrakeen 14y ago
i'd take anything i read at cat-v.org with a grain of salt, they seem to appreciate the art of trolling: http://gofy.cat-v.org http://gofy.cat-v.org
masry 14y ago
OFFTOPIC - Man I can't believe how often I am coming across "sexist in IT" stuff now. I read your second link and I thought to myself it all makes sense. Demanding that compsci have more women is like demanding [insert women dominated field here] have more men, even though most men just aren't interested in the stuff. Why bother? Why not just let people work on what they want to work on? Is this making me a sexist misogynistic jerk? I am not trolling, I am honestly curious. Explain to me why I am wrong. I will reflect and make up my mind and be intense and stuff.
Locke1689 14y ago
Dynamic linking seems to be a rather straightforward technical argument. I'm not sure what to tell you if you can't or won't parse it.
- comex 14y ago
  I've had a conversation about it on HN in the past: http://news.ycombinator.com/item?id=4112517 http://news.ycombinator.com/item?id=4112517 I wouldn't mind discussing it again.
  - einhverfr 14y ago
    when zlib had that double-free bug a while back, how many programs had to be updated because of static linking? I think the problem is that in most of these cases, people only count one side of the ledger. On the whole, I think static linking causes more security issues than dynamic linking, but dynamic linking causes some other problems that are less well accounted for.
    - rapala 14y ago
      A security hole in a library is "automatically distributed" to every program dynamically linked against it. Yes, the coin has two sides.
      - einhverfr 14y ago
        I am not saying that dynamic linking is perfect. However, a lot of it comes down to how manageable is security. How many programs do I have to update? How sure am I as the sysadmin that I got them all? This is easier with dynamic linking than with something ubiquitous but often statically linked like zlib. Yeah there is a tradeoff. I am not saying there is no downside. I am just saying security-wise, I prefer a single-point-of-correction to a case where I may not know where the weakest link is.
discussit 14y ago
The second link is to gibberish from reddit. Not sure if it's a joke or if it represents the opinions of cat-v. But the first link is on the money. I would not call it "odd" as that seems to carry a negative connotation. Rather, it's sensible, albeit irreverent, thinking to question dynamic linking (as the Plan 9 people have) and alas the mainstream of software development has a difficult time thinking sensibly and prefers to "follow the herd". Dynamic linking is anything but a clear "win", using the silly web lingo of today. It's one of those many engineering trade offs we continue to live with even though the original rationale for its adoption no longer exists. Here's the problem as I see it. You link to a library of n functions where, e.g., n > 10. But your program only uses 1 or 2 of those functions. There is no accounting method for keeping track of which functions each of those "4000" different binaries uses. How easy is it to tell me what functions each of those "4000" binaries uses, and which libraries they reside in? I have to resort to binutils hackery to extract this info, but it seems like basic information that should be easily available... because it should be used in making decisions. Why link to a library with, e.g., > 10 functions when your program only uses, e.g., 2 of them? How many functions in those libraries that your program links to are not used by your program? No big deal you say. And that's true. Because of dynamic linking. Dynamic linking to some degree makes us disregard this wasteful "black box" approach to use of library functions. But what if we started static linking? Then maybe we start to think more about those functions that are in the linked library but are not used. We might even question the whole idea of libraries. What if we took an accounting of all the unused functions? How much space would they account for? Why package functions together in libraries? Whatever the original reasons were for adopting this practice, do they still exist today? How many libraries do you have installed on your system that are only used by one or a few programs? Is there a threshhold for how many programs need to use a group of functions before it justifies creating a library tobe shared? If we really want to have functions that are to be shared among many disparate programs, and we have "4000" programs (cf. the no. of programs on a system in the 1980's) then it makes less sense to place them in arbitrary libraries (how many people know the location of every C fucntion purely based on library names intuition?) that have to be linked to as a unit. We perpetuate a black box. It makes more sense to have each function available on its own, and each program can select only those functions that it needs. This is if we were static linking. I do a lot of static linking because I move programs from system to system. It works very well. Another thing that I sometimes think about is the sticky bit. We try to achieve the same effect with caching. You call a program for the first time, it take some time to load. You call it a second time and hopefully it's all in the cache, and it is much more "responsive". But what if it cannot fit in the cache? What if another program displace it? Why can't we conscisouly keep a program in a "cache"? We give control to the OS, and we hope everything works as intended. Dynamic linking reminds me very much of package management systems, particularly those that build form source. It's extremely difficult to tell what a particular install procedure consists of. You type "make" and what happens next is in many respects a black box. Only so much information can be reliably extracted from the system. For example, if you wanted to know all the possible Makefile variables in the package management system, it's virtually impossible to get a list. You can get most, but not all. The way thse systems work is a lot like shared libraries. The mainatiners err on the side of overinclusion of dependencies, some of which may not actually be needed, in order to keep the black box working reliably.