John J. Lee
jjl at pobox.com
Sat Sep 6 14:03:10 CEST 2003
"Michael Peuser" <mpeuser at web.de> writes:
> "John J. Lee" <jjl at pobox.com>
> > > There are two aspects:
> > > (1) More power for same price - this works in favour of 'complex
> > > (2) Same power for less money - this works in favor of 'cheap software'
> > And? What is your point? In both cases, the more bangs per buck, the
> > greater the economic advantage that accrues to Python when compared
> > with, say, C++.
> There is no linear scaling in these issues. It is of no importance whether a
> word processor takes 0.1 sec instead of 0.01 for some operations. It is when
> it takes 5 sec instead of 0.5. The issues with hard real time programs are
> obvious. Most code is not written for home applications or some esoteric
> operating systems as windows but for telecomunication, industry
> microcontrollers, car applications,....
Windows is an esoteric OS?
Still, you make an interesting point here: is it the case that more
code is written for hard real-time systems than not? That would
certainly surprise me. Where do you get your data?
> May be they will be programmed in Python in 20 years, though I do not see
> it. You need a certified compiler, a fail proof and predictable garbage
> collector, and a little bit more.
Yes. And? We seem not to be communicating here...
> This is the matter of 'cheap' software.
Sorry, I don't quite follow that. How does that relate to the rest of
> Same argument holds for supercomputing as well. I may be wrong but I doubt
> that the ASCIs will ever see much Python in their production lifetime.
ASICs, you mean? Well, no, but so what? I don't think anybody has
ever *claimed* that Python is suitable for that kind of application.
> > Python is an order of magnitude easier to learn than C++, but it
> > brings really significant programmer-efficiency benefits. As a
> > result, the argument about training simply doesn't stand up: the costs
> > are lower than the benefits even on a short timescale.
> I know this argument well and have repeated it myself in the days of Pascal
> and Algol68. Few have listened.....
Well, they'd be right not to listen if you argued it about Pascal.
There's a real difference in productivity between Pascal and Python.
Pascal doesn't even have built-in garbage collection, for heaven's
sake, which places it much closer to C than to Python in this respect.
> Programmers are generally not trained in their compyna, thea are hired
> including their special language skills.
You're begging the question: arguably, that is the mistake of those
hiring. Training (for Python, anyway) will frequently be cheaper than
sticking to, say, C++. Other skills are more important than
pre-existing ability to use a language like Python (though that's
certainly not irrelevant!).
> > > The fact that a better world is possible does not mean you get it.
> > True (with the definite exception of 'state any new thing you like'!),
> > but I get the impression most places don't even try. Obviously, OOP
> > *has* swept the industry, and presumably most commercial development
> > makes use of version control.
> There is a great, great difference between what really happens and what
> management thinks is happening....
> > Total costs are exactly the issue -- the contention is that use of
> > languages like Python really does have a significant impact on that.
> This argument had been used by the most ambitious software tool project of
> the last century, which was DoD's Ada. Very few people will ever believe
> something like that again ;-)
> > > I should as well like to discuss your aspect of programmer's
> > > This is an important factor. However all investigations show that
> > > programmer's productivity is an unmeasurable quantity.
> > How would an empirical investigation show such a thing?
> Alex gave a hint to a German study. I think he was refering to:
(That was probably the one I was thinking of in another paragraph in
my reply) I don't see how such a study could show that "programmer's
productivity is an unmeasurable quantity". It's obvious that
variations between individuals make differences due to languages hard
to measure, but that doesn't make it impossible.
More information about the Python-list