NAME
docs/req/model_users.pod - Model Users For Parrot Design Decisions
RATIONALE
This document exists to give Parrot design a direction. Before we can make design decisions, we need a metric to evaluate them. The best metrics are based on informed intuition. This document is designed to inform the intuition.
Below are listed some model users with random (or, in some cases, not-so-random) names.
Questions to ask yourself: Do you know anyone who fits these descriptions? If so, what else would you write about them? How would you describe them? What else do they care about? What do they not care about?
And let's remember that, in the end, we can't really please everyone. So we have to pick who we'll please, and who we'll piss off. It just can't be helped.
MODEL USERS
"Autrijus": Perl 6 implementer
Autrijus has a favorite language, Perl 6, and he wants to target it to Parrot.
Autrijus:
values speed, but not above all else
values interoperability of languages, especially with Perl 5
doesn't care about PBC particularly, though he knows his users might, eventually
doesn't mind incompatible source changes, as long as the entire tool chain still works after upgrading
"Nick": Ponie implementer
Nick is implementing Perl 5 with (over? under? inside?) Parrot.
Nick:
doesn't care about dynamic loading of features
???
"Dick": Scripting an existing application
Dick has an application that needs some scripting features, so he's embedding Parrot to get PIR and the languages that target it, e.g. Perl 6.
Dick:
cares mostly about ease and stability of embedding (no memory leaks! no seg faults!)
is probably not very sensitive to performance, since scripting interfaces are never speed demons anyway
probably bundles a specific Parrot version (or linkage to a specific version) and maybe precompiled pbcs with his program
may be more or less tolerant of changes depending on the system into which Parrot is embedded
"Tom": Embedded system creator
Tom loves Perl 6, so wants to write his special-purpose embedded system to run on Parrot. The platform is very limited, and speed is not particularly crucial.
Tom:
cares mostly about stable long-term execution (no memory leaks! no seg faults!)
doesn't care about inter-version compatibility, since he bundles Parrot with his product
doesn't care very much about performance
depends on PBC for space efficiency
wants to be able to strip down Parrot for deployment, omitting subsystems that are large or which depend on large external systems
"Ilya": Intensive CPU User
Ilya writes high-performance CPU-bound code, typically involving either intense data structure manipulation or floating point math.
Ilya:
cares about performance to exclusion of most other factors
doesn't care about PBC one way or the other
can't handle incompatible source changes; is likely to pick a favorite feature set and stick with it
"Magpie": Lover of shiny things
Magpie sees something shiny -- a new runtime, or a new language, or even better, a new language on a new runtime -- and is willing to do a lot to make it work, just so he can play with it.
Magpie:
loves neat features
doesn't care about PBC, backwards compatibility, or any of the things that make a platform stable and useful for users who don't care about shiny tech
will put up with almost any change as long as the inconvenience leads to something even more shiny