Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie
Toon posts:

[alg] Slechtste programmeervoorbeelden deel 5 Vorige deelOverzicht

Pagina: 1 ... 16 17 18 Laatste
Acties:

  • gekkie
  • Registratie: april 2000
  • Laatst online: 01:23
ThomasG schreef op vrijdag 4 oktober 2019 @ 20:15:
[...]
Het ticket nummer in de titel van de commit is alleen maar irritant, en verteld je helemaal niets aan je dat ziet en het ticket nummer niet uit je hoofd kent. Ik wil gewoon snel zien wat de commit oplost, dus een samenvatting van de commit in één zin. Vervolgens een uitgebreidere uitleg (indien nodig).
Ohhhww dat is zo gigantisch irritant. Merged pull requests met alleen een pull nummertje op github zijn dat ook.

  • Bee.nl
  • Registratie: november 2002
  • Niet online

Bee.nl

zoemt

ThomasG schreef op vrijdag 4 oktober 2019 @ 20:15:
[...]
Het ticket nummer in de titel van de commit is alleen maar irritant, en verteld je helemaal niets aan je dat ziet en het ticket nummer niet uit je hoofd kent. Ik wil gewoon snel zien wat de commit oplost, dus een samenvatting van de commit in één zin. Vervolgens een uitgebreidere uitleg (indien nodig). Verwijzingen naar een ander systeem staan bij ons helemaal onder aan de commit message met iets als: Closes T123, T456 e.d. waardoor het automatisch opgepakt wordt. Als ik wil zien welke code is aangepast voor een bepaalde ticket, kijk ik daarvoor in het build systeem; niet in de git log.
Versiebeheer is imho juist bij uitstek de locatie om snel informatie te kunnen krijgen over het wie/wat/waarom/wanneer. Bij ons prefixen we de commit messages dus met ticket nummer gevolgd door een kleine uitleg. De relatie tussen een code change en het ticket in je build straat vind ik omslachtig. Aangezien het ticket nummer een vast format heeft vind ik het efficiënter om dat meteen aan het begin van de message terug te vinden. Bij logging zet je immers toch ook niet de datum achter de logmessage, maar ervoor.

  • DaCoTa
  • Registratie: april 2002
  • Laatst online: 23:00
gekkie schreef op vrijdag 4 oktober 2019 @ 20:25:
[...]
Ohhhww dat is zo gigantisch irritant. Merged pull requests met alleen een pull nummertje op github zijn dat ook.
Ik zeg ook niet alleen een ticketnummer, dat is idd onhandig. Maar ticketnummer met titel van ticket of andere aanduiding, en daaronder nog evt. verdere uitleg. Maar die uitleg is specifiek over die commit, dat zou niet de uitleg van de commit moeten zijn, dat staat in het ticketsysteem.

  • mcDavid
  • Registratie: april 2008
  • Laatst online: 17:31
Matis schreef op vrijdag 4 oktober 2019 @ 06:49:
Één van de weinige keren dat ik commentaar gebruik in een stuk code, is wanneer er een (onlogische) business keuze gemaakt is. Dan plemp ik daar de URL naar het ticket in, zodat een toekomstig ontwikkelaar terug kan lezen waarom er zulke gekke keuzes gemaakt worden.
Dat soort logica schrijf ik liever in een eigen method. Dat geeft je de gelegenheid om de functionaliteit te beschrijven in de method name, zodat in de flow van je code direct duidelijk is wat er gebeurt zonder überhaupt de inhoud van die method te hoeven lezen.

Eventueel kun je dan ook de docblock gebruiken voor extra uitleg of linkjes naar tickets of documentatie.

zcflevo.nl


  • DaCoTa
  • Registratie: april 2002
  • Laatst online: 23:00
Matis schreef op vrijdag 4 oktober 2019 @ 06:49:
Één van de weinige keren dat ik commentaar gebruik in een stuk code, is wanneer er een (onlogische) business keuze gemaakt is. Dan plemp ik daar de URL naar het ticket in, zodat een toekomstig ontwikkelaar terug kan lezen waarom er zulke gekke keuzes gemaakt worden.
Het lastige is dat commentaren niet altijd goed meeverhuizen met de code. Als dan de code veranderd, kan het zijn dat de originele business case niet meer valide is, maar het commentaar er nog wel staat.

Een mooiere variant vind ik zelf om de business case dan via test-cases af te vangen, waarmee je dus heel eenvoudig het onlogische aspect kunt verduidelijken.

  • Mugwump
  • Registratie: mei 2017
  • Laatst online: 23:45
DaCoTa schreef op zaterdag 5 oktober 2019 @ 10:29:
[...]

Het lastige is dat commentaren niet altijd goed meeverhuizen met de code. Als dan de code veranderd, kan het zijn dat de originele business case niet meer valide is, maar het commentaar er nog wel staat.

Een mooiere variant vind ik zelf om de business case dan via test-cases af te vangen, waarmee je dus heel eenvoudig het onlogische aspect kunt verduidelijken.
Ik vind testcases nog altijd de beste vorm van documentatie inderdaad. Daarin maak je heel expliciet dat je bepaald gedrag verwacht en als je ze een goede naam geeft ook gelijk waarom je dat verwacht.

How many Prolog programmers does it take to change a lightbulb? Yes.


  • incaz
  • Registratie: augustus 2012
  • Laatst online: 21:49
Ik zou documentatie het liefst daar hebben waar je het tegenkomt. Dus zeker ook een comment in de code, dat is immers de plek waar het veranderd wordt. En het zinnetje 'voor meer informatie zie.'
Volgens mij zou je dus op elke plek op moeten nemen wat voor die plek relevant is. In de code is dat wel dat er een onlogische keuze gemaakt lijkt te zijn, maar niet de discussie die ertoe geleid heeft. In de commitmessage wel wat er veranderd is, maar niet de argumentatie. In het ticketsysteem wel de overwegingen, maar niet per se alle exacte details, en in de testcases wel allerlei randdetails om ze goed uit te werken.

Bv, ticketsysteem kan beginnen met 'naam met een cedille wordt niet goed weergegeven', idee kan zijn om alles naar UTF8 te doen, in het ticketsysteem komt aan de orde dat dat niet genoeg is en er vanwege wetgeving (en ik zou hier dus ook nog een verwijzing en link naar die specifieke wetgeving opnemen) maar een aantal speciale tekens zijn die zijn toegestaan en anderen volgens vaste manier moeten worden omgezet (ik weet niet meer zeker of dat precies klopt, er was iets mee maar het is lang geleden.) In de code kun je dan een commentaar krijgen met '//let op, extra omzettingsstap voor speciale tekens, UTF8 is niet genoeg, zie ticket [...]'
Commitmessage: 'ticket [...], extra omzettingsstap speciale tekens toegevoegd'
Testcases: de speciale tekens en hun verwachte resultaat, met ticketnummer.

En als er ergens urls breken, dan mis je een deel van de geschiedenis, maar heb je toch op alle plekken wel wat om mee te werken.

Never explain with stupidity where malice is a better explanation


  • Haan
  • Registratie: februari 2004
  • Laatst online: 07-12 09:23

Haan

dotnetter


C#:
1
var olderThan18 = DateTime.Parse((currentYear - 19).ToString() + "-12-31");


d:)b

Kater? Eerst water, de rest komt later
Last.fm profiel


  • RobIII
  • Registratie: december 2001
  • Laatst online: 23:50

RobIII

Moderator Devschuur®

^ Romeinse 3 ja!

Haan schreef op vrijdag 8 november 2019 @ 11:28:

C#:
1
var olderThan18 = DateTime.Parse((currentYear - 19).ToString() + "-12-31");


d:)b
Ik snap niet hoe iemand zoiets schrijft en dan voldaan achterover leunt en door gaat met meer code uitschijten. Er is toch geen enkel zichzelf respecterend programmeur die niet inziet wat hier mis mee is?

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

