Article of interest: Python pros/cons for the enterprise

[Carl Banks]

There are other downsides to garbage collection, as the fact that it
makes it harder to implement the Resource Acquisition Is
Initialization idiom, due to the lack of deterministic destruction.

That's not a downside: it's at least a wash.

In C++ you manage memory and the language manages resources. In
Python you manage resources and the language manages memory.

RAII is merely one way of minimizing complexity. Garbage collection
is another way.


Carl Banks

 

[Jeff Schwab]

That's not a downside: it's at least a wash.

In C++ you manage memory and the language manages resources. In
Python you manage resources and the language manages memory.

RAII is merely one way of minimizing complexity. Garbage collection
is another way.

If you've already got a generic, language-supported way to manage
resources (like RAII with deterministic destruction), then why bother
with garbage collection? I'm not trying to knock it; it was a big step
up from C-style "who forgot to delete a pointer" games. It just seems
to me like a solution to something that's no longer a problem, at least
in well-written C++ code. I'll take destructors over GC any day.

 

[Paul Rubin]

This has nothing to do with language efficiency or whether the
language is interpreted. Of the languages listed with both hiding
and safety, Ada and Modula 3 are always compiled to hard machine code,
and Java can be. (GCC offers that option.)

But Java still takes a big performance hit because of method-call
overhead, unless the compiler does whole-program optimization, if I
understand it right. This is required in order to make sure that
private instance variables are really private against access from
malicious objects running in the same JVM. That really does seem to
me to be a weird and expensive requirement to put into a general
purpose language.

 

[Carl Banks]

If you've already got a generic, language-supported way to manage
resources (like RAII with deterministic destruction), then why bother
with garbage collection?

Because now you have to manage memory? Did you read my post? You
have to manage one thing or the other.

I'm not trying to knock it; it was a big step
up from C-style "who forgot to delete a pointer" games. It just seems
to me like a solution to something that's no longer a problem, at least
in well-written C++ code. I'll take destructors over GC any day.

About 2% of the objects I creat have resources other than memory. I
would rather manage resources of 2% of objects than manage memory of
100%. YMMV, but I suspect mine is the more common opinion, if the
recent (like, 10-year) trend in programming languages is any
indication.


Carl Banks

 

[Carl Banks]

So I wouldn't be
quick to dismiss the notion that Java/C#/C++ are more newbie-safe than
Python. =/

FWIW, when I posted my comment about C++, I was mocking the article
writer's notion that it was static typing and compile-time checking
that made Java and C# "safer" for newbies, by presenting an example
that clearly defied that. I was taking it for granted the C++ is
notoriously dangerous and newbie-unfriendly.

Obviously it is not a universal opinion (yet). Too bad.

But all I was really saying is that there are far more more important
things when it comes to "safety" than dynamic typing.


Carl Banks

 

[Paul Rubin]

FWIW, when I posted my comment about C++, I was mocking the article
writer's notion that it was static typing and compile-time checking
that made Java and C# "safer" for newbies, by presenting an example
that clearly defied that. I was taking it for granted the C++ is
notoriously dangerous and newbie-unfriendly.

Well, sure, but the danger from C++ is precisely that it is untyped
(so you can dereference invalid pointers, etc). Yes, C++ has a type
system, but it leaks, so the most you can say about it is that it's
better than nothing. A better example than C++ might have been Ada,
which is in fact designed to be newbie-friendly in the sense that one
of its design criteria is that engineers who are not software
specialists (e.g. jet engine designers) are supposed to not be led
astray when reading it. I have the impression that Ada programs are
much less likely to crash than C++ programs, unless you set special
compiler flags to make them unsafe (e.g. by disabling subscript
checking).

Yes, good programmers can keep track in their heads what types their
programs are supposed to compute, so Python doesn't stop them too
much, and the dynamicness makes some things easier (e.g. deserializing
arbitrary structures). But it's the same way with assembly language.
It just seems to me that there is a killer language just around the
corner, with Python's ease-of-use but with a serious compile-time type
system, maybe some kind of cross between ML and Python.

I don't think Coq (http://coq.inria.fr) is beginner friendly
enough yet ;-).

 

[Jeff Schwab]

Because now you have to manage memory? Did you read my post? You
have to manage one thing or the other.

Yes, I read your post. You seem to be saying there's some kind of
trade-off between automatic management of dynamically allocated memory,
and automated management of other kinds of resources. I don't
understand why you believe that, so I asked.

If you have proper RAII and deterministic destruction, the management is
of resources is consistent, and mostly automated. Managing memory is
just not that difficult, especially if the vast majority of objects are
allocated on the stack or in static memory. A special language feature
for managing dynamically allocated memory robs the programmer of a
reliable way to clean up resources automatically, without bringing
anything of particular value to the table.

