Development

Software-ontwikkeling
Wat is programmeren?

Wat is programmeren?

Wanneer programmeert iemand echt iets? Met welke factoren heeft dat te maken?

4 juni 2020

Het thema van dit nummer is no code/low code. Dat roept natuurlijk de interessante vraag op wanneer we iets als code zien. Een Mendixmodel zien we over het algemeen als ‘low’ code, een klasse in C++ is ‘gewoon’ code. Waarom eigenlijk? Boxes and lines, dat is geen echt programmeren, lijkt de gedachte. Echt programmeren, dat doe je met je toetsenbord, niet met je muis.

Het onderwerp van wat programmeren is houdt mij al lang bezig. No code is volgens Wikipedia namelijk iets dat eindgebruikers kunnen, zonder tussenkomst van een programmeur. Dan denk je al snel aan … spreadsheets, en laat dat nu net het onderwerp van mijn proefschrift zijn. Ik maakte, kort samengevat, een soort IDE voor Excel in mijn promotietijd, met ondersteuning voor unittests, refactoring en code smells. Handig voor eindgebruikers die soms heel ingewikkelde Excel-modellen maken. Hoon en spot viel mij ten deel; Excel, dat is toch zeker geen 'echt' programmeren?! Zelfs het feit dat ik erin slaagde om een Turingmachine te maken met formules was niet overtuigend genoeg.

