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 62  2834 
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
On Feb 20, 8:58 am, Tim Chase <python.l...@tim.thechases.comwrote:
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
Carl Banks a écrit :
On Feb 20, 8:58 am, Tim Chase <python.l...@tim.thechases.comwrote:
>>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)
On Feb 21, 10:55 am, Bruno Desthuilliers <bruno.
42.desthuilli...@wtf.websiteburo.oops.comwrote:
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
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)
On Feb 21, 3:46 pm, "Ryan Ginstrom" <softw...@ginstrom.comwrote:
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++?
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
Bruno Desthuilliers wrote:
Carl Banks a écrit :
>On Feb 20, 8:58 am, Tim Chase <python.l...@tim.thechases.comwrote:
>>>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.
Paul Boddie wrote:
On 21 Feb, 19:22, Nicola Musatti <nicola.musa...@gmail.comwrote:
>On Feb 21, 6:31 pm, Paul Boddie <p...@boddie.org.ukwrote:
[...]
>>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#.
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
On Feb 21, 1:22 pm, Nicola Musatti <nicola.musa...@gmail.comwrote:
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
Carl Banks wrote:
On Feb 21, 1:22 pm, Nicola Musatti <nicola.musa...@gmail.comwrote:
>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.
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.
On Feb 21, 7:17 pm, Jeff Schwab <j...@schwabcenter.comwrote:
Carl Banks wrote:
On Feb 21, 1:22 pm, Nicola Musatti <nicola.musa...@gmail.comwrote:
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.
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
On Feb 21, 11:17 am, "Reedick, Andrew" <jr9...@ATT.COMwrote:
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 wrote:
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
Jeff Schwab <je**@schwabcenter.comwrites:
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
>>file('hello').read()
'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".
On Feb 22, 12:23 am, Jeff Schwab <j...@schwabcenter.comwrote:
Carl Banks wrote:
On Feb 21, 7:17 pm, Jeff Schwab <j...@schwabcenter.comwrote:
Carl Banks wrote:
On Feb 21, 1:22 pm, Nicola Musatti <nicola.musa...@gmail.comwrote:
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 resourcewithout bringing
anything of particular value to the table.s. 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?
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.
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
Nicola Musatti a écrit :
On Feb 21, 10:55 am, Bruno Desthuilliers <bruno.
42.desthuilli...@wtf.websiteburo.oops.comwrote:
>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 ?-)
Paul Boddie wrote:
On 21 Feb, 19:22, Nicola Musatti <nicola.musa...@gmail.comwrote:
[...]
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.
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.
[...]
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.
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
On Feb 22, 12:24 am, Carl Banks <pavlovevide...@gmail.comwrote:
On Feb 21, 1:22 pm, Nicola Musatti <nicola.musa...@gmail.comwrote:
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.
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
On Feb 22, 1:17 am, Jeff Schwab <j...@schwabcenter.comwrote:
[...]
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
Nicola Musatti <ni************@gmail.comwrites:
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?
Nicola Musatti <ni************@gmail.comwrites:
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.
On Feb 22, 9:03 am, Bruno Desthuilliers <bruno.
42.desthuilli...@wtf.websiteburo.oops.comwrote:
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 ;-)
Had we been speaking of productivity... but we weren't, were we?
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
On Feb 22, 12:09 pm, Paul Rubin <http://phr...@NOSPAM.invalidwrote:
Nicola Musatti <nicola.musa...@gmail.comwrites:
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.
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
Nicola Musatti a écrit :
On Feb 22, 9:03 am, Bruno Desthuilliers <bruno.
42.desthuilli...@wtf.websiteburo.oops.comwrote:
>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 ;-)
Mmm... Feel like I've been trolled !-)
>>Had we been speaking of productivity... but we weren't, were we?
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? ;-)
Brillant !-)
In article
<a8**********************************@71g2000hse.g ooglegroups.com>,
Nicola Musatti <ni************@gmail.comwrote:
Yet I'm convinced that even such partial guarantee is worth having.
Partial guarantees are like being a little bit pregnant.
In article <ma**************************************@python.o rg>,
"Reedick, Andrew" <jr****@ATT.COMwrote:
>
-----Original Message-----
From: py********************************@python.org [mailto:python-
li*************************@python.org] On Behalf Of Carl Banks
Sent: Wednesday, February 20, 2008 8:39 PM
To: py*********@python.org
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
Well, you're technically right about static typing. That could head off
some bugs... But my experience over several years has been that this has
never happened to me. That is, where I need to test every line of code
or even half of them. What usually happens is that I get an error, I
get the line and module, go there, and realize I tried to use data that
didn't fit the expression (e.g. an object without the required method).
Usually, a one-step fix. What still occasionally gets me is mutable
objects where I just use "=" to set two things (accidentally) equal to a
mutable object instead of copying. Then modify one and get and error
when the other object is used since they were the same object. I know
better, but I have a half life on this of about 4 months which means
that about twice a year this one gets me.
Looking at it the other way having done C++ development, I am w a y
more productive in Python and overall spend far less time debugging.
Just my experience. YMMV.
--
-- Lou Pecora
On Feb 22, 3:25 pm, Roy Smith <r...@panix.comwrote:
In article
<a88eef80-1b0a-4e09-ae46-9fa632bc1...@71g2000hse.googlegroups.com>,
Nicola Musatti <nicola.musa...@gmail.comwrote:
Yet I'm convinced that even such partial guarantee is worth having.
Partial guarantees are like being a little bit pregnant.
Yes, and I'm sure your tests cover all possible paths through your
code.
Cheers,
Nicola Musatti
On Feb 22, 5:13 pm, Marc 'BlackJack' Rintsch <bj_...@gmx.netwrote:
On Fri, 22 Feb 2008 04:48:28 -0800, Nicola Musatti wrote:
[...]
As you can see the standard library takes care of all memory
management.
Aaah, that's much nicer and easier to understand than the list
comprehension. After this great example I'll switch to C++. ;-)
You should. As you can see C++ is waaaaay more explicit than
Python ;-)
>
But somehow you still manage memory by writing in a style that favors
value types.
Certainly, but this is a natural C++ programming style, at least for
those that aren't too deeply rooted in their C heritage.
Cheers,
Nicola Musatti
Nicola Musatti wrote:
The real sad thing is that nobody is likely to convince Guido to turn
CPython into C++Python ;-)
How difficult would that be? Could it be done in stages? I would be
willing to spend some time on that kind of project. Since I know almost
nothing about Python internals, though, I'd appreciate it if a
C++-fluent Python expert could give an estimate in person-months. Also,
what would be the general break-down? Maybe:
(1) Prepare a build environment appropriate for Python, supporting code
in both C and C++. Include unit-test targets, and a mechanism for
module developers to add unit tests to those targets.
(2) Get all the headers C++-clean.
(3) Begin translating one module at a time. Different people could work
on different modules, and add their test-cases to the global target.
One potential problem would be linkage. Would Python-internal C++
modules still have to provide C-linkable APIs, so that they could be
invoked from other parts of Python? A breakdown of module dependencies
would help address this issue, so that it would be clear which parts of
the code-base would be directly affected by translating a given module
to C++.
At the external API level, would it still be important to support
C-style linkage, even if the implementation code isn't written in C? I
don't know whether it's realistic for people embedding Python in non-C++
applications to have to work directly with C++ APIs.
Carl Banks wrote:
On Feb 22, 12:23 am, Jeff Schwab <j...@schwabcenter.comwrote:
>Carl Banks wrote:
>>On Feb 21, 7:17 pm, Jeff Schwab <j...@schwabcenter.comwrote:
Carl Banks wrote:
On Feb 21, 1:22 pm, Nicola Musatti <nicola.musa...@gmail.comwrote:
>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 resourcewithout bringing
anything of particular value to the table.s. 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?
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.
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.
I disagree with you completely. Your points don't make any sense to me
at all. I believe I am putting forth less effort by having a generic
resource-management infrastructure, rather than a memory-specific
language feature -- that's not just an implication, it's my honest belief.
But I guess we'll agree to disagree.
On Feb 22, 2:15 pm, Jeff Schwab <j...@schwabcenter.comwrote:
Nicola Musatti wrote:
The real sad thing is that nobody is likely to convince Guido to turn
CPython into C++Python ;-)
How difficult would that be? Could it be done in stages? I would be
willing to spend some time on that kind of project.
Yeah right.. what we need is yet another implementation of Python. At
least Jython/IronPython/Pypy (and Pyrex, Cython, Shedskin, etc.) had a
better motivation than "my language is better than yours". I am sure
your time, skills and experience would be much appreciated in more
useful projects.
George
On Behalf Of Jeff Schwab
When I see this silliness again and again, it really breaks
my heart
If you allow your heart to be broken by others' opinions, you're setting
yourself up for a lot of disappointment IMHO.
I personally used C++ for about 90% of my code for 10 years. During that
time, I was chugging the C++ Kool-Aid so hard I almost peed myself. I still
think that C++ is a beautiful language, but I have also come to think that
starting a program with C++ is a premature optimization.
I think that very few Python programmers today started with Python. Most of
them came to Python for a reason.
Regards,
Ryan Ginstrom
On Feb 23, 6:40 am, Jeff Schwab <j...@schwabcenter.comwrote:
Recently, I've had a few replies in tones that imply I'm on the brink of
entering several kill-files, mostly because I express disagreement with
a few closely held beliefs of some other c.l.p posters.
A bit of advice:
Python and C++ have almost no common ground in terms of what the
priorties of the language are. So, if you're a big proponent of the
language features of C++, you really ought to expect lots of
disagreement over just about anything you opine.
P.S. I've had much sharper disagreements with some Pythonistas over
aspects of Python. None of them are in my killfile.
One of the things that's supposed to be great about Python is the user
community, and in many ways, that community is wonderful; for example,
both new and experienced users can quickly get a variety of solutions to
any given coding issue, just by asking for help.
They say that about every small language community.
In other ways, though, the Python community is just blindingly ignorant,
arrogant, and argumentative.
You're not exactly riding the humble bus there yourself, chief.
Saying things like (in so many words), "I'm just here because C++
doesn't have good runtime libraries", doesn't come off too well.
and I am starting to become
really concerned about the clarity of mind of the Python community,
because I hope to rely on it.
I think your expectations for the Python community are unreasonable.
My advice to you, if you want a good relationship with the Python
community, would be to keep the comparisons with C++ out of it as much
as possible. Understand that a lot--a lot--of people are going to say
bad things about C++ and various features that C++ implements. If you
try to defend C++ every time that happens, you won't last long here.
Carl Banks
On Feb 23, 11:39 am, Nicola Musatti <Nicola.Musa...@gmail.comwrote:
Paul Rubin wrote:
Nicola Musatti <nicola.musa...@gmail.comwrites:
> a = [f(x) + g(y) for x,y in izip(m1, m2) if h(x,y).frob() == 7]
[...]
There you replace one line of code with 40+ lines to get around the
absence of GC. Sounds bug-prone among other things.
Come on, you didn't define f, g, izip, h or frob either. It's more like
5 to one. Furthermore your code is more compact due to the existence of
list comprehensions, not because of GC. Had you written a loop the
difference would be smaller.
So here's three versions, for comparison:
a = [f(x) + g(y) for x,y in izip(m1, m2) if h(x,y).frob() == 7]
a = []
for x, y in izip(m1, m2):
if h(x, y).frob() == 7:
a.append(f(x) + g(y))
std::vector<inta;
for (std::someiterable<int,int>::iterator i = izip(m1, m2); !
i.finished(); ++i) {
if (h(i->first, i->second).frob() == 7)
a.push_back(f(i->first) + g(i->second));
}
Although the the benefits of static typing can be argued, surely you
can see the clarity tradeoffs that you make for it?
Some notes:
* izip() takes two iterables as input and returns an iterator, using
only O(1) memory at any given time. Your original version got this
wrong.
* I fudged the "!i.finished()" as I couldn't find an appropriate
official version in time for this post
* The iterator can't sanely be copied, so it probably needs to use
refcounting internally. Oops, that's GC...
* Whoever decided to keep C's i++ syntax for iterators should be shot
* x and y aren't named. They could be extracted, but it's just enough
effort that it's probably not worth it in C++.
Jeff Schwab <je**@schwabcenter.comwrote:
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.
Out of interest, what is the usual way to manage errors that the
operating system reports when it closes the file?
-M-
Matthew Woodcraft wrote:
Jeff Schwab <je**@schwabcenter.comwrote:
>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.
Out of interest, what is the usual way to manage errors that the
operating system reports when it closes the file?
By default, the fstream object just sets its "failbit," which you can
check manually by calling my_stream.fail(). If you want anything
particular to take place on failure to close a stream, you either have
to call close manually, or you need a dedicated object whose destructor
will deal with it.
Alternatively, you can tell the fstream ahead of time that you want
exceptions thrown if particular actions fail. There's a convention that
destructors don't ever throw exceptions, though, so it would be unusual
to request an exception when close() fails.
Jeff Schwab <je**@schwabcenter.comwrites:
One great thing about C is that
a programmer can realistically hope to know the entire language
definition; maybe Guido would like the same to be true of Python.
C is horrendously complicated, with zillions of obscure traps. C++ is
even worse; there's actually a published book specifically about C++
pitfalls. Python is underspecified but freer of weird hazards in
practice.
C and C++ should practically be outlawed at this point.
Jeff Schwab <je**@schwabcenter.comwrites:
So to use the Perl example: If you want to sort a list using some
arbitrary snippet of code as the comparison function, you can write:
sort { code to compare $a and $b } @elements
Yes, you can do that in Python, using a lambda expression, a named
function, or whatever.
What language do you have in mind, in which lambda is more basic than
named definitions? Are you coming from a functional language
background?
All languages that I know of with lambda, treat it as more basic than
named definitions, e.g. the Lisp family (not sure if those count as
functional languages) in addition to functional languages like Haskell.
Paul Rubin wrote:
Jeff Schwab <je**@schwabcenter.comwrites:
>So to use the Perl example: If you want to sort a list using some
arbitrary snippet of code as the comparison function, you can write:
sort { code to compare $a and $b } @elements
Yes, you can do that in Python, using a lambda expression, a named
function, or whatever.
You can indeed. I think you can also use this to do the other stuff you
would expect, e.g. return locally defined code snippets to define closures:
def mkadder(n):
return lambda x: x + n
I have gotten the impression that this was somehow inferior in Python
though, at least in terms of performance. Every time somebody uses
lambda here, they seem to get a bunch "why are you using lambda?"
responses. If I am grossly mistake, please just enlighten me.
>What language do you have in mind, in which lambda is more basic than
named definitions? Are you coming from a functional language
background?
All languages that I know of with lambda, treat it as more basic than
named definitions, e.g. the Lisp family (not sure if those count as
functional languages) in addition to functional languages like Haskell.
I note from your other posts that you seem to have a strong Lisp bent.
Lisp programmer and Smalltalk programmers stand out in the crowd. I
first noted this when somebody found a while-loop offensive, on the
grounds that recursion was somehow a more natural way to implement
looping. It can take a while to convince somebody like that they
different idioms work best in different languages.
Just some anecdotal confirmation:
In article <ma**************************************@python.o rg>,
"Ryan Ginstrom" <so******@ginstrom.comwrote:
I personally used C++ for about 90% of my code for 10 years. During that
time, I was chugging the C++ Kool-Aid so hard I almost peed myself. I still
think that C++ is a beautiful language, but I have also come to think that
starting a program with C++ is a premature optimization.
Yes, I came to the same conclusion and now start all projects in Python,
then add C/C++ extensions for optimization.
I think that very few Python programmers today started with Python. Most of
them came to Python for a reason.
Exactly right in my case. In fact this observation is directly related
to the one your the previous paragraph. Python is a good language in
which to start a progrom.
--
-- Lou Pecora
On Feb 21, 10:22 am, Nicola Musatti <nicola.musa...@gmail.comwrote:
On Feb 21, 6:31 pm, Paul Boddie <p...@boddie.org.ukwrote:
The main reason why C++ has declined in usage is because almost
everything of practical value is optional.
No, disagree.
The main reason why C++ has declined in usage is because it never got
the kind of corporate marketing enjoyed by Java and C#.
I'm inclined to disagree for two reasons. C++ is a very complex
language. Java (and the later C#) less so. Couple that with reduced
debugging time due to garbage collection and fewer pointer problems, a
lot of us decided a factor of 2x in personal productivity was worth
it. Runtime was initially an impediment, and still is for desktop
applications, but the trade was worth it.
Corporate marketing, and corporate attention in general, saw to it
that Java was well equipped with libraries and frameworks addressing
enterprise application needs. ...but the *big* reason Java won over C+
+ is because your application became stable sooner. ...with arguably
fewer problems later.
And the migration to Python is due in large part because of an
additional factor of 3-4x in personal productivity (over Java).
Improvements in runtime performance wouldn't hurt, but for many
applications that's not an issue. (If optional data typing were
offered, Python's penetration in the enterprise space would be even
higher, and I suspect there would be performance gains as well.)
Larry
Larry Bugbee wrote:
And the migration to Python is due in large part because of an
additional factor of 3-4x in personal productivity (over Java).
Improvements in runtime performance wouldn't hurt, but for many
applications that's not an issue. (If optional data typing were
You mean static data typing, right? Are there any known holes in the
dynamic type system that still need to be plugged? (I haven't heard of
any.)
offered, Python's penetration in the enterprise space would be even
higher, and I suspect there would be performance gains as well.)
You mean static data typing, right? Are there any known holes in the
dynamic type system that still need to be plugged? (I haven't heard of
any.)
My apologies. You are right, I meant optional, static typing. Thanks
for the catch Jeff.
Python's dynamic typing is just fine. But if I know the type, I want
the ability to nail it. ...local variables, arguments, return values,
etc And if I don't know or care, I'd leave it to dynamic typing.
The need for a lot of doc goes away, those new to the language that
think it's a big deal can be explicit, and as I suggested earlier, I
think the byte code interpreter could be made a lot smarter and
faster. ...and corporate acceptance would follow.
Larry
PS: And tools like ShedSkin and Pyrex benefit.
On Feb 24, 9:14 pm, Larry Bugbee <ebug...@gmail.comwrote:
On Feb 21, 10:22 am, Nicola Musatti <nicola.musa...@gmail.comwrote:
On Feb 21, 6:31 pm, Paul Boddie <p...@boddie.org.ukwrote:
The main reason why C++ has declined in usage is because almost
everything of practical value is optional.
No, disagree.
The main reason why C++ has declined in usage is because it never got
the kind of corporate marketing enjoyed by Java and C#.
I'm inclined to disagree for two reasons. C++ is a very complex
language. Java (and the later C#) less so. Couple that with reduced
debugging time due to garbage collection and fewer pointer problems, a
lot of us decided a factor of 2x in personal productivity was worth
it. Runtime was initially an impediment, and still is for desktop
applications, but the trade was worth it.
While this was probably true towards the end of the nineties, given
the standard library and Boost I find it hard to believe that a
similar increase can be accounted for just in terms of language
differences.
Corporate marketing, and corporate attention in general, saw to it
that Java was well equipped with libraries and frameworks addressing
enterprise application needs. ...but the *big* reason Java won over C+
+ is because your application became stable sooner. ...with arguably
fewer problems later.
The number of libraries you get "out of the box" appear to me as more
likely explanations for the productivity increase.
And the migration to Python is due in large part because of an
additional factor of 3-4x in personal productivity (over Java).
Improvements in runtime performance wouldn't hurt, but for many
applications that's not an issue. (If optional data typing were
offered, Python's penetration in the enterprise space would be even
higher, and I suspect there would be performance gains as well.)
This I found less hard to believe. Python is more expressive than Java
and usually requires less code for the same task. Moreover tha
availability of libraries is comparable.
Cheers,
Nicola Musatti
On Feb 25, 8:29 am, Nicola Musatti <nicola.musa...@gmail.comwrote:
On Feb 24, 9:14 pm, Larry Bugbee <ebug...@gmail.comwrote:
Corporate marketing, and corporate attention in general, saw to it
that Java was well equipped with libraries and frameworks addressing
enterprise application needs. ...but the *big* reason Java won over C+
+ is because your application became stable sooner. ...with arguably
fewer problems later.
The number of libraries you get "out of the box" appear to me as more
likely explanations for the productivity increase.
The productivity increase of the language appears to me as a more
likely explanation for the number of libraries you get "out of the
box".
:)
Carl Banks
Jeff Schwab wrote:
>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.
I disagree with you completely. Your points don't make any sense to me
at all. I believe I am putting forth less effort by having a generic
resource-management infrastructure, rather than a memory-specific
language feature -- that's not just an implication, it's my honest belief.
Yet your belief is provably wrong. It's been realised by langauge developers
long time ago.
It's quite simple.
1. Your "generic" resource-management infrastructure is not generic to begin
with! It does not work for mutually dependant resources.
2. Your "generic" infrastructure increases burden on the programmer
everywhere any resorce (including trivial one like memory) is used, while
GC kills that burden in 95% of the cases. C++ish approach puts the notion
of ownership everywhere - both in 95% of cases where it's useless and in
remaining 5% where it's actually needed. That's not reduced effort by any
means.
3. You can't handle clean-up errors in reasonable way in C++ish approach, so
anything more complex should not by handled that way anyway.
rgds
--
"Never underestimate the power of human stupidity" -- L. Lang
On Feb 25, 3:17 pm, Carl Banks <pavlovevide...@gmail.comwrote:
On Feb 25, 8:29 am, Nicola Musatti <nicola.musa...@gmail.comwrote:
On Feb 24, 9:14 pm, Larry Bugbee <ebug...@gmail.comwrote:
Corporate marketing, and corporate attention in general, saw to it
that Java was well equipped with libraries and frameworks addressing
enterprise application needs. ...but the *big* reason Java won over C+
+ is because your application became stable sooner. ...with arguably
fewer problems later.
The number of libraries you get "out of the box" appear to me as more
likely explanations for the productivity increase.
The productivity increase of the language appears to me as a more
likely explanation for the number of libraries you get "out of the
box".
In the case of Python I suspect you have a point even without the
smiley, given how much of what's available was developed without any
major corporation's support. On the other hand, had the kind of money
that's been poured into Java and/or .NET been poured into *standard* C+
+, I dont' think it would be so far behind. Witness the kind of
libraries/framework that used to and still come with some commercial C+
+ implementation, and even some free/open source ones; Boost, ACE and
wxWidgets are the first that come to mind.
Cheers,
Nicola Musatti This thread has been closed and replies have been disabled. Please start a new discussion. |