Roses are red Violets are blue, Unexpected ‘{‘ on line 32.

Over mij


  • CurlyMo
  • Registratie: februari 2011
  • Laatst online: 23:42

CurlyMo

www.pilight.org

RobIII schreef op vrijdag 8 november 2019 @ 11:46:
[...]

Ik snap niet hoe iemand zoiets schrijft en dan voldaan achterover leunt en door gaat met meer code uitschijten. Er is toch geen enkel zichzelf respecterend programmeur die niet inziet wat hier mis mee is?
Ik kan op zich nog best mild zijn naar hoe iemand iets implementeert, maar als het simpelweg niet klopt, niet.

geen vragen via PM die ook op het forum gesteld kunnen worden.


  • SpeedQber
  • Registratie: april 2017
  • Laatst online: 06-12 17:38
Wat geeft DateTime.Parse terug? Ik hoop een bool en geen string

  • downtime
  • Registratie: januari 2000
  • Niet online

downtime

Everybody lies

SpeedQber schreef op vrijdag 8 november 2019 @ 12:02:
Wat geeft DateTime.Parse terug? Ik hoop een bool en geen string
Ik hoop dat ie een DateTime terug geeft.

Maarre... Ook als niet-programmeur krijg ik kriebel van zulke code. Het voelt niet goed en dan ga ik zoeken naar iets beters. Het is niet alsof je de eerste bent die het verschil twee datums moet berekenen en dan ga ik het wiel niet opnieuw (slecht) uitvinden als duizenden (betere) programmeurs dat probleem ook al bekeken hebben.

  • Mugwump
  • Registratie: mei 2017
  • Laatst online: 23:45
downtime schreef op vrijdag 8 november 2019 @ 12:33:
[...]

Ik hoop dat ie een DateTime terug geeft.

Maarre... Ook als niet-programmeur krijg ik kriebel van zulke code. Het voelt niet goed en dan ga ik zoeken naar iets beters. Het is niet alsof je de eerste bent die het verschil twee datums moet berekenen en dan ga ik het wiel niet opnieuw (slecht) uitvinden als duizenden (betere) programmeurs dat probleem ook al bekeken hebben.
In C# kun je dat heel eenvoudig als volgt kunt doen.


C#:
1
var olderThan18 = DateTime.Now.AddYears(-18);

How many Prolog programmers does it take to change a lightbulb? Yes.


  • heuveltje
  • Registratie: februari 2000
  • Laatst online: 21:27

heuveltje

KoelkastFilosoof

Mugwump schreef op vrijdag 8 november 2019 @ 13:17:
[...]


In C# kun je dat heel eenvoudig als volgt kunt doen.


C#:
1
var olderThan18 = DateTime.Now.AddYears(-18);

Dan nog verwacht ik dat een var genaamd olderthan18 een Boolean zou moeten bevatten ipv een datum ?

Tell me where is gandalf? for i much desire to speak with him!


  • Mugwump
  • Registratie: mei 2017
  • Laatst online: 23:45
heuveltje schreef op vrijdag 8 november 2019 @ 13:42:
[...]


Dan nog verwacht ik dat een var genaamd olderthan18 een Boolean zou moeten bevatten ipv een datum ?
Mja, kun je over twisten, qua conventie is een boolean weer eerder iets als isOlderThan18 vaak. Dat is een beetje een nitpick vergeleken met de functionele fail in die code. :P

How many Prolog programmers does it take to change a lightbulb? Yes.


  • Matis
  • Registratie: januari 2007
  • Laatst online: 20:57

Matis

Rubber Rocket

Daarvoor zijn er unit testen, dan valt zo'n stuk code meteen door de mand.

If money talks then I'm a mime
If time is money then I'm out of time


  • Mugwump
  • Registratie: mei 2017
  • Laatst online: 23:45
Matis schreef op vrijdag 8 november 2019 @ 15:45:
Daarvoor zijn er unit testen, dan valt zo'n stuk code meteen door de mand.
Ligt eraan wie ze schrijft. :P

How many Prolog programmers does it take to change a lightbulb? Yes.


  • .oisyn
  • Registratie: september 2000
  • Laatst online: 01:41

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

Mugwump schreef op vrijdag 8 november 2019 @ 13:51:
[...]


Mja, kun je over twisten, qua conventie is een boolean weer eerder iets als isOlderThan18 vaak. Dat is een beetje een nitpick vergeleken met de functionele fail in die code. :P
Maar dan redeneer je verkeerd om. Wat vind jij dat het datatype van een variabele "olderThan18" dan moet zijn?

Wat ze eigenlijk bedoelen is "18 years ago", dan zou een DateTime wel toepasselijk zijn.

.oisyn wijzigde deze reactie 08-11-2019 17:17 (10%)

We were doomed from the start. I guess all that remains now is for the captain to go down with the ship.
- That's surprisingly noble of you, sir.
No, it's noble of you, Kif! As of now, you're in command. Congratulations, Captain!


  • Mugwump
  • Registratie: mei 2017
  • Laatst online: 23:45
.oisyn schreef op vrijdag 8 november 2019 @ 17:16:
[...]


Maar dan redeneer je verkeerd om. Wat vind jij dat het datatype van een variabele "olderThan18" dan moet zijn?

Wat ze eigenlijk bedoelen is "18 years ago", dan zou een DateTime wel toepasselijk zijn.
Klopt, maar de meeste talen doen een beetje moeilijk over variabelenamen die beginnen met een cijfer. :P
Ik vind olderThan18 vooral slecht gekozen. Het lijkt nog het meest op een predicate die je kunt gebruiken om true of false up te leveren.

How many Prolog programmers does it take to change a lightbulb? Yes.


  • AW_Bos
  • Registratie: april 2002
  • Laatst online: 01:38

AW_Bos

Every day, it's a party day 🎉

Holy hell, wat ik nu tegenkom, bij het helpen van iemand die iets aan zijn site wou toevoegen, slaat echt alles 8)7...
Deze 'widget' die je als iframe kan invoegen op een site is wel erg... huge!
https://www.shoutcastwidg...ist.php?uid=452&frame=yes

Even ontleden:
- Meteen een hele bootstrap die inhoudelijk in het bestand staat, en dus niet even wordt ingeladen vanuit een een paas losse bestanden (cachen wordt al te-niet gedaan)
- Vervolgens worden de items geladen, niks mis mee, maar wacht.... elk item die geladen wordt laadt weer op zijn beurt https://unpkg.com/sweetalert/dist/sweetalert.min.js in 8)7
- En dan denk je dat we klaar zijn... nee hoor, want elk item heeft ook een eigen jQuery functie die steeds uitgevoerd wordt, en overschreven wordt. 8)7

Al met al wordt er op die manier enkele MB's ingeladen, en duurt het volledige renderen iets van 15 seconden.

En dan denk je: "Oh, maar dat fixxen ze wel?"
Welnee, op de chat is het advies om het aantal te verlagen 8)7
En uiteraard wordt het gesprek door hun beëindigd met: "Waar maak je je druk om?"
Bam, meteen een IP-ban en de chat sluit automatisch 8)7

Tja :P

Zo is het, en zo gaat het, en zo zal het altijd gaan! 😁


  • BertS
  • Registratie: september 2004
  • Laatst online: 18:14
Ik moest lachen om je sig onder deze post :D

  • Antrax
  • Registratie: april 2012
  • Laatst online: 07-12 13:59

Antrax

Pixelated '-')/

RobIII schreef op vrijdag 8 november 2019 @ 11:46:
[...]

Ik snap niet hoe iemand zoiets schrijft en dan voldaan achterover leunt en door gaat met meer code uitschijten. Er is toch geen enkel zichzelf respecterend programmeur die niet inziet wat hier mis mee is?
Dit kon wel eens mijn nieuwe signature worden :o

.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!


  • MBV
  • Registratie: februari 2002
  • Laatst online: 01-12 16:48
RobIII schreef op vrijdag 8 november 2019 @ 11:46:
[...]

Ik snap niet hoe iemand zoiets schrijft en dan voldaan achterover leunt en door gaat met meer code uitschijten. Er is toch geen enkel zichzelf respecterend programmeur die niet inziet wat hier mis mee is?
Helaas zijn er genoeg zichzelf respecterende programmeurs die ik hiertoe in staat zie, en die dus niet mijn respect verdienen :P
Matis schreef op vrijdag 8 november 2019 @ 15:45:
Daarvoor zijn er unit testen, dan valt zo'n stuk code meteen door de mand.
Hoe? Dit stuk broddelwerk levert toch een datetime op van 31 december 19 jaar geleden, dus afhankelijk van hoe het gebruikt wordt kan het het juiste resultaat opleveren (wanneer een datum wordt vergeleken met greater-than met deze datum, kan je zien of iemand dit jaar 18 wordt).
En trouwens: goede unittests schrijven is moeilijker dan goede code, dus als ik dit zie vertrouw ik er niet op :+

  • Mugwump
  • Registratie: mei 2017
  • Laatst online: 23:45
MBV schreef op woensdag 13 november 2019 @ 22:04:
En trouwens: goede unittests schrijven is moeilijker dan goede code, dus als ik dit zie vertrouw ik er niet op :+
Daar kun je dan weer mutation tests voor gebruiken. :P

How many Prolog programmers does it take to change a lightbulb? Yes.


  • MBV
  • Registratie: februari 2002
  • Laatst online: 01-12 16:48
Mugwump schreef op woensdag 13 november 2019 @ 22:38:
[...]


Daar kun je dan weer mutation tests voor gebruiken. :P
Unit-tests schrijven zou makkelijker moeten zijn, zeker met TDD, maar mijn ervaring met collega's is toch totaal anders. Om te beginnen moet je een goede test-infrastructuur opzetten, dan moet je 'alle' testcases uitschrijven, en je moet daarbij de neiging overwinnen om testen over te slaan 'want hij doet het toch?!?'.
Als ik iets nieuws opzet zorg ik als een van de eerste dingen voor een unit-test-infrastructuur, om op verder te bouwen. Maar als je ergens halverwege een project binnenkomt is dat lastig.

  • JeroenE
  • Registratie: januari 2001
  • Niet online
MBV schreef op woensdag 13 november 2019 @ 22:04:
Hoe? Dit stuk broddelwerk levert toch een datetime op van 31 december 19 jaar geleden, dus afhankelijk van hoe het gebruikt wordt kan het het juiste resultaat opleveren (wanneer een datum wordt vergeleken met greater-than met deze datum, kan je zien of iemand dit jaar 18 wordt).
Wellicht het vroege tijdstip, maar hoe zou je dat dan met deze datum kunnen checken?

Stel: iemand is geboren op 1 december 2002. Dan is die datum groter dan 31 december 2000. Maar die persoon wordt dit jaar niet 18 maar 17.

En een andere test (om te zien of iemand al 18 of ouder is) klopt ook niet. Want als je bent geboren op 1 januari 2001 dan ben je nu al 18 maar als je het vergelijkt met 31 december 2000 dan zegt het systeem dat je dat nog niet bent.

Nouja, misschien is er wel een specifiek domein waar zo'n test wel nodig is omdat iets pas mag vanaf het eerste nieuwe kalenderjaar nadat je 18 bent geworden. Dan maken wij het te ingewikkeld door te focussen op het gebruik van 31 december 19 jaar geleden in plaats van de onhandige manier om op die datum te komen.

Misschien gaat het niet eens om mensen maar denken wij dat alleen omdat de grens van 18 jaar bij veel mensen als grote mijlpaal wordt gezien vanwege allerlei wettelijke regels. Voor hetzelfde geld gaat het over het printen van een label voor whisky (of whiskey). Ik ken daar de exacte regels niet van.

  • CurlyMo
  • Registratie: februari 2011
  • Laatst online: 23:42

CurlyMo

www.pilight.org

JeroenE schreef op donderdag 14 november 2019 @ 07:49:
[...]
Nouja, misschien is er wel een specifiek domein waar zo'n test wel nodig is omdat iets pas mag vanaf het eerste nieuwe kalenderjaar nadat je 18 bent geworden. Dan maken wij het te ingewikkeld door te focussen op het gebruik van 31 december 19 jaar geleden in plaats van de onhandige manier om op die datum te komen.
Dan is het aan je documentatie om uit te leggen waarom je afwijkt van wat gangbaar is.

geen vragen via PM die ook op het forum gesteld kunnen worden.


  • P-Storm
  • Registratie: september 2006
  • Laatst online: 07-12 13:16
JeroenE schreef op donderdag 14 november 2019 @ 07:49:
[...]
Wellicht het vroege tijdstip, maar hoe zou je dat dan met deze datum kunnen checken?

Stel: iemand is geboren op 1 december 2002. Dan is die datum groter dan 31 december 2000. Maar die persoon wordt dit jaar niet 18 maar 17.

En een andere test (om te zien of iemand al 18 of ouder is) klopt ook niet. Want als je bent geboren op 1 januari 2001 dan ben je nu al 18 maar als je het vergelijkt met 31 december 2000 dan zegt het systeem dat je dat nog niet bent.

Nouja, misschien is er wel een specifiek domein waar zo'n test wel nodig is omdat iets pas mag vanaf het eerste nieuwe kalenderjaar nadat je 18 bent geworden. Dan maken wij het te ingewikkeld door te focussen op het gebruik van 31 december 19 jaar geleden in plaats van de onhandige manier om op die datum te komen.

