Perl Objects with C APIs, Stackless Python, Misc

[Mitchell N Charity <address@hidden>]

   > Isn't anybody going to rage, rage against the
   > dying of the lightweight language list?

   I hereby warn this list that if I don't see some intelligent discussion
   about getting innovative language features into the hands of working
   programmers, I'm going to [... consequences too horrible to contemplate ...:]

Oh my.

   > as a relative newbie coming into computer science through python, i'd like
   > to know what the C translators are about and what people think about the
   > idea.  will they (or one of them) speed up python considerably, and if so,
   > at what cost?

   There are a lot of theories about this. Today's C translators are quite
   far from improving the performance of Python much. Optimization is
   tricky in general and quite difficult in a language as dynamic as
   Python. I'm beginning to wonder if JIT and optimization-at-rutnime
   techniques will preempt the C translators.

Perhaps a complementary approach is to have interacting objects
"conspire to compile".  Interacting Perl/Python/Ruby objects gossip,
and on finding a mutual capability to provide auxiliary C
implementations or apis, switch to dealing with each other "under the
table".  Either via collections of C function pointers, or by dumping
their mingled guts to a file for gcc optimization and dynamic linking.
The upside is one can do principled engineering of "cost free"
abstractions, and can get truly wizzy speed (often better than
maintainable hand-tuned C).  Downsides include rather increased
complexity, having to engineer twice+ as many apis, dealing blended
multilingual programming, and suffering the artifacts of a very
immature infrastructure (multi-second pauses, file turds, etc).
I've a quick, dirty, and grossly incomplete note at "An Illustration
of Perl Objects with C APIs"
http://www.vendian.org/mncharity/dir3/inline/illustration/


In other news, Stackless Python is apparently mutating from an
extensively hacked version of CPython, to a clean combination of
CPython and a C stack-swapping scheme for light-weight threads.
He is apparently looking to Limbo for the thread api.  Anyone with
insight might weigh in.  http://www.stackless.com/


It seems the Goo manual is still not available in HTML?  :(
Trying to view the pdf version online always reminds me of Tufte's
comments on maximizing the portion of ink devoted to data... :-/

Cheers,
Mitchell Charity
(looking for a job... really...)