Dimmen met DSL’s

 
25 september 2008

Maak of definieer zo min mogelijk eigen DSL’s. Een van de belangrijkste uitdagingen in de software engineering is het vertalen van problemen omschreven in natuurlijke taal naar een zekere vorm van een model dat dit probleem simuleert en sommige aspecten ervan gedeeltelijk automatiseert. Dit betekent allereerst dat het probleemdomein doorgrond moet worden en daarnaast dat je je een bepaalde modelleertaal eigen moet maken.

Met het creëren van een specifieke taal voor sommige aspecten van dit probleem (of, erger nog, uitsluitend voor het specifieke probleem) werk je in exact de tegengestelde richting. Om deze beschijvingen te kunnen gebruiken dienen consumenten ervan ineens een hele nieuwe taal te leren! Dit komt ongeveer neer op de bouwvakker die voor elk gebouw dat hij moet maken een nieuw soort bouwtekening moet kunnen lezen. Ik vind juist het vertalen van complexe bedrijfsproblemen van specifieke omschrijvingen naar een meer generieke modelleer- of programmeertaal de kerncompetentie van de software engineer.

Hebben we niet al een vrij complete set van talen die ons in staat stelt om dit soort problemen op een meer deelbare manier op te schrijven? Ooit gehoord van UML?


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Development


Reacties (2)

  • @André

    Het maken van een DSL is meestal best een investering, dus daarom ben het ik wel met je eens dat je moet dimmen met DSL’s. Daarnaast kun je ook kijken of er niet al één is voor het domein waarin je bezig bent.

    Die investering kan denk ik echter wel verkleind worden. Daarom wilde ik je deze link even aan de hand doen: http://www.plicity.com/ – ik heb wel eens met hun software gewerkt en dat werkte best snel en prettig. Hoe we het toen gebruikten wat kort gezegd als een soort model-driven CodeSmith.

    Het is nog volop in ontwikkeling, maar inmiddels zijn er al wel een aantal projecten mee uitgevoerd. Ik probeer te regelen dat de eigenaar/CTO van het bedrijf bij ons uit komt leggen wat hij heeft gemaakt.

    Geplaatst op 16 oktober 2008 om 10:06 Permalink

  • Rick schreef:

    Op zich ben ik het met je eens als je zegt dat je zo min mogelijk eigen DSL’s moet definieren. Als er al een (goede) is, kun je beter die nemen. En als die er nog niet is, moet je je afvragen of je het probleemdomein voldoende begrijpt om er een DSL voor te kunnen maken. Want met een DSL maak je tevens een statement: lager dan dit niveau van abstractie hoef je niet te komen. Dat moet je dan wel waar kunnen maken.

    Als het echter wel zo is dat dat lukt, dan ben je met een DSL wel weer verder dan met een generieke taal. Want in die generieke taal moet je libraries leren gebruiken. En omdat de taal generiek is, kun je die veel vaker fout gebruiken dan goed. Met andere woorden: je hebt heel veel mogelijkheden, maar slechts een relatief beperkt aantal wijzes werkt correct.

    Een DSL kan je daarin veel meer houvast geven, volgens mij. En de syntax van zo’n DSL kan ook nog eens veel natuurlijker aanvoelen voor een niet-generieke programmeur met meer specifieke domeinkennis. Denk eens aan SQL, wanneer was de laatste keer dat je echt de database in moest duiken, om daarin iets op te lossen?

    Geplaatst op 27 september 2008 om 10:53 Permalink