CWI onderzoekt verkleinen softwareprogramma's

Het Centrum Wiskunde & Informatica begint een onderzoek naar methoden om programma's kleiner te maken door het toepassen van domeinspecifieke talen. Software zou zo efficiënter worden en een hogere kwaliteit krijgen.

Bestaande code voor software is veelal uiterst complex en daarom kostbaar om te onderhouden of uit te breiden. Bovendien bevatten de soms miljoenen regels code grote aantallen fouten die niet altijd worden gezien. Domein-specifieke talen, oftewel dsl's, zouden volgens prof. dr. Paul Klint van het CWI programma's aanmerkelijk kleiner kunnen maken, waardoor software in de toekomst veel sneller is te ontwikkelen. Een factor tien tot vijftig zou haalbaar zijn.

Dsl's zijn, in tegenstelling tot de meest gebruikte programmeertalen, gespecialiseerde talen die software binnen een afgebakend domein beschrijven. Bestaande voorbeelden zijn sql voor databasetoepassingen en html voor webopmaak. Voor een groot aantal toepassingen zouden er echter nog geen of onvoldoende efficiënte dsl's bestaan. De studiegroep software analysis and transformation aan het Centrum Wiskunde & Informatica wil onderzoek gaan doen naar het ontwerpen en toepassen van dsl's, nadat het subsidie heeft gekregen van het NWO.

Een van de vragen die de studiegroep wil beantwoorden is hoe een specifieke taal voor een bepaald domein het best kan worden ontworpen en hoe deze goed is te implementeren. Daarbij wordt gekeken naar metaprogrammeren. Via deze methode kunnen programma’s andere programma’s als data gebruiken. Tijdens het onderzoek wordt bestaande software voor diverse doeleinden bestudeerd. Uit deze kennis moet een dsl kunnen worden afgeleid, waardoor toekomstige code voor een bepaald domein efficiënter kan worden geschreven.

Als een praktijkvoorbeeld noemt Klint het ontwikkelen van dsl's voor forensische toepassingen. Zo heeft het CWI in samenwerking met het Nederlands Forensisch Instituut bekeken of er dsl's kunnen worden geschreven om scanprogramma's te ontwikkelen die zoeken naar data op opslagmedia. Het onderzoek van de studiegroep gaat vier jaar duren. Volgens Klint zullen de onderzoeksresultaten en de bijbehorende code zo veel mogelijk als opensource beschikbaar komen.

Reacties (109)

[Jeroen]

Dit klinkt wel als een goed idee, maar als je gaat nadenken over mogelijke toepassingen van een DSL zoals dat gaat met SQL en HTML dan kom je niet gauw heel ver.

Andere voorbeelden van DSLs zijn de scripts voor Mathematica, Matlab en Spreadsheet formules. Toch zijn dat een ander soort DSLs naar mijn gevoel, omdat HTML en SQL heel algemeen toegepast kunnen worden maar deze dingen alleen binnen het idee van een specifiek programma ergens op slaan.

Toch is het blijkbaar wel mogelijk om op deze manier sommige problemen beter op te lossen: "Language oriented programming is a style of computer programming in which, rather than solving problems in general-purpose programming languages, the programmer creates one or more domain-specific programming languages for the problem first, and solves the problem in those languages." Het is een strategie die zeker in sommige gevallen waarschijnlijk de moeite waard is, als mensen die mogelijkheid in acht nemen dan zouden we best wel betere software kunnen krijgen.

[Reactie gewijzigd door Jeroen op 23 juli 2024 09:31]

[Canaria]

Toch zijn dat een ander soort DSLs naar mijn gevoel, omdat HTML en SQL heel algemeen toegepast kunnen worden maar deze dingen alleen binnen het idee van een specifiek programma ergens op slaan.

Nee, HTML bestaat ook alleen "binnen het idee" van de interpreter: de browser. Dat internetbrowsers door meer mensen worden gebruikt dan Mathematica doet daar niets aan af. Met Mathematica kun je wiskundige, bouwkundige, medische, elektrotechnische of welk domein (een hoger niveau domein dan de DSL zelf) data verwerken.

[Canaria]

Aan DSLs is niet alleen een voordeel bij het ontwikkelen verbonden maar ook, misschien nog belangrijker, bij het beheersbaar houden van de applicaties.

De rol van ontwikkelaars verschuift daarnaast: in plaats van complexe business logic te formaliseren, ontwikkelen ze een DSL "framework" met bouwstenen in de vorm van herbruikbare componenten. Het is dan mogelijk dat business analysts zelf de business logic gaan modelleren door gebruik te maken van de DSL.

De ontwikkelaars kunnen zich dan richten op optimalisatie en koppeling van de bouwstenen met de service- en datalaag tot een applicatie, al zal die rol langzaam worden overgenomen door software factories.

Persoonlijk vind ik deze ontwikkeling jammer, omdat ik het modelleren van de business logic layer het leukste vond aan het programmeerwerk dat ik heb gedaan.

[Verwijderd]

> Software factories?
Geloof je het zelf?

En business analysts die zelf ook maar iets met logica gaan doen? Ik dacht van niet. In bepaalde domeinen, ja, maar dat is zo ongeveer 0.1% van de markt als het al niet een stuk minder is.

[Verwijderd]

Dat zeg je nu, maar je kunt je DSL ook grafisch maken hoor! Bij een 'language' denk wellicht aan code, maar het kan ook een diagram zijn, of een andere grafische weergave.

Veel business analysts gebruiken tools als M$ Visio om diagrammen te tekenen. Een dsl implementatie kan best die diagrammen interpreteren en aan de hand daarvan de software genereren. De techneut (lees degene die de DSL maakt) onderhoudt de DSL, en de code-generator/interpreter die erbij komt kijken.

