Re: Why C++ Is Not ???Back???
On 12/13/2012 9:30 PM, Tobias M??ller wrote:
Balog Pal <pasa@lib.hu> wrote:
On 12/12/2012 2:57 PM, Juha Nieminen wrote:
Rui Maciel <rui.maciel@gmail.com> wrote:
Some coding guidelines, similar to the one adopted by Google, explicitly ban
C++ features such as exceptions, templates, inheritance, and even dynamic
memory allocation.
I would show a middle finger to any coding guideline that bans the use
of templates or inheritance.
That is pretty self-reinforcing stuff.
1. You have a codebase that is C++ but mostly plain imperative C, no RAII
or such, and the usual return-code football.
While such a codebase is not a pleasure to work with, as a good programmer
you will just make the best out of the situation.
And more important, adapt your coding style such that it fits well into the
bigger picture.
Sure, it can be done, but why would a "good programmer" deliberately
chose to work with "no pleasure", adjusting for it rather than switch
for a "yes pleasure" field?
Masochists aside what is the virtue in suffering? I can deal with pain
if it looks temporary, but here we concluded it will be permanent and
increasing.
2. Someone picks up using exceptions, that work fine until get mixed with
the old code where suddenly new exit paths cause leaks and other problems.
That's stupid in the first place. Exceptions and "traditional" error
hangling are mostly incompatible, so better design your components such
that they are compatible with the rest of the code.
Not true, exceptions can be perfectly used in the implementation realm
properly caught and converted at the borders.
And it's possible to incrementally widen the realm.
I heard similar BS statements about using const -- correcting which is
way more intrusive initially -- but all evidence served it can be done
and well worth to do on any scale.
If you are new to the project you may not know the coding style yet, but if
you after a certain time you shouldn't make such errors no more.
Or you do it deliberatly to drive your coworkers to a different coding
style, which I think is a bit asocial. Such decisions should be made by the
entire team and not under pressure.
Certainly if the code is owned by the team decisions are made by the
team too. More interesting common situation is where the team is
responsible for the code (and released product) to work and be ready --
though the team is not granted power to make those "style" decisions.
But those come from distant managers who happen to not be responsible
for anything visible, and can't be bothered even with discussions about
global verdicts.
3. Realizing the problem you chose to go ahead (RAII-ize the stuff and
make it exitable anywhere) or back (banning the immediate troublemakers.)
While I agree the it would improve the code, making such changes in an
existing codebase is a huge task. And there is usually always something
more important to work on instead.
Exactly. Everyone is so dragged down in "important work" of reducing the
bug count from 1000 to 900 while 75 new entries are born, that any
effort preventing the shit from happening is starved.
All workers are engaged 11 hours each day in the debugger, so no time
remains to spend on design or reviews.
Also it potentially introduces new errors, while the existing code has
matured over years.
Translation: "our codebase is not correct but carefully balanced". What
is perfectly cool, is it is left alone as it is.
But in reality it is flooded with change requests, what breaks the
balance on everyday basis, and being matured for some old task hardly
helps.
See game "Jenga".
4a. You have bright and brave people who can manage the change. Putting
in big effort the codebase gets cleaned up and actually pleasant to work
with. That attracts more bright and brave people ... and eventually you wake up.
4b. You ban exceptions for starters and roll back the recent improvement
attempt. The codebase become even more old-style. The author of the
change quits, followed by others. Your new hires are limited to similar thinkers.
I think you overestimate that. Smart people can adapt to the situation and
if the job is interesting I don't think that will drive them away. And I'm
not sure that it's worth mourning after a language fetishist that quits
just because he cannot use exceptions.
Exceptions is just one small thing in the usual mix. But can serve as a
good indicator.
And you seem to miss the point entirely, exceptions are hardly fit as
'language fetishism'. The error handling strategy and tactics are pretty
fundamental in the sytems DESIGN plane, just like many other aspects. Or
so should be.
Banning them out of context makes me doubt there are healthy design
practices.
I'm a bit of a language fetishist too, but still manage to program without
exceptions at work. We just don't have the resources to make such a change.
Uh, my wife would probably call 'what a rationalisation' here. ;-)
Look, everyone is his own fate's master, if you have fun working and see
that your team can deliver value at proper pace and quality, hooray.
I saw a plenty of situations it was not the case. And fixing attempts
was refused, banned or just drowned. Those who didn't care about that
aspect, just that they can pick up the salary every month stayed, the
rest evaporated. Each person has a different agenda.
5. The codebase works like the usual snowball picking up more of the
same. People who could fix it see no future or fun working on it. The
ones start to have trouble with more and more features, so you start banning even more.
The reality is not just black or white. Some features are not as critical
as introducing exceptions. You may succeed convincing your coworkers and
project leaders to use some features, and fail for some other. And for some
you all agree that it would be nice to have, but it's just not important
enough or you haven't got enough resources.
My observation is that the reality IS pretty much black/white at the
bottom line. Though the cut is not by those lines. Most depends on
distribution of power and responsibility. Where those come closely tied,
The whole discussion does not apply -- people are forced to do what is
right or go down the drain. And where those are separated, you see the
described cycle.