Misschien gaat het niet eens om mensen maar denken wij dat alleen omdat de grens van 18 jaar bij veel mensen als grote mijlpaal wordt gezien vanwege allerlei wettelijke regels. Voor hetzelfde geld gaat het over het printen van een label voor whisky (of whiskey). Ik ken daar de exacte regels niet van.
Op zich is het logisch, maar meer de WTF is dat niet de new DateTime(year, month, date) is gebruikt, maar voor een tekst oplossing is gegaan Deze heeft netjes integers als parameters.Vanuit daar kan dan teruggerekend worden in de jaren :)

Of ik lees je tekst verkeerd en doel je juist op het domein daarvoor, dan blame ik het ook op te vroeg

P-Storm wijzigde deze reactie 14-11-2019 09:02 (3%)


  • Voutloos
  • Registratie: januari 2002
  • Niet online
JeroenE schreef op donderdag 14 november 2019 @ 07:49:
[...]
Wellicht het vroege tijdstip, maar hoe zou je dat dan met deze datum kunnen checken?

Stel: iemand is geboren op 1 december 2002. Dan is die datum groter dan 31 december 2000. Maar die persoon wordt dit jaar niet 18 maar 17.
De code is zo slecht dat jij nu totaal verward bent, uiteraard check je op of datum voor ipv na deze peildatum ligt.
En een andere test (om te zien of iemand al 18 of ouder is) klopt ook niet. Want als je bent geboren op 1 januari 2001 dan ben je nu al 18 maar als je het vergelijkt met 31 december 2000 dan zegt het systeem dat je dat nog niet bent.
olderThan he, niet olderThanOrEqual, dus dit voorbeeld slaagt toevallig wel.

Dat gezegd hebbende, code is minstens erbarmelijk en als de 12-31 ook niet een domeinregel is zijn er geen woorden voor.

Talkin.nl daily photoblog


  • BladeSlayer1000
  • Registratie: april 2013
  • Laatst online: 21:51
AW_Bos schreef op zondag 10 november 2019 @ 22:30:
Holy hell, wat ik nu tegenkom, bij het helpen van iemand die iets aan zijn site wou toevoegen, slaat echt alles 8)7...
Deze 'widget' die je als iframe kan invoegen op een site is wel erg... huge!
https://www.shoutcastwidg...ist.php?uid=452&frame=yes

Even ontleden:
- Meteen een hele bootstrap die inhoudelijk in het bestand staat, en dus niet even wordt ingeladen vanuit een een paas losse bestanden (cachen wordt al te-niet gedaan)
- Vervolgens worden de items geladen, niks mis mee, maar wacht.... elk item die geladen wordt laadt weer op zijn beurt https://unpkg.com/sweetalert/dist/sweetalert.min.js in 8)7
- En dan denk je dat we klaar zijn... nee hoor, want elk item heeft ook een eigen jQuery functie die steeds uitgevoerd wordt, en overschreven wordt. 8)7

Al met al wordt er op die manier enkele MB's ingeladen, en duurt het volledige renderen iets van 15 seconden.

En dan denk je: "Oh, maar dat fixxen ze wel?"
Welnee, op de chat is het advies om het aantal te verlagen 8)7
En uiteraard wordt het gesprek door hun beëindigd met: "Waar maak je je druk om?"
Bam, meteen een IP-ban en de chat sluit automatisch 8)7

Tja :P
Wie heeft dit ooit bedacht, wat waardeloos...

  • mcDavid
  • Registratie: april 2008
  • Laatst online: 17:31
Voutloos schreef op donderdag 14 november 2019 @ 10:07:
[...]
De code is zo slecht dat jij nu totaal verward bent, uiteraard check je op of datum voor ipv na deze peildatum ligt.
[...]
olderThan he, niet olderThanOrEqual, dus dit voorbeeld slaagt toevallig wel.

Dat gezegd hebbende, code is minstens erbarmelijk en als de 12-31 ook niet een domeinregel is zijn er geen woorden voor.
och heer, over <= vs < gesproken, ik had vorige week ook zo'n prachtige (treurigmakende) diff:


PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
    /**
     * Check when process can not run or fails it its
     * has to add new Process by retry count of process.
     *
     * @param  Process $process
     */
    public function checkIfNeedToRetry(Process $process)

        // Check if need for new Process
        if ($process->getRetryCount() <= $process->getMaxRetry()) {
            // some code that initiates a retry;
        }
    }



heb de comments die erbij stonden ook maar meegepost, dan is ten minste duidelijk wat deze method zou moeten doen :D Die heb ik uiteindelijk ook maar weggehaald en in plaats daarvan de method "retryIfNecessary" genoemd. Leek me duidelijker dan dit verhaal.

zcflevo.nl


  • Voutloos
  • Registratie: januari 2002
  • Niet online
Dat docblock had ook echt een negatieve waarde. Dat de retry geïnitieerd wordt mist en dat is het %*{%* het belangrijkste aan het hele proces. En dan nog opgeschreven met Engels woorden, maar Engels grammatica (of desnoods Nederlandse woordvolgorde) is het in ieder geval niet. :D

Ik zou trouwens de conditie ín het object stoppen, dus enkel isRetryAllowed() ipv de count en de max allebei uit het object halen. ;)

Voutloos wijzigde deze reactie 14-11-2019 10:59 (19%)

Talkin.nl daily photoblog


  • JeroenE
  • Registratie: januari 2001
  • Niet online
P-Storm schreef op donderdag 14 november 2019 @ 09:01:
Of ik lees je tekst verkeerd en doel je juist op het domein daarvoor, dan blame ik het ook op te vroeg
Wat ik bedoel is dat er misschien een hele goede reden is dat er getest wordt op jaartal plus 31 december. Misschien volgt dat wel uit regelgeving of een gebruikelijke manier in een branche of bedrijf waar ik geen weet van heb.

Om een voorbeeld te geven, in een bedrijf krijg je een extra vakantiedag als je 5 jaar of langer in dienst bent. Maar vakantiedagen worden toegekend op 1 januari. Dus als je op 1 februari 2014 in dienst bent gekomen krijg je die extra dag pas op 1 januari 2020. En als je op 31 december 2014 in dienst bent gekomen dan krijg je die extra dag ook op 1 januari 2020.

De regeling had net zo goed kunnen zijn dat je die extra dag al gelijk op de dag dat je 5 jaar in dienst bent krijgt. Maar ja, zo is die regeling niet dus in dat geval kan je een check maken die de datum in dienst controleert met het vaste gegeven van 1 januari en dan aangevuld met het huidige jaartal minus 5.
Voutloos schreef op donderdag 14 november 2019 @ 10:07:
De code is zo slecht dat jij nu totaal verward bent, uiteraard check je op of datum voor ipv na deze peildatum ligt.
Zo uiteraard vind ik dat niet. Je kan op twee manieren controleren:
  1. ligt de geboortedatum voor de testdatum
  2. ligt de testdatum achter de geboortedatum
Op beide manieren weet je of iemand ouder dan 18 jaar is.
olderThan he, niet olderThanOrEqual, dus dit voorbeeld slaagt toevallig wel.
Dat is wellicht weer mijn eigen interpretatie dat je checkt op 18 jaar en niet dat je checkt of iemand ouder dan 18 jaar (= groter of gelijk dan 19 jaar) is.

Als je het wel zo leest dat het groter of gelijk aan 19 moet zijn dan klopt die test weer niet met een datum als 1 december 2000. Want je bent dan nu nog geen 19 terwijl de test of je geboortedatum voor 31 december 2000 ligt wel waar is.

  • .oisyn
  • Registratie: september 2000
  • Laatst online: 01:41

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

JeroenE schreef op donderdag 14 november 2019 @ 11:11:
[...]
Wat ik bedoel is dat er misschien een hele goede reden is dat er getest wordt op jaartal plus 31 december. Misschien volgt dat wel uit regelgeving of een gebruikelijke manier in een branche of bedrijf waar ik geen weet van heb.

Om een voorbeeld te geven, in een bedrijf krijg je een extra vakantiedag als je 5 jaar of langer in dienst bent. Maar vakantiedagen worden toegekend op 1 januari. Dus als je op 1 februari 2014 in dienst bent gekomen krijg je die extra dag pas op 1 januari 2020.
Dat volgt niet uit je eigen criteria. Iemand die 1 jan 2014 in dienst is, is op 1 jan 2019 al 5 jaar in dienst, dus die zou op die dag al een extra vakantiedag moeten krijgen.
De regeling had net zo goed kunnen zijn dat je die extra dag al gelijk op de dag dat je 5 jaar in dienst bent krijgt. Maar ja, zo is die regeling niet dus in dat geval kan je een check maken die de datum in dienst controleert met het vaste gegeven van 1 januari en dan aangevuld met het huidige jaartal minus 5.
Als je de uitkomst wil zoals je beschrijft zal ik niets met datumchecks doen maar gewoon kijken naar het jaartal. Dat is immers leidend; iemand die in jaar X in dienst is getreden, krijgt de extra dag pas in jaar X+6. Dat in een datum-type proberen te gieten geeft alleen maar een extra bron voor fouten.

.oisyn wijzigde deze reactie 14-11-2019 11:36 (6%)

We were doomed from the start. I guess all that remains now is for the captain to go down with the ship.
- That's surprisingly noble of you, sir.
No, it's noble of you, Kif! As of now, you're in command. Congratulations, Captain!


  • JeroenE
  • Registratie: januari 2001
  • Niet online
.oisyn schreef op donderdag 14 november 2019 @ 11:34:
Dat volgt niet uit je eigen criteria. Iemand die 1 jan 2014 in dienst is, is op 1 jan 2019 al 5 jaar in dienst, dus die zou op die dag al een extra vakantiedag moeten krijgen.
Dat klopt, maar mijn voorbeeld was 1 februari 2014. En dan ben je op 1 januari 2019 dus nog maar 4 jaar en 11 maanden in dienst en krijg je geen extra dag.
Als je de uitkomst wil zoals je beschrijft zal ik niets met datumchecks doen maar gewoon kijken naar het jaartal. Dat is immers leidend; iemand die in jaar X in dienst is getreden, krijgt de extra dag pas in jaar X+6.
Behalve dus als je op 1 januari in dienst bent gekomen, dan is het wel X+5. Dan moet je daar weer een uitzondering voor gaan maken.

  • .oisyn
  • Registratie: september 2000
  • Laatst online: 01:41

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

Oh jezus ik las echt "1 januari 2014" :D. Ja, als die ene dag uitmaakt dan moet je dat idd op die manier doen. Je kunt je afvragen of dat conceptueel handig is, maar dat ligt buiten de scope van de architect ;)

We were doomed from the start. I guess all that remains now is for the captain to go down with the ship.
- That's surprisingly noble of you, sir.
No, it's noble of you, Kif! As of now, you're in command. Congratulations, Captain!


  • Haan
  • Registratie: februari 2004
  • Laatst online: 07-12 09:23

