{
"$type": "site.standard.document",
"content": {
"$type": "pub.leaflet.content",
"pages": [
{
"$type": "pub.leaflet.pages.linearDocument",
"blocks": [
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.website",
"description": "S1 · Afl. 11 · 1 u 27 min · 18 oktober 2020",
"previewImage": {
"$type": "blob",
"ref": {
"$link": "bafkreicsf5futjpz3qbrkbee3zsqweuj3rknrs6dqfwalj5r23jdrl7xnm"
},
"mimeType": "image/jpeg",
"size": 59484
},
"src": "https://codeklets.nl/episodes/401",
"title": "▶ Beluister deze aflevering"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.text",
"facets": [],
"plaintext": "We hebben dit keer niemand minder dan Meinte Boersma te gast. Meinte legt ons uit wat de kracht van een Domain Specific Language (DSL) is. En hij vertelt ons hoe hij erbij is gekomen om een boek te schrijven over DSLs."
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://kishenpanday.medium.com"
}
],
"index": {
"byteEnd": 63,
"byteStart": 40
}
}
],
"plaintext": "Te gast: Meinte Boersma · Presentatie: Kishen Simbhoedatpanday, Johnny Dongelmans"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.header",
"facets": [],
"level": 2,
"plaintext": "Hoofdstukken"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.unorderedList",
"children": [
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/401?t=22"
}
],
"index": {
"byteEnd": 11,
"byteStart": 0
}
}
],
"plaintext": "0:22 Intro"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/401?t=600"
}
],
"index": {
"byteEnd": 22,
"byteStart": 0
}
}
],
"plaintext": "10:00 Wat is een DSL?"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/401?t=1378"
}
],
"index": {
"byteEnd": 42,
"byteStart": 0
}
}
],
"plaintext": "22:58 Hoe begin je met maken van een DSL?"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/401?t=1773"
}
],
"index": {
"byteEnd": 33,
"byteStart": 0
}
}
],
"plaintext": "29:33 Waarom een boek over DSLs?"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/401?t=2271"
}
],
"index": {
"byteEnd": 43,
"byteStart": 0
}
}
],
"plaintext": "37:51 Hoe verhouden zich MDE, MDA en DSLs?"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/401?t=3470"
}
],
"index": {
"byteEnd": 23,
"byteStart": 0
}
}
],
"plaintext": "57:50 Rants on Twitter"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/401?t=4000"
}
],
"index": {
"byteEnd": 28,
"byteStart": 0
}
}
],
"plaintext": "1:06:40 Developer Dilemma's"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/401?t=4923"
}
],
"index": {
"byteEnd": 19,
"byteStart": 0
}
}
],
"plaintext": "1:22:03 Prijsvraag"
}
},
{
"$type": "pub.leaflet.blocks.unorderedList#listItem",
"children": [],
"content": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/401?t=5080"
}
],
"index": {
"byteEnd": 14,
"byteStart": 0
}
}
],
"plaintext": "1:24:40 Outro"
}
}
]
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.header",
"facets": [],
"level": 2,
"plaintext": "Shownotes"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.text",
"facets": [],
"plaintext": "We hebben dit keer niemand minder dan Meinte Boersma te gast. Meinte legt ons uit wat de kracht van een Domain Specific Language (DSL) is. En hij vertelt ons hoe hij erbij is gekomen om een boek te schrijven over DSLs."
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://www.manning.com"
}
],
"index": {
"byteEnd": 39,
"byteStart": 32
}
},
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://join.slack.com/t/codeklets/shared_invite/enQtNzQ4MTI4MTMxNzY2LWYzNTk0NzE1YzdkNDczYTg1MDBjZDIyZjkzMThmYTBkZTY3ZTBhNDYyOGY4OWQxZGExM2Q5NzA2ZDM0NGY1ZGM"
}
],
"index": {
"byteEnd": 178,
"byteStart": 163
}
}
],
"plaintext": "Een special shout out gaat naar Manning. Zij hebben voor onze luisteraars 35% korting aangeboden op de gehele collectie van Manning. Code kun je verkrijgen via de CodeKlets Slack. DM daar @Kishen of @Johnny. Ben er wel snel bij want de codes zijn 2 maanden geldig!"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.header",
"facets": [],
"level": 2,
"plaintext": "Links"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.website",
"src": "https://twitter.com/_oshell/status/1312206331277840384",
"title": "Rant on Twitter"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.website",
"src": "https://twitter.com/FrancescoCiull4/status/1312684319266279425",
"title": "Follow-up"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.website",
"src": "https://twitter.com/carnage4life/status/1311702322024644608",
"title": "Microservices Tweet"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.website",
"src": "https://strumenta.community/",
"title": "Strumenta Community"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.website",
"src": "https://en.wikipedia.org/wiki/Principles_of_Compiler_Design",
"title": "Wikipedia"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.horizontalRule"
}
},
{
"$type": "pub.leaflet.pages.linearDocument#block",
"block": {
"$type": "pub.leaflet.blocks.text",
"facets": [
{
"features": [
{
"$type": "pub.leaflet.richtext.facet#link",
"uri": "https://codeklets.nl/episodes/401"
}
],
"index": {
"byteEnd": 72,
"byteStart": 60
}
}
],
"plaintext": "Beluister de aflevering en lees het volledige transcript op codeklets.nl."
}
}
],
"id": "6dabdb61-6e6b-40f0-87ed-9faa291ae023"
}
]
},
"coverImage": {
"$type": "blob",
"ref": {
"$link": "bafkreicsf5futjpz3qbrkbee3zsqweuj3rknrs6dqfwalj5r23jdrl7xnm"
},
"mimeType": "image/jpeg",
"size": 59484
},
"description": "We hebben dit keer niemand minder dan Meinte Boersma te gast. Meinte legt ons uit wat de kracht van een Domain Specific Language (DSL) is. En hij vertelt ons hoe hij erbij is gekomen om een boek te schrijven over DSLs.",
"path": "/episodes/401",
"publishedAt": "2020-10-18T23:13:00.000Z",
"site": "at://did:plc:flhrheaiuteqoy65yixudwsv/site.standard.publication/self",
"tags": [
"DSL"
],
"textContent": "Meinte, maak jij gebruik van een muis als developer? Ja, absoluut. En wat zegt dat over jouw development skills? Het schijnt dat ik daarmee automatisch een junior ben. Hallo allemaal, welkom bij een nieuwe aflevering van CodeKlets. Dit keer zitten we alweer in aflevering 11. En vandaag met Meinte Boersma. Meinte werd 13 jaar geleden gebeten door een virus dat de modelgedreven softwareontwikkeling en domeinspecifieke talen veroorzaakt zonder uitzicht op genezing. Sindsdien probeert hij zoveel mogelijk mensen ervan te overtuigen om softwareontwikkeling met behulp van domeinmodulering te doen. Tegenwoordig doet hij dat bij de Belastingdienst. Daarnaast is hij ook nog eens bezig om een mooi boek te schrijven over dit onderwerp voor Manning. Zo Meinte, welkom. Dankjewel, hoi Kishen, hoi Johnny. Hallo, hallo, hallo. Ja, we zijn maar naar remote deze week. Oh, gezellig. Oh ja, goed, de coronaregels weer aangescherpt en dus toch maar besloten om weer een remote opname te gaan doen na onze hosts only jubileum aflevering van een tijdje terug. En we zijn met z'n tweeën vandaag, Kishen en ik zijn samen. En we hebben zoals in de intro Meinte Boersma als gast gevonden. En inderdaad, welkom Meinte. Dankjewel. Hoe is het jongen, hoe heb je het gehad de laatste tijd? Ja, goed. Ik ben net begonnen aan een sabbatical van een half jaar. Dat is extra reden voor feest. Een half jaar om een boek af te maken. En dus ja, dat gaat lekker. En daarvoor, ja, corona is natuurlijk geen feestje aan zich. Maar ik werk er altijd al veel thuis. Dus nu alleen maar meer. Dus dat was ik al gewend. En het fijn is dat bijvoorbeeld de team waar ik tot vorige week bij de Plassendienst bijwerkte nu ook allemaal thuis werkt. En daar ook veel beter in is geworden. Dus ik merk dat daardoor dat mensen gedwongen thuis moeten werken, ze ook effectiever raken als team omdat iedereen thuis moet werken. En niet een gedeelte thuis en een gedeelte op kantoor. En hoe bevalt het ook met de andere collega's bij de Belastingdienst die dus gewend zijn over het algemeen om op kantoor te werken? Ja, voor mij was het niet zozeer een omschakeling. Voor een aantal andere teamleden wel, omdat die echt alleen maar gewend waren om naar kantoor te komen. Wat dan normaal gesproken er wel eens gebeurde was dat, dan was ik met twee andere mensen thuis aan het werk en de rest zat op kantoor. En dan ben je toch een beetje de eenzame roepende in de hoestijn. Of je moet mensen echt gaan bellen als vervanging van ja, ik loop even naar je bureau toe. En nu heeft iedereen hetzelfde probleem. Iedereen moet maar gewoon op de slack of met de most zitten en goed op de mailtjes letten en meetings doen. En daar word je als team volgens mij wel effectiever van. Dat je ook goed snapt van wat het is om als team remote te werken. Ja, ik heb inderdaad ook gemerkt dat een hybride vorm, dat dat veel lastiger te bewerkstelligen is dan iedereen thuis of iedereen op kantoor. Dat was mij inderdaad ook opgevallen. Ja, maar ik heb ook nog een leuk nieuwtje meid die ik met je wilde delen. Ik heb toevallig vandaag een intake gesprek gehad bij de Belastingdienst. Ja, in Apeldoorn. En ja, ik ben er doorheen gekomen. Ze hebben me vanochtend gebeld. Of tenminste, sorry, vanochtend was het interview zoals het ware. Dus er waren zes man die mij dan allerlei leuke vragen stelden. En ja, in de middag hebben ze van de tien, geloof ik, hebben ze uiteindelijk mij uitgekozen. Nou, gefeliciteerd. Leuk. Ja, dankjewel. Dus ik word nog een Belastingdienst collega. Ja, dan zijn we gewoon weer collega's. Leuk, hè? Waar zit jij in het land? Nou, fysiek zit ik in Voorhout. En mijn normale standplaats bij de Belastingdienst is inderdaad ook in Apeldoorn. Al heb ik dat natuurlijk al ruim een half jaar niet meer gezien. En we mogen wel officieel dat gebouw ook helemaal niet in en zo. Dus ik heb dat ook niet meer geprobeerd. En nou ja, die mailtjes ga je nog wel krijgen. Maar ik had echt een beetje elke week een e-mail van ja, ja, het mag nog steeds niet. Ja, het is wel heel jammer, maar je mag nog steeds niet op kantoor komen. Tenzij je echt met een schoeven draaien aan de mainframe mag zitten of zo. Bij wijze van spreken. Maar even terugpakken, want jullie kennen elkaar dus al duidelijk. Ik ken Mijnte nog niet, maar jullie zijn dus al collega's geweest. Ja, zeker, zeker. We hebben beide bij Mendix gewerkt. En ja, Mijnte die kennen we daar heel goed, omdat hij daar het modelgedreven software ontwikkeling. Ja, eigenlijk iedereen de man bracht. Van waarom het zo belangrijk was. Of is eigenlijk, sorry. Je moet natuurlijk niet in passends praten. Maar waarom het zo belangrijk is. En natuurlijk ook onze Mendix developers te helpen in het bouwen aan een modelgedreven software pakket. Ja, precies. Ik ben daar gekomen omdat ik daar met Johan de Haan heb gesproken. Kort daarvoor eigenlijk. En wat Mendix doet is, Mendix maakt een low-code platform. Voor de mensen die het nog niet weten. Mendix maakt een low-code platform. Waarbij we met behulp van grafische modeleertalen een applicatie in elkaar kunnen zetten. En eigenlijk is dat gewoon keihard modelgedreven software ontwikkeling. In de begintijd noemden ze dat zelfs zo. Tegenwoordig niet meer zo. Maar dat heeft dus een hele sterke basis in het modelgedreven software ontwikkeling. En de grap is dat er niet zo heel veel kennis aanwezig was van modelgedreven software ontwikkeling. En software language engineering in het bedrijf zelf. Daarvoor heeft Johan mij aangetrokken om dat binnen bedrijf een goede basis te geven en verder te verspreiden. En wij hebben samen gewerkt aan wat tegenwoordig de Mendix Studio heet, geloof ik. En toen het de Webmodeler heette. En we hebben ook de model share gemaakt en de model SDK en de model server. Dat heet nu allemaal, geloof ik, anders. En model share bestaat niet meer, geloof ik. Nee, nee. Ja, het is een beetje deprecatie. Precies, ja. En ja, modeling services, dat was de teamnaam. En volgens mij is die nog steeds gaande. Ja, ik werk daar nu ook inmiddels niet meer. Maar ja, dat is inderdaad wel een hele goede bestempling geweest, denk ik, voor iedereen. En dat is natuurlijk een van de belangrijkste onderdelen binnen Mendix. Dus ja, dat heeft mij echt een hele goede bijdrage aangeleverd. Hoe ben je daar zo bij gekomen, om die kant op te gaan, eigenlijk? Is dat een interesse geweest van vroeger? Of is het iets een keer wat je tegenkwam? En ja, je zegt zelf in de intro, die had je mooi aangeleverd, dat je bent gebeten door het virus. Kun je daar wat over vertellen? Ja, nou, ik heb wiskunde gestudeerd. En alweer een best van een tijd geleden. En ook uit volle overtuiging, in de zin van dat ik echt het idee had dat ik wiskundige wilde worden en het onderzoek in wilde. Maar tegelijkertijd deed ik ook heel veel programmeren en software ontwikkeling. Dus dat had mijn interesse ook. En toen ben ik uiteindelijk toch niet het onderzoek in gegaan. Ben ik zeg maar gewoon tussen aanhalingshaakjes software ontwikkelaar geworden. Dat was wel leuk, maar ook veel meer van hetzelfde als het ware. En toen werkte ik op een gegeven moment bij Atos, toen nog Atos Origin. En ik kreeg de kans om mee te doen bij een project dat ging om het moderniseren van Legacy. Met de titel Legacy Transformation Factory. Dus dat ging erom om een oude applicatie, bijvoorbeeld in Cobol, te transformeren naar een mooie shiny Java applicatie. En dat was in 2007. En dat is eigenlijk de eerste keer dat ik in aanraking kwam met modelgedreven software ontwikkeling. En dat klikte in één keer. Dat was voor mij echt een aha-moment. Van oh, dit is eigenlijk gewoon hoe ik altijd software wil ontwikkelen. En sinds die tijd is dat dus ook niet anders geworden. En probeer ik zoveel mogelijk mensen dat aan een mand te brengen, of door een strot te duwen of hoe je het ook maar wilt noemen. Oké. En je programmeer jezelf nu nog steeds veel daarmee? Of waar ben je nu het meeste mee bezig eigenlijk in je dagelijkse? Nou ja, op dit moment met boekschrijven. Dus daar zit ook heel veel programmeerwerk bij, gelukkig. Mijn werk bij de belasting zit ook nog heel veel programmeerwerk bij. Hoewel ik daar teamlead ben en dus van nature meer aan het praten ben, met mensen overleggen ben, dat soort zaken. Dus daar valt het wel een beetje mee met hoeveelheid programmeerwerk. Maar ik ben nog steeds veel aan het programmeren inderdaad. Oké, leuk. Ja, leuk. Ja, we hebben meestal een beetje, noem het maar even, een standaard ridultje wat we gewoon elke gast bevragen, vooral omdat je natuurlijk een hele sterke DSL-achtergrond hebt. Voor de mensen die dat nog niet zo snappen, of misschien helemaal niet eens weten wat het überhaupt betekent, als je het zou mogen vertellen, wat is eigenlijk DSL? Nou, ten eerste moeten we hem eens even decorderen. DSL staat voor Domain Specific Language, oftewel in het Nederlands een domeinspecifieke taal. En dat is een computertaal specifiek voor een domein. Dat is natuurlijk een flauw antwoord. Maar waar het om gaat is dat je, ten eerste moet het een computertaal zijn, dus een taal die begrepen kan worden door een computer. Maar belangrijker nog, hij moet begrepen worden door een bepaald domein. En een domein kan zijn een bepaald vakgebied, of een bepaald bedrijf dat iets doet, of een bepaald clubje mensen dat een gemeenschappelijk doel heeft. Dus eigenlijk alles waar je een groep mensen kunt aanwijzen die een specifiek doel heeft met een specifiek taalgebruik, daardoor zal heel snel spaken van een DSL. En dan heb je misschien die DSL nog niet in computervorm, zegt dat als computertaal. Maar dat is dus mijn werk om daar dan wel daadwerkelijk een stuk software tegenaan te zetten, zodat ze, hoe zij al tegen elkaar praten, om dat dan ook daadwerkelijk in de computer te kunnen zetten, en op die manier software te kunnen maken. Uiteindelijk is dan het doel om het probleem dat die mensen, dat dat domein en de mensen in dat domein aan het oplossen zijn, om ze daarmee te helpen met een stuk tooling in de vorm van een DSL, zodat ze met een spreekwaardelijke druk op de knop de software die zij nodig hebben om hun doel te verwezenlijken, ook daadwerkelijk kunnen verwezenlijken. En moet ik het zien als een stuk vertaling? Want je zei zelf, het moet vertaald worden dat de computer het gaat snappen. Zeg ik dat goed? Ja, vertaling of een soort van precisering. Een voorbeeld is wat ik doe bij de Belastingdienst. Daar werk ik aan een product dat heet ALEF. Hij staat voor Agile Law Execution Factory. En wat je daarmee kunt doen is dat als je een wet moet uitvoeren, bijvoorbeeld een blastingwet, inkomstenheffing of iets dergelijks, hoe je dat normaal gesproken doet qua softwareontwikkeling is je kunt niet zo'n wettext pakken en maar gewoon een beetje gaan programmeren. Dat gaat niet werken, dat weten we allemaal. Dus wat er nou gebeurt is dat er een legertje zogenaamde regelanalysten, dat zijn zeg maar businessanalysten met een sterke juridische en financiële inslag, die gaan die wetten live en destilleren daar een heel pakket aan regels uit. En regels hebben dan zeg maar een vorm van als een natuurlijk persoon aan deze en deze voorwaren voldoet dan is die belastingplichtig. En vervolgens heb je nog heel veel andere regels die nou precies specificeren hoeveel belasting je dan moet gaan betalen en zo. En normaal gesproken wordt dat vastgelegd in ontzettend lijvige Word documenten. Dus dan heb je echt honderden, misschien wel duizenden pagina's aan dat soort regels in natuurlijke taal gewoon in een tekstwerker ingetikt. Wat je nou met ons project kunt doen of ons product kunt doen is die regels in plaats van in een tekstwerker intypen in ons product intypen. En dan wordt het gelijk gecontroleerd van klopt wel wat je zegt. Natuurlijk persoon, wat bedoel je daar precies mee? Heeft hij wel een inkomen? Dat soort zaken. Je wordt ook heel erg geholpen bij het intypen. Dus oh, je hebt het over een natuurlijke persoon. Dan moet je waarschijnlijk het ergens ook hebben over een inkomen of je kinderen of je partneren of dat soort zaken. Dus dat wordt allemaal heel erg gecontroleerd. Dus het ziet er nou steeds uit als iets als Nederlands. Het leest ook gewoon als Nederlands. Alleen eigenlijk elk woord in zo'n regelsin is gecontroleerd en heeft een bepaalde betekenis. En dat heeft als gevolg dat dat heel precies is vastgelegd. Dus het ziet er nog steeds hetzelfde uit alsof je het in een woord had ingetikt. Alleen het heeft echt betekenis en de computer kan er echt wat mee. En je kunt er ook echt software mee maken en software mee genereren. Dus dat is ook precies wat die regelandanalysten doen. Ah, precies, ja. Ja, het is eigenlijk inderdaad toch, ja, ik zou het dan zelf inderdaad toch het meest vertalen als een vertaalslag van de regels naar inderdaad de regels die de computer kan begrijpen. Ja, die vertaalslag hoort er zeg maar het vertaalslag hoort erbij. Dat is uiteindelijk de meerwaren die deze aanpak heeft. Namelijk iets dat je in zo'n DSL hebt opgeschreven om die automatisch te kunnen vertalen naar iets dat dat je ook daadwerkelijk kunt executeren, dat je dat daadwerkelijk kunt uitvoeren. Ja, dat stukje genereren. Ja, en het fijne is dat, nou ja, eigenlijk zoals het zelfde is bij Mendix gebeurde dat echt met een druk op de knop rolt daar een stuk software uit waar verder geen programmeur meer aan te pas komt om daar iets aan te veranderen of aan toe te voegen. En dat scheelt dus een heleboel moeite in de zin van je hebt dus niet meer programmeurs nodig die je echt regeltje voor regeltje, dat allemaal gaan lopen vertalen eerst naar code, zodat die code nou vervolgens het goede ding kan doen. Dan moet je die code natuurlijk wel gaan testen en derein gelijken, dus dan gaat er maar gesproken heel veel moeite in zitten en nu sla je die stap eigenlijk in een keer over doordat als je die regels in ons product hebt ingetikt dan weet je gewoon van oké als die uitgevoerd gaan worden dan klopt die uitvoering ook en de regal analisten kunnen dan bijvoorbeeld ook testgevallen tegen aan hangen zodat ze zelf direct kunnen zien van oké er gebeurt al een keer inderdaad het goede mee. Maar wordt dat dan ook nu nog veel gebruikt want ja hoe vaak is er een een wetswijziging in het belastingstelsel en hoe vaak worden dit soort producten dan aangepast? Vaak, heel vaak eigenlijk sowieso wetswijzigingen zijn er nou om de havenklap er wordt steeds wel iets in de belastingwetgeving aangepast dat, nou ja er zijn heel veel belastingmiddelen zoals dat heet er wordt ontzettend veel ontzettend veel kleine stukjes worden er steeds aangepast voor het meest in het oog springende voorbeeld is spinstjesdag daar wordt voor de loonheffing elk jaar er worden weer wat percentages aangepast nou dat is ook een wetswijziging van de wet en dat moet dus ook doorgevoerd worden en is die doorvoering van zo'n van zo'n wetswijziging is dat dan eigenlijk net zo simpel als in in het stuk DSL daar pas je het aan en vervolgens komt er volledig een applicatie uitrollen Wouter, hoe ver is dat geautomatiseerd? Dat is inderdaad precies de mate waarin het geautomatiseerd is. Op het moment dat je de dingen in ons product hebt gedaan, dan is het een kwestie van een percentage aanpassen of eigenlijk beter gezegd zeggen van tot aan Prinsjesdag of tot Prinsjesdag geldt dit percentage en na deze Prinsjesdag geldt dit percentage. En hij herkent ook woorden als Prinsjesdag? Nou herkennen, alles dat je gebruikt moet je wel ergens gaan definiëren. Prinsjesdag is niet helemaal nodig om te definiëren. Dat is meer een procesding of een naam die wij eraan gegeven hebben. Maar bijvoorbeeld wat je typisch terug ziet is een begrip als een natuurlijk persoon, omdat wij zijn natuurlijke personen zoals dat heet voor de wet. Dus daar wordt heel veel aan opgehangen. Nu heb je het voorbeeld bij Belastingdienst genoemd. Zijn er ook andere projecten waarvan jij weet die ook op deze manier software ontwikkelen? Ja, stiekem zijn er heel veel DSL's. Heel veel daarvan die ga je ook nooit zien omdat die namelijk binnen bedrijven worden gebruikt en die komen dat bedrijf nooit uit. Dus wat dat betreft, hoeveel DSL's er zijn? Ik heb echt geen idee. Ik weet dat er heel veel zijn. En ik weet dat er heel veel ontzettend onzichtbaar zijn. Maar ja, één voorbeeld daarvan is al wat ik doe bij de Belastingdienst. Want dat is geen open source. Dus dat wordt alleen binnen de Belastingdienst gebruikt voor een heel aantal projecten. En dat is dus ook alleen bekend binnen Belastingdienst. Hoe dat precies in elkaar zit en hoe je dat gebruikt. Dat is wel heel jammer aan de ene kant. En aan de andere kant, we kunnen het ook niet gelijk open source maken. En ik denk dat er heel veel DSL's zijn waar hetzelfde voor geldt. Namelijk dat ze wel bestaan. Soms weten mensen zelfs dat het een DSL is. Ook niet altijd. Maar dat heel veel van dit soort oplossingen, dat die er gewoon zijn, maar niet bekend zijn buiten de situatie waarin ze gebruikt worden. Ja. En toevallig hadden we daar ook een vraag over rondom open source. Zijn er open source DSL's out there? Ja, er zijn er gelukkig heel veel. Die worden niet altijd zo genoemd. Maar er zijn er echt ontzettend veel. De term slaat eigenlijk ook op heel veel talen die er gewoon zijn. Niet op programmeertalen. Heel expliciet, want een programmeertaal is zo generiek mogelijk. Dus dat is eigenlijk precies het tegengestelde van een domeinspecifieke taal. Dat ding is namelijk domein A-specifiek en heel generiek. Maar er zijn heel veel talen ook binnen software ontwikkeling die voor een specifiek doeleinde gemaakt zijn. Een standaard voorbeeld is bijvoorbeeld Make. Ik weet niet of je wel eens een new make gebruikt hebt. Nou, het is een heel klein taaltje. Je kunt er wel heel veel mee doen, maar als je kijkt wat er aan syntax mogelijkheden in zit, dan is dat best beperkt. En dat heeft een heel duidelijk doel namelijk, gegeven een bak files maakt daar uiteindelijk een executable mee. Andere domeinspecifieke talen zijn, CSS kun je bijvoorbeeld zien als een domeinspecifieke taal. Het heeft een heel duidelijk doel, namelijk defineer layout, defineer styling. Het heeft ook een hele simpele syntax eigenlijk. Er zit vrij weinig in. Dat is eigenlijk wel een hallmark van DSL, dat de syntax is vrij beperkt. De notatie is domeinspecifiek. Er is een specifiek doel. En dan zit je al vrij snel op een DSL. Maar wat eigenlijk nog veel interessanter is dan dit soort technische DSL's, wat ik dan business DSL's noem, dat zijn dus de DSL's die echt in een business gebruikt worden, die echt door niet-developers gebruikt worden, die wel een interessant probleem hebben om op te lossen, waarbij het heel erg kan helpen als je ze tools geeft om dat via een computer te doen. Ja, dus in plaats van de hoofden te laten zweven, dan programeer je, ja, noem niet programeeren, maar je regelt het zeg maar in, dat ook heel veel stukken van hun kennis ook daar natuurlijk in de DSL gewaarbord wordt. Exact, exact dat, ja. En de grap van de domeinexperts is, het zijn overdag mijn echt experts. Die mensen zijn hartstikke slim en ze hebben misschien geen programeerachtergrond. Maar ze krijgen het echt wel voor elkaar. Dus je ziet ook heel veel mensen die die dingen in Excel doen. Ik grap wel eens, Excel is de meest gebruikte programeer- en modeleeromgeving in de wereld. En dat vind ik nog steeds ontzettend waard. Je ziet gewoon mensen die echt ontzettend moeilijke, complexe dingen in Excel maken. Ja, en dat is meestal bubbelt daar een soort met van DSL onder de oppervlakte. Ja, precies. Ja, dat is een, ja, precies. Dat is echt gewoon een tool wat gebruikt wordt nu om het te bewaken zeg maar, die kennis en die expertise. Ja, dat is wel leuk om te zien. En even kijken hoor, want ja, iets wat op mij ook altijd, de vraag die ik altijd bij mij opborrelt als ik zoiets lees en dan begin ik het interessant te vinden. Maar stel nou voor dat ik zou beginnen, hoe begin ik met zoiets? Met het maken van een DSL, dat bedoel je. Het belangrijkste is dat je ziet of realiseert dat er een domein is met een specifiek doel waarmee je kunt helpen door een DSL te maken. Dus als je bijvoorbeeld kijkt naar, iemand heeft iets gemaakt in Excel, iets heel ingewikkelds. Dat is voor mij meestal een teken van, oké, Excel is niet de meest briljante tool voor programmeerwerk. Het is ontzettend handig om snel iets in elkaar te kunnen zetten dat je veel feedback geeft over wat je aan het doen bent. Maar uiteindelijk kun je daar niet echt de software mee maken. Maar er zit wel heel veel in de tool zelf om dingen te realiseren. Dus er zit een bepaalde mate van programmeermogelijkheden in. Je kunt formules maken en dergelijke. Dus als je iets groots en moeilijks in Excel gemaakt hebt, dan is de kans heel groot dat je met een DSL een betere softwareoplossing mee kunt maken. En waar je dan mee zou moeten beginnen is om te kijken wat zijn je onderliggende concepten, je basisconcepten, je basisprincipes die jij in je Excel sheet hebt gezet. Dus als je financiële dingen hebt, bijvoorbeeld je doet je financiële administratie in Excel om maar iets te noemen. De basisconcepten die je daar heel makkelijk in zou kunnen herkennen is waarschijnlijk rekening, mutatie, facturen, dat soort zaken. Hoe heb je afschrijfbare aanschaffen gedaan, dat soort zaken allemaal. Dat zullen zeker de ZZP'ers onder ons herkennen, dat soort dingen. Dus dat zijn dan basisconcepten waar je wat mee kunt doen. En leent elke programmeertaal daarvoor, om zoiets te bouwen? Ja, in principe wel, maar sommigen zijn wel wat geschikter dan anderen, natuurlijk. Want waar je uiteindelijk je domainexperts het meeste mee helpt is een goede interface, een goede gebruikersinterface, om jou DSL Proza, noem ik het dan vaak in het Nederlands, mee in te kunnen tikken. Sommige programmeertaalen helpen je daar wat meer in dan anderen. Bijvoorbeeld in het boek gebruik ik Javascript, want Javascript zit in een browser, en in een browser is het best makkelijk om fatsoenlijke UIs te maken. Oké, mooi. En ik denk ook TypeScript dan? Ja, in het boek toevallig niet. Ik had het graag gebruikt, maar ik heb maar dan eindig hoeveelheid pagina's, dus ik moest een afweging maken tussen hoeveel pagina's investeer ik in dingen met beeld van TypeScript uitleggen en dus misschien potentieel iets over TypeScript moeten uitleggen. Versus als ik het nou gewoon in zo'n vanille mogelijk Javascript doe, hoeveel mis ik dan van TypeScript? Ja, dat is ook zo. Interessant. Iets wat ik me nu afhaag, de laatste heel wat jaren is ook steeds meer machine learning en AI in opkomst. Zie je dat ook terug bij dit soort vrij domein specifieke oplossingen? Dus, of moet het eigenlijk altijd echt heel erg specifiek gedefinieerd zijn en blijft het daar ook bij? Nou, dat laatste sowieso, want dat is juist de kracht van DSL's, dus het feit dat je dingen juist zo strikt en zo strak hebt vastgelegd, dat maakt het juist mogelijk om ook daadwerkelijk dingen te genereren. Wat het ook mogelijk maakt is juist dat het heel duidelijk is vastgelegd van wat hetgene is wat er nou juist moet gebeuren. Bijvoorbeeld, je gaat niet een stuk belastingwetgeving met behulp van een neural netwerk uitvoeren. Dat doe je sowieso niet, omdat je moet kunnen uitleggen wat er gebeurd is. Niemand gaat akkoord met van ja, we hebben jouw belastingaangifte door een neural netwerk gehaald en dit getal kwam eruit, dus daar moet je het maar mee doen. Dus de uitlegbaarheid van wat er gebeurt is heel belangrijk en DSL's helpen daar juist bij omdat op een voor de MijnExpress heel begrijpelijke manier staat vastgelegd van, dit is hoe een bepaalde berekening gaat en dan kun je tot een bepaalde precissing komen, dus dat kun je gaan debuggen als het ware en dat kun je debuggen met behulp van de taal en de concepten die de MijnExpress gewend zijn. Waar ik wel een mogelijkheid zie voor AI en machine learning is in hoe je dan uiteindelijk tot die precieze omschrijving met behulp van een stuk DSL Proza komt. En daar zou AI best wel wat kunnen helpen, dat is dan wel onderzoek dat allemaal in de kinderschoenen staat, maar je kunt je bijvoorbeeld best voorstellen dat het voor een AI oplossing makkelijker is om datgene wat de AI leert, leert tussen aanhalingshaken of herkent in een bepaalde situatie om daar een stuk DSL Proza voor te genereren dan bijvoorbeeld voor een algemeen stukje programmeertaal. We hadden laatst die, hoe heet dat ding nou? Die G3T. Dat je maar gewoon een beetje begint te tikken en dat dat ding met wat programmeertalcode of wat algemene programmeertalcode terugkomt en zo, of een geïmplementeerde UI. Dat soort dingen, dat is een soort van gimmick, maar ik denk als je dat als doel maakt om daar een stuk DSL Proza van te maken dat dat ook voor domeinen specifiek best heel nuttig kan zijn. Dus in dit geval is het domein een UI met wat knoppen en wat invoervelden als het ware. Dus dat is ook al een soort van DSL. Als je dan een ander domein kiest, bijvoorbeeld een regel die je afleid uit belasting werd gegeven, dan zou je dat misschien ook wel kunnen doen. Ja, hartstikke mooi. Je noemde het net zelf ook al, ik heb het ook in de intro geroepen. Ja, je bent toch begonnen om een boek te gaan schrijven. Waar kwam dat ineens vandaan? Nou, ik wilde dat eigenlijk al een tijdje. En toen kwam Manning Publications mij op het spoor. Dus die hebben mij een mailtje gestuurd van zoals we praten over het schrijven van een boek. En wil je dat, like je dat wat? Ja, graag was twee keer het antwoord. Dus ja, zo doen we. Dan ga je bij hun eerst door een proces heen. Dus je moet een pitch schrijven, dat is ook heel gezond. Gewoon om even uit te leggen van waarom moet dit boek komen? Waarom is dit boek er nog niet? Zijn er andere soortgelijke boeken? En waarom doen die nog niet wat jouw boek wel gaat doen? En waarom ben jij geschikt om dit boek te schrijven? Dat soort vragen allemaal. Hoe zijn ze bij jou gekomen, denk je? Heb jij een openbaar blog of zo? Of is dat via via? Hoe loopt zoiets? Ja, ik denk gewoon internet namens de bekendheid. Ik weet het niet eens precies. Ik ben vergeten te vragen hoe ze nou precies bij mij uitkwamen. Maar ja, ik heb een blog. Ik heb best wel vaak op bepaalde conferenties dit gebied rondgelopen. Zoals CodeGeneration. Zelf een aantal keer met een aantal mensen een conferentie georganiseerd. Dus mijn naam is op het internet best wel verbonden met dit onderwerp. Dus ja, toen zijn ze blijkbaar op zoek gegaan. We willen dat iemand een nieuw boek schrijft over DSL's. En toen kwamen ze bij mij uit. Want is het een onderwerp waar veel over geschreven is in het verleden? Of nu nog steeds wordt? Ja, er is eigenlijk best wel heel veel geschreven. Maar wel heel veel academisch. Het bredere veld van software language engineering, SLA, dat is eigenlijk de meer officiële term waar DSL's binnenvallen. Dat is met name op universiteiten best wel een vrij actief onderzoeksgebied. En ook al tientallen jaren lang. Eigenlijk zitten DSL's al tient jaren lang in een soort van wederkerende Gortner-hype cycle. Dat is ook het frustrerende van dit vakgebied. Dus op zich, er zijn best wel boeken over. En met name in het academische veld zijn er boeken en zijn er heel veel artikelen over. Bijvoorbeeld een vrij bekend boek is het Dragon Book. Van die man ook weer, Aho en Hopcroft. Die gaat in de show notes? Ja, het boek is al een jaar of 30 oud. Bijna 40. Het wordt nog steeds best wel gebruikt binnen universiteiten. Hij heeft ook een behoorlijk grote oplage gehad. Dus dat is best wel een bekend boek. Maar het is ook gelijk al weer heel oud. Het is ja, bijna 40 jaar oud. Het eerste boek en het tweede boek is bijna 30 jaar oud. Dus het is heel erg low level. Er wordt heel erg over parsing gepraat. En hoe je dan bijvoorbeeld bytecode kunt gaan. Of machinecode zelfs kunt gaan genereren voor je processor. Dat soort zaken. En dat is niet meer het niveau waar we tegenwoordig software op maken. Dus ja, een nieuw boek was best wel weer eens tijd. Dat heeft Manning dus ook gedacht. En jouw boek is dus ook veel meer hands-on. En je kan het bij wijze van spreken meedoen. Ja, al leesend kun je mee programmeren en je eigen DSL gaan maken. Ja, absoluut. Dat is ook precies de insteek. Ik verrijs eigenlijk niet meer dan dat je wat JavaScript gedaan hebt. Of dat je wel eens wat met JavaScript ontwikkeld hebt. Of dat je je dat snel eigen kunt maken. En dat je misschien een beetje webdevelopment gedaan hebt. Of het eigen kunt maken. Dat is zeg maar het minimum. Dus je hoeft echt niks al te weten van software language engineering... voordat je het boek begint te lezen. En ga je dan een fictieve use case... ja, val je die aan door middel van een DSL? Ja. Ja, dus we beginnen met het huren van een auto. Wat komt daar bij kijken? Dus in dit geval is het domein een autoverhuurbedrijf. En de domeinexperts die daar zitten, die bedenken... Nou, als iemand een auto wil huren, hoe bereken je dan de huurprijs? Zijn er kortingen te vergeven? Moeten we rekening houden met of iemand schadevrije jaren heeft? Moet zo iemand een verzekering afnemen of hoeft dat niet per se? Dat soort dingen allemaal. Heel interessant. Dus daar gaat heel veel bedrijfslogica, heel veel businesslogic in zitten. Dus dat is de use case waar ik mee begin. Het is wel grappig eigenlijk, zoals je het nu ook uitlegt. Eigenlijk zijn er zoveel mogelijkheden om een DSL te implementeren. Daar denk je niet altijd over na. En heel vaak doe je het volgens mij ook zonder dat je erover nadenkt. Ben je in een DSL aan het implementeren? Ja, heel vaak doe je inderdaad traditionele softwareontwikkeling. Dus bijvoorbeeld bij zo'n autoverhuurbedrijf bedenkt je op een gegeven moment van ja, we kunnen niet meer op papier of in Excel af. Dus dan moeten we een softwarebedrijf voor gaan inschakelen. En als je op de traditionele manier doet, dan ga je requirements verzamelen. Dat soort zaken. En dan gaat iemand een echt programma van maken. Echt de UI maken, database erachter hangen. Dat soort zaken allemaal. Dat kan best oké werken. Alleen dit soort dingen verandert de hele tijd. Je verandert iets in regelgeving, zodat je andere voorwaren moet gaan stellen aan het verhuur van een auto. Een recente voorbeeld. Mag deze persoon überhaupt wel in deze auto zitten? Dan moeten we niet eerst vragen stellen over of hij klachten heeft. Want als hij klachten heeft, dan mag hij niet eens op de kantoor komen hoeveel mondkapjes moet je meenemen? Dat soort dingen. Dat wil je allemaal erbij gaan verwerken op het moment dat je een autoverhuurbedrijf hebt. Dus daarvoor moet je je software aanpassen. Dan kun je weer terug naar die software developers die die software gemaakt hebben. Maar het is natuurlijk veel fijner voor een autoverhuurbedrijf als ze dat zelf kunnen doen. Dus de vraag is dan meer aan de software developers. Dus maak voor ons een DSL zodat we dit soort dingen zelf kunnen doen. Precies, ja. Ja, ik moet ineens denken aan business logic-achtige architecturen ook. Dus dat je de business logic als het ware gewoon door de business ook daadwerkelijk laat programmeren weer. Maar uiteindelijk komt het wel daar op neer. Exact, ja. Het woord programmeren moet je niet noemen. Bij business mensen, dat is... Ja, nee, dat inderdaad. Dan rennen ze hard de andere kant op. Dat is alleen maar voor nerds. Ja, echt inderdaad. Dat soort reacties heb ik heel vaak gehad. Dat was niet bon ton om het zo te noemen. Noem het maar configureren of modelleren of specifiseren of zoiets maar absoluut niet progeren. Maar inderdaad, uiteindelijk is het tekenzak tenzelfde. Het verschil is natuurlijk wel, je geeft ze tooling en een taal waarmee ze dat ook werkelijk zelf kunnen doen. Ze gaan uit hun expertise, maar zonder gelijk een hele programmeursopleiding te moeten doen. Ja, precies. Nou, mooi. Ik denk dat we toe zijn aan de vragen uit het publiek. Vorige week hebben we een post geplaatst in onze chat om wat vragen te summeren. We hebben er uiteindelijk eentje van Saber ontvangen. Die vond ik zelf persoonlijk ook wel interessant omdat, ja, dat is toch wel wat onduidelijkheid hier en daar. Maar Saber, die vraagt zich af of jij zou kunnen uitleggen wat het verschil is, of in ieder geval de verhouding misschien is tussen model-driven engineering, MDA, model-driven architecture, MDA, en DSL's. Ja, dat is een hele interessante vraag. Ik moet even proberen om daar niet een enorm lang antwoord op te geven, want hier kun je heel lang om door. Ten eerste maar even de MD-afkortingen. Ik gebruik zelf meestal de term model-driven software engineering of zelfs model-driven software development om het echt te beperken tot het maken van software. Want MDA in hele brede zin gaat over het gebruiken van modellen en je zou dat prescriptieve modellen kunnen noemen, dus modellen die echt voorschrijven hoe iets in elkaar moet zitten om engineering te doen. En dat hoeft niet alleen software te zijn, maar dat kan bijvoorbeeld ook bruggen, vliegtuigen, gebouwen, dat soort dingen zijn. We hebben in Nederland bijvoorbeeld talers zitten in de defensieindustrie. En ik weet toevallig dat die best wat aan model-driven engineering doen, dus echt apparaten specificeren met behulp van modellen. En dus niet alleen CADCOM, de bouwtekeningen en dergelijke, maar ook hoe zo'n ding dan gemaakt moet worden. Zodra er software in zit, hoe software componenten in elkaar zitten, maar ook hoe die software componenten dan met de fysieke hardware interacteren. Dat soort modellen, dat is echt model-driven engineering, omdat er meer dan alleen software aan te pas komt. Andere bedrijven zoals wat vroeger OC heette tegenwoordig Canon, begrijp ik, de maker van kopierapparaten, doet ook aan model-driven engineering, specificeren van machines en dan uiteraard ook een heleboel software erin, maar ook dat echt wel uit specificeren van machines. ASML doet aan model-driven engineering. Dus dat is eigenlijk het verschil tussen model-driven engineering en model-driven software development. Model-driven architecture is inderdaad een heel verwarrend verhaal. Eigenlijk is model-driven architecture een soort met van merknaam van de object management group. Object management group is een groep van organisaties, consortium eigenlijk, die bijvoorbeeld UML definiëren en OCL en SysML, allerlei dat soort modeleerd talen. En die hebben op een gegeven moment bedacht van, ja, we gaan ook een model-driven engineering of een model-driven software development standaard bedenken. En dat hebben ze model-driven architecture genoemd. Maar dat is eigenlijk gewoon een convention, een convention die uit dat clubje is voortgekomen, echt bedacht is door dat clubje. En het probeert heel precies voor te schrijven hoe je dan model-driven software development of model-driven software engineering zou moeten doen. Dus dat begint dan bij een... Kijken, de term is, geloof ik, platform-independent model. Ja, dus een begin met een platform-independent model. Dan maak je dan een platform-specific model van. En dan ga je nog een transformatieslag verder dan. Dan ga je dat lekkerskitje wat code genereren en zo. En dat is een heel strak keurslijf. En ik heb nog nooit gezien dat dat werkte. Oké. Waarom denk je dat? Het is te strak. Het probeert je heel erg in zo'n keurslijf te duwen van ja, je moet het per se op deze manier doen. En dat werkt in de praktijk niet. Want die hele convention moet je best wel goed kennen om het volgens de, nou ja, door hun opgestelde spelregels te kunnen doen. Doe je dat niet, dan wordt het al snel wat link. Dus mijn ervaring is dat je het veel beter wat meer kunt loslaten. En gewoon als principe houdt van dingen moeten uit een model komen. Of dingen moeten vanuit DSL Proza gegendereerd worden. En dat is een veel gezondere insteek die je veel meer vrijheden geeft om ook daadwerkelijk het werk aan te krijgen. Oh ja, en een van de dingen van MDA is dat alles in UML moet. En UML is heel erg geschikt om mooie tekeningetjes op cv'tjes te maken. Maar dat is niet zo geschikt om er echt software mee te gaan specificeren. Dus wat je vaak ziet als je UML gebruikt is dat je van die profiles gaat gebruiken en stereotypes. Maar wat je dan eigenlijk doet is je maakt in UML een DSL. Dus om het even terug te grijpen naar dat eerdere verhaal over ja, als je nou, je hebt iets gemaakt in Excel, hoe maak je dan een DSL van? Nou, dan moet je concepten gaan herkennen. Als je iets in UML gemaakt hebt en je hebt veel stereotype gebruikt, dan zijn die stereotype eigenlijk altijd de concepten die je eigenlijke kennis vormen of coderen. En dan heb je, nou, de conclusie eigenlijk, je hebt UML helemaal niet nodig, maar je kunt gewoon veel beter een eigen DSL maken die direct op het niveau van die concepten praat en UML helemaal overbodig maakt. Nou, zou je zeggen dat de documentatie van zoiets als model-driven architecture wel goed is om te kennen of is een keer gezien te hebben? Dus dat je een beetje de concepten erachter hebt gelezen een keer? Nou, ik zou zeggen dat als mijn boek klaar is dan zeker niet, want dan lees je gewoon mijn boek en dan weet je ook wel wat de belangrijkste concepten zijn om na te kunnen denken over concepten. Is dat ook misschien een reden waarom UML toch anno, anno nu een beetje een stille dood gestorven is in software development land? Ik denk dat dat er heel veel mee te maken heeft inderdaad. Er zijn ook wel andere oorzaken. UML is een ontzettend grote modeleertaal. Dus je kunt er alles mee, maar je kunt ook alles op andere mieren doen. Dus wat dat betreft is het een soort met van programeertaal waar geen runknop op zit. Dat we zeggen, het heeft wel die complexiteit en je kunt alles op tien verschillende mieren doen en je moet honderden constructies moet je kennen om er iets mee te kunnen doen. Maar het heeft geen runknop. Tenminste, standaard UML niet. Er zijn wat UML dingen waar je wel dat werkelijk een runknop voor kunt maken. Maar UML is een algemeenheid. Het wordt nog wel veel gebruikt, maar het is zo moeilijker om zo'n runknop te maken. Dat is het probleem. Ik heb het inderdaad wel gekregen op de informatica opleiding. Inderdaad, UML en RUP, een beetje de ouderwetse manier van werken noem ik het altijd maar. Maar het heeft me ook echt nooit een soort gegrepen als dit is echt nou een goede manier om van een gedachte groet of een bepaalde probleemstelling om te gaan naar een daadwerkelijk software applicatie. Inderdaad, dat is ook mijn ervaring. Het heeft eigenlijk ook, als je weer kijkt naar het domein en of het nou domeinspecifiek is of niet, het domein is ook heel duidelijk plaatjes maken voor architecturen van software. Niet het specificeren van software aan zich of het specificeren van het probleemdomein dat een stuk software nodig had. Dus het gaat heel erg eigenlijk in op, nou ja, als je een mooi plaatje kunt maken voor hoe je het wilt gaan oplossen, dan zou het misschien een beetje kunnen helpen. Maar je daadwerkelijke domein-experts, dus bijvoorbeeld de mensen die bij een autoveruurbedrijf moeten gaan specificeren waarom jouw vijfdeurs auto drie euro lurer is dan jouw driedeurs auto per dag, ja, daar gaat het niet voor helpen. Ja, ik had ook Bernard, een van onze hosts, die had ook een mooie link gestuurd, wel naar Wikipedia pagina, maar wel een interessante quote. Dus eigenlijk wat jij nu, dus deze hele aflevering eigenlijk duidelijk maakt, is dat het vooral voor domein-experts is, waarmee ze zelf gemakkelijk kunnen begrijpen hoe het domein moet functioneren in software en waarmee ze kunnen valideren, aanpassen en dan natuurlijk ook zelf een domein-specifieke, domein-specifieke programmeertaal als het ware bouwen, maar er staat wel ergens op een regeltje, however, this is seldom the case, dus voor de Nederlanders tussen ons, alhoewel het toch niet altijd het geval is. Wat vind je daarvan, dat het zo op Wikipedia staat? Dat staat bij de omschrijving van de Wikipedia pijl van de DSL, ah, interessant, die was me niet zo opgevallen daar. Ja, ik weet niet of het seldom the case is, ik denk dat er, of het zeldzaam is dat dat voorkomt, er zit wel een bepaalde, bepaald maximum dat je kunt doen, dus je moet wel heel erg goed scopen, heel goed beperken wat je domein is. Om bijvoorbeeld, nou weer eventjes, dat autoveruurbedrijf, dat zou ik heel erg scopen op het beschrijven van hoe een, hoe een prijs tot stand komt, of een spraak is van kortingen, of de echte bedrijfslogica erachter, maar ik zou bijvoorbeeld niet gaan proberen te specificeren in, in zo'n DSL hoe je data bezigheid moet gaan zien. Of hoe bepaalde knopjes op, in de UI, heel specifiek moeten gaan werken. En daar zul je uiteindelijk toch nog wel wat programmeurs voor nodig hebben. Maar wat je wilt is dat, zeg maar, de dingen die de Minexpress zelf kunnen specificeren, en goed kunnen specificeren, dat ze dat kunnen doen. En dat je de rest via traditionele of meer traditionele software development oplast. Ja, want ik zat inderdaad ook met jouw voorbeeld een beetje te denken. Stel dat het autoveruurbedrijf vanwege de lage rentes toch meer marge moet gaan maken. Ja, dan is het in het aanpassen van zo'n percentage is vrij makkelijk gedaan. Maar stel dat de Nederlandse overheid met nieuwe regelgeving komt en elke bestuurder die een auto wil huren moet vervolgens een extra document gaan overleggen. Ja, dat weet je van tevoren ook niet tijdens het maken van zo'n DSL. Dus ja, dan zal er uiteindelijk toch ook een wijziging moeten plaatsvinden in die DSL. Ja, klopt. Ja, dus het kan heel goed zijn dat door veranderde requirements dat je ook echt de DSL moet aanpassen of vooral moet uitbreiden met nieuwe concepten. Dus bijvoorbeeld een concept dat zegt er moeten bepaalde documenten aangeleverd zijn en dat je dan ook kunt specificeren welk document dat is. Dat is inderdaad heel goed mogelijk. Wat wel het grote voordeel is van zo'n aanpak dan is dat je zo'n concept maar één keer hoeft te introduceren en ook maar één keer hoeft uit te leggen aan bijvoorbeeld de code generator hoe daarmee om te gaan. Vol, wat ook een interessant aspect van DSL is hoe test je door via DSLs gegendererde software. Nou ja, dat is voor Kishen, voor jou is dat natuurlijk zal altijd wel een hot topic blijven, denk ik. Ja, het is echt iets waar het keeps me up at night. Precies, ja. En de grap van zo'n DSL is dat je hebt een beperkt aantal constructies sorry, een beperkt aantal concepten waar vervolgens een generator mee aan de haal gaat en daar gewoon code uit genereert. Maar dan weet je wel dat elke keer als zo'n concept gebruikt wordt dan komt daar grotendeels dezelfde of komt er in principe steeds dezelfde code uit. Dus heel veel van die code hoef je ook maar één keer of een aantal keer, een aantal representieve voorbeelden hoef je maar te testen. Dus als je bijvoorbeeld een concept hebt waar een tabel uitkomt uiteindelijk in de database en een paar formulieren op een scherm, dat soort dingen. Dus gewoon een stukje data om op te slaan. Nou ja, je gaat er niet meer voor elke instantie van zo'n concept dus elke keer dat je bijvoorbeeld zo'n tabel op die manier defineert ga je meer testen van oh, was de tabel wel goed aangemaakt en kan ik er dan wel dingen in stoppen en dergelijke kan ik er wel dingen uithalen en klopt het formulier dat op het scherm staat klopt dat dan wel met wat er in de database staat dus je hebt zo'n hele integratietest van ga naar een schermpje, vul daar dingen in druk op de Submit-knop kijk of er dan iets in de database terechtkomt en kijk of er dat goede ding in terechtkomt. Dat doe je dan een paar keer maar dat doe je niet meer voor elke tabel in je database want na die paar keer weet je wel van ja, die generator gaat daar echt niet meer, gaat er wel de goede dingen doen. Ja, het wordt een beetje een slager die zijn eigen vlees keurt dan eigenlijk, je verwacht, je zet er variabele A in en ja, dan verwacht ik ook wel dat variabele A in de database terechtkomt dat maakt dan niet uit of het variabele B wordt Je keurt je, iemand anders dan de slager keurt het vlees een paar keer maar op een gegeven moment dan heb je wel het vertrouwen dat bij het volgende stukje vlees dat we op dezelfde manier specificeren dan gaat het ook echt wel goed. Ja, dat doet de slager zijn werk wel goed. Ja, het risico wordt steeds minder groot. Dat het fout gaat. Dan moet je dus inderdaad ook daarin je teststrategie of hoe je het ook wil noemen. Dat pas je gewoon daarop aan. Ja, je merkt dat je vrij snel op een hoger niveau kunt testen dus je hoeft een paar dingen niet meer de hele tijd in detail te testen of tenminste heel veel dingen hoef je niet meer in detail te testen maar kun je veel meer naar integratieachtige testen kijken. Ja, dat wilde ik net zeggen. Dus dan ligt het risico juist meer in integratie met de rest van de wereld. Ja, en wat ook heel interessant is met testen en DSL's is dat bijvoorbeeld iets dat we ook doen bij de Belastingdienst is dat Domainexperts zelf test kunnen schrijven. Dus die kunnen bijvoorbeeld zelf specificeren van gegeven en zo naar zo'n situatie een Nederlandse persoon 43 jaar, drie kinderen zes en zes inkomen reken maar eens uit wat er dan aan de belasting betaald moet worden. En dan kun je dus kijken van komt er het goede uit? En je kunt ook blijven kijken komt er het goede uit? Want die test kun je ook weer uitgenereren na het daadwerkelijk draaiende test. Dus je begint met een test die je gewoon in je DSL gespecificeerd hebt dus als DSL Proza gespecificeerd hebt naast je regels voor belasting of auto verhuur en de generator maakt dan naar uiteindelijk unit test voor die dus gewoon als normale test kunnen draaien. Ja, het is een heel leuk en leerzaam concept voor mij om ik moet zeggen ik zat eigenlijk zelf altijd een beetje in die hoek van ik denk in programmeertalen en ik ben eigenlijk altijd bezig met programmeertalen. Maar het is wel leuk om eens een keer zo gesprek te hebben met iemand die echt heel veel kennis hierover heeft zoals jij om er ook net even op een soort hoe moet ik dat uitleggen een soort meer helikopter view er naar te kijken dus echt meer naar het probleem te kijken en hoe kan je dat oplossen door zoiets als een DSL? Ja, een van de vragen die we hadden was ook hoe populair is dit? En het antwoord is in een bepaalde zin is het heel erg populair maar in een andere zin ook helemaal niet heel weinig mensen kennen de term DSL heel weinig mensen kennen de term model driven of model based en dat is wel heel jammer want je kunt er wel heel veel mee doen en de gewoondheid in onze IT industrie is wel een beetje om van nou ja goed programmeer te houden daar kennen we er een paar van we weten hoe we applicaties maken dus elk probleem dus dat is de grote hamer die we hebben dus kom maar met je probleem dan pakken wij die grote hamer en dan gaan wij wel voor je programmeren gaan wij wel software developpen En ja, maar misschien is dat niet de beste hamer die je hebt. Misschien moet je wel gewoon een heel andere soort hamer, misschien ook een soort van kleinere, maar scherpere hamer aan je domain express, aan de mensen die het probleem daadwerkelijk hebben, geven en het daarmee vervolgens zelf laten oplossen. In plaats van dat jij altijd maar met die enorme toolbox, met die enorme hamerzaak komt. Ja, want het blijft elke keer een vertaalslag die natuurlijk ook vaak wel eens misgaat. Een soort van Chinese whispers, dus dan kan me nog wel herinneren toen ik bij Stater zat, ja dat ging allemaal over hele ingewikkelde hypotheekberekeningen. En ja, weet je, daar zitten ook veel consultants over over de algemene en die hebben allemaal andere ervaringen en kan zo ineens zomaar verkeerd geïmplementeerd zijn. En wat ik dus van jou hoor, is dat je toch ook die kracht van die domeinexperts gewoon beter tot z'n recht kan zetten in het systeem door ze het inderdaad iets aan te bieten, waardoor ze zelf in staat zijn om die regels vast te leggen en door te gaan zonder de vertaling elke keer te doen. Exact, ja, je slaat echt de vertaalslag over of eigenlijk doe je de vertaalslag één keer, maar op een hoge niveau is een afgezaagd woord, maar je probeert het een één keer voor alles wat je tegen kunt komen te doen. En dat is wel moeilijker. Dat is echt vooral een stuk moeilijker, maar dat is ook een heel stuk interessanter dan weer een schermpje maken en dan weer een tabelletje erbij maken, dat soort werk. Ja, precies. Nou, hartstikke goed. Ja, we zijn nu inmiddels al door de vragen heen. In ieder geval heel erg bedankt dat je ons hier even te woord in wilde staan. Ik denk dat het in ieder geval van mij heel erg duidelijk is geworden wat de verschillen zijn tussen model-driven engineering, architecture en DSL's en de verhouding daarvan. Nou, ik stel voor dat wij nu doorgaan naar het volgende onderdeel van onze podcast. En ja, dat is eigenlijk iets wat in het leven is geroepen na de tiende aflevering. Dus we dachten, joh, we houden dat gewoon even erin. En dat heet de Rance on Twitter. Inclusive sound effects, wow. Daar heb ik echt de hele avond op gestudeerd. Ja, dit had je nog niet verteld dat je dit ging doen. Nee, cool hè. Echt een mooie verrassing. Ik ben trots op je. Dank je wel, dank je wel. Nou, de Rance on Twitter, maar is heel Twitter niet een grote rant? Of heb ik dat dan nu verkeerd? Tegenwoordig wel, ja. Ja, ik moet zeggen, ja, ik heb de vorige aflevering ook al verteld, maar ja, het is toch niet goed voor mijn bloeddruk, die website. Maar misschien zit ik een beetje op de verkeerde kant dan. Ja, hangt een beetje af wie je allemaal volgt. Ja, we hebben het in de Slack kanaal ook even over gehad. Ja, iets wat mij deze week toch wel een beetje opviel was die muis gebruiken van developers. En je meint, maak jij gebruik van een muis als developer? Ja, absoluut ja. En ja, wat zegt dat over jouw development skills? Nou ja, het schijnt dat ik daarmee automatisch een junior ben. Maar gebruik je dan een touchpad of gebruik je een echte muis? Ik gebruik een echte muis. Ja, dat is denk ik gewoon een beetje persoonlijke voorkeur. Een touchpad kan ik best mee overweg, maar uiteindelijk vind ik een echte muis toch wat handig aan werken. Maar gebruik je Mac of niet? Ik gebruik Mac, ja. Heb je dan ook zo'n Magic Mouse? Ja, ja, ja, ja. Ja, en dat vind ik heel prettig, want daarmee kun je, nou ja, zoals je wel weet Johnny, je kunt links, rechts en omhoog naar beneden, omhoog en omlaag scrollen. Met name dat links en rechts is vaak best praktisch om Windows goed te centreren, om een goede plek op te zoeken in je code enzo. Ja, ja, ik moet zeggen dat is het enige wat ik een beetje mis, want ik ben een tijd, even kijken, een jaar geleden of zo ben ik overgestapt van een Magic Mouse naar zo'n Logitech MX Master, met name gewoon vanwege kramp in mijn handen. Dus ja, een beetje lichte RSI klachten en toen dacht ik nou, laat ik dan toch maar iets ergonomisch verantwoordelijk muis aanschaffen. Maar dat is inderdaad wel iets wat ik toch mis, dat makkelijke heen en weer vliegen met die, ja, die lekker gladde plastic bovenkant van die Magic Mouse. Ja, ik heb zelf nu ook een Magic Mouse en ik heb het nu denk ik zo'n halfjaartje ben ik hem aan het gebruiken. Ja, ik vind het wel heel lekker hoor, dat met die, dus ik ben niet meer gewend om echt een muis in mijn hand te hebben en te klikken en ik voel me ook veel meer professioneeler of zo, als ik dat ding gebruik. Dat is ook wel knap, ja. Ja, nee, maar even de mensen thuis die misschien niet de rant hebben gezien op Twitter. Ik ben even de naam kwijt, wie nou de thread startte, weet jij dat misschien Johnny? Nee, ik weet dat niet aan mijn hoofd, daar zou ik ook echt even op moeten zitten. Ja, goed, zullen we het in de show notes stoppen? We zetten hem in de show notes erbij. Er staan ook een hele hoop leuke reacties op. Ja, bijvoorbeeld een iemand die heeft vier muizen aan zijn laptop gekoppeld en die vroeg zichzelf af of die dan nu ook echt, ja, wel aan het ene extreme van het spectrum. Ja, want het tweetje waar het over ging, dat was dus iemand die had, ja, ik weet niet eens of het een grapje was of dat hij echt serieus twitterde, maar hij koppelde, ja, je ervaring en je kennis als developer aan het gebruik van je muis. Dus als jij een muis zou gebruiken, dan werd je volgens hem als junior verklaard. Ja, bizar. Maar goed, wat vind jij ervan? Ik denk dat hij het als grapje bedoelde. Dat hoop ik wel. Ik denk ook dat heel veel mensen het er wel serieus zou overdenken. Helaas. Ik vind het echt onzin. Hij gebruikt zelf een muis, dus er is maar wat aan gelegen om wat onzin te vinden, natuurlijk. Ik zou zelf wel minder van de muis gebruik willen maken dan ik nu doe. Een bepaalde luiigheid in het aanleren van keyboard shortcuts en zo. Maar in het algemeen, ik vind het zo onzin om zo'n één enkel gebruiksdingetje als metriek voor je mate van professionaliteit of de mate van je skills te pakken. Je kunt ook zo'n discussie hebben over, die zie je ook nog wel eens een keer voorbij komen. Die gaat misschien wat minder viral, maar als je een IDE gebruikt, dan ben je blijkbaar geen echte developer. Je moet alles op de command line en vim gebruiken. Vim is dan altijd geavanceerd en dan moet je via je doen of zoiets. Maar ik moet zeggen, mijn IDE zorgt ervoor dat ik de muis minder gebruik. Dus dat is dan wel een beetje tegenstrijdig als we die twee metrics naast elkaar leggen. Ik moet zeggen, ik voel me altijd echt de koning van de aprots als ik gewoon met mijn toetsenbord alle shortcuts aan het uitvoeren ben en gewoon door mijn hele project heen navigeren ben. Het voelt wel lekker. Ik denk ook wel dat je er uiteindelijk productiever van wordt door keyboard shortcuts te nemen. Want de bandbreedte is natuurlijk gewoon groter. Je hebt eigenlijk iets van drie assen namelijk links, rechts, boven, beneden en nog iets met klikjes doen. Dat is alle informatie die je op die manier naar de computer kunt overbrengen om iets te gaan doen. En met een keyboard, ja, je hebt natuurlijk veel meer toetsen. Je hebt gelijk, zeker als je tien vingers kunt typen, je hebt gelijk tien vingers waar je wat mee kunt doen. Dus kun je veel meer combinaties zo mee maken. Dus het is wel logisch dat je daar productiever mee kunt worden. Maar ja, je moet wel investeren om al die dat er inderdaad ook alles mee kan via keyword shortcuts, et cetera. Ja, ik kwam een tijdje geleden. Een collega van mij attendeerde mij erop. Ik gebruik zelf IntelliJ of in ieder geval RubyMine in mijn geval. En er is dus een plugin die je kunt installeren. En dan als je heel vaak met je muis door bepaalde menu'tjes heen gaat en bepaalde dingen aanklikt, dan suggereert hij na een keer of vijf van hey, wist je dat er hier ook een shortcut voor is? Ja, het is geniaal. Ja, dat is een hele goede inderdaad, ja. Het was echt van, oh, my. Het is een soort van AI, een soort van machine. Ja, ja, ja. Ja, maar dat is ook een beetje het refereert ook een beetje naar het voorbeeld die je gaf over bij de Belastingdienst. Dat als je een natuurlijk persoon bijvoorbeeld ergens gebruikt, dat die dan jouw adviseert, als het ware. Ja, ja, het is gewoon assistentie van van hey, ik zie dat je ik zie dat je hiermee bezig bent, steeds hetzelfde doet. Nou, hier komt een suggestie om dat om dat wat productiever wat sneller te kunnen doen. Ja, precies. Nou, ja. Hey, het trouwens nog even terugkomen. Het is O'Shell op Twitter of underscore O'Shell. Hij gaat uiteraard in de show notes. Hij heeft de eerste tweet, de originele tweet. If you call yourself a developer and use a mouse for editing code, I just assume you're a junior. Dat was letterlijk een quote. En ja, hij zegt er later over. I made a stupid post and I apologize. Dus hij had het toch wel echt serieus. Serieus. Ja, ja, ik moest. Ik dacht echt wel in het begin dat het moet een grapje zijn. Weet je wel? Ja, ik ik ik zag ook gewoon een paar mensen. Ik dacht ook Saber dacht ik gewoon even echt serieus erop reageren. En toen dacht ik ineens van hee, wat, wat, wat? Is het nou echt? Wat bedoelt hij nou? En en toen toen zag ik ook op een gegeven moment. Volgens mij was jij dat Johnny die een tweetje stuurde of wat minstens een retweet deed van iemand die had dan vier muizen aan z'n laptop gehangen. Ja, ja, ja. Nou goed, het moet wel gezegd. Hij heeft netjes excuses aangeboden. Ja, nou goed, dat dan wel. Ja, dat is wel weer goed. De rent van de week zit er weer. Ja, die zitten er weer op. Langer dan kunnen we lachen. Ja, ja, ja. En ja, ook voor de volgende aflevering. Mocht je er eentje willen tippen. Ja, graag. Zeker. Ja, dan kunnen we meer gebruiken. Dan kunnen we weer lekker toepassen. Je kan hem tippen via Twitter. Het CodeKlets. Het is weer tijd voor onze volgende thema. Dat was fout, hè dit? Nou, we hebben vorige week ook een hele leuke, ja, leuke, leuke gedeelte gehad in onze podcast. Dat was de developer dilemma's. En ja, het leek ons wel leuk om dit weer een keertje te doen. En misschien ook dan, ja, ook in dit geval meint even zijn mening daarin te laten vragen. Nou, ik weet niet of je het kent toevallig Meinte developer dilemma's. Wat is het? Developer Dilemma's.com of zo? Correct. Ik denk nog niet. Oké, nou zou je eens een keer moeten doen. Het is wel leuk. Dan krijg je twee opties. En het is de bedoeling dat je toch echt echt het moet het moet. Het moet gewoon. Je moet één van ze kiezen. Oké, geen flauwe antwoorden van ja, depends en bla bla bla. Nee, je moet gewoon eentje kiezen. Yes. Ja, nou ben je er klaar voor meenten? Nee, maar ja, ja, je moet kiezen. Ja, ja, ja. Oké, daar komt hij. Een monolith of microservices. Ja, je maakt gelijk wat moeilijk. It depends. Dat altijd heel goed in software altijd. Maar laten we maar voor de microservices gaan. Oké, oké. We hadden het net over Twitter. Ik had ook nog een tweetje gevonden. Ik zal hem er ook even straks onder plaatsen. Die kreeg ik getippt van Bart de Water trouwens, een vorige gast uit de podcast. En dat was iemand die zei de longer I'm in tech, the more I'm convinced microservices were a technical solution to an organisational problem. Die heb ik inderdaad ook gezien. Wat denken we daarvan? Ja, ik ben er wel mee eens. Ik ben er ook zeker wel mee eens. Ja, ja. Ja, denken we dat de ja, de kwaliteit van de code een afspiegeling is van de kwaliteit van de organisatie of we het niet zo ver trekken? Nou, dat is toch Brookes law dat dat uiteindelijk. Ik weet niet meer de quote precies, maar dat uiteindelijk elk stuk software of de architectuur van elk stof een stuk software een afspiegeling is van de organisatie die die software heeft voortgebracht. Ja, precies. Dus ja, daarom was mijn antwoord ook net van microservices in plaats van monolith. Want proberen is maar is microservices. Als dat niet lukt, dan heb je waarschijnlijk een ander probleem of misschien wel een grote probleem dan dan alleen een beetje het maken van je software. En ik denk ook dat je met microservices daar wat sneller, wat harder achter komt dan als je een monolith gaat proberen te bouwen. Het voordeel van microservices is natuurlijk echt die keiharde boundaries die je op een gegeven moment gewoon gewoon hebt. Dus je moet je wordt gewoon gedwongen eigenlijk veel meer na te denken over ja, over die grenzen. Nou ja, dit haakt natuurlijk ook weer aan bij DSL's, want het kan best zijn dat de grenzen die je voor een microservice maakt in stijl dat dat daar binnen een betere of makkelijker en goede DSL te vinden is dan als je een monolith gaat bouwen. Want een monolith daar moet alles in zitten bij definitie. Dus dat moet ook alles kunnen en zo. Dus dat is vaak veel moeilijker om daar een DSL in te herkennen en een goede eruit te filteren of te extrageren als het ware. Als je kijkt naar één ding dan heb je toch iets meer kans om daar eerder een DSL in te herkennen. Dan hebben we gelijk een bruggetje naar eigenlijk de tweede developer dilemma, want dat komt wel goed uit dat je microservices dan toch als favoriet kiest. Deze ga je echt leuk vinden Meinte. Mano repo of multiple repo? Kishen, heb jij die uitgezocht? Speciaal voor jou. Mano, zonder twijfel. Kun je uitleggen waarom? Ik heb heel veel pijnlijke ervaringen met multi-repo gehad. Bij voorduringen eigenlijk. Elke keer dat mensen weer, ja, we moeten wel in meerdere repos stoppen. Eigenlijk is dat, het is wel grappig, want het is een beetje tegengesteld aan microservices, want een mono repo is helemaal niet micro. Maar juist bij een repo vind ik dat, begin maar eens een keertje met alles gewoon bij elkaar houden. Als het op een gegeven moment duidelijk wordt dat het echt zin heeft om dingen af te gaan splitsen, splits dan nog een keer af. Maar tot die tijd houden we het alsjeblieft gewoon bij elkaar en zorg dat je met z'n allen in één grote codebase kunt gaan bewegen. Ja, ik weet nog wel dat we ook bij Mendix, daar was er heel veel discussie over, ik vond dat echt een hele goede beslissing dat we dat gedaan hebben. Want een van de belangrijkste dingen wat ons elke keer tegenhield was, als je dan aan een story werkt met verschillende teams, dus een stukje of een feature, laat ik het even zo noemen, ja dan blijft het elke keer met de integraties tussen die verschillende repos en lenden en dat gaat je dan op een gegeven moment vertragen. En ik kan me nog ook wel herinneren dat Michel volgens mij toen de tijd, Michel Westrater die toen bij ons in teams zat, dat hij zei dat het echt een verademing was, want ja je werkt gewoon aan één story en het zijn gewoon verschillende componenten of verschillende, laat het even componenten noemen, en dat is gewoon zo heerlijk dat je dat in one go gewoon lekker kan committen en dan ook onder die story number of feature number en dan ook gelijk geïntegreerd kan testen lokaal, dat soort dingen. Dus ja ik denk dat dat wel een hele goede move is geweest. Maakten jullie dan ook gebruik van gitseptory of submodules ofzo? Ik geloof in de model server wel he, geloof ik toch mate? Ja, ja, ja en oorspronkelijk dus in de webmodeler ook, maar dat is er op een gegeven moment uitgegaan. En iedereen weet trouwens wat hoe submodules ook wel genoemd worden. Sab-modules. Sab-modules, als in heil-modules. Sab-modules, ja. Wacht even, wacht even. Ja, die is wel van toepassing. Die was echt van toepassing. Oké. Ja, soms is het een heetveel necessity om iets met submodules te moeten doen, maar meestal is het gewoon alleen maar pijn. Ja, goed man. Dat is echt iets leuks uitgekomen vind ik. Dank dat je aan dit onderdeel wilde meedoen. Oké. Doe maar niet nog eentje, ik wilde best nog maar eentje doen. Nog eentje? Nou, dan moeten we even naar de website. Had je geen reserve uitgezocht? Nee, nee, we hadden er twee he. We moeten ook een beetje op de tijd letten, maar we kunnen wel even nog eentje even inknallen. Wil jij iets doen Johnny? Ja, ik heb het net geopend. De eerste die ik krijg is conference or meet-up. Ik ben wel benieuwd. Ben jij zo open? Ja, goed, jij hebt al een paar keer gesproken, vertelde je net. Ja, wat is het verschil eigenlijk? Ja, ik denk toch een meet-up is een beetje meer kleinschalig en gezellig, en een conference is ja groot en georganiseerd. Een beetje dat denk ik. Ja, zeker. Ja, misschien is dit dan de vraag waar ik weer zo'n oranje kaart moet gaan trekken van in de bands. Mag niet, mag niet. Ik zou zeggen, als ik echt moet kiezen een meet-up. Een meet-up is inderdaad wat kleinschaliger, maar ook makkelijker te organiseren en ook makkelijker virtueel te organiseren. En een conferentie, dat merk je ook als je, nu zijn alle conferenties eigenlijk online. Je merkt ook dat een beetje de meerwaarde van conferenties, er zit hem toch in het sociale aspect en het tegenkomen van mensen die je anders niet zo snel tegenkomt. En dat is bij een online conferentie toch best wel weg op het moment. Bij een meet-up is dat juist wat een klein schaliger is, wat makkelijker te organiseren, dat je dat soort momenten wel hebt. Je moet het explosieter organiseren, maar dat is bij een meet-up ook gewoon beter te doen, heb ik het idee. Vaak ook met een kleinere club mensen, dus dat werkt dan ook beter. Dus daarom zou ik zeker, in ieder geval op dit moment zeggen meet-up. Op het moment dat het allemaal weer voorbij is, dan zou ik ook graag weer conferenties doen, maar nu graag eventjes meet-ups. Dat heb je al deelgenomen aan digitale meet-ups? Nee, nog niet. Wel elke week is er een meet-up vanuit een community rondom software language engineering, dat is de strumenta-community, dat we ook maar even in de show notes zetten. Dus daar is elke week een meet-up van. Dus daar heb ik wel aan deeg genomen en je merkt gewoon dat dat erg goed werkt. Dat is de deelnemer aantal tussen de 10 en 30 zo'n beetje. En daar merk je gewoon dat je erg goed vragen kunt stellen aan de presenter, dat er echt goede interactie uitkomt en zo. Eigenlijk ook wel beter dan bij conferenties. Een conferentie is meestal gewoon, je houdt een praatje en de echte interactie zit meer in de pauze dan tijdens het praatje zelf. Dan zit dat veel meer in de meet-up zelf. En jij Kishen, heb je al deelgenomen aan een online meet-up sinds de coronacrisis? Nee, nog niet. Maar we zijn wel binnen het bedrijf waar ik werk, Salves, om een interne meet-up te doen met alle medewerkers van Salves. Dus wij gaan dus ook de breakout-sessie van teams toepassen daarin. Er schijnt dat er een nieuwe feature uitgerold is, of een beta in ieder geval. Maar goed, we moeten het nog even uitzoeken. Het is pas over een paar weken, dus we hebben nog even de tijd. Maar we gaan dus die breakout-gedachten toepassen. Dus dan gaan we één kanaal maken, en dan komen we allemaal bij elkaar. En dan kondigen we het programma aan. En dan is het aan iedereen om hetzelfde te bepalen of je in Room 1 tot en met X zou willen deelnemen. Ja, ik had bij mijn vorige week gegeven, inderdaad hadden we dan breakout-sessions in Zoom. Dus het is eigenlijk gewoon een kopie, denk ik, daarvan. Ja, zeker. Je kan het natuurlijk met de hand ook gewoon in Teams helemaal zelf organiseren. Maar ik heb wel begrepen, ik had het ergens gezien op LinkedIn, volgens mij, dat ze een nieuwe feature, omdat Zoom natuurlijk al daar zo populair in was, gaan ze dat bij Teams ook doen. Ik denk dat het een hele slimme toevoeging is. Ja, zeker. En dat maakt het ook echt veel gemakkelijker om ook van het ene naar het andere toe te gaan, denk ik. Ja, ik vind het wel leuk om te zien dat die hele coronacrisis toch wel een beetje een soort paper in de kont is geweest voor bedrijven die dit soort collaboration tools maken. Want je ziet ook, vandaag kondigde Slack aan ook weer twee nieuwe features te gaan lanceren. Ze gaan bijvoorbeeld een soort voice chat implementeren, dus ala Discord, dus dat je voice channels hebt. Nou goed, er zijn ook een aantal losse applicaties voor heel populair geworden de laatste tijd. En er was nog iets wat ze ging introduceren. En ja, ik vind het wel leuk om te zien dat echt die coronacrisis een enorme vlucht laat nemen in die software ontwikkeling van dit soort tooling. Ja, en ik denk ook wel in bredere zin in hoe mensen met elkaar samenwerken, want dat wordt heel erg gefaciliteerd door software uiteraard. Maar uiteindelijk zijn het wel de mensen zelf en de bedrijven zelf die ook daadwerkelijk moeten willen veranderen. En nu moeten ze natuurlijk wel. Dat is een goede zet in de goede richting. Ik vind het wel heel fijn om te zien dat bijvoorbeeld dingen als thuiswerken, dat er nu veel meer over nagedacht wordt. Je moet het aan de ene kant wel doen, maar aan de andere kant, het wordt dus ook veel beter gefaciliteerd door de bedrijven zelf. Wat je voorheen nog wel eens een keertje had van, ja, je mag gewoon pantoor zijn, is, nou ja, de managers die dat riepen, die riepen nu als eerste van, ja, maar dan moet je wel thuis gaan werken. Dat werk moet gewoon doorgaan. Ja, precies. Ja, ik vind het ook prettiger of zo, want ik ben ook wat beter in mijn time management. Dus gewoon het idee dat iemand even je aandacht nodig geeft en dat hij dan eerst even een berichtje stuurt, weet je wel, die je dan zelf kiest om te lezen of niet, en dan daarna pas door te gaan. Kijk, het is even persoonlijk hoor, het kan zijn dat anderen het minder prettig vinden, maar van mij werkt het in ieder geval wel lekker, moet ik zeggen. Nou, hartstikke mooi. Nou goed, dan zijn we weer toe aan het volgende en tevens ook het laatste onderdeel. Dat is eigenlijk de goodies. Ja, dat is misschien niet elke aflevering, maar we proberen het natuurlijk wel zoveel mogelijk. Maar we willen even bij dit onderdeel even stilstaan bij Manning. Manning, heel erg bedankt dat wij namens Manning ook Mijnt ook in de show hebben gekregen. Die heeft ons getippt van is het misschien leuk om eens Mijnt uit te nodigen, en dat is het zeker, want het is heel erg interessant geweest het onderwerp, want om model driven development of engineering. En Manning die wilde ook als bedankje, ja, eigenlijk alle podcast luisteraars 35 procent discount code afleveren. En dat geldt ook echt voor alle producten die ze hebben op de Manning website, ook in alle formaten. Dus mocht je geïnteresseerd zijn, ja, kom naar onze Slack channel, DM een van ons en ja, we delen de code uit. Dus ik zou ook snel zijn, want het is twee maanden geldig heb ik begrepen. Dus ja, meld je aan. En ja, de Slack kanaal die staat natuurlijk in onze codeklets.nl website. En daarnaast hebben ze ook een leuke actie. En ik denk dat we daar natuurlijk ook Mijnt heel blij mee gaan maken, is om meer lezers van zijn boek te krijgen. En dat heeft hij natuurlijk al heel veel, maar om dat nog meer op te krikken. Mening geeft ook vier gratis e-book coders weg. En dus dan kan je met die code, de domain specific languages made easy van Mijnt, kan je dan downloaden. En uiteraard zijn we nieuwsgierig wat je er van vindt. En ja, we komen ook graag terug bij de Slack channel om je kennis en ervaring te delen. Het zou ook leuk zijn als misschien Mijnt ook ons joint. Wellicht krijg je ook nog wel een leuke vraag van de luisteraars. Dus dan kunnen we deze vibe nog een beetje doorpakken. Dus ja, en hoe je die kan winnen? Nou, daar hebben we wel even over nagedacht, Johnny. Ja, we gaan dat natuurlijk niet zomaar uitdelen. Iedereen krijgt wel 35 procent korting, maar als je 100 procent korting op het boek van Mijnt, dan moet je er wel wat voor doen natuurlijk. En ja, we hebben sinds een aantal afleveringen nu vijf hosts. En deze vraag gaat eigenlijk vrij specifiek over een van de hosts en dat is Pauline in dit geval. En ja, ze heeft in het verleden bij aflevering 1 was ze te gast. Ze is al een aantal keer als host ook heeft ze deelgenomen. Ze zit ook op Slack. Maar eigenlijk de vraag die wij willen stellen aan de luisteraars is in welk land heeft Pauline vorig jaar gewerkt? Inmiddels is ze weer terug in Nederland, maar vorig jaar heeft ze in het buitenland een tijdje gewerkt. En wij willen graag van jou horen welk land dat dan was. Dit kun je vinden. Ik ga er verder niet vertellen hoe, natuurlijk. Maar het is zeker de vindbaar. En ja, ook weer via het Slack kanaal kun je dat aan ons doorgeven. En dan inderdaad, als je een van de allereerste vijf bent, dan krijg je een code waarmee je het boek van Mijnt kunt bestellen. Super. Super, hè? Nou, helemaal goed. Hartstikke bedankt, Mijnte, dat je in deze elfde aflevering van de CodeKlets podcast aanwezig kon zijn. Nog wel een belangrijk vraagje, Mijnte. De status van het boek, wat is dat? Kunnen we het al lezen? Ja, we kunnen het gratis krijgen, dat is duidelijk. Maar hoe gaat het met het werk hier? Nou, je kunt de eerste zes hoofdstukken al lezen. Het is namelijk in voorpublicatie, of zoals dat bij Manning heet, Manning Early Access Program, de MIEP. Dat kun je vinden via de website van Manning inderdaad. En het is de bedoeling om in komend voorjaar klaar te zijn. Dus dan gaat het als het goed is naar de drukker en is het helemaal af. Nou, mooi. Als ik het goed begrijp, voorjaar zeg je dus? Ja, voorjaar. Niet met de kerst helaas, maar goed. Nee, dat ga ik niet redden, dat ben ik bang aan. Hartstikke goed, dank je wel voor het delen ervan. Nou, ja, nogmaals bedankt voor het aanwezig zijn. En Johnny natuurlijk, ik vond het leuk om deze podcast samen met jou op te nemen. Ja, is het nou de eerste keer zonder Saber, of niet? Ja, dat denk ik wel, ja. Ik probeerde een beetje zijn zoele stem erin te houden, maar dat is volgens mij een beetje mislukt. Nou, je hebt nog een kans bij de outro. Oké, nou goed. Nou, dat was hem weer. Hé jongens, hartstikke bedankt. Zoals ik al zei, we gaan naar de outro. Zoals altijd, zoals we altijd zeggen, dat je je altijd kan abonneren bij ons. Doe dat vooral in je favoriete podcast speler. Spotify, iTunes. Ja, mis ik iets? Nee, het is niet iTunes tegenwoordig. Het is Music. Ja, zoek ons ook op kodeklets.nl. En wil je met ons gaan babbelen? Ja, graag ook op ons Slack kanaal. Daar hebben we ook een speciale link voor gemaakt. En het gemakkelijkste is inderdaad gewoon om via die kodeklets.nl te gaan en daar alle linkjes te vinden en de favoriete spelers er aan te selecteren. En op de site staat link naar Slack bovenaan. Daar is hij niet zo verstopt meer. Dus dat is wel beter. Dat is zeker beter, ja. Nou, goed, mooi. En ik heb ook begrepen dat de site gegeneerd is. Even kijken, gek genoemd, staat er in de gegeneerde site handige links van ons allemaal. Dus dat is mooi. Dus het is helemaal geautomatiseerd, blijkbaar. Ja, helemaal mooi, joh. Heb je daar dan een belletje voor gebruikt? Ja, dat zouden we nog eens een keer samen kunnen voorleggen. Dan zouden we niet model-driven development moeten doen op die site. Ja, en we hebben het al een paar keren genoemd in de podcast. We zullen de show notes ook daarbij zetten. En dan is het toch heel gemakkelijk voor iedereen om even achteraf nog even door te kletsen. Of ja, te kletsen, sowieso, maar door te lezen. En natuurlijk zitten wij ook op Twitter. We hebben een Instagram-account. Op LinkedIn ook tegenwoordig, heb ik begrepen. Dus ja, join us, join the fun. En ja, retweeten en likes, die zijn ook altijd lief als je dat voor ons doet. Nou, in ieder geval, als ik er bedankt. En tot ziens. Dank je wel. Doei doei. Doei doei. Hoi.",
"title": "Meinte Boersma over DSL's",
"updatedAt": "2026-02-12T12:09:50.577Z"
}