The Industry choice

Premshree Pillai wrote:

On 30 Dec 2004 08:58:36 -0800, Sridhar R <sr*************@gmail.com> wrote:
From technical point of view, I could not understand the the reasoning

behind using Java in major companies. Sure that Python, is used in
some, but still Java is considered as a sure-job language.

It certainly is not because Python is bad or something. Organizations
typically take lot of time to change -- be it technology or office
furniture.

We either need time for folks to accept dynamic, "scripting"
languages, or a lot of "modern" language programmers need to gang up
against managers and stuff. :)

[...]
Right, what have the managers ever done for us?

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

Jul 18 '05 #4

Sridhar R <sr*************@gmail.com> wrote:
...

What makes such companies to choose Java over dynamic, productive
languages like Python? Are there any viable, technical reasons for
that?

Viable AND technical: nah.

Viable (forget the technical): yeah. Managers' dreams are about
replacing costly, quirky individual human=being programmers with
die-cast, factory-made replaceable parts. Java sort of promises that
(doesn't _deliver_, but, that's another issue;-).
Alex

Jul 18 '05 #5

It's me

"Premshree Pillai" <pr**************@gmail.com> wrote in message
news:ma**************************************@pyth on.org...

It certainly is not because Python is bad or something. Organizations
typically take lot of time to change -- be it technology or office
furniture.

In our industry, the code for the bread and butter tool hasn't really change
in over 40 years!

Jul 18 '05 #6

Aahz

In article <11*********************@z14g2000cwz.googlegroups. com>,
Sridhar R <sr*************@gmail.com> wrote:

What makes such companies to choose Java over dynamic, productive
languages like Python? Are there any viable, technical reasons for
that?

It's a decent cross-platform way of delivering libraries compared to C
libraries. We've been forced into Java because fewer and fewer credit
card processing libraries are available as C libraries. Just yesterday,
I ran into some annoyance because the PGP library I'm using doesn't allow
recombining their .jar files due to signing. Which has some good and bad
features, I suppose.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"19. A language that doesn't affect the way you think about programming,
is not worth knowing." --Alan Perlis

Jul 18 '05 #7

Bulba!

On 30 Dec 2004 08:58:36 -0800, "Sridhar R"
<sr*************@gmail.com> wrote:

From technical point of view, I could not understand the the reasoningbehind using Java in major companies. Sure that Python, is used in
some, but still Java is considered as a sure-job language.

After being a python programmer for long time, I consider it painful to
learn/use Java now (well, like many I will be forced to do that in my
job).

What makes such companies to choose Java over dynamic, productive
languages like Python? Are there any viable, technical reasons for
that?

It's the $$$ of the big organization behind it and all the
inertia^H^H^H^H^H^H stability of it.

Note all the fuss that was made when IBM has "spent $1
billion on Linux", for instance (or so it was said). Managers
paid attention to that (at least that was my impression).

AFAIK, Linux didn't really change in technical sense
just because IBM has embraced Linux, or at least not much.
But to companies and manager the major point is:

Big Blue has embraced it.

That means Linux going to stay around (at least in their
opinion) and it will have the backing of Major Vendor,
because Major Vendor can't afford to drop it (or so their
thinking goes; I'm sure there could be precedents showing
smth to the contrary, esp. when mergers/takeovers were
involved - off the top of my head, Informix is a case in
point).

Us techies can find it relatively easy to switch from one
technology to another, but even then it costs us considrable
effort.

For managers of companies it's worse: the company makes
VERY substantial investments into any technology it "marries",
and that means big losses if it goes. Long-term stability
of this technology in terms of "we're not going to be left out
in cold alone with this technology to feed it" means a lot
to them. Even a poor technology with external backing
of big, stable vendor is better than the excellent technology
without it. That's the downside of Adam Smith's division of
labor: it's very nice that it makes you so much more productive
-- the problem is that it also makes you automatically dependent
on other people, who tomorrow might feel like finding a more
interesting open source project, or joining a Tybetan
monastery, for instance, is better use of their lives.

Why managers actually ain't stupid in doing things like
embracing Java a following anecdote may illustrate nicely:

A friend of mine, after whom I got the sysadmin job, got a
job in CERN in Geneva. Once upon a time they needed to
get those industrial controllers used in physical experiments
programmed in a peculiar way. Since at the time there was
no available language or toolkit suitable for the purpose that
would fit what physicists needed to achieve, they hired this
guy to write a small programming language for them.

