[Alg] Wanneer scripten, wanneer normaal?

[Alarmnummer]

Ik ben me aan het verdiepen in python omdat ik uit alle hoeken hoor dat scripten icm met gewoon programmeren je veel sneller kan laten werken, en verder kan python voor alle platformen krijgen en ook combineren met java. Maar mijn vraag is dus nu wanneer je gaat scripten en wanneer je in een echte taal gaat proggen. Mijn probleem is dat programma`s in bv python veel foutgevoeliger en onduidelijker zijn dan in java. Ik kan bv niet zien wat voor type er terug komt bij een functie, of wat voor type argumenten erin gaan. Je krijgt runtime een foutmelding als er iets is foutgegaan, maar het kan ook aan tijd duren voordat je een fout krijgt.

Ik zie dus nog niet echt echt in waarom scripten binnen applicaties iets zou toevoegen. Scripten om je eentonige acties te automatiseren (als vervangers voor de bat files), kan ik me wel uitstekend in vinden.

[Creepy]

Kijk bijv. ok eens naar Lua. Hierin kan je wel zien wat voor type je variablen zijn.

Mochten er dingen zijn die tijdens ontwikkeling vaak veranderen dan is zoiets perfect voor een script. Script aanpassen en klaar. Geen complete IDE openen, niet opnieuw compilen etc.. Dit kan je enorm veel tijd schelen. Bijv bij RPG games, tegen het einde van de ontwikkeling moet er redelijk wat getweakt worden in stats, items etc. Elke keer een recompile vertraagt dat enorm.

Ikzelf gebruik nu scripts om zo wat makkelijker plugins te ondersteunen. 1 script = 1 plugin. Niks geen gezeur met dynamisch laden van DLL's, packages o.i.d.. Uitbreiden is zo ook makkelijk, met een text editor ala notepad kan je prima uit te voeten om een plugin te maken.

Edit: Laatst had ik een probleem bij een klant. Een deel van onze applicatie is met scripts in elkaar gezet. Naar de klant toe, script aanpassen, klaar. Ik kan zelfs compleet bij de klant de scripts debuggen vanaf hun eigen machines zonder iets te installeren, of zonder dat m'n eigen machine bij hun in het netwerk gehangen hoeft te worden.

[ Voor 20% gewijzigd door Creepy op 15-01-2004 09:40 ]

[Alarmnummer]

Creepy schreef op 15 januari 2004 @ 09:34:
Kijk bijv. ok eens naar Lua. Hierin kan je wel zien wat voor type je variablen zijn.

Ik heb voorlopig even voor python gekozen omdat ik het kan krijgen voor Linux en Windows en voor java en .NET. En verder werd het overal wel vrij hoog aangeschreven.

Mochten er dingen zijn die tijdens ontwikkeling vaak veranderen dan is zoiets perfect voor een script. Script aanpassen en klaar. Geen complete IDE openen, niet opnieuw compilen etc.. Dit kan je enorm veel tijd schelen. Bijv bij RPG games, tegen het einde van de ontwikkeling moet er redelijk wat getweakt worden in stats, items etc. Elke keer een recompile vertraagt dat enorm.

Ik snap het voordeel van scripts wel, maar ik vraag me af of het voordeel opweegt tegen de nadelen. Ik gebruik ANT voor het builden en een rebuild duurt bij het aanpassen van een enkele file maar een paar seconden, dus ik vraag me af of die extra seconden opwegen tegen minder krachtige compiletime checks.

Ik ben op dit moment bezig met een applicatie waarin ik voor het glui`en van subsystemen python in ga zetten zodat deze mix van onderdelen niet een harde specificatie is van het systeem (wil je het anders.. pas het script aan). Dus hierin kan ik me wel vinden in het script gedeelte. Verder wil ik de definitie van operatoren ook mbv een script laten plaatsvinden zodat niet-java programmeurs (voornamelijk ai mensen) ook inzicht krijgen in de werking van operatoren, en nieuwe kunnen toevoegen. Hierin kan ik me ook vinden om scripts te verkiezen boven normale sourcecode. Maar hierbij heb ik ook meteen vragen zoals hoe kan ik dit gaan unit testen, en hoe weet ik dat het wel echt deugt.

[Creepy]

Alarmnummer schreef op 15 januari 2004 @ 09:52:
[...]

Ik heb voorlopig even voor python gekozen omdat ik het kan krijgen voor Linux en Windows en voor java en .NET. En verder werd het overal wel vrij hoog aangeschreven.

