5 ms·

So on an every decent sized project in one of those languages most of the code is boilerplate code you didn't even write but which wastes your time and brain cy

• Tichy 19y ago
  Well, most of the code isn't boilerplate code. the LOC/hour statistic would interest me, is there a reference? Also, the condensed style of scripting languages might waste more brain cycles than more verbose code when trying to understand it? I enjoy the condensed style and clever things you can do with it. But clever things have a tendency to also require cleverness when trying to understand what they do.
  • marcus 19y ago
    On some regular expressions I tend to agree that there is such a thing as too condensed, but mostly I am a minimalist. The reference was somewhere in the PDFs I linked to, and its not that far from the truth from my experience.
  • LogicHoleFlaw 19y ago
    I had a discussion on this topic last night at the St. Louis Ruby Users Group. The consensus we came to was that code is not an asset; it is a liability. Features are assets. The fewer lines of code you have to write, test, and maintain, the fewer bugs you will have, and the less effort you need to expend on things like refactoring and maintenance. Boilerplate is a sickness. Even if your IDE is generating it for you, you still have to read, interface, and interact with it in your daily operations. Any higher level abstraction which allows you to remove boilerplate and redundancy leads to greater robustness and flexibility in your software. I'm not saying that playing golf with your code and turning it into line noise is a solution. That merely results in higher level of complexity rather than a higher level of abstraction. It becomes brittle. But when you can apply more powerful concepts to the solution of a problem, fundamentally complex operations can be expressed in a simple manner. New abstractions definitely have a learning curve. I believe that this is a separate effect from mere cleverness or an obfuscating complexity. The advantage of this learning curve is that once the concepts are understood, future effort is eased and the new principles become natural expressions of solutions. A professor of mine once told me that Mathematics is driven by the creation of new, more powerful notations. Being able to describe an idea in a more succinct way leads to the ability to reason about a problem space and discover the underlying fundamental principles of its operation. It may well be the case that it takes a more dedicated, talented, or skillful person to write code at higher levels of abstraction. The innate curiosity and insight needed to pursue the greater goals of software excellence can be distressingly uncommon. I believe that the balance of the issue is offset by the force-multiplying effect of powerful languages, designs, and abstractions as well as the social effects of being able to accomplish more with fewer people. Reducing the social and management overhead of a project results in greater individual productivity, improved group cohesion, and more effective communication. Any approach which can eliminate the extraneous details from the expression of the solution to a problem and which allows us to work with the raw core of its nature enables us as computer scientists and software engineers to deliver more robust, effective, and elegant software solutions. And you might even find yourself to be happier while doing it.
    • Tichy 19y ago
      Don't get me wrong, I am also curious about the "new" wave of programming languages. But Perl was also dynamic and very brief, and I remember being VERY glad to switch from Perl to Java. Suddenly code worked the way I thought it would work, not some other weird way. That memory sticks with me, and therefore I take the dynamic typing hype with a grain of salt. Maybe the "Boilerplate" aspect of Java is a bit overblown. There are interfaces, but I think they are a necessity because of static typing (how do Scala and Haskell deal with it?). So it is really the pros and cons of static and dynamic typing that are to be discussed. There are boilerplate things like the awful EJB stubs, but everybody hated them from the beginning, and I for one managed to avoid using them for all those years. They are not Java, just something stupid somebody implemented with Java. You could also create a horrible framework with lots of boilerplate code for Ruby, after all. What else? OK, the new generics are too verbose, I hate them, too. And then there are the curly braces and mandatory brackets for function calls, but I think that can't be what everybody hates (Ruby is more verbose with do end instead of brackets, isn't it?).
  • Xichekolas 19y ago
    It's not about fewer lines, it's about fewer layers. If you can abstract out portions of the code with your more powerful language, you can test it independently and know it works, then build on it. The fewer layers you have to hold in your head, the easier the code is to modify and maintain. Really productive programmers win by writing themselves APIs as they go. These can be reused in the future (hence the productivity multiple grows over time). As PG and others have said multiple times, you can be way more productive if you design a language for the problem domain, then use that language to solve the problem. That is what more powerful languages allow you to do. It's not so much about trying to condense lines of code, it's about how many things you have to focus on at once (the fewer things you need to pay attention to, the easier it is to work with). Since any modern language handles all the minutiae of disk access for me, I can read and write to files with one or two lines. I don't have to care how it's done. If you think I'm just stating the obvious, I rewrote a project in my last job in about three weeks that took the original team of four people two months to implement. The only thing that allowed me to achieve that kind of speedup was that I used an existing SOAP library (this was a web app with a web service back end for the data) instead of all the kludgy custom XML parsing they were doing. They had different code on each page of the web app for handling the webservice calls. It may sound retarded (because it is), but I have seen that kind of situation a hundred times, so I have to believe that that is the kind of code the average programmer churns out. I don't claim to be a rockstar either. I know I've written a ton of horrendous, kludgy, redundant crap in my lifetime too. I think it just happens when you don't have a clear idea of what the end product will be, and don't take the time to refactor as you go.
    • Tichy 19y ago
      Don't abstractions usually induce more layers, not fewer layers?
      • Xichekolas 19y ago
        But fewer layers you have to pay attention to... you don't have to think about lower layers, you treat them as if they work, and build from there.