WYSIWYG programming wordt het dan bijna. Akkoord; zover zijn we nog niet, maar het is zeker mogelijk.

[mashell]

dat business analysts zelf de business logic gaan modelleren

In mijn beleving heb je dan precies een harde techneut nodig om met 1 simpele vraag alle hete lucht uit de business bla bla ballon te laten lopen. Als je de complexe business logic in herbruikbare componenten te vangen is, dan is het niet complex. We hebben het hier immers niet over excel macro's.

[kh65]

Kan het niet nalaten ook te reageren.

Voor de context:
Ik heb zelf redelijk veel ervaring (een jaar of 25) in het bouwen van software en
zelfs in het bouwen van frameworks en een RAD omgeving.
Hoef je niet te geloven, maar het is wel zo ;-)

Enerzijds vond en vind ook ik DSL's (zoals andere posters) niet altijd goed toepasbaar.
Het is deels een andere vorm van een library van voorgebakken sourcecode.
En het is, net als bij een library, niet eenvoudig flexibel te maken dat hij overal inzetbaar is.

Anderzijds denk ik wel dat er aan het concepts van DSL's wel mogelijkheden en
toegevoegde waarde kan zitten.
Toen Microsoft in Visual Studio 2008 ook DSL's mogelijk maakte is deze mogelijkheid
uitgeprobeerd door verschillende partijen. Bijv. een commercieel bedrijf als Ordina.
Wat ik daarvan heb opgevangen (heb er gewerkt, ken daar mensen) is bijv. dat het
afdwingen van een uniforme software architectuur best goed gaat door DSL's te gebruiken.
Een doorgewinterde softwarebouwer (reken ik mezelf ook toe) zal
zijn neus ophalen, want die architectuur maak je toch automatisch uniform...
Maar in de praktijk zijn er bij het gemiddelde bouw-traject ook heel veel 'junior' bouwers,
die (en daarmee het project) toch wel geholpen zijn bij een voorgeschreven structuur.
En dat is iets wat je met een DSL best wel kunt doen.
Wel is het jammer dat je die DSL's (en de sourcecode erachter) voorlopig nog zelf moet maken...

En op een hoger niveau vind ik dat we bij het schrijven van de meeste software
veel te vaak, voor veel te veel dingen elke keer opnieuw het wiel uitvinden.
Hoe vaak er in Nederland al niet een bankrekening 11-proef check is geschreven
dat wil je niet weten (en dan bedoel ik voor dezelfde programmeertalen).
Hoeveel software niet een eigen 'adressen-beheer' of 'persoons-administratie'
heeft dat zal ook in de duizenden in Nederland alleen al lopen.
Met allerlei code die elke keer opnieuw wordt uitgevonden waarvan iedereen
denkt dat het niet kan worden ingevuld met 'standaard' software of componenten.
Ik denk dat we daar nog heel veel te winnen hebben.
En DSL's is daar ook een poging toe (net als component based development, SOA, etc.)

Persoonlijk heb ik twijfels of DSL's over 5-jaar gemeengoed zullen zijn.
Maar tegenover research m.b.t. DSL's sta ik niet negatief.
Volgens mij leer je er best iets van...

[.oisyn]

En het is, net als bij een library, niet eenvoudig flexibel te maken dat hij overal inzetbaar is.

Lol. Waarom denk je dat het een domain specific language heet?

[Verwijderd]

Besef ook dat het bouwen van DSLs ook valt en staat met goeie tools die het bouwen ervan vergemakkelijken!

Je kunt een DSL in Java schrijven, de old-school way, maar je hebt tegenwoordig gewoon tools (eclipse plugins bijv.) die erg snel complete DSLs genereren, met parsers, editors met syntaxhighlighting, debuggers, etc.

Dit is ook typisch iets waar het CWI onderzoek naar kan doen. De Universiteit Twente doet hier overigens ook veel onderzoek naar.

[CMG]

Dit klinkt gewoon als RAD (Rappid Application Development) middels frameworks als .NET en Java?

[Rob Coops]

Klinkt wel zo is het niet

Het idee is meer dat je in plaats van het wiel keer op keer uitvinden en een programma van de grond af op nieuw schrijven je op een hoger niveau gaat werken en bijvoorbeeld een ander programma aan roept met de data die jij hebt om vervolgens de output van dat programma weer te gebruiken en aan een ander programma te geven om veder te verwerken.
.NET is nog steeds een redelijke low level oplossing waarbij de persoon die het verhaal schrijft nog erg veel kennis moet hebben van de programmeertaal. En juist dat laatste is niet echt handig voor veel wetenschappers.

Een collega van me om schreef zijn switch van nucleaire wetenschap naar programmeren eens op de volgende manier: Als je atoom onderzoek doet dan moet je nog al wat berekeningen uitvoeren, toen de eerste computers beschikbaar kwamen werd mij verteld dat ik die dingen moest gaan gebruiken omdat ze veel sneller en accurater konden rekenen dan ik. Dus er werd een aantal programmeurs aangewezen en ik begon ze mijn berekeningen uit te leggen... al snel vroeg ik hun om dat programmeren aan mij uit te leggen omdat zij niets van mijn berekeningen snapten.
Nu is deze persoon die ik hierboven noem toevallig een hele goede programmeur (heeft mede het DHCP protocol ontwikkeld om maar eens wat te noemen) Maar voor de meeste wetenschappers geldt dat ze nu eenmaal wetenschapper geworden zijn omdat ze daar goed in zijn en geen programmeur omdat ze daar minder goed in zijn. Voor hen is het heel erg handig als er een taal komt waar in ze met een aantal standaard bestaande programma bouwstenen een nieuwe betere oplossing kunnen bouwen. Want om hun wetenschap aan een developer uit te leggen is lang niet altijd een makkelijk iets.

