[Alg] Slechtste programmeervoorbeelden deel 3

zaterdag 22 september 2007 14:20

Acties:

0 Henk 'm!

flowerp schreef op zaterdag 22 september 2007 @ 13:58:
Uhm, maar het -is- toch een slecht programmeervoorbeeld om variabelen niet te declareren en te initialiseren? Als je dat nu nog steeds doet dan heb je weinig geleerd van de 40+ jaar dat men nu al aan software development doet.

Je hoeft PHP niet goed te vinden hoor. Maar er is een doelgroep voor een dergelijke 'vergevensgezinde' taal. En ja, ik heb bijvoorbeeld ook liever duidelijke compile-time errors ipv dat het eea weggemoffeld wordt.
Als je dus in je programmeeromgeving goed op let, kan je met PHP gewoon goede software schrijven. Maar je kan inderdaad ook de kantjes eraf lopen als je dat zou willen.

Het is gewoon ronduit suf dat het in dit topic eens in de zoveel tijd over de werking van PHP moet gaan. Een aantal PHP snippets kan je wel een slecht voorbeeld noemen, maar dat maakt het nog niet echt voer voor dit topic. Met error_reporting aan wordt je gewoon gewaarschuwd voor de meeste zaken waar de maag van stricte programmeurs van gaat draaien.

{signature}

zaterdag 22 september 2007 15:53

Acties:

0 Henk 'm!

flowerp

Voutloos schreef op zaterdag 22 september 2007 @ 14:20:
[...]
Je hoeft PHP niet goed te vinden hoor. Maar er is een doelgroep voor een dergelijke 'vergevensgezinde' taal.

Ik denk dat we een beetje langs elkaar heen praten

Dat er een doelgroep voor is heb ik toch helemaal niet betwist? Net zoals er een doelgroep is voor HTML'ers die bijvoorbeeld geen <html> tag gebruiken of een <body> tag niet afsluiten etc.

Feit blijft natuurlijk dat het slechte HTML is, ondanks dat 100.000 mensen het op die manier gebruiken.

Vaak werkt het ook andersom; het feit -dat- de browser sloppy constructs toestaat motiveert mensen niet om het ooit beter te gaan doen. We weten allemaal wat voor puinhoop dat opgeleverd heeft. Ja, je kan ook voor een sloppy browser goede HTML pagina's schrijven, maar dat is niet het punt hier.

Dat er dus een groep mensen is die graag slecht wil programmeren en dat er een community is die mensen daarvoor 'vergevingsgezinde" tools aanbieden is ook een feit. De code die zij hier dan mee schrijven is dan niet automatisch goed, en blijft dus een voorbeeld van slechte code (waar dit topic over gaat).

Het niet declareren van een variabele en zeker het dan ook nog eens niet initialiseren ervan is toch een voorbeeld van slecht programmeren? Dat kun zelfs jij toch niet ontkennen?

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

zaterdag 22 september 2007 16:13

Acties:

0 Henk 'm!

ValHallASW

Het niet declareren van een variabele is zeker niet altijd een voorbeeld van slecht programmeren - waarom zou dat zo zijn?
Laat ik even refereren aan duck typing: waarom zou je willen dat iets per se een int, een double of een float is: zolang het maar optelt en vermenigvuldigt is het geen probleem

Variabelen niet initialiseren slaat sowieso nergens op. Het voordeel van variabelen niet expliciet definieren is ook dat je in geen geval in een bestaande variabele een onbekende waarde hebt staan.

offtopic:
Termen als 'Dat kun zelfs jij toch niet ontkennen?' zijn goed om een discussie mee dood te slaan, maar niet bijster constructief. Vertel liever waarom je denkt dat je gelijk hebt

zaterdag 22 september 2007 16:43

Acties:

0 Henk 'm!

flowerp

ValHallASW schreef op zaterdag 22 september 2007 @ 16:13:
Het niet declareren van een variabele is zeker niet altijd een voorbeeld van slecht programmeren - waarom zou dat zo zijn?

Ten eerste gewoon ervaring. Zowel mijn eigen als die van de industrie. Als je terug kijkt is de ontwikkeling juist andersom als wat jij nu lijkt te beweren. Typing is juist een feature die expliciet is ontwikkeld om problemen het hoofd te bieden die optraden toen er nog geen typing in talen aanwezig was. Het is niet iets wat inherent is aan computer talen en waar een oplossing voor gevonden moet worden, maar het is een oplossing voor een probleem wat optreed bij het programmeren van flinke stukken code.

Dit is een ontwikkeling geweest van velen jaren terug. Blijkbaar zijn sommige mensen die ontwikkeling vergeten of zijn ze zo jong dat ze het nooit meegemaakt hebben en hebben daarnaast ook niet de moeite genomen zich in de geschiedenis van de ontwikkeling van programmeer talen te verdiepen.

waarom zou je willen dat iets per se een int, een double of een float is: zolang het maar optelt en vermenigvuldigt is het geen probleem

Zolang je alleen die operaties doet op je variabele is het geen probleem, maar wat nu als ik opeens ergens de kleur van een int wil veranderen? ( zeg iets van foo.changeColor("blue") ). Zonder een expliciete declaratie van je type ga je hier geen (compile time) error voor krijgen.

In het bovenstaande voorbeeld wil je simpelweg declareren dat iets een -nummer- is. Dan declareer je een minder specifiek type. Dat is iets heel anders dan -geen- type declareren.

Des te groter je software wordt, des te meer garanties wil je hebben dat dingen kloppen. 1 van de uitkomsten van de grote software crisis uit de jaren 70 was dat software meer beheersbaar moest worden. Sinds die tijd is de grote en de complexiteit van software alleen maar toegenomen.

D.m.v. typing kan ik op 1 plek in mijn code een type refactoren en in alle 200.000 overige regels er zeker van zijn dat er niet stiekum iets breekt vanwege het feit dat een method niet meer bestaat in het nieuwe type. Hoe wil je dit in hemelsnaam doen zonder expliciete declaratie? Er zit niets anders op dan alle 200.000 regels handmatig door te gaan spitten, een karweitje wat niet alleen bijzonder veel tijd kost maar waar je ook nog eens bijzonder weinig garanties voor kunt geven dat het ook echt 'correct' gedaan is.

Daarnaast is het d.m.v. een declaratie veel makkelijker om aan te geven dat je een nieuwe scope begint. Zonder declaratie is het lastig en foutgevoelig om een nieuwe variabele ergens te gebruiken die dan toch niet stiekum (nu of later) betrekking heeft op een andere variable die al ergens anders gebruikt wordt. Het resultaat: je krijgt code die op 'magische' wijze elkaar beinvloed, zonder dat jij eigenlijk garanties kunt geven over dat dat niet zal gebeuren.

Het publiek wat graag sloppy programmeert denk natuurlijk amper na over dergelijke correctheid en garanties. Als er iets breekt ergens in de praktijk dan lappen ze het wel weer op, toch?

Een dergelijke houding getuigt niet echt van professionaliteit; daarom is dus het niet declareren van variabelen een bad practice of te wel een voorbeeld van slecht programmeren. Je -kunt- er mee weg komen, but it ain't pretty.

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

zaterdag 22 september 2007 18:57

Acties:

0 Henk 'm!

grooviee17

flowerp schreef op zaterdag 22 september 2007 @ 15:53:
[...]

[...]
Feit blijft natuurlijk dat het slechte HTML is, ondanks dat 100.000 mensen het op die manier gebruiken.

Vaak werkt het ook andersom; het feit -dat- de browser sloppy constructs toestaat motiveert mensen niet om het ooit beter te gaan doen. We weten allemaal wat voor puinhoop dat opgeleverd heeft. Ja, je kan ook voor een sloppy browser goede HTML pagina's schrijven, maar dat is niet het punt hier.
[...]

En als je dan alsnog aan goed HTML gaat doen, blijkt dat de browser de weergave niet doet zoals jij wilt. Die browser motiveert je dan om weer die sloppy constructs te gaan gebruiker, waar het ook niet echt beter op wordt.

zaterdag 22 september 2007 19:23

Acties:

0 Henk 'm!

Anoniem: 37526

ValHallASW schreef op zaterdag 22 september 2007 @ 16:13:
Het niet declareren van een variabele is zeker niet altijd een voorbeeld van slecht programmeren - waarom zou dat zo zijn?
Laat ik even refereren aan duck typing: waarom zou je willen dat iets per se een int, een double of een float is: zolang het maar optelt en vermenigvuldigt is het geen probleem

Variabelen niet initialiseren slaat sowieso nergens op. Het voordeel van variabelen niet expliciet definieren is ook dat je in geen geval in een bestaande variabele een onbekende waarde hebt staan.

offtopic:
Termen als 'Dat kun zelfs jij toch niet ontkennen?' zijn goed om een discussie mee dood te slaan, maar niet bijster constructief. Vertel liever waarom je denkt dat je gelijk hebt

Mag ik vragen in welke talen jij ervaring hebt? Met name in Java en C ontkom je niet aan typen variabele, al helemaal niet als je de verdere gedachtengang begrijpt. (wat een int binair doet, dat een string een char-array is).

De letter 1 bij de letter 2 optellen is anders dan het cijfer 1 bij het cijfer 2 optellen.

zaterdag 22 september 2007 21:01

Acties:

0 Henk 'm!

ValHallASW

flowerp schreef op zaterdag 22 september 2007 @ 16:43:
Als je terug kijkt is de ontwikkeling juist andersom als wat jij nu lijkt te beweren. Typing is juist een feature die expliciet is ontwikkeld om problemen het hoofd te bieden die optraden toen er nog geen typing in talen aanwezig was. Het is niet iets wat inherent is aan computer talen en waar een oplossing voor gevonden moet worden, maar het is een oplossing voor een probleem wat optreed bij het programmeren van flinke stukken code.

Ik beweer niets over de volgorde van ontwikkeling. Het lijkt me echter technisch gezien een stuk gemakkelijker om een static typed taal te maken dan een dynamically typed taal. Welke problemen er optreden noem je echter niet, en het is onzin dat het schrijven van flinke stukken code anders een probleem wordt: waarom zijn er anders grote pythonprojecten?

Dit is een ontwikkeling geweest van velen jaren terug. Blijkbaar zijn sommige mensen die ontwikkeling vergeten of zijn ze zo jong dat ze het nooit meegemaakt hebben en hebben daarnaast ook niet de moeite genomen zich in de geschiedenis van de ontwikkeling van programmeer talen te verdiepen.

Waarom zou je? Dat het vroeger 'beter' was betekent niet dat het nu nog steeds 'beter' is. De wereld verandert, en de manieren van softwareontwikkeling ook.

Zolang je alleen die operaties doet op je variabele is het geen probleem, maar wat nu als ik opeens ergens de kleur van een int wil veranderen? ( zeg iets van foo.changeColor("blue") ). Zonder een expliciete declaratie van je type ga je hier geen (compile time) error voor krijgen.

Dan krijg je een exception. Waarom zou je een compile time error willen krijgen? Het komt er tijdens je unit tests toch uitrollen, en die heb je toch echt nodig (want anders heb je misschien syntactisch wel prachtig correcte code, maar kloppen je uitkomsten niet...)

In het bovenstaande voorbeeld wil je simpelweg declareren dat iets een -nummer- is. Dan declareer je een minder specifiek type. Dat is iets heel anders dan -geen- type declareren.

Nee, je wilt dat het object kan optellen en vermenigvuldigen. Dat 'a'*10 'aaaaaaaaaa' oplevert en 10*10 100 doet er niet toe.

Des te groter je software wordt, des te meer garanties wil je hebben dat dingen kloppen. 1 van de uitkomsten van de grote software crisis uit de jaren 70 was dat software meer beheersbaar moest worden. Sinds die tijd is de grote en de complexiteit van software alleen maar toegenomen.

Je wilt garanties hebben dat *je uitkomsten* kloppen. Hoe je die krijgt is veel minder belangrijk.

Daarnaast is het d.m.v. een declaratie veel makkelijker om aan te geven dat je een nieuwe scope begint. Zonder declaratie is het lastig en foutgevoelig om een nieuwe variabele ergens te gebruiken die dan toch niet stiekum (nu of later) betrekking heeft op een andere variable die al ergens anders gebruikt wordt. Het resultaat: je krijgt code die op 'magische' wijze elkaar beinvloed, zonder dat jij eigenlijk garanties kunt geven over dat dat niet zal gebeuren.

Hoe scopes gedefinieerd zijn staat verder los van het al dan niet gebruiken van declaraties. In python lopen alle scopes van het begin van de functie naar het einde; of je een variabele nu initialiseert in een for loop of niet - en globals moet je expliciet in de functie definieren, dus je weet heel goed of je een eerdere variabele beinvloedt.

Het publiek wat graag sloppy programmeert denk natuurlijk amper na over dergelijke correctheid en garanties. Als er iets breekt ergens in de praktijk dan lappen ze het wel weer op, toch?

Een dergelijke houding getuigt niet echt van professionaliteit; daarom is dus het niet declareren van variabelen een bad practice of te wel een voorbeeld van slecht programmeren. Je -kunt- er mee weg komen, but it ain't pretty.

Omdat het niet gaat zoals jij vindt (of hebt geleerd) dat het hoort is het dus fout. Je kunt heel goed nadenken over 'dergelijke correctheid en garanties', en daaruit concluderen dat goede unit tests het doel van static typing prima over kunnen nemen.

Anoniem: 37526 schreef op zaterdag 22 september 2007 @ 19:23:
[...]

Mag ik vragen in welke talen jij ervaring hebt? Met name in Java en C ontkom je niet aan typen variabele, al helemaal niet als je de verdere gedachtengang begrijpt. (wat een int binair doet, dat een string een char-array is).

Nee, dus? Dat iets niet in Java of C mogelijk is betekent niet automatisch dat het fout is

