3 ms·

He lists C++ and C# as his favorite languages, and I tend to agree that with these languages you can't really be x100 more productive than the average competent

by marcus 19y ago

He lists C++ and C# as his favorite languages, and I tend to agree that with these languages you can't really be x100 more productive than the average competent programmer. That kind difference is only possible in languages that are more expressive & condensed, where you spend most of your time thinking not typing.

imsteve 19y ago
I'd program in raw machine code if it meant that I could live in HI.
- eru 19y ago
  Sorry. What does 'HI' mean?
  - icky 19y ago
    Postal code for Hawaii.
Tichy 19y ago
Come on, that has to be bullshit. I sympathize with the new "power languages" hype, but it can't be that much of a factor. Even with C++, C# or Java, you spend most of the time thinking. You don't even type all that much, because of the IDE support... Actually I recently thought about the "dependency on IDE makes you miss out on cool languages argument", and you could basically just turn it on it's head: rejecting IDEs makes you miss out on a lot of cool features, too.
- marcus 19y ago
  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 cycles when you tinker with the code. Another interesting statistics that has been researched throughly is that productivity in LOC/hour is pretty much constant for programmers in all languages, which pretty much translates into higher productivity with more condensed languages. Check out these links for some real data: http://norvig.com/java-lisp.html http://norvig.com/java-lisp.html http://wwwipd.ira.uka.de/~prechelt/Biblio/jccpprtTR.pdf http://wwwipd.ira.uka.de/~prechelt/Biblio/jccpprtTR.pdf http://www.flownet.com/gat/papers/lisp-java.pdf http://www.flownet.com/gat/papers/lisp-java.pdf And this research was on a toy problem, not a real world project, on those the differences greatly intensify.
  - 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.

by marcus 19y ago

imsteve 19y ago

I'd program in raw machine code if it meant that I could live in HI.

eru 19y ago
Sorry. What does 'HI' mean?
- icky 19y ago
  Postal code for Hawaii.

Tichy 19y ago

Come on, that has to be bullshit. I sympathize with the new "power languages" hype, but it can't be that much of a factor. Even with C++, C# or Java, you spend most of the time thinking. You don't even type all that much, because of the IDE support... Actually I recently thought about the "dependency on IDE makes you miss out on cool languages argument", and you could basically just turn it on it's head: rejecting IDEs makes you miss out on a lot of cool features, too.

marcus 19y ago
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 cycles when you tinker with the code. Another interesting statistics that has been researched throughly is that productivity in LOC/hour is pretty much constant for programmers in all languages, which pretty much translates into higher productivity with more condensed languages. Check out these links for some real data: http://norvig.com/java-lisp.html http://norvig.com/java-lisp.html http://wwwipd.ira.uka.de/~prechelt/Biblio/jccpprtTR.pdf http://wwwipd.ira.uka.de/~prechelt/Biblio/jccpprtTR.pdf http://www.flownet.com/gat/papers/lisp-java.pdf http://www.flownet.com/gat/papers/lisp-java.pdf And this research was on a toy problem, not a real world project, on those the differences greatly intensify.
- 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.