2 ms·

> The only way to get a good maintainable C++ code is to hire very mediocre programmers whose “C++” really means “Qt with some shared ptrs”. I feel like this i

by jack_h 5y ago

> The only way to get a good maintainable C++ code is to hire very mediocre programmers whose “C++” really means “Qt with some shared ptrs”. I feel like this is the most salient point in my mind. You can make an absolute mess of a code base in any language if you re-invent every wheel. I work in the embedded world and there's a definite trade-off between C and C++. C is very minimal and embedded developers are very reluctant to use any third party code so you end up with a lot of triangular and square shaped wheels so to speak. On the other hand C++ does offer a lot of nice (and appropriate to use) things that would normally be re-invented in a C codebase, however it offers almost too many things which precipitates weird, wrong, and hard to maintain abstractions. At least in my domain I feel the problem is developers just throwing code at a problem until it compiles and exhibits the expected behavior in the happy path before moving on to the next feature. This leads to the same concept being re-invented multiple times in the same code base in new and exciting ways. After all the goal is not to develop nice abstractions, it's to make a product that can be sold. I would say C++ is an amazing language for library authors who are necessarily talented and spend the time to create robust, easy to use, and well thought out abstractions that can make the life of an application developer vastly easier. Of course your mileage my vary as I'm sure the wider software world doesn't have all of the same problems that embedded has. I would just like to point out that I have seen absolutely unmaintainable, disastrous code bases in both C and C++ in my professional life and I doubt any language would have made it better.

lmilcin 5y ago
> At least in my domain I feel the problem is developers just throwing code at a problem until it compiles and exhibits the expected behavior in the happy path I specialize in joining projects with "issues", specifically to help them deliver, improve reliability, performance, etc. I have observed most projects with problems exhibit one of two "failure modes". I mean projects and not developers because projects tend to hire like developers and then developers mostly share same problematic quality. In the end it is not individual contributors who are at fault but management who allowed it to happen. #1. Insufficient programming skills. This where developers don't use libraries because they don't even know they exist, can't recognize the problem they are solving as generic. This is where they can't structure the code because they haven't seen much code at all and/or are not interested in learning. You can recognize this immediately as codebases with a lot of code duplication and very weak structure/abstractions. #2. Too much programming ambition. This is where developers think so highly of themselves that they can't accept existing off the shelf components and will reinvent them because they can do better. They will write new everything because it will offer 10% performance increase in their specific case or just for the intelectual fun of doing it. They will obsess over ensuring there is no duplication of code at the cost of creating baroque structures that have no meaning and purpose other than ensure that every single component works in every single case supported by the application and in any possible future. You can recognize this as codebases with no duplication but when you try to read the code it seems the structure is so complicated you need to have a huge map on entire wall and a guide to be able to travel the codebase. Most of the objects don't have any meaning in the domain of the problem and are just abstract "stuff" necessary to glue everything together. I very much prefer working with case #1 The reason is that, as dumb as the code is, you can read it and understand what the author probably had in mind, what the application attempts to do. You can then work with the code, refactor functionality out, and so on. In my experience case #2 is usually beyond repair (or at least beyond my abilities to repair). These developers become easily hostile -- because they think very highly of themselves they treat everybody as inferior and now I am trying to write some dumb unsophisticated code and so I must be dumb. They also tend to change jobs pretty easily so the only result of trying to fix that kind of project is people suddenly leaving it and management getting restless at the lack of progress. And for some reason every single C++ team I worked with falls under case #2. I think because, given so many options, you need to have ambition to willingly choose C++ as your main programming language and so the population is preselected. Don't get me wrong, these are all highly intelligent people. But you can be very intelligent and still make a mess. I know because I was doing the same until I have acquired some wisdom based on my own mistakes and mistakes I have observed.

by jack_h 5y ago

lmilcin 5y ago

> At least in my domain I feel the problem is developers just throwing code at a problem until it compiles and exhibits the expected behavior in the happy path I specialize in joining projects with "issues", specifically to help them deliver, improve reliability, performance, etc. I have observed most projects with problems exhibit one of two "failure modes". I mean projects and not developers because projects tend to hire like developers and then developers mostly share same problematic quality. In the end it is not individual contributors who are at fault but management who allowed it to happen. #1. Insufficient programming skills. This where developers don't use libraries because they don't even know they exist, can't recognize the problem they are solving as generic. This is where they can't structure the code because they haven't seen much code at all and/or are not interested in learning. You can recognize this immediately as codebases with a lot of code duplication and very weak structure/abstractions. #2. Too much programming ambition. This is where developers think so highly of themselves that they can't accept existing off the shelf components and will reinvent them because they can do better. They will write new everything because it will offer 10% performance increase in their specific case or just for the intelectual fun of doing it. They will obsess over ensuring there is no duplication of code at the cost of creating baroque structures that have no meaning and purpose other than ensure that every single component works in every single case supported by the application and in any possible future. You can recognize this as codebases with no duplication but when you try to read the code it seems the structure is so complicated you need to have a huge map on entire wall and a guide to be able to travel the codebase. Most of the objects don't have any meaning in the domain of the problem and are just abstract "stuff" necessary to glue everything together. I very much prefer working with case #1 The reason is that, as dumb as the code is, you can read it and understand what the author probably had in mind, what the application attempts to do. You can then work with the code, refactor functionality out, and so on. In my experience case #2 is usually beyond repair (or at least beyond my abilities to repair). These developers become easily hostile -- because they think very highly of themselves they treat everybody as inferior and now I am trying to write some dumb unsophisticated code and so I must be dumb. They also tend to change jobs pretty easily so the only result of trying to fix that kind of project is people suddenly leaving it and management getting restless at the lack of progress. And for some reason every single C++ team I worked with falls under case #2. I think because, given so many options, you need to have ambition to willingly choose C++ as your main programming language and so the population is preselected. Don't get me wrong, these are all highly intelligent people. But you can be very intelligent and still make a mess. I know because I was doing the same until I have acquired some wisdom based on my own mistakes and mistakes I have observed.