The Industry choice

[Alex Martelli]

Re: The Industry choice

<beliavsky@aol. com> wrote:
...[color=blue]
> array elements. Powers and subtractions in array operations seem to be
> free in Fortran but very expensive in Python with Numeric.[/color]

Right, particularly raising to power: a good part of your observations
(not all) is accounted for by the fact that Python doesn't perform
strength reduction. Taking a trivial example (everything is slow since
I'm using a laptop in lowpower mode, but the ratio is meaningful):

kallisti:/tmp alex$ /usr/bin/python timeit.py -s'import Numeric;
xs=Numeric.ones (999); sum=Numeric.sum ' 'sum(xs*xs)'
10000 loops, best of 3: 67.2 usec per loop

kallisti:/tmp alex$ /usr/bin/python timeit.py -s'import Numeric;
xs=Numeric.ones (999); sum=Numeric.sum ' 'sum(xs**2)'
1000 loops, best of 3: 835 usec per loop


I guess this plays to the strengths of old fogeys like me -- having
grown up in a world where even good (-for-the-time) Fortran compilers
(!) often didn't do strength reduction, it just wouldn't _occur_ to me
to write x**2 where I mean x*x. ((Memo to self: point this out in the
Optimization section of the Nutshell's 2nd ed, since it IS a reasonably
frequent performance trap)). I remember once working with a good
scientist, back in the early 80's, on getting good running times for his
Fortran program coming from some (I believe) CDC machine to an IBM
mainframe, and achieving almost an order of magnitude worth of gain in
some important function by doing manual strength reduction in just a few
statements; apparently the CDC Fortran compiler _did_ do strength
reduction (I don't recall whether it was specifically x**2 -> x*x).

I believe, but I don't have one at hand to check, that scipy.weave may
be better in this regard.


Alex

[Cameron Laird]

Re: The Industry choice

In article <7x8y7ed0yn.fsf @ruckus.brouhah a.com>,
Paul Rubin <http://phr.cx@NOSPAM.i nvalid> wrote:[color=blue]
>Peter Dembinski <pdemb@illx.org > writes:[color=green]
>> If it has to be both reliable and secure, I suggest you used more
>> redundant language such as Ada 95.[/color]
>
>That's something to think about and it's come up in discussions, but
>probably complicates stuff since it's not currently available on the
>target platform. Also, the people on the project have significant
>Java and Python experience but haven't used Ada. Do you think it has
>real advantages over Java?[/color]

You have me curious, Paul; what's the platform which lacks an Ada95
compiler <URL:
http://directory.google.com/Top/Comp...Ada/Compilers/ >?

Me, I think Ada has significant advantages over Java in safety,
especially where OO is *not* a benefit (as is sometimes the case).

For a not-too-different variety of safety, I like Eiffel. Again,
Eiffel compilers are available nearly, but not entirely, everywhere.

I'm not arguing for redundancy (see above), by the way, just precision.

[Cameron Laird]

Re: The Industry choice

In article <pan.2004.12.31 .11.29.03.51733 3@chello.at>,
Christopher Koppler <klapotec@chell o.at> wrote:

[Hans Nowak]

Re: The Industry choice

Paul Rubin wrote:
[color=blue]
> You should write unit tests either way, but in Python you're relying
> on the tests to find stuff that the compiler finds for you with Java.[/color]

As I wrote on my weblog a while ago, I suspect that this effect is
largely psychological. You jump through hoops, declaring types all over
the place, checking exceptions, working around the language's
limitations, etc. So when your code compiles, it *feels* safer. Like
you're at least part of the way towards ensuring correctness. All that
work must be good for *something*, right? Never mind that when writing
unit tests for a dynamic language, you don't check for these things at
all. How often do you explicitly check types in Python unit tests?
IMHO, when using a dynamic language, you don't need most of the checks
that Java, C# and their ilk force upon you.

--
Hans Nowak

http://zephyrfalcon.org/

[Hans Nowak]

Re: The Industry choice

Christopher Koppler wrote:
[color=blue]
> --
> Christopher
>
> In theory, I'm in love with Lisp,
> but I hop into bed with Python every chance I get.[/color]

That reminds me of something my old math teacher used to say... "My wife
is my cathedral, but I pray in every chapel." :-)

--
Hans Nowak

http://zephyrfalcon.org/

[Steve Holden]

Re: The Industry choice

Cameron Laird wrote:
[color=blue]
> In article <pan.2004.12.31 .11.29.03.51733 3@chello.at>,
> Christopher Koppler <klapotec@chell o.at> wrote:
> .
> .
> .
>[color=green]
>>Manager culture is still very much mired in rituals that may in one form
>>or another go back to hunter-gatherer days (or maybe even further); that
>>'the industry choice' is more often than not something backed by a *major*
>>company is part of a ritual complex based on relations to the alpha male.
>>Small companies ingratiate themselves with their perceived betters by
>>using their products, even when technically far superior products would be
>>available. When the 'market leader' produces a new toy, everyone who wants
>>to be in his favor must use it _and_ also damn the toys available from any
>>of those competing for leadership, viz. the ongoing state of cold war
>>between Sun and MS and their respective worshipers. Toys that have not
>>been sanctioned by the leader, or that are, even worse, de facto unknown
>>to him, are met with ignorance, scorn, or even repression.
>>
>>[snip]
>>[color=darkred]
>>>For Python a Big Thing would happen if some Major Vendor
>>>embraced it as its Official Language(tm). Python language
>>>itself could turn into a smoking crock the very next day, but
>>>everybody who doesn't live under the rock would still be
>>>writing in it.[/color]
>>
>>The moral is, of course, that either the Python community's alpha geeks
>>need to get access to controlling interest in a *major* company (or to
>>become successful enough with their own companies to register on the
>>current *major* companies radar as potential competition) or as you
>>say, Python needs to be embraced like Linux was. That's the way to win the
>>hearts of software companies' managers.[/color]
>
> .
> .
> .
> I like repeating the description which emphasizes culture
> and phenotype over the rationality of business schools.
>
> Let me add a cautionary note, though: Big Companies,
> including Oracle, Software AG, IBM, Cisco, and so on, have
> adopted Tcl over and over. All of them still rely on Tcl
> for crucial products. All of them also have employees who
> sincerely wonder, "Tcl? Isn't that dead?"
>
> I offer this as a counter-example to the belief that Adop-
> tion by a heavyweight necessarily results in widespread
> acceptance.[/color]

Indeed. This is. of course, because they adopt the technology to achieve
their business goals, and couldn't make money (using their traditional
business models) by promoting the technologies they themselves rely on.

Would anyone undertake to give a "Hidden Technologies" talk at PyCon,
outlining how this phenomenon operates against the adoption of
technologies that the big boys effectively keep to themselves by keeping
quiet about? Google's use of Python , while not a closely-kept a secret
as Oracle's use of Tcl, certainly isn;t as well-known as it deserves to be.

regards
Steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237 +1 800 494 3119

[Mike Meyer]

Re: The Industry choice

claird@lairds.u s (Cameron Laird) writes:
[color=blue]
> For a not-too-different variety of safety, I like Eiffel. Again,
> Eiffel compilers are available nearly, but not entirely, everywhere.[/color]

Eiffel compilers tend to generate C code, and hence work on anything
with a C compiler. The question then becomes how do you get to the
parts of your platform that you need to get work done.

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Paul Rubin]