[Verwijderd]

Dat iemand wetenschapper is geworden zegt niets over zijn programmeer kunsten. Echter, je kunt je tijd maar aan één onderwerp tegelijk besteden. En dan besteed je liever je tijd aan het echte probleem, dan aan de hulpmiddelen!

Precies een van de redenen waarom LabVlEW zo populair is. Volwaardige programmeertaal, maar wel met handige shortcuts, zodat je niet constant het wiel opnieuw moet uitvinden. zelfde geldt voor Matlab ed.

Het is niet een kwestie van "goed zijn", maar een kwestie van efficiëntie!

[TheGhostInc]

Dit klinkt gewoon als een first-post.

Waar ze het hier over hebben is talen als Erlang, maar ook bijvoorbeeld Ruby on Rails neigt hier naartoe. Maar denk bijvoorbeeld ook aan OpenGL of de nieuwe extensies voor GPU programmeren. De taal legt al veel meer het gebruik vast.
.NET en Java zijn nu net 2 "universele" talen, alles kan geschreven worden in een van die talen.

[Reactie gewijzigd door TheGhostInc op 23 juli 2024 09:31]

[CMG]

Toch zijn het frameworks die grote delen 'common' code vervangen waardoor je sneller applicaties kan ontwikkelen. Het artikel beschrijft common issues bij de oude unmanaged talen en is allemaal veel minder van toepassing op de nieuwere talen.

En wat is er FIPO aan mijn opmerking? Ik heb gewoon het artikel gelezen en mijn mening als programmeur gegeven.

[Bosmonster]

Alleen slaat je mening als een tang op een varken, aangezien het hier gaat om DSL's als oplossing en niet universele frameworks, wat juist een tegenovergesteld principe is.

Het idee van DSL's is juist dat je veel "kleine" specialistische talen krijgt en juist niet dat je één universeel framework hebt waar je heel veel mee kunt.

[Reactie gewijzigd door Bosmonster op 23 juli 2024 09:31]

[ZpAz]

Maar al die 'specialistische' dingen vormen samen waarschijnlijk een 'library' die je kan gebruiken, bijvoorbeeld als het Zend Framework voor PHP, je kan alles gebruiken, maar ook enkel bijvoorbeeld de Mail klasse.

[captain007]

Nee niet echt. Je moet het zien als talen voor specifieke doeleinden. Bijvoorbeeld HTML kan je zien als een DSL, aangezien het een domein specifieke taal is voor de opmaak van webpagina's. Echter kun je DSL's ook voor andere toepassingen gebruiken, zoals het beschrijven van hypotheken. Bij het CWI hebben ze daar wel eens een case study naar gedaan en de taal RISLA hiervoor ontwikkeld.
Daarnaast kun je DSL's ook goed gebruiken voor compiler generators om grammatica van een taal te beschrijven bijvoorbeeld. Ook ben ik zelf wel eens DSL's tegen gekomen om aansturingen van motion controllers voor mechatronici eenvoudiger te maken. Je moet DSL's dus niet zien als een library, maar een taal om de problemen die je moet oplossen in het specifieke domein uit te kunnen drukken.
Nadeel echter van DSL's is vaak dat het ontzettend veel tijd en inspanning vergt om het goed van de grond te krijgen. Je moet zelf namelijk de grammatica verzinnen en daarvoor een parser en interpreter bouwen en die blijven onderhouden. Nu is er de laatste jaren veel geëxperimenteerd met tooling om dit te doen. Microsoft heeft het geprobeerd met Microsoft "Oslo" (tegenwoordig SQL Server Modelling Services), maar daar is het de laatste tijd ook weer redelijk stil. Ik zie dus niet snel de komende jaren een doorbraak op dit vlak, maar het is natuurlijk wel goed dat er onderzoek wordt gedaan naar dit gebied.

[TheGhostInc]

Wat je vergeet is dat je framework ook gewoon opgebouwd is uit code, en dus ook uitgevoerd wordt. Alle bugs in je framework tellen ook mee in je totale bug count.

Daarnaast telt ook alle ontwikkeltijd in een framework (gedeeltelijk) mee aan de ontwikkeltijd van jouw applicatie. Efficiëntie betekent niet dat je iemand anders jouw werk laat doen (overigens wel slim), maar dat iedereen minder werk hoeft te doen.

.NET en Java kosten nog steeds heel veel tijd om te ontwikkelen en bugfixes door te voeren. Een taal die simpeler is, is eenvoudiger te beheren en wanneer het programmeren ook eenvoudiger is in die taal, dan krijg je een veel efficiëntere taal. Althans, dat is natuurlijk de onderzoeksvraag.

FIPO was een grapje, omdat je een FIPO hebt, je vraag is prima

[YopY]

Wat je vergeet is dat je framework ook gewoon opgebouwd is uit code, en dus ook uitgevoerd wordt. Alle bugs in je framework tellen ook mee in je totale bug count.

+1, maar nu je dat zo zegt, dat heb je immers ook in DSL's (wat mij overigens weer een dure term lijkt voor een interpreted programmeertaal), en in de interpreter daarvan kunnen ook bugs ontstaan. De taal zelf kan zelfs niet kloppen of toereikend zijn, waardoor je zaken krijgt zoals bij SQL, maar ook het in het artikel aangehaalde HTML en daarbijhorende CSS en Javascript - iedereen heeft er zijn eigen ideeën over, en daardoor krijg je verschillende implementaties en daardoor weer bugs en workarounds en zooi.

