Article of interest: Python pros/cons for the enterprise

[Jeff Schwab]

Read the title. This is about "C Traps and Pitfalls". Although it
shows its age, it's still worth reading. Unfortunately from its price
you'd think it was handwritten.

That is not a book about C++ pitfalls. That is a book about C pitfalls.
They really are two very different languages. Don't get me wrong, C++
has pitfalls of its own -- perhaps the worst of which is writing C and
thinking it's C++ in anything other than a superficial sense. But there
are vanishingly few cases that could lead to out-of-bounds indexes or
dangling pointers anymore.

 

[Jeff Schwab]

That is not a book about C++ pitfalls. That is a book about C pitfalls.

Whoops! You already pointed that out. My mistake!

As you probably know, Andrew Koenig is reportedly the individual who
first proposed argument-dependent lookup, a.k.a "Koenig" lookup, for C++.

 

[Nicola Musatti]

It looks like his main contribution was to get rid of superfluous
parentheses. Which, admittedly, is no small thing for Lisp.

Guido already did that, didn't he? ;-)

Cheers,
Nicola Musatti

 

[Steven D'Aprano]

I have found in the corporate
environment that managers frequently don't like it when you do in a few
days that things that they themselves don't know how to do in less than
several months. Especially when it makes the other programmers angry.

Easy solution to that:

Day 1 Solve problem.
Day 2 Read Slashdot, User Friendly.
Day 3 Call in sick.
Day 4 Muck about with StumbleUpon, YouTube.
....
Day 44 Post on comp.lang.python.
Day 45 Tell people you solved problem.


It's all billable time too. Since you're manager's requirement is that
you work slowly and inefficiently so as not to upset him and your fellow
coders, you would be billing for 45 days if you followed instructions
anyway.

*wink*

 

[Matthew Woodcraft]

So it's okay for a Python mechanism to deal with 95% of the cases,
but not for a C++ one? At least in C++ resource management only
becomes more complicated if you need more control.

I don't think specifying how your program will respond to errors is
something you can avoid 95% of the time, or anywhere close to that.

-M-

 

[Aahz]

I am most certainly claiming it; in fact I'm claiming that GC far more
desirable, because the cost of deterministic destruction is too high.

I'm trimming the rest of your post because I don't have time to argue
with you, but I want to point out that you're making the same mistake
that Jeff is: garbage collection and deterministic destruction are not
the only techniques for managing memory and resources. In particular,
CPython primarily relies on reference counting, which has similarities
with *both* GC and deterministic destruction.

Now you know why I said that I don't know anybody who makes Jeff's
claim. ;-)

 

[Jeff Schwab]

I'm trimming the rest of your post because I don't have time to argue
with you, but I want to point out that you're making the same mistake
that Jeff is: garbage collection and deterministic destruction are not
the only techniques for managing memory and resources. In particular,
CPython primarily relies on reference counting

That is GC. It's just not mark & sweep.

 

[Robert Brown]

That is just a dangerous hack of improving performance by turning off
some safety checks, I'd say. Static typing in the usual sense of the
phrase means that the compiler can guarantee at compile time that a
given term will have a certain type. That can be done by automatic
inference or by checking user annotations, but either way, it should
be impossible to compile code that computes improperly typed values.

Unfortunately, performance often comes at the cost of safety and
correctness. Optimized C programs can crash when pointers walk off the
end of arrays or they can yield incorrect results when integers overflow
the limits of the hardware.

Common Lisp compilers are allowed to completely ignore type
declarations, but the compiler I use, SBCL, uses a combination of
compile-time type inference and run-time checking to ensure that my
variables have the types I've declared them to have. Sometimes I see an
error message at compile time but otherwise I get an exception at run
time. It works this way because my code contains

(declaim (optimize (debug 3) (safety 3) (speed 0)))

which indicates I prefer correctness and ease of debugging to run-time
speed.

Very rarely, say inside a loop, I temporarily change my default compiler
settings. Inside the lexical scope of these declarations, the compiled
code does no run-time type checking and trusts me. Here, broken Lisp
code can crash the system (just as broken C code can), but the compiled
code runs very fast.

I trade off safety for speed, but only where necessary.

bob

 

[dave_mikesell]

Good article. Re: the comparisons with C++, most of my experience is
with C++ and I like it because it's powerful, flexible, portable, and
keeps me employable. However, I can't think of any application or
system I've written in C++ (or Java or Perl) that could not have been
written in Python.

In my hobbyist work, I've used Python quite a bit and will some more.
It's a joy to program with. Love to get a Python gig someday, but
there's just not much of a market, and with Ruby on Rails emerging as
the next Silver Bullet, I don't see one emerging soon.

No worries. C++ and Python will both enjoy long futures. Longer than
I will be employed.

 

[Paul Rubin]

Unfortunately, performance often comes at the cost of safety and
correctness. Optimized C programs can crash when pointers walk off the
end of arrays or they can yield incorrect results when integers overflow
the limits of the hardware.

Yes, even unoptimized C programs can do that. C is just plain dangerous.

[SBCL Common Lisp]
Very rarely, say inside a loop, I temporarily change my default compiler
settings. Inside the lexical scope of these declarations, the compiled
code does no run-time type checking and trusts me. Here, broken Lisp
code can crash the system (just as broken C code can), but the compiled
code runs very fast.

I trade off safety for speed, but only where necessary.

It seems to me that this trade-off results from a problem with the
language's expressivity. If you have a sound argument that the
subscripts in your loop are actually safe, you ought to be able to
express that argument to the compiler for static checking. That
should result in safe code with no runtime checks needed.

That said, trying to provide that level of expressivity is at the
cutting edge of programming language research, and in real-world
languages, for now, we have to live with some runtime checks.
But in an example like (pseudocode):

for i in 1..100:
hack(x)

it should be enough to check outside the loop in constant time that
1..100 are valid subscripts for x, then generate the loop code with
no check on each separate access. That is maybe not possible in C
because i might be aliased to something, but in a sane language it
should be possible.