Doelstellingen

• Doelgroep: we willen enerzijds een pakket dat voor educatieve doeleinden kan gebruikt worden (dus door gebruikers met weinig voorkennis van computers of wiskunde), maar anderzijds ook een pakket dat in een professionele productieomgeving (wat dat dan ook moge zijn) gebruikt kan worden. Iets concreter: het moet voor educatieve doeleinden geschikt zijn (dus niet onoverkomelijk complex in het begin) maar niet te beperkt zijn in mogelijkheden. Of, zoals het zo mooi gezegd wordt: eenvoudige dingen moeten eenvoudig zijn, en complexe dingen moeten mogelijk zijn.
• Interactief: van zodra je een operator intikt, wordt hij herkend. Bv. als je a/b typt, wordt direkt een breuk getoond, in tegenstelling tot andere systemen waar je eerst een hele regel in moet tikken en dan te horen krijgt dat er ergens een haakje te weinig staat.
• Gebruikersvriendelijk: ook al is het dikwijls veel meer programmeerwerk (zie hierboven) en iets trager: de dynamische parser bijvoorbeeld gebruikt natuurlijk iets meer processortijd tijdens het intikken, maar we zijn het 80x25-tekstscherm-tijdperk al lang voorbij (zelfs een handheld palmcomputer van tegenwoordig heeft een grafisch scherm en 2MB RAM). Die paar milliseconden extra verbruikte rekentijd wegen niet op tegen de tijd die de gebruiker uitspaart doordat het programma makkelijker te leren en gebruiken is.
• Correct: als je ziet dat veel grote pakketten er al niet in slagen eenvoudige functieplots verkeerd voor te stellen ... Het mag dan (heel) wat meer programmeerwerk vragen, we zijn niets met een systeem dat af en toe eens een verkeerd antwoord produceert. Efficiëntie van de gebruikte algoritmen is natuurlijk ook belangrijk, maar voor ons toch ondergeschikt. We zijn ook niets met een programma dat ons bliksemsnel het verkeerde antwoord geeft.
  (Veel) Later kunnen we proberen de correctheid te bewijzen met de formele logica-modules uit het programma zelf.
• Uitbreidbaar: je moet makkelijk eigen modules, operatoren, datatypes, notaties, enzovoort aan het systeem kunnen toevoegen. Om dit te vergemakkelijken moet het programma modulair opgebouwd worden (hiervoor gebruiken we natuurlijk het Java package management).
• Compatibel: we willen zo weinig mogelijk het wiel heruitvinden.
  • zoveel mogelijk standaard formaten gebruiken. Het ad-hoc .text formaat dat nu gebruikt wordt om formules te bewaren naar disk moet op termijn vervangen worden door MathML of zoiets.
  • programmeertaal zoveel mogelijk op Java baseren: het heeft geen zin het zoveelste nieuwe programmeertaaltje voor het zoveelste nieuwe computeralgebrapakket uit te vinden. Bovendien profiteren we van de OO-omgeving (klassen/methoden, garbage collector) van Java die beter getest is dan we zelf ooit zouden kunnen.
• Generiek: we willen dat het systeem zo weinig mogelijk vast ingebakken elementen bevat. Zo moet het mogelijk zijn eigen operatoren toe te voegen, en mogen de standaard-operatoren zo weinig mogelijk `bevoordeeld' worden door het systeem. Dit betekent dat bijvoorbeeld de `+' operator niet op een speciale manier zal behandeld worden maar op precies dezelfde manier in het systeem zit als een operator die je zelf zou gemaakt hebben. Vergelijk dit bv. met de manier waarop Pascal ingebakken procedures als writeln() voordelen meegeeft (variabel aantal en type van de argumenten) tegenover C, waar printf() een doodgewone functie is die je net zo goed zelf had gemaakt kunnen hebben.
  Analoog willen we dat je eigen bestandsformaten voor import en export makkelijk kan toevoegen.
• Open source: in hoeverre dit de kwaliteit van programma's verbetert, is nog steeds onderwerp van hefige discussies :-) Bedoeling is, eens de kern van het pakket stabiel is, het volledige pakket te open sourcen.
  Zie ook: Open Sources: Voices from the Open Source Revolution
  The Cathedral and the Bazaar
  Homesteading the Noosphere
  Software Release Practice HOWTO
  
• Ontkoppeling van voorstelling en inhoud: een `vermenigvuldiging' object kan zich tonen als a*b, ab, a.b enzovoort; een if-then object als if c then p of als een stroomdiagram, ... Net zoals T<sub>E</sub>X willen we dat je kan kiezen welke `stijl' gebruikt wordt om een object te tonen.
  Zie ook: SCID---Source Code In Database
• Modulariteit: dit hangt een beetje samen met het zoveel mogelijk willen overnemen van de Java programmeertaal. We willen dat alle functies niet in één grote namespace zitten, zodat twee pakketten elkaar nooit in de weg kunnen lopen. (Uit het leven gegrepen: een bepaalde versie van GAP heeft een nieuwe functie (die dan alleen nog intern gebruikt wordt ook!) en daardoor werkt een bepaald zelfgeschreven pakket niet meer omdat het die naam ook gebruikte als functienaam.)
• Internationalisation ondersteuning: we willen, voornamelijk uit educatief oogpunt, het programma voor meerdere talen configureerbaar maken. Dit hangt samen met de ontkoppeling van voorstelling en inhoud: net zoals a*b zich soms toont als a.b, moet computeCentralisatorGroup() zich soms kunnen tonen als berekenCentralisatorGroep().
• Of het ooit af zal geraken is natuurlijk een andere vraag; ik kan hier staan kappen op GAP, Maple enz. zoveel ik wil maar daarmee hebben we natuurlijk nog geen magische oplossing :-) Aan de andere kant ben ik ervan overtuigd dat een gevoel van onvrede met de bestaande pakketten een zeer goede motivatie is om het beter te doen ...
• Buzzword-compliant: Triviaal.