[j2ee] is ontwikkelen mbv wizards de toekomst?

[JeroenTheStig]

Gistermiddag was er op mijn werk een j2ee-demo-middag, om te laten zien wat de ambities van het bedrijf zijn, en hoe dat aangepakt gaat worden. We bouwen voornamelijk Oracle applicaties in webforms, maar aangezien Oracle van plan is om de switch naar java te maken, dus ontwikkelen in JDeveloper in plaats van Forms Builder of Designer, wil het bedrijf haar werknemers voorbereiden op de switch van formsbuilder/designer naar jdeveloper.

Natuurlijk is het alles behalve eenvoudig om mensen waarvan hun voertaal pl/sql is om te scholen naar een OO taal als Java. Maar nadat we gisteren de mogelijkheid hadden om Oracle ADF tutorials te maken in JDeveloper, lijkt het alsof er totaal geen java-kennis nodig is, laat staan OO-kennis.

Je moet je voorstellen: Je hebt leren programmeren in Java, en programmeert inmiddels een jaar of 5/6, alles met het handje, met behulp van een fijne IDE, zoals Intellij. Door de stages die je hebt gehad ben je in aanraking gekomen met design patterns, frameworks als ant, junit, en het programmeren wordt leuker en leuker.

Op een gegeven moment wil je toch eens verder kijken, en koopt wat J2EE boeken, en je gaat naar een java-middag waar een demo wordt gegeven over het ontwikkelen van j2ee applicaties in Oracle JDeveloper, en dan met name ADF. Je krijgt een tutorial voor je neus, en je gaat lekker aan de slag. Maar dan komt de teleurstelling al gauw, want waar ben ik in godsnaam mee bezig? Juist, invullen van wizards, die vervolgens andere wizards aanroepen. Hier een wizard, daar een wizard, overal een wizard. Ik heb de hele middag geen regel java-code ingeklopt. En het erge is dat je geen flauw benul hebt wat er achter die wizard nu precies gebeurt.

Wat wil ik met dit topic bereiken? Ik wil graag weten waar het in de toekomst naartoe gaat. Wordt er al veel 'geprogrammeerd' door het invullen van wizards, gaat het die-hard inkloppen van code eruit, welke kant gaat het op?

Wat zijn de voordelen en nadelen van wizards? Natuurlijk kun je met weinig kennis van de taal zelf snel een programma in elkaar sleuren en pleuren. Maar dan moet het onderhouden worden... en schieten de tranen in je ogen als je ziet wat voor code is gegenereerd.

Dus graag jullie ervaringen mensen, ik ben zeer benieuwd.

[Alarmnummer]

Ik betwijfel of het de toekomst gaat worden omdat RAD omgevingen als zo oud zijn en ze nog steeds niet 'de' tool zijn. In applicaties zit gewoon te veel complexiteit om volledig weg te stoppen achter wizards. Sommige dingen kun je wel eenvoudiger maken door wat goeie wizards/codegenerators in elkaar te zetten (ik gebruik het ook wel eens). Maar omgevingen die werkelijk alle complexiteit uit handen nemen zullen voorlopig er niet komen. En verder als je nu code klopt of je werkt via een of andere visueel iets vind ik niet zoveel uitmaken.

Ik denk dat de toekomst meer zit in declaratieve elementen in talen. Als je kijkt naar bv annotations van Java kan je nu (kon eerder ook wel.. common attributen en nare xml bestanden) veel meer informatie in je Java code kwijt. Allerlei or-mapping problematiek (hibernate), transactie (spring)/security(acegi) en ook allerlei view problematiek(tapestry) bv. Ipv dat je door tig files moet worstelen en nooit compiletime garanties kan dit nu een stuk beter.

En verder gaat denk ik Language Oriented Programming een veel grotere rol spelen. Java is een leuke taal, maar soms ben je bezig om schroeven in de muur te draaien met een hamer (alhoewel dat ook nog wel eens werkt) terwijl je gewoon een schroevendraaien nodig bent. Daarom moeten er domein talen op maat komen en moet de opstap om een domein taal op te zetten ook een stuk kleiner worden.

[ Voor 12% gewijzigd door Alarmnummer op 02-07-2005 09:54 ]

[whoami]

Ik denk niet dat wizards de toekomst zijn; zoals je zelf al zegt heb je dan totaal geen controle meer over jouw code.
Trouwens, een wizard kan ook niet alles; met een wizard kan je slechts bepaalde functionaliteit laten genereren, maar een 'domain model' zal je nooit met een wizard kunnen laten generen, gewoon omdat dat te specifiek is.

