Python advocacy

[Bijan Parsia]

Paul Prescod <paul at prescod.net> wrote:

[snip]
> 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.

This is very true. CMUCL and other systems have outperformed optimized C
code for certain numerical programs. Stalin, a highly optimizing, "whole
world" (a la Vyper) scheme compiler regular produced faster than C code
(for not crappy C, mind!).

There was an interesting discussion (I think on comp.lang.lisp) on
compiling to C. A Common Lisp implementer pointed out that on...Sparc
chips?...at the time, there were some powerful instructions and
instruction sequences that simply weren't usuable by C compilers. This
was an argument for generating native code directly.

One other general point is that systems like Smalltalk heavily optimize
message sends. So they permit/encourage a style where small methods,
forwarding messages, wrapping methods, etc. Similarly with classes,
which are easy and cheap to generate. Big systems tend to do better when
you can avail yourself of these sorts of abstraction techniques, and
langauges like C++ make it, in general, hard to use these with
reasonable performance (witness the problems lots of compilers had/have
with templates).

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

Yep and this has *always* been true, afaict. Or perhaps, true more in
the past :)

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

Actually, we just recently disputed this quite vigorously in
comp.lang.smalltalk :) We had quite the war with some static functional
types from comp.lang.functional.

I'll make the point that those folks (well, and that I make when wearing
my functional hat): The most commonly used static typing systems are
brutally horrendous and almost completely broken. The ones in modern
functional langauges especially with good type inferencing systems are
*much* nicer.

(Actually, I think the langauge to watch is Mercury, which let's you
declare *all sorts* of stuff including mode, determinism, and so on.
Rather efficient too. And strictly declarative.)

> It is relatively clear
> that it also helps the performance without massively complicating the
> implementation.

This is the biggest, IMHO, but there typically *loads* of room for
optimization before you get there. The difference between Squeak and
VisualWorks (perhaps the fastest current Smalltalk) is perhaps an order
of magnitude, or close to it, but VisualWorks has *no* type declarations
(built in) and none of the add-on type inferencers were used for
performance. Granted, the VisualWorks compiler/VM are *somewhat*
complex, but not insanely so. The Squeak JIT in the works looks to
increase Squeaks performance by 2-3x, and it's *very* straightforward.
(And Squeak's current vm beats CPython 1.5 by, from what I've read, 2x
or so.) None of this requires heroic efforts or compromizing simplicity
of implementation (indeed, that's one of the design constraints on the
Squeak VM, along with portability).

Folks interested in these issues should really take a peek at the 1999
OOPSLA workshop on VMs:

        http://www.squeak.org/oopsla99_vmworkshop/

I'll also point out that Self/Hotspot dynamic optimization based on
runtime profiling can get a lot of the speed with *no* actual type
declarations. Oberon has the basis of something like this in it's "slim
binaries", but, AFAIK, it's never been fully implemented.

Of course, some declarations + inferencing is probably easier to
implement. Especially if you want to e.g., compile to C.

[snip]

> Can there be one language that does everything? Everything? Possibly
> not, but it is better to presume so and fight to get there than to
> presume not and live with languages that force us to shift from one to
> the next because of designed-in limitations.

Of course, there are social issues, too. Tastes vary! But certainly I
think the default,
I'm-probably-going-to-be-stuck-programming-with-this-at-some-point,
all-the-jobs-require-this language could be *much* better than the
current ones. An XML of programming langauges (better than HTML with
it's goofy idiosyncracies and severe limitations, but more regualar than
SGML, though sharing in a lot of the benefits, including toolsets and
design strategies). Hmm. I like that analogy. I freely donate the title,
"An XML of programming lagnauges". ;)
 
Cheers,
Bijan Parsia.