Haan

dotnetter

Nog steeds discussie gaande over 'olderThan18' :+ (mijn grootste WTF was inderdaad de creatieve manier waarop het DateTime object gemaakt werd, maar de naam van de variabele zelf is ook niet helemaal handig)

Ik heb zelf ook even goed moeten kijken hoe het nou precies zit, maar het wordt dus gebruikt in een stukje berekening mbt Kindgebonden budget, waarbij deze variabele als een ondergrens gebruikt wordt om kinderen weg te filteren die dus al ouder dan 18 zijn:

code:
1
if (geboortedatum kind > 'olderThan18') doe iets

Kater? Eerst water, de rest komt later
Last.fm profiel


  • CurlyMo
  • Registratie: februari 2011
  • Laatst online: 23:42

CurlyMo

www.pilight.org

Haan schreef op donderdag 14 november 2019 @ 11:46:
Nog steeds discussie gaande over 'olderThan18' :+ (mijn grootste WTF was inderdaad de creatieve manier waarop het DateTime object gemaakt werd, maar de naam van de variabele zelf is ook niet helemaal handig)

Ik heb zelf ook even goed moeten kijken hoe het nou precies zit, maar het wordt dus gebruikt in een stukje berekening mbt Kindgebonden budget, waarbij deze variabele als een ondergrens gebruikt wordt om kinderen weg te filteren die dus al ouder dan 18 zijn:

code:
1
if (geboortedatum kind > 'olderThan18') doe iets

Terwijl het stukje code daar dus niet voor geschikt is want het geeft uitgaande van je beschrijving verkeerde resultaten.

geen vragen via PM die ook op het forum gesteld kunnen worden.


  • Janoz
  • Registratie: oktober 2000
  • Laatst online: 05-12 20:57

Janoz

Moderator Devschuur®

!litemod

CurlyMo schreef op donderdag 14 november 2019 @ 11:55:
[...]

Terwijl het stukje code daar dus niet voor geschikt is want het geeft uitgaande van je beschrijving verkeerde resultaten.
Mwah, lees het stukje van @JeroenE nog even een keertje ;).


Hier is nog een voorbeeld van zoiets:

Artikel 2; deelname
https://strongviking.com/nl/condities/
........ minimum leeftijd van 5 jaar (of wordt 5 jaar in dat kalenderjaar)......

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


  • heuveltje
  • Registratie: februari 2000
  • Laatst online: 21:27

heuveltje

KoelkastFilosoof

Janoz schreef op donderdag 14 november 2019 @ 16:16:
[...]


Mwah, lees het stukje van @JeroenE nog even een keertje ;).


Hier is nog een voorbeeld van zoiets:

Artikel 2; deelname
https://strongviking.com/nl/condities/


[...]
niet zozeer codegerelateerd, maar wtf, je gaat je kind van 4 mee laten rennen in een 3km obstakel run. :?

heuveltje wijzigde deze reactie 14-11-2019 16:53 (3%)

Tell me where is gandalf? for i much desire to speak with him!


  • Janoz
  • Registratie: oktober 2000
  • Laatst online: 05-12 20:57

Janoz

Moderator Devschuur®

!litemod

heuveltje schreef op donderdag 14 november 2019 @ 16:49:
[...]


niet zozeer codegerelateerd, maar wtf, je gaat je kind van 4 mee laten rennen in een 3km obstakel run. :?
Oh, ik wel hoor. Sowieso zijn de hindernissen natuurlijk ook op die leeftijd afgesteld, en daarnaast zijn kinderen over het algemeen een stuk behendiger in dergelijke dingen dan de gemiddelde volwassene.

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


  • CurlyMo
  • Registratie: februari 2011
  • Laatst online: 23:42

CurlyMo

www.pilight.org

Janoz schreef op donderdag 14 november 2019 @ 16:16:
[...]
Mwah, lees het stukje van @JeroenE nog even een keertje ;).
Haan schreef op vrijdag 8 november 2019 @ 11:28:

C#:
1
var olderThan18 = DateTime.Parse((currentYear - 19).ToString() + "-12-31");


d:)b
Voor het gemak alles even als integers. Stel is het nu 20190601 dan is de output van dit stukje 20001231. Iemand geboren op 20010101 is dan geen 18 op de huidige datum, maar dat is die wel volgens dit script.

Dit voorbeeld klopte inderdaad niet.

olderThan18 gaat qua variabele goed, mits je het niet omgekeerd gaat gebruiken om te checken of iemand jonger is dan 18.

CurlyMo wijzigde deze reactie 15-11-2019 13:09 (3%)

geen vragen via PM die ook op het forum gesteld kunnen worden.


  • Matis
  • Registratie: januari 2007
  • Laatst online: 20:57

Matis

Rubber Rocket

Ik zou gewoon de geboortedatum pakken, daar 18 jaar bij optellen en vergelijken met de (huidige) datum. Is die kleiner, dan is het antwoord nee.

Even kijken per programmeertaal hoe ze omgaat met schrikkeljaar en wat corner cases rond de jaarwisseling, maar verder zou ik het niet veel moeilijker maken.

If money talks then I'm a mime
If time is money then I'm out of time


  • Janoz
  • Registratie: oktober 2000
  • Laatst online: 05-12 20:57

Janoz

Moderator Devschuur®

!litemod

CurlyMo schreef op donderdag 14 november 2019 @ 19:11:
[...]


[...]

Voor het gemak alles even als integers. Stel is het nu 20190601 dan is de output van dit stukje 20001231. Iemand geboren op 20010101 is dan geen 18 op de huidige datum, maar dat is die wel volgens dit script.
Iemand die op 1 jan 2001 geboren is, wordt 18 op 1 jan 2019. Op 1 juni 2019 zal hij waarschijnlijk zijn rijbewijs al hebben ;)

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


  • Merethil
  • Registratie: december 2008
  • Laatst online: 21:38
Matis schreef op donderdag 14 november 2019 @ 21:24:
Ik zou gewoon de geboortedatum pakken, daar 18 jaar bij optellen en vergelijken met de (huidige) datum. Is die kleiner, dan is het antwoord nee.

Even kijken per programmeertaal hoe ze omgaat met schrikkeljaar en wat corner cases rond de jaarwisseling, maar verder zou ik het niet veel moeilijker maken.
Als je een goede datetimelibrary gebruikt dan houdt die daar rekening mee en heeft ie vaak een "addYears(int years)"-functie waar je er 18 bij op kan tellen. Dan zal het altijd moeten kloppen.

  • Crazy D
  • Registratie: augustus 2000
  • Laatst online: 19:00

Crazy D

I think we should take a look.

Janoz schreef op donderdag 14 november 2019 @ 16:16:
[...]


Mwah, lees het stukje van @JeroenE nog even een keertje ;).


Hier is nog een voorbeeld van zoiets:

Artikel 2; deelname
https://strongviking.com/nl/condities/


[...]
En zo zie je maar weer hoe belangrijk de specs zijn (even los van het feit of de code zo geweldig is en het juiste resultaat geeft) maar de subtiele aanvulling "of in het jaar waarin...." is wel een cruciaal stukje waar de gemiddelde programmeur wellicht erg makkelijk overheen kijkt :P

Exact expert nodig? itwize.nl


  • downtime
  • Registratie: januari 2000
  • Niet online

downtime

Everybody lies

Matis schreef op donderdag 14 november 2019 @ 21:24:
Ik zou gewoon de geboortedatum pakken, daar 18 jaar bij optellen en vergelijken met de (huidige) datum. Is die kleiner, dan is het antwoord nee.

Even kijken per programmeertaal hoe ze omgaat met schrikkeljaar en wat corner cases rond de jaarwisseling, maar verder zou ik het niet veel moeilijker maken.
Juist niet naar schrikkeljaren en corner cases kijken. Die zijn immers irrelevant bij het vergelijken van dit soort datums. Iemand die op 1 maart is geboren in een gewoon jaar viert zijn verjaardag immers niet opeens op 29 februari in een schrikkeljaar. Je moet echt 18 jaar bij de geboortedatum optellen en niet 18 maal 365,25 dagen.

Ik realiseer me nu opeens dat ook dit een corner case kent. Iemand die op 29 februari is geboren wordt 18 jaar later meerderjarig op een datum die in dat jaar niet voorkomt. Dat zal zelden een probleem opleveren maar is niettemin een corner case.

downtime wijzigde deze reactie 15-11-2019 10:42 (14%)


  • CurlyMo
  • Registratie: februari 2011
  • Laatst online: 23:42

CurlyMo

www.pilight.org

Janoz schreef op vrijdag 15 november 2019 @ 09:47:
[...]

Iemand die op 1 jan 2001 geboren is, wordt 18 op 1 jan 2019. Op 1 juni 2019 zal hij waarschijnlijk zijn rijbewijs al hebben ;)
Je reageert niet op wat ik schrijf. Bepalen of iemand ouder is dan 18 gaat wel goed, alleen niet of iemand jonger is dan 18.

geen vragen via PM die ook op het forum gesteld kunnen worden.


  • Janoz
  • Registratie: oktober 2000
  • Laatst online: 05-12 20:57

Janoz

Moderator Devschuur®

!litemod

Ik reageer wel degelijk op wat je schrijft ;). Jij zegt dat iemand die op 1 januari 2001 geboren is op 6 juli 2019 nog geen 18 is, maar die is dan al 18 jaar en een paar maanden oud. Je zult met een correct voorbeeld moeten komen om je punt te maken.

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


  • Matis
  • Registratie: januari 2007
  • Laatst online: 20:57

Matis

Rubber Rocket

downtime schreef op vrijdag 15 november 2019 @ 10:29:
Juist niet naar schrikkeljaren en corner cases kijken. Die zijn immers irrelevant bij het vergelijken van dit soort datums. Iemand die op 1 maart is geboren in een gewoon jaar viert zijn verjaardag immers niet opeens op 29 februari in een schrikkeljaar. Je moet echt 18 jaar bij de geboortedatum optellen en niet 18 maal 365,25 dagen.
Nee, ik bedoelde juist personen die op 29 februari geboren zijn. Ik heb in PHP (ja ik weet het) af en toe iets moois, als je op 30 januari + 1 maand doet, dan komt ie ergens in de eerste dagen van maart uit (afhankelijk van wel of geen schrikkeljaar). Slaat ie mooi februari over.

Been there, done that :+


PHP:
1
2
3
$time = strtotime("2019-01-31");
$final = date("Y-m-d", strtotime("+1 month", $time));
var_dump($final);


string(10) "2019-03-03"

Matis wijzigde deze reactie 15-11-2019 10:52 (10%)

If money talks then I'm a mime
If time is money then I'm out of time


  • Merethil
  • Registratie: december 2008
  • Laatst online: 21:38