About 2% of the objects I creat have resources other than memory. I
would rather manage resources of 2% of objects than manage memory of
100%.

That's not how it works. If I'm going to allocated a C++ object
dynamically, I have to assign it to some kind of handle, anyway, so I
might as well just use a smart pointer that will delete the object when
there are no more references to it. There is no extra effort involved.

The most traditional, easiest way to open a file in C++ is to use an
fstream object, so the file is guaranteed to be closed when the fstream
goes out of scope. CPython offers a similar feature, since you can
create a temporary object whose reference count will become zero at the
end of the statement where it is defined:

$ echo world >hello
$ python 'world\n'

It's graceful, easy to write, and a million times better than having to
clean up the resource explicitly. A book on Python I was reading
recently (either Alex Martelli or Mark Lutz) used this idiom again and
again, and every time had to have a footnote about how it wouldn't work
right on (e.g.) JPython, because who knows if/when the resource-owning
object's finalizer will ever get called.

Admittedly, you have to know enough to use the right kinds of objects,
but that's something you have to learn anyway.

YMMV, but I suspect mine is the more common opinion, if the
recent (like, 10-year) trend in programming languages is any
indication.

I agree that support for non-deterministic GC has grown very popular
over the past ten years or so. I don't think that is evidence of it
being a good idea though; I suspect that opinion of being the product of
widespread ignorance about alternatives to unpredictable GC.

 

[George Sakkis]

It just seems to me that there is a killer language just around the
corner, with Python's ease-of-use but with a serious compile-time type
system, maybe some kind of cross between ML and Python.

Could Boo or Cobra fit the bill ? If not, what's missing at a
technical level (i.e. ignoring current maturity, community size,
marketing, etc.) ?

George

 

[Paul Rubin]

The most traditional, easiest way to open a file in C++ is to use an
fstream object, so the file is guaranteed to be closed when the
fstream goes out of scope.

Python has this too, except it's using a special type of scope
created by the "with" statement.

CPython offers a similar feature, since
you can create a temporary object whose reference count will become
zero at the end of the statement where it is defined:

$ echo world >hello
$ python
'world\n'

CPython does not guarantee that the reference count will become zero
at the end of the statement. It only happens to work that way in your
example, because the file.read operation doesn't make any new
references to the file object anywhere. Other code might well do
something different, especially in a complex multi-statement scope.
Your scheme's determinism relies on the programmer accurately keeping
track of reference counts in their head, which is precisely what
automatic resource management is supposed to avoid. If you want
reliable destruction it's better to set it up explicitly, using
"with".

 

[Paul Rubin]

Could Boo or Cobra fit the bill ? If not, what's missing at a
technical level (i.e. ignoring current maturity, community size,
marketing, etc.) ?

I just spent a minute looking at these and both are interesting,
though Cobra looks .NET specific and I'd rather have something that
makes standalone native executables. Also, I don't see support in
either of these languages for higher-order functions, iterators,
libraries with powerful static datatypes, etc. Also, no mention of
concurrency. But, as I said, I only looked for a minute.

There is something called Links that looks interesting for web
programming:

http://groups.inf.ed.ac.uk/links/

I don't know if it's still being worked on.

 

[Carl Banks]

Yes, I read your post. You seem to be saying there's some kind of
trade-off between automatic management of dynamically allocated memory,
and automated management of other kinds of resources. I don't
understand why you believe that, so I asked.

If you have proper RAII and deterministic destruction, the management is
of resources is consistent, and mostly automated.

If you have garbage collection, the management of memory is
consistent, and mostly automated.

Managing memory is
just not that difficult,

Managing resources is just not that difficult,

especially if the vast majority of objects are
allocated on the stack or in static memory.

Especially if the there are fewer resources to manage than there would
have been heap objects....

A special language feature
for managing dynamically allocated memory robs the programmer of a
reliable way to clean up resources automatically,

A special language feature more managing dynamically allocated robs
the programmer of a reliable way to free memory automatically,

without bringing
anything of particular value to the table.

without bringing
anything of particular value to the table.

It cuts both ways, chief.

You like managing your own memory, be my guest. But please don't
imply that you're putting forth less effort because of it. You're
just putting forth different effort.


Carl Banks

 

[Bruno Desthuilliers]

Nicola Musatti a écrit :

Carl Banks a écrit : [...]

C++ is a compile-time, type-checked language, which means it is
totally safer for newbies than Python. Yep, your big company is
totally safe with newbie C++ programmers.

