Had ik niet verwacht, dat "afwezig" en "beginner" al meer dan 50% van de stemmen bevatten.

Gezien het algehele niveau in de computerbeveiligingsindustrie en de insteek van dit nieuwsovertikblog van vooral geinteresseerde leek willen aantrekken (en dat ook doen) is het niet zo heel raar. Of je moet het over de geimpliceerde eerlijkheid hebben.

@ bbecko 16:18 en @ Anoniem 21:22,
Security.NL wordt bepaald niet alleen door IT-pro's of zelfs maar door gevorderde gebruikers bezocht. Dat blijkt ook duidelijk uit een deel van de vragen die in het forum-gedeelte worden gesteld, en ook eerdere poll-uitkomsten lieten zien dat Security.NL bepaald niet alleen door IT-pro's en gevorderde gebruikers wordt bezocht. Dat in de huidige poll een groot deel van de bezoekers aangeeft nauwelijks of geen programmeer-skills te bezitten, dat sluit daar prima op aan en zou dus niet moeten verbazen, denk ik.

Programmeren is saai.

Maar nog saaier zijn "free" tools voor mensen die niet kunnen programmeren. Ik heb laatst gekeken naar een GUI tool om iptables rules te maken. Man, man, man. Je moet wel een enorme inlevingsstoornis hebben om zoiets gruwelijks te bedenken. Uiteindelijk moet je iptables expert zijn en de anti-intuitieve tool leren begrijpen, dus het is veel eenvoudiger, sneller en beter om de rules zelf te schrijven. Kennelijk zit de moeilijkheid niet in programmeren maar in ontwerpen. Dan vallen per definitie meteen ook alle autisten af.

Iets met een kam en scheren.
Een (G)UI in elkaar knallen is natuurlijk wel even wat anders dan mooie code schrijven.

En niet om het één of ander, maar wij hebben een autist op freelance-basis in dienst, werkt alleen van 21:00 tot 06:00, nooit aanwezig op vergaderingen, geen enkel sociaal contact met de collega's, maar een DIJK van een programmeurgod. Python, C++ en .Net draait hij zijn hand niet voor om. Knalt sneller VB-scripts in elkaar dan ik kan knipperen met m'n ogen, kent syntaxis uit z'n hoofd waarvan ik het bestaan niet eens weet.
En nog nooit een deadline gemist, óók belangrijk.

Ik heb "gemiddeld" geantwoord, daar ik diegene ben die zijn werk meestal controleert (lees: "test")... :p


@Redactie: beste poll die ik tot nu toe ben tegengekomen op deze site!

Programmeren is iets dat wilt willen doen.

Ik kan programmeren als ik er tijd in steek maar ik steek er niet genoeg tijd in om meer dan een "beginner" te zijn.

Hmm, zijn html en css programmeertalen ?

Hoe kom je daar nou bij? Programmeren is heerlijk ;-).
Ik denk dat het probleem hier is dat maar al te vaak gedacht wordt dat de inherent aanwezige complexitiet van de materie wel even afgeschermd kan worden. Dat is lang niet altijd zo, er is vaak een hardnekkige wet van behoud van ellende van toepassing.

Als je in zo'n situatie toch probeert de materie behapbaarder te maken voor een groep niet al te kundige gebruikers, of je dat nou met een GUI of een of ander soort abstractielaag doet, dan bereik je in de praktijk alleen maar dat het resultaat beginnersvriendelijker is dan het origineel omdat je simpele dingen zonder veel kennis van zaken voor elkaar krijgt, maar dat je in tweede instantie alsnog met de volle dosis complexiteit te maken krijgt zodra je iets meer wilt bereiken.

En dan wordt de kans erg groot dat de abstractielaag (en een GUI die iets simpeler probeert te presenteren dan het eigenlijk is vormt ook een abstractielaag) meer eigen complexiteit toevoegt dan hij wegneemt. Dat komt omdat je uiteindelijk, zoals je zelf constateert, toch het onderliggende mechanisme moet begrijpen om eruit te komen, en als je zover bent dat je dat snapt dan is de abstractielaag/interface die eromheen gebouwd is eigenlijk alleen nog maar ballast die het geheel nodeloos ingewikkeld maakt.

