docs/req/model_users.pod - Model Users For Parrot Design Decisions
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.
Audrey has a favorite language, Perl 6, and he wants to target it to Parrot.
- 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 is implementing Perl 5 with (over? under? inside?) Parrot.
- doesn't care about dynamic loading of features
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.
- 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 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.
- 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 writes high-performance CPU-bound code, typically involving either intense data structure manipulation or floating point math.
- 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 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.
- 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