. Ja, ik snap heel goed wat het verschil is tussen twee getallen optellen en twee strings 'optellen' (hoewel optellen daar een rare term is). Dat betekent nog niet dat je bij het schrijven van een functie hoeft te checken of het doet wat de functieschrijver verwacht: de gebruiker van de functie moet checken of de functie wel doet wat 'ie wil.

offtopic:
In welke talen ik ervaring heb is redelijk off-topic, maar een lijstje: Op het moment gebruik ik met name python, en C als time-efficiency belangrijk is. Verder LabVIEW om experimenten aan te sturen, en PHP om extensies te schrijven voor websites (drupal

, php4 booh enzo

). Java een enkele keer voor grappen als jibble, maar dat doe ik tegenwoordig ook gewoon in python. In het verleden heb ik met meerdere basicvormen en met pascal gewerkt.

Nog meer offtopic: De letter 1 bij de letter 2 optellen is helemaal niet zoveel anders dan het cijfer 1 bij het cijfer 2 optellen.. het is een off-by-96-error

offtopic:
Is het misschien een idee deze discussie af te splitsen? Het heeft weinig meer met slechte programmeervoorbeelden te maken

zaterdag 22 september 2007 22:20

Acties:

0 Henk 'm!

flowerp

ValHallASW schreef op zaterdag 22 september 2007 @ 21:01:
[...]
Ik beweer niets over de volgorde van ontwikkeling. Het lijkt me echter technisch gezien een stuk gemakkelijker om een static typed taal te maken dan een dynamically typed taal.

'Lijkt' jou dat, of weet je ook dat het zo is? Uiteindelijk wordt elke high-level taal naar native assembly omgezet. Zoals je (hopelijk) wel weet kent een CPU helemaal geen types zoals we die in high level talen gebruiken. Strong typing wordt grofweg geïmplementeerd via de compiler door de types van variablen te tracken in de bijbehorende symbol table en bij elke referentie hierna controles uit te voeren. Bij weak typing laat je die checks achterwegen.

Welke problemen er optreden noem je echter niet

Ik noemde ze niet nee. Ik schreef ze echter wel op.

Refactoring problemen en scoping issues waren 2 concrete gevallen die ik noemde.

en het is onzin dat het schrijven van flinke stukken code anders een probleem wordt: waarom zijn er anders grote pythonprojecten?

En wie zegt dat er in die projecten niet overdreven veel maintenance overhead is?

Je kunt het ook andersom stellen; waarom zijn er zoveel grote projecten in strong typed languages geschreven? Waarom zijn de meeste grote systemen die we kennen (zoals operating systems of databases) in strong typed talen geschreven? Ik noem een Windows, Mac OS X, Linux een PostgreSQL, etc. Waarom zijn vrijwel alle backends van grote financiele en transactie systemen in strong typed talen geschreven (denk aan banking of de software die voor lunchthavens gebruikt wordt).

Waarom zou je? Dat het vroeger 'beter' was betekent niet dat het nu nog steeds 'beter' is. De wereld verandert, en de manieren van softwareontwikkeling ook.

-zucht- Je snapt het niet. Er zijn vroeger fouten gemaakt, gewoon omdat men nog niet ervaren was met software ontwikkeling. Men leerde en kwam met oplossingen. Nu komt men echter met een zogenaamd 'moderne' taal en maakt doodleuk exact de zelfde fout overnieuw.

Dat is geen ontwikkeling of verandering en heeft al helemaal niets met het feit te maken dat het vroeger beter zou zijn. Dat is simpelweg een kwestie van fouten die in het verleden gemaakt zijn overnieuw maken. Zoek eens voor de grap op hoe het oer-Basic in elkaar zat en van welk jaar dat precies was

Dan krijg je een exception. Waarom zou je een compile time error willen krijgen?

Als je er zo over denkt dan denk ik dat verdere discussie met jou niet zo zinvol is. Jij leeft klaarblijkelijk in zo'n totaal andere wereld als je je dit soort dingen moet gaan afvragen...

Maar goed, je wilt zo veel mogelijk compile time errors kunnen krijgen omdat een compiler ELK onderdeel van je applicatie doorloopt. ELKE regel en ELKE case komt er langs. Je weet dus voor 100% dat een stuk code die door een compiler heen gegaan is volledig voldoet aan de constraints die gelden voor een taal. Dit geeft je een grote zekerheid over je code en zorgt ervoor dat een gehele klasse van bugs simpelweg niet kan bestaan. Het laatste wat je natuurlijk wilt is dat er pas een exception komt tijdens runtime.

Het komt er tijdens je unit tests toch uitrollen, en die heb je toch echt nodig (want anders heb je misschien syntactisch wel prachtig correcte code, maar kloppen je uitkomsten niet...)

Een unit test bevind zich op een geheel ander niveau dan de statische testen die een compiler uitvoert. Een serie unit testen voert slechts een steek proef uit op je code. Het is voor serieuze software development zeker een onmisbare tool maar geen vervanger voor een compiler die immers de testen die het kan doen volledig uit voert op elke regel van je code.

Een unit test geeft dus ook nooit een uitsluitende garantie. Als lead developer van een team weet ik nooit of mijn developers hun code 100% gecovered hebben door unit testen. Er zijn weliswaar weer aparte andere tools die iets kunnen zeggen over de coverage, maar dan nog weet je niet of elk mogelijk path is doorlopen. Geen enkele tool -kan- dit ook zeggen (dit probleem is in essentie terug te voeren op het halting probleem). Een compiler daarentegen is niet afhankelijk van code paths maar controleert type correctness simpelweg op syntax basis.

Je wilt garanties hebben dat *je uitkomsten* kloppen. Hoe je die krijgt is veel minder belangrijk.

Hoe je die krijgt is wel degelijk belangrijk. Ga jij meer eens in 200.000 regels die nu een correcte uitkomst heeft iets veranderen. De kunst is om te kunnen blijven garanderen dat de uitkomst in alle gevallen correct blijft.

Naast de uitkomst is de mogelijkheid om überhaupt veranderingen te kunnen maken essentieel. De software crisis ging er juist over dat de complexiteit van grote systemen hand over kop toe nam en dan mensen het niet meer konden bevatten. Daarom zijn er juist diverse constructies ontwikkeld in de loop der jaren om de complexiteit te beteugelen; functies (procedures), types, classes, name spaces, etc.

Nu kun jij wel heel leuk denken dat dat allemaal ingewikkelde dingen zijn die je wel kan weglaten "omdat de tijden veranderen", maar dan ga je er volledig aan voorbij waarom we die dingen in de eerste instantie zijn gaan gebruiken. Net zoals types is iets als een class of een namespace niet iets dat native is aan een computer zoals we die nu kennen (b.v. de traditionele von neuman architecturen).

Voor hele kleine stukjes software kun er mee wegkomen om die elementen niet te gebruiken; zoals ik al zei, ze zijn namelijk ooit in het leven geroepen om juist grote stukken software te kunnen ontwikkelen. Mensen die dan toch ijskoud grote stukken software gaan ontwikkelen in talen die dergelijke essentiële kenmerken missen zijn toch echt verkeerd bezig en herhalen simpelweg de fouten uit het verleden.

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

zaterdag 22 september 2007 22:40

Acties:

0 Henk 'm!

wboevink

flowerp schreef op zaterdag 22 september 2007 @ 22:20:
[...]

Ik ben het helemaal met je eens, maar je zou wel iets meer respect mogen hebben voor je 'mindere' medemens.

zaterdag 22 september 2007 23:02

Acties:

0 Henk 'm!

Glimi

Designer Drugs

flowerp schreef op zaterdag 22 september 2007 @ 22:20:
'Lijkt' jou dat, of weet je ook dat het zo is?
Uiteindelijk wordt elke high-level taal naar native assembly omgezet. Zoals je (hopelijk) wel weet kent een CPU helemaal geen types zoals we die in high level talen gebruiken. Strong typing wordt grofweg geïmplementeerd via de compiler door de types van variablen te tracken in de bijbehorende symbol table en bij elke referentie hierna controles uit te voeren. Bij weak typing laat je die checks achterwegen.

Je bedoelt hier het verschil tussen static typing en dynamic typing neem ik aan? Static type checking is opzich niet heel lastig. Je begint bij de variabelen en dmv signatures doe je gewoon checks. Niets lastigs aan, gewoon een kwestie van een environment door je AST heen slepen en checks uitvoeren. Bij overloaded functies is het een kwesite van de juiste opzoeken dmv de bekende types.
Dynamic type checking is al niet veel lastiger. Je houdt de environment dan gewoon @ runtime bij en checkt voor het invoken van een functie wat de types zijn, en doet dezelfde check @ runtime.

Type inferring daar en tegen, dat is een stuk lastiger te implementeren. Dan is het niet een kwestie van types checken, maar types inducen nav wat er bekend is in je environment. Maar ook daar is voldoende over onderzocht en theoretisch bekend, dus echt vreselijk lastig kan je dat ook niet noemen (of je moet exotisch gaan worden en los gaan met higher rankedness, functional dependencies etc)

zaterdag 22 september 2007 23:23

Acties:

0 Henk 'm!

flowerp

Glimi schreef op zaterdag 22 september 2007 @ 23:02:
[...]
Je bedoelt hier het verschil tussen static typing en dynamic typing neem ik aan?

Inderdaad, hoewel een subtiel verschil is dat static typing eigenlijk een sub classe van strong typing zou zijn. In de praktijk worden deze termen nogal eens misbruikt; voorstanders geven de voorkeur aan strong typing vs weak typing (strong klinkt immers beter dan weak), terwijl het bij static typing vs dynamic typing juist andersom is (dynamic klinkt natuurlijk veel hipper en moderner dan static).

Static type checking is opzich niet heel lastig. Je begint bij de variabelen en dmv signatures doe je gewoon checks. Niets lastigs aan, gewoon een kwestie van een environment door je AST heen slepen en checks uitvoeren.

Het werd natuurlijk een stuk makkelijker toen we compiler-generators kregen

Daarvoor was het iets lastiger. ValHallASW deed het echter voorkomen alsof weak typing een nieuwe recente ontwikkeling is die het 'oude stoffige' strong typing tegenwoordig overbodig zou hebben gemaakt. De waarheid is natuurlijk verre van dat. Geïnterpreteerde, weak-typed talen bestaan al bijna net zo lang als de pure machine talen. Een compiler van scratch bouwen is zonder compiler-generator technologie wel degelijk complexer dan een simpele interpreter bouwen. (ik heb trouwens beide dingen wel eens gedaan; een pascal compiler geschreven m.b.v. bison/flex en een pure interpreter voor een eigen taaltje).

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

zaterdag 22 september 2007 23:54

Acties:

0 Henk 'm!

ValHallASW

flowerp schreef op zaterdag 22 september 2007 @ 22:20:
'Lijkt' jou dat, of weet je ook dat het zo is? Uiteindelijk wordt elke high-level taal naar native assembly omgezet. Zoals je (hopelijk) wel weet kent een CPU helemaal geen types zoals we die in high level talen gebruiken.

Klopt. Om correcte assembly te krijgen heb je informatie nodig over het type van de inhoud van je variabele. Een statisch type toekennen is makkelijker dan het dynamisch toewijzen.

Strong typing wordt grofweg geïmplementeerd via de compiler door de types van variablen te tracken in de bijbehorende symbol table en bij elke referentie hierna controles uit te voeren. Bij weak typing laat je die checks achterwegen.

Ik heb het gevoel dat we hier langs elkaar heen praten, zeker ook aangezien je de behoorlijk ambigue term 'strong typing' gebruikt. Python heeft 'strong, dynamic typing': nee, je kunt geen integervermenigvuldiging uitvoeren tussen een int en een string. Je kunt wél definieren wat die vermenigvuldiging betekent. Ik kom hier aan het eind van mn post nog op terug.

En wie zegt dat er in die projecten niet overdreven veel maintenance overhead is?

Je kunt het ook andersom stellen; waarom zijn er zoveel grote projecten in strong typed languages geschreven? Waarom zijn de meeste grote systemen die we kennen (zoals operating systems of databases) in strong typed talen geschreven? Ik noem een Windows, Mac OS X, Linux een PostgreSQL, etc. Waarom zijn vrijwel alle backends van grote financiele en transactie systemen in strong typed talen geschreven (denk aan banking of de software die voor lunchthavens gebruikt wordt).

Daar zijn een aantal redenen voor. Snelheid is bij een OS en een database een pre, en daar is python dan ook niet geschikt voor. De backends van de grote financiele systemen zijn in het algemeen al behoorlijk oud; bovendien is snelheid daar ook een belangrijk punt.
Om even een paar tegenvoorbeelden te geven: Mailman, cia.vc en django; Google gebruikt het veel, het wordt gebruikt binnen BF2 en civ4...
Sterker nog: omdat python veel leesbaardere code geeft weet ik eigenlijk niet waar meer maintenance overhead is

-zucht- Je snapt het niet. Er zijn vroeger fouten gemaakt, gewoon omdat men nog niet ervaren was met software ontwikkeling. Men leerde en kwam met oplossingen. Nu komt men echter met een zogenaamd 'moderne' taal en maakt doodleuk exact de zelfde fout overnieuw.

Dat is geen ontwikkeling of verandering en heeft al helemaal niets met het feit te maken dat het vroeger beter zou zijn. Dat is simpelweg een kwestie van fouten die in het verleden gemaakt zijn overnieuw maken. Zoek eens voor de grap op hoe het oer-Basic in elkaar zat en van welk jaar dat precies was

Nee, het is nadenken over wat er 'volgens het boekje' fout is, daar over nadenken en dan bepalen wat je doet.

Je wilt zo veel mogelijk compile time errors kunnen krijgen omdat een compiler ELK onderdeel van je applicatie doorloopt. ELKE regel en ELKE case komt er langs. Je weet dus voor 100% dat een stuk code die door een compiler heen gegaan is volledig voldoet aan de constraints die gelden voor een taal. Dit geeft je een grote zekerheid over je code en zorgt ervoor dat een gehele klasse van bugs simpelweg niet kan bestaan. Het laatste wat je natuurlijk wilt is dat er pas een exception komt tijdens runtime.