Ik heb, met inmiddels 30 jaar programmeerervaring, de laatste jaren bij steeds meer hulpmiddelen die langs komen om het leven makkelijker te maken, van contentmanagementsystemen tot webframeworks tot workflowmanagementsystemen tot message brokers, het gevoel dat ze alleen nog maar de ene vorm van complexiteit door een andere vervangen. Dat wil beslist niet zeggen dat dat voor alle hulpmiddelen geldt, maar ik concludeer in toenemende mate dat de werkelijk goede toevoegingen helemaal niet proberen iets onzichtbaar te maken, die veronderstellen dat je de essentie van het onderliggende mechanisme juist goed kent en begrijpt en zorgen alleen dat je het directer, met minder "ruis" of "boilerplate", kan toepassen.

Dit alles is sterk verwant met de "law of leaky abstractions" van Joel Spolsky:
http://www.joelonsoftware.com/articles/LeakyAbstractions.html

Is Hodor ook een mogelijkheid?

Volgende week vast wel weer.

Een goede abstractie kan je enorm helpen, maar om hem te creeeren moet je zowel de onderliggende als de bovenliggende materie --mechanisme en gebruikspartroon-- doorgronden.

Abstracties nemen namelijk altijd expresiviteit weg, dus moet je met wat er overblijft helderder kunnen zeggen van wat je wil zeggen dan zonder. Dus is het niet geschikt als vehikel om jezelf te verdedigen tegen moeten snappen wat je doet. Zet je het toch zo in, rijd je vooral zowel jezelf als de gebruikers van je software in de wielen.

Merk op dat bijvoorbeeld de appliances van apple hier hele sterke keuzes hebben weten te maken, en dat bijvoorbeeld de rommel uit redmond hier notoir klungelt.

(Persoonlijk werk ik vooral met CLIs want GUIs passen gewoon niet goed in mijn manier van werken; daar zijn ook grote verschillen waar te nemen in hoe nuttig een zeker commando is.)

Nu heb ik geen 30 jaar ervaring maar ik heb wel het idee dat dit nooit echt anders geweest is. Er is altijd die drang eer van je werk te halen. Bouw een "framework" wat iedereen kan gebruiken en promoot het en kijk, allerlei mensen blijgemaakt met jouw nuttige software. Ook als je die software precies voor dat doel inelkaarknutselt en daardoor grote lappen nauwlijks geteste software de wildernis instuurt, vol met "algemene" routines die orthogonaal in het ontwerp passen maar die jij nog nooit nodig gehad hebt, bijvoorbeeld.

Dit voltrekt zich in golven, en is vaak politiek geladen. Ook in de open source wereld zijn daar verschillende voorbeelden van aan te wijzen. Kijk bijvoorbeeld naar wat voor de hand liggende controversen.

Best kans dat de schrijvers van de meeste abstracties niet snappen hoe een goede abstractie eruitziet.

Of dat je ondertussen zelf beter af bent zonder het type "bescherming" dat je pleegt tegen te komen.

Daar is heel veel discussie over. Ik noem ze zelf altijd scripting talen omdat het geen talen zijn die gecompileerd worden zodat deze direct door processor uitgevoerd kunnen worden. Ander gezegd: ze worden altijd geïnterpreteerd door een andere programmatuur die wel instructies geven aan de processor. Andere scripting talen zijn zou ik zeggen: PHP, CSS, Batch, Javascript, LUA en Python.

Sommige programmeurs doen een beetje lacherig over web programmeurs (eigenlijk scripters) omdat ze niet tot de kern programmeren. Dat wil zeggen: dingen waar scripters zich haast niet druk over hoeven te maken: geheugen management, typecasten en buffer under-/overflows.

