Article of interest: Python pros/cons for the enterprise

[estherschindler]

This is part of a series examining the strengths and weaknesses of
various scripting languages, with particular attention to enterprise
(read: big company) use.

You Used Python to Write WHAT?
Python is a powerful, easy-to-use scripting language suitable for use
in the enterprise, although it is not right for absolutely every use.
Python expert Martin Aspeli identifies when Python is the right
choice, and when another language might be a better option.
http://www.cio.com/article/185350

 

[Tim Chase]

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

Oh noes! You might need competent programmers that actually
understand what they're doing!

(they might even have to write testing code to make sure their
code works as intended...it's a good thing that Python includes
unittest and doctest modules in the stock install)

Sigh. Any programmer that can overcome the hurdles of learning
Java or C# can quickly/easily pick up Python as long as they're
willing to unlearn some bad habits.

-tkc

 

[Carl Banks]

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

Oh noes! You might need competent programmers that actually
understand what they're doing!

(they might even have to write testing code to make sure their
code works as intended...it's a good thing that Python includes
unittest and doctest modules in the stock install)

Sigh. Any programmer that can overcome the hurdles of learning
Java or C# can quickly/easily pick up Python as long as they're
willing to unlearn some bad habits.

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.


Carl Banks

 

[TerryP]

Thanks for the link, was a nice read.

"Have specialized needs better served by other languages that you already
know. For example, if you want to do a lot of text processing and you have
a basement full of Perl programmers, there's no compelling reason to
switch."

Now that really hits the sweet spot hehe.


The threads topic reminds me of a project I had in mind not so long ago, I
wanted to write it in Ruby because I could get it done in a few hours and
move on to other work but chose not to because I could not find a way
to /100%/ secure some information that had to be both kept classified and
apart of the program for business reasons.

So obviously ANSI C and the hunt for a suitable networking library to fill
in the biggest time waster came to mind.


Then I remembered any one we wanted to *prevent* getting that information
out of the Ruby scripts could do the same with a little (easy) forensics
work if the application was done in C or C++. So choosing a language like
Ruby or Python wouldn't be much worse for the situation.


Needless to say I went back to using languages on a scale of best shoe to
fit first and the project got side-stepped by new hardware and a stop-gap
in a can.

 

[Bruno Desthuilliers]

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)

 

[Nicola Musatti]

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. 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. So, yes, your big company is
likely to be safer with newbie C++ programmers than with Python newbie
programmers.

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

Cheers,
Nicola Musatti

 

[Ryan Ginstrom]

On Behalf Of Nicola Musatti

Newbies learn, and the fundamental C++ lessons are usually
learnt quite easily. 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. So, yes, your big company is likely to be safer
with newbie C++ programmers than with Python newbie programmers.

The danger of memory leaks alone makes C++ a decidedly newbie-unfriendly
language. Java I might go along with, but C++?

Regards,
Ryan Ginstrom
(who learned C++ before Python and has grappled with his share of memory
bugs)

 

[Tim Chase]

Newbies learn, and the fundamental C++ lessons are usually

learnt quite easily.

Ah yes...that would be why Scott Meyers has written three
volumes[1] cataloging the gotchas that even experienced C++
programmers can make...

And the 1030 page Stroustrup C++ reference is easily comprehended
by the uninitiated[2]. The Python core language is a mere 97
pgs. The documentation for the *entire* standard library is
about the size of just the C++ Language Reference.[3]

Assembly language is pretty easy to learn too. But is it a
productive use of a programmer's time? Only if it's 1975.

-tkc

[1]
http://www.amazon.com/s?url=search-alias=aps&field-keywords=scott meyers

[2]
http://www.amazon.com/dp/0201700735/103-4102786-4115058

[3]
http://python.org/ftp/python/doc/2.5/pdf-letter-2.5.zip

 

[Nicola Musatti]

Please do not reply personally to newsgroup postings, thank you.

]

 

[Nicola Musatti]

The danger of memory leaks alone makes C++ a decidedly newbie-unfriendly
language. Java I might go along with, but C++?

Memory *leaks* are just as common in garbage collected languages if
not more, thanks to C++'s deterministic destruction and its standard
library, especially if complemented with smart pointers such as
Boost's shared_ptr. 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.

Dereferencing invalid pointers however is indeed a more serious
problem. This is the one lesson I had in mind when I wrote my previous
message; newbies that are not hopeless tend to learn it rather quickly
and the number of mistakes of this kind they make tends to fall in a
rather short time. I do admit however that even experienced
programmers make similar errors every now and again.

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.

