[alg] scripten binnen een applicatie

[Alarmnummer]

De laatste tijd ben ik geinteresseerd geraakt in Jython. Dit de java versie van Python en valt vrij eenvoudig met java te integreren. Het voordeel aan een scripttaal is dat je minder verbose code hoeft te schrijven en dat je ook stukken van de applicatie niet als sourcecode hoeft te compileren (en dus altijd bij kan schaven). Maar aan de andere kant is heeft het ook weer beperkingen die te groot zijn om in te zetten voor echt veilig code, zoals bv static typechecking.

Mijn vraag is dus wie ervaring heeft met het gebruiken van scriptalen binnen een applicatie (ook vbs bijvoorbeeld) en wat je gaat scripten en wat je gaat schrijven in een 'traditionele' taal.

[ Voor 13% gewijzigd door Alarmnummer op 19-08-2003 18:38 ]

[Verwijderd]

Ik heb het Bean Scripting Framework met Rhino gebruikt (JavaScript in Java).
Dit heb ik gebruikt voor een Business Process Management (BPM) engine.
De engine was is java, de taken die het beschikbaar stelde ook.
Maar de volgorde en de uitvoering van sommige taken in javascript.
De volgorde, checks en informatie in de messages konden namelijk voor ieder process verschillen.
Zo konden we makkelijk en flexibel nieuwe processen definieren.

[Soultaker]

In principe heb je met Java (en .NET for that matter) natuurlijk al het voordeel dat je dynamisch extra code kan laden. Als extra voordeel heb je dat je een perfect aansluitende API hebt en dus geen communicatielaag tussen hoeft te voegen voor je scripting omgeving. Die extra laag wordt waarschijnlijk ook wel door Jython afgehandeld (ik had begrepen dat je daarin gewoon Java objecten vanuit Python kon gebruiken, en vice versa) maar meer algemeen heb je dat probleem natuurlijk wel (denk daarbij aan embeddable scripting talen als Lua of Tcl). Ik heb zelf overigens geen praktische ervaring met het embedden van scripting environments.

Ik kan me dus enerzijds goed voorstellen dat je een library als Jython gebruikt, omdat de kosten van de integratie met Java vrij laag zijn en de winst vrij groot (je krijgt er een goede embedded scripting environment voor terug), maar anderzijds lijkt me de noodzaak om een embedded scripting environment te creeeren me voor Java veel kleiner dan (bijvoorbeeld) in het geval van C of C++. In Java kan een plug-in de boel tenminste niet compleet verneuken terwijl een native component de applicatie kan laten crashen, om maar wat te noemen.

[mbravenboer]

Jext gebruikt erg veel (en steeds meer) Jython, misschien dat je daar wat ideeen uit kan halen?

[alienfruit]

Ik gebruik "PascalScript" (wordt ook gebruikt in DevExpress' EWF) in veel van mijn programma's kan men ook scripten, hierbij zie ik scripten als een manier om de functionaliteit van het programma uit te breiden dmv. nieuwe functionaliteit.

Zodoende kun je bijv. nieuwe menu items, dialogs etc. maken waarbij je volgens dingen mee kunt doen bijv. code generen voor in de code editor (of records) en op een makkelijke manier aanbieden van toevoegen van nieuwe business rules voor bijvoorbeeld CRM programma's (of het berekeningen/controles uitvoeren op gegevens) of cross-over programming waarbij een script gehele functionaliteit van het orginele programma overneemt (maar dit gebruik ik niet zo vaak, zie commentaar beneden) . Maar bijvoorbeeld ook voor batch processing, je bied verschillende interfaces aan zodat de gebruiker verschillende functies kan automatiseren.

Ik zie scripten binnen een applicatie meer als een "feature" voor de eindgebruiker, dan het beperken van de "verbose code" (zoals je dat zo mooi noemt) in het programma zelf. Het probleem met scripten is namelijk wel dat de gebruiker heel snel geneigd blijkt te zijn, om lekker te gaan "spelen" met deze scripts, wat dan weer problemen kan geven als het programma zelf (erg) afhankelijk is van net die scripts.

[ Voor 7% gewijzigd door alienfruit op 20-08-2003 01:51 . Reden: dingetjes ]

[Alarmnummer]

Soultaker schreef op 19 August 2003 @ 20:43:
In principe heb je met Java (en .NET for that matter) natuurlijk al het voordeel dat je dynamisch extra code kan laden. Als extra voordeel heb je dat je een perfect aansluitende API hebt en dus geen communicatielaag tussen hoeft te voegen voor je scripting omgeving. Die extra laag wordt waarschijnlijk ook wel door Jython afgehandeld (ik had begrepen dat je daarin gewoon Java objecten vanuit Python kon gebruiken, en vice versa) maar meer algemeen heb je dat probleem natuurlijk wel (denk daarbij aan embeddable scripting talen als Lua of Tcl). Ik heb zelf overigens geen praktische ervaring met het embedden van scripting environments.

Jython in Java embedden is gelukkig geen enkel probleem. Het is een paar regels aansluiten, eigenschappen instellen en draaien maar. En jython kan idd eenvoudig java objecten aanspreken, hij kan ze ook gebruiken als zijn eigen typen (hij kan er bv ook zelf van extenden). Ik geloof zelfs dat andersom het ook mogelijk is.

Ik kan me dus enerzijds goed voorstellen dat je een library als Jython gebruikt, omdat de kosten van de integratie met Java vrij laag zijn en de winst vrij groot (je krijgt er een goede embedded scripting environment voor terug), maar anderzijds lijkt me de noodzaak om een embedded scripting environment te creeeren me voor Java veel kleiner dan (bijvoorbeeld) in het geval van C of C++. In Java kan een plug-in de boel tenminste niet compleet verneuken terwijl een native component de applicatie kan laten crashen, om maar wat te noemen.

Ik zie het intussen regelmatig gebruikt worden voor allerlei taken om de applicatie heen, zoals voor een buildscript (ipv ANT) en voor unittests.

Maar ik zit dus echt een beetje hoe ik het in moet zetten binnen de applicatie. Ik prog icm met mijn IDE(A) denk ik net zo snel als een ander rechtstreeks in Jython (dus ik heb mijn twijfels over het snelheids aspect) en het argument dat je jython scripts eenvoudiger kan aanpassen dan java heb ik ook mijn twijfels over. Java zal in bytecode aangeleverd moeten worden en jython kan geintepreteerd worden (je mag dus source aanleveren), maar ik heb toch ANT altijd op mijn systeem aanwezig, dus er zitten hoogstends een paar seconden snelheids winst in (voor Jython dus).

Scripten is dan het meest interessant voor de gebruikers. En als ik ergens zeker van ben dan weet ik dat juristen over het algemeen een hekel hebben aan technische zaken en hier ook niet zo snel mee gaan experimenteren. *schrijft software voor juristen*

Ik wil dus echt dolgraag Jython gebruiken binnen mijn systeem, maar ik heb nog steeds de meerwaarde er niet van kunnen ontdekken.

[ Voor 7% gewijzigd door Alarmnummer op 20-08-2003 14:36 ]

[Alarmnummer]

mbravenboer schreef op 19 August 2003 @ 20:52:
Jext gebruikt erg veel (en steeds meer) Jython, misschien dat je daar wat ideeen uit kan halen?

Dat is idd een goed idee.