Scripting
Voordeel: makkelijker
Nadeel: minder efficiënt en vaak minder snel uitgevoerd

Programmeren
Voordeel: meer controle over efficiëntie
Nadeel: meer foutgevoelig

Kan je een algoritme, zeg om de reeks van Fibonacci produceren of om een lijst waarden te sorteren, implementeren in:

HTML? Nee (maar je kan er wel het resultaat mee weergeven)
CSS? Nee (maar je kan wel de opmaak van de HTML van zojuist erin specificeren)
Batch? Batch is een type verwerking, geen programmeertaal, of bedoel je MS-DOS .bat-files?
PHP? Ja
JavaScript? Ja (en dat kan je gebruiken om een webpagina toch werk te laten verrichten)
LUA? Ja
Python? Ja

Als je "ja" antwoordt is het een programmeertaal, als je "nee" antwoordt is het geen programmeertaal. MS-DOS .bat-files zijn wel een programmeertaal, maar een zo krakkemikkige dat ik me niet aan serieuze algoritmes zou wagen. Een mislukte programmeertaal, misschien.

HTML staat voor HyperText Markup Language. Een markeertaal, iets waarmee je, net als met die gekleurde stiften, markeringen mee in tekst aanbrengt. Daar is het (net als XML en SGML) voor ontworpen. De verzameling van markeringen die HTML beschikbaar stelt dient om webpagina's te structureren. Een paginabeschrijvingstaal dus. CSS dient om de opmaak van HTML-pagina's te specificeren. Hoewel je in DWDD jonge "programmeurs" steevast HTML ziet coderen zijn dat geen talen waarmee je een algoritme kan coderen, geen programmeertalen. JavaScript is dat wel.

Het onderscheid script-taal vs. programmeertaal is moeilijk te trekken en ik vind het eigenlijk niet zo zinvol. Er zijn geïnterpreteerde en semi-geïnterpreteerde talen waarmee serieuze, complexe applicaties te bouwen zijn die ook goed onderhoudbaar zijn. Ik heb zelf Python voor behoorlijk complexe zaken gebruikt, zoals beeldbewerkingssoftware. Talen die aan een command-shell gekoppeld zijn, zoals MS-DOS .bat-files en Bash, maken als "glue language" misschien nog de meeste aanspraak op de status van script-taal. JCL (Job Control Language op mainframes, dát is nou echt batchverwerking) wordt ook wel als script-taal aangemerkt, hoewel het een geval apart is.

@ Anoniem 15:29: Dank, leuke reactie.

Blij dat ik niet de enige ben ;-)
Dat is een manier van werken die voor we internettoegang hadden lang niet zo makkelijk tot veel leidde (hoewel er ook daarvoor de nodige shit werd geproduceerd). En in tijden dat alles nog wat primitiever en "dichter bij het ijzer" was was er gewoon nog geen capaciteit om abstractielagen op elkaar te stapelen voordat ze zich bewezen hadden. Maar ook in een gerenommeerd framework als .NET ben ik dingen tegengekomen die ik tenenkrommend vond, en dat is toch niet door enthousiaste amateurs in elkaar gezet maar door serieuze professionals.
Dat vergt ook een hoop ervaring én reflectie.

Wat mij betreft is het zinvoller te kijken wat je er mee doet. Een shell script om een veelvoorkomende taak te automatiseren, bijvoorbeeld. Of "glue", een klein ding om een deelprobleem op te lossen. Maar Oude Unixbaarden doen dat net zo goed in C, als ze dat toevallig beter uitkomt.

Dat kan overigens ook behoorlijk fout gaan. Zo herinner ik me een programma geschreven in clipper(!) dat je een aantal vragen stelde en dan een tekstbestandje uitpoepte -- een formulierinvuller dus -- maar als je ook maar één foutje maakte moest je het programma afschieten en kon je overnieuw beginnen. Daarnaaast was het ding plus vereiste runtimes nogal groot, het kostte behoorlijk wat binnenhaaltijd over de telefoon. Ik was dan dus ook veel beter af geweest met een voorbeeldtekstbestandje en mijn eigen editor. Maarja, ik had dus dat programma nodig om het voorbeeld te genereren. Het zei ook nogal veel over hoe de mensen die dat aanmeldformulier wilden hebben tegen de gebruikers van hun fido-stijl netwerk aankeken. In die zin een nuttige "blijf hier vooral weg!"-waarschuwing.