Matis schreef op vrijdag 15 november 2019 @ 10:43:
[...]

Nee, ik bedoelde juist personen die op 29 februari geboren zijn. Ik heb in PHP (ja ik weet het) af en toe iets moois, als je op 30 januari + 1 maand doet, dan komt ie ergens in de eerste dagen van maart uit (afhankelijk van wel of geen schrikkeljaar). Slaat ie mooi februari over.

Been there, done that :+


PHP:
1
2
3
$time = strtotime("2019-01-31");
$final = date("Y-m-d", strtotime("+1 month", $time));
var_dump($final);


string(10) "2019-03-03"
Dat is toch gewoon verwacht gedrag? Je telt er een maand bij op, dus ga je naar 31-02-2019, wat niet bestaat en dus overflowt hij. Wat had je zelf verwacht dat 'ie zou doen dan?

Is trouwens ook zo in andere talen. Java doet hetzelfde vziw. En C# vast ook. En JavaScript, python en Ruby doen dat volgens mij ook.
Had ik het toch even fout zeg...

Merethil wijzigde deze reactie 15-11-2019 12:21 (10%)


  • Janoz
  • Registratie: oktober 2000
  • Laatst online: 05-12 20:57

Janoz

Moderator Devschuur®

!litemod

Merethil schreef op vrijdag 15 november 2019 @ 10:58:
[...]


Dat is toch gewoon verwacht gedrag? Je telt er een maand bij op, dus ga je naar 31-02-2019, wat niet bestaat en dus overflowt hij. Wat had je zelf verwacht dat 'ie zou doen dan?

Is trouwens ook zo in andere talen. Java doet hetzelfde vziw. En C# vast ook. En JavaScript, python en Ruby doen dat volgens mij ook.
Nope


Java:
1
2
3
4
    public void telMaandOp() {
        LocalDate datum = LocalDate.of(2020,1,31);
        System.out.println(datum.plusMonths(1));
    }


output:

2020-02-29


--edit--
Oh, en nu ik toch bezig ben, dit is dan wel weer grappig:


Java:
1
2
3
4
5
6
7
    @Test
    public void telMaandOp() {
        LocalDate datum = LocalDate.of(2020,1,31);
        System.out.println(datum.plusMonths(1));
        System.out.println(datum.plusMonths(2));
        System.out.println(datum.plusMonths(1).plusMonths(1));
    }



Output:
2020-02-29
2020-03-31
2020-03-29

Janoz wijzigde deze reactie 15-11-2019 11:12 (24%)

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


  • Kanarie
  • Registratie: oktober 2000
  • Laatst online: 00:53

Kanarie

Dagen van gras, dagen van stro

Ruby doet dit

code:
1
2
>> Date.new(2019, 1, 31) >> 1
=> #<Date: 2019-02-28 ((2458543j,0s,0n),+0s,2299161j)>



Of met ActiveSupport geladen

code:
1
2
>> Date.new(2019, 1, 31) + 1.month
=> Thu, 28 Feb 2019

The fact that we live at the bottom of a gravity well, on the surface of a gas covered planet going around a nuclear fireball 90 million miles away and think this to be normal is obviously some indication of how skewed our perspective tends to be


  • Janoz
  • Registratie: oktober 2000
  • Laatst online: 05-12 20:57

Janoz

Moderator Devschuur®

!litemod

Oh, en nu ik toch bezig was @CurlyMo


Java:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
    LocalDate nu = LocalDate.of(2019,6,1);

    LocalDate olderThan18 = LocalDate.of(nu.getYear()-19,12,31);

    private boolean isDitEenKind(LocalDate geboortedatum) {
        return geboortedatum.isAfter(olderThan18);
    }

    private int leeftijd(LocalDate geboorteDatum) {
        return Period.between(geboorteDatum,nu).getYears();
    }

    private void printPersoon(String naam, LocalDate geboorteDatum) {
        System.out.println(String.format("%s is %s jaar oud.", naam, leeftijd(geboorteDatum)));
        System.out.println(String.format("%s is %s een kind.", naam, isDitEenKind(geboorteDatum)?"wel":"niet"));

    }

    @Test
    public void testPersonen() {
        printPersoon("Jan", LocalDate.of(2001,1,1));
        printPersoon("Piet", LocalDate.of(2001,7,1));
        printPersoon("Klaas", LocalDate.of(2000,12,31));
    }



Output:

Jan is 18 jaar oud.
Jan is wel een kind.
Piet is 17 jaar oud.
Piet is wel een kind.
Klaas is 18 jaar oud.
Klaas is niet een kind.


En dat sluit weer precies aan bij het kalenderjaar verhaal

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


  • Matis
  • Registratie: januari 2007
  • Laatst online: 20:57

Matis

Rubber Rocket

Merethil schreef op vrijdag 15 november 2019 @ 10:58:
Dat is toch gewoon verwacht gedrag? Je telt er een maand bij op, dus ga je naar 31-02-2019, wat niet bestaat en dus overflowt hij. Wat had je zelf verwacht dat 'ie zou doen dan?
Het is meer dat ik er, toen ik er voor het eerst tegenaan liep, geen verklaring voor had. Als je het fenomeen zoals jij het nu omschrijft uitlegt snap ik het wel.
Maar als je medio juni een stukje code schrijft en het jaar er op gaat het fout, dan moet je toch wel weer even graven.

Voor nu zit deze werking altijd in mijn hoofd geprent.

If money talks then I'm a mime
If time is money then I'm out of time


  • CurlyMo
  • Registratie: februari 2011
  • Laatst online: 23:42

CurlyMo

www.pilight.org

Janoz schreef op vrijdag 15 november 2019 @ 11:23:
Oh, en nu ik toch bezig was @CurlyMo

En dat sluit weer precies aan bij het kalenderjaar verhaal
Maar ik heb @Haan helemaal niet zien refereren aan kalenderjaar, @JeroenE inderdaad wel.

Ik heb het zelf ook even gedaan in PostgreSQL:

SQL:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
select
    max(h),
    min(g),
    max(g)
from
    (select
        a.a > (extract('YEAR' from now()) - 19 || '-12-31')::date as a,
        extract('year' from age(now()::date, a.a)) as f,
        a.a as g,
        now()::date as h
    from
        (select
            generate_series('2001-01-01', '2002-01-01', interval '1 day')::date as a
        ) as a
    ) as a
where
    f != 18
and
    a is true



Output:

code:
1
2019-11-15     2001-11-16     2002-01-01


Dus op de huidige datum van 15 november 2019 wordt iedereen tussen 16 november 2001 en 1 januari 2002 geboren onterecht als 18 aangemerkt.

Als je voorwaarde is dat je selecteert op het jaar waarin iemand 18 wordt dan gaat het inderdaad wel prima. Maar dan zou ik van beide datums het jaar extraheren en die met elkaar vergelijken. Dan ziet iedereen dat je alleen geïnteresseerd bent in het kalenderjaar en dat de dag en maand geen enkele rol spelen.

geen vragen via PM die ook op het forum gesteld kunnen worden.


  • Janoz
  • Registratie: oktober 2000
  • Laatst online: 05-12 20:57

Janoz

Moderator Devschuur®

!litemod

CurlyMo schreef op vrijdag 15 november 2019 @ 11:44:

Maar ik heb @Haan helemaal niet zien refereren aan kalenderjaar, @JeroenE inderdaad wel.
Daarom verwees ik ook naar Jeroen, en niet naar Haan ;):
Janoz schreef op donderdag 14 november 2019 @ 16:16:
Mwah, lees het stukje van @JeroenE nog even een keertje ;).
Als je voorwaarde is dat je selecteert op het jaar waarin iemand 18 wordt dan gaat het inderdaad wel prima. Maar dan zou ik van beide datums het jaar extraheren en die met elkaar vergelijken. Dan ziet iedereen dat je alleen geïnteresseerd bent in het kalenderjaar en dat de dag en maand geen enkele rol spelen.
Oh, maar ik denk dat we het er allemaal wel over eens zijn dat de code waar Haan mee aankwam slechte naamgeving, slechte documentatie en een slechte implementatie heeft.

Janoz wijzigde deze reactie 15-11-2019 11:56 (22%)

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


  • Merethil
  • Registratie: december 2008
  • Laatst online: 21:38
Janoz schreef op vrijdag 15 november 2019 @ 11:09:
[...]

Nope


Java:
1
2
3
4
    public void telMaandOp() {
        LocalDate datum = LocalDate.of(2020,1,31);
        System.out.println(datum.plusMonths(1));
    }


output:

2020-02-29


--edit--
Oh, en nu ik toch bezig ben, dit is dan wel weer grappig:


Java:
1
2
3
4
5
6
7
    @Test
    public void telMaandOp() {
        LocalDate datum = LocalDate.of(2020,1,31);
        System.out.println(datum.plusMonths(1));
        System.out.println(datum.plusMonths(2));
        System.out.println(datum.plusMonths(1).plusMonths(1));
    }



Output:
2020-02-29
2020-03-31
2020-03-29
Ik zou zweren dat het wel zo was maar blijkbaar niet. Bijzonder. Bedankt voor de rectificatie!

  • Janoz
  • Registratie: oktober 2000
  • Laatst online: 05-12 20:57

Janoz

Moderator Devschuur®

!litemod

Merethil schreef op vrijdag 15 november 2019 @ 12:21:
[...]


Ik zou zweren dat het wel zo was maar blijkbaar niet. Bijzonder. Bedankt voor de rectificatie!
In de oude Calendar implementatie werkte het wel zo, maar dat was zo'n draak om mee te werken dat iedereen al snel voor JodaTime koos. Wel jammer dat het nogal lang heeft moeten duren voor er wat fatsoenlijks in Java zelf kwam.


Java:
1
2
3
4
5
6
    @Test
    public void telMaandOpOud() {
        Calendar datum = new GregorianCalendar(2020, 1, 31);
        datum.add(Calendar.MONTH,1);
        System.out.println(datum.get(Calendar.YEAR) + "-" + datum.get(Calendar.MONTH) + "-" + datum.get(Calendar.DAY_OF_MONTH));
    }



geeft:
2020-3-2

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


  • Tjolk
  • Registratie: juni 2007
  • Laatst online: 06-12 15:17

Tjolk

FP ProMod
En daarom zijn datums dus niet zo gemakkelijk als mensen wel eens denken.

Er staat bij ons al een tijd lang een ticket open vanwege precies dat. De essentie van de vraag is in hoeverre het resultaat afwijkt van verwacht gedrag. Immers: 31 januari + 1 maand kan niet leiden tot 31 februari omdat dit geen bestaande datum is. Eigenlijk moet er dan een arbitraire keuze gemaakt worden:
1. Tel je 3 dagen bij 28 februari op (PHP doet met de geclaimde implementatie van ISO 8601)
2. Ga je uit van 'de laatste dag van de maand' (leidt tot wisselende datums)
3. Laat je maanden met minder dan 31 dagen achterwege (wat ongetwijfeld ook bezwaren oplevert)