Re: The Industry choice

Christopher Koppler <klapotec@chell o.at> writes:[color=blue][color=green][color=darkred]
> >> 2. "plausible but there are sound technical reasons to be wary"[/color]
> >
> > A security-critical financial application.[/color]
>
> Why, specifically? Would you need to eval user input?[/color]

Static typing, checked exceptions, etc.[color=blue]
>
> I haven't used those either (well, I looked at some, but I generally
> feel better at home in Emacs or even Idle than some glitzy IDE), but
> I find Python's debugging facilities completely sufficient,
> especially since I nearly never use them ;-) The interactive
> environment and unit testing are just great for whatever I've needed
> so far. But then I haven't used Python in a really *large* project
> yet, either.[/color]

I think it's partly a matter of development style. I like debuggers
where some people prefer print statements. IDLE's debugging features
were very crude, and IDLE locked up all the time or left stray threads
around when I used it.

There's lots of times when I have a cool programming idea, and find
when I sit down at the computer that I can implement the main points
of the idea and get a neat demo running rather quickly. That creates
a very happy, liberating feeling, plus gives me something to show off
to friends or co-workers. But turning it into a finished product with
no rough edges is an order of magnitude more work. It seems to me
that IDLE and a lot of the rest of Python are examples of someone
having a cool idea and writing a demo, then releasing it with a lot of
missing components and rough edges, without realizing that it can't
reasonably be called complete without a lot more work.

[JanC]

Re: The Industry choice

Steve Holden schreef:
[color=blue]
> Would anyone undertake to give a "Hidden Technologies" talk at PyCon,
> outlining how this phenomenon operates against the adoption of
> technologies that the big boys effectively keep to themselves by
> keeping quiet about? Google's use of Python , while not a closely-kept
> a secret as Oracle's use of Tcl, certainly isn;t as well-known as it
> deserves to be.[/color]

And since 2004-10-14, Corel uses Python too... ;-)

They bought JASC Software last year, who use Python as a scripting
language in their PaintShop Pro products.


--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9

[M.E.Farmer]

Re: The Industry choice

No one pointed these out so here goes:
Python's list

http://www.python.org/Quotes.html

Disney animation

http://python.oreilly.com/news/disney_0201.html

Disney Panda3d

http://www.python.org/pycon/dc2004/papers/29/

