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
Feb 20 '08
62  2837 
Robert Brown <bb****@speakeasy.netwrites:
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.
This is the approach taken by Common Lisp. Often just a few type
declarations, added to code in inner loops, results in vastly faster code.
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.
Lisp and Python don't attempt to make any such compile time checks.
They check at runtime, or (in the case of Lisp with the checks turned
off) they don't check at all.
On 25 Feb, 19:44, Nicola Musatti <nicola.musa...@gmail.comwrote:
>
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.
Oh, that's another good reason for C++'s decline: the fragmentation of
the development community through a plethora of proprietary products,
each one with its advocates and a relatively small common ground
(admittedly growing over the years thanks to Free Software and
standards) between them all. When Java came along, even though the
best GUI offering was AWT, it was better than nothing and it was one
of the batteries included. Although Sun's Java was also proprietary,
it was easier for people to obtain and redistribute, often without per-
seat or per-unit licensing costs.
Of course, C++ isn't the only language with this problem. The Lisp
scene has also been plagued by an unnecessary deference to commercial
interests, which means that the hottest topic on comp.lang.lisp right
now is probably Paul Graham's much-anticipated but arguably
disappointing Lisp "successor", Arc, amongst the usual in-fighting and
parade-dampening.
Paul
On Feb 26, 12:58 pm, Paul Boddie <p...@boddie.org.ukwrote:
On 25 Feb, 19:44, Nicola Musatti <nicola.musa...@gmail.comwrote:
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.
Oh, that's another good reason for C++'s decline: the fragmentation of
the development community through a plethora of proprietary products,
each one with its advocates and a relatively small common ground
(admittedly growing over the years thanks to Free Software and
standards) between them all. When Java came along, even though the
best GUI offering was AWT, it was better than nothing and it was one
of the batteries included. Although Sun's Java was also proprietary,
it was easier for people to obtain and redistribute, often without per-
seat or per-unit licensing costs.
C++ was born and acquired its popularity in a period when freely
available software wasn't as common as it is today and corporation
didn't see any kind of advantage in investing in it.
By the way, funny you should mention AWT, given how it was soon
superceded by Swing, which in turn competes against SWT. And given the
state of the Python web framekork scene if I were you I'd start
looking for another language ;-)
Cheers,
Nicola Musatti
On Feb 25, 3:59 pm, Sebastian Kaliszewski
<s.usun...@informa.i.to.tez.plwrote:
[...]
1. Your "generic" resource-management infrastructure is not generic to begin
with! It does not work for mutually dependant resources.
How so? Could you give a concrete example?
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.
Like others around here you seem not to be aware of the existence of
the standard C++ library. That and local variables usually deal with
well over half the cases of memory management in any non trivial
application, and boost::shared_ptr can deal with a good portion of the
rest.
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.
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.
Cheers,
Nicola Musatti
On Feb 26, 6:58 am, Paul Boddie <p...@boddie.org.ukwrote:
The Lisp
scene has also been plagued by an unnecessary deference to commercial
interests, which means that the hottest topic on comp.lang.lisp right
now is probably Paul Graham's much-anticipated but arguably
disappointing Lisp "successor", Arc, amongst the usual in-fighting and
parade-dampening.
It looks like his main contribution was to get rid of superfluous
parentheses. Which, admittedly, is no small thing for Lisp.
Carl Banks
On Tue, 26 Feb 2008 05:23:11 -0800, Nicola Musatti wrote:
At least in C++ resource management only becomes more complicated if you
need more control.
I think this is the point where so many people here disagree. I'm coming
from a "garbage collection" background in OOP programming. In C++
resource management becomes instantly more complicated because I have to
think about memory management and must actively manage it in *every case*.
Writing code in a RAII style and using smart pointer templates is a cost
for me. A cost that's quite high, because it feels completely wrong to
have to think about it and to write in that "value style", because that
goes against my expectations/picture of OOP -- a graph of
independent/loosely coupled objects communicating with each other. In
this sense C++ looks like a quite crippled and fragile OOP language to me.
Ciao,
Marc 'BlackJack' Rintsch
On Feb 25, 8:29 am, Nicola Musatti <nicola.musa...@gmail.comwrote:
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 the
availability of libraries is comparable.
I tend to cheat when I code in java and pretend
I'm writing in Python. But even then the biggest
pain comes in when I try to use really advanced
data structures and get all knotted up in the verbosity
-- and when I try to figure out what I was doing later
it's even worse. For example in Python I tend to build
things like dictionaries of tuples to lists of
dictionaries without thinking about it, but in Java
the equivalent of
D[ (x,y) ] = [ { a: b } ]
is too horrible to be imagined, even if you cheat
and use the non-type-safe containers. Of course
this is in addition to other Java annoyances like
no proper support for multivalued returns or
function pointers, and overgeneralized
libraries.
However, 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.
Sometimes I think programmers should get
sociology/psychology/poli.sci degrees and pick up the
programming stuff on the job, since most of
what counts seems to be politics, really.
-- Aaron Watters
=== http://www.xfeedme.com/nucular/pydis...TEXT=spam+eggs
On Feb 26, 2:23 pm, Carl Banks <pavlovevide...@gmail.comwrote:
On Feb 26, 6:58 am, Paul Boddie <p...@boddie.org.ukwrote:
The Lisp
scene has also been plagued by an unnecessary deference to commercial
interests, which means that the hottest topic on comp.lang.lisp right
now is probably Paul Graham's much-anticipated but arguably
disappointing Lisp "successor", Arc, amongst the usual in-fighting and
parade-dampening.
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
On Tue, 26 Feb 2008 06:35:21 -0800, Aaron Watters wrote:
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*
--
Steven
Nicola Musatti <ni************@gmail.comwrote:
Sebastian Kaliszewski <s.usun...@informa.i.to.tez.plwrote:
>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.
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-
Paul Rubin <http://ph****@NOSPAM.invalidwrites:
Robert Brown <bb****@speakeasy.netwrites:
>This is the approach taken by Common Lisp. Often just a few type
declarations, added to code in inner loops, results in vastly faster code.
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
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.
Robert Brown <bb****@speakeasy.netwrites:
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[i])
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. This thread has been closed and replies have been disabled. Please start a new discussion. |