I don't know the actual details, but the guy got the job done.

Since that time the controllers with appropriate performance
and features have appeared on the market. However, now
the managers cannot fire or reassign this guy, because there
are two problems:

1. nobody except him has the faintest idea how he has done that.

2. the software of those controllers obviously got "interfaced"
with the remaining software (and as we know, applications
live forever) and the quirks of that software obviously externalized
themselves elsewhere in the remaining software, so adapting the
apps to new controllers would cost more effort than it is
worth - basically rediscovering what the hell was done down there
in all the source code would be necessary (almost reverse
engineering), much of the debugging would have to be done again,
maintenance, etc. - all those efforts quickly add up.

So the "known evil" is kept in place because it is too costly to
switch to realize a relatively small benefit.

So that guy is kept in his job "just in case" - doing basically
nothing on the job.

Think about it: he's paid for DOING NOTHING, well, basically
just for being ready to make minor patches or ports of
his software (this is a case of "vendor lock-in" if there ever
was one).

This is the sort of situation that managers are rationally
afraid of.

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.

--
It's a man's life in a Python Programming Association.

Jul 18 '05 #8

Bulba!

On Thu, 30 Dec 2004 12:59:57 -0500, Steve Holden <st***@holdenweb.com>
wrote:

We either need time for folks to accept dynamic, "scripting"
languages, or a lot of "modern" language programmers need to gang up
against managers and stuff. :)
[...]
Right, what have the managers ever done for us?

Shoot the damn kulaks, I say. They ain't gonna stand
in the way of progress. ;o)

--
It's a man's life in a Python Programming Association.

Jul 18 '05 #9

Alan Gauld

On 30 Dec 2004 08:58:36 -0800, "Sridhar R"
<sr*************@gmail.com> wrote:

What makes such companies to choose Java over dynamic, productive
languages like Python? Are there any viable, technical reasons for
that?

Decisions are made by men in suits who read very expensive
business magazines, read "technical reports" by the like of
Gartner and Forester and get taken on expenses-paid trips by
company sales reps. My boss has never had his lunch paid
for by a man selling Python...

Think about the PHB in Dilbert, if some guy in a sharp suit from
a big supplier says use Java, while Dilbert and the others say
Python what will he pick?

There are some valid technical reasons to do with performance and
security too, but frankly, they come a long way down the list...

Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld

Jul 18 '05 #10

"Sridhar R" <sr*************@gmail.com> writes:

What makes such companies to choose Java over dynamic, productive
languages like Python? Are there any viable, technical reasons for that?

I think you have to be more careful when you program in Python. Java
is statically typed and can do all kinds of compile time checks that
catch errors which can crash your Python program after it's running.
The cure in Python involves very thorough testing, and it often means
more test-debug-edit cycles than you'd need with static typing. It's
also possible to miss stuff--not just type errors, but uncaught
exceptions, errors due to misspelled variable names (Python lacks
declarations), and so forth. Some Pythonistas respond with a blurb
about test-driven development, but really, the idea of programming in
HLL's instead of assembler is that the language is supposed to take
care of stuff so that you don't have to. Java code is larger and
takes longer to write, but has a higher chance of working properly
once it compiles and passes basic tests. (Of course you still have to
test it thoroughly, but you'll tend to hit fewer errors once you've
passed the initial and somewhat high hurdle of getting the code to
work at all).

Basically, highly-skilled programmers can be very productive with
Python, maybe more productive than they can be with Java.
Medium-skilled programmers, which is what the industry is full of, can
mess up very badly with a language like Python. With Java, it's
harder to mess up too badly.

I'm involved in a development project for something that's security
critical and has to be reliable. The implementation language hasn't
been chosen yet. Python and Java are both possibilities. I'm fine
with the idea of using Python for demos and prototypes. For the
production system I think we may be better off using Java.
Reliability of the final product is more important than rapid
implementation.

Jul 18 '05 #11

Bulba!

On Thu, 30 Dec 2004 12:59:57 -0500, Steve Holden <st***@holdenweb.com>
wrote:

We either need time for folks to accept dynamic, "scripting"
languages, or a lot of "modern" language programmers need to gang up
against managers and stuff. :)
[...]
Right, what have the managers ever done for us?

