4 ms·

Sigh. A good Java coder will also "get itchy" when writing two such similar functions. In fact, they'll probably already have a library that provides predicat

by jsankey 15y ago

Sigh. A good Java coder will also "get itchy" when writing two such similar functions. In fact, they'll probably already have a library that provides predicates that make the same level of abstraction trivial. Sure, the code in the predicate, being a whole class, will be a bit verbose, but that's a separate issue.

mck- 15y ago
Yes, verbosity is exactly the point. In the comments section, somebody actually wrote it.
- jsankey 15y ago
  Verbosity is not as big a deal as operating at the right level of abstraction. It's much more important to adhere to DRY than to save a few lines of typing. Verbosity can harm readability, but not much in this case (I wouldn't use an anonymous inner class, so it's just a case of passing a GreaterThanPredicate).
  - gruseom 15y ago
    Verbosity is not as big a deal Except that empirical evidence says it is a big deal: code size is the best measure of complexity we have, and error rates grow superlinearly with it. It's interesting how nearly everyone in the software profession pooh-poohs that finding. What we "know" (i.e., what we're used to) is more important to us than evidence. If we took the evidence seriously, we would work seriously to find ways to make smaller systems.
    - jsankey 15y ago
      I take your point and I may be underrating the impact of verbosity. However, I think you're not quite addressing my point, which is that violating DRY (by not using high level abstractions) is worse than verbosity. Is it verbosity that is the best measure of complexity, or is it code size? Yes verbosity leads to more code, but it's not the only thing that does. Operating at the wrong level of abstraction also will, and in a way that makes maintenance extremely difficult. Unfortunately I've not seen any evidence compares the impact of boilerplate vs duplication.
      - gruseom 15y ago
        Oh, I see. You're making a distinction between two kinds of code bloat: the kind that comes from verbose languages and the kind that comes from duplication. I don't know of any way to separate these. Look at it this way: to make small systems, we need both powerful languages and good programmers. If you don't get to choose what language to write in (as is the case on most software projects), it's still better to write less code. But how can we measure the impact of language choice? I don't think we can. You'd have to write the system twice, holding the other variables constant. But writing the system once already changes everything. I don't disagree with you about the importance of good abstractions for reducing code size. Where we might disagree a bit is on the influence of programming language on what abstractions get created. It's fashionable in the industry to downplay the importance of language (algorithms matter more, libraries matter more, programmers matter more - pretty much everything is supposed to matter more). But I think the language we're writing in influences the kind of thing we write, and thus the kind of thing we think, all the way up to how we conceptualize the problem. Maybe it isn't the strongest influence at any point, yet it's compounded over every decision made in the lifetime of the system. Once a system has passed the embryonic stage, by far the most important factor in how it develops further is how the existing parts already work. Language seems to me deeply involved in conditioning this trajectory - why the system grows this way and not another. Not every idea is equally likely in every medium. I think we see this in the fact that distinct languages give rise to such distinct programming cultures. As an aside, this is something the typical way of comparing languages -- juxtapose a known algorithm written in X to the same thing written in Y -- fails to address.
        jsankey 15y ago
        Yes, that is exactly the distinction I'm talking about. And I agree this is something that's pretty difficult to measure, probably impossible to measure precisely. I completely agree also that the language can have an impact on the abstractions you choose. Some abstractions are obvious in one language and obscure in another. I wouldn't defend Java against a better example than in the original post, it certainly has its weaknesses. But I find that most examples just show bad Java code, not that Java itself is bad, which is not enlightening and frankly becomes tiresome. On a related note, I think a lot of people underrate the influence of tools on code quality too. They might complain Java IDEs are a crutch that merely let you work around the language's weaknesses. I think they're a lot more than that -- when I start working in a seriously powerful IDE for the first time I was surprised how much it influenced my coding. Powerful automatic refactoring just makes it so trivial to do the Right Thing (give something a better name, factor out a method, etc). Beforehand I would have said that all you need is discipline to create code of the same quality without the IDE. Now I'd say even discipline and good intentions have their limits.
    - batista 15y ago
      code size is the best measure of complexity we have, and error rates grow superlinearly with it. So, Java programs must be much less buggy than CL programs, because most of the things are already available in well tested, open source libraries, used by millions, and with several version out. So, a Java programmer gets to write just the domain logic, and not also implement lots of things from scratch because they are not available. I'd take, say: 2K LOC Java Program + battled tested lib for X feature over 1K LOC CL Program + 1-2 K LOC custom CL X implementation
      - gruseom 15y ago
        By your logic we should be done writing all software soon. Most of it is already available, after all.
        batista 15y ago
        By your logic we should be done writing all software soon. Most of it is already available, after all. Not "by my logic". By an absurd interpolation of my logic to it's far out extreme. It's as if someone points out the existence of gravitational attraction, and someone says "by your logic, everything should be pressed together". The existence of a huge ecosystem of libs and APIs for major languages, and much less so, for lesser used languages, is not disputable. That people programming in languages with more available libs don't tend/need to reinvent the wheel as much as people programming in languages without, is also a basic observation. Not to mention that libraries != software.