En bij optie 1 kun je je dan ook weer afvragen of je bij een repeterende interval moet kiezen voor:
31 januari
3 maart
3 april

of
31 januari
3 maart
31 maart

Eigenlijk doe je het altijd voor een aanzienlijk deel van de gebruikers fout.

't is net alsof je het over friet of patat hebt :P

Tjolk is lekker. overal en altijd.


  • Merethil
  • Registratie: december 2008
  • Laatst online: 21:38
Janoz schreef op vrijdag 15 november 2019 @ 13:03:
[...]


In de oude Calendar implementatie werkte het wel zo, maar dat was zo'n draak om mee te werken dat iedereen al snel voor JodaTime koos. Wel jammer dat het nogal lang heeft moeten duren voor er wat fatsoenlijks in Java zelf kwam.


Java:
1
2
3
4
5
6
    @Test
    public void telMaandOpOud() {
        Calendar datum = new GregorianCalendar(2020, 1, 31);
        datum.add(Calendar.MONTH,1);
        System.out.println(datum.get(Calendar.YEAR) + "-" + datum.get(Calendar.MONTH) + "-" + datum.get(Calendar.DAY_OF_MONTH));
    }



geeft:
2020-3-2
Ik wist dat ik het ergens gezien zou moeten hebben (doe veel Java maar nauwelijks datum/tijd-manipulatie). Bedankt :) Wel gek dat het nog in mijn hoofd zit, laatste jaren gebruik ik Java 8 dus geen oude calenderzut meer maar blijkbaar dus ook sindsdien geen echte datum/tijd-manipulatie hoeven doen...

  • Crazy D
  • Registratie: augustus 2000
  • Laatst online: 19:00

Crazy D

I think we should take a look.

Tjolk schreef op vrijdag 15 november 2019 @ 14:38:
En daarom zijn datums dus niet zo gemakkelijk als mensen wel eens denken.

Er staat bij ons al een tijd lang een ticket open vanwege precies dat. De essentie van de vraag is in hoeverre het resultaat afwijkt van verwacht gedrag. Immers: 31 januari + 1 maand kan niet leiden tot 31 februari omdat dit geen bestaande datum is. Eigenlijk moet er dan een arbitraire keuze gemaakt worden:
1. Tel je 3 dagen bij 28 februari op (PHP doet met de geclaimde implementatie van ISO 8601)
2. Ga je uit van 'de laatste dag van de maand' (leidt tot wisselende datums)
3. Laat je maanden met minder dan 31 dagen achterwege (wat ongetwijfeld ook bezwaren oplevert)

En bij optie 1 kun je je dan ook weer afvragen of je bij een repeterende interval moet kiezen voor:
31 januari
3 maart
3 april

of
31 januari
3 maart
31 maart

Eigenlijk doe je het altijd voor een aanzienlijk deel van de gebruikers fout.

't is net alsof je het over friet of patat hebt :P
Plus, is 1 maand optellen bij 31 januari, dan 31 dagen erbij tellen, of 30?

Daarom wordt er best vaak (in ieder geval in het bedrijfsleven) als je het hebt over iets dat maandelijks gebeurt, vaker over de 1e of laatste van de maand, want dan is het altijd simpel: laatste dag van de betreffende maand. Of desnoods "1 week voor de laatste dag van de maand" dan wordt dat dus gewoon 24 januari en 21 februari.

Maar het ei dat bedacht heeft dat niet elke maand even veel dagen heeft, heeft niet echt een vooruitziende blik gehad...

Exact expert nodig? itwize.nl


  • Vaan Banaan
  • Registratie: februari 2001
  • Niet online

Vaan Banaan

Heeft ook Apache ontdekt

^^^ Bovenstaand bericht is goedgekeurd door Asterix en Obelix ^^^
:o

500 "The server made a boo boo"


  • mcDavid
  • Registratie: april 2008
  • Laatst online: 17:31
Crazy D schreef op vrijdag 15 november 2019 @ 15:14:
[...]

Maar het ei dat bedacht heeft dat niet elke maand even veel dagen heeft, heeft niet echt een vooruitziende blik gehad...
Wat is jouw voorstel dan, om een jaar van (ietsje minder dan) 365,25 dagen in gelijke porties te verdelen?

zcflevo.nl


  • Jerrythafast
  • Registratie: september 2012
  • Laatst online: 18:08

Jerrythafast

Hier, aan de kust

Ik heb een beter idee wat redelijk dicht ligt bij wat we nu doen. Afwisselend een jaar met 12 maanden van 30 dagen en een jaar met 12 maanden van 31 dagen. 1x in de 16 jaar we doen we ipv 31 dagen gewoon 30 dagen per maand (dan heb je dus 3 jaar achter elkaar 12x30).

Hiermee behouden we het concept van 12 maanden per jaar, met vertrouwde lengte van 30 of 31 dagen per maand, en met een periodieke gekkigheid om op een gemiddelde van 365,25 dagen per jaar te eindigen. Je kunt bijvoorbeeld de even jaartallen 31 dagen per maand doen, behalve als het jaartal deelbaar is door 16. Lekker makkelijk te programmeren ook.

Dat tezamen met het afschaffen van de zomer/wintertijd maakt dat we in dit topic in ieder geval geen rare datum/tijdmanipulaties meer hoeven te verwachten O-)

Jerrythafast wijzigde deze reactie 17-11-2019 10:53 (11%)

2925 Wp op SE3000 live op PVOutput en Jerweb.nl || Nu ook De Triangel 3020 Wp (live logging in aanbouw)


  • ThomasG
  • Registratie: juni 2006
  • Laatst online: 17:31
Jerrythafast schreef op zondag 17 november 2019 @ 10:50:

Dat tezamen met het afschaffen van de zomer/wintertijd maakt dat we in dit topic in ieder geval geen rare datum/tijdmanipulaties meer hoeven te verwachten O-)
De meeste willen dan de zomertijd als tijd voor het hele jaar, terwijl de wintertijd juist de normale tijd is. En de wintertijd loopt al 40 minuten voor op wat het werkelijk zou moeten zijn. 8)7

  • downtime
  • Registratie: januari 2000
  • Niet online

downtime

Everybody lies

Jerrythafast schreef op zondag 17 november 2019 @ 10:50:
Ik heb een beter idee wat redelijk dicht ligt bij wat we nu doen. Afwisselend een jaar met 12 maanden van 30 dagen en een jaar met 12 maanden van 31 dagen. 1x in de 16 jaar we doen we ipv 31 dagen gewoon 30 dagen per maand (dan heb je dus 3 jaar achter elkaar 12x30).

Hiermee behouden we het concept van 12 maanden per jaar, met vertrouwde lengte van 30 of 31 dagen per maand, en met een periodieke gekkigheid om op een gemiddelde van 365,25 dagen per jaar te eindigen. Je kunt bijvoorbeeld de even jaartallen 31 dagen per maand doen, behalve als het jaartal deelbaar is door 16. Lekker makkelijk te programmeren ook.

Dat tezamen met het afschaffen van de zomer/wintertijd maakt dat we in dit topic in ieder geval geen rare datum/tijdmanipulaties meer hoeven te verwachten O-)
Veel te ingewikkeld.

Even out of the box denken: Het probleem met onze kalender is dat die gebaseerd is op twee fenomenen die niet in de pas lopen. Het is alsof je een meter wilt uitdrukken in een heel aantal inches (i.p.v. centimeters) en het dan maar oplost door 40 inches in een meter te stoppen waarbij elke derde meter een schrikkelmeter van 39 inch is. (de realiteit zou nog ingewikkelder zijn)

Bij de kalender speelt dat ook. We proberen een dag, de periode waarin de aarde om zijn as draait, te passen in een ongerelateerde waarde, het astronomische jaar, de periode waarin de aarde om de zon draait (dit komt overeen met de 4 seizoenen). Dat past niet en dus bedenken we daar complexe workarounds voor.
En dan hebben we ook nog de week, die weliswaar uit 7 dagen bestaat, maar geen relatie met maanden en jaren heeft.

De oplossing is dan ook simpel: Definieer een maand als 28 dagen, een jaar als 364 dagen (13 maal 28 dagen), introduceer een extra maand, en accepteer dat de seizoenen op de lange duur uit de pas met het kalenderjaar lopen. Na een paar eeuwen kunnen we in augustus schaatsen.
Daar staat tegenover dat er nu exact 4 weken in een maand passen en 52 weken in een jaar. Elke maand en elk jaar start daardoor ook op dezelfde dag van de week.

Nu nog even een naam voor de extra maand verzinnen.

  • .oisyn
  • Registratie: september 2000
  • Laatst online: 01:41

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

mcDavid schreef op zondag 17 november 2019 @ 10:06:
[...]


Wat is jouw voorstel dan, om een jaar van (ietsje minder dan) 365,25 dagen in gelijke porties te verdelen?
Het is trouwens 365,2425. Daarom hebben hele eeuwen geen schrikkeldag, behalve als het jaartal deelbaar is door 400 :).

We were doomed from the start. I guess all that remains now is for the captain to go down with the ship.
- That's surprisingly noble of you, sir.
No, it's noble of you, Kif! As of now, you're in command. Congratulations, Captain!


  • mcDavid
  • Registratie: april 2008
  • Laatst online: 17:31
Jerrythafast schreef op zondag 17 november 2019 @ 10:50:
Ik heb een beter idee wat redelijk dicht ligt bij wat we nu doen. Afwisselend een jaar met 12 maanden van 30 dagen en een jaar met 12 maanden van 31 dagen. 1x in de 16 jaar we doen we ipv 31 dagen gewoon 30 dagen per maand (dan heb je dus 3 jaar achter elkaar 12x30).

Hiermee behouden we het concept van 12 maanden per jaar, met vertrouwde lengte van 30 of 31 dagen per maand, en met een periodieke gekkigheid om op een gemiddelde van 365,25 dagen per jaar te eindigen. Je kunt bijvoorbeeld de even jaartallen 31 dagen per maand doen, behalve als het jaartal deelbaar is door 16. Lekker makkelijk te programmeren ook.

Dat tezamen met het afschaffen van de zomer/wintertijd maakt dat we in dit topic in ieder geval geen rare datum/tijdmanipulaties meer hoeven te verwachten O-)
ik zou dan liever 13 maanden van 28 dagen doen. Loopt het ook netjes gelijk met de weken. Doe je bij de jaarwisseling 1 á 2 blanco dagen invoegen om te zorgen dat je in sync blijft lopen met de omlooptijd om de zon. Als je die bedrijfsvrij maakt is heel Nederland in één klap voorstander ook.

