Article of interest: Python pros/cons for the enterprise

[Paul Boddie]

On 21 Feb, 16:37, Nicola Musatti <nicola.musa... at gmail.com> wrote:
>
> While attempting to dereference a null reference is a rather common
> mistake in languages such as Java and C# - I'm not sure about Python -
> the one invaluable guarantee provided by the garbage collector is the
> absence of *invalid* references. This is one of the reasons why
> there's an ongoing effort to add garbage collection to the C++
> standard, albeit in an optional form.

The main reason why C++ has declined in usage is because almost
everything of practical value is optional. Meanwhile, those C++
newbies we were talking about are having to deal with decisions that
everyone else can quite happily ignore, knowing that the right choice
has probably already been made for them, where automatic memory
management is probably the right choice for the biggest decision of
them all, as Java demonstrated quite successfully to the hordes of
enterprise programmers (and their managers) at the end of the 1990s.

Back to those C++ newbies, then. Of course, none of them pushed into a
C++ project is going to have much say about which memory management
"best practice" is going to be used - the decisions are already set in
stone by the project - and so it's all about coping with the tedious
tracking of "who owns which pointer" and hoping that different
libraries don't have different policies. Taking the quotes out of
order...

> At least C++ programmers tend to know that memory
> must be managed, while newbies in other languages are often lead to
> believe - wrongly - that the garbage collector takes care of
> everything.

Sure, there are some issues with memory consumption patterns with
various garbage collectors, but the "it's good for you" attitude has
scant justification unless you're dealing with constrained
environments. And even with people watching the dials in their C++
application, you still get obscene resource misuse, which is why
Firefox eventually consumes over 1GB memory on this desktop. There are
considerably fewer caveats involved with regard to languages with
garbage-collected runtime environments.

I seem to remember that Hans Boehm had some interesting observations
about garbage collection myths, especially around performance, but
since the mindset persists in large tracts of the C++ development
landscape that it must somehow be cheating to use a garbage collector,
I suppose we still have a few more years of applications accessing the
wrong memory locations and showing the usual useless backtrace
dialogues for submission to uninterested developers who insisted on
using C++ because "everything else is slow".

Paul