by jsankey 15y ago

mck- 15y ago

Yes, verbosity is exactly the point. In the comments section, somebody actually wrote it.

jsankey 15y ago
Verbosity is not as big a deal as operating at the right level of abstraction. It's much more important to adhere to DRY than to save a few lines of typing. Verbosity can harm readability, but not much in this case (I wouldn't use an anonymous inner class, so it's just a case of passing a GreaterThanPredicate).
- gruseom 15y ago
  Verbosity is not as big a deal Except that empirical evidence says it is a big deal: code size is the best measure of complexity we have, and error rates grow superlinearly with it. It's interesting how nearly everyone in the software profession pooh-poohs that finding. What we "know" (i.e., what we're used to) is more important to us than evidence. If we took the evidence seriously, we would work seriously to find ways to make smaller systems.
  - jsankey 15y ago
    I take your point and I may be underrating the impact of verbosity. However, I think you're not quite addressing my point, which is that violating DRY (by not using high level abstractions) is worse than verbosity. Is it verbosity that is the best measure of complexity, or is it code size? Yes verbosity leads to more code, but it's not the only thing that does. Operating at the wrong level of abstraction also will, and in a way that makes maintenance extremely difficult. Unfortunately I've not seen any evidence compares the impact of boilerplate vs duplication.
    - gruseom 15y ago
      Oh, I see. You're making a distinction between two kinds of code bloat: the kind that comes from verbose languages and the kind that comes from duplication. I don't know of any way to separate these. Look at it this way: to make small systems, we need both powerful languages and good programmers. If you don't get to choose what language to write in (as is the case on most software projects), it's still better to write less code. But how can we measure the impact of language choice? I don't think we can. You'd have to write the system twice, holding the other variables constant. But writing the system once already changes everything. I don't disagree with you about the importance of good abstractions for reducing code size. Where we might disagree a bit is on the influence of programming language on what abstractions get created. It's fashionable in the industry to downplay the importance of language (algorithms matter more, libraries matter more, programmers matter more - pretty much everything is supposed to matter more). But I think the language we're writing in influences the kind of thing we write, and thus the kind of thing we think, all the way up to how we conceptualize the problem. Maybe it isn't the strongest influence at any point, yet it's compounded over every decision made in the lifetime of the system. Once a system has passed the embryonic stage, by far the most important factor in how it develops further is how the existing parts already work. Language seems to me deeply involved in conditioning this trajectory - why the system grows this way and not another. Not every idea is equally likely in every medium. I think we see this in the fact that distinct languages give rise to such distinct programming cultures. As an aside, this is something the typical way of comparing languages -- juxtapose a known algorithm written in X to the same thing written in Y -- fails to address.
      - jsankey 15y ago
        Yes, that is exactly the distinction I'm talking about. And I agree this is something that's pretty difficult to measure, probably impossible to measure precisely. I completely agree also that the language can have an impact on the abstractions you choose. Some abstractions are obvious in one language and obscure in another. I wouldn't defend Java against a better example than in the original post, it certainly has its weaknesses. But I find that most examples just show bad Java code, not that Java itself is bad, which is not enlightening and frankly becomes tiresome. On a related note, I think a lot of people underrate the influence of tools on code quality too. They might complain Java IDEs are a crutch that merely let you work around the language's weaknesses. I think they're a lot more than that -- when I start working in a seriously powerful IDE for the first time I was surprised how much it influenced my coding. Powerful automatic refactoring just makes it so trivial to do the Right Thing (give something a better name, factor out a method, etc). Beforehand I would have said that all you need is discipline to create code of the same quality without the IDE. Now I'd say even discipline and good intentions have their limits.
  - batista 15y ago
    code size is the best measure of complexity we have, and error rates grow superlinearly with it. So, Java programs must be much less buggy than CL programs, because most of the things are already available in well tested, open source libraries, used by millions, and with several version out. So, a Java programmer gets to write just the domain logic, and not also implement lots of things from scratch because they are not available. I'd take, say: 2K LOC Java Program + battled tested lib for X feature over 1K LOC CL Program + 1-2 K LOC custom CL X implementation
    - gruseom 15y ago
      By your logic we should be done writing all software soon. Most of it is already available, after all.
      - batista 15y ago
        By your logic we should be done writing all software soon. Most of it is already available, after all. Not "by my logic". By an absurd interpolation of my logic to it's far out extreme. It's as if someone points out the existence of gravitational attraction, and someone says "by your logic, everything should be pressed together". The existence of a huge ecosystem of libs and APIs for major languages, and much less so, for lesser used languages, is not disputable. That people programming in languages with more available libs don't tend/need to reinvent the wheel as much as people programming in languages without, is also a basic observation. Not to mention that libraries != software.