Daarom maak je unit tests die ELKE regel en ELKE case beschrijven. Da's nou net de hele grap: je gaat op functieniveau checken of elke functie wel precies doet wat je wilt. Door daarbij alle randgevallen te benaderen weet je niet alleen dat het goede *type* object terugkomt, maar dat het *goede object* terugkomt. Het enige wat static typing toevoegt is een automatische check of je wel braaf een int in een int zet... alsof je daarmee al je bugs opeens te pakken hebt. Overigens is pychecker behoorlijk vaardig in het nalopen van types in deze dynamically typed omgeving.

Een unit test bevind zich op een geheel ander niveau dan de statische testen die een compiler uitvoert. Een serie unit testen voert slechts een steek proef uit op je code. Het is voor serieuze software development zeker een onmisbare tool maar geen vervanger voor een compiler die immers de testen die het kan doen volledig uit voert op elke regel van je code. Een unit test geeft dus ook nooit een uitsluitende garantie.

Daar zit dus de truc van het maken van goede unit tests. Na je compile run weet je misschien dat in alle gevallen een correct type wordt teruggegeven, maar dat is al helemaal geen uitsluitende garantie: je hebt nog steeds geen flauw idee of je in alle gevallen de goede return value terug krijgt.

Hoe je die krijgt is wel degelijk belangrijk. Ga jij meer eens in 200.000 regels die nu een correcte uitkomst heeft iets veranderen. De kunst is om te kunnen blijven garanderen dat de uitkomst in alle gevallen correct blijft.

Okay, dat was slecht geformuleerd. Je schrijft een functie (programma) altijd met twee doelen in oog: leesbaarheid en correctheid. Het probleem is echter dat je die uitkomst niet kan garanderen met compile-time checks, maar wel met unit tests.

Naast de uitkomst is de mogelijkheid om überhaupt veranderingen te kunnen maken essentieel. De software crisis ging er juist over dat de complexiteit van grote systemen hand over kop toe nam en dan mensen het niet meer konden bevatten. Daarom zijn er juist diverse constructies ontwikkeld in de loop der jaren om de complexiteit te beteugelen; functies (procedures), types, classes, name spaces, etc.

Ik heb het ook niet over het afschaffen van functies, types, klasses en weet ik niet wat. Ik geef alleen aan dat het afdwingen van types vaak niet zinvol is.

Mensen die dan toch ijskoud grote stukken software gaan ontwikkelen in talen die dergelijke essentiële kenmerken missen zijn toch echt verkeerd bezig en herhalen simpelweg de fouten uit het verleden.

Uit deze quote kan ik alleen maar concluderen dat je python alleen 'van horen zeggen' kent en dat je niet even vijf minuten de moeite hebt genomen om je in te lezen. Nogmaals: ik promoot geen talen die dat soort structuren niet ondersteunen - ik geef alleen aan dat het lang niet altijd zinvol is dingen rigide af te dwingen.

Inderdaad, hoewel een subtiel verschil is dat static typing eigenlijk een sub classe van strong typing zou zijn

Nee. Static typing betekent dat een variabele een vast type heeft (itt dynamic typing waarbij een variabele een ander type kan krijgen). Strong typing betekent dat je geen stringfuncties op een int kan uitvoeren (str.strip(1) gaat niet werken in python), terwijl weak typing betekent dat er daarbij impliciete conversies plaats kunnen vinden (of dat er in het geheel geen typeinformatie aanwezig is)

ValHallASW deed het echter voorkomen alsof weak typing een nieuwe recente ontwikkeling is die het 'oude stoffige' strong typing tegenwoordig overbodig zou hebben gemaakt. De waarheid is natuurlijk verre van dat.

Tsja, volgens mij praten we weer langs elkaar heen met die termen. Strong typing is een noodzaak, maar het afdwingen van types niet

Een compiler van scratch bouwen is zonder compiler-generator technologie wel degelijk complexer dan een simpele interpreter bouwen.

mediawiki wikitext

(daar moet je dus wél met de hand een compiler bouwen aangezien de huidige parser geschreven is door iemand die ooit gehoord had dat regexps wel gaaf waren)

Lees je alsjeblieft even in over python en over de typing keuzes die daar zijn gemaakt, misschien dat je mijn punt dan wel snapt. Als je dan in je volgende volgende post ook nog aangeeft wat *jij* bedoelt met strong/weak en static/dynamic typing dan maak je me helemaal blij.

zondag 23 september 2007 00:08

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

flowerp schreef op zaterdag 22 september 2007 @ 15:53:
[...]

Ik denk dat we een beetje langs elkaar heen praten Dat er een doelgroep voor is heb ik toch helemaal niet betwist? Net zoals er een doelgroep is voor HTML'ers die bijvoorbeeld geen <html> tag gebruiken of een <body> tag niet afsluiten etc.

Feit blijft natuurlijk dat het slechte HTML is, ondanks dat 100.000 mensen het op die manier gebruiken.

*kuch* Zowel de start-tag als de end-tag voor o.a. HTML en BODY zijn optioneel in HTML

Vaak werkt het ook andersom; het feit -dat- de browser sloppy constructs toestaat motiveert mensen niet om het ooit beter te gaan doen. We weten allemaal wat voor puinhoop dat opgeleverd heeft. Ja, je kan ook voor een sloppy browser goede HTML pagina's schrijven, maar dat is niet het punt hier.

De vergelijking van een opmaaktaal met een programmeertaal gaat natuurlijk sowieso mank; een opmaaktaal dient een heel ander doel en HTML is ontwikkeld vanuit de gedachte dat het voor een zo breed mogelijk (authoring)publiek toegankelijk dient te zijn. Daar past dus een vergevingsgezinde manier van verwerken bij.

Sterker nog: je ziet o.a. ook dat bijvoorbeeld RSS readers (RSS is een XML-application!) steeds vergevingsgezinder omgaan met mallformed RSS. Waarom? Omdat Jan met de pet die een RSS feedje klust niet snapt wat een parse error is, en Miep op de hoek wel Jan's feed wil lezen.

Het grootste manko op dit moment met HTML (en ook RSS) is dat de errorhandling zelf ongedefinieerd is wat een interoperability probleem oplevert.

Feit is wel dat 'vergevingsgezinde' tools* gewoon een betere kans maken in de markt. Als ik morgen een browser op de markt zet die enkel sites kan tonen die volledig valide (X)HTML zijn, zal ik daar dan ooit een substantieel marktaandeel mee verwerven?

*note dat ik het specifiek heb over opmaaktalen, niet over programmeertalen en dus niet wil zeggen dat bijvoorbeeld compilers ook maar vergevend moeten zijn

Ik denk overigens ook niet dat je bij programmeertalen over 'vergevend' moet spreken als je 'weak-typed' bedoelt.

[ Voor 6% gewijzigd door crisp op 23-09-2007 00:12 ]

Intentionally left blank

zondag 23 september 2007 01:20

Acties:

0 Henk 'm!

flowerp

ValHallASW schreef op zaterdag 22 september 2007 @ 23:54:
Daar zijn een aantal redenen voor. Snelheid is bij een OS en een database een pre

Snelheid is een pre, maar geen vereiste. Correctheid en integriteit van je data is veel belangrijker. Als performance alles was dan zou als een vervanging voor een DB in veel gevallen iets banaals als een grote hashmap oid veel sneller zijn. Een DB is echter veel meer dan een snelle methode om data op te halen (voor een simpele select zal een DB dan ook altijd langzamer zijn).

Databases en operating systems zijn dus niet in strong typed talen geschreven alleen en enkel vanwege de performance, maar ook vanwege de beheersbaarheid van de source code. Niet alles is natuurlijk zwart/wit. C kent veel loopholes in het type system maar wordt toch uitsluitend gebruikt voor de linux kernel. De rest van de lagen in een typisch OS worden dan meer in het sterkere (qua typing) C++ geschreven.

De backends van de grote financiele systemen zijn in het algemeen al behoorlijk oud; bovendien is snelheid daar ook een belangrijk punt.

Af en toe zijn die behoorlijk oud, maar veel van dergelijke systemen die nu of in de afgelopen jaren zijn gebouwd maken overwegend gebruik van .NET en Java (EE). Een verondersteld populaire 'dynamically-typed' taal als PHP zie je daar bijna niet terug.

Nee, het is nadenken over wat er 'volgens het boekje' fout is, daar over nadenken en dan bepalen wat je doet.

