4 ms·

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

• 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.