Papers we love: Debugging for Reactive Programming

 
01 maart 2017

Een van de onderwerpen waar Sogyo steeds meer om bekend begint te raken is Reactive Programming. Dit doen we meestal (altijd?) met de libraries van ReactiveX, welke een generieke en open source API aanbiedt voor een groot aantal talen. Mocht je nu denken: huh? Waar heb je het over, verdiep je dan eens in hun introductie.

Nu is Rx, of Reactive Programming (RP) in het algemeen, heel tof maar er zijn wel een aantal downsides aan. Deze maand wil ik op een van deze tekortkomingen inzoomen. Ik zag op de ICSE van dit jaar een paper langs komen met een titel die me erg prikkelde, omdat hij op mijn persoonlijk grootste ergernis inhaakte: debugging. De titel ervan is ook kort maar krachtig: Debugging for Reactive Programming.

De auteurs van de paper constateren dat debuggen van een reactieve applicatie erg lastig is. Dit wordt, in hun woorden, veroorzaakt door een “paradigma verandering” tussen reactief programmeren en imperatief programmeren. Dit verschil uit zich in verschillende aspecten. De meest herkenbare is het flowcontrol model. Bij traditioneel imperatieve programma’s is dit vrij lineair, bij een reactieve applicatie kan het juist alle kanten op springen, zeker als er een complexe samenhang van signals gaat ontstaan. Ook het mentale model van een reactieve applicatie wijkt erg af van dat van een imperatieve applicatie. Dit is het gemakkelijkst te zien door de informatie flow te volgen: imperatief heeft een duidelijke callstack, reactief is eigenlijk een dependency graph waarbij je eigenlijk wilt redeneren over de inkomende en uitgaande edges. En laat dat nu net heel lastig zijn.

In “het veld” wordt er ook wel gewerkt aan dit “asynchrone” probleem. De bekendste is de “async” toggle uit de chrome developer toolbar. Hierdoor wordt asynchrone code met callbacks uit het systeem (timers, netwerk, …) geannoteerd met de oorspronkelijke caller, waardoor de Chrome dev tools een lineaire callstack kan laten zien. Zelfs als het dus niet lineair is. Dit is heel cool en super handig, maar het is een technisch specifieke oplossing voor een deel van het probleem: synchrone callstacks in asynchrone code in JavaScript binnen Chrome.

De auteurs van de paper (en stiekem vooral de master student die een eerste versie van de tool heeft gemaakt) laten een mooie, alternatieve debugger zien die je enorm kan helpen in een reactieve context. Het is geschreven als een eclipse plugin en het kan scala-react [8] applicaties debuggen. Helaas dus geen Rx of anderen, maar de techniek is mijns inziens toepasbaar voor de andere reactive libraries uit het ecosysteem.

Dit hebben ze bereikt door de code te analyseren en in de debug mode van Eclipse automatisch een aantal dingen voor je te realiseren. Het belangrijkste en meest prominente is de dependency graph. Hierdoor heb je dus direct zicht op de opbouw van je applicatie en zie je direct hoe de acties gewired zijn. De nodes in je dependency graph kun je vervolgens manipuleren alsof het normale expressies zijn: je kunt breakpoints zetten, waardes inspecten en terug de tijd in om oude state te zien. De tool zorgt vervolgens dat de normale Scala debugger wordt aangestuurd, waardoor je dus op een heel highlevel niveau kunt debuggen.

En dit is nogal een verbetering ten opzichte van het huidige devies: “plaats maar wat log statements” (basically dus oldschool printf() debugging). Waar je ook kijkt [1, 2, 3], iedereen zegt eigenlijk hetzelfde. Introduceer log statements met do() en teken op papier je dependency graph uit door je code goed te lezen. Iedereen voelt natuurlijk ook wel aan dat dit handiger moet kunnen, er is tot noch toe helaas geen algemeen geaccepteerde oplossing. Er zijn wat pogingen gedaan [4, 5], maar dit is altijd te geënt geweest op individuele talen of te losgekoppeld van de rest van de codebase, wat het een beetje “spielerij” tools maakt. De bug waar jij mee aan het stoeien bent zul je dus eerst helemaal uit de context van je codebase moeten halen voordat je met dit soort dingen aan de slag kan. Makkelijker gezegd dan gedaan…

Deze paper beschrijft een manier om de debugging experience voor reactieve applicaties een stuk krachtiger te maken. De manier waarop is nog redelijk generiek en zou in principe in meer editors en talen toegepast kunnen worden. Natuurlijk zijn er nog een hoop haken en ogen aan de huidige implementatie en zijn er ook nog een aantal open vragen, maar dat hoort erbij. Dat de paper een heel erg praktisch onderwerp bij de oren vat maakt hem heel erg toegankelijk en er zijn ook wel wat keuzes gemaakt die je als lezer wel even aan het denken zetten: “is dat niet wat kort door de bocht?” vroeg ik me bijvoorbeeld regelmatig af bij het lezen. Desalniettemin biedt het absoluut een mooie oplossing voor een probleem waar ik in ieder geval de pijn van voel. Ik geloof hier wel in!


Over deze papers we love: binnen Sogyo hebben we de traditie dat we maandelijks een nieuwsbrief rondsturen. De nieuwsbrief gaat veel over interne feitjes, echter sinds februari 2015 verzorgd Kevin van der Vlist het topic: papers we love. Hij deelt met ons papers die interessant zijn om te lezen en ons kunnen inspireren. De topic is uitgegroeid tot een mooie verzameling die we ook graag hier willen delen.


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


Categorieën: Gave Technologie