Het is een combinatie van beiden. Je eigen (jarenlange) ervaring met hetgeen er in boeken staat geschreven. In al die jaren dat ik nu software ontwikkel (en dan is vrij lang, ik begon al op m'n 6de met rommelen in basic op de c64) hebben types me altijd geholpen. In talen waar types ontbraken heeft het me altijd tegengewerkt. Daarbij is het zeker geen geval van het geen aanhangen wat je gewent bent. Ik groeide op met Basic (slecht begin eigenlijk), ging daarna over op assembly (een natuurlijk groei pad destijds) en kwam pas op latere leeftijd echt in aanraking met types.

Daarom maak je unit tests die ELKE regel en ELKE case beschrijven. Da's nou net de hele grap: je gaat op functieniveau checken of elke functie wel precies doet wat je wilt.

Dat is een illusie. Je kunt niet bewijzen dat een programma een ander programma uitputtend kan testen. Met uitputtend bedoel ik dan elke mogelijke case. Dit is een onmogelijkheid. Ik zal beloven dat ik me eens inlees over python, maar lees jij je dan eens in op het onderwerp theoretische informatica en dan met name turing machines en het halting probleem. Lees je daarnaast ook eens in over het onderwerp formal correctness proofs. Uit jouw comment kan ik weer opmaken dat je daar misschien wel eens iets over gehoord hebt, maar dat je nog nooit echt een stukje code formeel hebt moeten bewijzen.

Ik kan je alvast verklappen dat een unit test -geen- vervanging is voor een formeel bewijs van de correctheid (wat je hier lijkt te impliceren). De checks die een compiler uitvoert zijn dat overigens (natuurlijk) ook niet, maar zijn -wel- volledig in het geen er gecheckt wordt.

Daar zit dus de truc van het maken van goede unit tests. Na je compile run weet je misschien dat in alle gevallen een correct type wordt teruggegeven, maar dat is al helemaal geen uitsluitende garantie: je hebt nog steeds geen flauw idee of je in alle gevallen de goede return value terug krijgt.

Je maakt hierbij de denk fout dat het een de ander uitsluit. Dat is echter onzin. In een gecompileerde taal met type checking waarop ik daarna mijn unit tests laat lopen heb ik -en- de garantie dat de types kloppen en ik heb een steek proef gedaan die hopelijk een goede indruk geeft over de correctheid van het functioneren. De alle gevallen die je boven noemt is echt onzin. Serieus, no offence, maar als je denkt dat unit testen je die garantie geven moet je echt eens je iets meer in het onderwerp gaan verdiepen.

Het probleem is echter dat je die uitkomst niet kan garanderen met compile-time checks, maar wel met unit tests.

Maar lieve schat, ik heb het toch ook nooit gehad over de uitkomst? Compile-time checks vangen een bepaalde classe van bugs af, zoals ik al eerder zei:

flowerp schreef op zaterdag 22 september 2007 @ 22:20:
Je weet dus voor 100% dat een stuk code die door een compiler heen gegaan is volledig voldoet aan de constraints die gelden voor een taal. Dit geeft je een grote zekerheid over je code en zorgt ervoor dat een gehele klasse van bugs simpelweg niet kan bestaan.

Net zoals b.v. een garbage collector niet -alle- memory leaks voor je oplost (maar alleen de sub classe van leaks veroorzaakt door unreferenced objecten) zo vangt een compiler niet alle errors voor je af maar alleen die veroorzaakt door verkeerde typing. Dat is zeker geen onbelangrijke klasse (verre van dat) en een aantal (script) talen laten deze mogelijkheid leggen.

Ik heb het ook niet over het afschaffen van functies, types, klasses en weet ik niet wat. Ik geef alleen aan dat het afdwingen van types vaak niet zinvol is.

Ik denk eerder dat het andersom is. In verreweg de meeste gevallen is het gewoon duidelijker als je als programmeur aangeeft met welk type je te maken hebt. Dat geeft niet alleen de mogelijkheid tot een betere type checking, maar is ook gewoon duidelijker voor de programmeur die de code moet lezen.

Bij talen die types 'afdwingen' zijn er altijd wel wegen om het type systeem heen als je echt vindt dat dat nodig is. In Java kun je alles als Object declareren en dan later casten naar iets wanneer je er een operatie op wilt oproepen. 1 stapje verder is dan nog het type systeem helemaal links laten leggen en operaties op een object aanroepen d.m.v. naamgeving (via reflection). Dit zijn echter expliciete mogelijkheden voor special cases die gebruikt kunnen worden door mensen die (hopelijk) precies weten wat ze aan het doen zijn.

De default is echter gewoon dat types gebruikt worden. In het overgrote gedeelte van de business code wil je dat ook gewoon. Via (abstracte) base types en interfaces kun je nog steeds heel flexibel opereren zonder aan explicietheid in te boeten. Voor hele funky dynamische stukjes code kan het wel eens aardig zijn dat types 'opeens' kunnen wisselen al gelang naar het gebruik. Een professionele programmeur zal daar zeker bepaalde algoritmes elegant mee kunnen uitdrukken. Voor de meerderheid van de mensen is het echter een manier om gewoon sloppy te zijn en zit er helemaal geen verhelderende gedachte achter. "Niet denken, niet beredeneren, maar gewoon proggen!" Je kent het soort types (no pun intended) vast wel.

Nee. Static typing betekent dat een variabele een vast type heeft (itt dynamic typing waarbij een variabele een ander type kan krijgen). Strong typing betekent dat je geen stringfuncties op een int kan uitvoeren (str.strip(1) gaat niet werken in python),

Ik zei dat Static typing in feite een sub classe van Strong typing is omdat dat 1 van de manieren is om Strong typing te bereiken. Dit om type safeness te kunnen garanderen @ compile time. Static typing is niets meer of minder dat je het type aangeeft. b.v.

Java:

1 2	String foo = "foo"; // static typing, we actually declare foo as a String foo.myFunction(); // Type safeness; compiler rejects this; Strongly typed semantics

Daarbij zijn we door polymorphisme natuurlijk niet gebonden aan alleen dat ene type:

Java:

List<Integer> list  = new ArrayList<Integer>():
list.add(1);
list = new LinkedList<Integer>();
list.add(2);

Ook kan simpele type inference voorkomen, zoals in C++0x of wellicht in Java 7:

Java:

1 2	var list = new ArrayList<Integer>(): // "var" referers to an ArrayList<Integer> now, not to a dynamic type. list.myFunction(); // still strong typing; rejected by compiler

Een belangrijk punt is natuurlijk dat de termen nergens super eenduidig gedefinieerd zijn (zoals meerdere dingen in CS, neem bv termen als "module", "component", "procedure", "functie", etc). De eigenschap die we echter allemaal willen (of allemaal zouden moeten willen) is dat voor dat we een programma draaien we een lijst van alle fouten krijgen te zien.

Voor weakly typed talen (of weakly typed elementen in talen) is dat minder goed mogelijk dan in strongly typed talen.

Ik zal binnenkort eens wat meer gaan lezen over Python, het is nu net even te laat daarvoor

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

zondag 23 september 2007 11:14

Acties:

0 Henk 'm!

Voutloos

flowerp schreef op zaterdag 22 september 2007 @ 15:53:
Het niet declareren van een variabele en zeker het dan ook nog eens niet initialiseren ervan is toch een voorbeeld van slecht programmeren? Dat kun zelfs jij toch niet ontkennen?

Hoezo 'zelfs jij'? Ik ben misschien een 24-jarig broekie, maar ik weet wel wat alle termen die je aanhaalt inhouden (inc. de theoretische informatica kant). Ik heb dan ook eerlijk gezegd helemaal niets aan jouw manier van discussiëren (== jij probeert college te geven).

Binnen PHP kan je gewoon prima weten hoe je nieuwe variabele automagisch geïnitialiseerd wordt, dus zelfs met enige zaken welke een E_NOTICE opleveren kan je netjes programmeren. Overigens moet ik je wel deels gelijk geven dat PHP oude fouten opnieuw maakt, maar het is niet zo dat het hele weakly typed gebeuren 1 grote oude fout is.

{signature}

zondag 23 september 2007 13:37

Acties:

0 Henk 'm!

JeromeB

woei

flowerp schreef op zaterdag 22 september 2007 @ 15:53:
[...]

Ik denk dat we een beetje langs elkaar heen praten Dat er een doelgroep voor is heb ik toch helemaal niet betwist? Net zoals er een doelgroep is voor HTML'ers die bijvoorbeeld geen <html> tag gebruiken of een <body> tag niet afsluiten etc.

Feit blijft natuurlijk dat het slechte HTML is, ondanks dat 100.000 mensen het op die manier gebruiken.

Onzin, bepaalde HTML-tags zijn gewoon optional en met de juiste kennis is het prima om die tags gewoon weg te laten. Dat is niet 'slecht' en het is ook geen bad practice, het is eerder een kwestie van smaak. Verder is dit natuurlijk niet relevant voor de rest van de discussie, maar ik moest dit gewoon even kwijt.

edit: ah, ik had de reactie van crisp al over het hoofd gezien

[ Voor 4% gewijzigd door JeromeB op 23-09-2007 13:39 ]

PC load letter? What the fuck does that mean?

zondag 23 september 2007 13:46

Acties:

0 Henk 'm!

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

Modbreak:Kunnen we weer on-topic?

Als iemand een vreselijke behoefte heeft om dit onderwerp nog verder uit te diepen dan nodig ik diegene van harte uit om een nieuw topic hierover te openen.

[ Voor 64% gewijzigd door RobIII op 23-09-2007 13:47 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

zondag 23 september 2007 14:13

Acties:

0 Henk 'm!

Robtimus

me Robtimus no like you

ValHallASW schreef op zaterdag 22 september 2007 @ 13:11:
In python hoef je ook niet te declareren

Dat doet me denken aan een fout die ik een paar jaar geleden maakte.

Ik weet het niet meer exact, maar het was iets als het volgende:

Python:

1
2
3

def do_something(socket, ....): # socket is een server socket
    # aardig wat regels code
    socket = socket.socket(....) # maak een nieuwe client socket aan ergens naartoe

En ik me maar afvragen waarom mijn server socket afgesloten werd...
Op dat moment had een verplichte declaratie me kunnen waarschuwen.

More than meets the eye
There is no I in TEAM... but there is ME
system specs

zondag 23 september 2007 14:33

Acties:

0 Henk 'm!

flowerp

JeromeB schreef op zondag 23 september 2007 @ 13:37:
[...]
Onzin, bepaalde HTML-tags zijn gewoon optional en met de juiste kennis is het prima om die tags gewoon weg te laten.

pffff, ik bedoelde natuurlijk een document zoals de volgende:

HTML:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<head><title>test</title></head>
<body>
test
</html>

Dus een html tag wel afsluiten terwijl je hem niet geopend hebt of een body wel openen maar niet afsluiten. Natuurlijk was het slechts een snel voorbeeld; de achterliggende gedachte was dat je *foute* HTML schrijft die door de vergevingsgezindheid van de browser geaccepteerd wordt.

Het nadeel is dan dat de interpretatie van foute HTML bij een specifieke browser ligt. Als de rendering bij elke mogelijke fout gedefinieerd zou zijn, dan zou die manier van HTML schrijven gewoon onderdeel van de spec zijn. Het gevolg is dus dat elke browser foute html potentieel anders weergeeft.

(ps voor mensen die denken dat bovenstaande document toegestaan is; dit zegt de w3 validator erover:

# Error Line 4, Column 0: character data is not allowed here.

test

✉

You have used character data somewhere it is not permitted to appear. Mistakes that can cause this error include:

* putting text directly in the body of the document without wrapping it in a container element (such as a <p>aragraph</p>), or
* forgetting to quote an attribute value (where characters such as "%" and "/" are common, but cannot appear without surrounding quotes), or
* using XHTML-style self-closing tags (such as <meta ... />) in HTML 4.01 or earlier. To fix, remove the extra slash ('/') character. For more information about the reasons for this, see Empty elements in SGML, HTML, XML, and XHTML.

# Error Line 5, Column 6: "BODY" not finished but containing element ended.

</html>

)

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

zondag 23 september 2007 15:34

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

flowerp schreef op zondag 23 september 2007 @ 14:33:
[...]

pffff, ik bedoelde natuurlijk een document zoals de volgende:
HTML:
1
2
3
4
5
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<head><title>test</title></head>
<body>
test
</html>
Dus een html tag wel afsluiten terwijl je hem niet geopend hebt of een body wel openen maar niet afsluiten. Natuurlijk was het slechts een snel voorbeeld; de achterliggende gedachte was dat je *foute* HTML schrijft die door de vergevingsgezindheid van de browser geaccepteerd wordt.

Dat is nog steeds geen 'foute' HTML (zie onder)

Het nadeel is dan dat de interpretatie van foute HTML bij een specifieke browser ligt. Als de rendering bij elke mogelijke fout gedefinieerd zou zijn, dan zou die manier van HTML schrijven gewoon onderdeel van de spec zijn. Het gevolg is dus dat elke browser foute html potentieel anders weergeeft.

Dat is een probleem dat al onderkent is en dat HTML5 tracht op te lossen door error-correctie te specificeren. Op dit moment reverse-engineeren de meeste browsers IE's behaviour, behalve op punten waar dat absoluut niet wenselijk is of tegen de standaarden ingaat. En ja, zoals gezegd is dat een interoperability probleem.

(ps voor mensen die denken dat bovenstaande document toegestaan is; dit zegt de w3 validator erover:

[...]

Die foutmelding slaat niet op het feit dat je geen expliciete close-tag voor BODY gebruikt of geen expliciete open-tag voor HTML, het slaat op het feit dat onder een strict DTD BODY zelf geen inline content mag bevatten. Dit is wel valid:

HTML:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<head><title>test</title></head>
<body>
<p>test
</html>

Enigszins weer ontopic: markup heeft niets met programmeren te maken, vergelijkingen met een markup taal gaan dus gewoon altijd mank (en er is weer geillustreerd waarom programmeurs zich met programmeren zouden moeten bezighouden en niet met markup

)

[ Voor 6% gewijzigd door crisp op 23-09-2007 15:37 ]

Intentionally left blank

zondag 23 september 2007 15:53

Acties:

0 Henk 'm!

flowerp

crisp schreef op zondag 23 september 2007 @ 15:34:
(en er is weer geillustreerd waarom programmeurs zich met programmeren zouden moeten bezighouden en niet met markup )

Het wil maar niet lukken met mijn 'foute' HTML voorbeeld

I stand corrected

Ik denk overigens dat het meer te maken heeft met het feit dat ik simpelweg de formele taal definitie van HTML niet (goed genoeg) bestudeerd heb. In wezen is HTML natuurlijk net zo goed een taal met een duidelijk gespecificeerde grammatica. Dat de taal gebruikt wordt om layouts te maken van text en user interface elementen in een browser doet daar eigenlijk niet zo veel aan af. Informatici in het algemeen moeten wel zeer zeker de syntax beschrijving van diverse formele talen kunnen lezen

Blijft natuurlijk nog steeds het punt dat de HTML die ik opschreef wel degelijk fout was (maar dus niet om de reden die ik noemde) en wel degelijk zonder morren door alle browsers werd gerenderd.

offtopic:
Dat een tag afsluiten zonder hem te openen als valide binnen de taal wordt beschouwt vind ik eigenlijk wel een redelijk ranzig iets, maar dat is waarschijnlijk alleen mijn mening.

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

zondag 23 september 2007 21:50

Acties:

0 Henk 'm!

JeromeB

woei

flowerp schreef op zondag 23 september 2007 @ 15:53:
[...]

offtopic:
Dat een tag afsluiten zonder hem te openen als valide binnen de taal wordt beschouwt vind ik eigenlijk wel een redelijk ranzig iets, maar dat is waarschijnlijk alleen mijn mening.

offtopic:
Wat je zegt klopt inprincipe niet. <html> en </html> zijn twee aparte tags.
HTML maakt onderscheidt tussen elementen en tags.

PC load letter? What the fuck does that mean?

zondag 23 september 2007 22:32

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

flowerp schreef op zondag 23 september 2007 @ 15:53:
[...]

Ik denk overigens dat het meer te maken heeft met het feit dat ik simpelweg de formele taal definitie van HTML niet (goed genoeg) bestudeerd heb. In wezen is HTML natuurlijk net zo goed een taal met een duidelijk gespecificeerde grammatica.

True, HTML is wat dat betreft inderdaad een taal. HTML is overigens een SGML applicatie (en XHTML een XML applicatie), HTML5 daarentegen definieert z'n eigen syntax.

Dat de taal gebruikt wordt om layouts te maken van text en user interface elementen in een browser doet daar eigenlijk niet zo veel aan af.

Correctie: voor layout hebben we CSS

Informatici in het algemeen moeten wel zeer zeker de syntax beschrijving van diverse formele talen kunnen lezen

Jep, in het geval van HTML zou je dus de DTD als beschrijving kunnen nemen, daarin wordt ook vermeld welke elementen in welke context wel of niet zijn toegestaan en welke tags optioneel zijn

Blijft natuurlijk nog steeds het punt dat de HTML die ik opschreef wel degelijk fout was (maar dus niet om de reden die ik noemde) en wel degelijk zonder morren door alle browsers werd gerenderd.

Dat heeft een andere reden: validation is geen useragent taak of requirement. De meeste browsers hebben maar 1 enkele parser die elke vorm van HTML verwerken (inclusief XHTML geserveerd als text/html), naar de DTD wordt enkel maar gekeken om te bepalen of er in 'standards compliant' of 'quirksmode' gerendered moet worden.

Validation is een authortool (en biedt an sich ook geen garanties, maar kan wel nare verrassingen voorkomen) net als een lint-checker. Authoring conformance is dan ook iets heel anders dan useragent conformance met betrekking tot een specificatie, useragents moeten veel meer kunnen verwerken dan formeel conformant is voor authors. In HTML4 zegt 'Strict' versus 'Transitional' niets over useragent conformance, enkel iets over authoring conformance.

offtopic:
Dat een tag afsluiten zonder hem te openen als valide binnen de taal wordt beschouwt vind ik eigenlijk wel een redelijk ranzig iets, maar dat is waarschijnlijk alleen mijn mening.

Zoals JeromeB al opmerkt is er no such thing als een 'tag afsluiten'; in (X)HTML praat je over elementen die in syntax gedefinieerd zijn door een open-tag en (afgezien van 'void'-elementen) een sluit-tag. In XHTML heb je dan nog de 'selfclosing tags' voor 'void'-elementen noodzakelijk voor XML compliance.
Als de grammatica specificeert dat een bepaald element 'implied' is (zowel open- als sluit-tag zijn optioneel) dan volgt daaruit dat het ontbreken van 1 van beide tags (ongeacht welke) net zo goed valide is* (zelfs al staat het raar)

* in HTML uiteraard, niet in XHTML aangezien het dan niet meer aan het wellformedness vereiste van een XML applicatie zou voldoen

Intentionally left blank

maandag 24 september 2007 00:07

Acties:

0 Henk 'm!

flowerp

crisp schreef op zondag 23 september 2007 @ 22:32:
Als de grammatica specificeert dat een bepaald element 'implied' is (zowel open- als sluit-tag zijn optioneel) dan volgt daaruit dat het ontbreken van 1 van beide tags (ongeacht welke) net zo goed valide is* (zelfs al staat het raar)

Ik vind dat eigenlijk niet zo'n mooi taal ontwerp, als de grammatica ervan toestaat dat een -syntax- element dat als semantiek slechts heeft dat 'iets' wordt afgesloten toegestaan is terwijl dat iets helemaal nooit expliciet geopend is (door het bijbehorende -syntax- element).

Dat heeft een andere reden: validation is geen useragent taak of requirement. De meeste browsers hebben maar 1 enkele parser die elke vorm van HTML verwerken

Feitelijk is dat voor (gegenereerde0 assembly code voor een CPU niet anders. Deze wordt ook niet meer gevalideerd door de CPU. Is het niet valide dat halt je CPU of krijg je een kernel trap. Validatie is iets dat door de editor en/of compiler wordt gedaan. Bekrachtigt mijn eerdere uitspraak weer eens dat HTML eigenlijk de assembly van het web is

[ Voor 29% gewijzigd door flowerp op 24-09-2007 00:13 ]

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

maandag 24 september 2007 00:33

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

flowerp schreef op maandag 24 september 2007 @ 00:07:
[...]

Ik vind dat eigenlijk niet zo'n mooi taal ontwerp, als de grammatica ervan toestaat dat een -syntax- element dat als semantiek slechts heeft dat 'iets' wordt afgesloten toegestaan is terwijl dat iets helemaal nooit expliciet geopend is (door het bijbehorende -syntax- element).

Like I said: het staat inderdaad raar, maar 'implicit context' is ook beetje een afwijkend concept. Je maakt er overigens waarschijnlijk vaker gebruik van dan je denkt: hoe vaak gebruik jij TBODY binnen TABLE?

SGML is natuurlijk een taal die ontwikkeld is in een tijd dat bytes nog duur waren. Een aantal concepten zoals NET SHORTTAG zijn zelfs ook gedefinieerd voor HTML maar hebben nooit hun weg gevonden binnen implementaties. In sommige gevallen is het echter wel prettig dat je gebruik kan maken van features die je output minder verbose maken zonder dat het ambiguiteiten oplevert

[...]

Feitelijk is dat voor (gegenereerde0 assembly code voor een CPU niet anders. Deze wordt ook niet meer gevalideerd door de CPU. Is het niet valide dat halt je CPU of krijg je een kernel trap. Validatie is iets dat door de editor en/of compiler wordt gedaan. Bekrachtigt mijn eerdere uitspraak weer eens dat HTML eigenlijk de assembly van het web is

Mooie analogie, met dien verstande dat de 'interpreter' in deze vergevingsgezind is en een 'best guess' mag/kan doen*

* dat gaat uiteraard niet op voor wellformedness errors in XHTML modus (met een X(HT)ML mimetype dus waarvoor XHTML-compliant useragents een XML-parser gebruiken). Mede door deze draconische errorhandling (en het ontbreken van support in IE) is XHTML nooit echt van de grond gekomen.

Intentionally left blank

dinsdag 25 september 2007 21:47

Acties:

0 Henk 'm!

flowerp

crisp schreef op zondag 23 september 2007 @ 22:32:
Correctie: voor layout hebben we CSS

ps

Toch gebruik je HTML ook voor layout. Hoe wil je b.v. anders relatieve volgorde van elementen bepalen? Met CSS kun je natuurlijk wel dingen horizontaal of verticaal layouten, maar als je via markup 3 elementen definieert, 1, 2 en 3 (in die volgorde), dan kun je die puur via CSS toch niet als 2, 1, 3 laten renderen?

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

dinsdag 25 september 2007 21:58

Acties:

0 Henk 'm!

Alex)

flowerp schreef op dinsdag 25 september 2007 @ 21:47:
[...]

ps

Toch gebruik je HTML ook voor layout. Hoe wil je b.v. anders relatieve volgorde van elementen bepalen? Met CSS kun je natuurlijk wel dingen horizontaal of verticaal layouten, maar als je via markup 3 elementen definieert, 1, 2 en 3 (in die volgorde), dan kun je die puur via CSS toch niet als 2, 1, 3 laten renderen?

Wel met position:absolute

We are shaping the future

dinsdag 25 september 2007 22:39

Acties:

0 Henk 'm!

Grijze Vos

Alex) schreef op dinsdag 25 september 2007 @ 21:58:
[...]

Wel met position:absolute

en met float:right...

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info

dinsdag 25 september 2007 23:14

Acties:

0 Henk 'm!

flowerp

Alex) schreef op dinsdag 25 september 2007 @ 21:58:
[...]
Wel met position:absolute

Zou dat geen slecht programmeervoorbeeld zijn (om het nog een beetje offtopic te houden

). Nu ben ik verre van een HTML/Javascript expert, maar moet je dan niet via javascript de grote van je elementen bepalen, om dan vervolgens absolute posities uit te rekenen, die je dan vervolgens toe kent via een CSS expressie aan je element?

Dat lijkt mij niet meer puur CSS, maar meer een javascript layout manager die op pixel niveau werkt (voor de liefhebbers; zoals we die vroeger ook wel schreven in een win32/MFC omgeving).

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

dinsdag 25 september 2007 23:18

Acties:

0 Henk 'm!

Alex)

flowerp schreef op dinsdag 25 september 2007 @ 23:14:
[...]

Zou dat geen slecht programmeervoorbeeld zijn (om het nog een beetje offtopic te houden ). Nu ben ik verre van een HTML/Javascript expert, maar moet je dan niet via javascript de grote van je elementen bepalen, om dan vervolgens absolute posities uit te rekenen, die je dan vervolgens toe kent via een CSS expressie aan je element?

Dat lijkt mij niet meer puur CSS, maar meer een javascript layout manager die op pixel niveau werkt (voor de liefhebbers; zoals we die vroeger ook wel schreven in een win32/MFC omgeving).

Bwoch, daar heb je geen JS voor nodig hoor...

Gewoon je <li>'s een vaste hoogte geven en anders positioneren met CSS... maar we dwalen helemaal af geloof ik

We are shaping the future

dinsdag 25 september 2007 23:39

Acties:

0 Henk 'm!

Not Pingu

Dumbass ex machina

ValHallASW schreef op zaterdag 22 september 2007 @ 16:13:
Variabelen niet initialiseren slaat sowieso nergens op. Het voordeel van variabelen niet expliciet definieren is ook dat je in geen geval in een bestaande variabele een onbekende waarde hebt staan.

Mwoh. Null of 'deze variabele is niet geinitialiseerd' is heel wat minder ambigu dan 'de waarde is 0 of "", maar komt dat nou omdat deze variabele voor het eerst gebruikt wordt, of heb ik ergens wat fout gedaan?'
Je tweede zin volg ik ff niet. Bedoel je dat het een voordeel is dat je een variabele kunt gebruiken zonder deze een betekenisvolle waarde te geven?

Certified smart block developer op de agile darkchain stack. PM voor info.

woensdag 10 oktober 2007 10:37

Acties:

0 Henk 'm!

Serpie

Laatst een tijdje gespeurd naar een bug, er was een array gedeclareerd als volgt (zaten wat andere items in maar dit was het idee van de bug):

Visual Basic .NET:

1	Private list() As Integer = {-7, -6, -5, -4 -3, -2, -1, 0, ...}

Deze werd vervolgens in een algoritme gebruikt, en ik me afvragen waarom sommige items overgeslagen werden. Het nare met dit soort bugs is dat je het in de meest moeilijke hoeken gaat zoeken en dit snel over het hoofd ziet. De kans dat er een fout in het nieuwe algoritme zit is natuurlijk groter

woensdag 10 oktober 2007 10:42

Acties:

0 Henk 'm!

Anoniem: 49627

Serpie schreef op woensdag 10 oktober 2007 @ 10:37:
Laatst een tijdje gespeurd naar een bug, er was een array gedeclareerd als volgt [...]

Jeetje die is inderdaad wel heel erg nasty, ik wilde al bijna aan je vragen of dit een VB only issue was

woensdag 10 oktober 2007 10:57

Acties:

0 Henk 'm!

Woy

Moderator Devschuur®

Call me stupid, maar ik zie het probleem niet. Toch nog maar een bakie koffie halen dan.

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”

woensdag 10 oktober 2007 11:01

Acties:

0 Henk 'm!

Swaptor

Java Apprentice

*ziet dat er een komma mist*

Ontdek mij!
Proud NGS member
Stats-mod & forum-dude

woensdag 10 oktober 2007 11:05

Acties:

0 Henk 'm!

Woy

Moderator Devschuur®

Ah idd, nou zie ik het

“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”

woensdag 10 oktober 2007 11:11

Acties:

0 Henk 'm!

Janoz

Moderator Devschuur®

!litemod

Software engineering

Ikzelf had ook 3x nodig voor ik het zag... Nasty indeed!

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'

woensdag 10 oktober 2007 11:22

Acties:

0 Henk 'm!

TrailBlazer

Karnemelk FTW

uit eigen doos

code:

while (<>) {
chomp;
$file=$_;
undef %vlan if (defined(%vlan));
open (CONFIG,$_);
while (<CONFIG>) {
if (/\sswitchport\saccess\svlan/) {
($vlan)=($_=~/vlan\s(\d+)/);
if (defined($vlan{$vlan})) {
$vlan{$vlan}++;
}
else {
$vlan{$vlan}=1;
}
}
}
close CONFIG;
foreach $vlan (sort(keys(%vlan))) {
print "$file\t$vlan\t" . $vlan{$vlan} . "\n";
}
}

Een perl toolie die ik in 5 minuten in elkaar heb geklust niet heel erg spannend allemaal. Wat ik denk vooral ranzig is om de naam van hash en de variabele hetzelfde te houden. Ook maak ik vaak (hier niet toevallig) gebruik van het feit dat de variabele $_ wordt gebruikt als je geen variabele specificeert.

woensdag 10 oktober 2007 11:23

Acties:

0 Henk 'm!

Voutloos

@Serpie
Fraai voorbeeld van een typo waarbij syntax highlighting je niet kan helpen.

Puur omdat je de array met het handje vult, ben je bij het debuggen geniegd om het meest triviale niet te doen: de array weergeven.

{signature}

woensdag 10 oktober 2007 14:28

Acties:

0 Henk 'm!

roy-t

Voutloos schreef op woensdag 10 oktober 2007 @ 11:23:
@Serpie
Fraai voorbeeld van een typo waarbij syntax highlighting je niet kan helpen.
Puur omdat je de array met het handje vult, ben je bij het debuggen geniegd om het meest triviale niet te doen: de array weergeven.

Dat doe ik dus juist vaak wel, een matrix of array weergeven, met Visual Studio kun je er een breakpoint op zetten en gewoon op wat plusjes drukken om de inhoud te controleren.

vooral bij matrices echt een must.

(oh ja

dit was waarsch. common knowledge

)

~ Mijn prog blog!

woensdag 10 oktober 2007 16:42

Acties:

0 Henk 'm!

Mastermind

Ik had dit staan:

C#:

static private string getOmschrijving_Exact_artbst(int artcode)
{
     VwExactArtbstTypedView vwExactArtbstTypedView = new VwExactArtbstTypedView();
     vwExactArtbstTypedView.Fill();
     DataView dv = (DataView)vwExactArtbstTypedView.DefaultView;
     dv.RowFilter = "artcode=" + artcode; 
     string omschrijving = dv.Count == 0 ? "" : dv[0]["Oms300"] + " - " + dv[0]["KortOms"]; // Let op in de DB staat die als oms30_0 en kort_oms
     return omschrijving;
}

Ik dacht: Wa's ie traag ja?? Na veel Ticks in de code gezet te hebben kwam ik erachter dat het te herleiden was naar deze method.
Logisch, wat gebeurt er: De hele view wordt opgehaald, 1000+ records, en daar wordt 1 rij uit geselecteerd..

Bij onderstaande code haalt hij 1 record uit de view, en toont deze.

C#:

static private string getOmschrijving_Exact_artbst(int artcode)
{
     VwExactArtbstTypedView vwExactArtbstTypedView = new VwExactArtbstTypedView();
     PredicateExpression pex = new PredicateExpression(VwExactArtbstFields.Artcode == artcode);
     vwExactArtbstTypedView.Fill(0, null, false, pex);
     DataView dv = (DataView)vwExactArtbstTypedView.DefaultView;
     string omschrijving = dv.Count == 0 ? "" : dv[0]["Oms300"] + " - " + dv[0]["KortOms"]; // Let op in de DB staat die als oms30_0 en kort_oms
     return omschrijving;
}

Nog steeds wat traag maarja.

woensdag 10 oktober 2007 17:00

Acties:

0 Henk 'm!

Robtimus

me Robtimus no like you

Mastermind schreef op woensdag 10 oktober 2007 @ 16:42:
Bij onderstaande code haalt hij 1 record uit de view, en toont deze.

C#:

static private string getOmschrijving_Exact_artbst(int artcode)
{
     VwExactArtbstTypedView vwExactArtbstTypedView = new VwExactArtbstTypedView();
     PredicateExpression pex = new PredicateExpression(VwExactArtbstFields.Artcode == artcode);
     vwExactArtbstTypedView.Fill(0, null, false, pex);
     DataView dv = (DataView)vwExactArtbstTypedView.DefaultView;
     string omschrijving = dv.Count == 0 ? "" : dv[0]["Oms300"] + " - " + dv[0]["KortOms"]; // Let op in de DB staat die als oms30_0 en kort_oms
     return omschrijving;
}

Ik ben niet zo heel erg thuis in C#, maar wordt die PRedicateExpression niet aangemaakt met als parameter "TRUE"? Met andere woorden, heeft hij nog wel een referentie naar de waarde van artcode? Zo nee dan schiet dit volgens mij nog steeds niet op.

More than meets the eye
There is no I in TEAM... but there is ME
system specs

woensdag 10 oktober 2007 19:45

Acties:

0 Henk 'm!

Marcj

IceManX schreef op woensdag 10 oktober 2007 @ 17:00:
[...]

Ik ben niet zo heel erg thuis in C#, maar wordt die PRedicateExpression niet aangemaakt met als parameter "TRUE"? Met andere woorden, heeft hij nog wel een referentie naar de waarde van artcode? Zo nee dan schiet dit volgens mij nog steeds niet op.

Dat zou je wel verwachten, maar helaas ondersteunt C# ook operator overloading, dus je weet het maar nooit. Dit is trouwens ook gelijk mijn grootste bezwaar hier tegen.

woensdag 10 oktober 2007 20:23

Acties:

0 Henk 'm!

Mastermind

't Is inderdaad zo dat met operator overloading een query eenvoudig in een PredicateExpression of IPredicate geschreven kan worden. We gebruiken LLBLGen. Ik ben een groot voorstander van operator overloading, omdat je zo makkelijk queries kunt lezen en schrijven.
Voor degenen die hier niet van houden, kun je AddWithAnd en AddWithOr gebruiken trouwens, maar of dat overzichtelijk en in 1 oogopslag laat zien wat de query doet is een tweede..

Anyway, ik zat me net te bedenken dat ik de view beter global kan inladen, en dan een dataview rowfilter erop los laat. Want als er 40 orders ingepland wordt en hij bij elke activiteit steeds die view op moet halen gaat heel traag worden voorzie ik

woensdag 10 oktober 2007 21:00

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Software development
Software engineering

Marcj schreef op woensdag 10 oktober 2007 @ 19:45:
[...]

Dat zou je wel verwachten, maar helaas ondersteunt C# ook operator overloading, dus je weet het maar nooit. Dit is trouwens ook gelijk mijn grootste bezwaar hier tegen.

Heb jij om diezelfde reden ook een bezwaar tegen bijvoorbeeld properties?

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

woensdag 10 oktober 2007 22:28

Acties:

0 Henk 'm!

Marcj

.oisyn schreef op woensdag 10 oktober 2007 @ 21:00:
[...]

Heb jij om diezelfde reden ook een bezwaar tegen bijvoorbeeld properties?

Ik vind dat een vergelijking gewoon altijd een boolean moet opleveren. Dat het hier een object oplevert vind ik raar. De betekenis van de vergelijking is hier echt veranderd. Daarom vind ik het set en get methode van properties (die bedoel je toch?) ook raar. Hierdoor kan een assignment in een keer verdere side effects hebben, terwijl je dat niet direct er aan kan aflezen.

Ik weet dat jij hierover een andere mening hebt en dat we hier waarschijnlijk toch niet uit gaan komen, maar dit is mijn mening

donderdag 11 oktober 2007 00:28

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Software development
Software engineering

I know, en je argument is valide, ik vroeg me af of je het ook doortrok naar andere concepten

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

donderdag 11 oktober 2007 00:39

Acties:

0 Henk 'm!

Snake

Los Angeles, CA, USA

Niet echt een voorbeeld, maar eerder een eigen stommiteit:

Ik zit te werken in J#, omdat ik Java ken van op school, en ik wou gemakkelijk GUI's tekenen, en ik kon al werken met VS.NET, dus de keuze was rap gemaakt.

Anyway: ik probeer dus een string te formatten, via String.Format:

Java:

1	String dag = String.Format("{0:D2}", 7);

Maar dat werkte niet. Blijkt dat de Visual Studio compiler nog steeds Java 1.4 compliant is, een geen autoboxing ondersteund.

Java:

1	String dag = String.Format("{0:D2}", (System.Int32)7);

dus

Going for adventure, lots of sun and a convertible! | GMT-8

donderdag 11 oktober 2007 08:20

Acties:

0 Henk 'm!

4of9

Marcj schreef op woensdag 10 oktober 2007 @ 22:28:
[...]
Daarom vind ik het set en get methode van properties (die bedoel je toch?) ook raar. Hierdoor kan een assignment in een keer verdere side effects hebben, terwijl je dat niet direct er aan kan aflezen.

Ik weet dat jij hierover een andere mening hebt en dat we hier waarschijnlijk toch niet uit gaan komen, maar dit is mijn mening

Ik vind dat een beetje raar. Een Get of Set methode kan ook side effecten hebben naast de assignment en dat weet je dan ook niet. Maar bij conventie doe je dat niet.

Zo kun je ook een conventie maken over propeties. Wat mij betreft is het gewoon een syntax dingetje en niet eens een echt functioneel iets.

Aspirant Got Pappa Lid | De toekomst is niet meer wat het geweest is...

donderdag 11 oktober 2007 08:50

Acties:

0 Henk 'm!

Marcj

4of9 schreef op donderdag 11 oktober 2007 @ 08:20:
[...]

Ik vind dat een beetje raar. Een Get of Set methode kan ook side effecten hebben naast de assignment en dat weet je dan ook niet. Maar bij conventie doe je dat niet.

Zo kun je ook een conventie maken over propeties. Wat mij betreft is het gewoon een syntax dingetje en niet eens een echt functioneel iets.

Het verschil is dat je met een get of set methode weet dat je een methode aanvraagt, dat kun je direct zien. Dan weet je dat er meer kan gebeuren dan alleen een assignment (al is dat meestal alleen wat controles of de waarde wel geldig is, maar soms wordt er meer veranderd). Door conventie zal het wel goed gaan, maar toch moet je daar dan wel volledig op vertrouwen. Zo heb ik stage gelopen bij een bedrijf waar dit nog wel eens misbruikt werd

Daarom vind ik operator overloading ook erger dan properties, want dat wordt nog veel vaker uit context gehaald. Een == hoort gewoon twee primitieve nummer (of pointers) te vergelijken en een boolean op te leveren. Als ik nu wil kijken ik twee pointers naar hetzelde object heb, kan dat in een keer niet meer, omdat deze operatie overschreven is. Erger nog, de return type kan gewijzigd zijn!

Ik hoop tenminste dat ze dit soort onzin nooit in Java gaan invoeren...

donderdag 11 oktober 2007 08:54

Acties:

0 Henk 'm!

4of9

Met dat operator overloading ben ik het denk ik wel mee eens (hoewel het in meerdere talen voorkomt en het ooit met een reden bedacht is door mensen die veel slimmer zijn dan ik

)

Met die properties blijft het een kwestie van smaak en afspraken. Niets houd je tegen om zelf gewoon getter en setter methodes te schrijven in C#

Aspirant Got Pappa Lid | De toekomst is niet meer wat het geweest is...

donderdag 11 oktober 2007 09:31

Acties:

0 Henk 'm!

Zamalan

Whine Connaisseur

Uit eigen portfolio

SQL:

1	select * from someTable where someColumn = null

En maar zoeken waarom ik niks terug kreeg terwijl er toch wel zeker records waren met null!

Jammer maar helaas kom ik het nog tegen

MSI GX660 --- i5 460M /// 4GB DDR3 /// Mobility Radeon HD5870 /// 1920x1080 /// 500GB

donderdag 11 oktober 2007 10:25

Acties:

0 Henk 'm!

PrisonerOfPain

Marcj schreef op donderdag 11 oktober 2007 @ 08:50:
[...]

Het verschil is dat je met een get of set methode weet dat je een methode aanvraagt, dat kun je direct zien.

Ik verwacht dat .oisyn het over properties had zoals bekend uit C#, waarbij je dus ook niet meer het verschil ziet tussen een (potentiele) functie aanroep en een gewone propertie. Daarnaast weet iedere C++ programmeur donders goed dat een operator simpelweg een functie aanroep betekend.

donderdag 11 oktober 2007 10:45

Acties:

0 Henk 'm!

Anoniem: 49627

Zamalan schreef op donderdag 11 oktober 2007 @ 09:31:
Uit eigen portfolio
SQL:
1
select * from someTable where someColumn = null

Een beetje fatsoenlijke database smijt dan toch ook gewoon een exceptie?

Overigens nooit begrepen waarom er een andere syntax nodig zou zijn voor een 'is null' constraint. Ik vind dat echt een van de vele fundamentele fouten in sql.

donderdag 11 oktober 2007 11:04

Acties:

0 Henk 'm!

kenneth

achter de duinen

Wat is een fatsoenlijke database dan? Ik dacht altijd dat MSSQL dat wel was, maar die geeft gewoon 0 records, zonder warning of wat dan ook.

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.

donderdag 11 oktober 2007 11:18

Acties:

0 Henk 'm!

Anoniem: 49627

kenneth schreef op donderdag 11 oktober 2007 @ 11:04:
Wat is een fatsoenlijke database dan? Ik dacht altijd dat MSSQL dat wel was, maar die geeft gewoon 0 records, zonder warning of wat dan ook.

Oracle vind ik wel een fatsoenlijke. Die zegt, niet geheel onverwacht, dat het incompatible types zijn. Uiteraard wel op de wazige non-informatieve oracle wijze

donderdag 11 oktober 2007 11:42

Acties:

0 Henk 'm!

OnTracK

Anoniem: 49627 schreef op donderdag 11 oktober 2007 @ 10:45:
[...]
Een beetje fatsoenlijke database smijt dan toch ook gewoon een exceptie?

Overigens nooit begrepen waarom er een andere syntax nodig zou zijn voor een 'is null' constraint. Ik vind dat echt een van de vele fundamentele fouten in sql.

Dat komt volgens mij door het principe van "niets is gelijk aan null" (ook null is niet gelijk aan null)

Oftewel, zelfs als je null met null zou vergelijken zou daar false null uit moeten komen, tenminste in DB's

[ Voor 10% gewijzigd door OnTracK op 11-10-2007 16:56 ]

Not everybody wins, and certainly not everybody wins all the time.
But once you get into your boat, push off and tie into your shoes.
Then you have indeed won far more than those who have never tried.

donderdag 11 oktober 2007 11:57

Acties:

0 Henk 'm!

Anoniem: 26306

OnTracK schreef op donderdag 11 oktober 2007 @ 11:42:

Dat komt volgens mij door het principe van "niets is gelijk aan NULL" (ook NULL != NULL)

Oftewel, zelfs als je NULL met NULL zou vergelijken zou daar false uit moeten komen, tenminste in DB's

Eigenlijk zou het resultaat van NULL == NULL ook NULL moeten zijn, en niet "waar" of "onwaar". Maar je hebt gelijk. En als je NULL ziet als een "niet-bepaalde waarde" of zelfs "niet te bepalen waarde", is het veel eenvoudiger om te begrijpen waarom dat zo is.

donderdag 11 oktober 2007 12:06

Acties:

0 Henk 'm!

OnTracK

Daar heb je helemaal gelijk in, uit null == null komt ook null, en ook uit null != null komt null. Ik heb het bijgewerkt

Als je het principe van null goed begrijpt kun je op een veel elegantere manier ermee werken, bijvoorbeeld met cascade.

[ Voor 48% gewijzigd door OnTracK op 11-10-2007 12:17 ]

Not everybody wins, and certainly not everybody wins all the time.
But once you get into your boat, push off and tie into your shoes.
Then you have indeed won far more than those who have never tried.

donderdag 11 oktober 2007 12:13

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Software development
Software engineering

Marcj schreef op donderdag 11 oktober 2007 @ 08:50:
Een == hoort gewoon twee primitieve nummer (of pointers) te vergelijken en een boolean op te leveren. Als ik nu wil kijken ik twee pointers naar hetzelde object heb, kan dat in een keer niet meer, omdat deze operatie overschreven is.

Het is ook absurd als men toestaat dat je operators kan overloaden voor built-in types, zoals pointers. In C++ kan dat ook niet (er moet ten minste 1 user defined type in de operanden voorkomen). In C# zit dat ingewikkelder omdat het verschil tussen een value-type en een reference niet echt duidelijk is. Ze hadden imho een andere syntax moeten bedenken om 2 reference objecten inhoudelijk met elkaar te kunnen vergelijken, zodat je met == en != gewoon references (en niets meer dan dat) kunt vergelijken.

Erger nog, de return type kan gewijzigd zijn!

Een echte vergelijking moet natuurlijk een bool geven, maar ik zie niet in waarom een speciale verzameling van classes niet iets anders zouden mogen teruggeven. Jij denkt dat er een gewone vergelijking is omdat je de software niet kent, maar iemand die de software wél kent is enorm blij dat hij een complexe expressie kan noteren zoals ie gewend is, zoals ((a - b) + (c * d)), en niet door middel van new AddExpression(new SubExpression(a, b), new MultiplyExpression(c, d)), als overduidelijk is dat a, b, c en d speciale objecten zijn (zoals bijv. referenties naar attributen van een tabel) en niet zozeer variabelen met een waarde. De usability en readability voor de persoon die daadwerkelijk met de software werkt weegt zwaarder dan de readability voor de persoon die er niet mee werkt maar toevallig eens naar de code kijkt.

Ik hoop tenminste dat ze dit soort onzin nooit in Java gaan invoeren...

Ja want het zou natuurlijk van de zotte zijn dat je eigen valuetypes zou kunnen gaan definieren waar je gewoon mee moet kunnen rekenen, zoals vectoren en matrices

PrisonerOfPain schreef op donderdag 11 oktober 2007 @ 10:25:
[...]

Ik verwacht dat .oisyn het over properties had zoals bekend uit C#, waarbij je dus ook niet meer het verschil ziet tussen een (potentiele) functie aanroep en een gewone propertie.

Klopt, maar daar heeft Marcj het toch ook over? Hij zegt dat hij aan expliciete get en set methods hij kan zien dat je methoden aan het aanroepen bent, terwijl je bij een assignment aan een property dat niet kunt zien (het ziet eruit als een simpele assignment, maar voor hetzelfde geldt doet het iets heel ingewikkelds).

Mijn mening is overigens dat je er gewoon niet vanuit moet gaan dat een assignment iets simpels is - dat is immers ook maar gewoon iets dat is aangeleerd maar verder geen enkele basis heeft

. Een loei van een struct in C# assignen aan een variabele (en dus geen property) is ook niet goedkoop.

[ Voor 26% gewijzigd door .oisyn op 11-10-2007 12:47 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

donderdag 11 oktober 2007 12:43

Acties:

0 Henk 'm!

Anoniem: 26306

.oisyn schreef op donderdag 11 oktober 2007 @ 12:13:

Mijn mening is overigens dat je er gewoon niet vanuit moet gaan dat een assignment iets simpels is.

Daar ben ik het mee eens. Maar aan de andere kan is het natuurlijk wel zo dat je niet teveel gekkigheid moet uithallen de getter/setter van een property. Om de reden die je noemde. Men is eerder geneigd te denken dat een method achter de schermen allerlei dingen uithaalt, dan dat het setten van een property zoiets doet. Terwijl in bijvoorbeeld C# het enige verschil eigenlijk is, dat een setter van een property eigenlijk een method is dat alleen een value als argument accepteert.

Het zou me ook niets verbazen als na het compileren het verschil tussen een property setter en een method niet eens meer bestaat.

donderdag 11 oktober 2007 12:52

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Software development
Software engineering

Anoniem: 26306 schreef op donderdag 11 oktober 2007 @ 12:43:
Het zou me ook niets verbazen als na het compileren het verschil tussen een property setter en een method niet eens meer bestaat.

Het is idd pure syntactische suiker. Overloaded operators zijn dat natuurlijk ook.

[ Voor 7% gewijzigd door .oisyn op 11-10-2007 12:52 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

donderdag 11 oktober 2007 13:04

Acties:

0 Henk 'm!

Not Pingu

Dumbass ex machina

.oisyn schreef op donderdag 11 oktober 2007 @ 12:13:
Ja want het zou natuurlijk van de zotte zijn dat je eigen valuetypes zou kunnen gaan definieren waar je gewoon mee moet kunnen rekenen, zoals vectoren en matrices

No kidding, als je gigantische vergelijkingen moet implementeren waarin vectoren, kleuren of punten voorkomen, ben je harstikke blij als je twee vectoren gewoon met elkaar kunt vermenigvuldigen met v1 * v2.

Certified smart block developer op de agile darkchain stack. PM voor info.

donderdag 11 oktober 2007 15:50

Acties:

0 Henk 'm!

Marcj

Not Pingu schreef op donderdag 11 oktober 2007 @ 13:04:
[...]
No kidding, als je gigantische vergelijkingen moet implementeren waarin vectoren, kleuren of punten voorkomen, ben je harstikke blij als je twee vectoren gewoon met elkaar kunt vermenigvuldigen met v1 * v2.

True... dit zijn wel de voorbeelden waarin ik me wel kan vinden. Het enige waar ik me dan wel aan erger is de vorm waarin het voor databases gebruikt wordt (zoals in het eerdere voorbeeld). Want dan is de == in een keer geen vergelijking meer die wordt uitgevoerd, maar een vorm om een query op te bouwen.

Maar goed, ik ben nu al een tijdje bezig met Haskell, en dan ga je ook wel wennen aan iets andere syntax

, misschien ga ik ook ooit nog wel eens wennen aan C# en C++ (al heb ik gek genoeg minder moeite met de tweede).

vrijdag 12 oktober 2007 11:19

Acties:

0 Henk 'm!

Polichism

MOEHOE

Ik kwam dit net tegen in de les Java:

Java:

1	system.printout.ln("blaat");

{02:31:10} (splinkie): ik hoor net van iemand dat ze nu met een fietsband moest naaien omdat ze geen condooms meer kon betalen || {02:34:44} (Asjemenou): beter met een lange tijd met goodyear dan een korte tijd met firestone en in de problemen komen

vrijdag 12 oktober 2007 11:24

Acties:

0 Henk 'm!

Harmsen

Polichism schreef op vrijdag 12 oktober 2007 @ 11:19:
Ik kwam dit net tegen in de les Java:
Java:
1
system.printout.ln("blaat");

Haha, cool. Zo debug ik wel eens snel om te kijken waar een programma wel of niet komt. In elke functie snel
system.printout.ln("blaat1"); of system.printout.ln("blaat2");

What a fine day for Science! | Specs

vrijdag 12 oktober 2007 11:27

Acties:

0 Henk 'm!

Polichism

MOEHOE

Harmsen schreef op vrijdag 12 oktober 2007 @ 11:24:
[...]

Haha, cool. Zo debug ik wel eens snel om te kijken waar een programma wel of niet komt. In elke functie snel
system.printout.ln("blaat1"); of system.printout.ln("blaat2");

Je snapt hem niet he ?

je bedoeld zeker:

Java:

1	System.out.println("blaat1");

10 min later krijg je dit te zien in java:

Java:

1	return = 0;

[ Voor 9% gewijzigd door Polichism op 12-10-2007 11:33 ]

{02:31:10} (splinkie): ik hoor net van iemand dat ze nu met een fietsband moest naaien omdat ze geen condooms meer kon betalen || {02:34:44} (Asjemenou): beter met een lange tijd met goodyear dan een korte tijd met firestone en in de problemen komen

vrijdag 12 oktober 2007 16:33

Acties:

0 Henk 'm!

YopY

Software engineering
Software development

het niveau van code voorbeelden op schoolvoorbeelden (muv die uit een proper boek) zijn vaak om te huilen, vind ik.

vrijdag 12 oktober 2007 16:51

Acties:

0 Henk 'm!

Grijze Vos

YopY schreef op vrijdag 12 oktober 2007 @ 16:33:
het niveau van code voorbeelden op schoolvoorbeelden (muv die uit een proper boek) zijn vaak om te huilen, vind ik.

Praat me niet van schoolvoorbeelden. :x

Je wilt -niet- de code zien waar ik aan moet werken. Leuk visualisatie code waarin de variabele 'yx' 10x voorkomt in verschillende betekenissen. Ik ben al lang blij dat ik niet aan de fourier transformatie library hoef te komen.

offtopic:
(MBV, mocht je dit lezen: het is me gelukt door die fftw lib te includen als static lib.

)

[ Voor 9% gewijzigd door Grijze Vos op 12-10-2007 16:52 ]

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info

vrijdag 12 oktober 2007 18:57

Acties:

0 Henk 'm!

Polichism

MOEHOE

dit is dan een stukje javascript waar we dan mee bezig zijn.. en gewoon een 'domme' fout word gemaakt.
En maar afvragen waarom speedThrow niet werkt:

JavaScript:

function throwTimes(nrOT)
{
        nrLeft = nrOT;
        nrOfTimes = nrOT;
        timerId = setInterval('throwDice()', 500)
}
 
function speedThrow()
{
        clearTimer(timerId);
        alert('Slimme keus');
        for(i = nrLeft; i != 0; i--);
        {
                throwDice();
        }
}

{02:31:10} (splinkie): ik hoor net van iemand dat ze nu met een fietsband moest naaien omdat ze geen condooms meer kon betalen || {02:34:44} (Asjemenou): beter met een lange tijd met goodyear dan een korte tijd met firestone en in de problemen komen

zaterdag 13 oktober 2007 11:25

Acties:

0 Henk 'm!

MBV

Software engineering
Software development

Grijze Vos schreef op vrijdag 12 oktober 2007 @ 16:51:
[...]

Praat me niet van schoolvoorbeelden. :x

Je wilt -niet- de code zien waar ik aan moet werken. Leuk visualisatie code waarin de variabele 'yx' 10x voorkomt in verschillende betekenissen. Ik ben al lang blij dat ik niet aan de fourier transformatie library hoef te komen.

offtopic:
(MBV, mocht je dit lezen: het is me gelukt door die fftw lib te includen als static lib. )

yx zit helemaal niet in die code

Je bedoelt vx en vy, die als global bestaan én als argument worden meegegeven aan 3 functies? Fijn is dat ja

Gelukkig heb ik daar nog geen last van gehad. * MBV ziet voordelen in hungarian notation

.

libfftw wordt wel meer gebruikt, is een standaard lib, dus voor je daarin gaat duiken moet je jezelf even 3x achter de oren krabben

En als je nou gewoon op linux zou werken, had je nooit ruzie gehad met fftw

Polichism schreef op vrijdag 12 oktober 2007 @ 18:57:
dit is dan een stukje javascript waar we dan mee bezig zijn.. en gewoon een 'domme' fout word gemaakt.
En maar afvragen waarom speedThrow niet werkt:

JavaScript:

function throwTimes(nrOT)
{
        nrLeft = nrOT;
        nrOfTimes = nrOT;
        timerId = setInterval('throwDice()', 500)
}
 
function speedThrow()
{
        clearTimer(timerId);
        alert('Slimme keus');
        for(i = nrLeft; i != 0; i--);
        {
                throwDice();
        }
}

Leg uit, ik kijk er overheen.

zaterdag 13 oktober 2007 11:28

Acties:

0 Henk 'm!

Harmsen

Polichism schreef op vrijdag 12 oktober 2007 @ 11:27:
[...]

Je snapt hem niet he ?

je bedoeld zeker:
Java:
1
System.out.println("blaat1");

oops, moet ik wel goed kijken. Ik bedoelde idd de println

What a fine day for Science! | Specs

zaterdag 13 oktober 2007 23:10

Acties:

0 Henk 'm!

Polichism

MOEHOE

MBV schreef op zaterdag 13 oktober 2007 @ 11:25:

[...]

Leg uit, ik kijk er overheen.

een setInterval en die proberen te clearen met een clearTimer

{02:31:10} (splinkie): ik hoor net van iemand dat ze nu met een fietsband moest naaien omdat ze geen condooms meer kon betalen || {02:34:44} (Asjemenou): beter met een lange tijd met goodyear dan een korte tijd met firestone en in de problemen komen

dinsdag 16 oktober 2007 12:53

Acties:

0 Henk 'm!

Grijze Vos

MBV schreef op zaterdag 13 oktober 2007 @ 11:25:
[...]

En als je nou gewoon op linux zou werken, had je nooit ruzie gehad met fftw

Ik had geen ruzie met FFTW, Visual Studio had ruzie met FFTW.

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info

maandag 22 oktober 2007 15:36

Acties:

0 Henk 'm!

remco_k

een cassettebandje was genoeg

En weer eentje uit eigen doos bij het samenstellen van een deel van een dynamische query.
De gebruiker kan in de Labeled Edit (leDurationSec) een nummerieke waarde invullen om zodoende te kunnen filteren op duration X.

C++:

....
AnsiString asDurationSQL="";
if (!leDurationSec->Text.IsEmpty() && leDurationSec->Text.ToIntDef(-1)>-1) {
         asDurationSQL="AND duration>="+leDurationSec->Text.ToInt()*1000;
}
....

Uitvoeren van de uiteindelijke query ging helemaal mis. De meest vreemde errors.

spoiler:

Voor diegene die 'm niet vatten; ik vermenigvuldig niet de leDurationSec->Text met 1000 maar de pointer vermenigvuldig ik hier met 1000. Stom toevallig kwam ik op een stuk geheugen adres uit waar ook een AnsiString stond... En dat maakte het nog onduidelijker.
Dit is de goede code:
asDurationSQL="AND duration>="+IntToStr(leDurationSec->Text.ToIntDef(0)*1000);

Alles kan stuk.

maandag 22 oktober 2007 18:28

Acties:

0 Henk 'm!

Sv3n

Zag laatst ook een leuke:

Java:

if (var == null)
{
    log.error("Blaat met var " + var + " kon niet gevonden worden");
    return
}

Last.fm
Films!

maandag 22 oktober 2007 18:37

Acties:

0 Henk 'm!

Kuhlie

Dat kan natuurlijk nooit werken idd, je mist een puntkomma na return

dinsdag 23 oktober 2007 00:03

Acties:

0 Henk 'm!

.oisyn

Moderator Devschuur®

Demotivational Speaker

Software development
Software engineering

remco_k schreef op maandag 22 oktober 2007 @ 15:36:

spoiler:
Voor diegene die 'm niet vatten; ik vermenigvuldig niet de leDurationSec->Text met 1000 maar de pointer vermenigvuldig ik hier met 1000. Stom toevallig kwam ik op een stuk geheugen adres uit waar ook een AnsiString stond... En dat maakte het nog onduidelijker.
Dit is de goede code:
asDurationSQL="AND duration>="+IntToStr(leDurationSec->Text.ToIntDef(0)*1000);

Het spijt me zeer, maar daar klopt helemaal niets van

. Pointers kun je niet vermenigvuldigen, en bovendien heeft operator*() een hogere precedence dan operator+(). Wat er fout gaat is dat je aan de ene kant van de + een const char[] hebt, terwijl je aan de andere kant een int hebt staan. En ja, een int bij een const char[] optellen geeft een const char * die 'int' posities verder wijst, dus dat gaat fout. Een van de twee argumenten naar een AnsiString converteren zorgt dat het doet wat je verwacht

.

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

dinsdag 23 oktober 2007 14:42

Acties:

0 Henk 'm!

Anoniem: 224515

De variabele waar de pointer naartoe wijst kan je toch wel vermenigvuldigen?

C++:

int deVariabele = 1;
int * dePointer = &deVariabele;

*dePointer * 1000;

Zo kan het toch wel? (Heb net wat geleerd over pointers

)

dinsdag 23 oktober 2007 14:50

Acties:

0 Henk 'm!

NMe

Quia Ego Sic Dico.

Topicstarter

Anoniem: 224515 schreef op dinsdag 23 oktober 2007 @ 14:42:
De variabele waar de pointer naartoe wijst kan je toch wel vermenigvuldigen?
C++:
1
2
3
4
int deVariabele = 1;
int * dePointer = &deVariabele;

*dePointer * 1000;
Zo kan het toch wel? (Heb net wat geleerd over pointers )

Dat kan wel, maar dat heeft niet zoveel te maken met het probleem van remco_k en wat .oisyn daarover te vertellen heeft.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

woensdag 24 oktober 2007 00:07

Acties:

0 Henk 'm!

Possstema

Ok, ik ben nu bezig met opschonen van ons framewerk en kom regelmatig dingen tegen als

PHP:

1	if ($mod == 'modMyprofile') $mod = 'modMyProfile';

Ohwja, mijn baas had laatst een probleem en beweerde het op een volgende manier te kunnen oplossen:

PHP:

1	$var = $var;

vrijdag 18 januari 2008 13:12

Acties:

0 Henk 'm!

Crayne

Have face, will travel

Dit vind ik net in een JS form validatiescriptje, geleverd door een commerciële toko:

JavaScript:

function checkEmail(fieldObject, fieldMessage)
{

    if (fieldObject)
    {
    
        fieldObject.value = fieldObject.value.toLowerCase();
        var subValidationFailed = 2;    
        
        for( var i=0; i < fieldObject.value.length; i++ )
        { 
            if ( fieldObject.value.charAt(i) =="@"  )
            {
                subValidationFailed--;
            }
        }
        for( var i=0; i < fieldObject.value.length; i++ )
        { 
            if ( fieldObject.value.charAt(i) =="."  )
            {
                subValidationFailed--;
            }
        }
        for( var i=0; i < fieldObject.value.length; i++ )
        { 
            if ( fieldObject.value.charAt(i) ==" "  )
            {
                subValidationFailed++;
            }
        }
        
        if ( subValidationFailed > 0 )
        {

            ValidationFailed++;
            ValidationFailedFieldnames = ValidationFailedFieldnames + "- " + fieldMessage + "\n"

        }

    }

}

Afgezien van het feit dat dit nauwelijks validatie te noemen is, en het feit dat je beter af bent met een goede regular expression, is de code zelf ook nog eens idioot.

Als ik dus een email adres invul met meerdere "@" karakters, geen "." en geen spaties, dan wordt het gevalideerd. Maar even herschreven dus.

Mijn Library Thing catalogus

vrijdag 18 januari 2008 22:38

Acties:

0 Henk 'm!

flowerp

Crayne schreef op vrijdag 18 januari 2008 @ 13:12:
Als ik dus een email adres invul met meerdere "@" karakters, geen "." en geen spaties, dan wordt het gevalideerd. Maar even herschreven dus.

Dat 'even' herschreven zal ongetwijfeld beter zijn dan de dronkenmanscode hierboven, maar ik betwijfel of jij (of wie dan ook) 'even' een email validator kan schrijven

(kijk voor de grap maar eens de officiële specificatie na waaraan een email adres officieel moet/kan voldoen, dan sta je waarschijnlijk nog raar van te kijken

)

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

vrijdag 18 januari 2008 22:57

Acties:

0 Henk 'm!

mithras

Afaik valt de volgende regular expression best wel goed te gebruiken in de validatie^*

^[0-9a-z]([-_.]?[0-9a-z])*@[0-9a-z]([-.]?[0-9a-z])*\\.[a-z]{2,4}$

*)Ik ben dan niet zo thuis in regexen dat ik deze zelf kan schrijven, heb hem ook maar van het internet geplukt

vrijdag 18 januari 2008 23:11

Acties:

0 Henk 'm!

Rickets

Finger and a shift

mithras schreef op vrijdag 18 januari 2008 @ 22:57:
Afaik valt de volgende regular expression best wel goed te gebruiken in de validatie^*
^[0-9a-z]([-_.]?[0-9a-z])*@[0-9a-z]([-.]?[0-9a-z])*\\.[a-z]{2,4}$
*)Ik ben dan niet zo thuis in regexen dat ik deze zelf kan schrijven, heb hem ook maar van het internet geplukt

Die houdt al geen rekening met bijvoorbeeld single quotes en zo kan, zoals flowerp opmerkt, een e-mailadres nog meer rare fratsen bevatten waar je in eerste instantie niet aan denkt.

If some cunt can fuck something up, that cunt will pick the worst possible time to fucking fuck it up, because that cunt’s a cunt.

zaterdag 19 januari 2008 00:46

Acties:

0 Henk 'm!

mocean

mithras schreef op vrijdag 18 januari 2008 @ 22:57:
Afaik valt de volgende regular expression best wel goed te gebruiken in de validatie^*
^[0-9a-z]([-_.]?[0-9a-z])*@[0-9a-z]([-.]?[0-9a-z])*\\.[a-z]{2,4}$
*)Ik ben dan niet zo thuis in regexen dat ik deze zelf kan schrijven, heb hem ook maar van het internet geplukt