Alarmnummer, als je het hebt over 'language oriented programming', heb je het dan over 'domain specific languages' ?
Dat komt de laatste tijd nogal voorbij, ik ga dat eens van dichterbij moeten bekijken.

[mbravenboer]

Komop mensen, geef eens een mening. Een fanatieke lurker als ik verwacht tot wel wat meer interessantie verhalen in zo'n topic .

Ik denk (en hoop) niet dat Wizards zoals we die nu kennen de toekomst hebben, maar met 'hardcore' kloppen van grote hoeveelheden code zal je als bedrijf hopelijk ook snel de concurrentiestrijd verliezen.

Waar het allemaal om draait is het zo dicht mogelijk bij het domein brengen van de code. De code moet zo compact en duidelijk mogelijk het concrete probleem beschrijven. Dit concrete probleem is vaak een soort van instantiatie en configuratie van een concepten die steeds opnieuw terugkomen bij applicaties in het betreffende domein.

De vraag is dus: hoe kunnen we deze algemene concepten, patronen, abstracties gescheiden van de concrete applicatie implementeren? En hoe moeten die abstracties geinstantieerd worden voor de concrete applicaties? Hoe zorgen we ervoor dat er naast de standaard abstracties toch nog voldoende vrijheid is voor zaken die echt specifiek zijn voor een concrete applicatie?

Het gaat hier dus om de ultieme strijd tussen verschillende methoden om zulke abstracties aan te bieden en de manier waarop je van die abstracties gebruik kan maken.

1. Libraries -- die abstracties implementeren en gebruikt worden via een API
2. Wizards -- die code genereren door de vragen te stellen die specifiek zijn voor een bepaalde applicatie.
3. Domein Specifieke Talen (DSL) -- die de abstracties van een bepaald domein tot een taal maken. De confguratie van die abstracties is een 'programma' in deze DSL.

Wizards hebben vaak het probleem dat ze niet erg flexibel zijn en alleen bepaalde configuraties toelaten. Libraries zijn, zoals in de praktijk blijkt, niet altijd even gebruiksvriendelijk en voldoen dus kennelijk niet om domein abstracties echt duidelijk te onderscheiden van een applicatie. Dit hangt ook sterk van de taal af: Lisp/Scheme mensen zijn harstikke tevreden met hun libraries, die vaak richting domain specifieke talen gaan. In zekere zin vormen libraries altijd een taal. Domein specifieke talen zorgen vaak voor problemen in de infrastructuur: ze staan vaak in andere files, vereisen andere tools. Het is op dit moment eigenlijk niet mogelijk om een grote hoeveelheid domein specifieke talen te combineren in 1 project. Vaak is de interactie tussen de algemene programmeertaal en de domein specifieke taal ook moeizaam.

Binnen alle abstractie methoden zijn mensen naar oplossingen aan het zoeken. Voorbeelden: MDA (valt in principe binnen de DSL tak, maar is weinig concreet), Aspect Oriented Programming om de configuratie van libraries te verbeteren, Feature Oriented Programming om de compositie van features in een applicatie te verbeteren, DSL embedding om de interactie tussen een general-purpose taal en een DSL te verbeteren, en ga zo maar door.

Ik denk dat de meeste toekomst in talen zit. Waarschijnlijk zullen in de nabije toekomst libraries en domein specifieke talen dicht bij elkaar gaan liggen: het zou fantastisch zijn als je talen kan gaan gebruiken in je algemene programmeertaal zoals je nu gewoon libraries kan gebruiken. De algemene programmeertaal wordt dan steeds meer een taal voor glue en applicatie-specifieke zaken. Dit stadium is vrijwel het nirvana van het programmeren . Je kan zo de taal pakken die het meest geschikt is voor een bepaald deel van je applicatie. Je bent toch nog vrij: waar die taal niet voldoet, pak je een andere taal of de algemene programmeertaal. Wizards kunnen omgezet worden naar talen, en 'programmas' die deze 'wizard' aanroepen kan je gewoon in je code opnemen.

Disclaimer: mijn promotie onderzoek gaat over de implementatie van domein specifieke talen en configuratie van code .

[ Voor 6% gewijzigd door mbravenboer op 02-07-2005 16:00 ]

[mbravenboer]

whoami: Trouwens, een wizard kan ook niet alles; met een wizard kan je slechts bepaalde functionaliteit laten genereren, maar een 'domain model' zal je nooit met een wizard kunnen laten generen, gewoon omdat dat te specifiek is.