There are several other companies using Python for game logic and
scripting, I am drawing a blank right now.

M.E.Farmer

[Cameron Laird]

Re: The Industry choice

In article <JvjBd.45$sL2.3 @fe61.usenetser ver.com>,
Hans Nowak <hans@zephyrfal con.org> wrote:[color=blue]
>Paul Rubin wrote:
>[color=green]
>> You should write unit tests either way, but in Python you're relying
>> on the tests to find stuff that the compiler finds for you with Java.[/color]
>
>As I wrote on my weblog a while ago, I suspect that this effect is
>largely psychological. You jump through hoops, declaring types all over
>the place, checking exceptions, working around the language's
>limitations, etc. So when your code compiles, it *feels* safer. Like
>you're at least part of the way towards ensuring correctness. All that
>work must be good for *something*, right? Never mind that when writing
>unit tests for a dynamic language, you don't check for these things at
>all. How often do you explicitly check types in Python unit tests?
>IMHO, when using a dynamic language, you don't need most of the checks
>that Java, C# and their ilk force upon you.[/color]

[Cameron Laird]

Re: The Industry choice

In article <1104511661.928 284.10200@z14g2 000cwz.googlegr oups.com>,
<beliavsky@aol. com> wrote:[color=blue]
>Bulba wrote:[color=green]
>>OK, so what projects and why would you consider
>>Python:
>>1. "clearly unsuitable"[/color]
>
>Large-scale scientific computing projects, such as numerical weather
>prediction, where performance is critical. Python could be used as the
>"glue" but not the "guts", where Fortran 95 and C++ are more
>appropriate. In my tests, some posted here, there has been a[/color]

[Steve Holden]

Re: The Industry choice

Paul Rubin wrote:

[...][color=blue]
> There's lots of times when I have a cool programming idea, and find
> when I sit down at the computer that I can implement the main points
> of the idea and get a neat demo running rather quickly. That creates
> a very happy, liberating feeling, plus gives me something to show off
> to friends or co-workers. But turning it into a finished product with
> no rough edges is an order of magnitude more work. It seems to me
> that IDLE and a lot of the rest of Python are examples of someone
> having a cool idea and writing a demo, then releasing it with a lot of
> missing components and rough edges, without realizing that it can't
> reasonably be called complete without a lot more work.[/color]

^Python^open source^

regards
Steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237 +1 800 494 3119

[Steve Holden]

Re: The Industry choice

Paul Rubin wrote:

[...][color=blue]
> There's lots of times when I have a cool programming idea, and find
> when I sit down at the computer that I can implement the main points
> of the idea and get a neat demo running rather quickly. That creates
> a very happy, liberating feeling, plus gives me something to show off
> to friends or co-workers. But turning it into a finished product with
> no rough edges is an order of magnitude more work. It seems to me
> that IDLE and a lot of the rest of Python are examples of someone
> having a cool idea and writing a demo, then releasing it with a lot of
> missing components and rough edges, without realizing that it can't
> reasonably be called complete without a lot more work.[/color]

^Python^open source^

regards
Steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237 +1 800 494 3119

[Steve Holden]

Re: The Industry choice

Cameron Laird wrote:
[color=blue]
> In article <1104511661.928 284.10200@z14g2 000cwz.googlegr oups.com>,
> <beliavsky@aol. com> wrote:
>[color=green]
>>Bulba wrote:
>>[color=darkred]
>>>OK, so what projects and why would you consider
>>>Python:
>>>1. "clearly unsuitable"[/color]
>>
>>Large-scale scientific computing projects, such as numerical weather
>>prediction, where performance is critical. Python could be used as the
>>"glue" but not the "guts", where Fortran 95 and C++ are more
>>appropriate . In my tests, some posted here, there has been a[/color]
>
> .
> .
> .
> I feel like growling that it's clearly a mistake for large-scale
> scientific computing projects not to leverage dynamic languages,
> at least in part. Yes, I've seen projects that would have been
> disasters if done entirely in Python. I've also seen many, many
> large-scale scientific projects that soaked up far more resources
> than they should have because they limited themselves to C++ or
> Fortran.
>
> I argue that it's a false opposition to categorize projects in
> terms of use of single languages. Many projects are MUCH better
> off with a mix of Python and Fortran, say (and probably SQL and
> JavaScript and ...), and it's pernicious to accomodate the
> managerial conceit that One Language will suffice.[/color]

Indeed it's sensible to choose language based on the nature of the task
to be performed, to avoid "language-blindness" and to build systems in
mixed languages.

Unfortunately the hierarchy of power in most modern commercial and
academic organizations is such that large-scale efforts will be
nominally run by single individuals, and since those individuals
typically can dispense favors and determine who advances within the
organization it's often unwise *not* to accommodate the managerial
conceit it career advancement is one's primary goal.

which-is-why-i-run-my-own-business-ly y'rs - steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237 +1 800 494 3119