Lua is geschreven in plain C, en daarom zeker net zo portable (zo niet meer) dan Python, en koppelt ook prima aan Java en .NET. Maar laat ik ophouden met reclame te maken voor Lua

Python staat inderdaad hoog aangeschreven en is naar mijn mening hard opweg om één van de meeste gebruikte algemene script talen te worden.

[...]

Ik snap het voordeel van scripts wel, maar ik vraag me af of het voordeel opweegt tegen de nadelen. Ik gebruik ANT voor het builden en een rebuild duurt bij het aanpassen van een enkele file maar een paar seconden, dus ik vraag me af of die extra seconden opwegen tegen minder krachtige compiletime checks.

Ik acht even dat je helemaal geen voordelen zag in scripts . Gelukkig is dat niet zo. Uiteraard zijn er ook nadelen.

Ik ben op dit moment bezig met een applicatie waarin ik voor het glui`en van subsystemen python in ga zetten zodat deze mix van onderdelen niet een harde specificatie is van het systeem (wil je het anders.. pas het script aan). Dus hierin kan ik me wel vinden in het script gedeelte. Verder wil ik de definitie van operatoren ook mbv een script laten plaatsvinden zodat niet-java programmeurs (voornamelijk ai mensen) ook inzicht krijgen in de werking van operatoren. Hierin kan ik me ook vinden om scripts te verkiezen boven normale sourcecode. Maar hierbij heb ik ook meteen vragen zoals hoe kan ik dit gaan unit testen, en hoe weet ik dat het wel echt deugt.

Hier heb ik eigenlijk ook niet echt een antwoord op, en dat wordt nog moeilijker als je je scripts door derden laat aanpassen. Nou weet ik niet hoe je je scripts hebt geimplementeerd, maar als je in je scripts losse functies of Objecten hebt en ook zo kan gebruiken vanuit Java dan is de uitkomst van de functies of methods toch voorspelbaar en dus prima te unit testen?

[Alarmnummer]

Creepy schreef op 15 januari 2004 @ 10:02:
[...]

Lua is geschreven in plain C, en daarom zeker net zo portable (zo niet meer) dan Python, en koppelt ook prima aan Java en .NET. Maar laat ik ophouden met reclame te maken voor Lua

JLua

Hier heb ik eigenlijk ook niet echt een antwoord op, en dat wordt nog moeilijker als je je scripts door derden laat aanpassen. Nou weet ik niet hoe je je scripts hebt geimplementeerd, maar als je in je scripts losse functies of Objecten hebt en ook zo kan gebruiken vanuit Java dan is de uitkomst van de functies of methods toch voorspelbaar en dus prima te unit testen?

Je kan in 1 bestand meerdere operatoren plaatsen, dus het is een stuk lastiger om die eruit te vissen. In java heb je dan 1 operator per bestand en zet je ook heel duidelijk 1 testsuite op voor zo`n operator.

Het is niet dat ik dit niet kan oplossen, maar ik zoek een manier waarmee ik wel eenvoudig een testbaar systeem hou.

[Alarmnummer]

Het scripten is idd erg handig om subsystemen aan elkaar te lijmen zonder daar een nieuw systeem voor te schrijven.

vb:

Python:

def consult(kb,fileName):
    try:
        parser.parse(kb,fileName)
    except ParseException, target:
        print target.message
        sys.exit()
    

print 'Prolaw'          
print

kb = KnowledgeBase()
parser = DaParser()

print 'Building shared predicates'
consult(kb,'run/shared.pl')
print

print 'Building object-engine'
consult(kb,'run/object_engine.pl')
print

print 'Building object-program'
consult(kb,'run/object_programma.pl')
print

#op basis hiervan kan de engine geevalueerd worden
engine = DefaultEngine(kb)
contextList = engine.evaluate()

#en natuurlijk de oplossingen afdrukken.
contextList.print(System.out)

Anders had ik helemaal een package systeem in elkaar moeten zetten en daar heb ik op dit moment niet echt de tijd voor.

Ik moet straks conclusies van deze object engine weer gebruiken als invoer van de meta engine. Ik ga dit ook fijn met python doen zodat ik hier wederom geen nieuw systeem voor hoef te schrijven. Zo blijft deze prolog implementatie volledig los van zijn toepassingen.

[edit]
En waar is de Python syntax highlighting??

[ Voor 25% gewijzigd door Alarmnummer op 16-01-2004 09:54 ]