Je zou best een domein specifieke taal kunnen ontwerpen voor de definitie van domein modellen. Aansluitend op mijn vorige post betekent dat dan dat er ook een wizard kan zijn, maar de gedachte aan zo'n wizard laat gelijk het probleem van wizards als code generatoren zien. Je wilt hier duidelijk interactie tussen de 'abstractie' (in een wizard of DSL) en de general purpose language.

Dit voorbeeld laat ook mooi het probleem van een library zien: een abstractie voor de definitie van domein modellen kan je eigenlijk niet in een library vangen. Je hebt hiervoor een abstractie nodig die ook zelf weer min of meer code kan genereren. Macro systemen en Lisp/Scheme kunnen dit uiteraard.

Alarmnummer, als je het hebt over 'language oriented programming', heb je het dan over 'domain specific languages' ?

Ja, LOP en Language Workbenches lijken zich vooral te richten op IDE support voor domein specifieke talen. In ieder geval gaat het erom dat je een eigen taal kan definieren voor een bepaald applicatie domein.

[ Voor 3% gewijzigd door mbravenboer op 02-07-2005 16:14 ]

[mbravenboer]

Alarmnummer: In applicaties zit gewoon te veel complexiteit om volledig weg te stoppen achter wizards. Sommige dingen kun je wel eenvoudiger maken door wat goeie wizards/codegenerators in elkaar te zetten (ik gebruik het ook wel eens). Maar omgevingen die werkelijk alle complexiteit uit handen nemen zullen voorlopig er niet komen. En verder als je nu code klopt of je werkt via een of andere visueel iets vind ik niet zoveel uitmaken.

/me mbravenboer knikt instemmend.

(Voor de vorm moest ik even reageren: ik ben het volledig met je eens en heb eigenlijk weinig toe te voegen of op te merken .. )

[Verwijderd]

...

Alarmnummer, als je het hebt over 'language oriented programming', heb je het dan over 'domain specific languages' ?
Dat komt de laatste tijd nogal voorbij, ik ga dat eens van dichterbij moeten bekijken.

Ik heb deze paper even vlug doorgekeken, maar als ik lees dat onder DSL specifieke talen dingen als Make, YACC, LEX, SQL en HTML vallen, dan krijg ik het idee dat DSL gewoon een dure benaming is voor alledaagse dingen. IMHO zit niemand te wachten op het concept DSL of wat je ermee zou kunnen.

Kijk, ik snap het voordeel en het idee achter DSL's wel, maar dit gebeurt volgens mij vanzelf wel. Als er een probleem opduikt (dat zoals elk probleem een domein beslaat) dat niet of niet eenvoudig met een bestaande taal op te lossen is, dan komt er vanzelf wel een alternatieve DSL voor.

Als je echter, zoals in de paper waar Whoami naar verwijst, kiest voor het expliciet definieren van een DSL taal als onderdeel van je ontwikkeltraject, dan ben je denk ik verkeerd bezig. Als je dit consistent doorvoert zou je dus voor elke applicatie die een bepaald domein beslaat een aparte taal moeten zoeken/ontwikkelen. Dat lijkt me niet handig werken.

Bovendien zijn de grenzen tussen domeinen niet altijd even duidelijk, waardoor je weer met een hoop extra zorgen wordt opgezadeld naast de daadwerkelijke implementatie van je programma. Kijk gewoon naar de discussie over wat je nou wel en niet in SQL (dus je DB) of in bv. C# (dus in je applicatie) zou moeten oplossen.

Mij lijkt dat je het grootste deel van je domein specifieke problemen gewoon in je eigen programmeertaal kunt oplossen, in een specifieke class library bijvoorbeeld. Ligt natuurlijk ook weer aan welke definitie je voor een domein gebruikt... bedoel je een domein uit de programmeerwereld (zoals in de paper met SQL, HTML etc.) of bedoel je een business domein (bankwezen, ERP etc)... voor de eerste definitie lijkt het me een open deur en voor de tweede lijkt het me overkill...

Dus mijn conclusie is eigenlijk dat het een hoop geblaat is over een wazig concept zonder enige meerwaarde Overtuig me maar eens van het tegendeel MBravenboer

[MSalters]

Als je de bekendste en meest gebruikte DSLs noemt, en vervolgens concludeert dat die niet spannend zijn, dan mis je de plank. Dat zijn grote domeinen, waarvoor de talen al beschikbaar zijn.