{2,4} op het eind, maar wat dacht je van .museum?
De complete reg-exp voor een valid email adres volgens de RFC is wel ergens met google te vinden, maar dat biedt ook geen zekerheid. je kan ook gemakkelijk een lijstje van toplevel domains gebruiken om te checken.

Koop of verkoop je webshop: ecquisition.com

zaterdag 19 januari 2008 01:25

Acties:

0 Henk 'm!

flowerp

mithras schreef op vrijdag 18 januari 2008 @ 22:57:
Afaik valt de volgende regular expression best wel goed te gebruiken in de validatie^*
^[0-9a-z]([-_.]?[0-9a-z])*@[0-9a-z]([-.]?[0-9a-z])*\\.[a-z]{2,4}$
*)Ik ben dan niet zo thuis in regexen dat ik deze zelf kan schrijven, heb hem ook maar van het internet geplukt

Voorspelbaar

Zoals ik dus al voorspelde, beter dan de code boven je, maar natuurlijk niet een echte email validator. Lees maar eens deze: http://www.faqs.org/rfcs/rfc2822.html en eventueel de oudere versie: http://www.faqs.org/rfcs/rfc822.html

Probeer je reg exp nu nog maar eens te schrijven

Owja, en schrijf hem zo dat ie -exact- de officiële regels volgt. Niets meer, niets minder. Gewoon officieel wat de spec voorschrijft.

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

