Why C++ Is Not “Back”

J

Jorgen Grahn

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.

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.

3. Realizing the problem you chose to go ahead (RAII-ize the stuff and
make it exitable anywhere) or back (banning the immediate troublemakers.)

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.

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.

6. repeat descending cycle from 1

7. The product starts to lose business to a newcomer (hopefully the
guys who left at 4b and 5). The newcomer can evolve faster and with
less bugs. Eventually the product dies.

Not that I ever heard "the code base sucked and talented people were
encouraged to quit" as the explanation for the failure of a company.
But I *have* seen, many times, 90% of the effort spent on stupidity,
and wondered about the useful things we could have done with that
money.

/Jorgen
 
T

Tobias Müller

Balog Pal said:
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.
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.
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.
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.
Also it potentially introduces new errors, while the existing code has
matured over years.
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.
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.
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.
6. repeat descending cycle from 1

Tobi
 
B

BGB

7. The product starts to lose business to a newcomer (hopefully the
guys who left at 4b and 5). The newcomer can evolve faster and with
less bugs. Eventually the product dies.

yeah.


smaller teams or lone programmers can often outperform larger teams or
companies, even with considerably less resources available.

part of the issue I think is that with a larger team, much more time
ends up being spent debating things, "should X be done or not done", and
having meetings, ... than actually doing work implementing it.

from the POV of an external observer, they can watch as it takes a
course of many years for features to make it into the end product.


OTOH, a lone developer can throw together their own product which does
basically those things they care about, in a considerably shorter period
of time.

on the larger scale though, decentralized development (such as
Open-Source) seems to have a different problem though:
development tends to hit a "plateau" of essentially numerous half-way
working / not-very-good products.

so, it is a lot more of a landscape of "if you want something, do it
yourself". unless a person is an active participant working to develop a
given feature, they have almost no voice in the project.


likewise, unlike with commercial products, there are relatively few
"ready-made solutions", more often, parts need to be scavenged and
forced together into something that works.

additionally, if a person wants to work using an existing codebase,
often they may need to deal with license issues, and sometimes with some
particularly awful API designs.


so, a person may be left reimplementing a lot of things themselves,
especially if a person wants to do something slightly outside of "the
norm", like "Open-Source Proprietary", rather than the more typical FOSS
or "Closed-Source Proprietary" routes.

nevermind the issue of trying to address peoples' confusion over the
notion that the source code is available, but can only be used under the
terms described in the EULA.

Not that I ever heard "the code base sucked and talented people were
encouraged to quit" as the explanation for the failure of a company.
But I *have* seen, many times, 90% of the effort spent on stupidity,
and wondered about the useful things we could have done with that
money.

yeah, pretty much.
time spent on frivolous features;
time spent on keeping everyone locked up in meetings;
....


( all this is mostly from a mix of personal observations and
experiences, and need not be taken as a statement of fact. )


I am left to suspect from observation that many of the "usual" claims
regarding programmer productivity:
codebase size (1);
project complexity (2);
specific development practices (3);
choice of programming language (4);
....

are in-fact, largely irrelevant, especially for larger projects.


1: this could be called the "smaller is better" myth. namely that if you
can write the same code in fewer LOC, that it will also mean that work
will get done faster (under the premise that programmers spend most of
their time "drowning under the complexity of tangled messes of code", or
are typing-bound, or something). this doesn't really match with personal
experience.

2: IME, it seems that the "local complexity" is much more relevant than
the total complexity of the project as a whole. like, essentially, if
the APIs are moderately well designed, it just doesn't really matter
that there may be MLOCs just behind the door. the MLOCs of code are
essentially invisible, and the main determiner of the "complexity" has
to do much more with how well the API is designed.

this assumption seems to have a lot more to do with the idea that a
programmer has to keep the whole damn codebase in memory at once, rather
than mentally loading/unloading whatever parts they are working on.


3: I just haven't seen much evidence that specific practices, especially
regarding "detail" things (like naming or formatting conventions), make
really *any* significant productivity difference.

even more general things, like OO vs non-OO, don't really make a huge
difference AFAICT.

