Mobile, responsive en web bepalen development

Softwareontwikkeling krijgt een steeds belangrijkere rol in de ict-markt. Naast traditionele software wordt er tegenwoordig ook software ontwikkeld om als dienst uit de cloud aan te bieden. Daarnaast wordt software toegevoegd aan hardware en met de komst van smartphones en tablets zijn de ontwikkelaars van apps bijna niet aan te slepen. Die toename in softwareontwikkeling zorgt ook voor nieuwe ontwikkeltalen. Welke talen bepalen de ict-markt van nu en wat zijn de ontwikkeltalen van de toekomst. Onze experts van het topic Development aan het woord.

Wilrik Atsma, php- en .net-programmeur bij Senet

Ik voorspel dat het steeds meer richting web gaat, en dus Javascript en html5. Sowieso zie je de laatste jaren al dat de traditionele desktopapplicaties steeds meer plaats maken voor webapplicaties. De html5- en Javascript-standaarden worden ook steeds eenduidiger waardoor de verschillen in verschillende browsers steeds kleiner worden. Groot voordeel van webapplicaties is natuurlijk dat je niet meer afhankelijk bent van één computer waarop een programma draait, maar het op elk systeem met een browser gebruikt kan worden.

Ook voor mobile apps denk ik dat webontwikkeling steeds meer de overhand krijgt. Frameworks als PhoneGap of Sencha Touch worden steeds beter en kunnen qua prestaties nu al voor veel toepassingen native ontwikkelde apps evenaren. Het voordeel van apps maken op deze manier is dat je door één keer te ontwikkelen alle platformen dekt.

Robbrecht van Amerongen, manger development practice bij Amis Services

Het grootste issue bij ontwikkeltalen is de apparaatspecifieke interface. Dit was vijftien jaar geleden bij WAP al het geval. Per toestel moet een interface gemaakt worden. Op dit moment ontstaat er steeds meer ruimte tussen ‘native’ (iOS, Andoid, Windows Phone) en ‘responsive’ in html5. Hiertussen zitten verschillende hybride oplossingen die één taal voor verschillende apparaten genereren. Hierbij is PhoneGap de grootste speler, maar zijn Appcelerator Titanium en Sencha Touch ook goede alternatieven. Onder de motorkap gebruiken ze vaak html5. Je ziet dat deze technieken steeds meer richting een cloudontwikkelomgeving gaan. Hierdoor wordt het mogelijk om steeds meer standaardcomponenten aan te kunnen bieden.

De echte keuze en oordeel over een ontwikkeltaal is sterk afhankelijk van de functionaliteit, budget en de doelgroep. Een high-end mobiele toepassing met rijke functionaliteit zal op korte termijn nog altijd met een native taal gemaakt worden. Een goedkope informatieve applicatie met heterogene doelgroep komt meer in aanmerking voor html5. Terwijl administratieve applicaties met een relatief heterogene doelgroep vaak het goedkoopste zijn met een hybride oplossing. Daarnaast kan je ook kijken naar de techniek van het backoffice-platform. Als hier bijvoorbeeld al veel Oracle wordt gebruikt, dan is Oracle ADF mobile een logische vervolgkeuze.

Maurice Siteur, testmanager bij Capgemini

Ik voorzie een trend dat ontwikkeltalen/omgevingen voor mobile en internet één gaan worden. Het lijkt er nu op dat het twee omgevingen zijn en voor mobile misschien wel meer, waarbij onderhoud vanuit ontwikkeloogpunt en gebruikersgemak vanuit ‘operations’ alleen maar lastiger lijken te worden. Html5 lijkt dit deels te ondersteunen.

Ik hoop dat de apps een kort leven beschoren zijn. Apps zijn half SaaS en dat is niet handig. Of ontwikkeltalen/omgevingen als Mendix, Pegasys het gaan winnen van Java, .Net, et cetera? 4GL-talen hebben ook nooit een al te grote toevlucht genomen. Cobol zal niet sterven. Waarom zou dat na zoveel jaar in een keer wel gebeuren?

Jos van Rooyen, principal consultant testen bij Bartosz ICT

Bij testen van mobile apps komen een aantal zaken naar voren. Wat opvalt is dat er een enorme hype is ontstaan rond het testen van apps. Kijk je een stap verder, dan verschilt het niet zoveel als met het testen van andere applicaties. De accenten komen anders te liggen. Een voorbeeld is de gebruiksvriendelijkheid. Een app moet handig zijn in het gebruik, zelfverklarend en een logische flow hebben. Is het teveel zoeken dan zal de app niet geaccepteerd worden.

Is dit anders dan bij andere applicaties zoals websites? In essentie niet, maar deze aspecten komen nu nadrukkelijk naar voren. De technieken om dit te testen zijn al jaren beschikbaar. Naast de gebruiksvriendelijkheid spelen uiteraard de functionaliteit, porting over alle type smartphones en het gebruik van de bandbreedte een essentiële rol.

John Verwaaijen, general manager bij Magic Benelux

Ik denk dat ontwikkeltalen bezig zijn te evolueren naar programmagenererende wizards die gewenste functionaliteit op een relatief abstract niveau omzetten naar applicaties. Je tekent een pagina, geeft aan wat een en ander op die pagina moet doen en het platform doet de rest, inclusief integratie met backoffice-systemen en deployment naar iTunes-, Android- en Windows 8-markets.