I must have been slow last night (my usual state), so I
didn't catch your joke.

Respectfully, I have to disagree: Terrific race, managers.
Terrific. ;-)

--
It's a man's life in a Python Programming Association.

Jul 18 '05 #12

Peter Dembinski

"Thomas Bartkus" <to*@dtsam.com> writes:

[...]

What makes such companies to choose Java over dynamic, productive
languages like Python? Are there any viable, technical reasons
for that?

Are there "viable, technical reasons"? That would be doubtful.

But

There is a reason very important to major companies. When you leave
that company, there will be a *long* line of Java programmers
waiting to take your place.

IMO learning Python is a matter of few days for Java programmer.

Jul 18 '05 #13

On Fri, 31 Dec 2004 02:13:27 +0100, Bulba! wrote:

On 30 Dec 2004 08:58:36 -0800, "Sridhar R"
<sr*************@gmail.com> wrote:
[snip]
What makes such companies to choose Java over dynamic, productive
languages like Python? Are there any viable, technical reasons for
that?
It's the $$$ of the big organization behind it and all the
inertia^H^H^H^H^H^H stability of it.

Note all the fuss that was made when IBM has "spent $1
billion on Linux", for instance (or so it was said). Managers
paid attention to that (at least that was my impression).

AFAIK, Linux didn't really change in technical sense
just because IBM has embraced Linux, or at least not much.
But to companies and manager the major point is:

Big Blue has embraced it.

[add a few grains of salt to the following...]
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] 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.

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.

--
Christopher

Jul 18 '05 #14

On Fri, 31 Dec 2004 12:05:47 +0100, Peter Dembinski wrote:

"Thomas Bartkus" <to*@dtsam.com> writes:

[...]
> What makes such companies to choose Java over dynamic, productive
> languages like Python? Are there any viable, technical reasons
> for that?

Are there "viable, technical reasons"? That would be doubtful.

But

There is a reason very important to major companies. When you leave
that company, there will be a *long* line of Java programmers
waiting to take your place.

IMO learning Python is a matter of few days for Java programmer.

True, but learning to *think* in Python takes a while longer. That static
straitjacket takes some time to loosen...

--
Christopher

Jul 18 '05 #15

Christopher Koppler <kl******@chello.at> writes:

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.

It's not just a matter of attitude or politics. Python is an
excellent choice for many projects. For some other projects, it's
clearly unsuitable. For yet other projects, it's a plausible choice
but there are sound technical reasons to be wary of it.

Jul 18 '05 #16

On Fri, 31 Dec 2004 03:49:44 -0800, Paul Rubin wrote:

Christopher Koppler <kl******@chello.at> writes:
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.

It's not just a matter of attitude or politics. Python is an
excellent choice for many projects. For some other projects, it's
clearly unsuitable. For yet other projects, it's a plausible choice
but there are sound technical reasons to be wary of it.

IMO (and - indubitably limited - experience) in the many cases where it
*would* be an excellent choice, it *is* most often a matter of politics,
to have a project use, say C# or Java instead of Python (or Lisp for that
matter) as the main development language.

--
Christopher

Jul 18 '05 #17

Christopher Koppler <kl******@chello.at> writes:

IMO (and - indubitably limited - experience) in the many cases where it
*would* be an excellent choice, it *is* most often a matter of politics,
to have a project use, say C# or Java instead of Python (or Lisp for that
matter) as the main development language.

I don't know that C# is really that much different from Python. I
haven't used it but I have the impression that it's sort of similar
under the skin.

Jul 18 '05 #18

On Fri, 31 Dec 2004 04:03:53 -0800, Paul Rubin wrote:

Christopher Koppler <kl******@chello.at> writes:
IMO (and - indubitably limited - experience) in the many cases where it
*would* be an excellent choice, it *is* most often a matter of politics,
to have a project use, say C# or Java instead of Python (or Lisp for that
matter) as the main development language.

I don't know that C# is really that much different from Python. I
haven't used it but I have the impression that it's sort of similar
under the skin.

Well, it *does* take some pointers from Python but it's still
much more like Java (and even C++) under the hood, AFAIK. I'll get to
know firsthand soon, though, as I'll have to acquaint myself fully with
C#'s benefits, pitfalls and whatnot for a new project I'm on that (for
definitely political reasons) will have it as the main development
language. I'd pity myself if it weren't temporary; Python withdrawal isn't
good for my health ;-)