Mouarf ! Brillant demonstration, thanks Carl !-)

(and BTW, +1 QOTW)

Newbies learn, and the fundamental C++ lessons are usually learnt
quite easily.

Which is why the most common source of nasty bugs in C++ apps - even
coded by experimented, careful and talented programmers -has to do with
dangling pointers, memory leaks, erroneous typecasts and other related
niceties... Things that are somewhat less likely to happen in Python.

Unless we're talking about idiots, that is, but in this
case at least C++ is likely to make their deficiencies evident sooner
than most other programming languages.

Here at least you have a point !-)

So, yes, your big company is
likely to be safer with newbie C++ programmers than with Python newbie
programmers.

Sorry but I don't buy your arguments.

Had we been speaking of productivity... but we weren't, were we?

Should we ?-)

 

[Bruno Desthuilliers]

Jeff Schwab a écrit :

Carl Banks a écrit :

You Used Python to Write WHAT?
http://www.cio.com/article/185350
"""
Furthermore, the power and expressivity that Python offers means
that it may require more skilled developers.
[...down to the summary...]
Python may not be an appropriate choice if you:
[...]
* Rely on teams of less-experienced programmers. These
developers may benefit from the wider availability of training
for languages like Java and are less likely to make mistakes with
a compile-time, type-checked language.
"""
(snip)

C++ is a compile-time, type-checked language, which means it is
totally safer for newbies than Python. Yep, your big company is
totally safe with newbie C++ programmers.

Mouarf ! Brillant demonstration, thanks Carl !-)

(and BTW, +1 QOTW)

NB: This is not a troll. (Please, nobody try to be cute with a "yes it
is" reply.)

NB : standard disclaimer about all the following being MVHO.

c.l.python seem to be about the most close-minded of any of the
currently popular language-specific news groups.

May I suggest you take a tour on c.l.lisp then ?-)

It's just taken for
granted that Perl and C++, two of my personal favorite things in this
world, inherently favor ugly, buggy code.

I wouldn't say so.

It's a fact that C++ is a really complex language with quite a lot of
room for BigMistakes(tm), and that there's something like a
'my-code-is-more-cryptic-than-yours' culture in Perl. You cannot
seriously argue on this.

Now this has nothing to do with the respective merits of both languages
(FWIW, Perl, as a 'Practical Extracting and Reporting Language', beats
any other language I know pants down), and I'd be sorry if you were to
confuse what is mostly on the friendly jokes side with mere bashing. You
may not have noticed, but quite a lot of people here have a working
experience with either C++ and/or Perl.

As for my above comment, it doesn't imply anything else than the fact
that C++ is way harder to learn than Python (or Ruby etc...), and that
bugs in C++ code are likely to have way more nasty results. The joke is
not "against" C++, but about people asserting than static type checking
is safer than dynamic type checking without realizing that what is
really important is*runtime type checking - something C++ doesn't provide.

NB : As a side note, and while being myself a bit passionated when it
comes to languages and my job in general, I would not go as far as
labelling any language or technology as "one of my favorite things in
this world".

That is the farthest thing
from the truth as I see it. You can (and plenty of people will) write
terrible code in any language, including Python.

Indeed. Bad coders write bad code, period. And I think we've all been
bad coders one day, and that we're all still bad coders sometimes.

To use Python effectively, you have to know something about how it
works, and the same is true of Perl and C++.

And of any other language. Now a decent C++ or Perl programmer can be
proficient in Python in a couple weeks and become a master within a year
at worst. And it seems that non-professional, occasional programmers
(hobbyists, gamers, scientists, and any other kind of power user) are
able to get their job done in Python without much pain.

But a newbie who's
learning from a decent source (avoid the "C++ for Morons" style books)
is likely (I contend) to be writing semi-useful programs about as fast
as with Python, and to be writing heavy-duty work-horse programs far
sooner.

Sorry but I don't buy this.

Perl is, and always has been, a language for getting your job done; when
everything else failed, Perl and C++ got me through some of the toughest
tasks of my life. Translating file formats, automating system-level
tasks... And now that the C++ standard library is getting regular
expressions, I can replace plenty of glued-together scripts with
single-language, cohesive applications.

I like Python, and I think it's got a brilliant future ahead of it. It
is rapidly becoming the dynamic language of choice, especially for C++
projects. I am glad that Python can be extended straightforwardly in
any C-linkable language. But this bashing of other powerful languages
on the basis that they're hard to read and hard to use correctly is,
frankly, nonsense.

Stating the obvious is not bashing. In my last shop I was working with
(very talented BTW) Perl programmer, and he was the first to make jokes
on Perl's abuse of cryptic syntax.

 

