>once you've lost it, [ simplicity, that is ] it's never
>coming back
How true, I'm not holding my breath for CGI.pm divesment.
Simplicity to me as an integrator/admin means having set of binaries that can be
recompiled, or preferably configed, into diverse implementations
with uniform results.
To this end the core could be invoked as an unanchored micro-perl (like shell), a
mini-perl replacment, perfectly behaved for the thin applications
world. In its simplest form it would be fed emitted bytecode evisioned in my RFC. It
seems this microperl could also be embedded into other
languages via whatever their version of XSUB is. Note the absence of PMs at this
level. (no, not prime ministers or ny perl mongers ;)
Traditional clients are the next step having all the above features, including
location floatability and object receivablility, installing anywhere,
loading pms through relative paths via env attrs or cli args. I'm thinking
pre-compiled win32, trust me when I say ActiveState is bloating.
Finally comes the full implementation, a mirror or subset of the CPANTS server, itself
built from every single piece of perl ever presented for
review. Well defined, it operates entirely in perl, happily harvesting pieces of
itself for the multitude of workstation clients and embedded
receivers. Here, a cgi-suite gives every browser in the world access to editors
compilers and version control and pod-tools well beyond whatever
CVS provides… your take-home copy emits directly into your perl, if you are lucky
enough to own one, otherwise you can live in CPANTS.
>It seems like a good idea to try and coordinate efforts with
>[ others ] like blackdown.org.
As un-sexy as this sounds, I think there should be a subgroup of all ~free~ s/w
developers who would specialize in low level modules and
integration kits allowing all projects to benefit from each others' pain and
frustration ( gotta love it )
I have been predicting for a year now that perl6 will spawn another language which
will be a marriage of perl/python/scheme/sh, hopefully
enabling a billion or so humans in defiance of AOL and Microsoft.
(last rant, I swear ;)
> I'll get the list out soon, and we can get things going darned soon.
Hey ho, lets go !!
PS, below are all the design criteria, though my list is short. Did I say "testing" ??
>parser
>optimizer
>bytecode
>runtime dispatcher (w/knowledge of dynaloading)
>data-types
>regex
>memory
>identify the units/modules
>map relationships between modules
>design the API for the modules
>code test cases for the API (circular process with the previous
step?)
>code the API
>code the wrappers for the libraries (perl.c, etc)
>Robustness
>Portability
>Maintainability
>Testability
>Reusability
>Speed
>Simplicity
>Size
>Avoid copying.
>Avoid premature optimization.
>Be extensible.
>Be orthogonal. Orthogonal be.
>Be portable.
>Be scalable
