Op 73 procent van de universiteiten en hoger beroepsonderwijsinstellingen is Cobol-ontwikkeling geen vast onderdeel van het curriculum. Dit staat in contrast met de mening van de directeuren van de onderwijsinstellingen. 58 procent vindt dat Cobol-ontwikkeling een vast onderdeel in het curriculum zou moeten zijn. Dit blijkt uit onderzoek van softwareleverancier Micro Focus onder 119 directeuren van universiteiten en hoger beroepsonderwijsinstellingen wereldwijd.
Op 27 procent van de universiteiten en hoger beroepsonderwijsinstellingen wordt nog wel Cobol onderwezen. Hiervan is bij 18 procent Cobol-ontwikkeling een standaard onderdeel in het curriculum en bij 9 procent is de programmeertaal beschikbaar als keuzevak.
C#, C++ en Java
Het aantal onderwijsinstellingen waar veel Cobol-ontwikkelaars afstuderen ligt laag. Op slechts 5 procent van de hogescholen en universiteiten studeerden het afgelopen jaar meer dan dertig Cobol-ontwikkelaars af. Op 16 procent van de onderwijsinstellingen studeerden er het afgelopen jaar meer dan dertig studenten af op de talen C# en C++. Java is de meest populaire taal. Op 32 procent van de onderwijsinstellingen studeerden er meer dan dertig Java-ontwikkelaars af.
Om Cobol-ontwikkelaars goed op te kunnen leiden, hebben onderwijsinstellingen ondersteuning nodig. 43 procent van de onderwijsinstellingen zegt dat ze eerst de vraag van studenten moeten krijgen voordat Cobol in het curriculum wordt opgenomen. Daarnaast geeft 29 procent aan betere hardware- en softwarevoorzieningen nodig te hebben. 16 procent heeft behoefte aan onderwijsinstructies en 12 procent aan handleidingen en cursusmateriaal.
Cobol blijft minimaal tien jaar
‘De nieuwere programmeertalen, zoals Java en C#, zijn erg populair onder studenten’, zegt Huib Klink, senior consultant/presales bij Micro Focus. ‘Maar de Cobol-taal is nog goed vertegenwoordigd binnen organisaties en er is nog steeds veel vraag naar Cobol-ontwikkelaars. Uit eerder onderzoek blijkt dat zeven van de tien van de universiteiten en onderwijsinstellingen verwachten dat in ieder geval de komende tien jaar nog met applicaties gewerkt wordt die geschreven zijn in Cobol. Een kwart heeft deze verwachting zelfs voor de komende twintig jaar. Als Cobol niet meer onderwezen wordt, leidt dit tot het verlies van kennis en expertise en dit brengt de nodige risico’s met betrekking tot de bedrijfscontinuïteit met zich mee.’
het grote probleem is niet dat we een relikwie in stand moeten houden,
maar dat we vergeten dat opleidingen de beginselen en concepten die bij programeren komen kijken moeten bijbrengen.
Los van het feit dat deze daar tegenwoordig steeds minder in slagen is het dus niet te taak om C# of Java en zeer zeker geen Cobol aan te leren.
Om een specifieke taal te leren dien je naar je opleiding gewoon een cursus te volgen.
Serieuze ontwikkelaars zijn gewend dergelijke materie zelf eigen te maken.
Ik heb on mijn cariere met zo’n veertig verschillende talen te maken gehad, zo moeilijk kan het dus niet zijn.
Echter in deze gemakkelijk klikklakklaar is niemand meer bereid om eens een uurtje vrije tijd op te offeren en ergens moeite voor te doen.
En zoals reeds vermeld, is een werkgever tegenwoordig niet meer bereid om mensen die moeite doen hiervoor gepast te belonen.
Tja dan krijg je dat he, Ik kan er aleen maar om lachen.
@Pascal, het probleem is wel dat die relikwie die jij noemt, in erg veel software bij heel veel organisaties gewoon draait. Vermoedelijk al sinds de jaren 60/70. Deze organisaties “durven” en meer zakelijk “doen” geen migratie van deze code. Als je vraagt naar de reden waarom ze niet migreren naar meer programmeertalen waar gewoonweg meer programmeurs in geschoold zijn, lees ik alleen maar angst in de ogen.
Met wat doorvragen kom je er dan achter dat ze eigenlijk niet meer weten wat de software dan exact doet (functioneel) en met de omgeving interacteert (interfaces).
Overigens zijn C#, Java ook gewoon normale programmeertalen als Cobol. Waar Cobol meer uit de tijd van Pascal en ALGOL komt, heeft in die tijd veel voordelen voor administratieve software. Daarom draait het ook bij veel financiele en andere informatierijke organisaties. Zonder een kampenstrijd te beginnen, kun je jezelf wel de vraag stellen of talen als C# of Java zich nu echt zo goed lenen voor deze software. Deze talen zijn vooral onder veel commercieel geweld op de markt gekomen en er hangen veel frameworks/eco systemen aan vast.
Probleem van de organisaties die Cobol hebben draaien is dat de “oudjes” met pensioen gaan of misschien er al niet meer zijn. Aanwas is dus praktisch nul. Wie gaat straks al die code migreren?
Helemaal mee eens. Cobol is een taal voor administratieve toepassingen, en een goed geschreven Cobol programma leest als een roman. Ook een niet-programmeur kan redelijk begrijpen wat er in een Cobol programma gebeurt. Dat maakt het onderhoud in principe eenvoudig, opnieuw mits goed geschreven. Cobol programma’s kunnen in hoge mate zelf documenterend zijn, hoeveel programmatuur is gedocumenteerd? Vergeet ook niet dat Cobol nog steeds ontwikkeld wordt, we hebben nu Cobol 2002 er staat nog een nieuwe versie op stapel. Een goede Cobol compiler zal onder water ook heel veel controle code inbouwen, bijvoorbeeld controleren of een numeriek veld inderdaad een numerieke waarde bevat. En over velden gesproken, welke taal kent zoveel mogelijkheden om een veld te definiëren?
Veel programmeurs vinden het geweldig interessant om zo cryptisch mogelijk te programmeren. Alleen zij zelf kunnen begrijpen wat ze geprogrammeerd hebben, maar een half jaar later snappen ze het zelf ook niet meer. Als je daarom graag programmeert in een computertaal die sourcecode gebruikt waarbij het lijkt alsof de kat over het toetsenbord gelopen heeft, dan is een taal waarbij de loonadministrateur zelfs kan lezen en begrijpen wat jij geprogrammeerd hebt natuurlijke helemaal niet sexy.
Een goede Cobol programmeur die optimaal gebruik weet te maken van de vele mogelijkheden die Cobol biedt kan bedrieglijk eenvoudig uitziende, compacte, en tegelijk heel krachtige sourcecode schrijven. Vanuit een business optiek lijkt mij da bepaald een voordeel boven de enorme hoeveelheden onbegrijpelijke en onbeheersbare bloatware die tegenwoordig vaak geproduceerd wordt bij administratieve programmatuur.
@atillav, Hoewel ik wel eens ooit naar Cobol heb gekeken is de banken en verzekerings wereld niet de sector waar ik ooit werkzaam ben geweest.
Komende uit een wereld van ADA, ALGOL en FORTRAN heb ik however o.a. redelijk wat in FORTRAN (een relikwie dat ongeveer uit de zelfde tijd stamt) software geschreven. Niet bepaald iets wat ik voor de lol deed maar zeker ook geen heldhaftige onderneming in tegendeel zelfs weinig moeilijks aan.
Het gaat mij er niet om dat de betreffende sector naar een meer courante programmeertaal moeten overstappen, daar zie ik weinig voordeel en ik moet er werkelijk niet aan denken dat de weinige centjes die ik bezit afhankelijk zijn van keurig WO opgeleide ‘specialist’ wiens capaciteiten nooit verder gekomen zijn van VisualBasic ,C# of Java (ik had een andere zin gecomponeerd, maar Computable is een respectable magazine)
Waar het mij wel omgaat is dat de betreffende ondernemingen niet moeten miepen dat er geen jongetjes meer van school komen die Cobol in hun opleiding hebben gehad maar er zelf voor moeten zorgen dat deze kennis aan nieuwe mensen wordt doorgegeven dan wel dat zij zelf zorgdragen dat er een passende opleiding voor komt (geen idee waarom eigenlijk ik heb alle talen die ik beheers zelf eigen gemaakt, dat kan iedere andere ontwikkelaar van enig caliber ook)
@Dirk ik ga met je mee dat het zaak is dat je goed leesbare en duidelijk verifieerbare code moet schrijven en er geen (overigens kenlijk facto standaard) cryptische bagger moet schijten, los of dit een hoogstandje is of niet wel te verstaan.
Een belangrijke les die ik altijd probeer over te dragen is ‘use the right tool for the job’ dat geld evenzeer voor programmeer talen. Je geen dynamische website in C schrijven (ja maar ik kent iemand…. rot op man) je gaat geen systeembeheertaken in php schrijven (weer op een hoop tere zieltjes getrapt) en je gaat geen administratief paket in JAVA bijeen schijten.
Zo zijn er nog zat voorbeelden van don’ts en do’s te verzinnen. Cobol hoef ik niet zo nodig op mijn prive systeem (FORTRAN ook niet, maar staat er toch nog op) maar daarmee geef ik er zeer zeker nog niet op af, bij herhaling zeg ik enkel dat een organisatie die graag bepaalde specialisatie wil daarvoor niet bij onderwijsinstellingen moeten zijn.
Ik kwam overigens een bedrijf tegen dat het product VisualCobol op de markt brengt !
AARGH !!!! mijn centjes snel in een veilige ouwe sok onder het matras !
Pascal,
‘Use the right tool for the job’ is precies waar ik op doel, en Cobol is ideaal voor administratieve doeleinden. Dat blijkt ook wel, want zo’n 50 procent van alle administratieve programmatuur is nog steeds geschreven in Cobol. Het probleem is alleen dat de ict een werkgebied is dat vooral geregeerd wordt door hypes en mode. Cobol is natuurlijk één van de oudste talen (ik kan mij nog herinneren dat Cobol-programma’s regelnummers hadden 🙂 ), dus dan moet het wel een fossiel zijn dat je zo snel mogelijk moet vervangen door iets moderns. Dat die taal gewoon verder ontwikkeld is en aangepast aan de eisen van de tijd en dus nog steeds bij uitstek geschikt is voor je administratieve programmatuur speelt dan blijkbaar geen rol.
Jaren geleden was het duidelijk, we moesten over naar C. Nu is C niets anders dan een geglorificeerde universele vervanger van assembler, bij uitstek geschikt voor het schrijven van drivers etc. door vooral kundige programmeurs. Daar waar een Cobol compiler onder water allerlei controle routines zal invoegen om bijvoorbeeld te voorkomen dat een index-pointer met waarde 200 een index gaat lezen of schrijven die maar 100 entries groot is, daar zul je bij C zo’n controle zelf moeten inbouwen. Dat is logisch, want een driver bijvoorbeeld moet alleen de uiterst nodige instructies bevatten, en niets meer. Het is aan de programmeur om precies te bedenken welke controles en fout opvang waar in de code opgenomen moet worden.
Ik heb eens meegemaakt hoe een administratief programma herhaaldelijk crashte op file problemen. Als supporter werd ik gevraagd de programmeur te helpen bij het vinden van de oorzaak. Het programma was natuurlijk geschreven in C (want modern). Ik vroeg hem dus welke foutmeldingen het programma gaf. Geen enkele, alleen een register dump. Maar je hebt toch wel fout afvang routines ingebouwd? vroeg ik hem. Nee dus, en ik hoor hoe hij zijn collega’s vraagt “bouwen wij ook fout afvang routines in onze programmatuur?” “Nee” hoorde ik alle collega’s brullen. En dat terwijl dat soort fout afvang als kant en klare subroutines in de standaard C bibliotheek werden bijgeleverd. Cobol heeft voor zulke file problemen de Declaratives die automatisch worden aangeroepen.
Hier zie je dus het resultaat van niet ’the right tool for the job’, en je kunt je afvragen hoeveel fouten niet gedetecteerd worden omdat de taal noch de programmeur de nodige controles inbouwen.
@Dirk: Maar ze ontwikkelden wel Agile? 🙂
Errors niet juist afvangen is iets wat de klikklakklaar generatie niet heeft mee gekregen. Als het niet werkt, breng je toch gewoon een nieuwe versie uit? Zoals de beheerder gewoon de machine opnieuw opstart.
Dat IT stiekem een beta richting is en je alles zo sluitend kan maken als een boekhouder terzijde.
Tanenbaum was ook voorstander van juiste foutafhandeling binnen besturingssystemen. Het is ook daar waar de oorsprong van het meeste van het geaccepteerde afraffelwerk ligt. Besturingssystemen die onleesbare foutmeldingen genereren die de standaard geworden zijn.
De tijd dat Cobol ideaal was voor administratieve toepassingen ligt ver achter ons. De leesbaarheid mag dan stukken beter zijn dan die van assembler, hij komt niet in de buurt van modernere talen als lisp, pascal en smalltalk… Een van de dingen die die (en vele andere) talen stukken beter doen is het vermijden van duplicatie. Daarmee wordt de roman een stuk minder saai, en is de kans dat fouten in één keer goed verbeterd worden een stuk groter.
Als je een migratie succesvol wilt doen is het handig om een hele korte feedbackloop te maken. Ik heb uitstekende resultaten behaald met het dagelijks maken van plaatjes van hoe ver we waren, hoe we dachten dat het in elkaar zat, en wat we nog niet begrepen, zodat de domeinexpert van de klant ons kon sturen. Het snel oppikken van Cobol was geen probleem, het is een redelijk simpele taal. Snappen hoe het systeem gebruikt wordt en waar prioriteit aan gegeven moet worden wel, en daar is de betrokkenheid van de domeinexpert cruciaal.