Cheers,
Nicola Musatti

 

[Nicola Musatti]

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

Ah yes...that would be why Scott Meyers has written three
volumes[1] cataloging the gotchas that even experienced C++
programmers can make...

Scott Meyers's books don't just catalogue gotcha's, but suggest
effective ways to use the language. Moreover their combined word count
is probably below the "Python Cookbook"'s one.

And the 1030 page Stroustrup C++ reference is easily comprehended
by the uninitiated[2]. The Python core language is a mere 97
pgs. The documentation for the *entire* standard library is
about the size of just the C++ Language Reference.[3]

A more reasonable comparison would be against the core portion of the C
++ standard. This is still roughly three times the Python Reference
Manual. The C++ syntax is way more complex than Python's and mostly
due to its C heritage is also often inconsistent. However, despite its
apparent semplicity, Python allows extremely advanced programming
techniques. I wouldn't be surprised if the proportion of Python
programmers that are capable of exploiting the language's full power
was comparable to the corresponding proportion of C++ expert
programmers.

While I find the Python standard library documentation adequate for a
free, voluntary effort, I consider it one of the weakest spots of
Python as a professional tool. Still comparing its size against
Stroustrup's book's is really comparing apples with oranges.

Assembly language is pretty easy to learn too. But is it a
productive use of a programmer's time? Only if it's 1975.

It depends on the task at hand.

Cheers,
Nicola Musatti

 

[Steve Holden]

The danger of memory leaks alone makes C++ a decidedly newbie-unfriendly
language. Java I might go along with, but C++?

Regards,
Ryan Ginstrom
(who learned C++ before Python and has grappled with his share of memory
bugs)

I think you can safely assume that an <irony></irony> tag pair should
have surrounded Nicola's assertion.

regards
Steve

 

[Reedick, Andrew]

-----Original Message-----

From: [email protected] [mailtoython-
[email protected]] On Behalf Of Tim Chase
Sent: Wednesday, February 20, 2008 8:58 AM
To: estherschindler
Cc: (e-mail address removed)
Subject: Re: Article of interest: Python pros/cons for the enterprise


Oh noes! You might need competent programmers that actually
understand what they're doing!

(they might even have to write testing code to make sure their
code works as intended...it's a good thing that Python includes
unittest and doctest modules in the stock install)

Sigh. Any programmer that can overcome the hurdles of learning
Java or C# can quickly/easily pick up Python as long as they're
willing to unlearn some bad habits.

-----Original Message-----
From: [email protected] [mailtoython-
[email protected]] On Behalf Of Carl Banks
Sent: Wednesday, February 20, 2008 8:39 PM
To: (e-mail address removed)
Subject: Re: Article of interest: Python pros/cons for the enterprise

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.

Eh, don't laugh too hard. Since Python code isn't type-checked until
the actual code block is executed, you have to go through the extra step
of testing/running _every_ line of code before you'll find an error.
Then there's the problem of how mutable Python objects are. So even if
you execute every line of code, you might not have executed the code
with every possible type of object combination.

Compared to a statically typed language, it can get very expensive to
write comprehensive test cases for python scripts. So I wouldn't be
quick to dismiss the notion that Java/C#/C++ are more newbie-safe than
Python. =/

An amusing case in point was where I had a type-cast error in an
exception's catch block's print statement. This simple error caused the
program to stop with an unhandled exception. Something that basic would
have been caught in a statically typed language very early in the dev
cycle when it's cheaper to fix the problem. And the idea of
running/testing exceptions or simple print statements isn't always
foremost in people's minds. =P




*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625

 

[Nicola Musatti]

The danger of memory leaks alone makes C++ a decidedly newbie-unfriendly
language. Java I might go along with, but C++?

[...]
I think you can safely assume that an <irony></irony> tag pair should
have surrounded Nicola's assertion.

To an extent, certainly. As not all companies can afford to hire only
the best, you do have to cater for newbies. The way to do it, however,
is not to provide them with "sandbox" languages [1], but rather to
ensure that they acquire experience as quickly as possible and that
they aren't in a position to do more damage than expert programmers
through their inexperience. To this purpose mentoring, tests and code
inspections appear to me as more effective tools than a garbage
collector.

Still, suppose you were to choose a team of swimmers that had to be
ready for a tough task in a short time; the first time around, would
you push them into the swimming pool with or without a life jacket?
The trouble with C++ is that at times it takes you sooo long to
drown ;-)

Cheers,
Nicola Musatti

