3 ms·

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

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?).

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?).