--
Christopher

Jul 18 '05 #19

Bulba!

On 31 Dec 2004 03:49:44 -0800, Paul Rubin
<http://ph****@NOSPAM.invalid> wrote:

It's not just a matter of attitude or politics. Python is an
excellent choice for many projects. For some other projects, it's
clearly unsuitable. For yet other projects, it's a plausible choice
but there are sound technical reasons to be wary of it.

(being the usual me, I can't resist putting a stick into
a nest of pythons)

OK, so what projects and why would you consider
Python:

1. "clearly unsuitable"

2. "plausible but there are sound technical reasons
to be wary"

BTW, I don't think I agree with your statement
elsewhere about unit tests - if you write a prototype
(in any language), why bother with unit tests, and
if you write security-critical app, maybe the tests
should be written anyway (again, whatever is the
language chosen for a project).

--
It's a man's life in a Python Programming Association.

Jul 18 '05 #20

Peter Dembinski

Paul Rubin <http://ph****@NOSPAM.invalid> writes:

[...]

I'm involved in a development project for something that's security
critical and has to be reliable. The implementation language hasn't
been chosen yet. Python and Java are both possibilities. I'm fine
with the idea of using Python for demos and prototypes. For the
production system I think we may be better off using Java.
Reliability of the final product is more important than rapid
implementation.

If it has to be both reliable and secure, I suggest you used more
redundant language such as Ada 95.

Jul 18 '05 #21

Bulba! <bu***@bulba.com> writes:

OK, so what projects and why would you consider Python:

1. "clearly unsuitable"
An OS kernel, a high-performance signal processing application like a
video encoder, or maybe a compact embedded application for an 8-bit
microcontroller. Note that you could do the microcontroller project
with JavaCard. (Yeah, you could maybe write the outer shell of the
high-performance app in Python, but I mean the part doing the real work.)
2. "plausible but there are sound technical reasons to be wary"
A security-critical financial application.
BTW, I don't think I agree with your statement elsewhere about unit
tests - if you write a prototype (in any language), why bother with
unit tests, and if you write security-critical app, maybe the tests
should be written anyway (again, whatever is the language chosen for
a project).

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.

I'm also not too impressed with Python's bundled debugging features,
as compared with gcc/gdb. People have said nice things about some of
the commercial Python environments but I haven't used those.

Jul 18 '05 #22

Peter Dembinski <pd***@illx.org> writes:

If it has to be both reliable and secure, I suggest you used more
redundant language such as Ada 95.

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?

Jul 18 '05 #23

On Fri, 31 Dec 2004 05:54:05 -0800, Paul Rubin wrote:

Bulba! <bu***@bulba.com> writes:
OK, so what projects and why would you consider Python:

1. "clearly unsuitable"
An OS kernel, a high-performance signal processing application like a
video encoder, or maybe a compact embedded application for an 8-bit
microcontroller.

Of course, but those are not areas where I'd consider any
high-level language appropriate. C, Forth and Assembler rule where every
last bit counts, and they will continue to do so. Exceptions like Lisp
Machines are however something to hope for.

Note that you could do the microcontroller project with JavaCard. (Yeah, you could maybe write the outer shell of the
high-performance app in Python, but I mean the part doing the real work.)
Hmm, didn't know about JavaCard, but I'd guess without bothering to look
that, like Java's Micro Edition, this features a restricted subset of
Java... Python definitely cannot do that now, but the PyPy future may
(hopefully) change that. And at least Python's beginning to try to
encroach in the very heavily Java-dominated mobile phone software market...

2. "plausible but there are sound technical reasons to be wary"
A security-critical financial application.

Why, specifically? Would you need to eval user input?

BTW, I don't think I agree with your statement elsewhere about unit
tests - if you write a prototype (in any language), why bother with
unit tests, and if you write security-critical app, maybe the tests
should be written anyway (again, whatever is the language chosen for
a project).

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.

I'm also not too impressed with Python's bundled debugging features,
as compared with gcc/gdb. People have said nice things about some of
the commercial Python environments but I haven't used those.

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.

--
Christopher

In theory, I'm in love with Lisp,
but I hop into bed with Python every chance I get.

