We halen de bevindingen uit de recente editie van de Tiobe Index, een van de lijsten die Computable gebruikt voor zijn eigen index.
Al heeft Tiobe de neiging om te mikken op de eerder klassieke benadering van it (en programmeertalen). C staat daar bijvoorbeeld op de eerste plaats, gevolgd door Python (terwijl die bij veel andere de lijst aanvoert) en Java op plek drie.
Assembler
Opvallend zijn de oudjes in hun index. Zo stijgt Assembler in een jaar tijd van veertien naar negen, en rolt dus de top tien binnen. Dat is opvallend voor een taal die echt teruggaat naar de basics van programmeren. Assembler is nauwelijks meer dan een symbolische weergave van machinetaal. Ze ontstond in 1947, en is dus bijna 75 jaar oud.
Seppe Vanden Broucke, professor aan de UGent en KU Leuven, ziet een aantal redenen voor de comeback van Assembler. ‘Assembler wordt gebruikt voor embedded en internet of things-toestellen met vaak weinig stroomverbruik en geheugen’, stelt hij. 'En dergelijke toepassingen zitten in de lift.'
Een andere reden is dat het een belangrijke hobby-taal is. ‘Bijvoorbeeld voor Arduino-achtige projecten, vaak gerelateerd aan iot. Ook zogenaamde retro-computing platforms, die de laatste tijd in opmars zijn, maken er gebruik van. Projecten als Mega65', stelt Vanden Broucke, ook in security een rol voor Assembler ziet. ‘Zo zijn er toch nog veel exploits die Assembler gebruiken voor de kritieke delen.’
Fortran & Cobol
De grootste stijger in de recente Tiobe-lijst van programmeertalen is Fortran. Die gaat op een jaar tijd maar liefst van 37 naar 17 in hun Index. Ook Fortran is een oude krijger. Het was een programmeertaal die in de jaren vijftig ontstond en door IBM werd aangeboden.
Bij Tiobe zelf wijten ze de opmars van Fortran aan ‘de massale behoefte aan getallen kraken’, vaak voor wetenschappelijke projecten. ‘Fortran heeft één duidelijke gebruikstoepassing in machine learning. Onderliggend is er heel veel Fortran-code die daarbij wordt gebruikt’, beaamt Vanden Broucke, die zelf voor it-gebruikersvereniging SAI onlangs een webinar over trends in programmeertalen en dit aanhaalde.
Verder in de lijst houdt ook Cobol behoorlijk stand op plaats nummer 25. Al is dat niet echt een comeback. Traditionele programmeertalen blijven vaak vrij lang aan, door hun legacy. En ook een taal als Cobol, een taal uit de jaren zestig, gaat maar moeilijk weg. Het is zo dat er het voorbije jaar bij een legacy-vernieuwing wel wat Cobol is gebruikt (of opgefrist). ‘Maar dat zijn geen nieuwe projecten’, nuanceert Vanden Broucke.
SQL
Wie ook mooi standhoudt in de lijst is SQL, een querytaal. ‘We hadden de laatste jaren een beetje het gevoel van dat SQL aan het verdwijnen was’, aldus de professor. ‘Maar SQL is het database lingua franca.’
Voor SQL spreekt de professor wél van een opmars. ‘Met de komst van NewSQL, zoals een MongoDB en dergelijke, zien we vandaag zelfs een revival in SQL’, vindt hij. ‘Het idee leeft toch wel dat die oude databanken nog niet zo slecht waren. Ook met de beweging naar cloud gerichte databanken en dataplatformen zoals Dremio en Snowflake, is men SQL terug volledig gaan omarmen als querytaal’, stelt hij.
Is die revival van SQL niet opmerkelijk? ‘Velen beseffen dat ze die taal niet willen missen, want het alternatief wordt niet altijd als beter aanzien. Het zal waarschijnlijk nog vele jaren duren alvorens SQL dood valt te noemen.’
De Tiobe-index vind je hier; de Computable-index hier.
Reacties
Dan krijgt Forth wellicht straks ook nog een revival. De Next-interpreter van Forth springt naar het adres dat volgt op de assembly code van die interpreter (van Forth-word naar Forth-word totdat hij op een opcode Forth-word terecht komt, een Forth-word dat niet met het Builds-deel van de Builds/Does-constructor is gebouwd. Dan komt ie dus niet meer op een opcode assembly van de Next-Interpreter terecht maar in functionele op-code. Onder Andere Harvard SoftWorks had een compiler/optimizer gebouwd die alle Next opcode verwijderde uit een versie voor deployment en dan kreeg je ongelooflijk snelle op-code waar het resultaat van een C-compiler alleen maar tegenop kon als je wist wat je moest doen om daarmee optimaal snelle code te krijgen. Forth had ook reverse polish notation dat direct aansloot op het push/pull-karakter van CPU's. Had Intel de smeekbeden van de toenmalige community opgevolgd en een Next-instructie ingebouwd in de CPU, weet ik niet hoe het met Forth gegaan zou zijn.
Als ik met goed herinner kon de optimizer ook nog bepalen of hij sommige code maar repeterend achter elkaar moest zetten of toch opteerde voor een loop (maar dat kan ik er later ook romantisch bij gefantaseerd hebben :-))
Grappig dat Cobol als oude taal wordt gemarkeerd, en C niet, terwijl ze niet zoveel van elkaar in leeftijd verschillen... Maar met C++, Java en C# als direct afgeleiden, oogt C veel moderner (en minder oubollig) dan Cobol, dus ik snap het wel.
SQL is geen taal zoals bv C, het heeft toevoegingen nodig zoals PL/SQL of Transact-SQL om het een volwaardige taal te maken.
SQL is al tijden de voorkeursmethode om iets met data in een database te doen. Dankzij Spark SQL implementaties is het ook mogelijk om in (Databricks) notebooks met SQL op dataframes te werken, bijvoorbeeld tussen de Python statements door.
Ik zou SQL geen taal willen noemen, maar meer een onder woorden gebrachte wiskunde (verzamelingenleer). Het is een gestructureerde manier om te benoemen welke verzamelingen er moeten worden meegenomen in het verkrijgen van een uitkomst.
Met de komst van procedures zijn er meer directieve zaken in de taal gesloten. Maar strikt gesproken zijn procedures geen onderdeel van de 'taal' SQL. SQL is opgezet en bedoeld als een onafhankelijke manier van uitvragen, procedures zijn door leveranciers aan de taal toegevoegd om teveel dataverkeer tussen applicatie en database te voorkomen. Hier is in de praktijk echter vaak misbruik van gemaakt door het verplaatsen van zuivere applicatie verantwoordelijkheden naar de database. Dit heeft meer dan eens geleid tot het gevreesde 'vendor lock-in'.
Maar zuiver gesproken is SQL geen taal.
"Maar zuiver gesproken is SQL geen taal."
Jack, is er niet nog een dooie duitser die hier wat over geschreven heeft ?
SQL is zeker wel een taal, maar of het echt een programmeertaal is... :-)
Ik programmeer nauwelijks meer, maar als ik wat schrijf is het SQL, heerlijk want functionele taal. Je beschrijft welke uitkomst je wilt hebben in plaats van het imperatieve waarin je zegt wat de computer moet doen.
Iemand al een vertaling van de L in de afkorting SQL gedaan? Prachtig dat Dino rammelt op de deur van Jack en Henri toegeeft dat hij niet meer weet waar de Q en S voor staan in de afkorting want de gesloten vraagstellingen zijn voor een woordkunstaar als een vrije interpretatie van de uitkomst. Cryptisch als altijd gaat het niet om de dode Duitser die ooit eens wat geschreven heeft maar de context waarin hij het geschreven heeft, 5 mei vieren we nog altijd het aantal dooie Duitsers. Of om precies te zijn het aantal foute Duitsers want de tijd leerde dat niet iedereen een stramme rechterarm had. Foute denkbeelden kent in de taal van Jack geen grijs middenveld. Henri probeert een balletje op te gooien met zijn reactie over uitkkomsten maar hij krijgt het balletje recht tussen zijn ogen, wat is namelijk het doel waarop we richten?
@Dino
I stand corrected, SQL is een taal in de zin dat het iets is waarmee je de informatie opvraagt. Mijn fout om het geen taal te noemen.
Maar ik hoop dat je het ermee eens bent dat het in het lijstje van programmeertalen als C, C++, Java, Cobol, etc. niet thuishoort.
"Bijvoorbeeld voor Arduino-achtige projecten, vaak gerelateerd aan iot"
Dit is een voorbeeld van niet weten waar je over praat.
De Arduino is in 2004 bedacht als een kleine single-board computer met een bijbehorende IDE.
Het bordje had een USB-aansluiting en een ingebouwde bootloader voor het programmeren.
De taal waarin je hem moest programmeren heet C++, assembler kent de IDE niet en dat zou ook zijn doel voorbij schieten, want de Arduino was bedoeld voor mensen met weinig programmeerervaring.
Internet of things was nog toekomstmuziek en voor de Arduino onbereikbaar, want daarvoor heb je een TCP/IP stack nodig en die paste niet op het 8-bit computertje met 32k programmageheugen.
@CPT
Je had ook één reactie boven de eerste van jou kunnen kijken, daar leg ik uit wat het verschil is tussen de databasetaal SQL en de volwaardige talen PL/SQL en Transact-SQL.
Oudlid, je opmerkingen zijn niet eens off topic als we in de evolutie van programmeertalen een beweging zien van formele – logische, wiskundige en imperatieve – kunsttalen naar natuurlijke taal.
In tegenstelling tot derde generatietalen (3GL) en vierde generatietalen (4GL) zijn vijfde generatie talen veel sneller te leren omdat deze niet meer gericht zijn op wiskunde en logica, maar op natuurlijke taal.
Een eenvoudig overzicht:
3GL: HOW. Procedureel en datagedreven. Python, Java, etc.
4GL: WHAT. Declaratief. Database vraagtalen (SQL)
5GL: WHY. Declaratief en doelgedreven. DT (Decision Tables)
Tot op zekere hoogte sluit ik aan bij de visie van prof. Jan Vanthienen (KU Leuven):
https://dmcommunity.org/challenge/challenge-june-2021/
SQL kan gezien worden als een wiskundige specificatie van het gewenste resultaat en kan daarmee een zuivere 4GL worden genoemd (gericht op het wat, niet op het hoe). Mijns inziens is het vooral interessant om SQL steeds minder op te nemen binnen 3GL-talen (ofwel het embedden van SQL in procedurele talen) of aan te vullen met andere 3GL-constructies (bijv. PL/SQL) en steeds meer op te nemen binnen 5GL-talen.
Een fraaie challenge om dit aan te tonen is:
https://dmcommunity.org/challenge/challenge-oct-2016/
waar een oplossing met SQL nog steeds ontbreekt
(ofwel: wie gaat deze uitdaging aan)!
---------------------------------------------------------------------------------------------------------------------------------
Je opmerkingen over de grootste denker ooit zijn bepaald ongemakkelijk;
hier laat ik liever de meest relevante hedendaagse filosoof aan het woord:
https://www.trouw.nl/nieuws/heidegger-de-antisemiet-met-het-grote-licht~b70636d8/
Als we de toeslagenaffaire bij de belastingdienst echter plaatsen in de categorie “misdaden tegen de menselijkheid” gaat het niet om de vraag hoe fout Heidegger was in oorlogstijd, maar hoe fout het technocratische neoliberalisme is in “vredestijd”.
@Jack, volledig met je eens. SQL moet je aan Transact-SQL overlaten voor wat betreft SQL-Server. Niet vanaf een API-host e.d. en al helemaal nooit vanaf een user interface.
Forth was trouwens de eerste natural language programming language, zij het dat ere weinig functies te bedenken waren voor woorden als 'de', 'het' en 'een'. Maar ook zinsconstructies daarmee had je prima kunnen bedienen.
Door een of andere annonce (waarschijnlijk in Computable) was ik aanwezig bij de oprichtingsbijeenkomst van UX-NL op het Mathematisch Centrum in Amsterdam. Voor de aanmelding had ik om de een of andere reden Andrew Tanenbaum aan de lijn. Ik begon natuurlijk onmiddellijk over Forth en hij zei: "Ik heb mijn halve leven al in Assembly geprogrammeerd en ik ga dat de komende helft zeker niet nog eens doen".
Achteraf in mijn ogen onzin. In Forth programmeren is volkomen transparant met de taal uitbreiden en is aan geen enkel abstractieniveau gebonden. Integendeel, je ontkwam er niet aan om abstractieniveau op abstractieniveau te stapelen zoals je dat in een natuurlijke taal ook doet.
Voorlopig gaan we lekker door in Transact-SQL. Wat een heerlijke taal is dat. Voordat je met Forth in je eentje weer op dat niveau bent, is iedereen al dood en begraven. Tenzij je bij Adobe gaat werken wellicht. Volgens mij hebben die praktisch alles op basis van een eigen doorontwikkeling van Forth, in ieder geval PostScript als je dat van binnen beziet.
Jack,
Doe je een filosofische drogredenering van tu quoque? Tijd en (fout) Zijn kent uiteraard een context omdat we niet met hedendaagse moraal kunnen oordelen over denkbeelden in het verleden maar wat als deze rijmen met het heden?
Kom, kom Jack het 'zijnshistorisch antisemitisme' blijft HOE mooi je het filosofisch ook verpakt een moreel verwerpelijk denken. Mark Twain stelde daarom ooit dat de geschiedenis zich niet herhaalt maar dat deze wel rijmt omdat de HOE achter de uitkomst vaak niet goed onderzocht is.
Een 'gekunstelde' taal van beeldspraak heeft geen duizend woorden nodig voor het binaire gevoel van goed en fout. Volgens mij maak je namelijk een foutje in de vertaling als het gaat om misdaden tegen de mensheid en menselijkheid door een historisch-culturele referentie naar een suggestief gevoel.
Goed dat je refereert naar toeslagen-affaire want vergeet niet dat opdracht hiertoe vanuit het volk kwam toen bleek dat er op grote schaal gefraudeerd werd, niet iedereen is slachtoffer. Willen we meer of minder (Bulgaren)fraude want het nieuwe leiderschap lijkt erg veel op het oude.
Zo te horen zijn die 4e en 5e gen talen makkelijk te leren, alleen moet je gekunstelde prijsvragen uitschrijven om iets te vinden dat je ermee kunt oplossen :-)
@Dino
Zo te lezen heb jij geen flauw idee wat 4e en 5e generatie programmeertalen zijn.
Rob, wat een gave reactie; wat je stelt is computer nostalgie van de bovenste plank!
Zelf programmeerde ik in Z80-assembler, Basic en Forth op een TRS80 model 1 en dat was één van de redenen om in 1983 na mijn militaire diensttijd Informatica te gaan studeren in Groningen (HIO).
Gestructureerd programmeren werd vooral onderwezen met Pascal en pseudocode maar mijn interesse voor de taal Forth bleef op de achtergrond steeds aanwezig. Nog steeds heb ik “Flitsend Forth” van Alan Winfield (met een oranje FORTH-79 Overzichtkaart) in mijn boekenkast.
En hoofdstuk 7 van mijn afstudeerscriptie in 1988 had de titel “Een kennisbeschrijvende taal in FORTH”. Maar in het voorwoord van deze scriptie had ik al afscheid genomen van deze taal.
Terwijl ik in het vierde jaar van de opleiding een expertsysteem maakte in Forth, toen nog met losse als-dan regels in plaats van beslissingstabellen, volgde ik ook het vak Vertalerbouw, onder andere aan de hand van het gelijknamige boek van Alblas (en anderen). Vanwege mijn eigen interesse schafte ik daarnaast het mooi compacte “Compilerbouw” aan van Nicklaus Wirth, de bedenker van talen als Pascal en Modula. Dit handzame boekje lijkt mij overigens een bewerking en vertaling te zijn van hoofdstuk 5 van zijn eerder verschenen bekende boek “Algorithms + Data Structures = Programs”.
Hoewel Forth beslist compilerende (codegenererende) eigenschappen heeft, vond ik de toepassingsmogelijkheden van deze taal voor Vertalerbouw uiteindelijk toch te beperkt. Ik overwoog hiervoor destijds de overstap naar de programmeertaal C, maar heb dat verder nooit doorgezet.
Inmiddels ben ik enkele jaren geleden wel overgestapt naar Python en heb daar geen seconde spijt van gehad. Maar Forth is in de jaren 80 beslist een bron van inspiratie geweest!
De link die je legt tussen Forth en natural language onderschrijf ik volkomen.
“Forth is zeer geschikt voor het maken van een taal, toegespitst op een bepaald onderwerp.
Op zijn best lijkt een Forthprogramma uiteindelijk op een normale zin.”
“Het is ongetwijfeld de meest flexibele en kneedbare programmeertaal die er bestaat.”
https://www.hcc.nl/algemeen/2981-flexibel-programmeren-in-forth
“… omdat bij een goede programmeerstijl zonder variabelen de data verborgen blijft, beschouwen sommige programmeurs Forth als een object-georiënteerde programmeertaal avant la lettre. “
https://nl.wikipedia.org/wiki/Forth_(programmeertaal)
Je moet mij natuurlijk niet vertellen dat je Transact-SQL een heerlijke taal vind, want dan ga ik je een oplossing vragen voor die eerder genoemde challenge :-)
Weet zo niet welke challenge je bedoelt, Jack. Wellicht mijn fout. Harvard Softworks heeft indertijd ook nog FOO (Fort Object Orientation Tools) uitgebracht. Daar heb ik toen niets mee gedaan. Ik gebruikte Forth voor een Eprom-progammer (later nog uitgebreid van 2K (2702 naar 8K (2708)) voor de Brother Centronics typemachine interface die we ontwikkeld hadden en verder voor native export van data uit vroege versies van Exact (met een random access file structuur) voornamelijk naar Dbase 3/4 en Clipper.
Hoor graag meer over die challenge. Transact-SQL kan alles :-)
mvgRob
Rob, even naar boven scrollen:
https://dmcommunity.org/challenge/challenge-oct-2016/
waar een oplossing met SQL nog steeds ontbreekt
(ofwel: wie gaat deze uitdaging aan)!
@Jack:
Enkele jaren later was Compilerbouw van Wirth het standaardwerk op de opleiding...
Het probleem van jouw link:
https://dmcommunity.org/challenge/challenge-oct-2016/
is goed oplosbaar in Transact-SQL middels loops en cursoren en "SELECT (TOP x) * FROM table WHERE whatever ORDER BY status / miles" (eventueel via een hulptabel of decode). En ook in Transact-SQL is er geen plek voor Tom, daar verandert een taal niks aan.
Transact-SQL kan alles, nl 3GL constructies :-) https://en.wikipedia.org/wiki/Transact-SQL
@Frank, vergeet de Window Functions niet (https://www.sqlservercentral.com/articles/understanding-the-over-clause). En eventueel een WITH voor de UPDATE. (WITH common_table_expression). Je moet dan met ROW_Number minderen in de PARTITION_BY uitsluiten en erbinnen Capacity met 1 verlagen en uitsluiten als ie 0 gelopen is. Status Flight en SortOrder Passenger is beide statisch. Met de Window Functions kun je nog van alles binnen ieder element van een SET-based ResultSet.
@Rob
Met WITH (een query als pseudotabel) en window functions kom je al een heel eind. Ik gebruik van de window functions vooral de ranking, maar er kan veel meer mee. Je kunt er min of meer de GROUP BY mee vervangen (niet helemaal, je groepeert niet dus verliest geen regels), maar het kan ook in combinatie met (OVER komt na GROUP BY). Het lukt dan ongetwijfeld zonder programmeertaalstructuren zoals loops, maar vanwege de leesbaarheid zou ik daar waarschijnlijk toch voor kiezen.
@Frank, eens met betrekking tot dit geval (als praktijkgeval, niet als challenge). Het probleem is dat je steeds uit moet sluiten wat je al behandeld hebt bij iedere iteratie en dat alles wat je al behandeld hebt ook nog op andere manieren leidt tot een nieuwe situatie. Dat is typisch wat voor Window Functions omdat die allerlei Clause onderdelen steeds per item in de resultset opnieuw uitvoeren.
Wat denken jullie, komt basic onder dos van microsoft ook weer terug?
@Jan
Nee, die rotte basis-Basic met regelnummers komt niet meer terug, maar wie weet komt GFA Basic ooit wel terug:
https://en.wikipedia.org/wiki/GFA_BASIC
@Frank, bedankt voor de link, leuk. Was bedoeld als grapje . . .
Wellicht krijgen we nog een virtuele S36 met RPG II.
Ik denk dat ze daar in de virtualisatie-omgevingen van IBM nog honderden in Nederland van hebben draaien, Jan. Of inmiddels in allerlei Docker instances, wellicht?
@Jan, Rob:
https://www.rs-online.com/designspark/my-raspberry-pi-thinks-it-s-a-mainframe
Voor een paar euro kun je "mainframpje" spelen!
Rob, Frank, natuurlijk kan met Transact-SQL alles.
De vraag is alleen hoeveel code je nodig hebt voor een bepaald probleem en of deze code door bedrijfsmedewerkers (en niet alleen door ICT-ers) nog te volgen is.
Wat de vraag oproept: is een 4GL, zoals SQL een taal voor de business of voor IT?
Mijn antwoord is eenvoudig:
- als je SQL aanvult met 3GL programmeerconstructies is het een taal voor IT-ers,
- als je SQL aanvult met 5GL beslissingstabellen is het een taal voor de business.
Maar dit onderscheid is er ook als je SQL als een zuivere querytaal (en dus 4GL) gebruikt:
- eenvoudige queries zijn goed te volgen en te maken door bedrijfsmedewerkers
- ingewikkelde queries zijn alleen te maken door IT-ers.
Het goede nieuws is nu dat ook ingewikkelde queries veel eenvoudiger gemaakt kunnen worden in combinatie met beslissingstabellen.
En dus mijn oplossing voor de eerder genoemde challenge:
3 eenvoudige beslissingstabellen die een kind nog kan begrijpen en 5 zeer eenvoudige SQL-queries.
https://dmcommunity.org/challenge/challenge-oct-2016/
Ben natuurlijk wel benieuwd hoe citizen developers dit probleem oplossen met hun lowcode en nocode tools :-)
PS. een mooi voorbeeld van SQL en beslissingstabellen kun je hier aantreffen:
https://openrules.wordpress.com/2020/11/13/accessing-database-from-business-rules/
Ik ben echter niet gecharmeerd van de wijze waarop SQL-statements hier in tabellen worden opgenomen; persoonlijk kopieer ik ze liever in z’n geheel vanuit de gebruikte databasetool, waar ze eerst ontworpen en getest kunnen worden!
Lang geleden dat ik hier iets gepost heb.
Kwam ineens een quote tegen van een van de mensen die hier regelmatig reageren.
Wat ik van de tiobe index begrijp is dat ie gebaseerd is op resultaten van zoekmachienes.
Deze kijken echter enkel naar explicite vraag, niet naar werkelijke behoefte.
Ik herinner mij nog wel de tijd dat websites enkel werkte met IE6 met als argument al onze klanten hebben IE6.
Ja duhhh al eens in je log gekeken hoeveel klanten je mist ?
Zo zie ik dat dus ook met programeerskills gebeuren, of beter gezegd, skill in het algemeen.
Anyhow, Een jaar geleden nog eens een hobby projectje gedaan waar ik heb besloten de hele boel in assembly te tikken.
Geen idee of links hier toegestaan zijn maar wie het aardig vind om te zien, bij deze:
http://coollabs.nl/TacanSim/TacanSim.html
Niet zeiken over mijn website, hij is nog in opbouw en ik ben een lousy webdesigner.
Interessant Jack, Ik kende OpenRules niet. Ik ga het bestuderen. Bedankt voor de suggestie(s).
@Jack:
“Ben natuurlijk wel benieuwd hoe citizen developers dit probleem oplossen met hun lowcode en nocode tools :-)”
Nog even voor de duidelijkheid: welk probleem zou er opgelost moeten worden?
Bij lowcode/nocode draait het om het versnellen van applicatiebouw – de onderliggende database-structuur en/of taal is daar niet of nauwelijks relevant = je vraag heeft veel weg van iets over appels en peren en zo?
:-)
=====
Voor de volledigheid mijn € 0,50 over de meerwaarde van nocode (bij lowcode heb ik wat bedenkingen).
De sweet spot van nocode zit hem vooral in het stroomlijnen van grotendeels sequentieel uitgevoerde administratieve processen – zeg maar het digitaliseren van vele opeenvolgende digitale en/of fysieke "papier-"stromen.
Of het in elkaar schuiven en optimaliseren van de gegevensverwerking rondom meerdere losse administratieve systemen.
Een voorbeeld over de as van "papier-"stromen: near-realtime registratie en verwerking van aankopen van producten en diensten; inclusief geautomatiseerde fiscale verrekening met de belastingdienst (versus achteraf verrekenen via het indienen van declaraties met bijbehorende bonnetjes) = iets wat vooral relevant is voor de medewerkers van (bijvoorbeeld) de Europese Commisie en buitenlandse ambassades.
Een voorbeeld over de as van het in elkaar schuiven van losse administratieve systemen: het administreren van opportuniteiten rondom adviesopdrachten, de daaropvolgende inzet van groepen interne en externe consultants, de financiele verrekening, bijbehorende facturatie en financiele analyses = alles near-realtime zodat er wekelijks en maandelijks helderheid is omtrent mogelijke opdrachten, beschikbaarheid van mensen en de cashflow.
Versus alle inzichten op het eind van de maand volgend op de maand waarin de uren/diensten feitelijk geleverd zijn = zoiets als een auto besturen met een nagenoeg permanente blik op de achteruitkijkspiegel.
Karakteristiek bij een dergelijke nocode aanpak is het bij elkaar klikken van stroomschema’s, gegevenselementen en de bijbehorende elkaar opvolgende bewerkingen. Hierdoor is er een enorme tijdwinst te boeken in vergelijking met een traditionele aanpak; waaronder de keuze van een data(base) model en query-taal. Dit is bij nocode allemaal niet of nauwelijks relevant.
Rob, nog even wat achtergrond info bij OpenRules.
Drijvende kracht achter dit platform is Jacob Feldman, zoals bovenaan de website staat vermeld.
Hij is schrijver van 2 boeken, die ik niet heb gelezen, maar de titels zijn veelzeggend:
- DMN in Action with Openrules (2017)
- Goal-Oriented Decision Modeling with Openrules (2019)
Hij volgt de DMN-standaard (DMN = ‘Decision Modeling and Notation’), maar is er ook kritisch over.
Hier bijvoorbeeld: https://openrules.wordpress.com/2018/06/18/keep-dmn-simple/
“However, today DMN is full of complex, programmer-oriented features which seem to get even more complex in new releases. There are plenty examples of unnecessary complexity being proudly promoted for their “elegance”. “
En verderop vetgedrukt:
“We need to keep the DMN standard oriented to business users.”
Naast DMN is hij ook voorstander van Goal Orientation, zoals blijkt uit zijn tweede boek.
En daarmee wedt hij, mijns inziens, op 2 verschillende paarden, die in tegengestelde richting lopen.
DMN is namelijk niet doelgedreven maar datagedreven. In mijn optiek gaat de Goal Orientation van OpenRules dus nog niet ver genoeg. Waarbij ik het verband tussen Goal Orientation en Service Orientation nu maar even laat voor wat het is.
Met deze informatie zijn we er nog niet, want dezelfde Jacob Feldman is ook de drijvende kracht achter de website: https://dmcommunity.org/challenge/
En dan vind ik dit berichtje van hem wel heel aardig:
https://dmcommunity.org/2021/04/14/which-rules-not-to-execute/
-------------------------------------------------------------
Will, bedankt voor je inzichten!
Daar ga ik nog even op kauwen :-)
@Jack, ik heb het verhaal gisteren doorgelezen en snap er nog niet veel van.
Is er sprake van een of andere engine waar vanuit wordt gegaan maar verder in het artikel (https://openrules.wordpress.com/2020/11/13/accessing-database-from-business-rules/) niet wordt genoemd? Is er ergens een relationele structuur waarin type (DataSQL) is uitgewerkt? Bijvoorbeeld Decision Table DefineTotals heeft vier kolommen - twee aan twee - (condition/conclusion) ieder met een onderverdeling van twee (Payment Amount etc. met daaronder 8 kolommen, twee aan twee (conditie/operator). Ik zie zo niet hoe ik hiervan een proof-of-concept kan uitwerken zonder eerst op een aantal onderdelen eerst het wiel opnieuw uit te moeten vinden.
mvg Rob
@Will, waar je m.i. over praat, is het automatiseren van de rol van de gebruiker. Dat is waar het bij ons ook voortdurend over gaat. Ik ben ook met je eens dat de keuze van de database model en query taal daarbij in principe niet belangrijk is, althans niet in meerdere mate dan dat die keuzen in het algemeen van belang zijn. Maar zeker ook niet in mindere mate.
Bijzonder hoe de discussie zich betreffende code ontwikkelt want de blackbox is niet de code van de front-end welke eenvoudig te vervangen is zoals Jack en zijn SOA vriendjes laten zien. Blackbox van de back-end gaat om achterliggende data architectuur wat steeds vaker een datalake is waar dynamisch de benodige informatie uit verkregen kan worden door het real-time combineren van data op een front-end device hoewel de QR-code voor toegang dus nog even statisch is als de beslissingstabellen van Jack. Ik heb de QR-code daarom maar gewoon uitgeprint want de belofte dat de locatiegegevens niet gebruikt worden is niet erg geloofwaardig uit de mond van een minister die alleen maar liegt.
@Rob
“waar je m.i. over praat, is het automatiseren van de rol van de gebruiker”
Is dat niet per definitie het geval? Als in: gaat het niet altijd om het (weg-?)automatiseren van gebruikersrollen? Tis te zeggen... mij lijkt dat dit de primaire driver zou moeten zijn achter de inzet van IT?!
Kan je het hooguit nog hebben over wie je dan als "gebruiker" ziet... :-)
=====
“althans niet in meerdere mate dan dat die keuzen in het algemeen van belang zijn. Maar zeker ook niet in mindere mate”
Hangt er vanaf uit welke elementen je lever- en verdien-model bestaat.
Als daar een vorm van (technisch) applicatie- en systeem-beheer bij zit klopt je stelling. Immers, de keuze voor een DBMS gaat gepaard met keuzes voor een onderliggend OS en infra; al dan niet afgenomen in IaaS- of PaaS-vorm. De mate en manier waarop je die combi beheer(s)t is leidend voor het rendement op die elementen van het lever en verdien-model.
Is het een model op basis van applicatiebouw en functioneel beheer (wat als SaaS-dienst wordt afgenomen = nocode), dan maakt het DBMS niet meer uit = iemand anders zijn probleem/vraagstuk. En daarmee een element in het lever- en verdien-model van die “iemand anders”.
=====
En dit is dan enkel het aspect “applicatie-techniek” - de aard van de opslag, de te verwerken gegevens en bijbehorende governance komt daar nog eens bovenop = moet ook beheer(s)t worden.
Voordeel is dat dit een generiek element is in welk model dan ook. Maar inhoudelijk wel eentje met een grote variëteit aan smaakjes: on-prem, cloud-storage voor backup, IaaS, PaaS, SaaS, etc. Laat staan als er gewerkt wordt me een hybride model...
@Will, Inzake automatisering van de rol van de gebruiker is dat - zoals ik het bedoel - niet per definitie het geval. Je automatiseert een toepassing of proces en dat vergt gebruikers. De gebruikers hebben vaak met meerdere applicaties te maken. Wij proberen die gebruikers te ondersteunen of routinematige taken zelfs over te nemen met Workflow/Robotic Process Automation. Het Worfklow process kan daardoor worden gezien als een (virtuele) gebruiker van de aanwezige applicaties. In iets groter verband worden applicaties daarmee elkaars gebruiker.
@Rob: ok – even een voorbeeld – als tjek op wat je bedoeld.
Stel je hebt een taak in een proces wat op dit moment 1 FTE aan tijdbesteding vraagt. Die tijd gaat op aan het herhaald uitvoeren van een serie clicks verdeeld over – zeg – 12 verschillende applicaties.
Dat wordt vervangen door een stukje (RPA-)software wat dezelfde clicks voor diezelfde applicaties doet. Waardoor je de rol van de gebruiker niet direct hebt vervangen; enkele degene die de rol vervult: dat was eerst die ene FTE (verdeeld over bijvoorbeeld 4 medewerkers) en is nu dat stukje RPA-software.
De business case zit hem er dan in dat de kosten voor die ene FTE substantieel hoger zijn dan (1) - de kosten voor die RPA-software, (2) - het inregelen en (3) - het beheer/onderhoud. Waarbij beheer/onderhoud, naar verwachting, vooral betrekking heeft op veranderingen in de gebruikersinterface van die 12 applicaties. Dit omdat de tjeks en clicks in de workflow van de RPA-software dan wellicht aangepast moet worden.
Zoiets? Ongeveer?
Ja, klopt helemaal in mijn visie. Maar er is meer. 1. de RPA zit op ieder moment klaar, terwijl sommige wenselijke acties bij een menselijke gebruiker mosterd na de maaltijd kunnen zijn. 2. Dat heeft een gevolg: uit het feit dat een actie nog niet heeft plaatsgevonden, kan worden afgeleid dat de geassocieerde gebeurtenis nog niet heeft plaatsgevonden. 3. De RPA-kan 1500, 2000 verwerkingen in een minuut afhandelen en dan weer dagen geduldig wachten. 4. De RPA (gebruiker) kan worden gevoed met wat hij zelf eerder heeft aangemaakt (voor backups, versie-migraties, dingen met een terugkerend karakter zoals abonnementsfacturen, (memoriaal) journaalposten van periodieke afschrijvingen en dergelijke).
@Rob:
“2. Dat heeft een gevolg: uit het feit dat een actie nog niet heeft plaatsgevonden, kan worden afgeleid dat de geassocieerde gebeurtenis nog niet heeft plaatsgevonden”
“4. De RPA (gebruiker) kan worden gevoed met wat hij zelf eerder heeft aangemaakt (voor backups, versie-migraties, dingen met een terugkerend karakter zoals abonnementsfacturen, (memoriaal) journaalposten van periodieke afschrijvingen en dergelijke)”
Ja – dat zijn inderdaad mooie use cases.
En als ik vragen mag: wat is een voor dit doel fraaie RPA oplossing?
Andere vraag: heb je ooit eens overwogen om dit soort dingen met Python in te regelen?
Rationale achter Python (afgaande op het begin van het artikel): heb je Python eenmaal onder de knie, dan zijn er legio mogelijkheden. Zowel aan de kant van de werknemer (toekomstperspectief) als voor een IT-dienstverlener (hogere automatiseringsgraad van beheertaken).
Je moet sneller dan je schaduw klikken om 1500 maal per minuut te klikken, probeer het maar eens met een stopwatch. Rob is dan ook niet echt realistisch als we kijken naar round-trip van de gebruikelijke online transactiesystemen welke niet van batchverwerkingen houden. Dat wil natuurlijk niet zeggen dat je via de achterdeur de truc niet kunt doen want scripts en job schedulers zijn niet echt nieuw en ik was altijd goed in mezelf weg automatiseren. Dat leverde weer de kennis voor loadtesten op want het juist dimensioneren van een systeem scheelt een heleboel geld, misschien wel meer dan de FTE die ook wat anders kan doen. Zo knijpen we Rob met zijn RPA via QoS want geen mens kan een factuur of journaalpost in een fractie van een seconde controleren. Je kunt die proces stap er natuurlijk ook tussenuit halen maar volgens mij pas je dan het business proces aan welke opeens tot een integriteitsprobleem leidt als er geen controle meer is.
@Oudlid, de controle e.d. zijn allemaal aansluitende workflow processen die òf in het asynchrone (vervolg)deel van de api call zitten òf via een message queue gaan. Die processen kunnen op een email-reactie zitten wachten, een voorraadcheck bij een leverancier moeten doen, een externe credit-check, een doorverwerking naar een erp-programma, enz. Daar hoeft de API-client allemaal niet op te wachten. Als we een API-client laten wachten en we zoeken een crediteur op (of we maken hem rudimentair aan, we een invoice header aanmaken, gemiddeld 2 à 3 factuurregels met lookup/rudimentaire aanmaak van voorraadartikel met lookup/aanmaak verpakkingseenheid/prijs van betreffende artikel, halen we toch echt wel circa 1800 facturen per minuut in een gecompileerde t-sql stored procedure (in een met NVMe SSD en 512GB RAM opgepimpt servertje van 6 jaar oud waarbij de betreffende virtual server dan circa 80GB krijgt). Moet je wel in 1 roundtrip de betreffende JSON List aanleveren in de SQL-server natuurlijk.
@Will, Python zou zeker een optie zijn. Kan ook in SQL-Server, dus geen van/naar van data. We zijn echter helemaal ingevoerd op T-SQL en ik denk dat Python ten opzichte daarvan toch nog wel wat beperkingen zou hebben en vermoedelijk geen extra mogelijkheden.
Rob,
Natuurlijk kun je fantastische prestaties halen als je alles in-memory op één server kan doen maar de realiteit na meer dan 30 jaar SOA is dat verschillende servers onderling communiceren via API-interfaces en message queue's waardoor de round-trip van één transactie steeds langer wordt omdat er steeds meer schakels aan de ketens toegevoegd zijn. En natuurlijk kun je eerst alle bestellingen consolideren zodat je één bestand hebt wat je middels een batchverwerking kunt laten doen maar daarmee pas je eigenlijk het proces zelf aan, je gaat van een online parallel proces waarin de transacties binnen druppelen naar een sequentieel proces waarin je in één keer een emmer leeg gooit. Die keus kan trouwens heel valide zijn als we kijken naar de aanpassing van tabellen maar ik vrees dat we het dan niet meer over de RPA van het automatiseren van klikken in de fornt-end hebben.
Klopt, het ging inmiddels over het automatiseren van de rol van gebruiker.
Ter aanvulling, jouw realiteit na 30 jaar SOA is inmiddels volkomen verouderd. Het kan echt allemaal slimmer.
Als ik kijk naar mijn dagelijkse realiteit waar welbekende 'bill of materials' al snel enkele honderden factuurregels heeft als ik het project tot in detail moet specificeren dan heeft concept van de online transactionele verwerking van één-voor-één duidelijk een voordeel in het maatwerk waarin de onderdelen van verschillende leveranciers op elkaar afgestemd moeten zijn. De beslissingstabellen van Jack gaan om de keuzevrijheid die je hebt want de massaproductie van een lopende band lijkt me verouderd als we kijken naar de marktveranderingen. Het kan dus inderdaad een stuk slimmer nu dingen sneller wijzigen en paradigma van SOA heeft naar mijn mening daarin een voordeel omdat de workflow sneller aan te passen is door het principe van 'disconnected processes' waardoor er minder afhankelijkheden in de keten zijn. Ik kan bijvoorbeeld winkelen bij de AH maar ook bij de Jumbo als beiden hetzelfde leveren en alleen nog op de prijs met elkaar concurreren. Slimmer wordt dan het welbekende kwaliteitsaspect van goedkoper hoewel het vaak lastig is om appels met appels te vergelijken doordat het vraagstuk van standarisatie uiteindelijk haaks op de commerciële belangen van de leverancier staat. Wij van WC-eend kennen dan ook de truc van business logica in proprietary code stoppen want Transact-SQL is volgens mij niet een open standaard.
@Oudlid, dat soort bill-of-materials-achtige processen is vaak al sinds edifact in voorzien. In onze gevallen gaat het om tot dan toe handmatig werk. Op de koppelvlakken volgen we zoveel mogelijk Odata. Mvg rob.
Will, als je het zo stelt is nocode niets anders dan orkestratie!
Je (zeer verhelderende!) reactie maakt duidelijk dat lowcode- en nocode-tools geen oplossing bieden voor het vormgeven van bedrijfsfunctionaliteit, zoals bij de vermelde passenger rebooking-challenge, maar voornamelijk een rol spelen bij het modelleren van opeenvolgende processen. Ik was dus inderdaad appels met peren aan het vergelijken.. :-)
Maar….
Is orkestratie niet een ander woord voor (proces)spaghetti?
Dan is het de hoogste tijd om procesmodellen te vereenvoudigen met beslissingstabellen:
https://blog.sapiensdecision.com/how-the-decision-model-drastically-simplifies-process-models/
die hier nog minder gelukkig decision models worden genoemd.
Het vervangen van procesmodellen (dus low/nocode) door beslissingstabellen (dus 5GL) is dus beslist een stap in de goede richting:
https://openrules.wordpress.com/2020/10/17/rules-based-service-orchestration/
al mag het van mij nog wel wat doelgerichter, zoals blijkt uit de hier vermelde Loan Origination example/challenge.
Op een website kwam ik de volgende evolutie van programmeertalen tegen:
3GL - 4GL – Lowcode – Nocode
Maar als Low/Nocode vooral een rol speelt op het vlak van de opeenvolgende processen, blijf je op het vlak van de bedrijfsfunctionaliteit dus afhankelijk van de duistere algoritmen van een 3GL en/of machine learning-code (ofwel de blackbox van Oudlid). Waarmee je dus blijft knoeien met de beruchte Business-IT-alignment.
Hierbij is Lowcode en Nocode dus een aanvulling op 3GL en 4GL; je opmerking
“Bij lowcode/nocode draait het om het versnellen van applicatiebouw – de onderliggende database-structuur en/of taal is daar niet of nauwelijks relevant” klopt dus precies.
In mijn optiek is de evolutie van programmeertalen echter – verrassing - :
3GL – 4GL – 5GL
waarbij 5GL wordt toegepast voor het beschrijven van functionaliteit (als vervanging van 3GL en aanvulling op – eventueel al bestaande - 4GL-databases) èn de end-to-end applicatieflow.
Zoals 3GL ooit ter vervanging diende van 1GL/2GL Machinetaal/Assembler.
Waar stroomschema's tekort schieten is het rekening houden met de persoonlijke situatie van de klant/burger; precies het punt waarop de belastingdienst steeds onder vuur ligt (toeslagenaffaire, schuldenbeleid, etc).
https://www.nu.nl/economie/6120737/belastingdienst-weer-onder-vuur-mensen-met-schulden-niet-goed-beschermd.html
Wil je wel rekening houden met de persoonlijke situatie van de burger met stroomschema's, dan leidt dat tot een onontwarbare processpaghetti/flowchartspaghetti. Wat je dus precies vermijd met het toepassen van beslissingstabellen/taal (en dan doelgedreven ipv. datagedreven)!
Waar het mis gaat met een nocode-aanpak is af te leiden uit de volgende formuleringen in je reactie:
“..stroomlijnen van grotendeels *sequentieel* uitgevoerde administratieve processen”
“..digitaliseren van vele * opeenvolgende* digitale en/of fysieke "papier-"stromen”
“.. elkaar opvolgende bewerkingen”
En dan wordt het tijd om één van de bekendste voorvechters van de beslissingstabellentechniek te citeren (in “De vaste waarden van de systeemontwikkeling” uit 2003, blz. 7):
https://www.frankrobben.be/publications-press/commemorations/prof-dr-maurice-verhelst/
“In dit verband moet worden opgemerkt dat het gebruik van flowcharts bij het programmeren een verderfelijke praktijk is; flowcharts behoren tot de slechtste technieken die men bij het programmeren ooit heeft gebruikt. Ze dwingen de programmeur sequentieel te denken en verhinderen juist daarom dat hij ruimtelijk denkt.”
Hoi Jack,
Zie inzake OpenRules s.v.p. de vragen in mijn reactie van 15 aug 14:37.
Evolutie is niet zo makkelijk, vooral als het de toekomst betreft. Evolutie is aanpassing aan real world veranderingen. Want Life is what happens to you, while you're busy making other plans. Dus braaf meebewegen met de agile naar de cloud movement. You'll never walk alone.
Wat hebben 4GL/5GL talen nu daadwerkelijk opgelost ? Het niet gebruiken ervan is geen complot of kennisgebrek. Het heeft momenteel (de laatste 30 jaar) alleen een beperkt toepassingsgebied. Als ik mijn programeeruitdagingen met alleen specificatie van input/output en paar tabellen kon oplossen, dan deed ik het meteen. Dat we als zowel niet- als wel-iters zoveel moeite hebben met specificeren, dat verklaart overigens ook de noodzaak van agile. Continuous gepruts, maar wel steeds stukkie beter result, hopen we dan maar. En als het design slecht bleek, wordt het uiteindelijk legacy. Dan beginnen we opnieuw.
@Jack:
"is nocode niets anders dan orkestratie"
Ok - maar geldt dat dan ook niet voor alle andere methodes van applicatiebouw? Immers, in de basis zijn applicaties erop gericht om bedrijfsprocessen te orkestreren (“meer-met-minder”)? Zodat het bedrijfsrendement toeneemt?
Inzake je verwijzing naar een artikel van Maurice Verhelst:
Dat gaat over flowcharts gebruiken bij het programmeren. Met de aanname dat Maurice doelt op het documenteren van algoritmes die vervolgens “een-op-een” vertaalt worden naar regels code kan ik me daar wel wat bij voorstellen. Alleen… dat staat los van “processpaghetti/flowchartspaghetti”... :-)
En nu we het daar toch over hebben: de “persoonlijke situatie van de burger met stroomschema's” kan prima. De bijborende “processpaghetti/flowchartspaghetti” komt doordat elke processtap meer uitzonderingen dan regels heeft – een 5GL en zijn beslistabellen doet daar niks aan af. Hooguit verplaatst het probleem zich naar een spaghetti aan beslistabellen vanwege het grote aantal onderlinge afhankelijkheden!
Rob, het verbaast mij een beetje dat het eenvoudige voorbeeld
Migrating Simple SQL to OpenRules
al vragen bij je oproept, terwijl het pas interessant wordt met:
Migrating More Complex SQL to OpenRules.
Het is duidelijk dat de eerste eenvoudige query veel meer records op gaat leveren als de conditie
p.amount 80000 AND o.status = 'In Process' uit de where clause wordt gehaald; om precies te zijn: 1277.
Inderdaad is er een engine die onder water deze records doorsluist naar een beslissingstabel waarin de verwijderde condities uit de query zijn opgenomen.
Persoonlijk vind ik het onderscheid tussen “technical logic” wat achterblijft in de SQL-query en “business logic” wat overgeheveld wordt naar de beslissingstabel niet handig, maar eerlijk gezegd vervang ik ‘logic’ sowieso liever door ‘functionaliteit’.
Het tweede voorbeeld is veel interessanter, niet omdat de query hier veel complexer is, maar omdat de bedrijfsregels in de beslissingstabellen complexer zijn. Het zou een interessante uitdaging zijn om deze regels alsnog in de SQL-query op te nemen, maar ik begin er niet aan :-)
En dan vind ik het Oudlid in zijn reactie van 19 augustus 2021 20:35 wel heel sterk als hij stelt:
“dan heeft concept van de online transactionele verwerking van één-voor-één duidelijk een voordeel in het maatwerk waarin de onderdelen van verschillende leveranciers op elkaar afgestemd moeten zijn.”
“… want de massaproductie van een lopende band lijkt me verouderd als we kijken naar de marktveranderingen.”
Ondertussen ben ik dus wel benieuwd naar een oplossing van OpenRules voor de eerder genoemde Rebook-challenge…
@Jack, SQL to Openrules is me wel duidelijk. Maar daarna wil ik nog wat met die Openrules tabellen. Zonder een of andere engine heb ik voor die tabellen geen toepassing. Zag bij het zoeken wel de link van Barbera von Halle die je later gestuurd had. Bedankt.
Rob,
Electronic Data Interchange (EDI) gaat om een elektronische uitwisseling van bepaalde berichten of bevestigingen tussen systemen (machine-2-machine) waarbij de structuur van de berichten strak gedefinieerd is. Dat klinkt als de 'lopende band' van een sequentiële verwerking welke in de dagelijkse realiteit al lang is vervangen door een onderlinge data uitwisseling middels Systems of Engagement die zich ondertussen evolueren naar Systems of Collaboration waardoor het winkelen bij verschillende winkels met dezelfde producten een stuk makkelijker is als de onderliggende Systems of Record 'losjes' met elkaar verbonden zijn. De flexibiliteit van SOA heeft zich ondertussen geëvolueerd tot een spaghetti aan microservices in de cloud waarbij de gebruiker zich niet druk maakt om wat er onder de motorkap gebeurt maar als code de motor is dan is data de brandstof. OpenRules en Open Source zijn twee kanten van dezelfde medaille want het zijn uiteindelijk niet de algoritmen die schuldig zijn aan vooringenomenheid. En als het om de doel oriëntatie van Sein und Zeit gaat dan is het de vraag tot hoever we terug moeten in de tijd want de sequentiële vraag over de IST en SOLL kent een begin- en een eindpunt waarbij het continuous gepruts van goed naar beter en best een overtreffende trap kent die om een vergelijking gaat.
Will, als je stelt “in de basis zijn applicaties erop gericht om bedrijfsprocessen te orkestreren”, dan heb je daarmee precies de motor van de aanhoudende IT-faalindustrie te pakken (die ook wel bekend staat als ‘digitalisering’).
Die motor wordt namelijk precies gekenmerkt door:
machinedenken, datadenken, procesdenken, systeemdenken, modeldenken, logica, wiskunde
Kortom, denken vanuit een digitale mindset.
Als je stelt dat “het probleem zich naar een spaghetti aan beslistabellen” verplaatst heb je gelijk als beslissingstabellen nog datagedreven worden verwerkt. Een doelgedreven ‘verwerking’ van beslissingstabellen maakt echter een stapsgewijze verfijning van doelen mogelijk, en dat is op geen enkele manier nog spaghetti te noemen!
Zo’n stapsgewijze verfijning van doelen kun je aantreffen op bladzijde 3 in mijn oplossing voor:
https://dmcommunity.org/challenge/challenge-june-2017/
en noem ik: Decision overview.
In DMN wordt dit overzicht een Decision Requirements Diagram (ofwel DRD) genoemd, en de DRD voor de challenge kun je vinden in hoofdstuk 11 van de DMN-specificatie (eerste linkje in de beschrijving). Om precies te zijn in Figure 11-2: DRD of all automated decision-making.
Of hier nog sprake is van spaghetti mag je zelf beoordelen.
Inmiddels ligt het procesdenken bij DMN-adepten flink onder vuur als je op deze website rondklikt:
https://www.decisionautomation.org/dmn-challenges
Op verschillende plaatsen lees ik:
…..the incorrect assumption that decision automation is normally part of a BPMN process.
Workflow tools with BPMN and case tools are seldom used to orchestrate larger decision automation problems.
Decisions without processes?
….
Jack, je voorbeeld (challenge june-2017) bevestigt voor mij niet alleen het procesmatig werken maar ook nog eens de loketgeest (pre/post?) waarbij je de spaghetti opknipt in de matrix van Excel. Heb je ook rode pillen om ons de werkelijkheid buiten je modellen te laten zien?
Oudlid, rode pillen zouden inderdaad een uitkomst zijn voor wetenschappers en politici die het contact met de werkelijkheid helemaal kwijt zijn (en neem er dan zelf ook één).
Maar het idee dat je hiervoor pillen zou kunnen gebruiken bevestigt weer eens je wetenschappelijke, materialistische visie.
In het verleden heb ik je wel eens een reductionist genoemd (als in: https://nl.wikipedia.org/wiki/Reductionisme), maar ondanks dit reductionisme verval je niet in een monisme (waar een reductionisme vaak op uitdraait) maar in een visie waarin nog steeds een dualisme (van lichaam en geest) is terug te vinden. Tot zover dan het goede nieuws, want het lijkt er op dat je het reductionisme vervolgens aan weerszijden van de kloof uitvoert: aan de ene kant de materiële processen (en dat zal wel een vorm van neuronenwerking zijn) en aan de andere kant de geestelijke processen. Dit reductionisme aan weerszijden van de kloof komt ook mooi tot uiting in jouw idee van “digital twins”.
Dat je filosofische inzichten niet uit de weg gaat blijkt wel uit het vermelden van het begrip ‘loketgeest’.
Als ik op deze term zoek krijg ik naast jouw reactie alleen een pdf met een vergeeld document uit 1956 met een herdenkingsrede voor het 10 jarig bestaan van Humanitas. De zin waarin loketgeest voorkomt is veelzeggend: “In de openbare zorg overheerste naar onze smaak nog te veel de loketgeest, de dorre ambtelijke geest die in de hulpbehoevende alleen maar zag een geval en te weinig de mens“. Het lijkt er dus op dat jouw begrip “loketgeest” van eigen makelij is, en dat is een ontwikkeling die ik alleen maar kan toejuichen :-)
Je visie is die van een wetenschapper/technoloog die zijn materialisme aanvult met filosofische inzichten; een positie die precies is terug te vinden in (jouw waardering voor) het “systemisch” denken en het daaraan gekoppelde onderscheid tussen onderstroom en bovenstroom. Het begrip ‘systemisch’ wordt vooral ingezet door wetenschappers die zich wagen op filosofisch terrein zonder hiervoor over adequate filosofische kennis te beschikken.
Dat je nu vraagt om rode pillen om de werkelijkheid buiten de modellen te kunnen zien is precies waar het systemisch denken tekort schiet: er is een dualisme en parallellisme van bovenstroom en onderstroom, zonder enige mogelijkheid om de wisselwerking tussen beide te kunnen denken. Waarmee het systemisch denken nog altijd gevangen is in het Cartesiaans dualisme tussen lichaam en geest; conform het thema van “the Matrix” en jouw vraag om rode pillen.
Om de kloof te kunnen overbruggen heb je niet een pil nodig maar een begrip: intentionaliteit.
Intentionaliteit is een sleutelbegrip in de fenomenologie zoals ontwikkeld door de Duitse filosoof Edmund Husserl (1859-1938).
Zie bijvoorbeeld:
https://en.wikipedia.org/wiki/Phenomenology_(philosophy)
Intentionaliteit is hier de gerichtheid van het bewustzijn op de dingen; tegenover Descartes' 'ik denk' (dus 'ik ben') stelt Husserl dat denken altijd iets denken is en dat bewustzijn altijd bewustzijn van iets is; een losstaand cartesiaans 'ik denk' bestaat dus niet.
Maar intentionaliteit kun je ook begrijpen als doelgerichtheid!
Als ik een appeltaart maak ben ik mij ook – enigszins – bewust van het ding dat ik aan het maken ben. Maar als het maken van een appeltaart een gewoonte is, bijvoorbeeld omdat ik elke week zo’n ding maak, komen hier nauwelijks beslissingen aan te pas en handel ik op de ‘automatische piloot’.
Tijdens het maken van de appeltaart kan ik dus aan heel andere zaken denken, zodat hier sprake is van een parallellisme tussen denken en doen (toch weer een dualisme!). Op het moment dat zich een verstoring voordoet bij het maken van de appeltaart, bijvoorbeeld omdat de appels verrot blijken, kom ik – vanuit het denken aan heel andere zaken - terug in de keuken waar ik aan het werk ben en beslis dan – opnieuw denkend - of ik nog snel naar de supermarkt ga om nieuwe appels te halen of dat ik de appeltaart deze keer maar laat zitten.
Beslissingen vereisen dus doeloriëntatie en komen niet tot stand in datagedreven processen.
Ondanks het feit dat jij geen enkele kennis hebt van de filosofen die er werkelijk toe doen - en de grote 3 van de filosofie van de twintigste eeuw kun je precies naast elkaar op de eerder gegeven wikipedia-pagina aantreffen - kunnen we over het voorgaande nog wel even verder filosoferen.
Het parallellisme tussen denken en doen is doorJoke Hermsen al beschreven in haar prachtige, zeer aanbevolen essay Windstilte van de ziel (2010, blz. 37): “Sinds pakweg twintig jaar werk ik de gedachte uit dat de mens op z’n minst met zijn tweeën is – een zichtbare en omschrijfbare identiteit enerzijds en een onbewust en onzegbaar zelf anderzijds – maar aan dat zelf heb ik nooit eerder de naam ‘ziel’ gegeven. Sterker nog, ik geloof niet dat het woord ‘ziel’ ooit bij me opgekomen is in dit verband. “
Maar dan vervolgt zij: “Hoewel ik niet denk dat ziel en zelf hetzelfde zijn, …”
en ben ik het volledig met haar eens.
Zowel ziel als zelf hebben te maken met werkelijkheid en in het zeer leesbare Realisme herwonnen (2016), vertaling van Retrieving realism (2015), zijn filosofen Charles Taylor en Hubert Dreyfus beide op het spoor:
“We verlaten het bemiddelde beeld (en dus ook de modellen – JJ) en gaan uit van een contacttheorie. Ons begrip van de dingen zit niet in ons, los van de werkelijkheid, maar bestaat in de manier waarop we met de wereld in verbinding staan, in ons in-de-wereld-zijn (Heidegger) of ons tot-de-wereld-zijn (Merleau-Ponty). “
Zowel ziel als zelf, en dus ook werkelijkheid, ontbreken volledig in jouw visie.
Maar dat geldt helemaal voor wetenschappers/architecten zonder enig gevoel voor filosofie die gewoon verder blaten over digitale mindsets.
PS. Je toevoeging (pre/post?) achter loketgeest is wat mij betreft ijzersterk.
Want pre is: eerst denken, dan doen. Bijvoorbeeld als ik iets voor het eerst doe.
En post is: eerst doen, dan (eventueel) denken; de eerder genoemde gewoontehandelingen.
In het eerste geval heb ik doelen; in het tweede geval hebben de doelen mij!
In geval van gewoontehandelingen blijft datgene wat je tot stand brengt voorbewust of onderbewust (maar zeker niet onbewust), en komt het denken pas achteraf als iemand vraagt wat je aan het doen bent of als er iets fout gaat. Doe je iets voor het eerst, dan stel je je wel eerst het eindresultaat voor – een nieuw gerecht bijvoorbeeld - en werk je hier meer bewust naar toe. Op dat vlak kun je weer mooi nadenken over mindfulness versus soulfulness (J. Hermsen).
Merk op dat in gewoonte ook wonen zit, en in het nadenken hierover komen we uit bij de ethiek.
Het begrip 'ethos' (van het Griekse ethos) duidt oorspronkelijk op de plek van het wonen, in een uitgebreidere betekenis ook op de rol, het karakter, en later ook wel op 'gewoonte' of 'zede'.
Jack,
Je vergeet in je betoog van de doeloriëntatie de pre(setting) van een vertrekpunt, in het dualisme van schipperen en polderen niet onbelangrijk. Verder stelt een Cruyffiaanse wijsheid dat het goede doel het tegenovergestelde doel van je eigen doel is. Als het om de doeloriëntatie van me, myself and I gaat met de Angelsaksische mindfulness gaat dan lijkt de ontdekking van westerse filosofen me een erg eenzijdige visie op de wereld als het om systemisch denken gaat. Oja, de dimensie van een loket is een raamopening zonder uitzicht naar buiten.
In de hedendaagse sociaal politieke mores gaat ethos meer om het imago doordat het Cartesiaans dualisme tussen lichaam en geest van een zichtbare en omschrijfbare digitale identiteit geen direct relatie meer heeft met de fysiologische wereld. De wetenschap gaat hierin om een dogmatisch autoriteitsgeloof welke allesbehalve verlichting geeft, de mens wordt namelijk gedehumaniseerd object en dorre ambtelijke geest heeft hierbij de empathie van een boekhouder. Wat betreft de morele filosofie ben ik benieuwd hoe je een identiteit weet te omschrijven zonder dat je discrimineert.
Het boek van Verena Mayer ‘Edmund Husserl, denken zonder oordelen’ geeft richting d.m.v. Husserls fenomenologische methode in de dagelijkse praktijk.
UIT HET VOORWOORD:
Husserl’s motto ‘Zu den Sachen selbst’ vraagt om een evenwichtige denkgeest. De fenomenologische methode heeft vele sporen achtergelaten: in de filosofie van de geest, de relatie denken-taal-communicatie, pedagogiek enz. Deze herkenning betekent dat leiderschap reflectie en distantie vereist, dat wijsheid voorbij kennis ligt, dat ruimte geven, echt luisteren en samenhangen
Isbn 9789079133253
Daniël,
Gaat westerse filosofie ondertussen niet meer om het lezen van boeken dan het luisteren naar mensen? Deze belezenheid vergeet de taal van het ongeschrevene welke vooral om het lichamelijke zijn gaat. En wat betreft leiderschap is er dan ook een groot verschil tussen managen en leiden, de zelfreflectie van empirische wijsheid levert nu eenmaal kennis op die erg moeilijk vast te leggen is in woorden. In de relatie denken-taal-communicatie kun je een extra dimensies aanbrengen met gevoel hoewel het betreffende de pedagogiek tegenwoordig natuurlijk helemaal fout is om te leren door te voelen. De oude tucht van naar bed zonder te eten omdat je weigerde te bidden voor bruine bonen had naar mijn opinie ook zijn waarde maar dat terzijde. Aangezien beslissingen altijd om een oordeel gaan lijkt het me heel moeilijk om te denken zonder oordelen, ik wees daarom op de discriminerende vooroordelen die het denken al in een bepaalde richting kaderen.
Daniël, dat is wel een heel mooie toevoeging aan mijn vorige betoog!
Over de fenomenologie van Husserl zijn al bergen literatuur verschenen, maar deze studie is heel actueel en relevant.
Zelf raakte ik begin jaren 90 bekend met deze denkrichting door het boek van de Nederlandse cultuurfilosoof prof. C.A. van Peursen: Fenomenologie en Analytische filosofie (1968). Ook zeer degelijk is het overzichtswerk van prof. Bakker: De geschiedenis van het fenomenologisch denken (1964, 1974), met hoofdstukken gewijd aan Husserl, Scheler, Heidegger, Sartre, Merleau-Ponty (en in een latere editie toegevoegd: Levinas).
Ik kan het niet nalaten om een online versie van het geadviseerde boek op te zoeken, zoals hier:
https://www.deslegte.com/files/samples/books/9789079133055.pdf
en enkele relevante passages over te nemen ten aanzien van de in mijn vorig betoog genoemde filosofen:
Blz. 15, over Husserl:
Husserl volgt de bewustzijnsverbanden van Brentano waar deze bewustzijn als wezenlijk intentioneel beschouwt. Dat betekent dat bewustzijn niet simpelweg uit data bestaat die zich door randomcausale processen in het denkvermogen voordoen. Het staat altijd al in verhouding tot de wereld; het is altijd bewustzijn van iets en het geeft deze objecten zin.
Blz. 188, over Merleau-Ponty:
Merleau-Ponty, die dichter bij Husserl staat dan Sartre en Levinas, was een van de eerste bezoekers van het in 1939 opgerichte Husserl-Archief in Leuven. Zijn fenomenologische variant concentreert zich op het eigen lichaam als het hart van de wereldervaring en -constitutie. Hij ontwikkelde op basis van Husserl’s beschrijvingen een fenomenologie van de waarneming die nog steeds in de kunstmatige intelligentie en de robotica gerecipieerd en omgezet wordt. MerleauPonty is een belangrijke brug die Husserl naar de cognitiewetenschappen leidt.
Blz. 195, over Dreyfus:
In de receptie van Husserl in de cognitiewetenschappen kreeg de concurrentie tussen Husserl en Heidegger een vervolg. Zo heeft Hubert Dreyfus een verwantschap van Husserl’s fenomenologie met bepaalde ontwikkelingen in de kunstmatige intelligentie geconstateerd.
In 1973 heeft Marvin Minsky aan het Massachusetts Institute for Technology (mit) een geheugenstructuur (frames) voorgesteld die alledaagse kennis moest representeren, waarbij het hoogste niveau onveranderlijke informaties (analoog aan Husserl’s noëmatische kern) moest bevatten, terwijl de lagere niveaus contextafhankelijk gespecificeerd moesten worden.
Volgens Dreyfus kan Husserl als computationist begrepen worden omdat hij net als de kunstmatige intelligentie de wereld als een ‘systeem van overtuigingen’ beschouwt. Dreyfus, zelf een criticus van de kunstmatige intelligentie, steunt echter op Heidegger en contrasteert diens begrip in-de-wereld-zijn met Husserl’s begrip intentionaliteit.
------------------------------------------------------------------------------------------------------
Tot zover de citaten; woensdag heb ik de papieren versie in mijn brievenbus.
Bedankt voor je waardevolle tip!