Aan de andere kant hebben bijvoorbeeld de *BSDs een startupsysteem compleet in shell geschreven, en een ports tree (een collectie instructies en patches om van "geporteerde applicaties" de broncode op te halen en soepeltjes te kunnen compileren en dan packages te bouwen) in het aloude make. Beiden werken prima, en zijn welbeschouwd het juiste vehikel om die problemen in op te lossen. Maar echt kleine scriptjes zijn het niet meer, nee.

Met andere woorden, hoezeer een programmeertaal een scriptingtaal genoemd wordt, is een verhaal van gradaties van geschiktheid alnaargelang de perceptie over het gebruik.

De discussie over html en css als programmeertaal is dan ook vooral een perceptieverhaal, en daarmee onderdeel van de politiek van de onderlinge sociale hierarchie. "Wij zijn wel serieuze codeklopperts, hoor". Net zo serieus als vb- en php-klopperts, zeker. Technisch gezien zijn ook vb, php, zelfs js, hele jammere taaltjes. En toch wordt er ontzettend veel in geschreven. Het is dan niet raar dat html- en css- (ondertussen ook hele jammere taaltjes) schrijvers nou ook wel eens serieus genomen willen worden.

Waarmee ze best nog een punt hebben ook, ook al zijn hun taaltjes niet Turing-compleet, want je kan eigenlijk alleen maar de gewenste uitvoer beschrijven op nogal breedsprakige wijze. O ironie.

Wat mij betreft zijn ze allemaal onderdeel van een collectief probleem zoals ook "simpele routinetaken, zoals programmeren" (die perceptie alleen al) willen out-sourcen naar India (en dan verbaasd zijn over de lage qualiteit van het werk dat terugkomt!) onderdeel is van het probleem.


Nou. Ik herinner me nog "word 6" en de wordperfect van rond die tijd. Zoveel vreselijk veel megabytes.

Ik kan de aanhaling zo snel niet vinden dus moet het maar zonder, maar, helemaal verbazend is dat niet. Vergelijk "COM" en "OLE(2)", maar ook "VB", zelfs "VBA", allemaal uit dezelfde stal. Er is vast veel te leren waarom grote projecten in grote bedrijven maar al te vaak in drijfzand verzanden. De bedrijfscultuur is daar ook een onderdeel van. Daarnaast was het ook een politiek vehikel.

Blijkbaar nog een hele discusie dus hoe dat nu met html en css zit. In ieder geval wel bedankt voor de heldere uitleg.


CSS bespaart vind ik ook gewoon een hele hoop werk. zonder CSS was het bij elke table bijvoorbeeld border="1" toevoegen, nu is het gewoon een documentje maken en het geldt meteen voor bijvoorbeeld 5 tabellen op de website.

Ach je moet toch ergens beginnen he? Zonder kenis van html kun je denk ik ook niet veel met PHP.

Met het HTML 5 kun je vind ik inmiddels wel al een stuk meer, even gelet op tags als bijvoorbeeld de progress tag, al blijft het natuurlijk wel nog steeds opmaak.

Een GUI voor een firewall is geen slecht idee. Mensen die overstappen van Windows of de syntax nog niet eigen zijn kunnen zich toch al beschermen.

Het is een ander verhaal dan niet cruciale tools. Hoewel ik in het verleden ook eens zenmap gebruikt heb en daardoor de kracht van nmap ontdekte om vervolgens alleen nog de command line te gebruiken.

Het is wel zo dat alleen bij een GUI blijven niet genoeg zal zijn om een tool of programma werkelijk te begrijpen.