Ik geloof nooit dat een DSL zoveel problemen oplevert. Hoe vaak wordt bijvoorbeeld een nieuwe programmeertaal ontwikkeld voor een specifiek probleem? Ook de toepasbaarheid van DSL's is beperkt - ik ga niet gauw even een nieuwe programmeertaal ontwikkelen om één bepaald probleem op te lossen, dan maak je juist meer problemen dan dat je ze oplost.

[latka]

Een DSL is vrij lastig te maken en als je deze vrijgeeft zul je zien dat er bergen bugs inzitten, dus problemen leveren DSLs in de praktijk wel op. Al is het maar omdat meestal niet de moeite wordt genomen te definieren wat de exacte syntax en semantiek zijn.

Overigens, in de praktijk kom je ontzettend veel DSLs tegen. Sommige zijn Turing compleet, andere verre van. Als je bijvoorbeeld een file-formaat definieert voor je applicatie ben je strikt genomen al een DSL aan het maken. Erin programmeren is een andere verhaal, maar het is wel een DSL. Dus in de praktijk heeft iedereen die al een aantal applicaties op naam heeft staan wel eens een DSL gemaakt.

[QQ2]

Helemaal mee eens, maar daar geef je ook meteen de beperking van een DSL aan.
Een file formaat is een formaat met een specifieke toepassing. Een applicatie met een specifieke toepassing is simpelweg een applicatie. Een DSL moet dus de exact juiste middenweg vinden tussen niet alles kunnen (ala C++) en tegelijkertijd toch breed genoeg zijn om meerdere applicaties mee te kunnen ontwikkelen en daarbij een efficiency slag te halen.

Overigens vind ik het op zijn minst merkwaardig dat juist het CWI dit op pakt want in mijn mening heeft Fred Brooks in zijn thesis 'No Silver bullet' al bewezen dat dit niet kan. (De efficiency slag van C\C++ over Assembly zit hem er in dat je exact hetzelfde kan maar met minder instructies en dus meer efficiency. De verbetering van Java/.net, hoewel vele male kleiner dan de stap van Assembly naar C, in het feit dat Memory management zelden een intended goal van een applicatie is. Maar naast deze verbeteringen betwijfel ik of er een domein te vinden is die groot genoeg zal zijn om dit het waard te maken.)

P.s. een Turing complete DSL is IMHO eigenlijk geen DSL, van dat punt is eht immers strict gesproken een unviersele taal

[scsirob]

Het risico bestaat dat een domein te beperkt is waardoor een eventuele DSL voor een klein publiek, en daardoor met te weinig resources ontwikkeld zou worden. Daarmee maak je het voor dat publiek misschien eenvoudiger, maar de kwaliteit gaat er niet mee omhoog.

[Shunt9]

Dat is het hele idee van een framework, een team maakt een stuk code (lets say, het .NET framework), en duizenden teams herbruiken deze code. Als al deze teams zelf de code hadden geschreven (in een andere taal of niet), zou het totaal aantel bestede uren VEEL hoger dan het nu is. Daarnaast is het framework breed ingezet en veelgebruikt, wat betekent dat je een andere programmeur erop kan zetten en relatief eenvoudig zijn weg kan vinden.
Als je in een of andere domeinspecifieke taal werkt, krijg je vast veel minder regels code, maar het aantal mensen met de kennis daalt ook drastisch en wordt je in mindere mate gestuurd door de 'regels' van een wijdgebruikt framework. Dat het dan beter onderhoudbaar zou zijn hoeft hier dus helemaal geen gevolg van te zijn.

Overigens hoeven meer regels uiteraard helemaal niet slechtere code te zijn. Fatsoenlijk stuctureren van je code en op zijn tijd refactoren zorgt enkel voor beter leesbare code (mits fatsoenlijk uitgevoerd uiteraard), maar niet voor minder regels...

[latka]

Volgens mij, en dit doen veel mensen tegenwoordig, worden framework en library nog al eens door elkaar gegooid. Het grootste verschil is dat een een framework ook een bepaalde stijl van programmeren vereist die conform de regels van het framework zijn. Bijvoorbeeld: een library gebruik je om iets op het scherm te printen, Struts is daarentegen een framework omdat het alleen lekker bruikbaar is om in een MVC-achtige stijl web-applicaties te ontwikkelen. DSLs gaan nog een stap verder omdat ze niet alleen een stijl afdwingen maar hier ook een specifieke taal aan verbinden.