Je stelt echter dat voor kleinere gebieden DSLs de moeite niet waard zijn. Waarom? Wat is het probleem? Ik heb al twee applicaties gezien met een DSL, en in beide was het behoorlijk handig. Vergeet niet dat domein experts geen programmeurs zijn. Die verliezen het overzicht als ze in C++ bezig moeten. Een DSL maakt ze veel productiever.
Het bankwereld is een goed voorbeeld. De modellen kunnen behoorlijk complex zijn, dus vanwege performance zijn de onderliggende modellen daar vaak in C++ gemaakt. Economen moet je niet met dat soort details lastig vallen, die willen op hoofdlijnen werken, en in termen die ze kennen.

Naast applicaties met een eigen DSL gebruiken we binnen ons bedrijf een DSL voor geautomatiseerd testen. Daar zie je overigens een trend naar standaardisatie.

[Soultaker]

Alarmnummer schreef op zaterdag 02 juli 2005 @ 09:51:
[knip]

Eigenlijk zou ik deze hele post wel kunnen quoten, want ik ben het er helemaal mee eens.

Als het zinnig is om met een wizard code te genereren dan is de programmeertaal waar je mee werkt blijkbaar niet geschikt voor het doel waarvoor je het wil gebruiken. Er is echter geen enkele reden waarom je dan een wizard zou moeten gebruiken; je hebt dan gewoon een programmeertaal nodig die op je doel toegespitst is.

Daarom is er wel degelijk bestaansrecht voor 'little languages'; simpele taaltjes voor simpele doeleinden, maar die toch formeel gedefinieerd zijn. Uiteindelijk denk ik dat een goede programmeertaal altijd superieur is aan een wizard/GUI-achtige omgeving omdat een geschreven programma altijd volledig gespecificeerd is. Uiteindelijk geeft dat veel meer controle over het gedrag van je applicatie. Zo kom ik bijvoorbeeld dagelijks applicaties tegen waarbij de tab order niet klopt; dat komt puur omdat die met een GUI in elkaar geknutseld is en niet expliciet gespecificeerd is.

Wizards lijken me dus vooral een verkoopargument en een tool voor de gemakzuchtige programmeur, maar geen vervanging van de code die ze produceren.

[LauPro]

Dat er per 'doelgroep' een aparte programmeertaal gaat komen lijkt me erg onwaarschijnlijk. Wat wel mogelijk is (en wat nu al gebeurd) is dat er complete libaries beschikbaar komen welke al een deel van een oplossing bevatten. Als 'programmeur' moet je dit pakket dan zodanig aanpassen (evenuteel met Wizards) zodat het aan de eisen van de klant voldoet.

Eigenlijk gaat dit voor een deel al de richting op waar Oracle e.d. in willen voldoen. Oracle levert een soort platform waar binnen ze zelf standaard beperkt een aantal mogelijkheden bieden. Als ontwikkelaar breid je dit dan vervolgens uit.

Mogelijk dat er een aantal grote partijen op gaan komen die hele brede oplossingen aan gaan bieden (voor zover die er nog niet zijn, zie bijvoorbeeld Microsoft). Deze oplossingen (bijvoorbeeld een voorraadbeheersysteem) kunnen dan worden gefinetuned door middel van wizards. Maar in dat geval komt er denk ik een gehele nieuwe arbeidsmarkt: namelijk het finetunen van bestaande oplossingen. De echte ontwikkelaars zitten dan helemaal onderaan in de lijn. De afstand tussen de ontwikkelaar en de klant wordt zo dus groter.

Welke richting het op gaat zou ik zelf niet zo snel kunnen zeggen. Persoonlijk zou ik toch wel proberen zo min mogelijk met Wizards te hoeven werken. Indien je een Wizard nodig hebt om je doel te bereiken dan is je taal of platform te complex en kan je beter die complexiteit proberen te bevatten door het opzetten van libaries. Dit spaart veel meer tijd uit omdat je daarna heel complact iets kan maken dat uiteindelijk veel impact heeft.

[dingstje]

LauPro schreef op zondag 03 juli 2005 @ 02:47:
Mogelijk dat er een aantal grote partijen op gaan komen die hele brede oplossingen aan gaan bieden (voor zover die er nog niet zijn, zie bijvoorbeeld Microsoft). Deze oplossingen (bijvoorbeeld een voorraadbeheersysteem) kunnen dan worden gefinetuned door middel van wizards. Maar in dat geval komt er denk ik een gehele nieuwe arbeidsmarkt: namelijk het finetunen van bestaande oplossingen. De echte ontwikkelaars zitten dan helemaal onderaan in de lijn. De afstand tussen de ontwikkelaar en de klant wordt zo dus groter.