zcflevo.nl


  • downtime
  • Registratie: januari 2000
  • Niet online

downtime

Everybody lies

mcDavid schreef op zondag 17 november 2019 @ 13:55:
[...]

Doe je bij de jaarwisseling 1 á 2 blanco dagen invoegen om te zorgen dat je in sync blijft lopen met de omlooptijd om de zon.
Waarom? Dat is ooit verzonnen toen de meerderheid van Europa van het land leefde, het hele leven van die mensen draaide om de seizoenen, maar vandaag de dag is dat voor niemand meer belangrijk.
Als je een jaar gewoon 364 dagen maakt zal niemand echt merken dat de seizoenswisselingen niet meer in de pas lopen met het kalenderjaar. Daarvoor gaat het te langzaam.

  • mcDavid
  • Registratie: april 2008
  • Laatst online: 17:31
Dat lijkt me juist uitermate onpraktisch. Dan moet er (by design) jaarlijks van alles aangepast worden. Zoals vakantieperiodes, seizoensgebonden werk, lesstof, etc. We mogen dan niet meer "van het land leven", maar de seizoenen zijn toch behoorlijk verweven met vrijwel iedere leven.

zcflevo.nl


  • downtime
  • Registratie: januari 2000
  • Niet online

downtime

Everybody lies

mcDavid schreef op zondag 17 november 2019 @ 14:52:
Dat lijkt me juist uitermate onpraktisch. Dan moet er (by design) jaarlijks van alles aangepast worden. Zoals vakantieperiodes, seizoensgebonden werk, lesstof, etc. We mogen dan niet meer "van het land leven", maar de seizoenen zijn toch behoorlijk verweven met vrijwel iedere leven.
Valt wel mee. De eerste jaren gaat het maar om een paar dagen verschil. En daar staan ook voordelen tegenover. Vakantieperiodes vallen nu elk jaar op een iets andere datum, omdat vakanties nu eenmaal altijd van weekend tot weekend lopen, en is soms ook per regio verschillend. Dat kan dan 7 jaar hetzelfde blijven en dan verschuif je het een week. Hetzelfde geldt voor seizoensgebonden werk.

Lesstof aanpassen is triviaal. Dat materiaal wordt toch geregeld herzien en herdrukt. En de eerste paar jaar kan meester of juffrouw zelf wel even vertellen dat het boekje niet meer klopt.

Het raarste is juist die dertiende maand erbij. Opeens zit er een maand tussen Kerst en Nieuwjaar. Of doen we Kerst dan pas aan het einde van de dertiende maand? Het is vooral die extra maand waar mensen aan moeten wennen.

  • Jerrythafast
  • Registratie: september 2012
  • Laatst online: 18:08

Jerrythafast

Hier, aan de kust

downtime schreef op zondag 17 november 2019 @ 12:42:
[...]
Nu nog even een naam voor de extra maand verzinnen.
Downtime natuurlijk O-)
mcDavid schreef op zondag 17 november 2019 @ 13:55:
[...]

ik zou dan liever 13 maanden van 28 dagen doen. Loopt het ook netjes gelijk met de weken. Doe je bij de jaarwisseling 1 á 2 blanco dagen invoegen om te zorgen dat je in sync blijft lopen met de omlooptijd om de zon. Als je die bedrijfsvrij maakt is heel Nederland in één klap voorstander ook.
Oké, jullie pleiten beide voor 13x28, zit inderdaad ook wat in. Ik zou wel graag in de pas blijven lopen met de zon, dus dat betekent inderdaad ieder jaar één extra dag en in de schrikkeljaren twee. In eerste instantie vond ik je voorstel om die dagen bedrijfsvrij te maken een goed idee (het werkt dus! je kunt zo de politiek in). Maar toen ging ik nadenken... onze politiek kennende wordt "Nieuwjaarsdag" dan een eenmalige 8ste dag van de week die gewoon aan het weekend wordt geplakt (zaterdag, zondag, Nieuwjaarsdag, maandag). En dan hebben we netto nog steeds geen extra vrije dag gescoord, want Nieuwjaarsdag is nu ook al bedrijfsvrij wanneer het doordeweeks valt :/

Ik stel trouwens voor om Nieuwjaarsdag en Schrikkeldag aan het einde van het jaar te doen, zodat programmeertechnisch 1 Januari altijd de eerste dag van het jaar is en we van daaruit kunnen doortellen. Wat wordt het leven dan makkelijk 8)

Python:
1
2
3
4
5
6
7
8
9
dagVanHetJaar = 0 # 1 januari
if dagVanHetJaar < 364:
    dagVanDeMaand = dagVanHetJaar % 28 + 1
    maand = maanden[dagVanHetJaar // 28]
    dagVanDeWeek = weekdagen[dagVanHetJaar % 7]
elif dagVanhetJaar == 364:
    dagVanDeWeek = "Nieuwjaarsdag"
elif dagVanHetJaar == 365:
    dagVanDeWeek = "Schrikkeldag"

downtime schreef op zondag 17 november 2019 @ 15:23:
[...]
Het raarste is juist die dertiende maand erbij. Opeens zit er een maand tussen Kerst en Nieuwjaar. Of doen we Kerst dan pas aan het einde van de dertiende maand? Het is vooral die extra maand waar mensen aan moeten wennen.
Als we nog kans willen maken op een witte Kerst moeten we dat gaan vieren op 25 Downtime ipv 25 December...

Jerrythafast wijzigde deze reactie 17-11-2019 15:45 (14%)

2925 Wp op SE3000 live op PVOutput en Jerweb.nl || Nu ook De Triangel 3020 Wp (live logging in aanbouw)


  • kenneth
  • Registratie: september 2001
  • Niet online

kenneth

achter de duinen

Hoe perfect het nieuwe systeem ook is, je moet dan werken met een nieuw systeem vanaf datum X en met het oude systeem vóór datum X. En dat opent een nieuw blik met wormen :p Dit soort problemen: https://stackoverflow.com...s-giving-a-strange-result

De beste oplossing lijkt me om te accepteren dat het ingewikkeld is en blijft, en zo min mogelijk te veranderen.

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


  • downtime
  • Registratie: januari 2000
  • Niet online

downtime

Everybody lies

kenneth schreef op zondag 17 november 2019 @ 16:38:
Hoe perfect het nieuwe systeem ook is, je moet dan werken met een nieuw systeem vanaf datum X en met het oude systeem vóór datum X. En dat opent een nieuw blik met wormen :p Dit soort problemen: https://stackoverflow.com...s-giving-a-strange-result

De beste oplossing lijkt me om te accepteren dat het ingewikkeld is en blijft, en zo min mogelijk te veranderen.
Je hebt gelijk natuurlijk. Er is nu een standaard, die wereldwijd wordt gebruikt, en we zijn er helemaal op ingesteld. Zelfs delen van de wereld met een eigen kalender hanteren meestal zonder problemen de westerse kalender ernaast.

Maar het blijft ingewikkeld.

  • mcDavid
  • Registratie: april 2008
  • Laatst online: 17:31
Jerrythafast schreef op zondag 17 november 2019 @ 15:34:
[...]

Oké, jullie pleiten beide voor 13x28, zit inderdaad ook wat in. Ik zou wel graag in de pas blijven lopen met de zon, dus dat betekent inderdaad ieder jaar één extra dag en in de schrikkeljaren twee. In eerste instantie vond ik je voorstel om die dagen bedrijfsvrij te maken een goed idee (het werkt dus! je kunt zo de politiek in). Maar toen ging ik nadenken... onze politiek kennende wordt "Nieuwjaarsdag" dan een eenmalige 8ste dag van de week die gewoon aan het weekend wordt geplakt (zaterdag, zondag, Nieuwjaarsdag, maandag). En dan hebben we netto nog steeds geen extra vrije dag gescoord, want Nieuwjaarsdag is nu ook al bedrijfsvrij wanneer het doordeweeks valt :/
Het moet ook weer niet te gek duur worden he ;) 1x in de 4 jaar een extra dag is prima. Dan doen we idd een extra blanco dag aan het einde van het jaar, en oud-en-nieuw vieren we de nacht vóór die dag.

Die 13e maand noemen we natuurlijk mcDavidember, naar de bedenker 8)
kenneth schreef op zondag 17 november 2019 @ 16:38:
Hoe perfect het nieuwe systeem ook is, je moet dan werken met een nieuw systeem vanaf datum X en met het oude systeem vóór datum X. En dat opent een nieuw blik met wormen :p Dit soort problemen: https://stackoverflow.com...s-giving-a-strange-result

De beste oplossing lijkt me om te accepteren dat het ingewikkeld is en blijft, en zo min mogelijk te veranderen.
Ik vind het juist stom om aan een beslissing uit het verleden vast te blijven houden, terwijl er objectief betere keuzes gemaakt kunnen worden.

Wat dat betreft heb ik nog wel een paar ideeën. Laten we bijvoorbeeld eens ophouden met dat domme decimale getallen stelsel. Octaal rekenen maakt veel meer sense.

zcflevo.nl


  • kenneth
  • Registratie: september 2001
  • Niet online

kenneth

achter de duinen

mcDavid schreef op zondag 17 november 2019 @ 20:22:
[...]

Ik vind het juist stom om aan een beslissing uit het verleden vast te blijven houden, terwijl er objectief betere keuzes gemaakt kunnen worden.
Als je de omschakelingsproblemen meerekent en het feit dat je nog altijd terug in de tijd moet rekenen met het oude systeem heb ik mijn ernstige twijfels bij "objectief beter". Je vervangt niets, er komt gewoon iets bij.
Wat dat betreft heb ik nog wel een paar ideeën. Laten we bijvoorbeeld eens ophouden met dat domme decimale getallen stelsel. Octaal rekenen maakt veel meer sense.
De Sumeriërs hadden al ontdekt dat een zestigtallig stelsel de meeste voordelen biedt :7

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


  • .oisyn
  • Registratie: september 2000
  • Laatst online: 01:41

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

mcDavid schreef op zondag 17 november 2019 @ 20:22:
Octaal rekenen maakt veel meer sense.
Waarom?

We were doomed from the start. I guess all that remains now is for the captain to go down with the ship.
- That's surprisingly noble of you, sir.
No, it's noble of you, Kif! As of now, you're in command. Congratulations, Captain!


  • orf
  • Registratie: augustus 2005
  • Laatst online: 00:43
mcDavid schreef op zondag 17 november 2019 @ 13:55:
[...]