Jul 18 '05 #24

Christopher Koppler <kl******@chello.at> wrote:
...

> What makes such companies to choose Java over dynamic, productive
> languages like Python? Are there any viable, technical reasons
> for that? ... There is a reason very important to major companies. When you leave
that company, there will be a *long* line of Java programmers
waiting to take your place.

IMO learning Python is a matter of few days for Java programmer.

True, but learning to *think* in Python takes a while longer. That static
straitjacket takes some time to loosen...

Yes to both: learning, particularly with Jython (so one keeps using
already-known Java libraries), is quite fast -- the full benefits take
more time to develop, although even using Python less than ideally can
already be faster. But for a company to convince itself that the
investment is small and the benefits accrue rapidly -- and keep accruing
in the long term -- can still be quite a leap of faith.
Alex

Jul 18 '05 #25

Christopher Koppler <kl******@chello.at> wrote:

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

Well, Google's market capitalization must be around 50 billion dollars
or more, in the range of the top-100 companies, I believe, and they've
never kept their Python use a secret. But they don't sell SW nor
consulting services like, say, MS or IBM...
Alex

Jul 18 '05 #26

al*****@yahoo.com (Alex Martelli) writes:

Well, Google's market capitalization must be around 50 billion dollars
or more, in the range of the top-100 companies, I believe, and they've
never kept their Python use a secret.

They use Python for a lot of internal tools but their high-volume
services are written in C++.

Jul 18 '05 #27

Paul Rubin <http://ph****@NOSPAM.invalid> wrote:

al*****@yahoo.com (Alex Martelli) writes:
Well, Google's market capitalization must be around 50 billion dollars
or more, in the range of the top-100 companies, I believe, and they've
never kept their Python use a secret.

They use Python for a lot of internal tools but their high-volume
services are written in C++.

I thought the "webcrawling" and updating of the indices/databases/caches
(high-volume, but not latency-critical) was coded in Python, the
latency-critical part (essentially that where every fraction of a second
counts, because a human user might be waiting for an answer), such as
queries to those DBs, in C++ -- based on the idea that you can "always"
(well, if you've got the right underlying data structures, of course,
and if the problems you're solving are as "embarassingly parallel" as
these would seem to be) enhance throughput by throwing more HW at the
problem, but latency doesn't yield to such treatment. But, I could be
wrong, of course; I don't recall where I may have read these details,
and the throughput vs latency issue is a well-known general
consideration, so I may simply have "bridged" these in my mind.
Alex

Jul 18 '05 #28

beliavsky

Bulba wrote:

OK, so what projects and why would you consider
Python:
1. "clearly unsuitable"

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
significant speed differential between Fortran 95 and Python with
Numeric. I don't know if using Numarray instead would change the
results.

Calling an extension written in C, such as Numeric, can improve
performance greatly over using "pure" Python, but the speed of
evaluating simple expressions can still be close to 2 orders of
magnitude slower.

Here is an example that computes
(1) sum(x)
(2) sum(x**2)
(3) sum((x-0.5)**2)

for 1E7 uniformly distributed random numbers.

# Python
from RandomArray import random
from time import time
from Numeric import sum
n = 10000000
half = 0.5
x = random(n)
for iopt in range(1,4):
t1 = time()
if (iopt == 1):
xsum = sum(x)
elif (iopt == 2):
xsum = sum(x**2)
elif (iopt == 3):
xsum = sum((x-half)**2)
t2 = time()
print iopt,xsum,t2-t1

! Fortran 95
program xsum_power
implicit none
integer, parameter :: n = 10000000
real(kind=8) :: x(n),xsum,t1,t2
real , parameter :: half = 0.5
integer :: iopt
iopt = 1
call random_seed()
call random_number(x)
do iopt=1,3
call cpu_time(t1)
select case (iopt)
case (1) ; xsum = sum(x)
case (2) ; xsum = sum(x**2)
case (3) ; xsum = sum((x-half)**2)
end select
call cpu_time(t2)
write (*,"(i4,100f16.6)") iopt,xsum,t2-t1
end do
end program xsum_power

The approximate times taken in seconds, in Python and Fortran, are

task Fortran Python
sum(x) 0.05 0.1
sum(x**2) 0.05 2.4
sum((x-0.5)**2) 0.05 3.2

