7 ms·

(commenting on one of the articles) Wow. Just stumbled upon the following quote and read the corresponding article. > Programming language comparisons usually

• seanmcdirmid 12y ago
  > - https://codewords.hackerschool.com/issues/one/why-are-object.. https://codewords.hackerschool.com/issues/one/why-are-object.... > In all seriousness, this is one of the best articles I've ever read. I couldn't agree more with the author. I'm not sure if you are being serious (you say you are, so Po's law), but this is a bad article written by someone who I guess must be a novice who thinks he knows something now but will look back on this 5 years later and cringe; examples... > From the perspective of debugging, an instance variable is not in the scope of any of the methods on the stack. He might as well be talking about heap allocated structs in C. > This threatens to increase the search space, and suggests that avoiding instance variables in favor of passing arguments might be a better strategy where possible. State should be stack allocated, except when it really is state (even if hidden in a monad). > if you make the mistake of defining public “setter” methods, then the instance variables with setter methods become effectively global variables: if the value of the instance variable is incorrect at some point, that incorrect value might have been set anywhere in your code. I'm trying really hard now to not be sarcastic. > So, to avoid making your object-oriented code harder to debug than imperative code, you need to not use any public instance variables, and also avoid defining setter methods. How does this guy define imperative code? Definitely not C where all members of a (heap allocated) struct are public? He then describes the fragile base class problem without really understanding what that means. > The technical term for a programming paradigm which uses neither inheritance nor instance variables is imperative (or functional) programming. Ok, I can't stop myself from laughing at this point; I can't really go any further. You know, we all go through this as programmers. We start knowing nothing, then we get a couple of years of experience and think we know everything....then we get 10 years of experience and realize we still don't know very much and what we thought we knew were just delusions of grandeur. I won't say much about the rest of the publication. The nice thing about the internet is that anyone can produce something and make it available to read.
  • thaumaturgy 12y ago
    > a bad article written by someone who I guess must be a novice who thinks he knows something now but will look back on this 5 years later and cringe The article's author appears to be Robert Lefkowitz. If it is, then the author transitioned from nuclear physics to programming in the 1970s, has been a speaker at PyCon, currently seems to be writing software in Haskell, Ruby, and Java, gave several talks at OSCon in 2013, and is currently a CTO while also working with corporations to open proprietary code ... among other things. I won't further belabor the point, but what you just said (and how you said it) is one of my least favorite aspects of HN.
    • GFK_of_xmaspast 12y ago
      I've seen a lot of bad talks coming out of pycon.
    • deleted 12y ago
      [deleted]
      • GFK_of_xmaspast 12y ago
        I agree with you, I read that article and was giving it the stinkeye the whole time.
      • carljv 12y ago
        You don't get to be a good writer via ad hominem attacks either. Having had several interactions with the author, I'd say he has a knack for putting forth controversial theses like the one in the article. I've disagreed with lots of them--but I've always gotten smarter thinking about why I've disagreed with them (and have often been left with the suspicion that he really might be right). When I was younger I used to read things I thought were wrong and smugly dismissed them as due to some flaw on the part of the author. Luckily I've outgrown that. (Good thing too, as I no longer do embarrassing things like asserting that a multi-decade veteran of the industry must be some novice.)
        • deleted 12y ago
• sheepmullet 12y ago
  In truth tooling fixes a lot of his issues with OOP. E.g. "you will have to check the entire code base for any methods which called the setter." Sounds difficult... But it's really less than a second away as OOP IDEs have a "find references" functionality. Likewise if you want to know who is setting a bad value you just set a data breakpoint and the debugger will break when the bad value is set. More fundamentally I don't agree with his assertion that figuring out where the bug is is the most time consuming part of debugging. The most time consuming part by a very large margin is setting up the environment to properly replicate the defect, followed by retesting all surrounding code/features that could be impacted by the fix, followed by determining a fix, followed by documenting/management overhead. The average time for me to find the location of a bug in our codebase is around an hour. Yet I only fix on average a bug a day and it's not because I head to the pub after finding it :p.
• Retra 12y ago
  >This comparison is useful if one supposes that the art of programming is primarily concerned with writing programs. It isn’t, of course. It is mostly concerned with debugging programs. I don't really get this. If you can write programs that have fewer bugs because your language is expressive and prevents them, then naturally there is a lot to gain from valuing a language primarily by how it works when writing code. A language that is brief and concise gives you fewer opportunities to make mistakes: print "hello" console.out.sprintf("%1$s", "hello"); Which one is more likely to need debugging?
  • splinterofchaos 12y ago
    > A language that is brief and concise gives you fewer opportunities to make mistakes I don't think that's necessarily true. Look at brainfuck! But in all seriousness, dynamically typed languages could be categorized as "more expressive" than statically typed languages, and generally allow for cleaner interfaces, but turns static-typing compile-time errors into dynamic run-time errors. What's worse is that your tests might not cover the specific conditions that cause it. So, while you might consider C++ less expressive and concise than Python, at least you'll never try to take the square root of a string. The ease of writing bug-free code and debugging depends on a lot of factors. How well designed is the interface/API? How structured is the code? How good are the available tools? It's not what language you use, but /how/ you use it.
    • Retra 12y ago
      I'm not willing to say that dynamically typed languages are more expressive. It's hard to compare two languages and just say "A is more expressive than B." Usually they just express different things with different degrees of conciseness. (In particular, Brainfuck is not concise. It has a small grammar, but an equivalent print statement has much more room for error, since it takes a longer string of obfuscated code to produce.) My point is that the _goal_ of expressiveness is still there and still valuable. We need languages that express our intent safely, clearly, and quickly. The better this is achieved, the less debugging you have to do -- because, by definition, the code will express what you want more clearly and with less room for error. >It's not what language you use, but /how/ you use it. How you use a language is determined by the grammar of that language. So I don't see any value in your point here, save for trying to dodge specificity and feign wisdom.
• mannykannot 12y ago
  This is an interesting perspective, but I think the author has made too much of it. OO is one of several developments that have added ways to put abstraction to work, and they are all double-edged swords, providing additional ways for a confused coder to express his confusion and work around his initial misconceptions of the problem he is attempting to solve. The problem is not in the programming language features, any more than they are panaceas: the problem is in how we approach problem-solving. Guessing at the solution and then debugging it into acceptability, or 'guard-rail programming', as Rich Hickey has described it, is not the optimal approach in any language.