more relevant are "general" practices, like "don't leave the program's
guts hanging out all over the place".


4: basically the same issue as 3, especially when one considers the
dominant languages in use, and observes that, in general, they aren't
really *that* much different in many areas (usually, similar things can
be done largely independent of the exact language used, and as one moves
"beyond the trivial", similar amounts of code are generally required to
accomplish similar types of tasks).

even people criticizing C largely amounts to this IMO, with them either
equating language with specific development practices (typically
old-style procedural development), or claiming that certain things (such
as OO) are "impossible", rather than just "pretty damn ugly".

the ugly syntax of function pointers, things like
"obj->vt->SomeMethod(obj, ...);", ... may not actually be a huge
difference (may sometimes be wrapped though).

I suspect even things like the presence or absence of things like
"generic container classes" may be at most a modest difference.


or, IOW, for larger projects, most smaller-scale details largely end up
evening out (and may well become largely moot points, if all the
developers are mostly left arguing about things and stuck in meetings).


or such...
 
W

woodbrian77

so, a person may be left reimplementing a lot of things themselves,

especially if a person wants to do something slightly outside of "the

norm", like "Open-Source Proprietary", rather than the more typical FOSS

or "Closed-Source Proprietary" routes.


I searched on Bing and www.duckduckgo.com for "open-source
proprietary" and didn't find a definition.

I suppose it means using a mixture of open-source and
proprietary code. That's the approach I've taken and
recommend.

Brian
Ebenezer Enterprises -- so far G-d has helped us.
http://webEbenezer.net
 
B

BGB

I searched on Bing and www.duckduckgo.com for "open-source
proprietary" and didn't find a definition.

I suppose it means using a mixture of open-source and
proprietary code. That's the approach I've taken and
recommend.


not necessarily a mix, but more like what is often called "Commercial
Open Source" or "Shared Source" (in MS terms).

in other words, publicly available source-code, but with license terms
more like those of proprietary software (say, a person is allowed to
recompile the program, and make changes for their own use, but is not
allowed to redistribute the program, and they may have to pay royalty
fees to reuse the code in their own projects, ...).


or such...
 
B

Balog Pal

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.
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.
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".
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.
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.
 
S

Saxo

With regard to the language itself, Java has always been behind compared

Well, you have to see that a lot of Java developers are fed up with earlierSun and now Oracle improving the language at a much too slow pace. Even C#from M$ is years ahead of Java. You have to see that Java is just one language running on the JVM. There are quite a few others such as Scala, Kotlin, Groovy, JRuby, Ceylon, Fantom. There are even some more exotic ones. All these languages are a result of people being bored with Java and its pace.

Looks to me that Oracle cannot get these people back anymore as they have been annoyed for too long time. You cannot leave Java completely for sake ofjob stability, but people are more and more looking for some opportunity to mix in some Scala or Groovy. The other languaes still need some time to arrive.

-- Oliver
 
B

BGB

Well, you have to see that a lot of Java developers are fed up with earlier Sun and now Oracle improving the language at a much too slow pace. Even C# from M$ is years ahead of Java. You have to see that Java is just one language running on the JVM. There are quite a few others such as Scala, Kotlin, Groovy, JRuby, Ceylon, Fantom. There are even some more exotic ones. All these languages are a result of people being bored with Java and its pace.

Looks to me that Oracle cannot get these people back anymore as they have been annoyed for too long time. You cannot leave Java completely for sake of job stability, but people are more and more looking for some opportunity to mix in some Scala or Groovy. The other languaes still need some time to arrive.

yeah...

I am aware of at least one C# compiler that can also target the JVM.
sadly, the JVM itself is in the same boat as Java (not very good, and
under a very slow development cycle).


I didn't go for Java partly because I could single-handed write a
language better suited for my uses much faster, and otherwise use
languages which "don't suck nearly as badly" for the rest of the code.


not that "not sucking" is an easy goal though, partly because, even if
it does what I want, very possibly it will still suck pretty hard as far
as everyone else is concerned...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,479
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top