Studenten leren liever Java, C# en C++ dan Cobo zo meldde een bericht in Computable. Vooral de financiële sector zal zich zorgen maken. Hun it zit immers nog boordevol met Cobol-applicaties: Is het dan erg als er nog weinig Cobol-expertise is? Nee, in mijn ogen niet. Door de opkomst van platformonafhankelijk ontwikkelen is het namelijk helemaal niet meer nodig om code te kunnen schrijven in Cobol.
In vroegere tijden was het platform waarin de applicaties werden ontwikkeld een eerste keuzemoment en de eenmaal gemaakte keuze wierp zijn schaduw soms tientallen jaren vooruit. Organisaties zaten tot in lengte van dagen vast aan het platform en zijn besturingssysteem. Over vendor lock-in gesproken – maar dat even terzijde. Voor elk wissewasje (soms slechts een verhoging van de btw) moest een programmeur aan de slag om de applicatie aan te passen. Dat is niet alleen kostbaar en inefficiënt, het is ook nog eens levensgevaarlijk: de programmeur kan onbedoeld code wijzigen die niet gewijzigd had moeten worden, iets dat meestal pas na enige tijd blijkt.
Ook als de applicatie moest worden gemigreerd of gaan samenwerken met een nieuw systeem, moest de programmeur komen programmeren. Hergebruik van (delen van) de software is vrijwel onmogelijk, net als het beschikbaar stellen van de applicaties op mobiele devices. Kortom, erg flexibel en efficiënt is het niet in deze tijden waarin verandering de enige constante is.
Inmiddels bestaan er gelukkig ontwikkelplatforms waarin applicaties op een neutrale manier kunnen worden ontwikkeld, waarna ze met een druk op de knop worden omgezet in de taal die nodig is: Java, C+, C#, C++ en Cobol. Zo kan ook een Java-programmeur dus bijvoorbeeld een Cobol-applicatie aanpassen. Als de applicaties inderdaad in de neutrale code is opgeslagen, kan de applicatie – of delen daarvan – worden hergebruikt in verschillende talen, op verschillende operating systems. Dat stuk intelligentie maakt van legacy-applicaties een gemakkelijk hanteerbaar fenomeen, dat niet langer als een molensteen om de nek van de cio hangt.
Overigens: platformonafhankelijke ontwikkelplatforms bestaan al langer dan tien jaar en zijn beproefde en bewezen technologie. Nu het is gelukt een aantal technische beperkingen weg te nemen, kunnen ook de Cobol-gebruikers opgelucht ademhalen.
Ik ben heel benieuwd wat voor ontwikkelplatforms dat zijn die in 1 druk op de knop code genereren in de taal (en omgeving) naar wens. En als dat zo is dan denk ik dat je nog programmeurs nodig zal hebben om wijzigingen aan te brengen.
@Louis
Er bestaat een groot aantal van dit soort omgevingen, meestal gericht op een enkele programmeertaal. Grootste probleem is dat de opgeleverde “code” vaak zo slecht en bloated is, dat de bedrijven die deze tools gebruiken voor hun klanten ook vaak een (apart te betalen) sanitation service hebben. Daarbij lijkt het me wat vergezocht om 4-GL talen te vergelijken met Cobol (en ja, ik weet dat er OO Cobol bestaat maar dat is toch echt heel anders).
John,
Ik vind je verhaal heel aardig maar ik kan me niet vinden in je eindconclusie.
Net als Jeroen heb ik mijn twijfels over het eindresultaat van zo’n ontwikkelplatform, voorbeelden te over waar bagger geproduceerd wordt.
Daarom deel ik ook niet je conclusie dat het niet meer nodig is om Cobol te kloppen.
Vergeet niet dat de finaniciele wereld juist vast houd aan deze taal omdat deze sector juist zo bang is dat er verborgen issues worden geintroduceerd (je begint er zelf al over)
Dat er een tekort aan Cobol-coders is omdat scholen dit niet meer doceren tja daar hebben we het al uitgebreid over gehad.
Gewoon opzoek gaan naar serieuze mensen die wel in staat en bereid zijn iets nieuws te leren, die mensen een fatsoenlijke baan met een fatsoenlijk salaris bieden en het probleem is opgelost. Heeft je helemaal niets te maken met scholieren die geen idee hebben wat ze moeten doen als er geen IDE voor hun neus staat.
@Pascal: Waarom zou je die Cobol meuk in stand houden? Die draait wellicht wel, maar onderhoudbaarheid lijkt mij een groot probleem. Temeer omdat er – ongetwijfeld – met zwaar verouderde programmeermethodieken is geprogrammeerd. Oplappen van dergelijke code kost alles bij elkaar veel tijd. Op zich kan zo’n ontwikkelplatform best helpen voor een eerste conversieslag. Over de gegenereerde code is uiteraard nog wel een optimalisatieslag nodig.
@Jeroen Dat vermoeden had ik ook al, het is gegenereerde code en dat zal niet de meest prettige code zijn mee te gaan werken. Die omgeving die naar alle talen en platformen met 1 druk op de knop code kan genereren ben ik nog niet tegengekomen. Wel wat gelezen over tools voor het vertalen van Cobol code naar Java, met inderdaad de haken en ogen, niet alle functionaliteit ondersteund, issues met performance. Zeker geen 1 druk op de knop. En las dat de gegenereerde code er nog steeds er meer als Cobol dan als Java uitziet en nog niet zoveel met Java te maken heeft. Wel logisch. Het eindresultaat werd ook wel omschreven als JOBOL.
@Pascal Ik denk dat nog het beste is, laat die Java programmeur zich maar Cobol eigen maken. Dat zal nog niet het lastigste onderdeel zijn, de bestaande software onder knie krijgen lijkt me heel wat lastiger.
Dat er niet zoveel Cobol mensen zijn lijkt me een hele slechte reden om afscheid te nemen van deze software, zeker niet als de software goed functioneert.
Tja, mensen betalen om iets te leren dat je als bedrijf nodig hebt, hoe kort dat ook duurt voor een reeds ervaren programmeur, vertikt men. Dan liever voor veel te veel geld inhuren. En zolang IT bedrijven het imago houden dat je er bij de minste economische tegenwind meteen uitvliegt (hallo Cap) gaat niemand zich daarin verdiepen, als je dan toch een risicovol vak kiest leg je je toe op iets dat je zelf leuk vind.
En het soort omgevingen dat hogere code uitspuugt heb ik van nabij meegemaakt, als gedetacheerde bij het toeslagen project bij de belastingdienst. Als 90% van de uitgespuugde code uberhaupt compileerde was je al blij. En de code was, zoals Jeroen al schreef, volkomen ondoorgerondelijk voor mensen. Geen wonder dat dat project zo enorm uitgelopen is en zoveel duurder dan gepland dat het kamervragen opleverde.
Het idee is prima maar de uitvoering minder haalbaar. Ik geloof best dat er vertalers zijn van een moderne taal naar Cobol. Maar daarmee kan je nog geen bestaande cobol code mee teruglezen en/of begrijpen. Je moet toch bestaande systemen onderhouden. Wanneer je met een andere taal zou kunnen schrijven dan kun je dat onderdeel ook beter in die taal houden en aanroepen vanuit de Cobol code.
Maar als er echt een tekort zou zijn dan zouden de tarieven voor Cobol programmeurs fors omhoog moeten gaan. En als dat zo is zijn er best wel wat mensen die zich ff omscholen (zo moeilijk is het ook weer niet). Kan me prima voorstellen dat de banken zelf een eigen trainingscentrum opzetten als dat nodig is.
Tja, bovenstaande reacties bevestigen aleen maar mijn lage dunk van de moderne ‘ict-specialist’
Ik heb ook al veel bagger gezien en heb er helaas dagelijks mee te maken. Al die jongetjes die ‘moderne talen’ leren hebben werkelijk geen idee meer wat ze nu eigenlijk aan het doen zijn.
Lach me werkelijk kapot, zat situaties gezien waar voor absurde bedragen lui worden ingehuurd die niet in staat zijn om goede bestaande code te onderhouden en daarom maar zonder enig sucses clumsy een c# versie proberen te implementeren… Pascal wordt er blij van, kan straks schunnige tarieven rekenen, Gitaarcollectie uitbereiden, een leuke zeilboot, een Fiazoli mischien.