In the Fortran code, essentially all the time is spent accessing the
array elements. Powers and subtractions in array operations seem to be
free in Fortran but very expensive in Python with Numeric.

Not wanting to be guilty of "premature optimization", I did not try to
make either code more efficient than my first attempt. The Fortran
compiler is Compaq Visual Fortran 6.6c, and the Python used is 2.2.

Jul 18 '05 #29

JanC

Paul Rubin schreef:

Java code is larger and takes longer to write, but has a higher chance
of working properly once it compiles and passes basic tests.

That's why you can make most JSP sites useless by disabling cookies in
your browser? :-p
--
JanC

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

Jul 18 '05 #30

<be*******@aol.com> wrote:
...

array elements. Powers and subtractions in array operations seem to be
free in Fortran but very expensive in Python with Numeric.

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

Jul 18 '05 #31

In article <7x************@ruckus.brouhaha.com>,
Paul Rubin <http://ph****@NOSPAM.invalid> wrote:

Peter Dembinski <pd***@illx.org> writes:
If it has to be both reliable and secure, I suggest you used more
redundant language such as Ada 95.

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?

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.

Jul 18 '05 #32

In article <pa****************************@chello.at>,
Christopher Koppler <kl******@chello.at> wrote:

Jul 18 '05 #33

Hans Nowak

Paul Rubin wrote:

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.

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/

Jul 18 '05 #34

Hans Nowak

Christopher Koppler wrote:

--
Christopher

In theory, I'm in love with Lisp,
but I hop into bed with Python every chance I get.

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/

Jul 18 '05 #35

Cameron Laird wrote:

In article <pa****************************@chello.at>,
Christopher Koppler <kl******@chello.at> wrote:
.
.
.
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]
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.

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.

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

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

Jul 18 '05 #36

Mike Meyer

cl****@lairds.us (Cameron Laird) writes:

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

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 <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Jul 18 '05 #37

Christopher Koppler <kl******@chello.at> writes:

2. "plausible but there are sound technical reasons to be wary"
A security-critical financial application.

Why, specifically? Would you need to eval user input?

Static typing, checked exceptions, etc.
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.

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.

Jul 18 '05 #38

JanC

Steve Holden schreef:

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.

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

Jul 18 '05 #39

M.E.Farmer

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

Jul 18 '05 #40

In article <Jv************@fe61.usenetserver.com>,
Hans Nowak <ha**@zephyrfalcon.org> wrote:

Paul Rubin wrote:
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.

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.

Jul 18 '05 #41

In article <11*********************@z14g2000cwz.googlegroups. com>,
<be*******@aol.com> wrote:

Bulba wrote:
OK, so what projects and why would you consider
Python:
1. "clearly unsuitable"

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

Jul 18 '05 #42

Paul Rubin wrote:

[...]

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.

^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

Jul 18 '05 #43

Paul Rubin wrote:

[...]

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.

^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

Jul 18 '05 #44

Cameron Laird wrote:

In article <11*********************@z14g2000cwz.googlegroups. com>,
<be*******@aol.com> wrote:
Bulba wrote:
OK, so what projects and why would you consider
Python:
1. "clearly unsuitable"

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

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

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

Jul 18 '05 #45

Donn Cave

Quoth Hans Nowak <ha**@zephyrfalcon.org>:
| Paul Rubin wrote:
|
|> 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.
|
| 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.

I have been fooling around with strongly, statically typed languages
for a couple of years, in my spare time - Objective CAML, Haskell,
O'Haskell. This is a little different experience than what you two
are talking about - I don't think Java, C# and their ilk are quite as
rigorous, nor do they use type inference - but as much as it would
probably gag an FP enthusiast to say this, the basic idea is the same.

I can only believe that if you think the benefit of static typing is
psychological, either something is very different between the way you
and I write programs, or you're not doing it right.

For me, the effect is striking. I pound out a little program, couple
hundred lines maybe, and think "hm, guess that's it" and save it to
disk. Run the compiler, it says "no, that's not it - look at line 49,
where this expression has type string but context requires list string."
OK, fix that, iterate. Most of this goes about as fast as I can edit,
sometimes longer, but it's always about structural flaws in my program,
that got there usually because I changed my mind about something in
midstream, or maybe I just mistyped something or forgot what I was doing.
Then, when the compiler is happy -- the program works. Not always, but
so much more often than when I write them in Python.

