Python advocacy

Cameron Laird claird at starbase.neosoft.com
Tue Mar 7 13:14:54 EST 2000


In article <38C411A1.B552C42 at prescod.net>,
Paul Prescod  <paul at prescod.net> wrote:
			.
		[Maybe Java can be
		used for everything;
		in any case, Tcl is
		crap]
			.
			.
>Then a language like Python comes along which subsumes the abilities of
>(at least) TCL, Perl, Visual Basic and ten thousand macro languages. It
>is my assertion that there are no large, complex problems that can be
>solved more easily in any of those languages than in Python with a
>suitable library and (in the case of VB) development environment.
			.
			.
			.
>choosing our programming languages for us. Yes, you can use sh and VBA
>for tiny little programs but isn't it just one damn more thing to learn?
>Is it worth learning another language to reduce a 10 line program into
>1?
>
>Given that Python offers us an opportunity to avoid the code
>fragmentation caused by all of these little fragmented language
>communities (Perl for text processing, TCL for Unix GUIs, VB for Windows
>GUIs, other Basic variants for macros), it is only natural to ask if it
>can also swallow the huge category of tasks being done with Java (we'll
>leave C and FORTRAN alone for now...). If Sun succeeds in making Java
			.
			.
			.
> 1. that the one complex feature we still cannot profitably strip out is
>type safety -- if we strip that out we won't be able to build big,
>complex systems (sound familiar?) or at least efficient systems
>
> 2. that there is no good way to introduce this feature into an
>erstwhile dynamically typed language
>
>I am told by those in the know that Common Lisp disproves both of these
>assertions. You can get fast code and complex systems from a language
>with an optional "add-later" type declaration system. In fact, people
>write large, complex systems in competely dynamic Lisps, Smalltalks and
>low and behold, Python. The people writing the largest systems seem the
>least inclined to argue that the lack of a static type system is
>limiting them.
>
>It is debatably the case that static type checking systems help people
>to write code that scales to large systems. It is indisputably clear
>that it can help the readability of the code. It is relatively clear
>that it also helps the performance without massively complicating the
>implementation. That's why Python is likely to eventually grow a static
>type system. Then we can shove another sock in mouth of the apologists
>for languages that are not good at one thing or another.
>
>Can there be one language that does everything? Everything? Possibly
			.
			.
			.
>> Obviously, Paul is entitled to his view that the cost of proficiency in C++
>> is too high. As a proficient C++ programmer, I have to disagree. I  can't
>> imagine writing industrial-strength apps solely in Python (and I do mean
>> industrial -- I've got applications running in steel mills).
>
>To be honest with you, if I was required to write an application that
>was going to run in a steel mill, and I was not constrained by memory or
>CPU (which you often would be) then I would choose a dynamically typed
>language with automatic memory management and pointer safety over a
>statically typed language without, any day. Tbe safe I would probably
>use a language like Java or Eiffel with both, just to be safe.
>Seriously, where reliability is an issue, C++ would be at the bottom of
>my list. Dr. Watson's frequent appearance on Windows NT desktops is a
>testament to C++'s reliability.
			.
			.
			.
Paul and I could happily go off in a corner and split hairs
for--well, for a long time.  I disagree with several claims
about Tcl, Java, ...; those who truly care about the details
are welcome, as usual, to ask.

I'll decorate a few of his more central points, though:
1.  Sun's not going to make Java a success.  I
    think Sun still intends that, but hasn't
    the capacity.

    IBM probably *will* make Java a success.
2.  I have no idea whether Java will make it in
    the embedded world.  My current expectation
    is that the project of porting Java every-
    where's going to collapse in a sorry heap.
    Maybe it'll work.  I'm unconvinced.
3.  Type safety is a tiny and essentially ir-
    relevant part of what it really takes to
    build big, complex systems.  I know you
    know this.  It needs to be repeated.
4.  Do NOT buy into the nonsense, even for a
    moment, that C and C++ are "better supported
    by tools".  They *require* tools to compensate
    for their burdens of memory management, ...
    That's the whole story.
5.  We're not far away from a time when people
    will say, "Controlling a steel mill/submarine/
    power plant/refinery/... with C++ codings?
    Are you serious?  That would be like, well,
    like, driving a car without having the children
    buckled into seat belts."  Yup.  We did it for
    a lot of years.  There's a much better way.
6.  Complex systems never work, anyway.
7.  Complex systems have a shot of working when
    they're constructed from reliable parts.  The
    winning languages of the '90s were those that
    played well with other technologies.
8.  Ada and Eiffel:  they're safe.
9.  As much as Paul wants to do everything with one
    language, I'm probably as strong on the other
    side in looking for a way to accomodate lots of
    different languages.
10.  If I had to choose only one language, it would
    definitely be Python.  It's not really ready,
    though, without Unicode ...
11.  It's the libraries.  Syntax--piffle!

I'm probably still better at C than anything else.  I can
process signals and respond to external ports and maintain
complex data structures and so on without leaking memory or
violating array bounds or confusing argument lists.  I'm an
anachronism, though.  I might as well be knapping flints.
Industrial customers are better off with any of several
other languages, although they don't yet realize it.

My most important point:  yes, we lose some benefits when
moving away from C and C++.  With very few exceptions, those
are costs we can afford, in comparison with the greater
benefits brought by other modern languages.  Don't get stuck
waiting for alternatives which are "perfect".
-- 

Cameron Laird <claird at NeoSoft.com>
Business:  http://www.Phaseit.net
Personal:  http://starbase.neosoft.com/~claird/home.html



More information about the Python-list mailing list