zaterdag 19 januari 2008 01:39

Acties:

0 Henk 'm!

RayNbow

Kirika <3

flowerp schreef op zaterdag 19 januari 2008 @ 01:25:
Probeer je reg exp nu nog maar eens te schrijven

Owja, en schrijf hem zo dat ie -exact- de officiële regels volgt. Niets meer, niets minder. Gewoon officieel wat de spec voorschrijft.

Regexp oplossing:

spoiler:

Geen, de taal die alle geldige emailadressen bevat is niet regulier.

Ipsa Scientia Potestas Est
NNID: ShinNoNoir

zaterdag 19 januari 2008 09:52

Acties:

0 Henk 'm!

Crayne

Have face, will travel

flowerp schreef op vrijdag 18 januari 2008 @ 22:38:
[...]
Dat 'even' herschreven zal ongetwijfeld beter zijn dan de dronkenmanscode hierboven, maar ik betwijfel of jij (of wie dan ook) 'even' een email validator kan schrijven

Oh, dat zei ik ook niet. Kijk, als men het genoeg vind om te checken of een adres één of meerdere punten ".", één "@" en geen whitespace bevat, dan vind ik dat best.

Wat ik dus heb geschreven doet wat zij willen, zonder de dronkemanscode en de mogelijkheid om adressen met bijvoorbeeld meerdere "@"-tekens goedgekeurd te krijgen.