Halverwege vorig jaar besloot ik die visies van programmeurs eens onder de loep te nemen. Samen met een bevriend webdeveloper ontwierp ik een survey waarin programmeurs konden aangeven welke programmeertalen zij als het ‘meest programmeren’ zien en waarom. De resultaten waren tegelijk verrassend en vreselijk voorspelbaar. De echte talen, dat zijn natuurlijk alle C-talen (C, C++, C# en zelfs Objective-C stonden hoog in de rankings), dan een groepje scriptingtalen zoals Python, Ruby en PHP, en dan het ‘restje’: Excel, SQL en XML.

De redenen die mensen opgaven - die waren wel verrassend! Nummer 1: moeilijkheidsgraad. Hoe moeilijker, hoe meer programmeren. Eigenlijk raar als je erover nadenkt. Een programmeertaal is toch uiteindelijk een gereedschap. Wie is er nou dol op een hamer die steeds uit je hand glipt en waarvan de kop er steeds afvliegt? Waarom is een moeilijkere taal een waardigere taal? “Je kunt een hoop met een beetje HTML”, zei een van de deelnemers, “maar voor Java moet je echt dingen snappen, zoals memory management”. Het is duidelijk: het is goed als je veel moet weten van de onderliggende computerarchitectuur. Toegang tot het blote metaal werd door veel deelnemers als een wenselijk aspect gezien: hoeveel controle krijg ik over de machine zelf? Dit koppelt natuurlijk naar no en low code. Die vormen van programmeren geven vaak weinig controle over de machine en abstraheren ervan – je zou ook kunnen zeggen: lossen de lastige problemen voor je op – en zijn dus niet echt programmeren.

Een programmeertaal is toch uiteindelijk een gereedschap

Als vrouw in de informatica kan ik het niet laten om dit ook als een mannelijk perspectief te zien: machines, en daar dingen aan/mee mogen doen, dat is een bezigheid die we toch vooral met mannen en mannelijkheid associëren. Hoe verder van het metaal af, hoe minder stoer het is en dus hoe minder street cred de programmeertaal de gebruiker gaf. Ook dat kwam regelmatig voor als antwoord: hoe populair een taal is, of hoe andere programmeurs de taal zien bleek ook van invloed op hoe ‘echt’ een taal gezien werd. Grappig om te zien dat programmeurs die zeggen wars te zijn van trends en modes, toch ook naar anderen kijken in het vormen van hun meningen over talen. Het zijn net mensen.

Magazine AG Connect

Dit artikel is ook gepubliceerd in het magazine van AG Connect (meinummer 2020). Wil je alle artikelen uit dit nummer lezen, klik dan hier voor de inhoudsopgave.

Reactie toevoegen
7
Reacties
Marco Schramp 06 juni 2020 13:42

Mijn kinderen maakten een indrukwekkend spelletje met Scratch waar ik als C++ programmeur nog een stevige dobber zou hebben. Conclusie is dat de taal (visueel of tekst) het niet tot programmeren maakt, maar de capaciteit om voor elkaar te krijgen wat voor je doel nodig is. Zou ik een administratief system in Scratch makes? Geen goes idee...

Root Adminidtrator 05 juni 2020 13:16

Het is niet verrassend dat de moeilijkheidsgraad als een van de criteria werd genoemd. Als het eenvoudiger wordt spreken we meestal van scripten. Ik snap ook niet waarom alles ineens programmeren moet heten.
Wat dan weer ergerlijk is is zo'n vergelijking met een hamer die steeds uit je handen vliegt. Als we dat doortrekken, dan moet iedereen ineens ook "timmerman" heten, ook al kunnen ze nog geen hamer vast houden.
Het argument dat er een Turing machine mee gemaakt kan worden slaat ook nergens op. Richard Ridel heeft een Turing machine van hout gemaakt, maar schuren, zagen, frezen etc. is daardoor niet ineens programmeren geworden.
Oh ja, het is ook natuurlijk weer de schuld van mannen dat niet alles programmeren wordt genoemd.

Atilla Vigh 05 juni 2020 12:14

Het klopt dat er zeker geen "beste" taal is. Praktisch gezien is het prettiger om te putten uit een zeer groot vat van ontwikkelaars die een taal machtig is. Met meer dan duizenden programmeertalen, waarvan er natuurlijk een handjevol echt veel worden gebruikt, is er een te gefragmenteerd landschap van programmeertalen. Naast wat een bepaalde taal wel of niet kan, is de inzet van ontwikkelaars zeer relevant. En natuurlijk leent Fortran zich meer voor rekenintensieve taken dan een meer algemenere taal (Pascal, C, etc....). Daarom zou ik op zijn minst pleiten om algoritmiek te gebruiken voor elk software ontwikkeltraject en eenmalig met honderden ontwikkelaars de ultieme inlogprocedure te schrijven voor alle gangbare programmeertalen (of er een van kant-en-klaar van de plank te halen) en deze universeel in de standaard van die taal op te nemen. Het moet dan verplicht worden dat als je wat software gaat bakken, eerst in die standaard gaat kijken of het al is geschreven. Dan houden we zowel de verschillende talen in stand (als dat zo nodig moet) en we gaan eindelijk hergebruik van software daadwerkelijk toepassen.
I have a dream!

JGM van der Zanden 04 juni 2020 17:02

Misschien geeft toch Wiki nog de beste definitie: Programmeren is het schrijven van een computerprogramma, een concrete reeks instructies die een computer kan uitvoeren.
Je zou daarnaast nog de eis kunnen stellen dat een "goede" computertaal de mogelijkheid moet bieden om ELK denkbaar algoritme in te kunnen realiseren.
Tenslotte zou ik denken: hoe eenvoudiger, sneller en foutvrijer in gebruik, hoe beter de taal. Dus assembler is wel een hele slechte taal. Daarom maakte ik al in 1981 embedded software met Pascal.
Excel, zeker in combinatie met VB, voldoet natuurlijk gewoon aan de definitie van een taal: je kunt er alles mee oplossen. En een bepaalde klasse van problemen en algoritmes is daarmee zeer eenvoudig op te lossen.
Dat leidt dan tot de 4e conclusie: Er is geen beste taal. Voor een bepaald type problemen is een bepaald type taal het beste (MS Acces bijv. voor simpele databases; Python voor tekstanalyses).
Er zou nog wel betoogd kunnen worden dat de beste talen, die talen zijn die OOK maximale intrinsieke controles (type checking, integriteit, leesbaarheidseisen in de syntax etc.) op compile time hebben. Daarmee zijn dan bijv. de C-talen inferieur t.o.v. Pascal en Java. Dat blijkt ook wel uit onderzoek; fouten met pointers in C kosten, net als foute spreadsheets, miljarden per jaar......

Nico 04 juni 2020 14:34

Interessante en goede kijk op programmeren. Programmeren staat los van de programmeertaal waarin men dat doet. Een artikel schrijf je in de taal die jij en de ontvanger begrijpen. Of het een goed artikel is komt voort uit de opbouw niet uit de taal die is gebruikt. Daarom is een goed boek ook naar elke taal te vertalen. Dat zelfde gaat op voor programmatuur. Er zijn wel programmeertalen die bepaalde functionaliteit bevat die in een ander programmeertaal niet mogelijk is. Maar die functionaliteit staat los van het kunnen programmeren.
Wanneer je kan programmeren, dan kan je dat in principe in elke programmeertaal, je moet daarvoor wel de specifieke syntax van die taal leren. Net zoals je dat moet doen om iets in het Engels te kunnen schrijven. En daarbij hoort ook het bepalen waar je aan moet sluiten op bestaande systemen of er frameworks zijn die gebruikt kunnen worden en van het bestaan van modules weten die je kan gebruiken.

Atilla Vigh 04 juni 2020 12:23

Software ontwikkelaars leven bij het adagium "Not invented here! (BTW, Infra specialisten leven bij het adagium "Pielen tot je een ons weegt"). Beide adagia zijn het gevolg dat er compleet niets wordt afgedwongen. Sinds mijn hele carriere wordt al gewag gemaakt van hergebuikt van code. Het enige dat ik merk is dat er alleen maar meer code bijkomt. Hoeveel loginprocedures in hoeveel programmeertalen zijn er inmiddels wel niet in elkaar geknutseld?
Natuurlijk zou het efficiënter en effectiever zijn dat er meer abstractie in kant-en-klare bouwblokken beschikbaar komen waar iedereen gewoon mee werkt. Het nadeel van die abstractie is dat die aangeboden wordt door vaak weer commerciële organisaties of idealisten. De commerciële organisaties zorgen ervoor dat de abstractie dermate wordt vormgegeven, dat combinaties van technologieën (integratie) en afwijkingen van de standaard niet mogelijk is. De idealisten vergissen zich vaak in de hoeveelheid onderhoud en werk er in standaardisatie gaat zitten.
Zolang het "God voor ons allen, en ieder voor zich" onder ontwikkelaars de manier van werken is, de commerciële partijen over elkaar heen vallen met hun "ultieme oplossing" en de idealisten de bomen door het bos niet meer zien, verwacht en zie ik niet zo snel een uitkomst in deze.

Arnold Wentholt 18 mei 2020 14:07

Interessant artikel. Wel verbazingwekkend, omdat heel wat vooral ervaren programmeurs aangeven dat zij graag bouwen aan abstractielagen/frameworks/bibliotheken/DSL's om het niveau van abstractie bij het programmeren in overeenstemming te brengen met het probleemdomein. Uiteindelijk maakt het vanuit functioneel perspectief niet zoveel uit welk formalisme c.q. kale syntax het startpunt is geweest. Het kunnen staan op de schouders van anderen door, bijvoorbeeld in Python, gebruik weten te maken van de (op het moment van schrijven) 234.691 modules, is voor programmeurs essentieel.