[Nicola Musatti]

What? C++ was practically the favoured language for serious
applications development on the win32 platform for a good decade. It
was all about Visual C++/Studio until Microsoft dabbled with J++, got
sued and eventually came up with C# (and Managed C++). You can't
really ask for a more influential patron than Microsoft.

You're partly right, but there are a couple of things to consider:
first, at the time the language wars hadn't started yet. As you say
when Sun came out with Java Microsoft first tried to jump on the
bandwagon on its own terms, then invented .NET. Don't forget that
Visual Studio stuck at the 6.0 release for about 5 years. Second, what
Microsoft pushed at the time was their own notion of C++, centred
around the MFC framework. People used to say that there were C++
programmers *and* Visual C++ programmers.

[...]

Yes, but support for a lot of this stuff usually lags behind the best
practices, so there are usually the tools that actually do attempt to
provide this stuff, then there are the tools which people have to use
(such as Visual Studio) and which don't work satisfactorily, although
I'll admit that the situation was improving (on the Free Software
side, at least) when I last had anything to do with C++ in a project.

Things have changed a lot in the last six years. VC++ and g++ are both
very good C++ compilers, quite close to standard compliance and both
moving to anticipate the next version of the standard itself.

Sadly, it took most of the 1990s for widespread support for several
key C++ features to become available. The joke always used to be about
templates and exceptions, but I've had pages full of bizarre errors
from libraries like Boost more recently than the 1990s. And I've seen
plenty of libraries this century which probably don't follow the best
practices, possibly because the people involved have no faith in the
language implementations.

Both VC++ and g++ support Boost quite well nowadays, with way fewer
workarounds than were required a few years ago. Note that basic things
like shared_ptr have been working well on most C++ compilers for at
least five years.

The real sad thing is that nobody is likely to convince Guido to turn
CPython into C++Python ;-)

Cheers,
Nicola Musatti

 

[Nicola Musatti]

That's not a downside: it's at least a wash.

In C++ you manage memory and the language manages resources. In
Python you manage resources and the language manages memory.

RAII is merely one way of minimizing complexity. Garbage collection
is another way.

In C++ memory is just another resource which you can handle just like
any other one, possibly using RAII. GC deals with memory very
reasonably, but makes it more complicate to deal with other resources.

Cheers,
Nicola Musatti

 

[Nicola Musatti]

If you've already got a generic, language-supported way to manage
resources (like RAII with deterministic destruction), then why bother
with garbage collection? I'm not trying to knock it; it was a big step
up from C-style "who forgot to delete a pointer" games. It just seems
to me like a solution to something that's no longer a problem, at least
in well-written C++ code. I'll take destructors over GC any day.

The real point about garbage collection is that it's about the only
way to ensure that an object of one type is never taken to be of
another type, e.g. by keeping around pointers to the object that
occupied its memory before it was reallocated. I believe that this
degree of type safety is worth having, which is why I favour the
addition of optional GC to C++.

Cheers,
Nicola Musatti

 

[Paul Rubin]

In C++ memory is just another resource which you can handle just like
any other one, possibly using RAII.

Ok, I'll bite. Here's a straightforward Python expression:

a = [f(x) + g(y) for x,y in izip(m1, m2) if h(x,y).frob() == 7]

Consider how many intermediate objects are being allocated in figuring
out that listcomp. Do you REALLY want to manage all the deallocation
with something like RAII?

 

[Paul Rubin]

The real point about garbage collection is that it's about the only
way to ensure that an object of one type is never taken to be of
another type, e.g. by keeping around pointers to the object that
occupied its memory before it was reallocated. I believe that this
degree of type safety is worth having, which is why I favour the
addition of optional GC to C++.

But in C++, garbage collection makes no such guarantee. Think of
out-of-range subscripts.

 

[Nicola Musatti]

Nicola Musatti a écrit : [...]

So, yes, your big company is
likely to be safer with newbie C++ programmers than with Python newbie
programmers.

Sorry but I don't buy your arguments.

I suspect nobody seriously does, not even in C++ newsgroups ;-)

Should we ?-)

Oh, I'm convinced that Python wins in many contexts, but I believe
that it has more to do with the number of batteries that come with the
package rather than to its being a dynamically typed language. Is this
controversial enough? ;-)

Cheers,
Nicola Musatti

 

[Nicola Musatti]

But in C++, garbage collection makes no such guarantee. Think of
out-of-range subscripts.

I'm aware that the guarantee would not be perfect. For instance
another source of problems could be holding pointers to local
variables that went out of scope. Yet I'm convinced that even such
partial guarantee is worth having.

Cheers,
Nicola Musatti