3 ms·
After developing software professionally for 30 years, I've come to believe it largely comes down to tastes and fads. I've programmed professionally in Fortran
by JackFr 7y ago
After developing software professionally for 30 years, I've come to believe it largely comes down to tastes and fads. I've programmed professionally in Fortran, C, C++, perl, C#, Python and Scala and various SQL flavors. I've dabbled in JS and R and have no experience with Go or Rust.
You can write verbose garbage in any language and you can write clean, well factored code in any language.
The garbage I'm most familiar with is "Consultant Java" where every class has an interface, every field has a getter and setter, every method (especially the getters and setters) has Javadoc -- oh and the test coverage is 100%, thanks for asking. But you've got 450K lines of code for an app that does CRUD on 3 tables. I've seen virtually the same thing in C#, only with the added magic of the latest MS Framework. And if "boilerplate" is such a bad word, how did Ruby on Rails ever succeed. It's an environment literally built on boilerplate. And don't get me started on perl. There are perl scripts that were healthy until they kept dividing until they were cancerous "systems" throughout the enterprise. C++ pissing contests between developers intent on showing their worth by writing the most difficult code possible.
So why do have so much garbage out there?
Because programming is a human endeavor. We have tastes. We're often unwittingly subscribe to faddish beliefs. We all suffer from a host of cognitive biases that will always prevent us from seeing things clearly.
I can say with certainty that particular tools are better suited for particular jobs. At this point though, you can't pin me down as to which for which. I can say that in the past I enjoyed using C and Java and I didn't enjoy C++ and C#. I was lukewarm over Python. I currently enjoy using Scala and I think I am most productive in it. But that is more about me than the languages. Importantly though, I think they all contribute to the software industry in ways that are not always obvious.
- wefarrell 7y ago> And if "boilerplate" is such a bad word, how did Ruby on Rails ever succeed. It's an environment literally built on boilerplate This is not remotely true. "Don't Repeat Yourself" and "Convention Over Configuration" are the two core tenants of the Rails philosophy[1], both of which are intended to reduce boilerplate. This is why you don't have to specify table names, foreign key names, controller endpoint paths, view file names, etc... [1]https://edgeguides.rubyonrails.org/getting_started.html#what-is-rails-questionmark https://edgeguides.rubyonrails.org/getting_started.html#what...
- antpls 7y agoI can think of two cases, either : 1) the code had no external review, was written by one person. In this case, the solution to boilerplate is code review. or 2) if even with code review there is boilerplate, it means someone somewhere has an incentive to make the code as difficult to understand as possible (for example, to justify salaries of an entire team, or to justify more maintenances, etc)
- JackFr 7y agoIn particular I know one code base of consultant written Java where part of their contract was 100% Javadoc coverage and 100% test coverage, so you would see tests of getters and setters and Javadoc for getFoo(): "Gets the value of foo" The code worked, but 80% of it added no value.
- vincnetas 7y agoDon't blame consultants for such requirements.