[ Voor 3% gewijzigd door Crayne op 19-01-2008 09:57 ]

Mijn Library Thing catalogus

zaterdag 19 januari 2008 09:55

Acties:

0 Henk 'm!

mithras

Tja, en met mijn regex wilde ik ook niet aantonen dat het de perfecte was

Ik snap dat een regex in principe een emailadres niet kan valideren, maar het maakt niet uit? Het is een simpele en relatief snelle manier om het adres globaal te controleren. Met foutafhandeling zorg je voor 99.9% afdekken van mogelijke fouten, je zal nooit alles kunnen voorkomen

zaterdag 19 januari 2008 10:32

Acties:

0 Henk 'm!

Erkens

Fotograaf

RayNbow schreef op zaterdag 19 januari 2008 @ 01:39:
[...]

Regexp oplossing:

spoiler:
Geen, de taal die alle geldige emailadressen bevat is niet regulier.

mja, deze komt aardig dicht in de buurt: http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html

zaterdag 19 januari 2008 11:13

Acties:

0 Henk 'm!

Anoniem: 43565

mithras schreef op zaterdag 19 januari 2008 @ 09:55:
Tja, en met mijn regex wilde ik ook niet aantonen dat het de perfecte was Ik snap dat een regex in principe een emailadres niet kan valideren, maar het maakt niet uit? Het is een simpele en relatief snelle manier om het adres globaal te controleren. Met foutafhandeling zorg je voor 99.9% afdekken van mogelijke fouten, je zal nooit alles kunnen voorkomen