ik zou dan liever 13 maanden van 28 dagen doen. Loopt het ook netjes gelijk met de weken. Doe je bij de jaarwisseling 1 á 2 blanco dagen invoegen om te zorgen dat je in sync blijft lopen met de omlooptijd om de zon. Als je die bedrijfsvrij maakt is heel Nederland in één klap voorstander ook.
Dit idee: https://infomongo.com/posts/proposal-for-a-saner-calendar

  • Reptile209
  • Registratie: juni 2001
  • Laatst online: 00:42

Reptile209

- gers -

mcDavid schreef op zondag 17 november 2019 @ 20:22:

[...]
Ik vind het juist stom om aan een beslissing uit het verleden vast te blijven houden, terwijl er objectief betere keuzes gemaakt kunnen worden.

Wat dat betreft heb ik nog wel een paar ideeën. Laten we bijvoorbeeld eens ophouden met dat domme decimale getallen stelsel. Octaal rekenen maakt veel meer sense.
Recent wat meegekregen van discussies over (zwarte) Piet, 100/130 km/h, zomer/wintertijd, AOW? Dan heb je een idee van hoe bereid men is om tradities te laten varen... En anders moet je vaker buiten komen :+.

If you're not part of the solution, you're part of the precipitate.


  • Crazy D
  • Registratie: augustus 2000
  • Laatst online: 19:00

Crazy D

I think we should take a look.

mcDavid schreef op zondag 17 november 2019 @ 10:06:
[...]


Wat is jouw voorstel dan, om een jaar van (ietsje minder dan) 365,25 dagen in gelijke porties te verdelen?
Je zou natuurlijk van het concept maanden af kunnen stappen :+ Gewoon dag 1 t/m dag 365. Voorkomt ook meteen gedoe met dag-maand-jaar of maand-dag-jaar datum opmaak en -invoer :P

Exact expert nodig? itwize.nl


  • CurlyMo
  • Registratie: februari 2011
  • Laatst online: 23:42

CurlyMo

www.pilight.org

Dan blijft de vraag hoeveel er nu eigenlijk mis gaat en in welke proporties als je met 365 dagen rekent, 365,25 of 365,2425? Specifieke toepassingen daargelaten natuurlijk. Rekenen met datums blijft nu eenmaal klote (kuch, DST) dus laten we het gewoon simpel bij 365 houden. Als je rekent met leeftijden valt dat volgens mij sowieso buiten de levensduur van een persoon.

geen vragen via PM die ook op het forum gesteld kunnen worden.


  • boe2
  • Registratie: november 2002
  • Niet online

boe2

'-')/

Deze discussie doet me denken aan deze mooie video van Tom Scott :)

En hij adresseert dan nog niet eens sommige van de dilemma's die hier genoemd worden.

'Multiple exclamation marks,' he went on, shaking his head, 'are a sure sign of a diseased mind.' - Pratchett.


  • mcDavid
  • Registratie: april 2008
  • Laatst online: 17:31
Ja ongeveer behalve dat 1 januari natuurlijk wel gewoon een maandag is.

8)7 wie begint zijn week nou op zondag.

:+

zcflevo.nl


  • ThomasG
  • Registratie: juni 2006
  • Laatst online: 17:31
Het verschil tussen decimaal en octaal is niet zo groot, waardoor het nauwelijks voordeel heeft. Base-12 (of dozenal) is beter dan zowel decimaal als octaal. Bijvoorbeeld omdat het meer delers heeft (2, 3, 4, en 6) terwijl decimaal enkel 2 en 5 heeft en octaal ook enkel 2 en 4.

  • CurlyMo
  • Registratie: februari 2011
  • Laatst online: 23:42

CurlyMo

www.pilight.org

boe2 schreef op maandag 18 november 2019 @ 09:45:
Deze discussie doet me denken aan deze mooie video van Tom Scott :)
[YouTube: The Problem with Time & Timezones - Computerphile]
En hij adresseert dan nog niet eens sommige van de dilemma's die hier genoemd worden.
Dan kan de video van CGP grey ook niet ontbreken:

geen vragen via PM die ook op het forum gesteld kunnen worden.


  • mcDavid
  • Registratie: april 2008
  • Laatst online: 17:31
ThomasG schreef op maandag 18 november 2019 @ 10:33:
[...]
Het verschil tussen decimaal en octaal is niet zo groot, waardoor het nauwelijks voordeel heeft. Base-12 (of dozenal) is beter dan zowel decimaal als octaal. Bijvoorbeeld omdat het meer delers heeft (2, 3, 4, en 6) terwijl decimaal enkel 2 en 5 heeft en octaal ook enkel 2 en 4.
Het voordeel van 8 is dat het een macht van 2 is, zodat het makkelijker omrekent naar binair, en er prettig breuken mee te maken zijn. Plus je kunt het nog steeds prima op je vingers tellen, moet je alleen je duimen overslaan.

zcflevo.nl


  • Janoz
  • Registratie: oktober 2000
  • Laatst online: 05-12 20:57

Janoz

Moderator Devschuur®

!litemod

Als je alleen met je computerbril kijkt snap ik het. Getallen worden alleen op veel meer plekken gebruikt. En dan blijkt dat 12 eigenlijk veel handiger is. Wist je, dat je in een twaaftallig stelsel tot 144 kunt tellen op je handen?

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


  • .oisyn
  • Registratie: september 2000
  • Laatst online: 01:41

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

ThomasG schreef op maandag 18 november 2019 @ 10:33:
[...]
Het verschil tussen decimaal en octaal is niet zo groot, waardoor het nauwelijks voordeel heeft.
Maar "nauwelijks" betekent nog steeds een klein beetje. Wat is dat voordeel dan? Imho heeft 8 een nadeel tov 10: het heeft maar 1 priemfactor: 2.
mcDavid schreef op maandag 18 november 2019 @ 10:52:
en er prettig breuken mee te maken zijn.
Overal zijn toch prettig breuken mee te maken :?

.oisyn wijzigde deze reactie 18-11-2019 11:06 (22%)

We were doomed from the start. I guess all that remains now is for the captain to go down with the ship.
- That's surprisingly noble of you, sir.
No, it's noble of you, Kif! As of now, you're in command. Congratulations, Captain!


  • mcDavid
  • Registratie: april 2008
  • Laatst online: 17:31
Janoz schreef op maandag 18 november 2019 @ 10:57:
Als je alleen met je computerbril kijkt snap ik het. Getallen worden alleen op veel meer plekken gebruikt. En dan blijkt dat 12 eigenlijk veel handiger is. Wist je, dat je in een twaaftallig stelsel tot 144 kunt tellen op je handen?
Waar zitten mijn 11e en 12e vinger dan?

zcflevo.nl


  • Janoz
  • Registratie: oktober 2000
  • Laatst online: 05-12 20:57

Janoz

Moderator Devschuur®

!litemod

mcDavid schreef op maandag 18 november 2019 @ 11:28:
[...]


Waar zitten mijn 11e en 12e vinger dan?
12 kootjes per hand, en een vrije duim om aan te wijzen waar je gebleven bent met tellen.

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


  • dragonhaertt
  • Registratie: februari 2011
  • Laatst online: 06-12 21:42
mcDavid schreef op maandag 18 november 2019 @ 11:28:
[...]


Waar zitten mijn 11e en 12e vinger dan?
Binair tellen :+

Though we all crumble, we will still perpetuate,
Far beyond all in which, we can participate.
We will live on in all that, which we propagate,
Destined to always be heard, as we resonate.


  • PageFault
  • Registratie: april 2002
  • Laatst online: 06-12 17:52
Als God gewild had dat we met computers om konden gaan, had Hij ons wel 16 vingers gegeven...

  • Brummetje
  • Registratie: december 2003
  • Niet online

Brummetje

Ginkeltjes

PageFault schreef op maandag 18 november 2019 @ 11:41:
[...]


Als God gewild had dat we met computers om konden gaan, had Hij ons wel 16 vingers gegeven...
Om er later achter te komen dat het toch te weinig is en we er 32 64 128 256 etc.. hadden moeten hebben ?:P

  • .oisyn
  • Registratie: september 2000
  • Laatst online: 01:41

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

PageFault schreef op maandag 18 november 2019 @ 11:41:
[...]


Als God gewild had dat we met computers om konden gaan, had Hij ons wel 16 vingers gegeven...
Hij heeft ons er 10 gegeven zodat we tot 1024 kunnen tellen.

We were doomed from the start. I guess all that remains now is for the captain to go down with the ship.
- That's surprisingly noble of you, sir.
No, it's noble of you, Kif! As of now, you're in command. Congratulations, Captain!


  • ThomasG
  • Registratie: juni 2006
  • Laatst online: 17:31
.oisyn schreef op maandag 18 november 2019 @ 11:50:
[...]

Hij heeft ons er 10 gegeven zodat we tot 1024 kunnen tellen.
Maar kunnen we ook floating points op onze vingers? :+

  • .oisyn
  • Registratie: september 2000
  • Laatst online: 01:41

.oisyn

Moderator Devschuur® / Cryptocurrencies

Demotivational Speaker

ThomasG schreef op maandag 18 november 2019 @ 11:55:
[...]
Maar kunnen we ook floating points op onze vingers? :+
3 bits exponent + 7 bits mantissa? ;)

We were doomed from the start. I guess all that remains now is for the captain to go down with the ship.
- That's surprisingly noble of you, sir.
No, it's noble of you, Kif! As of now, you're in command. Congratulations, Captain!


  • R4gnax
  • Registratie: maart 2009
  • Laatst online: 06-12 22:17
.oisyn schreef op maandag 18 november 2019 @ 12:02:
[...]

3 bits exponent + 7 bits mantissa? ;)
Damn it! Nu zit ik met het beeld in m'n kop van iemand die het ook nog aan het proberen is ook. 8)7
(Hm... hier moet een IT-geek web-comic toch ooit een setje panelen aan gewijd hebben, of niet?)

  • Matis
  • Registratie: januari 2007
  • Laatst online: 20:57

Matis

Rubber Rocket

ThomasG schreef op maandag 18 november 2019 @ 11:55:
Maar kunnen we ook floating points op onze vingers? :+
Een aantal mensen die met vuurwerk stuntte wel >:)

If money talks then I'm a mime
If time is money then I'm out of time


  • CurlyMo
  • Registratie: februari 2011
  • Laatst online: 23:42

CurlyMo

www.pilight.org

Ach ja, de evolutie gaat in sommige families nou eenmaal harder dan bij anderen:

geen vragen via PM die ook op het forum gesteld kunnen worden.

Pagina: 1 ... 16 17 18 Laatste


Apple iPhone 11 Nintendo Switch Lite LG OLED C9 Google Pixel 4 FIFA 20 Samsung Galaxy S10 Sony PlayStation 5 Smartphones

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2019 Hosting door True