Now you may repeat here that we all must make thorough unit testing
a cornerstone of our Python programming, but don't tell me that the
advantage of static typing is psychological. It does substantially
improve the odds that a program will be correct when it runs, because
I have seen it happen.

If unit testing does so as well, then obviously there will be some
redundancy there, but of course only where you actually have complete
coverage from unit testing, which not everyone can claim and I'm sure
even fewer really have. And like the man said, you're doing that work
to find a lot of things that the compiler could have found for you.

Donn Cave, do**@drizzle.com

Jul 18 '05 #46

Hans Nowak

Donn Cave wrote:

Quoth Hans Nowak <ha**@zephyrfalcon.org>:
| Paul Rubin wrote:
|
|> 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.
|
| 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.

I have been fooling around with strongly, statically typed languages
for a couple of years, in my spare time - Objective CAML, Haskell,
O'Haskell. This is a little different experience than what you two
are talking about - I don't think Java, C# and their ilk are quite as
rigorous, nor do they use type inference - but as much as it would
probably gag an FP enthusiast to say this, the basic idea is the same.

I can only believe that if you think the benefit of static typing is
psychological, either something is very different between the way you
and I write programs, or you're not doing it right.

I do think it makes more sense in functional languages like the ones you
mention... that's one of the reasons I am trying to learn OCaml. I
don't think the type systems in OCaml, Haskell etc can quite be compared
to what's used in Java, C#, C++ or Delphi. So far, I am getting the
impression that the type system in OCaml is actually there to help you,
rather than something that gets in your way.

I concur that in my OCaml experiments so far, errors pointed out by the
compiler made a lot more sense, because they pointed to actual problems,
rather than being a case of "you didn't declare this method as public
static final".

Of course, it helps that, like Python, said languages (OCaml, Haskell)
are higher-level than Java/C#/etc, so you can express things concisely
and clearly. That might be one of the reasons why static, strong typing
in VHLLs has a much higher "return on investment" than it has in
lower-level languages, where you have to write acres of code just to get
something done (availability of libraries notwithstanding).

--
Hans Nowak
http://zephyrfalcon.org/

Jul 18 '05 #47

Rob Emmons

> For managers of companies it's worse: the company makes

VERY substantial investments into any technology it "marries",
and that means big losses if it goes. Long-term stability
of this technology in terms of "we're not going to be left out
in cold alone with this technology to feed it" means a lot
to them. Even a poor technology with external backing
of big, stable vendor is better than the excellent technology
without ......

There is the stability issue you mention... but also probably the fear
issue. If you choose a solution from a major company -- then it fails for
some reason or they drop the product -- it's their fault -- you've got an
automatic fall guy. On the other hand, an open source solution or
otherwise less accepted solution ... it will probably be consider
your fault by the organization. It's a rational decision to avoid
personal risk when you don't get much reward for choosing something
different.

Rob

Jul 18 '05 #48

Rob Emmons wrote:

For managers of companies it's worse: the company makes
VERY substantial investments into any technology it "marries",
and that means big losses if it goes. Long-term stability
of this technology in terms of "we're not going to be left out
in cold alone with this technology to feed it" means a lot
to them. Even a poor technology with external backing
of big, stable vendor is better than the excellent technology
without ......

There is the stability issue you mention... but also probably the fear
issue. If you choose a solution from a major company -- then it fails for
some reason or they drop the product -- it's their fault -- you've got an
automatic fall guy. On the other hand, an open source solution or
otherwise less accepted solution ... it will probably be consider
your fault by the organization. It's a rational decision to avoid
personal risk when you don't get much reward for choosing something
different.

You are ignoring the fact that with the open source solution you do at
least have the option of hiring bright programmers to support the
framework which has now become moribund, whereas when a company goes
bust there's no guarantee the software IP will ever be extricated from
the resulting mess.

So I'm not sure I'd agree with "rational" there, though "comprehensible"
might be harder to argue with.

Personally I'd feel in a better position standing before a Board of
Directors and saying "While it's true that our chosen software platform
isn't being supported by the original team any more, we do have options
to continue to move it forward, including forming a consortium with
other users".

Avoidance of blame is way too large a motivator in large organizations,
and it leads to many forms of sub-optimal decision making.

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

Jul 18 '05 #49