Inderdaad, als je er meer tijd in gaat steken verspil je resources die je beter voor nuttigere dingen kunt gebruiken

Uiteindelijk kan iedereen toch wel een verkeerd e-mail adres invullen die wel aan de regex voldoet.

zaterdag 19 januari 2008 18:00

Acties:

0 Henk 'm!

YopY

Software engineering
Software development

Possstema schreef op woensdag 24 oktober 2007 @ 00:07:
Ohwja, mijn baas had laatst een probleem en beweerde het op een volgende manier te kunnen oplossen:
PHP:
1
$var = $var;

De oplossing is ook niet vreemd of vreselijk slecht of wat dan ook. Wat ik interresanter zou vinden is welk probleem dit stukkie op zou moeten lossen, en wat de logica daarachter dan is

.

zaterdag 19 januari 2008 18:17

Acties:

0 Henk 'm!

Voutloos

Dat probleem bestaat gewoon niet. Het enige dat ik kan bedenken is een isset() call verderop de code, maar isset() geeft false terug voor bij null values.

Als er een cast of dubbele quotes zou staan, of als het een andere var zou kopieren kon ik me er nog wel iets bij voorstellen.

{signature}

zaterdag 19 januari 2008 18:42

Acties:

0 Henk 'm!

Anoniem: 84120

RayNbow schreef op zaterdag 19 januari 2008 @ 01:39:
[...]

Regexp oplossing:

spoiler:
Geen, de taal die alle geldige emailadressen bevat is niet regulier.

spoiler:

Ook lang niet alle RegExp libraries zijn regulier, meerendeel kunnen meer dan alleen reguliere talen aan. *Jaa naam verteld wat anders*. Dus een programmeertaal-reguliere expressie (niet de formele-talen reguliere expressie) zou nog best kunnen.

[ Voor 12% gewijzigd door Anoniem: 84120 op 19-01-2008 18:44 ]

zaterdag 19 januari 2008 18:44

Acties:

0 Henk 'm!

g4wx3

hierboven in het topic:

PHP:

1
2
3

<?php
if ($mod == 'modMyprofile') $mod = 'modMyProfile';
?>

Dat is wel lekkere code zeg!

dan zou ik toch even zoek vervang uitvoeren toepassen op al mijn documentjes, of je gaat me niet vertellen dat deze 2 vars tegelijk worden gebruikt met een andere waarde?

Over de email controle, een simpele regexp is genoeg. Een beter systeem zou zijn even checken of het email-adress bereikbaar is (een soort ping). De enige manier om echt te checken, is echter een bevestigings mail te sturen.

http://www.softfocus.be/

zaterdag 19 januari 2008 18:57

Acties:

0 Henk 'm!

RayNbow

Kirika <3

Anoniem: 84120 schreef op zaterdag 19 januari 2008 @ 18:42:
[...]

spoiler:
Ook lang niet alle RegExp libraries zijn regulier, meerendeel kunnen meer dan alleen reguliere talen aan. *Jaa naam verteld wat anders*. Dus een programmeertaal-reguliere expressie (niet de formele-talen reguliere expressie) zou nog best kunnen.

Ah, bedoel je dit?

Ipsa Scientia Potestas Est
NNID: ShinNoNoir

zaterdag 19 januari 2008 19:28

Acties:

0 Henk 'm!

MBV

Software engineering
Software development

g4wx3 schreef op zaterdag 19 januari 2008 @ 18:44:
hierboven in het topic:
PHP:
1
2
3
<?php
if ($mod == 'modMyprofile') $mod = 'modMyProfile';
?>
Dat is wel lekkere code zeg!
dan zou ik toch even zoek vervang uitvoeren toepassen op al mijn documentjes, of je gaat me niet vertellen dat deze 2 vars tegelijk worden gebruikt met een andere waarde?

Over de email controle, een simpele regexp is genoeg. Een beter systeem zou zijn even checken of het email-adress bereikbaar is (een soort ping). De enige manier om echt te checken, is echter een bevestigings mail te sturen.

Ik heb ook wel eens zo'n regeltje neergezet. Ik wilde een breakpoint hebben, op iets dat door een veld van 50x50 heen liep met 60fps (zonder breakpoints

). Iets zegt mij dat er hier wat anders aan de hand is...

zaterdag 19 januari 2008 19:33

Acties:

0 Henk 'm!

Voutloos

MBV, volgens mij lees je over het verschil heen, want die code doet wel wat.

edit:
Ik las er eerst ook over heen, en dat is meteen de reden waarom dergelijke stunts met verschil in casing een nekschot waard zijn.

[ Voor 47% gewijzigd door Voutloos op 19-01-2008 19:34 ]

{signature}

zaterdag 19 januari 2008 23:32

Acties:

0 Henk 'm!

Anoniem: 84120

RayNbow schreef op zaterdag 19 januari 2008 @ 18:57:
[...]

Ah, bedoel je dit?

Bijvoorbeeld, nesting zoals daar beschreven is een goed voorbeeld van een niet-regulier iets, dat terwijl het in veel bestaande reguleire expressie-mechanismen wel mogelijk is. Maar goed, das allemaal theoretisch, niet interresant voor normale mensen.

Ik ga niet zeggen of mail-regexp met of zonder uitbreiding mogelijk of wenselijk is. Het zal vast wel kunnen met een uitgebreide reguliere expressietaal, maar dat maakt de oplossing niet echt *leesbaar* ben ik bang.

Onderwerpen