Je bedoelt hoe het nu ongeveer werkt met SAP.

Ik denk trouwens dat wel dat domein specifieke talen meer en meer gebruikt gaan worden. Ik merk het zelf ook in mijn eigen gedachtengang dat ik soms denk aan semi-DSL oplossingen. Dit is zonder er iets van te kennen op voorhand, maar gewoon iets wat voor mij een logisch gevolg was (wist tot enkele weken geleden niet wat DSL was). Het lijkt mij dus wel een grote kanshebber om 'dé toekomsttechnologie te worden'.

[Verwijderd]

MSalters schreef op zaterdag 02 juli 2005 @ 22:08:
Als je de bekendste en meest gebruikte DSLs noemt, en vervolgens concludeert dat die niet spannend zijn, dan mis je de plank. Dat zijn grote domeinen, waarvoor de talen al beschikbaar zijn.

Ik zeg niet dat deze talen zelf onzin zijn, ik vind het concept van DSL alleen overbodig. Zoals dingstje ook aangeeft komen deze specifieke talen vanzelf wel om de hoek kijken, zoals bijvoorbeeld een scripttaal bij een spel, etc. Om hiervoor nu het concept van DSL's te introduceren komt op mij een beetje theoretisch en puur academisch over.

Wat ik probeer te zeggen is dat de term DSL zelf gewoon een holle term is. Alle talen zijn domeinspecifiek als je van de voorbeelden SQL, HTML etc uitgaat, want ook bv C++ beslaat een (weliswaar heel breed) domein van computerproblematiek. Dus we gebruiken het al jaren en gieten het nu in een nieuw jasje.

Je stelt echter dat voor kleinere gebieden DSLs de moeite niet waard zijn. Waarom? Wat is het probleem? Ik heb al twee applicaties gezien met een DSL, en in beide was het behoorlijk handig. Vergeet niet dat domein experts geen programmeurs zijn. Die verliezen het overzicht als ze in C++ bezig moeten. Een DSL maakt ze veel productiever.
Het bankwereld is een goed voorbeeld. De modellen kunnen behoorlijk complex zijn, dus vanwege performance zijn de onderliggende modellen daar vaak in C++ gemaakt. Economen moet je niet met dat soort details lastig vallen, die willen op hoofdlijnen werken, en in termen die ze kennen.

Mijn post richtte zich tegen het introduceren van het concept DSL's, dat was misschien niet duidelijk. Maar ook bij deze toepassing die je voorstelt heb ik m'n twijfels. Het lijkt op het eerste gezicht een goed idee om een taal te maken waarin economen business regels e.d. kunnen definieren, maar economen zijn geen programmeurs dus ik voorzie hiet al een hoop problemen.

Daarbij zie je met je brede standaard programmeertalen (die in principe alles kunnen) al vaak hoe moeilijk het is aan de wensen van de opdrachtgever te voldoen. Door met een (evt. zelfgemaakte) kleine DSL aan de slag te gaan loop je gegandandeerd tegen beperkingen op die kunnen zorgen voor houtje-touwtje oplossingen of een wildgroei van de DSL waardoor het eventuele voordeel verloren gaat.

Naast applicaties met een eigen DSL gebruiken we binnen ons bedrijf een DSL voor geautomatiseerd testen. Daar zie je overigens een trend naar standaardisatie.

Zou je een paar concrete voorbeelden willen geven, zodat ik me misschien meer bij DSL's en het nut ervan kan voorstellen? Ben hier nl wel serieus in geinteresserd, maar wat ik tot nu toe heb gezien kan me niet overtuigen dat dit ' the next big thing' gaat worden.


En over de orginele discussie:

...

Maar in dat geval komt er denk ik een gehele nieuwe arbeidsmarrkt: namelijk het finetunen van bestaande oplossingen. De echte ontwikkelaars zitten dan helemaal onderaan in de lijn. De afstand tussen de ontwikkelaar en de klant wordt zo dus groter.

SAP is hier inderdaad het beste voorbeeld van, maar ik het dit al met meerdere paketten gezien. Ik heb me al eens afgevraagd hoeveel bedrijven tegenwoordig nu echt nog zelf programma's maken... bijvoorbeeld al die MS partners die hun eigen spinnoff van Navision als ERP pakket verkopen, CMSen gebaseerd op Lotus Notes etc.