Dit betekent dat applicatiebouw in toekomst in afnemende mate door ontwikkelaars zal worden gedaan en veel meer door proceseigenaren en architecten in en tijdens de bedrijfsuitoefening. Er komen dus platformen die gedachtegangen kunnen volgen. Dit zal daarmee dan ook een revolutie teweegbrengen in gevestigde erp- en crm-systemen, Force.com speelt hier ook al op in en staat op het punt een geduchte tegenstander te gaan worden voor Dynamics, Oracle EBS en JDE en uiteraard SAP.

Marcel den Hartog, senior principal product marketing manager bij CA

Ik ben van de mening dat alle ontwikkeltalen op den duur, en soms duurt dat helemaal niet zo lang, de status ‘legacy’ krijgen. En als dit misschien niet meteen telt voor de taal zelf, dan zeker wel voor de incompatibele versies die leveranciers soms, gedwongen door de techniek, uit moeten brengen. Denk maar eens aan de problemen in het verleden met een Java-versie die niet compatible was met zijn voorganger, waardoor miljoenen regels code geconverteerd moesten worden.

Ik denk dat de industrie zo langzamerhand toe zou moeten werken naar producten waarmee applicaties beschreven en gemodelleerd worden en waarmee dan code wordt gegenereerd. Het is dan aan leveranciers om er voor te zorgen dat nieuwe talen ondersteund worden en zijn het niet langer de bedrijven die met de rotzooi opgezadeld worden. Dat dit mogelijk is wordt op IBM-mainframes al jaren bewezen met middelen waarmee het mogelijk is om aan de hand van een model Cobol of, met hetzelfde model, Java te genereren.

We trainen nu jonge mensen in de meest gruwelijke talen op de universiteiten in Nederland en bijna op het moment dat deze personen afgestudeerd zijn, is hun kennis verouderd en moeten zij nieuwe talen en protocollen leren. Een verspilling van tijd en moeite. Laat de leveranciers die ontwikkelomgevingen aanbieden dit oplossen zodat de kosten niet door één bedrijf, maar door vijfhonderd bedrijven gedragen kan worden.

Dus in plaats van allerlei commissies die Java, Cobol en andere talen nu certificeren en definiëren zou de industrie een standaardbeschrijvende taal moeten definiëren waaruit leveranciers vervolgens code kunnen genereren in om het even welke programmeertaal. Programmeertalen zijn de heroïne van de it-Industrie. Als een keuze eenmaal gemaakt is, kunnen bedrijven moeilijk, of zelfs helemaal niet, meer voor een andere richting kiezen. Je bent per slot van rekening .Net of Java, niet waar?!

Ralf Wolter, senior software consultant bij Sogyo

Een tijdje geleden zag je dat de ontwikkeltalen een beetje vast zaten. Elke branche had zijn eigen taal en er was niet heel erg veel beweging. Alles was Java, C++ of C#. En toen kwam Apple met de iPhone. Hiervoor mocht alleen ontwikkeld worden in Objective C, de eigen taal van Apple. Ontwikkelaars die apps wilden ontwikkelen, moesten naast hun normale taal deze nieuwe taal leren.

Dit zorgde er voor dat ontwikkelaars meerden talen moesten leren. Objective C voor iPhone, Java voor Android en C# voor Windows Phone. Specialisatie op een enkele taal zit nu in de weg, het beperkt je tot een enkel platform. De toekomst voor ontwikkelaars is je niet te beperken, maar de taal te kiezen die past bij je probleem.

Ramon Zanders, managing director bij Yonder

In de laatste decennia zijn duizenden programmeertalen tot leven gekomen, van de populaire C, Java of C++ tot de exotische en esoterische Malbolge, Lolcode of Whitespace. De reden dat er een wildgroei aan programmeertalen is ontstaan, is dat ontwikkelaars altijd bezig waren met innovatie en efficiëntie van hun talen om bepaald computergedrag te beschrijven middels nieuwe programmeerparadigma.

In het laatste decennia hebben Java en C# een dominante rol gespeeld in de enterprise softwarewereld. Met beide talen kan men enorme oplossingen ontwikkelen, bestaande uit miljoenen regels code terwijl de complexiteit en specifieke platform optimalisaties beperkt blijven in tegenstelling tot hun C- en C++-voorgangers. De toenemende dominantie van web als een gevestigd user interface-platform en de onbeteugelde evolutie van mobiel zorgen ervoor dat programmeertalen zoals JavaScript en Objective C een explosieve groei doormaken.

Als ik JavaScript onder de loupe neem, dan zie ik een taal die ontwikkeld is in de jaren negentig voor totaal andere doeleinden dan het vandaag de dag gebruikt wordt. Losstaand van de design tekortkomingen, deelt JavaScript de progammeerwereld in tweeën: clientontwikkeling en serverontwikkeling. Vanuit een efficiëntieoogpunt maakt dit het moeilijker. Daarom zijn initiatieven zoals Google Dart en Microsoft TypeScript zo interessant. Zij zouden zich kunnen ontpoppen als de nieuwe enterprise programmeertaal van de toekomst, zeker nu mobiel zich ontwikkelt richting webtechnologie en deze tools en technologieën volwassen worden. Dan zal het landschap van nieuwe servergeoriënteerde ontwikkeltechnologieën zoals Node.js ook weer anders worden. Mochten initiatieven zoals Google Dart en Microsoft TypeScript uitgroeien tot veel gebruikte enterprise ontwikkelplatformen, dan zal dit waarschijnlijk leiden tot een meer holistische aanpak, doordat er een homogener ontwikkellandschap ontstaat. De vraag is niet of, maar wanneer het bestaande landschap opnieuw gedefinieerd wordt.