[1] I'm not thinking of any specific language, but rather to the
notion that some languages are inherently "safe".

 

[Paul Boddie]

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

 

[Jeff Schwab]

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.)

c.l.python seem to be about the most close-minded of any of the
currently popular language-specific news groups. It's just taken for
granted that Perl and C++, two of my personal favorite things in this
world, inherently favor ugly, buggy code. 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.

To use Python effectively, you have to know something about how it
works, and the same is true of Perl and C++. 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.

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.

 

[Nicola Musatti]

The main reason why C++ has declined in usage is because almost
everything of practical value is optional.

The main reason why C++ has declined in usage is because it never got
the kind of corporate marketing enjoyed by Java and C#.

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.

A choice that is available to C++ programmers too, altough I admit
it's not a common one and does usually require an external library. As
to it being the right choice it's debatable: it took Java something
like ten years to come out with usable GUI applications and, judging
from many articles and postings across the internet memory management
*is* an issue with Java, especially for long running applications.

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.
Other languages, such as Python and C#, are recognizing this fact and
provide the with/using statement, which serves this purpose but is
definitely more clumsy.

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

Sorry, but although this was probably true in the early 90's that's
not the way it goes in practice nowadays, thanks to automatic
variables, destructors, the standard library containers and smart
pointers.

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.

It's not just a matter of memory consumption patterns, it's also a
question of explicitly resetting your memory references to ensure that
the GC can reclaim them. This can be less than obvious when complex
data structures and/or callback objects are involved.

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.

Unfortunately C++ by itself cannot ensure that only top programmers
use it ;-)

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

Things change. Boehm himself is working for the inclusion of -
optional - garbage collection in the C++ standard.

Cheers,
Nicola Musatti

 

[Steve Holden]

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.)

c.l.python seem to be about the most close-minded of any of the
currently popular language-specific news groups. It's just taken for
granted that Perl and C++, two of my personal favorite things in this
world, inherently favor ugly, buggy code. 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.

I'm not sure I agree with that opinion. There is, however, a certain
amount of what we might term "defensive push back" against static
language bigots, some of whom come from the C++ camp. You are certainly
right about bad programmers producing bad programs in any language.

As far as C++ goes I usually defer to Alex Martelli, who used it a long
time at IBM and is therefore well able to address its deficiencies. I
believe you are also right in that the defensive posture tends to remain
even after the bigots go away.

For the record, there are many fine systems crafted in a mix of C++ and
Python (EVE Online being a prime example). For any sufficiently large
software system there will always be engineering problems, some of which
are conditioned by choice of language and some by other factors.

To use Python effectively, you have to know something about how it
works, and the same is true of Perl and C++. 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.

I agree that C++ is a nice language conceptually, and haven't used it
enough to hit the hard problems.

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.

Yes, Perl has always been a pragmatist's language (and indeed the
author's favored acronym has the P stand for "practical"). I *did* have
to use Perl for quite a while in the early days of the web and so got to
experience its many delights at first hand. Again, you are probably
right in saying we should accept Perl for its efficiencies (I believe
even now it will generally beat Python on regular expression processing)
and stop knocking it for its ill-though-out syntax and clumsy object
implementation.

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.

Agreed, mostly. I think Perl *is* hard to read (and frankly have been
amazed at the intentions of the Perl 6 designers), but that shouldn't
stop people using it, and isn't something that needs constant repetition.

regards
Steve

 

[Paul Boddie]

The main reason why C++ has declined in usage is because it never got
the kind of corporate marketing enjoyed by Java and C#.

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.

[...]

Sorry, but although this was probably true in the early 90's that's
not the way it goes in practice nowadays, thanks to automatic
variables, destructors, the standard library containers and smart
pointers.

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.

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.

[...]

It's not just a matter of memory consumption patterns, it's also a
question of explicitly resetting your memory references to ensure that
the GC can reclaim them. This can be less than obvious when complex
data structures and/or callback objects are involved.

As I said, the caveats are fewer, but there are caveats involved, yes.

Paul

 

[John Nagle]

No, the real problem is that C++ is the only major language to
have hiding ("abstraction") without memory safety. C has neither hiding
nor safety. Python, Java, Modula 3, Delphi, Ruby, C#, and Ada have hiding
with safety. Javascript, Perl, and LISP have safety without hiding. C++
stands alone as having hiding without safety, the least safe possibility.

The safety problems with C++ could be fixed, but the C++ committee
is off in template la-la land, ignoring safety issues in favor of
cute template features no one will use in production code.

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.)

John Nagle