Dus .Net is strikt genomen niet echt een framework maar een programmeertaal (C#) met een uitgebreide library. Als ASP.NET gaat doen wordt het al meer een framework-achtige omgeving.

[R4gnax]

Strikt genomen is .NET een (collectie) runtime(s). C# is een programmeertaal waar 'toevallig' compilers voor bestaan die CIL-code genereren welke op deze runtime(s) uitgevoerd kan worden. VB.NET, F#, en PHP zijn ook talen waar 'toevallig' CIL compilers voor bestaan.

Het .NET framework, is een serie ge-precompileerde CIL-compliant assemblies die door andere CIL-compliant code aangesproken en gebruikt kan worden. In je eigen woorden; door code die conform de regels van het framework geschreven is.

[tweaktubbie]

Hm, dan had het NOS Basicode geweest

[beany]

Nee, want .Net en java zijn ook generieke talen.

Waar het om gaat bij dsl's is dat er elementen IN de taal worden opgenomen die specifiek voor de applicatie zijn. Dit gaat wat verder dan een standaard library die bijvoorbeeld de boekhouding faciliteerd.

Je moet het meer zien dat, bijvoorbeeld weer dat boekhouden, er in de taal constructies zijn opgenomen die het boekhouden regelen(al is boekhouden denk ik een verkeerd voorbeeld).

Iemand met een goed voorbeeld?

[MarCreative]

Om even op .NET in te gaan, .NET is geen taal maar slechts het framework. Visual Basic en C# zijn de talen, welke gebruik maken van .NET. Je bent echter niet afhankelijk van het .NET framework om er een programma of applicatie in te schrijven.

Tevens, vindt ik het mooi wat ze doen. Als je ziet dat de software eigenlijk alleen maar langzamer wordt (gezien de hardware wat het nodig heeft) is dit een goed initiatief.

Wat ook kan helpen, is de programmeurs anders op te leiden. Hiermee bedoel ik dat, je niet direct in Java of C# gaat programmeren maar begint bij de basis van alle programmeertalen (Assembly) of misschien nog wel lager, hoe de hardware werkt. Anders heb je niks aan Assembly. Alleen op die manier (en zo zie ik het) kun je écht snelle software schrijven.

[Br4mmie]

De eerste 2 weken van mij opleiding kreeg ik assembly, ik heb alleen niet het idee dat er veel mensen iets van opgestoken hebben. Het is daarbij ook niet nuttig om eerst assembly te gaan leren, want je leert er niet van hoe je snellere code schrijft. Dat kun je beter in java/C# leren.

[johnbetonschaar]

Assembly wordt ook niet onderwezen om er daadwerkelijk programma's mee te schrijven, het is gewoon basiskennis die je nodig hebt om een hele hoop andere concepten beter te kunnen begrijpen. Het is net zoiets als schakeltechniek, als software engineer of electrotechnicus ga je ook je eigen transistors en flip-flops niet maken maar het is wel zo handig als je op zijn minst een klein beetje achtergrond hebt hoe de bouwstenen waar alle hogere abstracties die wel actief gebruikt worden op zijn gebaseerd. Als je studenten alleen maar in Java of C# leert denken dan wordt het nogal lastig om ze uit te leggen of te zelf te laten beredeneren waarom bijvoorbeeld de meeste embedded platforms totaal andere performance karakteristieken hebben dan desktop systemen met x86 CPU's.

Twee weekjes assembly op een hele opleiding vind ik persoonlijk dan ook niks te veel.

[raphidae]

Precies, het is ook wel eens handig om ergens iets te kunnen bypassen met een jmp als je de source niet hebt.

[.oisyn]

Het gaat ten eerste niet om snelheid maar om codesize, en ten tweede schrijf je snelle applicaties door de juiste algoritmes te gebruiken, niet door te gaan zitten bitneuken in assembly (dat is pas de aller-aller-allerlaatste stap om die paar cycles extra eruit te persen)

[johnbetonschaar]

Dat hangt er maar net van af wat je programmeert natuurlijk, er zullen altijd toepassingsgebieden blijven waar managed en/of interpreted talen ongeschikt voor zijn. Is het niet vanwege performance dan wel vanwege het gebrek aan controle en voorspelbaarheid van de prestaties en het gebruik van de hardware. Maar in zijn algemeenheid heb je wel gelijk ja.

Ontopic:
Onderzoek naar DSL's is natuurlijk prima, maar of ze echt tot nieuwe inzichten zullen leiden betwijfel ik. De wereld sterft nu ook al van de domein-specifieke talen waar dat nuttig is, en er is geen enkele reden om aan te nemen dat er nu belemmeringen zijn die ervoor hebben gezorgd dat er voor andere toepassingen nooit DSL's zijn ontwikkeld. Voor sommige toepassingen zijn gewoon geen geschikte DSL's te verzinnen en moet je inderdaad complexe code in een generiekere taal schrijven. Het komt een beetje op me over als een oplossing op zoek naar een probleem.

[koelpasta]

Ik denk dat ze DSLs willen gaan genereren.
Althans, dat lijkt mij de enige weg voorwaarts met dit idee.

[Verwijderd]

Kennis van lage programmeertalen (c/c++) of assembly draagt echter wel voor een zeer groot deel bij aan je inzicht van wat er nou werkelijk gebeurd, en dus ook aan welk algoritme sneller zal zijn dan het andere. Zelf gebruik ik nooit assembly (c++ wel meer) maar sinds ik deze talen heb geleerd kan ik ook efficienter programmeren in andere talen omdat ik beter weet wat ik nou daadwerkelijk aan het doen ben.

[.oisyn]

en dus ook aan welk algoritme sneller zal zijn dan het andere.

Euh, nee. Als je het hebt over algoritmes dan kijk je naar schaalbaarheid in geheugen en performance tov het aantal elementen, dat wordt aangegeven door de grote O notatie. Een linear search (O(n)) schaalt veel slechter dan een binary search (O(log n)). Een lookup in een hashtable (O(1)) is daarentegen nog sneller. Natuurlijk, bij kleine n speelt de constante factor veel meer, en dan is het van belang wat het algoritme intern doet, en dan ga je krijgen dat bijv. een linear search sneller is wegens cache coherency e.d. Maar dan heb je het over hele specifieke gevallen.

[Herko_ter_Horst]

Snel? Wie heeft het over snel?

Het gaat om kwalitatief hoogwaardige en robuste software. Dat maak je het best in een taal die zo dicht mogelijk bij het probleemdomein ligt, niet in assembly.

[R4gnax]

Het in een serieuze context toepassen van complexe programma instructies in een taal die zo dicht mogelijk bij het probleemdomein ligt, cq. bij de belevingswereld van een domeinexpert heeft men eerder geprobeerd. De daaruit voortgevloeide collectie sterk lijkende en verraderlijk subtiel verschillende dialecten staat heden ten dage jammer genoeg nog steeds bekend als COBOL ...

Voor hoogwaardig en robuust moet je dus allerminst specialistische constructies gaan gebruiken die door domein experts gebruikt gaan worden, want domein experts hebben ten eerste de ballen verstand van programmeren en ten tweede allemaal hun eigen, individuele visie op hoe hun domein er uit ziet en wat het inhoudt.

[Reactie gewijzigd door R4gnax op 23 juli 2024 09:31]

[Vinnienerd]

Wat heb ik aan assembly als ik in Java werk of .NET? Het zijn beide high-level languages.

[Verwijderd]

Er is maar een manier, gewoon direct in assembler programmeren.
Dat is snel en zeer compact.

Mensen die het niet kennen: http://www.menuetos.net/

Past op een floppy!!
Maar is wel razend snel, net als OS/2 is.

Windows is maar pokke traag met de kernel in C.

[latka]

C is niet het probleem hier, veeleer het generieke karakter (draait op alle ranzige hardware die ooit gemaakt is) en alle open interfaces (overal abstracties en injection-points om iedereen de mogelijkheid te geven het OS aan te passen naar zijn/haar wensen). C code is maar een klein beetje langzamer dan assembly. Zeker op moderne hardware met pipeline stalls is assembly erger dan monnikenwerk geworden.

[Dreamvoid]

Maar is wel razend snel, net als OS/2 is.

Jij hebt overduidelijk niet met OS/2 Warp gewerkt toen dat uit kwam. Wat een trage (en instabiele) puinhoop was dat. Ik heb mijn eerste centen als ICT-er verdiend door bij wanhopige buren en kennissen het eraf te gooien (het stond een tijdje standaard op bijna alle nieuwe PC's) en Windows 3.11 te installeren. En dat was niet omdat Windows zo geweldig was.

[Verwijderd]

Nog voor Warp, ben OS/2 1.2 begonnen, toen nog niemand wist wat multitasken was
Warp was gewoon te vroeg voor zijn tijd, als je het op moderne machines laat lopen vliegt het gewoon, maar helaas is het dood.
Gelukkig zijn de Linux mannen het OS en de kernel grondig aan het herzien, en da's te merken want het is veeeel sneller dan Windows (een jaar geleden was dat nog niet zo op de desktop).
En je bent meteen van Spam/Virus scan rotzooi af, een hele opluchting

[LogiForce]

Heel simpel. We gaan alles weer in Assembly coden. Dan word het wel efficienter, maar kost ook meer

[ktf]

Dat zal je verbazen. Tegenwoordig zijn compilers zo goed dat ze vaak efficientere code afleveren dan programmeurs, tenminste, als de code in de hogere taal niet al te inefficient is geschreven.

DSL's zijn naar mijn idee juist altijd verfoeid. Vroeger waren taak-specifieke talen heel normaal, daarom liet het Amerikaanse ministerie van Defensie Ada ontwikkelen, een taal die alle andere zou moeten kunnen vervangen. Men had in die tijd honderden verschillende programmeertalen, wat erg inefficient werkte. Vaak werken er meerdere mensen aan een project die dan allemaal even bij moeten scholen naar die taal (niet zo moeilijk, maar toch, het moet gebeuren) en waar het combineren van stukjes in verschillende talen weer een rol gaat spelen Willen we weer terug naar die tijd?

Nog een punt: Als je je verdiept in één enkele taal ken je veel beter de kneepjes van die taal. Ik zou denken dat je veel dingen aan libraries over zou laten in plaats van een geheel specifieke taal. Als programmeur zou je, als je van baan wisselt, een setje nieuwe talen aan moeten leren voor de nieuwe toepassingen. Lekker handig

[.oisyn]

DSL's zijn naar mijn idee juist altijd verfoeid

Ik zou echt niet weten waar je dat idee vandaan haalt. Het idee van een DSL is niet "just another language", maar iets dat een bepaald systeem beter kan beschrijven dan een generieke programmeertaal. Ook is een dergelijke tool doorgaans veel toegankelijker voor iemand die wel te maken heeft met de werking van het systeem maar geen programmeur is.

En het is echt niet zo dat het aanleren van een DSL net zoiets is als het aanleren van een volledige programmeertaal. Jij hebt je post ook zojuist getikt in een DSL. Eentje waarin je gewoon heel makkelijk een [url] tag kunt gebruiken ipv met <a src=".."> te moeten prutsen, of nog veel ingewikkelder, de HTML die gegenereerd wordt als je [quote] of [code] gebruikt. Een ander voorbeeld is een shell script, waarin het chainen van de in- en uitput van programma's veel makkelijker gaat, en bovendien veel leesbaarder is, dan als je dat in C zou moeten beschrijven oid. Of het gebruik van een parser generator, waarin je je grammatica gewoon in een EBNF-achtige syntax kunt omschrijven, in plaats van met de hand alle parse-regels te implementeren wat ontzettend onleesbare en ononderhoudbare code oplevert. Of een .Net WPF applicatie, waarin je je UI beschrijft met XAML (vergelijkbaar met HTML) ipv in code "g = new Grid(); g.Add(new Button());" te doen. En zo kan ik nog wel even doorgaan...

[Reactie gewijzigd door .oisyn op 23 juli 2024 09:31]

[Jeroen]

Daar wordt het echt niet minder code van, en al helemaal niet meer portable

Wat wel zou kunnen is specifieke delen van zo'n DSL interpreter in assembly schrijven, waardoor bepaalde dingen een stuk sneller kunnen worden.

[Reactie gewijzigd door Jeroen op 23 juli 2024 09:31]

[the_stickie]

Dat is net het tegenovergestelde van het in het artikel genoemde voorstel.
Ik denk eerder dat men zoiets als Visual Pinball bedoelt; een IDE die toegespitst is op het ontwikkelen van pinball's met geïntergreerde fysics en grafische engine. Op die manier hoef je als intwiieklaar je alvast dààr niet meer mee bezig te houden....

[Gustaaf437]

Waar deze man volgens mij niet op let is dat elke taal onderhouden moet worden en dat daar ook de fouten dus uitgehaald moeten worden. Uiteindelijk wordt het er alleen maar complexer op, omdat niemand meer dezelfde taal gebruikt en er totaal niks meer simpel met elkaar kan samenwerken, simpelweg omdat het een totaal ander fundament heeft. Het lijkt me dus niet dat je voor van allerlei verschillende desktop applicaties weer een andere taal moet gaan ontwikkelen.

[Bosmonster]

Nee, bekijk een voorbeeld als frontend development, waar dit eigenlijk al jaren gebruikelijk is met scheidingen tussen html, css, javascript, maar ook technieken als ruby (on rails), python, sql, etc.

Iedere developmentgroep kan zich richten op een klein gecontroleerd stukje. De samenwerking is iets waar je je niet zo heel druk over hoeft te maken als de standaarden goed in elkaar zitten. En het voordeel is ook dat er meerdere standaarden kunnen ontstaan zodat er keuze is en competitie.

Ipv een grote bak van miljoenen regels C++ code bijvoorbeeld, krijg je dan kleine delen gespecialiseerde code in daarvoor geoptimaliseerde talen. Wat hij ook niet zegt is dat de overkoepelende taal (zoals C++, C#, PHP, etc) verdwijnt. Je zult hem alleen meer nodig hebben om de losse onderdelen te koppelen ipv echt alle logica te schrijven.

[Reactie gewijzigd door Bosmonster op 23 juli 2024 09:31]

[Verwijderd]

Een DSL is niets anders dan een API. Dit is gewoon de zoveelste keer dat ze software ontwikkeling als onderzoek willen verkopen. Dit zou niet betaald moeten worden met belastinggeld.

[.oisyn]

Als je dat beweert snap je niet eens wat een DSL is. Misschien moet je eerst even wat vooronderzoek doen voor je met dergelijke onzin-stellingen komt.

[Verwijderd]

Ik heb weet ik niet hoeveel presentaties gezien van mensen op universiteiten en daarbuiten die een DSL hebben gepresenteerd. Een DSL en een API kunnen compleet voor elkaar worden ingewisseld qua betekenis, omdat het _niets_ zegt. Ik heb zelf ook een "DSL" gemaakt volgens sommige mensen, maar ik vind DSL een compleet overbodig woord, dat alleen bedacht is om meer geld van het NWO te krijgen.

Computers manipuleren in een redelijk consistente manier symbolen en om dan een subset van die interacties een DSL te noemen (zonder enige wiskundige onderbouwing) is compleet belachelijk, maar goed, als jij denkt dat het iets betekent, blijf dat dan vooral geloven.

Elke 'nieuweling' die vraagt wat een DSL is, is na het beantwoorden van de vraag nog steeds niet wijzer, omdat het een concept is dat niets betekent, hoe hard professors ook willen dat het bestaat.

Het Wikipedia artikel is intern al inconsistent, dus om daartegen te gaan argumenteren lijkt me een beetje overbodig.

[.oisyn]

Computers manipuleren in een redelijk consistente manier symbolen en om dan een subset van die interacties een DSL te noemen (zonder enige wiskundige onderbouwing) is compleet belachelijk, maar goed, als jij denkt dat het iets betekent, blijf dat dan vooral geloven.

En dit is precies de reden waarom jij het niet snapt. Het gaat niet om de computers. Het gaat om de mensen die met de taal moeten werken. Neem bijvoorbeeld HTML. De DOM is ook via API via JS beschikbaar. Maar het is veel lastiger en onduidelijker om de DOM op te bouwen met Javascript, dan om gewoon direct de HTML te beschrijven.

Een DSL maakt het mogelijk om met veel minder handelingen en veel betere leesbaarheid dingen te beschrijven dan waarin het moet blijken uit de operaties van een reguliere programmeertaal. En als je het dan toch over wiskundige onderbouwing hebt, vaak zijn DSL's veel beter bewijsbaar omdat de semantiek veel beter beschreven kan worden (zodat een computer die ook snapt) en het domein veel beter afgebakend is.

[Reactie gewijzigd door .oisyn op 23 juli 2024 09:31]

[Verwijderd]

Computer science heeft helemaal niets met mensen te maken. Op het moment dat je mensen in de definities van objecten gaat gebruiken, kun je alles wel gaan roepen. Natuurkunde heeft ook niets met mensen te maken en wiskunde al helemaal niet. Dingen als human computer interaction zijn dan ook geen onderdeel van een informatica opleiding, maar van informatiekunde.

Alles wat je over een DSL zegt kan ook met een API gedaan worden. Je neemt een willekeurige API, bijv. iets als GNUMP en je compiler herkent dan bepaalde specifieke structuren in die API en herschrijft ze dan afhankelijk van de architectuur. Dit noemen sommige mensen ook een DSL. Het is gewoon een toepassing van het idee "optimaliseren naar wat we weten". Dat is iets wat al sinds het begin der tijden gedaan wordt en daar hebben we geen speciaal woord voor nodig als dit met een beetje syntactische suiker wordt gedaan.

[Jeroen]

Het gaat er hier om dat:

- Software kleiner geschreven kan worden
- Software makkelijker te onderhouden is
- Er minder fouten in software gaan zitten

Al deze handelingen worden uitgevoerd door mensen, dus daar gaat het mijns inziens wel degelijk om. Er zijn allerlei dingen om dit soort menselijke interactie te verbeteren, of dat wel onder de wetenschap informatica valt is niet echt belangrijk.

Een DSL is een API net zoals een Mac een Turing machine is en C code Assembler is. Dat mensen het verkeerde woord ergens voor gebruiken is hoogstens kwalijk, dat doet niet af aan het nut van het concept zelf wanneer het goed toegepast wordt. Mensen kunnen dingen noemen wat ze zelf willen zo lang ze er maar bij vermelden hoe ze het interpreteren.

In sommige situaties dekt de term DSL de lading beter dan API, terwijl het allebei geldt. Je kunt eenvoudig hardmaken dat HTML een 'language' is, maar het is per definitie ook een API voor een browser. Waar het meer om gaat is dat mensen begrijpen waar ze mee bezig zijn en dat het voor mensen makkelijker wordt om code te begrijpen, om zo het bovengenoemde te bewerkstelligen. Als je een API ontwerpt in de vorm van een DSL met dat doel voor ogen dan kan je dat zo toepassen dat je softwaresysteem er beter van wordt.

[Verwijderd]

Je eerste paragraaf bevat allerlei onbewezen asserties (iets bewijzen is sowieso nogal lastig in deze hoek, dat zal ik je nageven) en niet omdat het de eerste keer is dat een onderzoeksinstituut een berg geld krijgt.

Ik kan me redelijk vinden in de rest van je verhaal, maar ik vind dat API design (of DSL design) niets met computer science te maken heeft en omdat er dus geen objectieve criteria zijn zou het ook niet 'onderzocht' moeten worden.

Als het CWI een nieuwe manier wil vinden om getallen te ontbinden in factoren, goed, dat mogen ze van mij doen. Als je wireless mesh networks willen optimaliseren, dan kunnen te dan ook doen, maar op het moment dat ze gewoon een berg software gaan produceren waarvan niemand kan zeggen dat het beter is dan wat er daarvoor gedaan werd, dan zitten ze gewoon belastinggeld te verspillen.

[Verwijderd]

Het hele idee achter object georiënteerd programmeren is imho dat je een DSL schrijft voor de laag er boven. Je methoden zijn als ware de werkwoorden van je taal, en wat de het werkwoord doet is afhankelijk van de context. In de meeste talen is er slechts 1 context en implementatie, de klasse waar de methode voor gedefinieerd is. Multiple dispatch omgevingen zoals LISP zijn flexibeler zodat slechts enkele methoden hoeft te onthouden.

[OMX2000]

Je beschrijft Domain Driven Design... En daar zijn termen als ubiquitous language gangbaar.

Die DSL zijn leuk, en ik geloof er ook echt in. Maar om een goede DSL te ontwikkelen ben je wel ff bezig.

Het gevoel wat mij bekruipt bij dit initiatief is dat ze een nieuwe term (DSL) gebruiken om herbouw te rechtvaardigen.

Een goed DDD design vereenvoudigt de zaak ook. Maar vereist wel een aanpak en filosofie die zorgt dat de software doet wat het moet doen, en onderhoudbaar houdt.

[SPee]

In een DDD wordt ook gebruik gemaakt van DSL.
Die vormen veelal de transitielaag van het ene model naar het andere. De beschrijving van het model en de transitie naar het volgende wordt met een DSL gedaan.

[Jeroen]

Ik denk dat in sommige gevallen het makkelijker zou zijn om er een laagje tussen te bouwen, de zogenaamde DSL interpreter, zodat je diezelfde werkwoorden net iets overzichtelijker of simpeler kan schrijven en daarmee de werking van het programma duidelijker maakt zodat het makkelijker te lezen is en dus makkelijker te verbeteren is en het makkelijker is er fouten uit te halen, wat waarschijnlijk ook het hergebruik van bestaande functies bij het interpreteren bevordert en zo de code kleiner maakt en het ook makkelijker is verbeteringen in de onderste laag van de code door te voeren.

Het scheelt natuurlijk niet veel maar het gaat meer om de strategie die je voor ogen hebt bij het proces.

[El_ByteMaster]

Cool. Aangezien de meeste software bedrijfsmatig word gebruikt, stel ik voor om dat als eerste te tacklen... dus een bedrijfs-georienteerde taal, maar beruikbaar in alle bedrijven of in goed Engels een "common business-oriented language". Iemand een idee for zoiets?

[raphidae]

10 PRINT "Gimme ur money"
20 GOTO 10

[R4gnax]

De COBOL kaart had ik inderdaad al eerder gespeeld in deze discussie. Dat is dan ook gelijk het voorbeeld bij uitstek waarom het op brede schaal toepassen van DSLs gedoemd is te mislukken. Zeker als het als doelstelling heeft de kloof tussen expert en programmeur te dichten, wat feitelijk neerkomt op een taal maken die er op toegespitst is de expert zelf te laten programmeren...

[edsnor]

Dit doet me denken aan een artikel in Communications of the ACM (augustus 1986) van Jon Bentley "Little Languages". Specificeer een taal om je probleem gemakkelijker op te lossen.

[RayNbow]

Link naar het ACM artikel.
(Vereist zeer waarschijnlijk een abonnement)

Discussie over het artikel op c2 wiki.